Libtcod Traditional Roguelike "Engine"

Written in Python using libtcod (a computer console emulator library), this traditional roguelike engine has all the basic framework for a roguelike game. It's not a true engine in the sense of Unity or UE4 with a nice UI and a strong separation from "direct coding," but it instead has a framework that is easily hooked in to or built on top of. It is currently hosted on Github.

Summary

Partially based off of a tutorial (some of the code and usage of the library was very bad or very outdated), I created an engine suited for traditional roguelikes. It includes features such as a basic event propagation and handling system, menus, inventory, rendering and has a simple component-based entity system.

Video

Design

There's not a lot of actual mechanics design in the engine (I wanted to focus on the engine, not the games it could make), but there are a few implications due to it's roguelike nature.

First, the game is set up in a grid-based, turn-based environment. The player takes their turn and then the AI takes its turn(s). This gives the player plenty of time to think about their next move, which is especially important under the context of a roguelike game, where character death is permanent and thus, dying means restarting.

Secondly, all level content (such as layout, enemy locations, item location) are a product procedural generation. This means that the game will be different in some way every play-through.

Lastly, it does have the start of a general RPG style stat system. This was mostly implemented so that I could test combat and leveling. The combat is entirely deterministic, but that's an easy function to change.

Technical

Being intended as more of an "engine," the code is mostly framework and handling of very low level functions (like drawing onto the console). That being said, it still has a lot of interesting technical bits.

Shown above is the Entity class definition, with all of it's possible components. Normally when I write code architecture, I think in a more object oriented style. Wanting to try something different, I went with the component-based model for this project. It has a couple of advantages, the biggest one being that it is very easy to change an Entity's components at run time and it cuts down a lot on having many different classes for each possible combination of use-cases.

Overall, a component-based system is far more robust and dynamic, which is really helpful for game development as games tend to change a lot they're being developed, nothing is really ever set in stone.

Above is a snippet of the extraction part of the event system. It makes use of a python dictionary (key-value pairs like a map) and new events are "appended" to the dictionary and extracted between turns, their results processed by their respective handlers. The best part of this, at least in my opinion, is that it helps keep code out of the input handlers (which uses a more libtcod based event system), keeping those much, much cleaner than they could be. This method is also very expandable, allowing new events and event handlers to be easily added.

Lastly, we have the targeting system code. It that isn't really super important to the engine's features, but I am oddly proud of it. This snippet grabs all viable entities within range, sorts them by closest to farthest and then allows the player to cycle between them. The cycle is accomplished in a simple way: pop the next entity off the top of the list and set it as targeted and then stick it at the back of the list. This makes the actual cycling process very painless and quick.