Sunday, August 21, 2005

Common Game Prototyping Pitfalls

I’ve spent some time in previous posts describing the benefits and process of game prototyping. You’ll create more innovative game mechanics, weed out bad concepts early, and help ensure that your final product is highly addictive. As with any good technique, there are several notable pitfalls and drawbacks to prototyping that a savvy practitioner should be mindful of.

How can you prototype successfully when…
  • Your programmer tells you that he needs 8 months to implement the cool DX 9 engine you need and another 4 months to build out the game’s architecture. Only then can he start the prototype.
  • People keep getting pulled off the prototype to work on other high priority projects
  • Your prototypes end up being stupid mini-games that no one cares about
  • You create games that are fun for you to play, but everyone else seems to hate them.
  • Your idea for the next greatest FPS MMOG Adventure game seems far too big to prototype.
Read on to find out how solve these common prototyping dilemmas.

The need for fundamental engine systems
Of all the pitfalls, the need for infrastructure is the most difficult to overcome. Most games need substantial game engine system in place before they can be prototyped. The list ranges from graphics engines to networking support. It is nearly impossible to prototype a game like Doom if you don’t have a 3D engine. It is also difficult to prototype an online game when your engine had not networking support.

In the worst case situations, you’ll need to build these items before you can begin exploring your game mechanics. This is costly, time consuming and gets in the way of the real task at hand: rapidly exploring a series of game mechanics. In many cases, I’ve seen momentum for the project completely extinguished. In others, the spirit of prototyping is lost. There ends up being so much effort invested in the infrastructure necessary to support a particular game idea that it becomes politically unreasonable to radically transform (or even kill) the concept.

Solution - Use an existing engine: My recommendation is to use off the shelf or preexisting engines that have most major systems in place. Ideally, you can work at a higher level by manipulating pre-existing blocks of functionality and focus on roughing out the game mechanics. I’ve seen great success with multimedia tools like Flash (2D) and Anark (3D). Those with a bit more of a programming background can do amazing things with Torque or other off the shelf engines.

When selecting an engine for prototyping, be sure that it is more than just a rendering engine. Having preexisting systems for handling simple physics, collision detection, player movement, path finding, and input device support can make your life much easier.

The misplaced urge to create sound architecture
The spirit of prototyping is one that is best suited to off the cuff hackers and geniuses. In mere hours, the prototype needs to be playable such that the feedback cycle can begin. Hackers, though deadly in the long run, will cobble a prototype together by hook or by crook. The code will stink, but it will work. Geniuses will get the prototyping up and running just as quickly, but they’ll have enough experience to give themselves room in the code to build a competent architecture.

There is a third group that believes deeply in good architecture above all else. This group will spend 3 weeks creating the most beautiful data structures the world has ever seen. “If we don’t *insert engineering speak here*, we will be screwed.” To which, I reply “Bullshit.”

Unless you are talking about engine systems, most prototypes do not need to be overly robust architectures to test the basic game play. In fact, it can be quite damaging.

Consider the downside of perfectionism at the prototyping stage. In the prototype The Secret Lives of Aliens I had proposed a core game mechanic based on a conversation simulation. Building that out is a good chunk of work. Instead, we went with the stupidest mechanic possible and within a couple of hours discovered that the entire system was simply not fun from a game play perspective. If we had spent the time to build a robust conversation system, the project would have been delayed by weeks and major momentum would be lost.

Solution – Set strict time limits on architectural work: The goal is to create a prototype that can be critiqued, trashed and thrown away. The goal is not to create a finished product. There is a time and a place for spending copious time on your architecture and the prototyping phase is not it. Depending on the personality of your team, this can be your biggest project management challenges.

Importance of project momentum
I’m going to harp on the importance of project momentum when it comes to prototyping. Very few prototypes have any sort of official buy off and are generally seen as throw away activities. Prototypes are one small step removed from game design ideas and everyone knows that game design ideas aren’t worth a hoot in this industry. Everyone has a dozen in their pocket and 99.99% will never turn into anything. In the grand pecking order, prototypes are almost always projects of low individual value.

If a prototype is not showing results, team members will begin to focus on other ideas or project management will move team members to higher priority activities. There is almost always something higher priority than a prototype that isn’t going anywhere.

A prototype becomes something more valuable when it is an enjoyable mini-game that shows great promise. At this point, people begin to get excited about the project. They’ll put in the extra time if needed and it becomes more difficult for the project to have its resources taken away. A project with momentum can go through a dozen iterations in a short period of time. A project without this momentum might hit two or three iterations in the same amount of time. Both projects can have killer game design ideas at their core, but poor execution of the prototyping phase will kill off the low momentum project before it even has a chance.

Solution – Prototype early and prototype often: Focus on early results and do everything you can to keep the momentum going. Promote your early successes and outline the immediate short term steps you are taking towards success.

A roadmap with clearly defined, visible chunks of meaningful functionality can be a great help in organizing your work effort. By making each chunk of work small enough to easily build, you ensure that there is always a constant stream of interesting results coming from the prototyping project. Avoid long gaps between prototypes at all cost.

Locking in mechanics too early and reducing the scope of the game.
When you get the first prototype up and running, there is an urge to immediately perfect the game play in all ways. Common critiques tend to be very detail oriented:
  • Is the text readable?
  • Does clicking on the character have a satisfying feel?
  • Is the timing on the respawn too fast?
All sorts of little details that make your prototype an awkward player experience shout for attention and you really want to polish the heck out of the prototype immediately.

If you create your list of ‘Things that suck” and then fix all these little details, you’ll end up with a short, trivial mini-game that isn’t really all that fun to play. You’ve locked in the game play too early.

Solution – Focus on the design on the big picture: A better tactic is to look at the game from the standpoint of its future potential.
  • Can the player make meaningful decisions?
  • Is the player getting the feedback they require to make good decisions?
  • Are the major risk / reward schedules in place?
  • What is the pacing of the experience?
  • Is there enough meat here to hang the rest of the game on?
These higher level questions will reveal fundamental problems with your game play and point to additional systems that must be added. Often by thinking big and then paring the design down to its core elements, you’ll end up with a prototype that has the foundation for some major game play elements.

Getting feedback from the wrong users
Game developers are sometimes the worst testers. They are expert gamers with intimate knowledge of the system. Their natural bias is to make game play more difficult and less intuitive.

Let me tell you a classic tale of a title called Galapagos. It was roughly an ‘action puzzle’ game that involved manipulating the 3D environment such that a little creature could find his way through to the level exit. Watching a developer play the game was a delightful experience. The camera would swoop dramatically around your little character with Star Wars-like platforms zooming about, arriving at their location at the very last second. It looked fun!

As a first time player, Galapagos was easily one of the most frustrating games I have ever played in my entire life. The camera angles were nearly unmanageable. The little creature never went where you wanted him to go and you had no idea how you were supposed to manipulate the environment. The only way to beat the game was super natural reflexes and lots and lots of trial and error.

The major feedback on each round of prototypes came from the same people who had played early prototypes. As the game grew, so did the skill level of the people testing the title. The end result was game that was enjoyable for expert Galapagos players, but not by the general public.

Solution – Gather new user feedback: The way around this is to use lots of ‘Kleenex Testers’ to balance the useful testing done by the development team. These are ‘throw away’ testers that try the game for the first time and then are never used again. Setting up such a system ensures that you are constantly having your expert opinion challenged by a fresh, unpolluted crop of new users.

Content heavy games
Prototypes tend to be algorithmic in nature. There isn’t a lot of animation, the graphics are primitive and even level design is unlikely. Most modern games can be prototyped despite these inherent limitations. Some cannot.

Content heavy games like RPG’s, Adventure games, some MMOGs and heavily scripted FPSs are difficult to prototype. The problem here is that these titles are actually highly evolved versions of a core game mechanic.

A RPG or MMOG is generally a single or multiplayer turn-based combat system with a whole bunch of content and meta-game systems layered on top. You can prototype the combat system, but the game’s competitive advantage is often “everything else.”

Adventure games are really just a series of puzzle oriented mini-games tied together with a bunch of story. Again, you can prototype the mini-games, but the reason people play is to experience the story-based rewards. The same basic concept applies to modern single player FPSs.

Solution – Know when to prototype and when to start production: Prototyping still has a place in established, content heavy genres. I suspect the various weapons in Half Life 2 were heavily prototyped before they made it into the game. I’ll bet money that Blizzard spent ages testing the WoW combat system at very early stages in the project’s development. However, ultimately 99% of the work that will go into such games will be custom crafted content. When the conversation turns to custom content, it is time for the prototyping phase to hand over the reigns to the production team.

Prototypes can’t do everything. However, done correctly they can provide a strong foundation to build the rest of the game upon.

Conclusion
Prototyping is a high value development activity. By paying attention to the common execution pitfalls you can increase its effectiveness.

One last pitfall is worth mentioning. It is almost too obvious to talk about, but is important for artist / designers like myself. Prototypes are algorithmic creations. In general, you need some programming skills to create a prototype. Better programming skills make a wider palette of game mechanics available to your prototype in a shorter period of time. But the trick is to at least have some programming skills.

I have a friend named Charles who makes award winning casual games. He is a great artist, but only has moderate scripting skills. Due to his current scripting abilities, it is unlikely that he will ever create the next great MMOG on his own. However, even the basic level of scripting that he has mastered allows him to create wonderful platformers, shooters and racing games. The inspiration I take from Charles is that as long as you have a great knowledge of game design, entry level programming and art skills are all you need to produce great games.

The flip side of this is that a game designer without access to programming talent is at best a windbag (a label I happily accept :-). A song writer alone makes a poor band and the same is true for a game design. If you can’t program, you need to hook up with someone who can. Of course, the opposite is also true. If you are a programmer that can’t design, you need to hook up with someone who can.

I’m personally (and no doubt for selfish reasons) a fan of a small prototyping teams that include 2 to 3 people. Being able to bounce ideas off of one another results in a better final project. There is less tunnel vision and the team is more likely to notice the obvious solutions.

So the minimum prototyping team includes some dash of game design talent and another dash of programming talent. With that mix, the sky is the limit. You can build an enjoyable prototype, get enough momentum to recruit an artist, build some initial levels and start to wow people who matter (be they early customers, producers, etc.). Sweet.

Take care
Danc.

5 comments:

  1. What do you mean by 'hacker' in this context? One who can produce running code that is poorly planned for the long run?

    If so, I don't think that that is the meaning that most programmers think of when they hear it, let alone what the general public thinks.

    ReplyDelete
  2. Hacker as in "programmer who just hacks stuff together quickly" makes sense. Excellent article by the way (as are the other ones I've read so far). I came here from Penny Arcade but I think I'll be hanging around for some intersting game design conversations :-)

    ReplyDelete
  3. Ya i wouldn't go around using hacker, as people use it instead of (cracker, who cracks computers) and it can give the wrong idea. Great post though, i'll certainly think about prototyping differently now.

    ReplyDelete
  4. In software engineering "hacking" is the term used for the style of programming where a coder puts together code with a short-term mentality (i.g "What will make this work right now?) or as Peter put it: "One who can produce running code that is poorly planned for the long run."

    So yeah, anyway, though the term "hacker" has a negative connotation associated with breaking computer systems in the general populace, it is the technically correct term for the style of programming Dan is talking about in this article.

    ReplyDelete
  5. An excellent article, congratulations!

    A hint for you fellows, I'm having some success using Virtools as prototyping tool, it have been bringing the better from both worlds; I can using drag and drop system to fast prototyping and behaviors and when its necessary, I can be programing some C++ hardcode to create some brand new very specific feature. You can be using Flash and other tools as well, but technically speaking, Virtools is nearest from real game development boundaries.

    ReplyDelete