NOTE (14 AUG 2010): ROAR Engine is now known as GORE – Graphical Object-Oriented Roguelike Engine. See this post for clarification.

As mentioned in my previous post, I’m using my own homebrewed pygame-based engine called the ROAR (Rapid Object-Oriented Awesome/Adaptable Roguelike) Engine. It’s awesome. I know. :smirk:

Anyway, I need to heavily refactor the engine to achieve a more decentralized architecture. Right now, rendering of entities are done by the SceneManager, which handles both logical and render data of all entities. This means that pygame code is splattered all around the SceneManager, and inherited into entity subclasses, making it difficult to switch libraries in the future, which I fully intend to. Also this kind of coupling makes it difficult to port over algorithms from this engine to another engine, which kind of make the point of building this 7DRL moot in the first place (since this project is meant to eventually serve as my prototyping ground for code to be implemented in my commercial project – Splintered Core).

Therefore, here’s what I need to change:

I’ll need to split the current SceneManager into two portions: SceneManager and SceneRenderer. SceneManager will hold all entity data and perform LOGICAL operations on them (e.g. calculating an entity’s field-of-view is a logical operation, while rendering the fog-of-war based on the entity’s FOV is a render operation); while SceneRenderer is called after all updates have been done on that particular frame to render the results of the carnage.

This means that SceneRenderer and SceneManager will both hold a set of entity data, with the former containing render information and the latter containing logical information. This doubles the memory usage of the game, but at this stage the RL is pretty lightweight by itself, so I guess this is a drawback that I can manage.