So, yeah. Since June of last year I’ve been working on a little roguelike project on the side. Since development on rium has slowed down a bit over the last few months (for reasons not likely to become clear at the moment), I’ve really shifted most if not all of my development time into this project. I’m really enjoying it, and already have a long list of games in mind to make once this thing is baked a bit.
Wait… wha.. an engine?
Yes. I’m aware there are a number of roguelike engines out there. Yes, I know there are several game engines out there, with roguelike plugins. Reinventing the wheel, resolving solved problems, wasting time developing math when you could be developing games… Yes, I know… I know the usual advice, and I I’m very aware as to why I don’t totally agree with it, but that’s a subject for another post. One I may get into one day… but not today.
So, the Basics
Rendering
KRL is written in C# with an extremely flexible rendering backend. Currently, I’m rendering using OpenGL via OpenTK, with alternative rendering to XNA (FNA/Monogame). I chose C#, as it’s a language I’m becoming more and more familiar with (and enjoy). The backend rendering code is well isolated and extremely basic, rendering tiles from a tile atlas… so switching between rendering engines is a rather simple process. This was a high priority for the engine, and one of the first things I did.
KRL is solely graphic tile based… there is no terminal mode. I’m ok with that. Tiles are loaded from image files, whichare mapped via xml files (currently). Tiles can be re-loaded dynamically, allowing for switching between tile sizes, console sizes and tilesets at runtime. Experience (mine and others) has taught me that preferred screen and tile sizes are very subjective, so I have planned accordingly. This should also make custom tilesets rather trivial. Simply change the tile texture, and the glyph mapping XML.
One or more glyphs can be assigned to any created game object in one of several different modes. For each frame, you can define a glyph, background and foreground color. This allows for static glyphs (like dirt), animated glyphs (like water), connected glyphs (like walls) or state based glyphs ( like doors). The rendering side of the code takes care of the rest, dynamically assigning the correct glyph for the frame and state.
User Interface
KRL currently supports both mouse and keyboard input, though I’ll admit it heavily favors keyboard input at the time. As a lefty, a heavy focus was put on key mapping. Similar to the rendering, the basic mouse and keyboard capture are isolated, to keep them portable as possible. Game Controller support is currently not supported, but it is an interesting prospect I want to look into when I find a roguelike game idea that could possibly work with that control scheme 
For the main interface that the programmer will interact with, I went with a panel system. The UI is divided into seperate panels (KRLMapPanel, KRLStatusPanel, KRLLogPanel,etc) each of which can be controlled by their own separate input handlers, as well as be re-sized dynamically, either by relative or absolute dimensions.
Maps
Maps are divided into spaces, allowing terrain tiles, structure tiles, item tiles and mob tiles to be stacked into the same space. Each individual space also tracks it’s visible, discovered and lit status, which is handled by the renderer. Maps are structured and store in both a grid based fashion (as in a 2D array), as well as a grid based fashion (as in a grid). This, while minimally expensive in memory, can allow for some pathfinding and FOV algorithm optimization.
FOV supports multiple passes for lighting, as well as visibility. This I would image in pretty basic stuff, but the approach was to make it as simple as possible. Set an entity as a light source, and set its range, and the map takes care of lighting itself. Set a mob’s visual range, and it tracks it’s own FOV each turn.
Currently, maps support a static, XxX grid, or an pseudo infitite chunk based approach…
Mobs and Structures and Terrain and Items. Oh My.
Base classes exist for all these elements, which handle animation, collision, and lighting. Creating a new “one of these” TM is as simple as populating the type and the glyphs, or deriving off the base class, if you require overriding the FrameUpdate or TakeTurn procedures. All of these can be defined programmatically, as well as from files (unless you are overriding behaviors.. of course)
Scripting is something I really want to implement, but for now it’s taken a back seat. I’ve implemented Lua, Python and C# into a C# based engine in the past, but it opens up a big ol can of debug checking worms I’m really not wanting to get into at the moment. I have designed the whole engine with this possibility in mind, so when and if it does come, it shouldn’t be that big a thang.
And the fun little parts…
I love procedural generation. I have to admit I may have a problem with it. I’ve produced a number of procedural algorithms to produce dungeons, caves, cities and other things. I’ve designed my procedural algorithms to support a automatic, as well as a stepped mode. This, step by step mode has added a pretty handy way to debug and tweak procedural generation algorithms. I highly recommend it. It also allows for some pretty fun animations.
Along with animations, I’ve also added in an effect system, which can be easily setup as a color and a time.
Future Plans
The big plan is to debut this engine with the upcoming 7DRL challenge. If all goes well, I plan to opensource, or at least make available the engine for use to others. I’ll be honest, it isn’t a ‘secret’ or ‘money’ thing… it’s simple laziness. I don’t want to support an engine for me and you :P, I have enough fun keeping it working for me. Future plans are subject to change however…so as it matures, we’ll see how usable and maintainable it becomes.
As the weeks go by, I hope to update this section with updates to the engine, or a little more in depth into specific areas myself or others find interesting. Stay tuned!
Love,
Ross