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).

Detours and Excursions

I'm sitting on a 3-D engine that originally had a dual purpose.

In the beginning, I set out to create not only a 3-D game engine, but one that could theoretically be rolled into all different types of software. At one point I had thought about incorporating it into a version of Linux, with the idea of building a sort of subsystem underneath the main desktop like Vista eventually implemented. During my initial research, I also came across Project Looking Glass and Compiz/Beryl.

After looking at loads of screenshots, web pages, demos, and articles, I realized Looking Glass wasn't going anywhere fast, unfortunately. I didn't know what I could really add to Compiz/Beryl that had not already been implemented, so I decided to focus more on game development. As time passed the engine developed into a sizable framework, with a few functions related to window management. I even implemented my own basic canvas feature, with buttons, sliders, image containers, etc. that could be spun around fully in 3-D. You can see some of my earliest posts on this blog for examples of that.

Despite all the work put into this project, it is still a little directionless right now. As a result, I'm going to take a brief detour and learn some Flash programming in order to get another, smaller game project done. This should, in theory, only take a few months at most. In the meantime, however, I am going to start posting some other semi-related ideas here that I'm not really seeing in use anywhere else.

You see, one of the other projects I've worked on over the years is my own programming language. It has never been fully implemented, and right now occupies thirty pages of a notebook as a bunch of sketches, thoughts, and ideas. It would nice at some point to incorporate some of those ideas into a scripting language that would plug in to the engine, but I need to better understand parsers in order to pull that off.

Speaking of parsers, I would like to come up with a better method of parsing a line of programming code. Numerous examples I've seen over the years that attempt to teach a developer how to build a parser tend to follow a similar process. With certain languages such as C++, I feel that learning the language is often made much more difficult because of having to fight with the compiler and all the errors/warnings that go with code that has an occasional error in it.

Case in point: when I was first learning C, I missed a semicolon in one line of code. Although I eventually found other errors, that single missing piece of punctuation threw an absurd 30 errors up onto the screen in the compiler. There really wasn't 30 errors, but talk about a fast way to discourage someone. Those types of situations tell me there are better ways of doing this. Hopefully I'll have time to pursue that soon.