By Rich "Beaker" Wyckoff
I've been designing games professionally for three years and thinking about designing them for most of my life (when not playing them). I tend to present strong opinions, but I want to make it clear that these are only opinions, and I don't want to come off like some of the famous names in the industry who seem to think that selling a lot of copies of a game and getting attention from the press makes them an expert on everything about making games. My tenet is that if you claim to know everything, you're missing out on the fact that there's always something new to learn, some other opinion which is worth considering, some experience you are still lacking...
ou may have noticed that the Bent's more than a little late this week – things have been pretty busy in work-land. So as I cast around trying to find a topic which would inspire my overtired brain enough to pump out a column, it suddenly became obvious: write about what I'm doing.
My project remains top secret and unannounced, but luckily what I want to discuss doesn't pertain to specific details but a more general issue of development. The exact topic is something I have been preaching since I entered the industry but have never had a chance to actually put into practice until my current job at Knowledge Adventure: the early implementation, testing, and reworking of gameplay ideas.
When I first started making computer games, I ended up working on two projects in a row which were already in their final months when I joined. On both theses games, I noticed immediately games that there were entire sections of gameplay or interface or graphics technology which just felt "wrong," and I wondered why these games were going to ship with such seemingly wrong elements.
As a new designer, I wasn't really in a position where I could do anything about these problems. I subdued my opinions partly because I hadn't yet learned to trust my game development instincts and mostly because I assumed that steps had been taken to correct the problems I thought I saw.
Now that I am a little more seasoned, I have come to realize that producing great gameplay really does come down to instinct and gut feelings. This column often represents my attempt to try to define some rules of game design, but the real truth is that there will never be a manual that a person who has never designed games before can just pick up and read to become a great designer, nor are there a set of rules that an experienced designer can follow which will always guarantee the production of a great game.
I'm reading a very interesting book on design (Bringing Design to Software, ed. Terry Winograd) which perhaps will feature more prominently in a future Bent. One of the common threads in the different essays in this book is the idea that design is a conversation – in other words, an ongoing process of revision and experimentation as opposed to an engineering task of using set rules to solve a quantifiable problem.
This confirms what I've always felt about game design – that it is not something that can be predetermined and then followed, but rather a course which is embarked upon but which requires constant steering and attention and possibly even complete changes of direction as development proceeds. This, then, brings me back to what I felt when I first was working on games which were near the end of their development cycle, yet obviously felt wrong.
|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.|