- Lack of time dedication

Unfortunate, but justified due to cost-of-living expenses here in NYC
forcing developers to get 'real' jobs

- No money incoming at early stages

Could have gotten some funding, but would have been difficult for a
pet project from two guys without prior published games. Self funding was
really the only way.

- Development took too long

- Used own code when open source code would have worked

- No real schedule

- Wrote a lot more code than was expected from the start. I could
possibly have written more code than was necessary to get the thing running.

- I took an engine-oriented approach, intending to reuse it for other
games or sell it on its own. In retrospect, a lot of the framework was
tested and good code, but game logic code also needs attention. And is a
HUGE part of the project.

- Lack of game dev project completion from me. I haven't taken a
game to completion, so I tend to find solace in repeating things I've done
before, but polishing them up. There was a lot of code for game logic,
menus, enemies, etc., which I ignored because it felt like a big task. One
which I was unfamiliar with.

- Played with bulletML for a too long? Was it too early to worry
about this? BulletML was complicated and I could have used simple bullet
code first, and then expanded the bullet arrays later on. Plus, BulletML was
poorly documented and didn't gain us much. There were existing bullet
patters, but would we have used them? The ML was too complex for us to learn
and try to create ourselves.

- Took too long to recover context to make code progress after
spending week(s) away from the code.

- Too much refactoring. Refactoring is good, but there's time to do
it after delivery of completed application. There was no good reason for me
to go back and polish the engine before game completion. I need to work on
'black-boxing' the code and forgetting about underlying framework classes
when writing game logic code.

- Too feature-ful code in the framework. Changing resolutions on the
fly is good, but who gives a shit? XBLA probably has only one resolution.

- Lack of artwork expertise

- 3rd person on the project could have helped

- Artwork didn't need to be optimized from the start. Could have
been individual files of whatever size which the engine was capable of
handling

- Too much focus on tweaking one or two images to get the right look
of game art. Transparency and such could have come later on.

- Should have worked on getting the artwork workflow for the artist
down so art can easily come out as usable in the game. We decided on TGA
which gave us freedom for transparency, but it was difficult to export to.
We could have used BMP with color keys from the start (I even coded this!)
and cleaned things up later.

- Poor communication of game design

- Documentation needed to be much better. About half-way through I
started to use word docs to roughly decide tasks needing completion. Some
sketches and mockups existed, but a true requirements document spelling out
all necessary details was needed. Maybe.

- Other projects manage to wing it and get a completed game out.
This may be a problem with my technology-oriented focus. I have a hard time
visualizing the end goal and seeing past the code.

- Some milestones with expected feature completion would have been
useful. I had a rough milestone document, but it had CODE completion. There
were many required bits of code which I didn't anticipate from the start,
making it seem like later milestones were far out of reach. I should have
had end user features listed in the milestones, functionality.

- Lost interest (~9 months from meetup to project abandonment)

- Project lifetime of 3-6 months is more realistic for a small game
like this.

- Better requirements and milestone documents (see above comments)
would have helped to visualize the completion of the project, rather than
just feeling like there was always tons of work left to do.

I'm not a gamer!

I code games because I enjoy the challenge, not because I am an avid
game player. I need to pick an application I care about, not code I care
about. Good code can be written in any context.

Unit tests

Doing unit tests on the framework classes helped to be certain that
things were working as intended. Even when refactoring later in the project
I found some bugs in code which had long since been left alone.

Engine code