Towards a Roguelike Framework

Its been a long time since my last post, but real life and Dota got the better of me. Fortunately I deleted Dota for the 3rd time, I just can’t stop playing that game without deleting it, and now I can carry on with some game development.

I have been playing around with field of view algorithms and settled on using recursive shadow casting for now. I got my little @ running around in the random dungeons having terrain light up as I go.

Next I started working on a framework for a roguelike. My goal has always been to design a framework so that I could easily swap out dungeon generation, FOV, and display targets i.e. console vs graphics.

This is of course easier said than done. I find it difficult to make such design decisions in the framework without the knowledge of what it would actually take to implement a specific feature in reality. And I don’t want to implement a set of features using a flawed design. (Of course no design is ever perfect.) Damn the need for perfect architecture without perfect knowledge.

My current game loop makes use of the GOF strategy pattern instead of a switch statement. I’m hoping to encapsulate each game state such as Welcome, Character Generation, Town and Dungeon into a different strategy implementation. The game loop will then just defer to the active strategy to do some processing, pass the strategy to the active renderer to produce the output and then retrieve the user intput from the active input handler and pass it on to the active strategy.

Input is quite easy to abstract as its just a mapping of the active input handler for example the .NET console to some form of generic command that can be passed to the active game strategy for processing. The game strategy/state then receives the input as a generic command for example ChangeDirection and acts upon it. This command could have come from the Keyboard, Mouse, GameController or even different key strokes in case the user customized the keyboard to command mappings.

Rendering has proven to be a bit more difficult. Firstly, the .NET console support is really limited. The amount of colours supported is very limited (this can be overcome by making some win32 API calls) and its just plain clumsy. I am also uncertain of what game information should be available to the renderer and whether it should be a completely generic implementation (per render target) or a specific implementation per render target per game strategy/state.

I started off with a generic implementation using a console render target and quickly found it to be lacking. I am currently playing around with a graphic library to see what it would take to convert the game information to graphical representation. The idea is that the experience of both styles of output will give me enough information to do a more general design that supports both cases.

That’s enough rambling for now. Any comments and suggestions would be most welcome.


One thought on “Towards a Roguelike Framework

  1. For my roguelike. I use the Strategy pattern for game states, combined with the Command pattern for guiElements. Works far better than horrible switch statements, and allows me to easily add mini-games 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s