IOTD: Particles at work!
Particles at work!, by The Master
Early 2013 saw a change from using TileStudio - a simple tile editor with limited capabilities besides a very useful ability to define your own file format. I did some searching and found Tiled. This made TileStudio look like a plastic tricycle compared to a roaring monster truck. It allows multiple layers, multiple object groupings, context-sensitive tile placings (properly creating a boundary between grass and gravel, without you having to select the tiles manually), and it's XML-based format allows you to insert objects of any type having as many properties as you like. This was exactly what I wanted. I used an open-source library to load Tiled XML files, courtesy of Tamir Atias, although I will probably write a map compiler when I've programmed all the features I want.
Throughout 2012 I had to do a lot of Python programming. One thing I found really useful was it's dictionary function, which is similar to STL maps. Except the former can have any type as a key and value. I wanted to have that kind of functionality in order to pass configuration parameters to objects (I'd save me having to call setters and getters, and would also allow me to load configurations from files). I was able to use the Boost Utility Library, which contains a Variant type similar to the one found in QT. This allowed me to create a Parameter class capable of containing many different kinds of data. Combining this with an STL map allows me to create functionality similar to Python's dictionary. I even made it so Parameters could hold lists of parameters within them, creating nested lists. This has become an extremely integral part of my engine.
I've had some sparse experience with QT, and I really like the idea of using signals. In fact I had an idea for an OOP language completely driven by signals, which could be used to intuitively create powerful multithreaded software. I didn't do that here. Boost also has a signals and slots library, which I employed in the engine. Objects (like NPCs, etc) can connect slots and signals to other parts of the engine, and listen for triggers from other objects. An example of an application is that I could now encapsulate input into a singleton class, and have it fire signals for each input event. Then objects in the game like the Player can subscribe to these events. All of it functions quite intuitively.
All of this came together with the Lua interface. Using parameter lists, I can transfer Lua tables to and from my engine, allowing complex data structures to be modified by scripts. Configuration lists can be uploaded from a Lua script for, say, a battle. Moreover, scripts can easily be resumed by having the script connect to a signal to be fired when the behaviour it's waiting for has been exhibited. For example, the player making a selection in a list or an NPC reaching a destination on the map. In earlier incarnations of the Marduk engine, this was extremely difficult to program, and Boost has made it so much easier.
I'll say, I've had a lot of fun working on this incarnation. With a few more tweaks and further testing, I can declare the over-world component complete, and begin building the database facilities on top of it. I think I'll use SQL for it. Once that's complete, then comes the battle engine. With enough testing, the engine will be complete!
Then I have to get motivated enough to actually create an RPG out of it...
- Paul whoknows
Oh very nice!
This section is only available to registered Allegro.cc members.
:: Join Allegro.cc
The Gallery | Add your own image!