Tuesday, June 18, 2013

Moving Into Game Design

Some days I want to turn this engine into a kind of "game construction set", sort of like the "Pinball Construction set" from the eighties. (Speaking of the Pinball Construction Set, Bill Budge recently released the Atari source code for the product here in case you are interested.)

The problem with doing that, however, is that I would probably need to make it as simplified on the front end as possible, and maybe even make it so that it would not require any coding on the part of the end user...except for some basic scripting. I do have a couple of tools that have grown up together with the engine...namely a particle system designer and a gameboard/terrain map/terrain feature designer that has been prone at times to excessive feature creep. Yet I don't know how popular such an idea would be considering there are already such systems out there, for better or for worse.

Instead, I have focused on putting such flexibility into the engine framework/API itself. Here, too, there has been a bit of feature creep and experimentation, but the end results have been useful. As this phase has wound down it becomes more of a process of making things run faster, more efficiently, or trying to cram more functionality into existing methods. Even that, too, has its limitations, which is why I'm now working on creating actual games rather than refining the tools used to build them.

Should I build a new MMORPG? What about something with incredibly realistic graphics or state of the art sound? What if I build something with gigantic terrains that would take a player weeks to explore? That's probably the wrong approach, if anything. Unless you have a huge team of developers, artists, and sound designers working together...taking on such a task would increase the risk of project abandonment.

So instead I'm starting small, perhaps with basic puzzle or action games with a sort of '80s theme to them. Although I made prior posts about a 3-D marble puzzle game, I may put that on hold for a while until I get some other ideas out the door. Some may say there is no more room for innovation with classic-type games like Pac-Man, Tetris, or Galaga, but I would argue otherwise.

For example, take a centuries-old board game such as chess. The board is simple: eight by eight squares with a checkered design using two colors. Each player has sixteen pieces to work with (a king, a queen, two rooks, two bishops, two knights, and eight pawns). The rules, too, are straightforward and each type of piece has its own style/pattern of movement. The complexity appears during the gameplay.

Yet from this simple setup, hundreds if not thousands of new games could be created. What happened if you changed the board size? To something like twelve-by-twelve? What if you added more pawns, bishops, or knights? What if the board was no longer square and became a three or a four-player game? What if a third color was added to the board, or the medieval theme was swapped out for something else? What if you changed the style of movement for each piece along with some of the other changes I listed? Again, the setup may appear simple, but the dynamics could change drastically during gameplay when compared to the original game (chess).

The same thing goes for older arcade games, although copyright infringement is something to be aware of. For instance, you could take a maze/action game like Pac-Man and create a different character along with a new storyline and a different shape to the maze. Although the game programming landscape is littered with tons of abandoned projects, defunct company creations, and dated ideas, it would not take much to generate dozens of ideas from such a game setup.

And so...with that idea generation concept in mind, I'm going to start making games...lots of them. Short, easy-to-play ones with quick turn-around-times while still building towards the Big Idea (more on that later).