Word Invaders Flash Game Post-mortem
Recently, I read Panayoti Haritatos’ post-mortem for Robot Riot and decided to write my own for Word Invaders. In it, I discuss what went right, what went wrong and the lessons learned along the way. Stepping away from the project and then coming back to do this post-mortem certainly gives me a fresh perspective and makes me anxious to start applying some of those lessons. I hope you enjoy reading it. I definitely enjoyed writing it…it gave me a break from working on my Silverlight Out Of Browser tutorial…, which is turning out to be another long one.
What went wrong
Making my first game a typing game
Let’s face it, even the best typing game ever made (which some consider this to be), would have a hard time knocking World of Warcraft or The Sims off the best-seller list. Now, I had my reasons for making a typing game, which I will discuss later, but only when I released my game to the general public did I realize just how FEW people enjoyed a typing game. Of course, the flaws in my implementation didn’t help either.
Despite being prepared for a lukewarm reception, I still got a bit depressed. I think creating a game with broader appeal would have helped keep up my momentum and morale.
“Retro” graphics
I based this game off of an old text-mode typing game I played on my IBM XT PC called Typing Tutor IV (I found a link to the Apple II version of Typing Tutor IV). I love text mode games, but I definitely wanted to update the graphics for my first Flash game. After looking around he web for inspiration, I came back very disappointed. Many people just slapped in some crappy graphics, added some brightly colored dropping text and called it a modern typing game. Lacking any graphic design ability, I knew if I tried to do the same thing it would look even worse. Thus, I decided to make my game look like an 8-bit Atari game. That way, I could at least say myself it looked terrible by design.
However, with all the visually appealing games on Newgrounds and Kongregate, in order to compete visually and catch a potential player’s eye, I don’t think an 8-bit look will cut it.
Breaking the YAGNI rule
You Aren’t Going to Need It…and boy, I sure didn’t. In the my most egregious breaking of this rule, I, shamefully, slipped into the trap of ALWAYS programming to an interface. For EVERY single class.
Yep. Every last one.
Now from a purity standpoint, I don’t mind this at all. But, when dealing with a short deadline (I allocated three weeks for development), and a still maturing IDE (no offense to the FlashDevelop guys. FlashDevelop ROCKS!), it added unnecessary complexity and slowed me down. To be sure, the extra level of indirection did come in handy, however I should have taken a step back to find the points where adding the abstraction would pay off the most and only applied it in those places.
Non-existent unit testing
Man,…it hurts just writing that subtitle. Some developers swear by TDD. I’m not one of them. Still, I should know better than to leave test framework setup until the end of the project. For me, that pretty much guarantees a testing framework will NOT get setup. Sure, I skated by for a while by throwing in a few “trace” statements, but the game shipped with one bug that I know I would have caught had I put a proper testing framework in place.
Poor Level balancing. Overly ambitious reward goals
A few players complained the game got too hard too fast. I could have easily spent another week on tweaking level balancing, but simply ran out of time. I will definitely fix this for the next release. Others complained that I set the goals for bonuses (reaching level 50 or scoring 10000 points) unrealistically high for this type of game. I admit, scoring 10000 points will take you a WHILE, so I should definitely look at scaling these goals back. Also, if I made the game a little more engaging, perhaps people wouldn’t find sitting in front of it such a chore.
What went right
Making my first game a typing game
I actually didn’t set out to make Word Invaders. I started by making a clone of Crack Attack (great game, by the way). After completing 50% of it, I realized I would go WAY over my time budget to finish it. So, I down shifted (WAY down) into Word Invaders. As turns out, my level of interest and passion increased quite a bit once I started working on Word Invaders. I had alot of love for the game as a kid and that helped fuel my drive (especially during those all-nighters
). I believe that fact, combined with the almost non-existent graphic asset requirements,
allowed me to ship what I consider a finished game. And for my first time, I think actually shipping is very important.
Using “enterprise” design patterns
Although I spend plenty of time developing game prototypes as a hobby, I’ve spent most of my career in a cubicle developing Windows desktop and web-based applications. This has exposed me to the alphabet soup of enterprise application programming methodologies: MVC, DDD, BDD, TDD, SOA, etc. Despite the sometimes confusing cacophony of overlapping techniques, I firmly believe that developers should apply them even in the realm of video games. As a matter of fact, when Robo Riot’s post-mortem mentioned separating game play logic from game presentation logic, this resonated with me quite a bit and helped inspire me to write this article. Being a Java web developer, I’ve sailed the vasts seas of web framework code created to solve, with varying degrees of of success, the very problem of business and display code separation. I know it well, and I believe I got this particular implementation detail right. Also, following Domain Driven Design principles allowed me to effortlessly switch from making Crack Attack (as I mentioned above) to making Word Invaders. I simply removed my Crack Attack “domain” classes and started writing new Word Invaders specific classes with zero code surgery necessary. Eventually, I’d like to modularize my code even further to factor out the game engine entirely, and then on a per-game basis, integrate domain specific classes using a declarative attribute/aspect like mechanism.
Using Flash
I attempted to make Word Invaders a few times in the past as a native Windows game. This would inevitably lead me to get bogged down in some C++ or DirectX minutiae and never complete a truly polished game. Conversely, the Flash platform made it almost too easy to get a prototype up and running. Despite a few oddities, I especially appreciated Flash’s text manipulation abilities, because manipulating text in DirectX 9 gave me all sorts of headaches. Flash abstracts away all the annoying platform stuff and allows me to dig right into the meat of writing a game. Since I don’t make the type of games that would require to-the-metal access of system resources anyway, I will definitely stick with Flash as my game platform of choice for a while. And, I will certainly consider a Silverlight or JavaFX port in the future.
Tracking my hacks
About five years ago, whenever I worked on a project, I also wrote down all the hacks, future feature ideas and vague promises to “do it right next time” in a separate place outside of code comments. So, even after getting away from the project for a little while, I had an easily reference-able “todo list”, allowing me to pick up right where I left off. Looking over my notes now makes me confident that from a game play and architecture standpoint, Word Invaders 2.0 will totally eclipse version 1.
Conclusion
Even after thinking through everything that went wrong, I still take pride in shipping my first Flash game. Not only did I learn (and sometimes re-learn) plenty of programming lessons, but I also learned much about licensing and distributing Flash games. I look forward to shipping my next one.
Software and Hardware Used
Workstation: A 2GB, 1.83 GHz Core Duo MacBook
Compiler: FlashDevelop ( running under VMWare Fusion. Not as slow as you’d think
)
Assets: Game sound effects obtained from soundrangers.com
Related Posts:
Comments
3 Responses to “Word Invaders Flash Game Post-mortem”




[…] the original post here: Word Invaders Flash Game Pos… Share and […]
Thank you for the info! You just saved my first (soon to be released) game with your “level balancing” information.
You’re welcome!
I definitely learned my lesson and will do better next time.