Skip navigation

Tag Archives: physics

I wanted to start typing down some things as notes I’ve learnt during the development of Freekick until now before I forget all about them. The first article in the series is about one of the most important things that are different between Freekick and my previous hobby projects: modularization in software.

I first started to understand the importance and the benefits of modularity as I read the great book “The Art of Unix Programming” by Eric S. Raymond, a book I can recommend to every software developer, even those who’ve never used or programmed on Unix. Lacking modularity in my programs was the biggest reason why I had to abandon them sooner or later – I’ve ended up in such horrible situations where tweaking the AI creates a bug in the main menu, for example.

As mentioned in the book, managing complexity is one of the most crucial (and difficult) jobs when developing software. Basically, as long as you can simplify the tasks of the software into more and more smaller, simpler sub-tasks, and organize them so that you always know which parts of the software should be talking to each other and how the talking is done (interface design), you have no problem. If you lose the overview half-way to the project but go on writing code, you probably won’t get it finished.

From a developer’s point of view, some programming languages encourage designing the software top-down, always breaking problems into smaller pieces, and then implementing the software bottom-up. I take FORTH as an example, in which it is near to impossible to write even slightly complicated software without designing it thoroughly in a top-down fashion first. Most languages, such as Java or C, don’t really force you to manage complexity in any way, but merely provide you with the tools.

There are a lot of ways to bind all your software components so tightly together that there’s soon no way to take them apart anymore. One way is having a so called “god class“, a class usually aptly called something like “World” that ends up having most of the code in the project. Other popular ways include global variables, static variables or simply functions that are 1000 lines long, with multiple static variables that are conditionally used for different purposes in the beginning, middle and end of the function. Here are some small hints how such misfortunes can be avoided.

One thing to keep in mind is that each class, function and module should have exactly one well defined task to do. When I put it that way it sounds almost trivial, but it’s still sometimes forgotten. Another problem that I often see are confusing interfaces: when designing the interface, don’t have functions InitTaskX(), BeginTaskX() and StartTaskX(), where StartTaskX() internally calls InitTaskX() and BeginTaskX() in sequence. Instead rather decide on one option that the one using the interface will need (even when it’s “future you” – in a few weeks you’ve forgotten what you meant with all the weird functions anyway) and stick to it.

Another thing I wanted to use to increase modularity in Freekick was to split the whole application in multiple processes. There’s one process for doing all the non-soccer-match stuff – menus, league tables, transfers, etc. and other processes for the actual match. When the main menu process starts a match, it creates an XML file for the match server, then starts the server and passes this XML file to it, then starts the other match-related processes (client and AI). This allows me to be 100% sure that I can change anything in the menu part of the application and not break the actual match, as long as I don’t change the XML file which serves as the interface between the two.

The server itself handles the physics, rules and the match state, while the clients display the state received by the server and send user input to the server. As a nice bonus adding multiplayer capability is relatively easy, even though it was something I hadn’t originally planned. Another positive thing about it is that I can use different programming languages for different processes; I’m currently writing the menu part in Python and the actual match part in C++. There are also more sophisticated libraries for accomplishing a similar task, such as D-Bus, but I felt it would’ve been an overkill for this one.

As for the server and the clients, they communicate over a simple, clearly defined Freekick protocol that works over network sockets. This allows me to change the way the client displays the match, for example, without me being able to break the functionality in the server. In Freekick, the AI is a client as well, which allows me to reuse much of the client code while still having clear limits on what code belongs to the client that the player sees, what is only relevant for AI and what code is used by both of them.

Splitting the game into a server and a client is what FreeCiv did as well, by the way. That’s why there exist multiple clients for FreeCiv that do the same thing but look different. Freekick has two clients now as well, one that shows the match  in 3D and another where all the graphics are text based, using Curses. In the end they both same exactly the same soccer match with the same AI, logic, state and rules, only the way of displaying it and receiving input from the user different.

As for the internal structure of the server itself, I’ve also tried to keep things as independent from each other as possible. There’s the Physics class, which is a facade to the whole physics subsystem. Then there’s Rules, a class that is responsible for calculating the changes in the current rules status of the match. Physics can be subscribed to, implementing the visitor pattern, and is subscribed by Rules. Rules receives all updates from Physics (where the ball is at the moment, which player touched the ball, etc.) and updates the rules state correspondingly.

Rules can be subscribed as well, and both of these classes are subscribed by Dispatcher, a class that sends both kinds of updates, rules and physics, to the clients. How does Dispatcher know who the clients are? There is the class ServerManager, which accepts incoming connections and adds them to the list, which the Dispatcher has a pointer to. There are also classes ClientEventListener that receives the input from the clients and InputMonitor, which validates the data before passing it on to Physics.

Freekick is using Bullet for physics simulation. While Bullet is an excellent library, I can’t be sure Freekick will be using it forever (who knows what kind of open source physics libraries we have in five years). To make sure the physics engine can be exchanged in the future as easily as possible, I wrote an interface that should correspond my needs and no more – functions like addStaticObject(form, position) and simulate(timestep) – a wrapper. The interface is then implemented by the BulletPhysicsEngine class using the sometimes not-so-clear Bullet interface.

These are some ways to add modularity in software – of course, there are more and maybe better ways to do it, but these have made it rather easy for me to continue implementing Freekick, even as the code base has gotten bigger with time. For the interested, the Freekick code itself can be browsed here.


Time for a small blog entry again. I’ve been going through the Ogre tutorials and after feeling more confident with the whole graphics rendering I decided it was time for the next step: integrating physics with the graphics. Ogre lets (or, as the critics put it, forces) the developer choose a physics engine suitable for his needs. I checked Wikipedia and the Ogre Wiki for some available engines and came to the conclusion that I’d have to choose between Bullet and ODE (I’d rather avoid commercial and closed source engines). Being impressed with the ODE documentation and the list of ODE users, I decided for the latter.

There are wrappers between Ogre and physics engines that make the life of the developer easier. The problem with integrating the two types of engines is basically that both Ogre and the physics engines have their own formats or classes for basic mathematical elements such as vectors, degrees and matrices and the wrapper has to convert them. Moreover, things like the Ogre timing system, nodes and entities have to be integrated with the physics engine. Since OgreODE, the ODE wrapper for Ogre, does not quite describe its functionality with as much detail as ODE I thought for a moment about just skipping the wrapper and using ODE directly with Ogre, doing the aforementioned conversions by myself – but after seeing the work needed I decided to go for OgreODE after all. The source code should be enough documentation anyways… Right?

After messing around with OgreODE a bit and trying out a couple of tutorials it does seem to work pretty well after all. My first test scenes involved the typical boxes bouncing onto the floor and each other, but soon I wanted to go and try out some physics that would really be useful for my game project, namely rag dolls and dynamic (procedural) animation.

I’ll explain quickly what dynamic animation is. First of all, there’s a nice video showing the technique at Youtube (link), the original thread at Ogre forums can be found here. (But don’t click on the links if you’re arachnophobic…) Basically it means the movements are not preanimated but calculated physically instead, and the characters move their joints themselves by applying forces on them with their muscles. This may sound complicated, but in the end it’s just a rag doll with enough intelligence to move itself. They can, however, be hugely flexible and can do anything without making the player feel bored. In other words, a character can really interact with the surrounding world with its limbs, i.e. when a soccer player gets tackled he falls realistically based on the angle from where the tackle came instead of simply doing a preanimated sequence.

The flexibility that dynamic animation offers is not the only reason I want to implement it. As some well known developers have said, a good developer has to be lazy. Manually animating all the sequences that a dynamically animated character is capable of would be way too much work. On the other hand, if only x animation sequences were to be animated, like a few sequences for the kicking, jumping and tackling actions (which would already be a tremendous amount of work), it wouldn’t really be any easier nor less work to make that look realistic in a soccer game than with dynamic animation. If I teach the players to do the actions with their muscles instead of animating them, I save the work on animating the falling down sequences (I just let them fly over as they simply follow the laws of the physics) and instead of doing the animation the traditional way I have to define the forces, vectors and angles for moving the bones and the joints, therefore having a lot of mathematical work instead of artistic work (after all, I’m a programmer, not an artist, and when in doubt, stick with what you can, right?).

The only problem with the technique is that there isn’t really that much reference for me to look for. There are a lot of scientific papers written about it (just google for procedural animation) and some code as well, but since I haven’t (yet) found anything about it for Ogre or Ode, it seems like this will be my first test to see if I’ve learnt enough about the APIs to create a solution to a “real” problem. So in the next few days (weeks, months?) I’ll be going through the theory of procedural animation and try to come up with a way of combining the Ogre meshes with ODE joints and motors to create a real, dynamically animated character.