Just pushed out another update in response to feedback you guys gave!

My strategy was to get a prototype out very quickly (within the first couple weeks, but with all dummy art and all but the most basic features missing) to make sure the core drawing mechanic worked in practice. I then showed this off to help raise interest and attract other people to help me with the project. At that point I drafted a plan of what I reasonably thought my team and I could do in a relatively short timeframe (no absurd features like 100's of levels or a massively advanced engine). I think, especially for your first real game, targeting a short timeframe (e.g. a few months) is a good way to limit yourself and not tempt yourself to go too broad. The next step was to get a great first level up and running as quickly as possible, ignoring the later parts of the game. This way we could get early feedback from others while also making sure that we had a lot of time to iterate on the beginning of the game. Then we worked on the later part of the game, which worked well because at that point we knew the tools and felt comfortable enough to break the mold a little more. When I recognized we were falling behind I added an additional team member to help with the art, and I also started to help out with the pieces of art I could do (although originally I was only supposed to write code). I also decided it was better to put less time and resources into the penultimate section in favor of really focusing on making a great and memorable finale. I hate the fact that so many games have a great start but a poor ending, so I spent quite a lot of time on the finale to make sure it was satisfying.

To elaborate on pitfalls associated with game development, I've worked on several other game projects (led by others) that have failed. Not to say Robokiller is perfect, but I personally am very proud of it, and we got a complete, playable, fun game, which is not the case on these projects. Some major reasons I see projects fail are:
* Caring too much about elegant code (ooh, you have a really nice component-based architecture and your code is beautifully organized, now we have no time to actually make a game or playtest it).
* Focusing primarily on something that you think is really cool but most players won't even care about, at least when they first try your game (great, you have the world's most complex crafting system, but without graphics, sounds, or core gameplay, it's irrelevant).
* Making changes to the code that impact other team members without consulting them. I remember on one project I had put countless hours into scripting a really cool intro for a game, when suddenly the project leader changed the whole codebase from floats to doubles without notifying me, and now nothing in my script worked as it should. I has to spend lots of time redoing it but couldn't get through the whole thing, and I believe the game was eventually released with a broken intro because of this. Worse, I had no time to work on the other parts of the game since I had to spend my time redoing this.
* Making the core gameplay mechanic something that's really hard to implement (often some sort of crazy advanced physics-y thing) and launching into full-scale development before having a fully working prototype of that mechanic. What typically happens here is that the creators never really get it to work right and end up with a mediocre game that's playable but isn't very fun and has nothing really unique.
* Losing interest in the project near the end, being too quick to call it "good enough" and not being willing to take the time and effort to fully polish it. Even if the rest of the team has moved on, become too busy, or lost interest it's really up to the project leader to take the initiative to bring the project to completion. This is one case where perfectionism can be helpful: A good project leader will keep striving to make a game better and better simply because they love it.
* Not making a game you yourself would love to play. It seems obvious but many get this wrong. When making indie games, the cool part is that you have the freedom to make games you think are really fun, even if they don't appeal to many others. This is the opposite of most big-budget AAA games which are designed to appeal to as many people as possible. In order to devote enough time and effort into making a game great you need a burning passion for it, it's not enough just to think it's a "cool idea". And at the end of the day you know you will have succeeded in making a game that at least one person loves, everything else is just icing on the cake. :-)

It falls into the tracker category. Specifically, the XM format. The FMOD sound system is used for many popular commercial games.

Multi-directional sprites would be less confusing, and would allow you to do things like sneak up behind an enemy, but require a LOT of additional art for only a small benefit. In Robokiller, at least every sprite is consistently one-directional. In Wolf3D, Doom etc. sprites were multi-directional when enemies were live and one-directional when they died. I can definitely see how this could be confusing.

It's hard to get away from some element of mazeiness when limited to a Wolf3d-like engine. Once the engine gets to the level of Doom it's easier to avoid this.