Elementum is a turn-based strategy game which gameplay is greatly inspired by the discontinued game Etherlords. As a multiplayer game, players will be creating a Hero of the Elementum to fight with, who will engage in an extensively rich featured combat system by experimenting with and customising Decks to carry out strategies, draw and cast unique spells, summon creatures to their bidding, and master the elements!
Elementum is an open-source project, written in C++, and deploys open-source, cross-platform technologies:
- Ogre3D for rendering
- CEGUI for UI purposes
- OIS for input management
- RakNet for networking
- TinyXML for XML parsing
- OpenAL for audio processing
- LUA for scripting & events
- tolua++ binding generator from cpp to lua
- PostgresSQL for the backend database
- pqxx for C++ / Postgres binding
- log4cpp for logging
The project is aimed to be released in native ports for Mac OS X, Linux distros, and .. Win.
Latest Updates
March, 13th, 2010
Just done one FAT git commit, god this has been some week! I'm proud to say that I've implemented a fully functional, tailored to my very far needs Event Module that's flexible enough for the game. The code isn't so pretty given the exotic nature of RTTI in C++, but hey, it works!
The way it works is, there is an Event Manager which serves as a centralized spot for generating Event instances and releasing them. But the Manager's job is a lot more than that; most importantly, it has the processing queue for events to be dispatched. The manager maintains a list of "subscribers", modules that are interested in a certain type or category(family) of Events, called Event Listeners. Listeners act as a layer of abstraction between the Manager and the actual Event Handlers, the methods that will do the actual processing.
The actual process of dispatching is a bit tricky, though. Event processing queues are maintained in two layers: first at the Manager which simply dispatches it to all subscribed Listeners with no interest of their return values. However, once a Listener is notified of an Event, it pushes it into its own queue, which will finally feed its registered Handlers. Handlers are mere references to actual methods of the class deriving from Event Listener; prior to transmitting events, the class has to "bind" a method to the desired Event / family (think SLOTS / signals).
Now, an event residing in the Listener's queue will not be discarded until all Handlers inform it that they're done. When they are, the event is removed, and the next is tracked for processing.
Events themselves act as a smart pointer, in a way; they are called for destruction internally by holding a counter that tracks how many Listeners are actually processing it. Once the counter hits 0, the event calls the Manager for destruction.
In a Client-Server game as Elementum, where basically every action in the game has to originate and be processed by the Server, Events are defined under two "types": REQUEST, and RESPONSE. When the client takes an action, an event of type REQ with minimal info is "hooked". Upon dispatching, the Manager probes the event for its type, and takes a special action in the case of a request event; it bypasses all the originally subscribed Listeners, and instead notified the sole Network Manager (which is a Listener on its own). From there, the NetMgr "packetifies" the event and ships it off to the Server.
Server-side, the opposite happens, sorta. It parses the event out of the packet, then hooks it into the manager. However, this time the Manager will see that it has no network dispatcher (since this is the server, it needs no requests) so it passes the event on for handling. Once handled, the event is bundled and sent back to the Client.
Client-side, the Network Manager picks the packet up, parses the event and modifies its type to RESP, and finally hooks it. From there on, the event gets dispatched and processed by each subscribed Listener.
March, 2nd, 2010
Integrated the original Event module I had created last year for my first game, but eventually I had to strip and modify much of its functionality. The way it worked was through registering handlers directoy for each type of event, and the EvtMgr would be the one holding a premade dummy instance of these Event objects in store for the engines to manipulate on demand. That raises a few concerns, what if more than component request the same event and modify it at the same time? Even, what if two instances of the same evt are to be triggered simultaneously?
With the new design, I'm implementing a trigger-hook-dispatch paradigm, where the components interested in Events register to the Manager as EventListeners, they create the event object they need, then "hook" it to the Mgr's queue. Once the Event gets its turn, the Manager dispatches it to all registered Listeners.
Now the Manager isn't responsible for which handler handles what, for all it knows, it has Listeners who are interested in all Event-derived objects.
Once the EvtListener is notified of the event, it takes care of the handler looking up for the passed event, then calls them respectively. Should there be no handlers subscribed to that type of event, the message will simply be discarded.
It sounds alot cleaner to me, since the logic is now decentralized among the manager and the listeners, so I'll be getting to implementing it this week.
February, 28th, 2010
Built the NetworkManager for use with RakNet, now I have a wrapper for sending and receiving BitStream packets. The connection between the client and the server is now made!
Off to creating the Event module now, then connect it with the NetMgr, once that is functioning, I will be ready to get my hands dirty with the real thing!
February, 26th, 2010
Integrated Luabind with my existing UIEngine and CEGUI's lua scripting module (they use a modded version of tolua++) .. created binders for some methods and now that i see it works, I'm not certain that I need this really. I'm going to go on without Lua for a while, and see if I change my mind later on.
February, 24th, 2010
Integrated log4cpp, tailored a nice layout for the logger.. now it prepends messages with their corresponding class, useful and "mainstreamed".
February, 21st, 2010
DBManager now supports creating, updating, and loading player Profiles! Profiles are also linked to Spells and Talents, and a Matches table is set into the schema for tracking players' wins & losses. Yummy.
February, 20th, 2010
Set up a PG database on my remote server, integrated libpqxx and created a DBManager that connects and performs queries!
February, 19th, 2010
Revisited my feature plan, and took another look at my design. I've revised the roadmap, and now have a more solid plan in motion. I'll be setting up the Network Manager, giving Boost ASIO a shot, so let me see how that goes!
Update: It's very late now, and I ended up changing my plan regarding using Boost ASIO for networking; I don't get the point really, it's supposed to be a library that provides a higher level API to networking, while I genuinely found it more complex than writing Berkley sockets directly -.-'
I'm giving RakNet a shot right now, and after having to modify some code to get it to compile under Mac, it's looking great. Good documentation, a few tutorials included, and the interface looks clean enough. I've successfully set up a server and a client instance in a very short time, I'm satisfied.
February, 17th, 2010
So, after an overhaul of the UI layout flow system I had earlier, I have now properly contained the flow between the UISheets and the UIEngine … GameStates only have to interact wth the UIEngine, prompting it to toggle the first sheet in the chain, where it gets handled externally from there on. I like it.
There's a glitch though; the case where UISheets have to handle external data (e.g profile creation sheets have to modify a dummy Hero object for dumping), they are forced to interact with the running GameState.. which is, to an extent, defeating my design. I know what I need, I need a shared, globally accessible - and by global, I mean scope of the sheets - resource space for data manipulation by these models. The UIEngine might be the place for the job, but then it'd also be handling objects out of its scope. I'm not sure.
The Hero parser module is now functional; it's handling the parsing and loading of Hero object resources. Although this is the point where I think I must take a further look at things, because it might be obsolete; if I end up storing profiles in a DB, the module will have to be entirely revamped.
So, in an overall glimpse, I have the Intro state now fully set, except for the Spells & Talents assignment. These will have to wait until I'm certain of how I'm gonna be handling events (LUA scripts vs C++ based event handler). For now, I'm safe to start working on the server and the networking involved between that and the clients.
Boost ASIO, ir INC!
February 14th, 2010
It's real design time! I'm going to spend as much time as needed to get everything written down; the framework, its components, how they relate to and interact with each other.
Once I'm done with the design documents, I'll be starting from the grounds up with a clean and fresh head-on! I'm likin' this.
February 13th, 2010
Heroes are here!
A simple and sweet XML object parser module is now in motion. Hero "Profiles" are dumped onto a very vulnerable XML sheets and loaded on choosing from a very sexy list of Profiles in the Prep scene!
I'm not really fond of the XML lib I'm currently using though; tinyXML. It gets the job done, but its interface isn't all-elegant. A shiny alternative would be Poco's, since I'll probably be off using their Net module, might as well adapt to their XML as well.
Units and Spells will be parsed in a similar manner, although it's getting into my mind that a need for an abstraction layer is needed; if later on I decide to drop using tinyXML, I'll be in for a lot of refactoring. Might just as well spend some time into writing a unified parsing interface and spare the mess.
The Resource Manager is also on its way: in earlier revisions, I had no central module that regularizes object loading & creation.. obviously, there are many reasons for such a module, but the question is, am I better off writing another layer of RManagement (since it will have to load my data along with OGRE's / CEGUI's and who knows what else to come) or should I be off using OGRE's…
February 12th, 2010
CEGUI is now integrated perfectly, it had been such a hassle tackling with CEGUIOgreRenderer under XCode; CEGUI now (post 0.7.1) lets OGRE handle the image processing using its underlying library instead of external ones (eg. SILLY), however, for a reason beyond me, OGRE's ImageCodec would keep rejecting any image I pass through, even the Samples images that come bundled.
I digged deeper into the code, and found out the problem was being produced on CEGUIOgreRenderer's side: the OgreImageCodec module only accepts two formats of images: PF_R8G8B8 and PF_A8R8G8B8, yet all the images I could produce / get my hands on had a format of PF_A8B8G8R8. I know they are compatible, so I added my own formats to their processor, and voila, it works.
I'm not sure if it was me missing something, or it's an issue on their side, I'll have to contact them soon over it. For now, it works. But I'm sure there's some hidden glitch that will haunt me in the future over this!
Created CEGUI layouts for preparation stages:
- Name & Race
- Stats
- Deck (placeholder)
- Talents (placeholder)
Deck & Talents stages will be created once the game objects are introduced.
February 11th, 2010
Still struggling against getting OGRE to build / link properly… the so-dreaded segfault @ shutting down threads isn't going away. I'm almost sure the problem originates somewhere in compiling OGRE with POCO's threading library. I've re-built the packages over 3 times with different — and should be proper — flags, yet still to no avail.
Update This has taken too much time, I've eventually removed POCO libraries support entirely, and who would've thought, everything works now. I can render an empty, black window and SHUT IT DOWN now.. segfault-free ! zomg!
Too much for a day, can't wait to get on speed with actual development come tomorrow! I never thought I'd say this, but the design of a software by Apple is filling me with hatred, XCode sucks! For n00bs, at least.
