By Rich "Beaker" Wyckoff
Our game has gone through two kid tests already. Between those tests, we have reworked such things as our keyboard controls, on-screen interface, and the approach we use to building levels. Even if at first it seems frustrating to have to rework elements which we have already spent countless hours designing and implementing, every change we have made has improved that almost indefinable "feel" that will make the difference between a game and a good game. We are doing this early enough in the project (our ship date is a long, long way off) that we can afford to make large changes without feeling that we will miss our ship date or compromise a large bulk of existing work which was based on the old system.
What we are doing can basically be defined as prototyping – every successive revision we make on our systems and data is closer to something we consider final, and the desire on entering each test is that if it passes the test, we will keep it, or at least use the approach we used for the prototype to make the real data. The difference between what we have been doing and what I have seen on other games I have participated in is that we have put functionality and gameplay ahead of graphics and all other glitzy touches.
In my time in the industry, I have seen project teams produce demo after demo which focuses on the look and other graphical features, saying to themselves "we'll get the gameplay in later." Beyond just certain disastrous dinosaur games, even well-run projects with the best of intentions have followed this plan. I never understood then how anyone could put gameplay after any other feature. How can you expect to produce tons of art and levels before you even know if your game is fun? Perhaps some of this is the mistaken impression that fun can be pictured and written down ahead of time, and that whenever the programmers get around to writing the code which supports that gameplay that it will just spring into being, polished and perfectly formed.
I am here to say now that this does not work. It was the lack of early gameplay implementation and testing which doomed aforementioned dinosaur game, and it was the lack of early implementation and testing which kept the games of my first employer from being polished enough to attract any more than the limited and tolerant hardcore audience.
The question which remains is that when creating with new technology, how do you manage to implement and test early enough? I do not have an answer to this question yet, because in my experience I only have new technology projects which delayed or ignored testing and thus shipped less-than-perfect gameplay and my current existing technology project which is making a point of testing early. All I can say for now is that the number one priority of any project, new technology or not, should be to create great gameplay, and if any other part of the implementation is being prioritized ahead of this, it is a mistake.
There is even more to making a truly great game than gameplay testing. As I pointed out in the beginning of the article there can be many parts of a game which can just feel wrong. Again, testing is the key here – no matter how juicy a feature sounds in the initial design spec, if it turns out to be slow, or ugly, or too hard to utilize, it should be revised or replaced. These decisions almost never get made if the feature is never seen beyond the engineer who wrote it and the designers who are trying to use it. However, a test with some groups which resembles the target audience can provide a big enough stick to shake a team out of its complacency and into action.
To conclude, let me repeat this column's title: test early, test often. To be fair, there is such a thing as over-testing, or following a test group's feedback too blindly, but it would double the size of this column to explain how to best handle tests. I can only say that it is a mistake to not test at all, and now that I am finally involved with early testing myself, I can see how it has improved my design work more dramatically and more quickly than I ever could have on my own.
Rich Wyckoff is a professional game designer.
|Credits: Beaker's Bent logo illustrated by and is © 1999 Dan Zalkus. Beaker's Bent is © 1999 Rich Wyckoff. All other content is © 1998 loonyboi productions. Unauthorized reproduction is strictly prohibited, so don't do it. We have ways of making you talk.|