Just a quick update, I haven't been active here in a while. I just released Deep Sea Descent, the product of about 10 months of work. And I've been moving my blogging over to my own site; I put up a retrospective on the game. I've been gently asked to reproduce it here :)

--------

The Early Concepts

This is the third time I've made DSD. The first two were college projects. The earliest one was a Game Maker game thrown together in a three day weekend. I started by attempting to capture the feeling of exploring the ocean, with drone gameplay and collection being one of the earliest features. When I threw shooting gameplay on top of this the experience became extremely lively and interesting. It was essentially a small demo, one large level with a boss at the end; after collecting all the bombs the path opened to the boss. I knew I had to go back to this and expand it - there was something thrilling in there.

My second attempt was also a technology exercise - I built a 2D engine with SDL, Lua, and Object Pascal(a language choice done on a whim) and with some help from a classmate brought it to completion over the course of a little over a quarter. It was much worse in several ways - the technology was poor, with some fairly janky collision and barebones gameplay - and the scope was way too high; I wanted to start adding some storytelling elements, but discovered fairly quickly that game stories are extremely time-consuming. I played with the mechanics, dropping drones and the one-level layout, and adding inventory and shops, giving it more of an open, Metroidvania feel. The open-ended aspects were appealing, but the game was overall a less distinctive and refined one, despite taking months instead of days.

For this game, I had combat in mind; I wanted to make a game which turned the conventions of shmup combat on its head. I also decided to bring back drones, but I didn't have a clear plan for how they would be used or drive gameplay. I also made a decision early on to use linear levels to help push along a story concept. This was the genesis of the current DSD.

Technology

My thinking at the outset of the project was that tools and technology were essential to make the game stand out. They did, but not in the way I had expected. I did several experiments; I had some in-engine editing for a while; I built a fairly sophisticated external map editor, and then a second, thinking that when I got it right, it would be a great help and reusable. I was wrong, in several ways!

First of all, I discovered that my tools didn't exactly fit the gameplay. I definitely did one thing right, which was to make the editor aware of relationships between entities(typically used as targeting between doors and switches, or groups of enemies being controlled by a single invisible "choreographer" entity). This is a feature that pays off over and over and is the #1 reason for the levels being distinctive all the way through.

But on the other hand, I spent a lot of time on making a graphics system that let you "stamp" terrain with rotation and scaling. Stamp systems worked for the earlier games, but proved to be terrible in this one for two reasons: my collision system used tiles and didn't line up exactly, and then couldn't actually exploit the full power of the stamps anyway, because the 3D models I was using had to look somewhat flat to present a clear boundary to the player, and I didn't have enough time to make lots of assets and detail levels in a way that would use the system properly. So I almost never used rotation or scaling in the project. It's funny, since I figured to myself "it worked for the earlier ones, it worked for Aquaria too, why not this?" In the future I'm planning to "regress" to tile-based backgrounds because it will let me speed up level design through procedural generation and aid in gameplay clarity - both of which are more important to me than the best-case-scenario of being able to obsessively detail every inch of the game.

I also was mistaken in thinking I would make a reusable tool. The lesson here is: if your tool is reusable, it's probably mediocre for any particular task. By engineering it to be an external thing, I just made it harder to iterate. I wanted to stick to human-readable formats because one of the issues I had seen working as a studio designer was formats that were "locked up" to be tied with the properietary tool - if the tool sucks(which, if the project has little programmer time to spare, is likely) you're SOL. But here I was doing it all, so that use case wasn't actually worth consideration. Whoops.

Another area in which technology failed me was in going off and inventing a mini-scripting language to help with the enemy choreography. It worked, but I don't have a clue as to whether it was actually useful, because I just found myself getting ultra-conservative about what I actually did with it and when it came time to write the boss code I didn't use it at all. The problem was that I didn't actually know my requirements for the language, so I couldn't add the kind of "slam-dunk" features that would actually make the designing part easier, I just stumbled around with it and kept running into bugs of my own creation due to low error-checking. If I had stuck to the native source language(haXe), where the tooling support was better, I could probably have done more in-depth customizations. The same language proved fairly useful for dialogue, fortunately, but not so much that it was worth the effort, I think.

Lastly, there were some general engine quality issues that I had to learn by "taking the blows," so to speak. I've now studied up and incorporated everything into my new engine project, Fireball. But in the meantime I had to deal with those problems for the entire project. With smaller scoped games you can "bleed less," maybe too much so, and ignore problems that would be terrifying on a bigger game - but a lot of the lessons can still be learned.

The brightest part of the technology side of things were that I did, in the end, do things I didn't think were going to happen. I didn't think I'd have lighting, but then one day I was like, "man, it wouldn't be so hard to just dump two giant bitmaps on top of each other to get the effect." So I tried it and it worked. Some refinements and optimizations later and the game looks like it does now - things like subtle procedurals are being used to provide ambient light that isn't completely flat. Similarly, I didn't have particles until the very end, and I thought, "nah, they're too hard," but I got goaded into it after several playtest sessions where it came up. It wasn't that hard. I had my particle effects done within a week and they made all the difference in making the world look lively with fish and trails and all those things going off.

Story and Gameplay

The storyline and characters presented in the game now were iterated on dozens(hundreds?) of times. I wanted something that would be intreguing and present new ideas, not just color for the action. I would sit down at a coffeeshop and write "the story," and it would always leave a lot of things out about specifically how it would work into the gameplay. And then I'd do it again another day, and again, etc. Every time, when the story hit the test of "describe a level actually using this story," it would tend to get stretched and distorted and lose the original intent. The broad ideas of the characters were figured out fairly early, but their exact relationships to each other and "reason for being," per-se, weren't. It was more than half-way through the project by the time I realized that the game worked as a post-apocalyptic tale of rediscovering the past. This let me avoid a traditional story arc of conflict and rising action, which tends to fall flat in games and become a farce: "Ha ha ha, you will not defeat me - oh, I am defeated! *shock*" By the end I had something as engaging as I could hope for, but it was a messy, tangled plotline that wasn't completely resolved. I'll clean it up in the sequel, I promise.

I also ended up doing some unexpected things with the gameplay. Again, a little over halfway through, when content development had begun in earnest, I was going to myself, "man, this gameplay just isn't good enough yet, what am I gonna do *panic*" so I dumped on the fire control features, which made it more lively, and then I added the sonar and invisible stuff, and then I added secrets, and with each addition it got a little richer and more satisfying - but the guided shot was a pain to tune and took months before my feedback was coming back all thumbs up on that. Getting mechanics right is an expensive thing. The gameplay of 1-1 turned out quite a bit differently than everything else because I was still thinking in terms of the original DSD game, but didn't succeed in making the "collect things with the drone to advance" concept tie into the rest of the story. I also found that the linear levels came out feeling claustrophobic, when I was hoping for a more free-flowing feeling.

I'll say this right now: I'm going to make the sequel way more open-ended, with upgrades and exploration aplenty, and more "AI" than "choreography." I want to make the experience bigger, and I think I can do this without ridiculously high scope or a complete upending of the current gameplay, by taking on more procedural elements and carefully developing them so that they provide a similar level of quality and more variation.

Business

I knew from the beginning that this game wasn't going to end up with a traditional Flash sponsorship deal. I got Gamersafe integrated from a very early stage and proceeded with the "sell content" angle for the remainder of the project, though I shifted the scope and price I thought I was going for several times. I still did due diligence and investigated the sponsoring angle, but I didn't go out of my way to market the game to sponsors, and eventually got antsy after two weeks of waiting and seeing no bids, which is why the game is out on the 13th and not the 15th, when I had originally thought I would go ahead with it. In the meantime, I watched the marketplace and saw Captain Forever and VVVVVV come out, I saw a sequel to Robokill come out, and I figured that if these games were succeeding, I was probably on the right track too. We'll see if I'm right.

The game has been somewhat engineered to encourage a fandom - that was a big rational to have a major storytelling component. I want to see what fans can do with the world, and hopefully incorporate that to make a stronger sequel.

It got frustrating to not have a track record as an indie to fall back on whenever I talked to people, online or at GDC or wherever. I could even sense a bit of snubbing going on at times, but I don't think this was actually so bad; all I have to do to correct that is to keep shipping stuff.

Even though I think I got enough feedback to know how I was doing, I wish I had had more of it, and I wish I had taken the effort to build in more data-collection features. When you put up a game on "random forum X" and only get the one-liner comments of "it didn't work" or "it sucked," you learn almost nothing, but if you can see what they did when they played, it reveals a whole lot more. Most of my biggest changes came from one-on-one sessions where someone played through the tutorial and broke it and started flailing and showing increasing discomfort - it wasn't what they said that mattered so much, it was the microscopic things in their play and reactions.

Assets

I really dragged on asset creation, in part because I had to learn a lot to pull off what I wanted to do. And I did learn - I developed a process using Poser as a reference for the characters, and Wings and Blender to do 3D work. I agonized over the music, which I always do with music, and am now finding ways to speed that process up. But overall, I felt overwhelmed and was forced to cut the scope and change the story around simply because assets were taking too long, with the level design taking the most time of all. It's amazing how often the dialogue was forced in a particular direction because I only did one pose for each character and thus could not depict strongly varying emotion - the clash of pictures and words looked ridiculous. (I had wanted to do lots of poses, of course.)

I also had the integration process to deal with, and while I got that down to a reasonable time length, it's something I think my technology is going to be a lot better at from here on out.

I'm going to lean a lot more on procedural methods in the future because they can cut the time spent on assets so dramatically. I also want to get more confident at the art side of things, generally - I should at least feel less "dread" about doing it.

Final Thoughts

I've made a lot of discoveries about the creative process in making this game, and I've done a lot to try to focus my lifestyle around becoming a great indie game maker.

More specifically, I developed a few rules of thumb about creative works: Maximally polished products have to be made in layers, not all at once and the more "process" you add to this, the more consistent the final work is likely to be; 10 hours of practice is sufficient to make breakthroughs in a lot of skills; using references saves a lot of time and doesn't usually impede your own thinking; everything can be iterated on, you just have to decide whether it's worth it.

I also developed lifestyle guidelines: Health(primarily sleep, stress and diet) is tremendously essential to your motivation and clear-headedness, and it is at the core of productivity. Purchases for learning and process improvement are usually worth the money, even if a particular purchase doesn't pan out. Practice time can pay off more than any monetary expenditure by expanding your "horizon of possibility." And don't be afraid to relax: it usually stimulates ideas.

Hopefully, this is just the beginning.