Sign in to follow this  
  • entries
    10
  • comments
    3
  • views
    9041

WynterStorm - Engine Layout

Sign in to follow this  
zerotri

355 views

As I noted in my last entry, I want to use this article to describe the way I have been laying out code in WynterStorm and the different libraries it is broken up into. I've found that I am horrible at code documentation and because of this I have tried to somewhat combat this problem by organizing my code out quite strictly. WynterStorm is broken up into the following parts:

Crystal - Crystal is the lowest layer of all of the libraries. It contains code that is meant to be compilable on most any system with a modern C++ compiler. It contains basic primitive structures, memory management, rtti helpers and event handling.
Shard - Shard is the operating system compatibility layer. It contains code for initializing the application, creating windows and processing system events.
Shade - Shade is the Graphics API layer. It handles anything related to actually displaying graphics onscreen, with the exception of updating a window's contents upon rendering.
WynterStorm - Contains common game code to the engine. Game State mechanisms, base Entity classes, etc. will be stored here.
Game - Contains any game specific code. This is for anything that extends base WynterStorm classes or should for may be specific to a single game (map loading, battle system code, etc.).

These parts are all stored in the wynterstorm/ directory, each in their own directories. These directories then each contain a include/ and a source/ directory for splitting .h and .cpp files. As development matures I may choose to split code by task rather than by type of file, but for now this layout works.

Along with these parts, the WynterStorm engine also relies on some external library code, stored in lib/. The libraries in use currently are SDL, Trefall's Component/Entity classes, Efficient Delegates in C++ and Simple OpenGL Image Library. I also plan to use Freetype for font loading, and libRocket for the heavy GUI lifting.

As for scripting I've been deciding between Lua and v8 for scripting. Lua has the advantage of running in most places I need it to while v8 offers the speed and easy integration that I enjoy. Google's v8 however does not currently run on iOS and because of this I am not yet willing to commit to it as my scripting language of choice.

I've also been looking into how to handle Component/Entity templates. In most of the engines currently using them I've seen primarily XML for defining the templates but I've found this way to be rather cumbersome(may not be the right word I'm thinking of). XML code requires more text than should be necessary for defining the templates and ends up making the properties harder to read and write. Some people have turned to using Lua for this. I've become very interested in using CSS for this, minus all of the web-specific properties and attributes. For that, I have discovered this library, which has minimal requirements (two Boost headers, which I should be using anyways) and seems to have a fairly nice API. The one downside is the LGPL license used, which may inhibit the development of commercial games. I'll have to look into this further.

What does Gamedev think about any of this?

Thank you for your time,
-Wynter Woods

EDIT: I feel a bit retarded. libRocket provides a very nice interface for using stylesheets. It is very likely I can just use this outside of GUI code to achieve what I need.
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now