The development of Mad Skills Motocross so far. Screenshots, background, tools and libraries, implementation details, and plans for the future.

Welcome to the Turborilla Developer Diary. I will use these articles to get some thoughts off my chest as well as inform the public about the making of my games. They will be relatively technical and hopefully interesting for those who do care about the process of developing and marketing a game. Hopefully this diary will be updated monthly.

My current, and first, game is being developed right now: Mad Skills Motocross. Check out the trailer to get the most out of reading this.

In this, the first developer diary entry, I will talk about the background of Mad Skills Motocross, the various tools and libraries I use, some implementation details, the excellent artist I have found, and what the plans are for the following months.

Background

About two years ago, I started playing around making my own physics engine based on work by Jakobsen. He is the guy behind the ragdoll physics in the game Hitman. I really liked the concept and the simplicity of it and kept developing my physics engine, and one day I tried out making a motorcycle driving on a flat plane. It worked, and the springs and dampers made acceleration and deceleration a joy to watch.

This was just a motorcycle, two wheels and a frame, but no rider. I added a few jumps to the "track" and when I compiled and ran this small prototype it blew me away. It was fun. All I could do at the moment was to throttle or brake, but the motion of the motorcycle, the interaction between the frame and the wheels, was really smooth and seemed very realistic and the jumps and landings were a blast to watch.

It got me thinking in the usual way: "What if I added this and that and monkeys in pirate-clothes? That would make it really fun." 

I talked to a good friend of mine who was interested in my work with the physics engine, and showed him the prototype. He liked it and we decided to brainstorm for a bit, and during that brainstorming session Mad Skills Motocross was born. With no name and somewhat different feature set, but still the same core gameplay mechanic: A rider whose stance you can control, riding a motocross on a track full of jumps at neck-breaking speeds. Everything enhanced by glorious real-time physics.

For some, it may be apparent which games were the inspirations for Mad Skills Motocross. I dare not mention them both, for one of the companies has a very unpleasant history of lawsuits. One of the games is Ski Stunt Simulator and you can ask a friend, one who was a gamer back in the day, what the other game is

Software, tools and libraries

With the birth of the excellent LWJGL some years ago, it became possible to use OpenGL hardware-accelerated 3D graphics with Java, my favourite programming language. Yep, that's right. Mad Skills Motocross is entirely programmed in Java.

I am not interested in low-level graphics programming though, so when I found the jMonkey Engine (jME) I started using it and never looked back. jME is a 3D graphics engine for Java that uses LWJGL. And it makes 3D programming so much more fun and so much less time-consuming that I urge you to take a look at it if you like Java. Even though jME is primarily a graphics engine it also handles audio, input, and general game programming features.

Other stuff I abuse:

• Eclipse is my Java IDE of choice, it has no equal
• Subversion for versioning control
• GIMP for my crappy programmer's art
• Audacity for sound effects
• Firefox for wasting time
  
• Coffee
• Beer (great for brainstorming sessions)

Why not an existing physics engine?

Why didn't I just use an existing physics engine? Well, there are some good and free physics engines out there. The problem is that they are too general. I do not believe in general physics engines unless you are dealing with 3D rigid body dynamics, which I am not. My in-house physics engine is specialised for this particular game. In Mad Skills Motocross, bodies very seldom collide and inter-body collision is not part of the core gameplay.

Implementation

A tale of trial and error (and success): The rider 

The very first thing that I had to get right was the player's control over the rider. Just like in Ski Stunt Simulator, you control the rider with the mouse (you could use gamepad or keyboard also). If you move the mouse upwards, the rider stands up. Mouse down, rider crouches. Mouse right, rider hangs over the handle bar. Mouse left, rider leans back. And everything in-between. That's full control for you. Have you played those trial-games, mostly made in Flash, were you can only get the rider to lean back or forward? This is a whole new dimension over that. You can also throttle or brake with the left and right mouse buttons.

Now, this took me months to get right. After months of tweaking, coding and ripping my hair, I finally got it just right. The problem is that there are so many ways the joints can bend and still place the centre of mass where you have placed it with the mouse. The problem is that it does not look very realistic when the knees bend backwards. Look up Inverse Kinematics if you want to understand the complexity of this task.

The dream of the all-curing elixir

Just as is the case with physics engines, also graphics engines tend to be general. No graphics engine can instantly solve all the problems for all developers in an efficient manner. This problem is not as apparent as it is for physics engines, though.

jMonkey Engine is primarily intended for 3D graphics, but in Mad Skills Motocross I use both 3D and 2D graphics. I need 2D because I love parallax scrolling. If you do not know what parallax scrolling is then ask that gamer from back in the day. In short: several scrolling 2D layers moving at different speeds to create the illusion of different distances from the camera. Imagine a far-away mountain partially blocked by nearer hills.

Even if 3D is all you need, there are always some missing features unless you are making a very simple game. This is true for all graphics engines.

Fortunately, jMonkey Engine has a wonderful architecture which makes it easy to add features. I did say I wasn't interested in graphics programming, but I am still pretty good at it.

The first thing I implemented graphics-wise was Subdivision Surfaces, which I was going to use to make the tracks smoother. This was a pain, and took me a week mostly because all academic papers I read on the subject were incomplete and some even contained very serious errors. Turns out I have no use for it in this game

Second was parallax scrolling, which turned out really nice. It fits today's games as well as yesterday's.

Third were shadows. Sure, jME has support for shadows, but not with so called planar geometries. My rider and bike are planar, as in they have no volume, since you never see them from behind or from ahead. Turns out this broke jME's shadows and I had to implement my own. No biggie, and jME can not support every feature imaginable. Planar geometries also enable a nice performance short-cut for stencil shadows, so the shadows in Mad Skills Motocross do not take much CPU power.

Game Engine Architecture

One of the most important decisions one can make at the beginning of a project, is on the architecture of the game engine. A game is full of objects (game objects) of various looks and behaviours. How does one manage all these objects? And what if you want that villager to start chasing women when he gets drunk? Do you remove the "villager" game objects and replace it with a "quagmire" game object? Or do you change the behaviour of the game object?

I chose to follow this advice: inheritance vs. aggregation. In short: Every game object has a list of components. The combination of these components defines the behaviour of the game object (and with behaviour I do not mean the AI). One component might make the game object turn towards the player's avatar, another component might move the game object away from bullets, and yet another might shoot whenever a friend is not in the line of fire. Now these components, and others, can be combined to give a game object a certain behaviour. The player's game object has a component that fires off a rocket when the player presses "fire".

What the hell has this got to do with motocross? Why would you need different behaviour combinations in Mad Skills Motocross? Answer: Nothing and I don't!

This is a classic case of over-engineering, I have no villagers that can get drunk or swords that can have "+5 bashing might of Blair". I have very few game objects: one track and four motorcycles with riders, a finish line and a start line. So far. I can still use my current game architecture, but it does not give me any advantages when coding this game. Maybe the next game will use it better

Art

Art is important for a game. I'll explain why.

I am doing this full-time now, I have put my measly savings and my girlfriend's patience on the line for this business to work. The keyword is business. I need to make a profit from this game, to be able to make any more games. Otherwise I would make the game multiplayer only, with my crappy art, and just play it with my friends. It would need no menus, no options, no instructions, no AI, nothing. I could have it done within a month or less.

Here's a hypothesis for you: An ugly game sells less than a beautiful but equally fun game.

Reasons in order of importance:

1. Stunning screenshots make more people download the demo
2. Beautiful graphics makes players more immersed, causing longer play sessions
3. Better overall scores in reviews, and greater chance of getting reviewed
4. Friends become more interested when players show the game to them

Hence, I need an excellent graphics artist. And I found one. His name is David Ferriz, check out his portfolio. I am very happy that David wanted to do the art for Mad Skills Motocross, I am confident he will take it to a new level. A lesser artist might have made "ok" graphics, but that is not enough. The gameplay is not "ok", it's brilliant, and so should the art be.

Art includes music. You cannot hear music in screenshots, but otherwise the reasons stated above hold just as true. But more about that next month, I've got to save something for the August diary. 

Next month

The next diary entry will be available on the 1st of August. And by then I hope to show some screenshots and videos with the new art, and with three computer-controlled opponents. Man, I can't wait.

I am planning for alpha-test in October, beta in November, and release in December. This might very well change though, estimating time in game development when you are only one coder is like a lottery. (UPDATE: This has indeed been changed, check the front page for release date)

Take care
// Tobias
Turborilla Entertainment

These diary entries are here for you, the readers. So I would like to know what you think, what you would like to see in the future, and any ideas and questions you might have really.

I have created a forum topic just for this diary entry: discuss here

Get the developer diary in your favourite news reader