Prototyping for Fun And Profit

So here we are, ready to start development of our first game. We have the time, the resources, and the game idea itself. Where do we start?

Since both Charles and I are tech guys, we knew we could implement our game idea without any problem and make it sing and dance at a silky-smooth 60 fps. But would it be fun? Now that we have these brand-new designer hats, finding that always elusive fun factor is a big concern. The idea of waiting for a couple of months before we could tell if our game idea was fun seemed too risky, so we tackled that problem first and head-on by prototyping.

We could start at the bottom, write some low-level input handling, some graphics rendering, a basic asset pipeline, and all the other usual suspects. The problem is that, even if we try to keep things as simple as possible, it would still be several weeks or even months before we can actually start implementing the game itself. And even when we do, we’ll always be running up against incomplete technology and having to spend time fleshing it out as we try to make a game come out of the other end.

Instead, we decided to start with a prototype. This isn’t supposed to be a “prototype” that eventually morphs into a shipping game, or a prototype that uses the same technology as the production code, or even a prototype that’s used to impress the big-wigs to squeeze some money out of them (ha!). No, all that stuff detracts from the ultimate goal of our prototype. Our approach was very similar to what Chris Hecker and Chaim Gingold described in their GDC presentation. We had the need to answer one very specific question: “Is our game idea fun?” And we wanted the answer as quickly and cheaply as possible. Everything else was secondary.

Prototyping period

And so we dove into a prototyping frenzy. For our first day, we set up shop at the E Street Cafe. We opened up the place, took over a table, hooked up gamepads to our laptops, and hacked away furiously until late in the evening, fueled all the while by cappuccinos, gourmet tea, and pastries [1]. Yum! By the end of the day, we had the basics of the game implemented and even some of the more advanced features. Heck, we even thought it was kind of fun, but that’s because we were tired and we had been staring at Charles’ horrible programmer art all day long. In all honesty, it really was a pretty sucky game, even if the enemy characters were wearing party hats. But hey, that was just end of day one.

Over the next few days, we had to take a break to deal with all the paperwork and logistics involved with setting up the new company and the office, but we resumed prototyping as soon as possible. The plan was to keep hammering away at the prototype until we saw it was clearly fun, or we decided it was hopeless and we had better think of something new (or go back and beg for our jobs back). Charles took it even further and swore not to shave his beard until the prototype was fun, much to his fiancee’s delight (seriously, the only thing the ladies think is hotter than a game programmer is a bearded game programmer).

A week later, things weren’t looking too hot. The game hadn’t gotten much beyond what we had done the first day. Sure, we had a bunch of advanced features in, but it didn’t really make it much more fun. Were we on the wrong path?

The major breakthroughs happened in the last few days. First of all, we removed a key feature that had been there since the very beginning. We really thought it was going to be key to the whole game, but it really made the game too easy and boring. As soon as we removed it, the feel of the game changed completely and things started to look up.

Then, as we were discussing some other advanced moves and features, the idea for a minor feature came up. Since the caffeine hadn’t kicked in yet and I didn’t have the energy to work on the next big feature, I implemented our little idea in about ten minutes. Charles saw it over my shoulder and he started laughing and begging me to check in the code. It was an instant hit! We ended up liking it so much that we decided to expand on with a few features, and before the end of the day, it’s clear that it’s going to become a main gameplay mechanic in the final game. That day we went home knowing we were nearing the end of the prototype face. Good thing because Charles’ beard was starting to look scary!

One more day of tweaking the prototype and we officially called it done. We knew we had gotten there when we tweaked a small feature, fired up the game to see how it felt, and then spent 10-15 minutes going crazy with the controller because we were having too much fun. Another good sign was when we would start playing and then yell at each other to look at the crazy things we had just accomplished.

Finally, Charles was able to shave. Thank God.

The prototype

The prototype process was supposed to be as quick and cheap as possible. None of the code written was intended to be kept or extended to go into production code, and performance wasn’t an issue either. So, with that in mind, what did we use for developing our prototype?

C++ and Allegro. Yes, you read it right the first time. Let me say that again: C++ and Allegro.

With all the other choices available of higher-level languages and extensive game development libraries and frameworks, why on earth did we make that choice? Wouldn’t Python with PyGame or C# and the Game Studio Express have been better choices? The honest answer is that I don’t think either one of those options would have allowed us to get the prototype done any faster for several reasons:

• Small scope. The scope and size of the prototype was quite small, so there wasn’t much to be gained by using slightly higher-level language constructs or more complete libraries.

• Allegro. Even though it might seem like an odd choice and be behind the times, it’s precisely the old-school, fully procedural approach that makes Allegro so valuable. There are no frameworks, no enforced class hierarchies… heck, no classes or private members to get in the way. In Allegro, if you want to do something, you call the function and you’re done. Exactly what we needed for the prototype. In retrospect, SDL might have been a better choice since it would have allowed us to use a DirectX surface and do video capture more easily. But Allegro worked like a charm and we have nothing but good things to say about that experience [2].

• Proficiency. Both Charles and I are quite proficient at C++, so even if another language gave slightly faster development time, we more than made up for it by being very familiar with C++ and its libraries. For the prototype we allowed ourselves to use STL recklessly and with wanton disregard for memory access patterns and spurious allocations.  We also didn’t care about memory leaks at the end, so that helped get things up and running a lot faster.  Destructors?  Delete?  Free?  Cache coherency?  How do those equate to fun gameplay?!

It’s no secret that I’m an avid advocate of good software engineering practices for game development. As with anything, good software engineering practices have some very real and important benefits, but those benefits come with a cost. Because of the small scope of the prototype, and the fact that the code wasn’t going to survive more than a week or two, we decided to throw any software engineering practice that would slow us down in the least straight out the window!  Forget about accessors and private scoping; skip any unit tests; bye bye factories, loose coupling, and proper physical dependency management. Welcome to hackfest, check your engineering discipline at the door!

One of the things that made the prototype very successful for us was to concentrate on a single gameplay mechanic. We didn’t try to prototype the whole game, just the one bit we were most concerned about (and that was going to take 80% of the player’s time and attention). That allowed us to deal with a small subset of the game and iterate on it very quickly without getting bogged down by creeping features or dealing with a larger scope.

The prototype shamelessly used the worst programmer art imaginable (Charles + MS Paint == … you can imagine [edit: Charles] TOTALLY AWESOME SWEET). Yes, it looked horrible, but if the game was so much fun with those graphics, just imagine how it’s going to blow people away whenever we add some real art and animations.

Lessons learned

The most valuable lesson we learned was the value of constantly asking ourselves the questions “Is this fun?” and “What can I do now to make it more fun?”  That was actually really crucial. Having such a specific (even if subjective and nebulous) goal allowed us to remain in the right path. Sometimes it was tempting to add feature X or Y, but when we realized that it wouldn’t make the game any more fun, we quickly dropped it and moved to something else.

It’s important not to over-intellectualize the idea of “fun”, though. Sure, most of the fun comes from the choices the player makes and what happens as a result of those choices (even if the choice is to mash the buttons). But don’t underestimate the value of “fun” in having cool, flashy things on the screen, or to have the character jump with a nice ramp-up curve and land with some squishiness to give it that “just right” feel.

It was also very helpful to run the prototype by somebody else towards the end to make sure we weren’t finding it fun because we were simply delirious. Clearly, it has to be someone you can trust and who can understand what the prototype represents and not be put off by the stick figures. It was great to get confirmation from an outside source that it really was getting to be fun. We also got a bunch of feedback that made it a much tighter experience. A lot of it was pretty obvious, but we were too close to the game to be able to see it by ourselves.

As with most prototypes, it’s always very tempting to not throw it away and continue hammering at it until it looks like something that could be shipped. We didn’t really have a choice because of the technologies we went with (allegro is a fully cpu-based renderer), but we could feel the call of the dark side. It really was a good thing that we didn’t even try. Towards the end, the terrible hacked code we’d written was starting to slow our productivity. Code that bad builds up an “engineering debt” that you have to pay off sooner or later or you hit a wall.  Our particular wall came in the form of extending a pre-existing player action in what seemed like a trivial way.  Something like this would have literally taken about 5 minutes at the beginning of the prototype, but by the point we were at it would have taken closer to an hour. Heck, even having to go on for another week would have started to be painful. So in a way, the prototype came with a built-in self-destruct mechanism, which is a good thing because it discouraged us to continue working on it for too long.

Using existing technology is definitely the way to go. That way there’s very little “wasted” time getting up to speed. The fact that we were able to get most of the core mechanics of the game in the first day goes to show how useful is to hit the ground running instead of getting bogged down in how to load bitmaps or create a window.

Additionally, the procedural, non “framework-y”, non-object oriented approach of the API we chose made it much easier to bend to our will and make it work the way *we* wanted, and not the way somebody decided for us ahead of time. The fewer restrictions your prototyping API has, the easier it will be to do all the crazy things that come to mind during the prototyping phase.

The game

Unfortunately, we can’t really talk about the game right now. Just rest assured that we’re working on it at full steam and we’ll announce some details as soon as we can. Clearly, we’re not going to release the prototype since it has a good chance of scaring away any potential publishers in its current state. But if one day the game sells tons of units, maybe we’ll release the prototype as a “behind the scenes” feature so other people can have a glimpse at how things got started and they can laugh at our artistic skills.

Conclusion

There you have it. Now at least we can be confident that the game is going to be pretty fun. Sure, there are lots of aspects of the game that we haven’t prototyped, but we consider those to be lower risk and we’ll figure them as we go along. At least the core mechanic has proven to be fun. Now it’s just a matter of writing the production code and implementing it all. That simple. What could possibly go wrong? 😉

[1] Money saving tip #1 for starving startups: If you have to pay for a 24-hour Internet connection in a coffee shop and you need to have several computers with Internet access, connect them with an ethernet cable and share the Internet connection from one of them. Ta-dah! 🙂

[2] Actually, I’ve been wanting to create a movie of the prototype in action, but I haven’t been able to. It seems that Fraps doesn’t work because it’s not using a DirectX surface, and saving each frame is too slow. Anybody has any suggestions? Don’t get your hopes up though, we’re not uploading a movie of the prototype any time soon, we’re just saving it to show our grandchildren one day.