The Lost Art of Prototyping

Even after years working in the Software Industry, I'm still amazed by how little emphasis companies put on building prototypes for their applications.

A prototype is a very basic version of an application, with limited functionality that still represents, in a very primitive way, the overall functionality of the final product. It doesn't have any fancy graphics or sound. There is a big difference between a prototype and an alpha release. An alpha may take months (or even years!) of development to attain, and is built on what will eventually be the final codebase. Art and other resources in the alpha are also nearly final. A prototype, on the other hand, is very limited in scope. In many cases it might not even run on the same platform that the final product will run in. It could feature stick figures, or recycled code from other products. Maybe it's a couple of static html pages, or maybe it's a text only console app.

Instead of creating prototypes, it seems that companies place an undo emphasis on the Design Documents. True, Design Documents are great way to express the overall vision of a product -- the Big Picture. However, there are at least two serious limitations of Design Docs:
1. The document will be out of date within 3 months. Guaranteed. And in many cases Producers don't have enough time (or don't care to) keep them updated.
2. The process of generating a design document does not effectively flush out obstacles and unexpected challenges to development.

I think the reason Design Documents are so central to most companies' processes is that they are something very much within the capabilities of a Producer alone. A prototype, on the other hand, can (usually) only be created collectively by a producer and a programmer. Many times the programmer is too busy fixing bugs in their past releases, so there just isn't any time to dedicate to a prototype. Though, in the long run, a prototype could make the final release less buggy, it simply isn't seen as a priority during the pre-production stage. It is a vicious cycle.

Prototype code will usually not make it into final product, but it is proof that the ideas behind the product are sound. It should only takes a few weeks, or maybe a few days, for one person to develop a reasonable prototype most products.

Gooeeno Diary

Yesterday I released the Beta 3 Version of Gooeeno. There's still a few odds and ends to clean up, and of course I want to see what the reaction is as far as difficulty and balance, but basically the game is done. Now is a good time for me to put down some thoughts about what my vision was for the game, where I succeeded or failed, and what I learned from the experience.

I started working on this game about 6 months ago, and originally it was just an expirement in Flash. My goal was to create a simple game engine in Flash that would support an side-scrolling platform game (a la Sonic, Mario, etc.). Despite this being an "old school" game, I hoped to make it fun enough and original enough that it would still appeal to gamers that are used to the high-tech 3D games that are prevelant today.

As it is, building this kind of game in Flash is a mammoth challenge. If you look at Flash Game sites, you will find hardly any background scrolling games of this sort. The main reason for this is speed. Despite all the great things about Flash, it's pretty darn slow when it comes to rendering graphics. First, it doesn't take advantage of graphics hardware. Moreover, it is a "virtual machine" technology -- meaning the SWF is interpreted by the Flash Player program, which is a whole layer between the swf and the operating system. In short, there's a lot of performance overhead.
For more about building scrolling arcade games in Flash, see this site: http://outsideofsociety.idz.net/ It gives one a sense of what a challenging problem it is. Of course the fact that this has not been done successfully in the past was part of the challenge!

Here are some of my other original goals:
* Create a game with unique, appealing characters and some semblance of a story.
* Create an engine flexible enough to allow for a variety of levels and environments.
* The level-creation process should be easy and quick. A simple level should only take a couple of hours to lay out. Ideally, the level could be laid out in Flash itself from a collection of building blocks. Thus, there would be no need to develop a seperate level creation tool.
* The overall file size should be small. * Sound effects -- this is my first game with some sound effects!
* Reuse existing code from previous games.

In another entry, I will discuss some of the failures and limitations of the game, but at least I can say that, after months of work, I was successful in achieving these goals. I consider Gooeeno my "magnum opus" in Flash; from here I will probably try to move on to mastering other technologies, like DirectX. It's difficult imagining a single Flash Game that's more complex than this.

...until Gooeeno 2, that is. :)