September 2009

New Sourceforge site!

This is the last post on this blog. All things pertaining to RogueRunner will be available on the new Sourceforge site at:

RogueRunner on Sourceforge

The new site has the development blog plus downloads and a forum, so make your way over, register, and join the RogueRunner community!

|

Input and User Commands

I just finished implementing the system for handling user input and commands, and I must say that I'm liking how it's turned out. Some of it was planned, some of it I had no choice, and some of it felt like a hack but turned out nice.

The first thing I had to deal with was user input on Windows. Since I'm using the Win32 API, I decided to get my input from WndProc and that the best thing to do would be to queue up all input as it came in, then have the game poll the input queue whenever it needed user input. So currently, my game loop infinitely run, and each time around, the game logic allocates energy to objects and gives turns to objects with enough energy. If the player has enough energy for a turn, the game logic polls the input queue. If there is no input waiting, the game logic exits out, and the loop continue until the user HAS pressed a key.

The game logic then takes action based on the key pressed, and code for all sorts of commands gets called. Sometimes the command doesn't actually use the player's turn, so the game logic continues to poll for more input, until the user actually does something that uses up their turn. Energy is taken from the player, and the whole process starts over.

I really like how Crawl takes multiple turns to do certain things, like puting on and taking off armor, eating, etc. To make this work under my system I hacked in a sort of internal command queue to the game logic. If a user command takes multiple turns, fake user input along with helper parameters are placed in an internal queue that gets polled just before the real user input. The internal queue gets consumed first, and things happen automatically without the need for the user to explicitly tell the game to do them.

For example: If you try to put on a helm when you already have one on, the game simply queues up an order to take off the current helm then put on the new one. If you try to put on heavy armor, the game queues up the command internally along with a timer parameter that keeps track of how many game turns are left until the 'puting on' is complete. I love the realism this provides without causing the user pain.

Eventually I'll need to add in an alerting system that aborts internal commands if certain bad things happen, like a monster comes around. It shouldn't be too difficult, as all I'll have to do is clear the internal queue and only accept user input. A cool side effect of this whole system is that I'll be able to record and replay entire games simply by feeding the keystrokes the original user made into the input queue! I never call getc() or anything of the sort - it all comes from the queue. I'm just now starting to think about the possibilities. The game could easily be advanced to a certain game turn. This could be any arbitrary turn, or one chosen from a recorded list of 'notable moments of the game', like the first encounter with a unique, or the player's HP dropped to 1, or the player arrived at such 'n such town. The user could step through the turns, or let it run at a given speed and watch it like a move. Players could learn tactics from observing others or share battle stories as an actual short clip of the game.

I really am making some good progress with things, and there are a lot of fun game elements that I'm going to be able to start to put into the game.

|

Timing, Turns, and Speed

My first thoughts on turns and game timing were directed towards a priority queue of events. A creature takes a turn, then adds itself back on the queue for a later time. I thought about leveraging the queue for other things, like when hunger starts to take a toll, poisons that wear off over time, etc. But the more I go into coding it, I started to realize that efficiently managing that queue was going to be hard. So I decided to save myself the days and days of coding and testing and opted for a simpler solution.

Like many others I'm using an energy system, where the game has an internal loop, each loop being a sort of 'game turn'. Any object that takes actual turns will have an amount of energy added to it, and when a certain amount of energy is reached, that object takes an actual turn and loses some energy. What's nice is you can adjust how fast a creature gets to take a turn by adjusting the amount of energy they gain each 'game turn'.

My system uses a linear approach to speed. Currently, objects get 30 energy multiplied or divided by a speed factor each game turn, and they get a turn once they have at least 600 energy. The speed factor is 1.0 if the objects speed is 0. For speeds greater than zero, the 30 is multiply by 1.0 + 0.1 * speed. So +10 speed means you get 2X turns, +20 speed means you get 3X turns. For speeds less than zero, the factor is calculated the same, but the 30 is divided by it instead. So -10 speed means you get 1/2X turns and -20 means you get 1/3X turns.

|

The new look of RogueRunner

So here's a look at what I've been working on for the past few weeks. As mentioned before, OpenGL is out, ASCII is in. I'm loving it. I'm hard at work adding more and more to the game now that the display changes have been made, and I'm planning on lots of areas of the game to start to really develop.

Here's the new title screen. I'm sure it will go through a few tweaks, but I quite like it.

A sample shot of the current layout of the main display. I'm planning on moving most of the status stuff to other areas of the screen, but you get the idea. The numbers are all random, and my character is apparently in pretty bad shape.

|

Doxygen

I've decided that I will eventually make this game open source. I do a pretty good job of commenting in code, but I never comment my classe or method headers. So I'm now also in the process of adding Doxygen comments to all of my source files. What sucks is that it takes a VERY long time to add this amount of comments to this amount of code. Adding comments to files as I write them isn't that bad at all, so getting completely caught up now will be much better than finishing the game and then going back and commenting. Seeing how much work it has been already has convinced me that if I hadn't decided to get caught up now, I never would have had the time and patience to do it later.

Ultimately, open source serves 2 purposes as I see it. One, the user can see the inner workings of the system to assist in their own work. And two, people can actually help me hunt and destroy bugs. Before going beta I'll have a forum and bug reporting system in place. It's my hope that some form of community whether big or small will form around this game, and people can contribute.

|

Major overhaul

I haven't posted any updates for quite some time now, but not due to lack of working. In fact, I've been working heavily lately on making a complete overhaul of the display system. I've made the executive decision to switch over to colored ascii text instead of OpenGL graphics. Let me map out what infuluenced my decision.

OpenGL
Pros:
- Flexible sprite display. Easy to color, texture, rotate, scale, blend
- Not tied to the grid for things like projectiles, magic effects, etc.
- Better visually in general. More accessible to people outside the genre.

Cons:
- Heavier system requirements. ( Not big, I know, but with Roguelikes some people do care. )
- The need for sprites. This is the biggie. Every item and every monster and every floor tile and every wall tile needs a sprite to go with it. Well, I have about 50 sword sprites and only 6 or 7 axes. So, either there are just lots more swords in the game, or the axes will all look the same. I have entire races of monster sprites that I don't even know what I would use them for because of the way they look, but I don't have a certain set of monsters that I do want. If I want to add more sprites to the game, they not only have to be the right size, but they have to look like what I already have to some degree, otherwise they stick out like a sore thumb.

Which brings me to my final point - ascii is even more flexible, in some areas:

ASCII
Pros:
- Complete flexibilty in what gets added to the game. Whatever combination of letter and color I want can represent whatever I want it to. Then I just add some good descriptive text to everything, and it's up to the user to use their imagination.
- Traditionally Roguelikes are in ascii. It goes with the genre.
- Very light weight and fast. The screen updates as fast as you can send in key commands to it.

Cons:
- Not as pretty/accessible.
- Tied to the grid for projectiles and effects.

So I've spent the past month gutting the system of all OpenGL stuff and re-implementing the display system to use win32 text commands. I'm actually mostly done with that stuff, probably just needs some tweaking as time goes on.

|