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.

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

Testing News

No screenshots today...although I have some testing news. I began to test the engine on other systems, most notably a laptop with Windows Vista installed on it. The tests ran reasonably well, although there was a 10-15 fps performance drop on terrain rendering and UI rendering, but that was to be expected considering it is a Celeron/Windows Vista Basic laptop. I'm just happy at this point that it is working without a hitch for the most part. Hopefully at some point soon I'll be able to test it on a Windows 7 system, too.

Over the next couple of weeks I also plan on making some tool updates and will promote the water/mesh functionality I developed over the past month so that it is on par with the terrain map feature I have in the map tool today. I'm also continuing to improve the UI functionality I mentioned previously.

More Waves and Dialog Boxes

After several weeks of testing several different algorithms, I think I've finally settled on one for rendering basic waves (without the help of shaders). It's been a long road, and oddly enough, I've pretty much come back to where I started, with some minor modifications to an original idea...combined with a minor discovery. First some wave screenshots:

The new algorithm essentially checks the nearby eight vertices (as opposed to the four I was originally working with) and averages them. Also, when a waveheight initially passes over a point, it essentially starts the point "spinning" around. That angle is translated via a sine function into a value which is added to the point's height. The key discovery I made was that through this combination, I could make each vertex of the mesh simluate a dying sine wave by continually decreasing the radius value in the following equation:

y = r * sin (angle)

Basic trigonometry, yes, but in all my previous testing I ignored the r component for some unknown reason.

I've also been busy working on some 3-D dialog box improvements, seen here:

In this screenshot, I'm demostrating some basic checkboxes, a slider control, a textbox control, a button, and an image control. All on a fully rotatable, 3-D dialog box/window. The main use for this will be heads-up-displays, pop-up dialog boxes, etc. It is also fully alpha-blending enabled.

With these items nearing completion, I'm now turning the corner towards actual game design. There is one last stubborn textbox bug to squash, and after that I'll run some tests over on my Vista box. Then...it's design time!

Rendering Waves, Part I

For the past couple of weeks I've been testing several different algorithms for water rendering. I've limited myself in terms of technology a bit because of the age of my video card (7+ years old) and to keep the user base somewhat broad...therefore...no pixel shaders or any effects like that. Yes, I can go out and buy a shiny new high-end graphics card, but again, it would ultimately limit the user base down the road because of my tendency to want to push my graphics hardware as far as I can. :-)

I started out by building a basic mesh class (jMesh), and then running various functions across the mesh data. One of the most peculiar algorithms I came across "averages" the four surrounding points to calculate the current point's height on every pass:

y0 = (y1 + y2 + y3 + y4) / 4

I'm not sure who to credit for coming up with that, but I thought I'd give it a run and see what happened.

I was surprised to see that when I randomly dropped raindrops onto the mesh, little wavelets spread out from each drop and then faded out. Soon, though, I ran into some limitations of this concept because I wanted my waves to propagate out further and (hopefully) reflect off some walls I'd set up at the edge of the mesh.

Today, however, I spent some time paging through a 1960's physics book and came across a diagram of something called a "wave machine". That, along with the explanatory text beneath the photo, gave me some new ideas. The text described the wave machine and how it worked. As a result, I changed course on my own algorithm tests and added an "angle" value each point on the mesh. Also, I let the x coordinate and y coordinate of each mesh point be controlled by output of a sine and a cosine function.

The result?

What is difficult to see in this screenshot is that the entire mesh is in motion, and it looks pretty close to what a storm-tossed sea would look like. With a little bit of coloring, and some mountains thrown in, it looks like this:

Maybe I should post a movie at some point. Anyway, this new algorithm is a cross between the sine/cosine functions my own "averaging" type function that has damping and a whole bunch of other variables to play around with.

One key design point I want to make here is that because I've generalized all this into a generic "mesh" class, it opens up a lot of new possibilities such as basic cloth simulation, erosion-generated terrains, etc. I suppose you could also use some of it for creating landscapes altered by earthquakes. One other thing I plan on testing down the road is whether this could be morphed into a semi-realistic cloud mesh for cloud banks.

3-D Dialog Boxes, Part II

Things are moving along pretty well with the game engine...and there have been some recent updates to the 3-D dialog/GUI functionality. So far, the dialog box library can render buttons, picture boxes, text, etc. I'll be adding textboxes soon, too. Again, every GUI that is created with this library is fully 3-D (capable of being rotated, scaled, etc.) and has alpha-blending capabilities.

As usual...here are some screenshots...

Electric Maze

I threw this together in an about an hour or so. Just another test to see how fast I could create a playing field...in this case, a Tron-like 3-D maze.

Mountains

Here are a couple of screenshots demonstrating a basic mountain range made with the contour map tool. This was a basic test not only for the map tool but for the engine itself.

Several engine features are at work here, including terrain rendering, tile map rendering (brown ground tiles) and the skydome (along with a sunset). It probably took me less than an hour to create the tile map, the mountain range (using contours), and the mountain/ground textures. This scene can be viewed from any angle or elevation, by the way.

 

 

I have yet to perfect the sunset/sky coloring yet (or clouds for that matter), although the algorithm I created for it is up and working properly. Now it is just a matter of adjusting some color tables I've created for the skydome to make it look a bit more realistic.

Turning the Corner

I've entered a new phase with the engine...bug cleanup and performance testing. At this point  I've pretty much locked the codebase down in terms of adding new features. Now it's a matter of speeding things up and pushing the limits of it to see where improvements can be made and to identify any lurking bugs. Then...it's off to design a set of games!

In a few short weeks, I'll post some more pictures of where things are at with the engine and the game itself. For now, here is a feature list of what is currently up and running in the engine:

• Skydome rendering with a time/date based sun position, time-of-day shading, and star rendering
• Tile map rendering (using height maps)
• Terrain feature rendering (for higher detail features such as mountains, hills, rivers, etc.)
• Keyframe character animation
• Wavefront model rendering (.obj format)
• Collision detection
• Basic physics properties for all objects in the game (mass, velocity, acceleration)
• Basic shadows
• Billboard rendering
• Particle system that can render particles, billboards or models
• Keyboard/mouse input
• Gameboard rendering (with model pieces)

Concurrently, two tools have also been developed alongside the engine: a particle system design tool and map design tool. The map design tool can create gameboards, terrain features, tile maps, and more. Additionally, the map tool can take an existing contour map and convert it to a height map...or allow you to create your own from scratch with adjustable contour lines.

Underneath all of this, however, is the fact that this engine if fully object-oriented, and that the graphics portion is written in OpenGL. This opens the door to potentially porting games down the road to the iPhone, Linux, and maybe even the Macintosh platform.

Forward Progress

It's been a busy few weeks since I updated this blog, but I've been hard at work adding several new features to the engine. These new features have included basic collision detection, a sound system, and simple projective shadows. Right now, I'm in the middle of upgrading the lighting system to accomodate spotlights and multiple light sources (as opposed to one). This is taking longer than I expected, but theoretically it should be done by the end of the year.

In a previous post, I said I would talk more about one of the features I added earlier this year: the contour map tool. This tool (seen below) has two main capabilities. One feature is the ability to create contour maps from scratch, and then, using Bezier curves, allow the user to manipulate a series of concentric rings in order to create mountains, hills, lakes, valleys, or even simple riverbeds.

Eact tiny white ring in the picture above is a "handle" which the user can use to shape the blue contour lines. I can imagine this would get tedious if you wanted to create a multitude of unique mountains or lakes, for example, so in the future I might allow for some procedural mountains to be rendered by this particular tool.

The other feature is the ability to take a pre-existing contour map which has been pre-color-coded and then convert that into a 3-D heightmap (using the "Import File" option above). I haven't fully tested this particular capability of the tool yet, but I plan to in the near future with an area lake map. The goal, of course, is to create more realistic terrain features and hopefully begin to use various real-world features in the first game I hope to release using this particular engine.

Mt. Ararat, anyone? ;-)

Character Animation, Part I

Over the past month I've worked hard to complete one of the major features of the engine: keyframe character animation. As of this post, the engine is only supporting a customized format which can be exported from Blender (via a Python script). Here is a recent test I performed on the engine by exporting a spinning cube animation out of Blender:

 

The fps rate is decent (for a basic six-year old video card) even on animations with hundreds of triangles. At some point, however, I'd like to experiment with pushing all of the individual keyframe renderings into display lists instead of doing all the interpolation on the fly.

A decision was made early on (by me) to go with keyframe animation versus bone animation. Someday I hope to add a much more comprehensive set of animation functions that could handle multiple formats.

One thing to note, however, is that many of the objects in this engine (lights, models, billboards, character animations) are all full class objects with inhertiable properties from the parent class of "jObject". The basic jObject class declaration looks like this:

class jObject
{
     public:

     float mass; // for physics calculations
     j3Dvector location;
     j3Dvector velocity;
     j3Dvector acceleration;
     j3Drotation rotation;
     objectstate state;
};

I have lots of ideas for these properties, but the obvious one is the soon-to-be-implemented feature of collision detection and basic physics calculations. :-)