Matt's Dev Blog

Terrain implementation for games is a subject with a lot of depth. At the surface, it's very easy to get rudimentary terrain working via a noise function and fixed triangle grid. As you add more features, though, the complexity builds quickly. Overhangs, caves Multiple materials Destructive terrain Collision detection Persistence Dynamic loading Regions, biomes Very large scale Smooth features Sharp features Dynamic level of detail Extremely long view distances In isolation, each of these features can make terrain difficult to implement. Taken together, it takes a lot of care and attention to make it all work. Minecraft is probably the canonical example for terrain generation in the last generation of games. In fact, I'd say Minecraft's terrain is the killer feature that makes the game so great. Minecraft does an excellent job at 1-8, but for a recent planetary renderer project I was working on, I really wanted 9-12 too. In a series of articles, I'm planning to break do...

I've been writing a new game recently -- and this time, I decided to use an entity/component system . Boy, does that approach make things easier! In other games I've written, I've struggled to fit new gameplay features into the existing code base. With a entity-component based systems, it's easy to add new features: Need a way to track targetable objects in your game? Add a Targetable component that advertises the unit's position, name for display in the HUD, etc. Need to add some new AI behavior to a unit? Add a component! Update all the AI components once per frame and you're on your way. Does your game need networking? What should you do...? Add a component containing all the info for network serialization! Need to control a unit from user input? Add a joystick component that updates the unit's position component in response to user input. Basically, any new feature can be folded into a component. The best thing about components is that they are dy...

Yesterday, on my day off, I played around with generating some Minecraft-like terrain. A lot of people see Minecraft and think "Hey, that doesn't look too complicated...I could do that!" As a result, we have lots of Minecraft clones and articles about implementing Minecraft-like terrain. I think that's great, because it inspires people who don't have much graphics programming experience to give it a try. A game like Crysis doesn't exactly do that. It's just too much complexity for a single person to handle. Anyway, the first step in my journey to copy Minecraft was to implement a "mesher." A mesher converts a 3D bitmap containing block data into a quad mesh that's displayable using OpenGL. This part was surprisingly easy, at least for the simple approach I took. I decided to sweep each "column" of blocks in the X, Y, and Z directions, and generate the quad faces that way. This doesn't allow quad faces to span across m...

This week, I finally got fed up with typing in/managing passwords on a billion different sites. Since things like OpenID haven't really taken off, I decided to take matters into my own hands...and write a password generator extension for Google Chrome. There are actually a ton of such apps on the Chrome web store, but I'm paranoid about security, so I wrote my own and open-sourced it. By virtue of being open source, perhaps people will trust my version a bit more. Anyway, the extension is available here , and the source code is hosted at github . May all your online transactions be secure! UPDATE: Fixed github link.

Lua's implementation of coroutines is one of my all-time favorite features of the language. This (short) paper explains the whole reasoning behind the Lua's coroutine implementation and also a little about the history of coroutines. Sadly, coroutines are not supported out-of-the box by many modern languages, C++ included. Which brings me to the subject of this post: Lua-style coroutines in C++! For those who don't know (or were too lazy to read the paper!), Lua's coroutines support three basic operations: Create: Create a new coroutine object Resume: Run a coroutine until it yields or returns Yield: Suspend execution and return to the caller To implement these three operations, I'll use a great header file: ucontext.h. #include <vector> #include <ucontext.h> class Coroutine { public: typedef void (*Function)(void); Coroutine(Function function); void resume(); static void yield(); private: ucontext_t context_; std...

This is a demo of my homegrown cascading shadow mapping.  Notice how the shadows remain sharp at all distances.  This is currently using 4 2048 byte shadow textures, but it looks similar with 1024 byte textures. Cascading shadow maps work by dividing the view frustum into sections, and assigning a shadow texture to each section.  This allows shadows to be rendered at great distance without loss of visual fidelity during close-up shots of a shadow.  The great thing about shadow mapping is that you get self-shadowing for free. The performance isn't too bad either.  This demo ran at 270 frames per second on my EVGA 8800 GTS, with normal mapping and specular mapping.  Modern GPUs have really great texture lookup performance: the shader I wrote for this demo performs 7 texture lookups per pixel (1 for normal mapping, 1 for the diffuse map, 1 for specular mapping, and 4 for shadow mapping).  A previous iteration of this demo (with only 1 shadow texture loo...

Here's a demo of the new particle systems I've implemented in OpenGL.  Performance is much improved over the DirectX version.  Particles are initialized in C++ rather than in Lua.  Also, I use two particle buffers and swap between them, rather than using one buffer per particle system.  Anyway, here's a video capture:

I've been meaning for a while to mess around with destructible meshes (they're way cool!). Making physically accurate destructible meshes is hard. Instead, I've opted for a simple scheme that still has great visual results for compact objects. The technique works like this: Choose a plane to split the mesh along. Create two new meshes to hold the fragments. For each triangle in the mesh: if the triangle is entirely above the plane, add it to the first mesh.  Otherwise, add it to the second mesh. Create a new scene node/rigid body for each of the fragments. I added some optimizations as well.  To begin, you don't have to copy the triangle data for both fragments. They share the exact same mesh data, just different halves of it.  Instead, I create a new index buffer for each fragment and then re-use the same vertex buffer. This works really well and is relatively light on the video memory. Another thing I did is to re-use the original destructible mesh object. T...

So, it turns out that I didn't use Criterium for the video game competition at Stanford.  I actually met a partner and went with another concept instead -- Warp.  It's kind of like Starfox and it's inspired by Rez, one of the first PS2 games.  Explosions and missiles fire in time with the music; we used ChucK , an audio processing language, to achieve this. We also made some destructible objects using rigid bodies, and I added some particle explosion effects.  We used Lua to for enemy AI, and wrote a small TCL-like script parser that reads in data for the level layout.  The buildings in the background are procedurally generated.  We used OGRE for the graphics (this was a loose requirement of the project) and Bullet for the physics.  I had a lot of fun with this project, and I've posted a video capture below.

I finally got around to making the road tool for Criterium.  The tool has two parts: a Java application that lets you paint roads on the 2D heightmap texture, and a Ogre-based tool that automatically converts a 2D path into a 3D mesh.  The Ogre-tool queries the heightmap to get the height of the road, and performs smoothing so there are no discontinuous road segments.  I've posted a screenshot below.  Also, I've got my GIMP terrain shown in the screenshot.  I generated it using random noise and the GIMP lightmap filter.

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

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

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

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