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.

Flying Marbles

After fighting a two-week losing battle with what I thought was a programming bug, I'm back with a couple more screenshots. Here is a test player marble rolling along on the marble "terrain":

 

 

As far as the "bug" goes, it was actually some old viewport-type code I put into some of the rendering routines of the engine. The key word here is "some". I overlooked a couple of key model rendering routines that were used for rendering player models and well...the entire terrain was being rendered through a viewport while the player's model was not. The result was quirky, but vaguely predictable offset errors on the location of the marble which caused it to either levitate above the playing field or made it half-disappear into walls.

This is one of the drawbacks of taking long breaks while working on a major software project. To put it another way, I think I need to document the libraries a little better.

On a positive note, what these screenshots do not show is that as the marble moves along the field, it rotates and goes up and down the slopes. There are no physics involved yet, however.

Next up: some minor bug fixes and some enemy marbles.

Rolling Along

Here is another screenshot from the marble test game (aka "Marbleland"). The yellow blocks constitute the playing field, while the green tile in the middle is the start tile. The red tiles scattered about are "powerup" tiles, but those will likely change.

Despite the appearance of this as a marble game, the models (blocks) could easily be swapped out and instead of marbles (not pictured here), one could use animated characters. This particular playing field took about 2-3 hours to design/assemble, but would have gone much faster had I implemented some more features (such as cut and paste) in the level builder tool. The blocks were built using Blender and PaintShop Pro and those took additional 6-8 hours.

The engine also has basic physics capabilities built into every model. Each object has mass, velocity, and acceleration properties. I haven't used any physics yet in this particular project, although I will test that to see what effect it has on rendering speed. I will also probably attempt to simulate friction at some point.

Were I to actually ship this game at some point stage it would need:

• Sharper differences between the blocks and the blue playing field below (i.e. shadows)
• Game mechanics/goals that differentiate it from Marble Madness
• Different enemies other than black marbles, green puddles, green Slinky-things, etc.
• Add things like chutes, elevators, etc.

Marble Madness was a platform/racing/isometric-view game. This one is fully 3-D, which opens a lot of new possibilities and allows for a changing point of view, such as the one found in Switchball, Monkeyball, or Hamsterball. Speaking of Switchball, it is possible I could add very basic cloth simulation with the water mesh capabilities I added to the engine last year.

Next up: Putting marbles onto the blocks and setting up basic AI for the enemies.

Marbleland

I've started to build a test game for the engine. For now I'm calling it "Marbleland", until I come up with something better. Right now the main goal is to put the engine through its paces before moving on to a more marketable idea. In fact, here's the first screen shot of a test level I'm building:

At this point it probably looks like a cross between Tron and Marble Madness. I've gotten the basic player marble up and rolling and have built numerous models to represent different block heights. After building the models, I drew the level design on a piece of graph paper. The end result in the screenshot above took about two weeks total (a half hour here, a half hour there).

The process is going smoothly for the most part, although I had to relearn how to use Blender after switching from version 2.49 to 2.64. The UI overhaul on Blender is jarring at first, but it is so much easier to use. In fact, while searching for some tutorials I came across this fantastic video on UV mapping using the new interface. I highly suggest you check out some of the other related tutorials by this particular author.

I think the most surprising thing so far is the time each step of the process is taking. The model building was tedious at first, and the construction of the first level is going slower than expected. On the plus side, I have only made minor modifications to the base engine code.

Maybe Next Year

I have a few Linux books on my bookshelf. I want to use them, but every time I look through them I hesitate. It's hard to explain why, but I think this post by Miguel de Icaza just about sums it up: What Killed the Linux Desktop.

When I was a kid, I got into programming on the Apple IIe. I practically mastered Applesoft BASIC, toyed around with UCSD Pascal, and then moved into 6502 assembly language programming. I sunk a lot of hours (er...years) into software development on my own time (read: unpaid work). I built my own word processor which I used to write school papers and created a basic 3-D drawing program. I also built a 2D drawing program which I hoped to someday bundle with the word processor (along with a music program). I also tinkered with creating my own programming language and tore apart the DOS 3.3 operating system with the hopes of rebuilding it into something I could call my own. This was back in the late 1980's.

Then the development world shifted drastically under my feet. One word changed everything: Macintosh.

I didn't have a lot of information at the time, but I could read the writing on the wall: the Apple II was not forever as some articles had indicated. That pretty much ended my interest (at the time) for developing on the Apple II platform. I later shifted my efforts to the PC world. I also dove into C and C++ development, and tinkered with a lot of different development environments from Turbo C++ to Visual Studio to simpler tools. Windows programming brought its own set of challenges...one of them being increased complexity.

Then one day I discovered Linux. It reminded me a lot of the work I did years ago when I attempted to build my own operating system on the Apple II. I toyed around with a handful of distros from Knoppix to Ubuntu. I even picked up some Linux books and installed a dual boot partition with Windows and Dapper Drake. I thought to myself, "if I could only combine my dream of a 3D environment with Linux, I might be able to build something really special." Unfortunately, I was hoping to swing for the fences and make something game changing...in other words, Visicalc-like special.

Yet the more I worked with Dapper Drake and looked around at the various development environments that were available, the more discouraged I became. I found myself spending more time getting everything up and running than actually coding. Of course, more distros kept coming out of Canonical, too. Canonical is now up to Quantal Quetzal (12.10) with the most recent long-term support product being Precise Pangolin. That's a lot of releases in six years. I have enough trouble testing the game engine on the various Windows versions out there. As far as Linux distributions, I'd be at a loss trying to figure out where to even begin testing.

Now, I'm all for improvements in applications and operating systems. I also understand it is a difficult tradeoff between security, innovation, and backwards-compatability. Unfortunately, I also know what it is like as a third-party developer to put years of work into a product, only to find the foundation beneath you has shifted.

It feels like a huge waste of time.

So, in the short term, I will not port this engine to a Linux distro. I wanted to at one point, and in fact, I wanted to create a dream IDE just for game developers that could be used in conjunction with Blender to make great games on Linux...and maybe even Linux only. Then I looked at the endless hours of testing I would have to do and cringed. I don't have infinite resources.

That said, the engine I'm working on has the potential in the future to be ported to Linux. It is built on OpenGL, which opens up a lot of possibilities down the road, and doesn't tie it to a particular platform. Yes, there are some DirectX components, but those can be easily swapped out. Who knows...someday it might happen. Someday this studio might even grow into a bigger house. But until then...as the saying goes..."maybe next year."

The Four Year Leap

I've spent a lot of time on this software project...four years to be exact. One year was spent reading and researching, and three more years were spent developing and testing. At some point, however, a game engine needs to be put to use in something larger than itself, much like a V6 engine needs to be placed into a car.

In some ways it's a leap of faith at this point. All the hard work of development, testing, and research is kind of meaningless if you don't put the engine into something practical. In other words, it's time to down to the business of actually writing games.

One of the commonly suggested starting points for anyone that wants to get into serious game development is to recreate an existing game on the platform of their choice. The best starting point, however, is not create a multi-player online game. It is not to build the next Halo installment, either. Often, it's easier to start with something simple...such as a common card game (cribbage, poker, etc.) or a retro game such as Pac-Man, Space Invaders, or Missile Command. Checkers would work too, although building a chess game with a full-blown chess engine behind it is a bit daunting at first.

So, armed with Blender, Paintshop Pro, and a shiny new engine waiting to be revved, I'm going to plunge into game development again. Like the advice of old, I'll start with simple projects, with the end goal of building skills which will eventually pave the way for bigger undertakings such as the "Big Idea" I've hinted at in prior posts.

As always...stay tuned. I'll start posting screenshots shortly.