RemBolo

Today I commited the 200th change to the RemBolo source code.  This also marks some milestones reached:

• Proof-of-concept for the game object model by implementing various stone types, figures and “immaterial” objects like rubber bands.
• Rooms (levels) can be loaded / saved from XML files
• Created a basic GUI for selecting level files

The GUI thing wasn’t that difficult at all.  The CEGUI library was easy to compile and integrate with the Ogre graphics library. It was fairly easy to grasp the basics from the documentation. Just as it should be.

The serialization (loading / saving of game objects) was another topic. If you g**gle for “C++ serialization”, you get an overwhelming number of “suggestions”. The idea is to let all objects handle their (de)serialization by themselfs instead of having central “load” and “safe” functions that need to know the details of all objects.  This is the way to go if you want an easily extensible code base. I already had a basic idea how to implement this stuff myself but I thought I would give one of these “serialization” libraries a try. Since RemBolo already uses boost excessively, it was only natural to try out boost.Serialization. I liked many things about it:

• Easy to add serialization to an object. Just one additional method and a few macro calls needed.
• Clean source. Serialization method can handle both serialization and deserialization with the same source without the need of conditions.
• Automatically handles serialization of built-in and standard types like vector, set, map.

What I disliked:

• Too much “macro magic” behind the scenes. Library source code is difficult to understand. This is propably true for any generic serialization library.
• The XML archive output is too verbose (e. g. using element text instead of attributes to store single values). Since one of my goals is to have a level format that can easily be editied by hand, this was a no-go.

I could have written my own archive plugin for boost.Serialization to get a cleaner output or try out another serialization library. But I decided it was not worth it. In the same time I could completely write my own serialization code and also learn from the experience. So I developed a simple serialization model based on inheritance. It uses the factory pattern for deserialization, boost.PropertyTree as the archive format. The code is propably not as clean as with boost.Serialization but easy to understand and customize.

Enough tech babble, some screenshots:

… about Bolo® can be found on this site:
http://members.chello.at/theodor.lauppert/games/bolo.htm

I like the b/w screenshot of Bolo on Atari ST. I’m especially proud of that I played this 1st version of Bolo on an original Atari ST. I didn’t own one but had access to one in a computer club when I was a child. I found the game very hard but fun and inspiring.
I need to get an Atari ST emulator soon!

Some more screenshots of the Atari ST version:

After roughly two years of silence, where other interests took precedence, I felt it was time to continue this project. Surprisingly, I’m again very motivated. Consider that the 1st time I had the idea to remake this game was more than 7 years ago ;-)

Since the last blog post I implemented the following:

• Created a framework for game object creation, interaction and linking between physics (Box2D) and graphics engine (Ogre). That was the hard part. Now it really is fun to create further game objects in the source code since they can easily be derived from the basic classes.
• Created most important objects Stone, Beater, Ball, Hole and their basic functionality.
• Stones can have associated overlay graphics for showing score or a special function of the stone. Implemented the “fixed” and “superfixed” state of the stone.
• Created all stone shapes of the original game.
• Implemented functional stone classes “HoleStateStone” (opens or closes holes) and “FixedStateStone” (fixes or unfixes other stones).

So far, the gameplay basics are done. Everything else is just a matter of variation of existing things and adding details (many details, of course ;-) ).
Overall I’m satisfied about what I reached.  There is still much work to do, but I’m definitely making progress.

Screenshots:

Finally, I’m making some progress with this “pixel shader” stuff. Basically, this enables one to do nice effects on a “per-pixel” basis, e. g. soft shadows and glass refraction effects. Though I find it difficult to comprehend I managed to create basic implementations of these two effects in a prototype (see the following screenshot).

This is so rewarding – to enter some dry and often frustrating program code that in turn produces beautiful eye-candy. I think this is why so many people are attracted by games / graphics programming.

There is a glass effect on the beater, which correctly distorts the image of the scene behind the beater. Though barely visible in the screenshot, it actually looks quite nice in motion.

Soft shadows are implemented using a simple 3×3 PCF filter. This looks much better than the hard shadows of the last prototype but the shadows still look somewhat “striped”, especially in higher screen resolutions. Variance Shadow Maps and screen space blur might be ways to overcome this – if I find enough courage to try and comprehend this stuff sometime ;)

Next step will be to create an interactive, playable prototype.  Integrating the physics engine should be fairly simple, judging from my experience with the 2D-prototype. Sound isn’t that difficult either.
I think most difficult (and interesting) will be to create an extensible object oriented game system that allows one to easily add more game objects and interaction bit by bit without the need of rewriting large parts of the source. Or at least make this refactoring easier ;)

Update:
- Added tinting effect to the beater shadow. You can see that the shadow caused by the translucent part of the beater is now slightly coloured to give a better impression of light falling through glass. This was fairly easy to implement.

I made some progress trying to recreate my 2D-prototype with the 3D-engine  Ogre.
The game actually will be “2.5 D”, i. e. graphics in 3D but gameplay still being 2D since all objects will be in a 2D plane.

It wasn’t that difficult to get Ogre up and running and create a simple scene with some basic texturing. I really like how easily you can define “material” properties with “material scripts” in Ogre and how everything fits together in a logical fashion.

Here is how it looks so far:

Everything you see is already rendered dynamically in 3D. There are 2 light sources (main light and back light) and dynamic shadows.
There is no interactivity yet (except the ESC key ;). And won’t be for some time as I’m still figuring out how to do various graphic details.
I’m planning to make some kind of glass refraction effect for the beater and definitely need soft shadows – they look too hard and distracting right now.

What’s so special about the original game compared to the thousands of other Breakout / Arkanoid clones?

• The beater isn’t restricted to horizontal movement at the bottom of the screen but can move around freely.
• The gameplay is based on an accurate physics model which allows for much interaction.
• The ball is not killed by falling out of the bottom of the screen but if it’s sucked into holes which can be scattered all over the screen.
• Many unique elements like rubber bands, magnets, flipper-like bumpers, wormholes, mines, killer disks, hammers, pincers, etc. that can be combined in nearly all imaginable ways ( click here for a complete list ).

More than thousand words say some screenshots I have just made by running original Bolo in a DOS Emulator (see previous post). I badly made it up to level 10 ;)

Note that the artwork is copyright by Dongleware Verlags GmbH.

Since the original game is incompatible with modern operating systems, we need a DOS emulator in order to play it and revive our memories. Be warned that you will only have fun with it if you know the original game or if you are a true geek who is into old computer games ;)

My DOS emulator of choice is “DOSBox” together with “D-Fend Reloaded” as the graphical front-end which makes it relatively easy to use and supports many other old games too.
With DOSBox/D-Fend I was able to play the game smoothly though the graphics look a bit grainy nowadays and the sound lags. But then I’m happy to have any sound at all – which is not understood if you already tried emulating some of the old games you grew up with.

Now on to the instructions (related to D-Fend Reloaded v1.0.0):

1. Get your hands on original Bolo. I assume you can find it on one of the “abandoned games” sites though you should notice that the game is still copyrighted by Dongleware and I don’t encourage you to break copyright laws.
2. Put all Bolo files into folder where you have full write access as standard user. This is an important step since Bolo creates temp files in this directory.
3. Download and install D-Fend Reloaded. It already brings the emulator DOSBox with it, so you don’t need to install DOSBox separately.
4. Extract these D-Fend configurations files into the main program folder of Bolo. Replace file autoexec.bat.
5. Start D-Fend Reloaded. Import the .conf file you have extracted in step 4.
6. Edit the configuration by selecting the Bolo game entry and clicking “Edit” on the D-Fend toolbar.
   Go to the “Drives” tab and replace the path “E:\Games\Bolo” with the actual path were your Bolo folder is located.
   
7. Click on the “Starting” tab to verify that it looks like this (if it contains a “mount….” line, remove the line):
   
8. To start the game in the emulator, just double-click on the Bolo item in D-Fend. Bolo complains about “DOS 6.0″ but that doesn’t matter. Just press any key on this screen to continue. You should see the main menu of Bolo then. From there on, anything should be pretty simple.
9. Have fun playing this “oldie” game!

As I already mentioned, the sound lags severe. If you can find a better sound configuration in D-Fend for Bolo, please leave a comment on this post, so me and other Bolo fans can have more fun with this classic game.

EDIT (2010/09): I updated the steps for v1.0.0 of D-Fend Reloaded and also added a hint about required write access of the Bolo folder.

I’m proud to present the first playable prototype version of Rembolo (see screenshot of previous post).

This version allows you to select between 3 levels:
Level 1 – Remake of Bolo level 1
Level 2 – Testing of balls connected with rubber bands
Level 3 – Testing of various stone textures

In-game keys:
ESC – exit current level
R – restart current level
C – toggle chain reaction mode
D – toggle debug mode (slow!)

Please read the license agreement before you download the  prototype.

The game doesn’t need installation, just extract the contents of the ZIP file into an empty directory and start “Rembolo.exe”.

Update on July 13:
- fixed minor optical glitches (clipped stone shadows, pixelated explosions)
- synchronized game frame rate with display frame rate to reduce CPU-load and fix sound stuttering

This is a screenshot of the current prototype. Thanks to the open source ClanLib SDK and the Box2D physics engine, it was possible to rapidly develop a working prototyp.

The prototype can already be used to play the first level of Bolo. Stones can be destroyed, holes will attract and kill the ball. Rubber-bands are working too. Everything interacts nicely thanks to physics engine. There are even some of the original sounds to hear when objects collide.

Overall, it already makes for some good “Bolo-feeling”.

Currently I’m thinking about ways of making the graphics resolution-independent. A few years from now, monitor resolution has probably increased again and I don’t want to recreate all the bitmaps then.

One way could be to use a 3D-Engine like Irrlicht or Ogre. 3D engines get resolution-independence by using vector data to describe a scene. This could also open new possibilities for some nice graphics effects.