We originally defined the things that would be in phase 2 as the bare minimum stuff we thought would be required to make the game ready for release on Xbox Live Indie Games. As it turns out, we didn't need some of the stuff on the original list so we cut it, but we felt we needed some other things before really being ready to ship to joe gamer, which we did not add to the phase. The result of all this is that we don't think it's ready to ship yet. However, it's still worth talking about all of the awesome stuff we did accomplish for the milestone.

Here are some of the things we added in phase 2 (in no particular order):

• AI drivers
• "Race Circuit" (/Grand Prix) mode
• 12 tracks
• 3 track themes (jungle/mud, mountain/ice, monastery)
• 3 "speeds" for levels of racing experience
• Animated sprite effects
• Cell shaded and outlined sprites
• 5 custom songs in soundtrack
• Engine and tire sounds
• General bug fixin'
• Game balancin'
• General polish

Some of my favorite accomplishments for this phase came in the tools I made to support generating content for the game. Particularly, I'm quite proud of how the BitmapToTiles and Sprite Maker turned out. They were both a lot of fun to work on and turned out to be tremendously useful.

Here's the obligatory screenshot

Anyway, enough blabbering from me, there's more details, more screenshots, and a juicy download link all available from the games page: Karma Riot v2!

I'm going to take a break for a few weeks now, but almost as exciting as being done with phase 2 is that I now get to decide what to work on next.

Here are some development stats:

• Phase 2 calendar time: 26 weeks
• Phase 2 initial task time estimates: 126 hours
• Phase 2 actual implementation time (combined): 168 hours
• Phase 2 average hours per week (combined): 6.5

Last week I went to E3 for the first time. I only got half a day there, but I still got to see a lot of cool stuff. I'll boil down my experience into a few conventient bullets:

• Microsoft's Kinect is a bad idea and would we totally pointless if it weren't for the impressive Dance Central
• I can find no reason whatsoever to get excited about Sony's Move. It is a more expensive Wii that doesn't have any games to back it up. The Wii has already demonstrated that motion control based experiences are shallow.
• Nintendo's 3DS seemed to steal the show in terms of interest. It looks like it has a ton of potential. Now if someone could only convince Nintendo to use modern graphics techniques they would have a real winner on their hands.
• I'm not that interested in the big games that were shown, but I was most impressed by the graphics in Sega's Vanquish.
• All of the things that got me genuinely excited were downloadable (XBLA, PSN) games, as listed below.

There were a few games that I saw that I got really excited about. It is no coincidence that they are all smaller downloadable games that support multiplayer co-op. None of them seem to be getting a lot of press, so this may be news to you even if you were following E3. I got a little lazy and just decided to embed the trailers; take a look: (games are displayed in no particular order)

Castlevania: Harmony of Despair

Necromachina

Scott Pilgrim vs. The World

Glide

So Glide development is still coming along at work quite nicely, although only getting to work one day a week on it (and Friday at that) makes progress quite slow. Despite all of that, we took this video after about 6 days of effort was put in. I think we've come a really long way. This project is a team effort, but the stuff that I specifically contributed were flight mechanics, camera mechanics, landing coordination, and level design. Sadly, youtube took a big crap when I tried to upload it, so you'll need to download the video and hope you have whatever obscure codec I used. Check it out:

• Glide demo video

Well, that's about enough embedded videos for one month. Maybe next month I'll go back to nice old fashioned static pictures. Later!

• We can (kind of) see our product from an end user's perspecive - we are eating our own dog-food as they say
• We are testing the upcoming release of Gamebryo in a way that directed and automated testing does not
• Team members are working with systems they are unfamiliar with which is helping with knowledge transfer and redundancy
• It gives us a creative outlet, which is always fun
• It breaks up the soul-draining monotony of finalizing a release (all testing, bug-fixing, documentation, and paperwork)
• Probably some other reasons

I was really happy with how good of a turnout we got for project proposals. In the end, we had to settle down to two projects to divide the team between and my proposal was one of the ones that got voted on. My proposal (entitled "Glide") was to make a game where players control a skydiver that can deploy or retract hang-gliding wings at any time. The goal is to get the highest score you can on a single drop where contributing factors are how smooth your landing was, the value of the landing platform you ended up on, how many floating rings you passed through on the way down, and any bonus objectives. You can think of it as combining the relaxing pace and exploration of Pilotwings with the reward mechanisms and social aspects of Monkey Target.

I made some concept sketches that I'll subject you to, but not without first disclaiming that I'm a terrible artist. You've been warned.

The game must feature a Pterodactyl

So that's fun. I'm still cranking away on Karma Riot, although making effects required a lot of iteration which slowed things down a lot. In order to keep up the pace, I've decided to put effects on the back burner and concentrate on more pressing features. I did sit down for two hours this week and crank out a new song for the sound track. Now we have one song per track type, which will probably be enough to get away with for this phase. Check it out:

Opus 23

Later

Behold; the sprite maker:

The UI for Sprite Maker

Sprite Maker is a utility that runs inside of 3ds Max. I wrote it in Max's built-in scripting language, MaxScript. I'm not going to go on about every little feature it has; just look at the options and use your imagination. The main point of the tool is that once I've created and animated a 3d scene:

source scene in Max

I tell this thing to go and it automatically takes rendered frames of the scene for each frame of animation in the sequence, each camera angle, and then composites the results into a single image, giving you something like this:

The frame and angle counts are lowered here just to make the sheet fit nicely on the web

In order to make the resulting sprite sheet look more like classic sprites, the Sprite Maker just passes the resulting image off to the Post Process Manager - another custom tool. The Post Process Manager simply takes in a config file and uses the config file to determine what external operations to perform on the input file. I've currently created two operations; the first is 'palettize':

Getting there

You can re-use the same configuration file for many sprites or create a custom configuration for some sprites that you want to process differently than others. All of the Sprite Manager settings including the configuration file to use are stored in the Max file. Anyway, here's the second image processor; the 'outliner':

Now we are cooking with fire

To get a sprite in the game, it's a matter of adding an entry to an XML file that indicates how many cells wide and high the sheet is along with a few other handy parameters. Now that my pipeline is complete, I should be able to start churning out effects.

A 2x zoom of the result

Later

It's no secret that KR is directly inspired by Super Mario Kart. In SMK, if you take a look at the tracks from a top-down perspective and overlay a grid, you can see that the tracks are actually constructed out of a 128 by 128 grid of 8 by 8 pixel tiles.

Exhibit A: 2x zoom of Mario Circuit 2 in the Mushroom Cup

I want to do this as well. This way each track simply uses a 1024 by 1024 texture for rendering, so the challenge is how do we construct this texture from individual tiles?

Instead of creating a custom level editor, I decided to have track authors instead create a 128 by 128 image where each pixel in the image represents a tile the the full sized map. The images would use a small fixed palette of colors where each color represents a type of terrain. Basically, you just create the layout in MS Paint, or your image editor of choice. Creating the basic shape of maps in this way has a lot of advantages:

• Everyone already has a map editor
• Everyone already knows how to use the editor - no learning curve
• The editing process is simple and intuitive - just draw out a shape
• The editor comes with tools like undo, flood fill, lines, curves, shapes, and selection
• Some editors come with tools like magic wand, layers, and clone stamp (very useful)
• The editor reliably handles a known filetype - little to no chance of corruption, instability, or version mismatches
• I didn't have to create an editor that does any of these things

Once this image has been created, I have a processing tool that 'compiles' it into a high-resolution image. The compiler can make intelligent decisions about what tiles to use in each location based off of what the neighboring terrain types are. However, instead of just coding in a bunch of specific conditions that match a fixed tileset, I decided to make it data driven. The compiler is provided two things: a rule set, and a tile set.

The tile set is simply an image that contains an atlas of 8 by 8 tiles that you want to be used in the construction of your map. The tile set author can provide as many or as few tiles as they want and arrange them in any way they want. For example:

Exhibit B: 2x zoom of KR's "mountains" tile set

The rule set is an XML file that contains an arbitrary number of rules where each rule basically just says: for the terrain type of this pixel and given a particular configuration of neighboring tiles, use this set of tiles from the associated tile set. I'm not going to get into the nitty gritty of how these patterns are defined but I am quite happy with the solution that I came up with. Rules are fairly compact and easy to read but also flexible enough where you can describe a lot of situations and you don't need a ton of rule duplication to describe similar situations. At the same time I made it very verbose about anything it encounters that is out of the usual, so it identifies any rule parsing errors and while processing the track clearly identifies any situations that aren't covered by the rules you gave it.

So with the compiler (called BitmapToTiles), you give it an input image, a rule set (which references a corresponding tile set), and an output filename and it churns away. Let's take another look at the SMK example segment from earlier:

Exhibit C: 16x zoom of how you would represent that track in the base layout image

Exhibit D: 2x zoom of the compiled result

Now the cool thing about using a compiler is that if you play the level and you want to make some quick edits, rebuilding is trivial - just change the base layout (which is also used for the game's driving simulation) and the high res image can be kept in sync. Another handy feature is that you can change track types easily. Here I've changed the same example to use the "jungle" tile set, which actually has a completely different layout and set of rules for how terrain types interact with each other:

Exhibit E: 2x zoom of the jungle version

The BitmapToTiles program itself is fairly generic; it doesn't have any KR-specific assumptions. Each track also has an XML file that sets its name, tile set, numberof laps, music, etc. By creating another wrapper program for BitmapToTiles, I can just crawl through the track's XML and its references to figure out all of the arguments that need to be passed into BitmapToTiles. This wrapper, called TrackToTiles, only takes in the track XML file as a command line arg, which is mainly a convenience for compiling tracks. To further add to the convenience, I added it to my right click menu for XML files, so that compiling a track is super-easy!

So easy!

I had a blast making these tools, and I'm really proud of how they turned out. That being said, I realize that there would be tons and tons of additional work to get the tools and the tilesets to a point where I could just give them to some stranger and expect them to be able to make a map for the game. Fortunately, that's not a requirement (for now). In closing, I'll leave you with a preview of one of the tracks I put together. You'll have to use your imagination to figure out what it looks like in game:

2x zoom of "Jungle Rumble I" (tentative title) base layout