En voilà, we have a graphical level editor!
Well, it’s still in an “early alpha” phase 😉
So far the following features are working:
– Select a game object from a list of all objects.
– View the properties of the object.
– Modify the properties and update the object and its graphical representation accordingly.
Although this doesn’t sound very impressive, it is the proof-of-concept that really counts here. The editor code is currently only 350 lines long but is already able to edit 16 kind of different game objects. There isn’t much more code in the game classes to support this.
What I have learned from RemBolo’s big sister, is that a standalone editor doesn’t work out well, especially if done as an afterthought. It would always be outdated compared to the actual game and it would be a maintenance nightmare.
So I’m taking a different approach here where the editor will be integrated into the game engine from the beginning. A big enabler for this is the CAMP C++ reflection library. It basically allows the editor to stay completely independent from the actual game classes. Once the editor “knows” how to manipulate the basic type of properties (e. g. integer, float, string, bool, enumeration and so on), it will be done. We can add any kind of additional object classes without having to touch the editor code again!
I’ll write about how this kind of magic works in one of the next articles.
Have fun and keep coding!
I just found this relatively recent interview with the father of Bolo, Esprit, Oxyd and other Dongleware games:
Among others he talks about the old “Atari ST” times, when games where not a big market yet and that he was propably in the wrong time at the right place. Though he also thinks positively about these times, that he actually made a difference with his games. To which I absolutely agree!
That’s great to hear as there are many stories from developers of remakes who got troubled by the original game developers/publishers even decades after these games were sold.
Soooo…. I just want to let you know that this project isn’t dead 😀
Some things that motivated me again:
- Visual Studio 2013 Community Edition available “for free”
This is really exciting as this version replaces the express editions but feature-wise it is equivalent to VS 2013 Professional! Looking forward to VS 2015 Community Edition with more C++1x features.
- Discovery of a nice C++ reflection library called CAMP (also on Github).
- Discovery of YAML – a very neat configuration file format as a fat-free alternative to XML or even JSON. There is an easy-to-use C++ parser for it.
I’ll write more about how I use CAMP and YAML for game development in the next article.
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:
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.
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 😉
– 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.