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.

Misfire

Okay, not really. But my last post on here talked about "ignition" and how work on the game engine was going to start up again shortly. That was the original intent, but the time schedule got continually pushed back.

That said, this weekend we did some evaluation of the work that has already been done with the tools and the game engine itself, and so over the next few weeks I'll start getting into more in-depth detail on those topics.

Currently, we have plans for one Big Idea in the works, and we are considering in the short term working on some other, smaller games just to "test the waters" so to speak. More details to follow...

Ignition

It's been a while since my last post here, but there has been a good reason for the silence.

I took most of the summer off from the Jasper engine project mainly because I needed a break. Before the break, however, I worked on some low-poly trees and found some great videos that gave me a lot of new ideas. One of those can be found here and the other one can be found here.

Over the summer I also gathered some more game ideas, did some more animation research, and began preparing to take the engine into a game design phase. Much of the game design process will initially take place on paper, and I have given some thought lately to rolling out a short-term (1-2 month) game to demonstrate the engine's capabilities and to get some feedback. This way I could also run the engine through some more realistic tests and get some early user feedback.

I also created some basic trees in Blender and dropped some of them onto a terrain map for testing, but the screenshots are not all that impressive at this point, so I'll defer to a later date before posting those. That said, the major systems of the engine are all in place (particle systems, UI elements, sound, character animation, terrain rendering, etc.). The next goal is to either to start in on the major game I have planned or write up a small, side game project that may become available for download in the future.

Whatever the case, I'll post some more updates in the coming days as to where this technology is heading...

Debugging Is An Art

Most of the time, debugging is an art. It takes a careful balance of knowledge, hard-won experience, compiler tools, investigative skills, and loads of patience. But sometimes there comes a point when even these things have their limits and you throw your hands in the air in frustration trying to figure out what is going wrong.

Case in point: the strange texture bugs I was finding when I tested my engine on a Vista laptop.

Every other feature seemed to be working fine on the laptop, but every time I used a texture, the results were unpredictable. Often times, when rendering a tile map and some terrain features, the same texture would be used everywhere even though the tile map called for a variety of textures to be used...especially when rendering mountains.

Then, when testing some animation features, the textures on the animated model would look okay at first, but when I pressed a key (and another model came onto the screen), the texture on the original model swapped places with the new model that was being rendered.

Ugh.

Then I created a tile map with an array of textures just to test those functions.

The entire map was rendered with the exact same texture.

Can you say, hello brick wall? What was strange was that the issue was only occuring on the Vista laptop, and was not occuring on the XP box or the Windows 2000 I tested the engine on.

Somewhere, in the back of my mind, I kept wondering if it was a graphics driver issue.

I started eliminating possibilities. Was there some unitialized variable somewhere that was holding unpredictable values? Nope. Was the texture loading function failing? After lots of investigative work, the answer appeared to be no.

Then, I spotted a type/casting issue. Surely that must be it, I thought. Fixed the bug. Recompiled and tried again.

No dice.

At this point, things were getting discouraging. To add to the issues, the frame rates on the Vista machine were down by 10-15 fps compared to the XP machine. I know it is a laptop with a low-end processor, but this was ridiculous.

So I checked out some forums. I looked into the OpenGL on Vista issues. I prayed about it. Ugh...I was ready to just give up and live with it.

Then, I checked on the graphics drivers issue. According to the Device Manager's "Update Driver" feature it said I had the most current version of the driver installed.

I didn't buy it.

I went to the manufacturer's website and checked on the drivers that were available. And wouldn't you know it, there was a driver out there that had an update date of 2007 (vs. 2006, which was pre-installed on the machine itself).

At this point I was so used to hitting brick walls with these bugs that I didn't hold out hope. I was preparing a "Plan B". And C. And D. And E...

I installed the new drivers, ready to hit the rollback button if necessary.

And then I tried the engine again.

In one swoop, a whole class of bugs was wiped out. Every. Single. One of them.

The texturing issues went away. Completely. The frame rates shot up 10-15 fps, and in some cases it was faster than my XP machine. Wow what a relief! Now I can really, truly, start focusing on game design.

Moral: check your drivers!

Water, Water Everywhere

Today's screenshot, while rather uneventful looking, actually represents a significant step forward for the engine.

It represents weeks of work...and the final promotion of the water mesh concept into the map tool (and subsequently rendered by the engine). In other words, I can now add water meshes/features to my tile maps, similar to how terrain features (mountains, hills, etc.) can be added to a tile map. Then, when the map is imported into the engine, it will be rendered as a water feature, just like other terrain features.

Additionally, I have also been testing the engine on a Vista machine, as well as a Windows 2000 machine. There are a few minor bugs on each system to work out, but they are not showstoppers. At this point, the engine is officially "feature complete" and I'll be enlisting some other users soon to get rid of as many bugs as possible before moving ahead with games building.

Next up: the game design phase. :-)