Matt's Dev Blog

Lua is a big name in game scripting.  I chose it for my engine because it is simple, easy to integrate and has excellent performance. Anyway, I just read an article about LuaJIT , which is a just-in-time compiler for Lua that is partially sponsored by Google.  It's supposed to have even more amazing performance than the standard implementation.  It's also binary-compatible with the standard Lua library and interpreter, which means I'm going to try it out with my game engine ASAP.

Here's a screen capture of my game engine in action. The video quality isn't great, but hopefully it shows off the engine well enough. While you're at it, check out a screenshot  (better quality).

Today I was working on animating my cyclist/bike mesh for Criterium. I just wanted to give kudos to the folks who developed Blender , because it is a great tool and the documentation keeps getting better and better. The inverse kinematics feature for animation is particularly awesome.  However, using Blender is not for the faint-hearted. It is extremely well designed, but also extremely complicated. In fact, when I first used Blender I thought it was buggy; strange unexplained things would sometimes happen to my models. Now I know that the "bugs" were all my fault. I simply didn't understand the software. Thankfully, I think I've progressed past that state of ignorance. When I finish my animations with the cyclist (hopefully this week) I'll post a video. P.S. Here is a link to a render of the bike model .

I'm considering game mechanics related to cycling.  First up is gearing: should the player control the gears, or should this be automatic?  Gearing would definitely give more realism, but might be clunky for the player. A mechanic I definitely want to use is drafting.  I figure it's relatively easy to do this: draw a ray along the bike's velocity vector.  If it doesn't hit another bike in front within a certain distance (say, 2 meters) then apply a small aerodynamic friction force in the opposite direction of the velocity vector.  Did you know the drag coefficient of a bicycle + rider is about 0.9 ? Finally, the user has to have some control over power the cyclist is expending.  I'll probably display some kind of heart rate counter as an indicator of effort, and possibly a stamina indicator that's proportional to lactic acid buildup.  This will keep the player from sprinting through the whole race!

Today, I was thinking about the "advanced" effects that would most benefit the realism of the game: Motion blur , to give the illusion of speed.  Ogre compositors are most likely the best solution. Dust particles , which would be thrown up occasionally when the bikes cross sandy portions of road.  Dust, IMO, is one of the easiest particle systems to implement well.  My Asteroids demo has some dust particle systems and textures. Rain , which is also easy to implement, given Ogre's built-in particle scripts . Bloom effect , one of my favorite effects, and definitely necessary for a setting sun.  I plan to use bloom to boost glare from specular highlights on the bike frame.  I used this affect in the Asteroids demo as well, and it looks quite good for highly reflective surfaces.  This can be easily done using HDR + high pass filter + Gaussian blur, and Ogre might have a compositor plugin for it. Shadows , which are completely trivial with Ogre.  Awesome!

Roads are tricky.  They have to match the terrain; they have to bank, curve, swerve and whatnot.  I have three ideas for roads, and no idea is trivial to implement.  All my ideas output a road mesh with a rectangular cross section, so there will be no gaps between the road and the underlying terrain.  The road will actually be a rectangular "tube" with only the top of the tube showing above the terrain. First up is procedural generation of roads.  For this scheme, I would first generate the terrain heightmap.  Then, the roads could be generated by following contours, making random changes in direction, or making random jumps to different contours.  In the end, the procedural algorithm would output a list of waypoints for the road, and a mesh could be generated from the waypoints. Second is direct creation of the road mesh.  I would have to make a modeling tool for the road, and extrude road segments from the end of the road.  Perhaps Bezier curves and control points

Terrain is, of course, one of the most important aspects of any video game.  It is the player's sandbox, and it fills most of the player's field of view.  Therefore special attention should be given to terrain. In Criterium, the terrain will model an outdoor environment.  I considered city environments, but decided that the detailed textures and models needed for city streets would be too much work for one person.  Therefore, Criterium's environment will be a natural one: plains, mountains, hills, etc. The obvious answer for this type of environment is a terrain heightmap.  Heightmaps are relatively easy to use in Ogre thanks to the terrain and paging scene managers.  Heightmaps can be generated with a tool like Terragen  or even GIMP (the cloud effect makes a good base for a random heightmap). The terrain also has to include vegetation and roads.  I figure I might have to make some kind of tool for placing vegetation, or perhaps I could load trees by using a textur

The engine is finally approaching some kind of maturity. Here is a tally of the features I've finished so far: Renderer: Written from stratch in DirectX, heavy use of HLSL HDR Rendering Bloom Effect Cubemapping (shader driven) Bumpmapping (shader driven) Scriptable particle system Billboards/textured quads Physics: Using ODE.  Supports simple sphere volumes, box volumes and planes Persistence:  Through XML using eXpat.  All engine objects are XML-configurable Scripting: Using Lua.  All engine objects can be manipulated by script Audio: Using FMOD, with 3D sound! Of course, these features are only a small subset of the features provided by a modern engine, but my goal was to make a uniform, easy-to-use, API. I strive to make each of the features my engine has as solid and well-engineered as possible. I'm using the quality-over-quantity approach. After all, I'm just one person, not a team of 300. Most of these features are in the demo .

For my CS248 project at Stanford, I have to make a video game. My idea is to create cycling game called "Criterium."  In cycling, a criterium is a short race that tests the cyclist's skills.  The idea came to me as I was playing the cycling game on Wii Sports Resort and wondered what it would be like if the game was more realistic.  I'm setting my goals pretty high for this game:  I want polished graphics, and good game mechanics. One of the coolest things about cycling is riding in the peloton  and excercising bike tactics.  I want to try to recreate that experience in my game.  As far as I know, no game has done that yet.

Over the past year and a half I've developed the bad (or maybe good?) habit of working too much on my hobby project, a video game engine. Yes, I know that today most game programmers use an off-the-shelf engine like Ogre+ODE/Torque/Unreal, but the engineering challenges of writing a good game engine are for me just too enticing to skip over. Source code for the Jet Game Engine.  I've released this under the MIT License. Installer for the Extreme Asteroids demo.  Tested with a GTS 8800 and a 2.4 GHz Core 2 Duo.  If you can't get it to work, leave a comment below this post!  It also works on my 4-year old Dell D610, if I turn off bloom, floating-point frame buffers, and antialiasing. Gallery of demo models.  All created by me.  Released under the Creative Commons Attribution-Share Alike 3.0 United States License (man is that a mouthful!)