#code examples

A Slightly Smarter Minecraft Server Notifier

So our initial notifier messaged us when players were on our Minecraft server, but it always messaged us, even if we already knew there were players online.  That’s not brilliant.  Instead, let’s have the script create a little file that says there are players online.  The pseudo-code then would be:

if the .players file exists and isn’t empty check if players are still online if they aren’t, clear…

In this post, I'd like to talk a bit about the architecture and the various frameworks used to create our engine.

I mentioned in a previous post that I've read "Game Engine Architecture" (once again, highly recommended read). From that text, we took some ideas and applied them to our engine, mainly making the engine modular and implementing a component based entity system.

At first, let's look at a high-level diagram of the engine:

The topmost layer is the overarching engine. It handles initialization, entity-management (more on entities later) and manages the gameloop (to a certain degree, more about that later).

The second (organe) layer shows what modules we implemented. The modules are separate from each other, each implenting another library. This also adds the advantage that we could swap any library with another one, for example swap BULLET with Newt or something similar.  The only expection to this rule is Ogre3D, since that library handles more things than only graphics.

As promised, I'll talk a bit about each library. I'll talk about Ogre3D in a separate post, since that library is a bit deeper integrated in our engine.

Physics: Bullet

For simulating a marble in a maze, the player need to be able to accurately predict where the marble will go if he tilts the board. As such, we need a physics engine. Bullet is an open-source engine that is widely adapted by both the game- and the film-industry.  

Bullet was easy enough to get into the engine, but hard to acutally work with. Personally, I found it very unintuitive to program for, it seems to favour a more sequential programming style, rather than a object oriented one. You have to implement your very own callback methods and keep track of previous physic states yourself. This worked out in the end, but we weren't exactly happy with the end result.

Audio: SFML

Instead of using the raw OpenAL library, we decided to use SFML. While the SFML offer plenty of possibilities, the only thing we used out of it was the audio module. We implemented the whole system in one day, with fully working 3D sound. This was a blast to work with, SFML is one hell of an awesome software library. If you can USE IT!

GUI: Librocket

We searched relatively long for a suitable GUI library, going through CEGUI and several others. None of wich made us really happy. They were either to big or to "obfuscated" for us to learn, since we added the GUI near the end of the project.

When we first learned of Librocket, we were excited. A simple GUI library,  working on HTML and CSS? This was our chance. Looking back, we have mixed feelings. When we finally got it to work (took us about 3 days), it worked as promised, but it seemed like quite a hassle. Anyway, it payed of in the end, so I'm not complaining (that much).

Input: OIS

The object oriented input system was our day one choice for handeling input, since it pretty much comes bundled with Ogre. Not that this is something bad, this library is really solid and intuitive to work with. Overall, not much to say about this, I can recommend it.

Wrapping up