Quest, the roguelike game

Still here...

2006-01-22T20:26:00.000+01:00

I haven't posted for a couple of days, because I've been totally unable to work on the game. Real life can be absorbing! I hope that this week will be less frantic, and I'll be able to report some progress soon...

Weapons

2006-01-18T19:35:00.000+01:00

Ok, I haven't had much time to do anything this week - crazy week at work. Still, a couple of features have gone in these last few days:

Melee weapons are in. Now, when you wield one (held in one hand) it adds to the combat value. Watch out for monsters finding them around next version!
Module information: when choosing a module, the screen shows information about the highlighted module, so the player can decide better wether to try it or not.
Health/Mana regeneration now happens sometimes. Before, they never increased, but now a player can heal and rest with enough time.

If I have time, this week I'd like to also add a new ability - Lockpicking, so it's possible to lock/unlock doors without the key, and also make monsters able to use Minor Healing, Tracking and Lockpicking like players do. This will probably entail heavy rewriting of the AI module.

Version 0.1.2 released

2006-01-15T18:49:00.000+01:00

Well, in the end I did have time to polish it out before the weekend was over. The bugs have been solved, and I'm very happy I made it in time, since next week will be crazy and I doubt I'll be able to work on Quest at all.

The changelog for this version:

Interface:

The message window now makes messages dim as they get pushed back.
The message window now holds seven messages instead of five.
It is now possible to quit during the game by closing the main window (if necesary, the game will be saved).
When the user enters a string, it is highlighted yellow and stored in the message buffer after it's entered.
Whenever possible (with items/beings), choice lists now show the symbol and color of each element, next to the choice (i.e, "+ ~ a torch" instead of "+ a torch").
The information window (which shows long text such as descriptions) now has word-wrapping.
The key to save and quit in the main game is now "s", to avoid hitting it by accident when using ESC to get out of menus

Engine:

The requisites to load a module are now handled by a special file, modulename.req. This way, to check the requirements only this file has to be loaded instead of the whole module, making startup time much faster.
Since getting Field-Of-View (FOV) is processor intensive, now the game uses caching. It will cache the FOVs of the level for later use.
Monsters now have a primitive memory: if they remember something very interesting, they will try to reach the place where they saw it last, instead of going for something they can see that is less interesting. This makes them able to chase the player quite well.
Each tile now has a "track" reference, to the last being that passed through it, the direction they left, and the "strength" of the track, which fades with time. This track can be checked with a new ability (see Content changes), and will eventually allow monsters to track the player.

Content:

There are now two kinds of maps: Underground maps (dark everywhere) and Overground maps (lit everywhere).
Modules now have requirements of minimum/maximum fame to join, which are set in the editor.

Bugfixes

When the display gets a string, it now accepts backspace to delete characters (duh!).
Portals now check that a being is standing on them before they let the being cross the Portal.
Light sources now behave properly when doors are open/shut.
Walls can now only be seen when you're on the right side of them, if they're lit by a light source.

Unfortunately, there are not many screenshots that could show the changes properly, since they aren't really visible, but here is a main game screenshot:

Evil bugs

2006-01-14T22:40:00.000+01:00

Even though I did finally decide to make a 0.1.2 release this weekend, I doubt it will happen. I have a couple of nasty bugs I can't allow in the release, and trying to fix them has made it impossible to work on the other two necessary things for a release: re-writing the documentation, and making a Mac port.

So, tomorrow I'll try to fix the remaining bugs (which have to do with the AI acting quirky and the caching FOV making light sources not work any more when there's more than one level, if you're wondering), but that still makes it very unlikely I can get it all done. And of course, next week I have a lot of meetings and busy time at work...so 0.1.2 is likely to come out next weekend, with a small chance of happenning before that. I doubt very much it will be later than that though, or I'd be really upset!

Smarter AI, module requirements

2006-01-12T22:03:00.000+01:00

So, besides some more bug-fixing, two little new features put in today:

Monsters are smarter. Not very smart, mind you, but at least they react to more than just what they see. I'll explain with an example. Before, if an ogre saw a yummy player (interest rating: 5) and a torch (interest rating: 1), it would obviously start going for the yummy player. But if the player goes around a corner and disappears - the ogre would look around, see the torch, and go for it. Now, though, the ogre remembers the player. He thinks he was indeed much, much nicer than the crappy torch. And then, the ogre walks up to the last place where he saw the player - and many times, from that position he will be able to see the player running along a corridor...which means he will keep going for his @-snack. On the other hand, if the ogre reaches the place where he saw the player and he can't see anything, he will forget about the player, focus on what he can see, and go back for the torch.

You might make some smartass comment like "Ok, but the ogre forgets about the player once he gets to the last place where he saw him. Not very good at following, is he?". You know, you're right. But I'm adding a system that will make the ogre be able to follow (if you're not very stealthy, and/or the ogre is very good at tracking you). And that system might actually make the Stealth attribute useful too! Yay! You'll be able to "cover your tracks" and also to follow monster's tracks (if one is fleeing from you). Hobbits might be a little beefier then - but still underbalanced. On the other hand, the next step will be to make Stealth lock/unlock doors without the key - which will make hobbitses very hard to catch indeed (they will be able to run, cover their tracks, leave locked doors behind them...)

The second change: modules now have requirements to join. Before, all you needed to play a module is to not have played it before with that character. But now, modules can have minimum/maximum fame requirements. This way, I can make a "tutorial" module that requires that you have fame 0 (that is, you suck), or an "advanced" module that requires that you're a kickass adventurer (say, fame 20). I plan to add more requirements, but not for this version - like having completed specific modules before, being of a specific race, having certain attributes to a certain level, etc.

Even though I've added quite a few things lately, I'm hesitant to make a release. On one hand, I've fixed bugs that made the previous nasty, but on the other I'd like each release to have enough meat that you can notice the difference pretty fast. I'm not sure what to do.

LOS (probably) solved

2006-01-11T21:27:00.000+01:00

Well, the answer to my problem seems to come from an unexpected place: threading! I'll try to explain briefly:

The profiling seems to show that my bottleneck is Line Of Sight calculation - it's called a lot, specially if there's a lot of monsters/lightsources on the level, and it made the game quite slow.

My first attempt was try other algorithms instead of my custom-made one: but they were either not accurate enough, or slower. I just couldn't get it done! Yesterday, I implemented a variation of Bresenham's algorithm, to have a ray-casting system -- too slow.

Fortunately, the start of a solution came from Guild and PGuild author Antoine, in a rec.games.roguelike.development discussion: when he generates a field of view (FOV) in his game, he caches it. Then, if another FOV has to be generated at the same place (if a monster walks into it, for example) it's retrieved from the dictionary instead of recalculated. If anything that can change FOV happens - like a door opening or closing - he clears the cache of the level. A brilliant idea, methinks!

So, doing just that improved the game slightly - not enough, but nice, specially when (for example) a monster carried a light source around. The first change I made to it was make it so when a door opens/closes it doesn't clear the whole cache - only those tiles that the door can "see". Overall, and very specially on big levels, this made an improvement. But I wanted more caching.

But I still thought - hell, many times you just sit there looking at the screen, and that pause of one or two seconds could be used for so much calculating, instead of doing it all between player turns! So I decided to try threading, and so far it seems like another nice boost to game responsiveness.

Basically, when the player enters a level, a new daemon thread is created, a "cacher". This little thread starts generating FOVs of every single freakin' tile of the level map, and caching them all. I haven't noticed slowdown while it's running, and the effect is quite noticeable, specially in monster-packed levels. I don't know if memory usage might be an issue, but so far - and with reasonably large maps - it hasn't at all.

So, for now, and with a grain of salt, since problems might still arise, I'm happy. The game is still a little slower than I'd like when there's 20+ monsters active at the same time, but it's definitely faster than it was before. I will leave LOS for a while and see how it goes, then come back if it still seems slow or this solution has obvious flaws that I haven't seen yet. Next step - slightly smarter monsters.

Slow, steady progress

2006-01-10T22:27:00.000+01:00

Some of the improvements I mentioned yesterday are fixed for the next version : portals now behave properly, and light sources don't light up walls when you're on the other side of the wall.

I still am working on faster LOS calculation, and will probably cache as many calculations as I can to speed things up, since I don't think I can make it really fast and accurate at the same time -- we'll see.

And I see no easy fix for Dvorak keyboard issues until I make a proper keyboard-mapping tool that lets the user customize command keys, but I'll keep looking into it.

Next on the list is the LOS, that's very important. After that, probably making monsters a little bit smarter by giving them a memory, and adding some sort of "scent" so that they can find the player (or another monster) if they stumble on their previous path. And combined with that, stealth - which should make hobbits a little less underpowered. There are still more things I have planned before a release - modules with actual fame requirements (both min and max fame), and modules that require a previous module to have been won...and more things, but I'll list them as they get added or at least worked on!

All in all, slow but steady - the only things that still nag at me are LOS and also the constant fear of the game becoming too slow.

Various bugfixes, little improvements

2006-01-09T22:08:00.000+01:00

Although I haven't had much time to work on the game for the past few days, I have fixed several ugly things that shouldn't have been there, so the next release is nicer: allowing Backspace to delete characters when entering strings (this was working with curses, but the port to SDL broke it), and more importantly (I'm very glad this works now): light sources now update correctly when a door opens or closes.

Another change done today, when choosing a module, all the modules aren't loaded anymore. Before, to check requirements to join a module, the whole module had to be loaded from disk, which (if there were several big modules) amounted to lots of work. Now, requisites are held in a separate, little file. Much faster startup.

There are a few nifty improvements that take use of pygame's features: the message window now has messages dim until very dark as they get older (the last message is white, the next a little dimmer, etc.), which makes for a nice experience. Also, controlling the font size has let me add more messages to the buffer, so seven can be seen at the same time now. I will add a couple more similar things to the next release.

For other things I want to work on this week -

Light sources not lighting a wall when you're on the other side of it (if you don't understand it, it doesn't matter, but right now if a light is lighting a wall and you're on the other side, you see the wall as lit).
Dvorak keyboard. Apparently, pygame doesn't handle this very well. I don't know if there will be an easy fix, but I will research it, probably tomorrow.
Optimization of the LOS algorithm. I have a custom-made one that is very accurate and nice (shadow-casting calculating arc-tangents and angle intervals), but slow. And the ray-casting one I wrote to be faster isn't as accurate. If I can pre-calculate things for my own one, or cache calculations so they're only done once, maybe it would be acceptably fast. I'm not sure, but have to look into it.
Make portals behave properly. They should only be used when standing on them, and there should be a key to use them that's easier than "+". In fact, I might make "return" the default key and pressing it on a portal would use it.

On the good news side, there's been quite a few people who've tried the game, even though it's in a pretty bad state yet - encouraging! The more bug reports and feedback, the more drive to keep working on it and make it playable. Thank you, if you're reading this!

Version 0.1.1 released

2006-01-08T13:39:00.000+01:00

Well, I managed to get the windows binary working, yay! There is absolutely nothing new in this version except the fact that now the game is a graphical window (with ascii graphics, of course), and that there is a separate, binary windows port so windows users don't need python to play the game.

You can get the source here, and the Windows self-contained binary here (the Windows binary has lots of needed .dlls, so it's quite big).

A couple of screenshot goodies! For some reason, they have funny colors when seen on this page, so click on them to see them for real. First, the editor:

The black window in the middle is the stupid screenshot interface, ignore it.Now, the main game:

As you can see, they look pretty much the same they did before - except now the colors are different, since I can choose them (or my wife can *cough*), and the font is nicer. On the next version, I'll try to take more advantage of pygame's features, but I wanted to have this done first to make sure I could make the game run in windows.

Next step, which I'll attempt during the week, will be to port it to Mac OSX so it can be run without any requirements as far as python/pygame/etc, like the windows version.

Finally, good news

2006-01-07T19:54:00.000+01:00

Well, a few pieces of good news this time:

First, I have an almost working version of the game with pygame. There are a couple of minor things to fix, and it will be running fine. It looks even better than it did on the console (I can control where to put things exactly, so a square room now looks square, and I have millions of colors to display text), and it is quite faster, for some reason. Kudos for pygame!

Second, I have been looking into packaging the game as a windows executable using py2exe, as was suggested in r.g.r.d, and it works! Instead of having people get python + pygame, I can package everything and make it run as a stand-alone application in windows. I might be able to have this running before monday, and if so I have to post at r.g.r.d so people can check it out if they want to.

I have to look more closely at py2app, which I think will work similarly so it shouldn't be too hard, so people with osx can play without getting additional packages.

Anyway, most of the setbacks are solved and I should have a really working 0.1.0 in a day or so. Yay!

Pygame

2006-01-07T09:14:00.000+01:00

Well, I am making an attempt at using pygame instead of curses. So far, it's being very easy (as I would expect from python). I have a working main window, and the three sub-windows reasonably set up, the intro is working, and the choice-list system is working as well.

In fact, there's so many new things that would be better than before and are easy to implement, it's hard to keep from changing stuff - but I'm going to first try to have the game running, see how performance is, and then think about changing things. And before anything else I want to try it in windows, see if it works, then use py2exe and py2app to have it as an executable in windows and mac.

Mostly setbacks

2006-01-06T11:20:00.000+01:00

I'm a little frustrated today. It turns out QuestRL will never run in Windows as it is - because of the lack of curses. I have several options right now:

Move over to Java, make my own console, emulate curses there. The pros of this are that my wife (with whom I plan to someday write a proper roguelike game) is a java developer, and doesn't like python much, and the fact that java is most certainly faster than python for a game like this. The cons are that I really like python, and that I'd have to recode the game - it's not that large, but it'd be long, boring, frustrating work.
Use a different curses library, like pdcurses. This is probably the fastest option, although I have to see how to make it work with python. The main pro of this is that it's probably very fast to do, if the methods are the same in pdcurses as in ncurses.
Go the pygame way, and emulate a curses interface. This is the equivalent of the java emulated console, only done in python. It seems a bit silly to use a graphics environment to do ascii characters, but I guess if I do this it will be easier to expand the graphics options of the game later on, if I feel like it. The main con of this is that I have to redo the display module, and learn how pygame works...but this is the option that appeals to me the most.

Apart from this, the only good news is that while browsing miscellaneous information about optimizing python programs, I came across the map() function (yes, I suck, but I didn't even know any python a month ago, so bear with me). I have gazillions of for loops in the game, and since map is supposed to be faster, changing that might actually make the game playable speed-wise. It will be some work to convert them all, but I will try just in case it makes a difference - otherwise, as the game get more complicated, the speed issue might make me give up and switch to a different language.

Version 0.1.0 released

2006-01-05T16:56:00.000+01:00

Well, it's finally here: the first public release of Quest. Not that there's much to show! The help files are done, and the game is as polished as I think is necessary for such an early release. If you want to try it, you can grab it here. Remember that it's not very playable right now, but you might have fun playing with the module editor and make some adventures!

Here's a couple of screenshots of the new features in 0.1.0. To begin with, the help files:

I enjoyed working with Maven a lot. It was easy, and the output is very easy on the eyes, and very consistent. I'll probably keep using it for the rest of the project.

The next screenshot...quests galore!

You can see the description of a quest (a victory quest, even!). Here you can see another quest screenshot, this time of the player completing a quest:

That darn helm was pretty easy to find, actually. The starting module is very silly and doesn't properly show the features of the game, but oh well. Too tired to write a better one.

And, for the last screenshot, keys:

I am so stupid that I designed the starting module with a gate that had a lock, and a matching key that is in a different level of the dungeon....only to forget to lock that stupid gate, to force the player to find the key. Well, you can find the key and lock the freaking gate if you want to, at least. *sigh*

If you do try it, write to tell me what you think of it -- but only if you don't hate it, and no calling names.

Almost there!

2006-01-05T10:54:00.000+01:00

I've cleaned up the code, documented stuff, fixed bugs, and changed a couple of little details so the game is neater. I've also done everything I think is needed for the GPL license stuff (adding tags to all source files, including a COPYING.txt file, and a disclaimer when the programs start).

So, the only thing needed before releasing 0.1.0 is writing a little help document to show people how to play the game. I'm going to do this using Maven, which was pointed to me most wisely by Geli. It should be easy to read and work anywhere there is a web browser. I don't know when it will be done, but probably today or tomorrow.

Decision time -- GPL it is

2006-01-04T16:58:00.000+01:00

So after consulting with Geli (my wife, who has read quite a bit about software licenses) I've reached a decision: when I release Quest 0.1.0, it will be under the GPL.

The only reason I was considering not to release the source was because having the source lowers the mystery factor of the game (i.e., compare ADOM to Angband). There are three reasons why I will make it open source:

1. Providing an editor makes the "mystery factor" silly, since the game is meant to be designed by a "dungeon master" who creates the adventures anyway, and hopefully the editor will allow pretty much anything to be seen and defined without looking at the code. No mystery that way.

2. One nice thing about Python is that, if the user has the interpreter installed, the game should hopefully be multi-platform. No worries about porting it to foobar! But if I don't release the source, I have to figure out how to make binaries (which I know of only for Windows), and then compile it for several architectures, which I don't have the knowledge or the energy to do.

3. I am fickle. Right now I work on this game a lot, but I've done this before and then abandoned it. Although right now Quest is a sorry excuse for a roguelike, maybe one day it will grow and be of use to others...and it would be a pity to let it die because I forgot about it.

After reading the GPL howto, it seems I have to put a tag on every source file, and then a separate file with the license on the root directory of the game. I will set to that tomorrow, because there aren't that many bugs to polish out anymore and the release could be soon.

Quests added -- and freeze!

2006-01-04T11:42:00.000+01:00

Ok, so once again showing how freaking fast it is coding in Python, quests are in (which is good, since that's the name of the game!)...yay!

There are two ways of completing quests right now: acquiring a specific item, or killing a specific monster. I think that's enough for now. And there is also a way of failing a quest (besides dying): you can set a monster to be the "bane" of the quest, so if the monster dies, the quest is failed. This could, in the future, mimick the "protect X" school of questing.

In the editor, when editing an item or a monster, you can set them as the goal of a new quest - the details of the quest are requested (no pun intended), and the new quest is added to the module. For monsters, you can also set the monster as the bane of a quest, so that if it dies the quest has failed.

Of course, there is now a way of seeing all quests (completed or otherwise) on the main game via a "quest menu". It keeps a record of all quests, so that you can finish a module, play another one and check all the quests you completed in previous ones, along with how much fame they gave you, etc.

Reasonably complex modules can be created now: with keys and quests, combinations are pretty large. And, a module can be failed without dying now, too - if the victory quest required a specific monster to live and it dies. I am happy enough I'm calling it a freeze, and won't implement any major features for this release. It's bug-hunting time, and also time to make the code neat, document things left undocumented, etc.

Hopefully, 0.1.0 (and releasing the code with it) is not far away now. It all depends on how many new bugs I find, and how neat I want it to be before others see it - although the rec.games.roguelike.development group advices to release often and early, so I won't refine it too much before releasing it.

Unlock it, baby!

2006-01-04T08:29:00.000+01:00

Keys and locks are in: having the right key, a door can be locked and unlocked. Eventually, there could be more than one key that unlocks a door, or a key that unlocks more than one door, but for now I'm keeping it 1:1.

In the editor, when you add a key object to the game you are informed that the next door you add to the module will be linked to that key, to simplify the process of choosing which door it's associated to. Naturally, the key and the door need not be in the same map.

This actually means a simple module with a little bit of a challenge that is not just bashing monsters can be created with the editor now. You can have several maps, and have to go through the trouble of finding out where the key to unlock some final area is, instead of just strolling there.

Overall, I'm very happy. My two strong feelings about Python remain - it noticeably slower in running than most languages I know, but it is such a pleasure to work with it!

v 0.0.9 screenshots

2006-01-03T14:17:00.000+01:00

Click on a screenshot to see it full-size, of course. Here goes:

The editor program, showing a view of the current map. There is a torch on the floor, and a monster on the lower left corner (the @ is the "dungeon master" creating the map).

Even though the stupid message says v 0.0.8, it's the new version. I *cough* forgot to change it.

The editor program again. This time, you can see the properties of a torch being edited. The program uses little menus where the user chooses with the cursors and keys, and the program does different things depending on the key used to choose. Both "item templates" and individual item objects in the adventure can be edited this way.

This is a screenshot of the main game (looks similar to the editor, huh?). You can see the description of the one and only ability that exists right now, Minor Healing.

On the map, you can see the player, the torch and the monster that were shown in the editor view before. Yes, all monsters except the boss monster are white M's. *thbpppt*

To finish, here is a view of some butt-kicking game action! As you can see in the message buffer, the kobold has walked up to the torch and picked it up (greedy bugger), the player has cornered it against the wall, and the kobold has realized there is no way out and is turning against the player.

Oh, the character sheet shows how very, very simple the game system is currently (only three "stats" besides health, and only two of those do anything right now).

First post and version 0.0.9

2006-01-03T13:48:00.000+01:00

So, here it is. I've decided to keep a development diary for Quest, probably for no good purpose. I didn't post anything before now because there was little to show (not that it's very exciting now!)

Anyway - what is Quest? It's a little roguelike written in Python, currently in its early stages of development (like lots of others out there). Most of the coding is done by me, but my wife makes life-saving contributions all the time, some in the form of design tips, and others as actual code (half the current AI code has been written by her). To describe the game very briefly, it uses curses and is composed of two programs: the main program where the game is played, and the editor where the adventures are created. Both are slowly growing in parallel, so that new features added to the game can be used to design adventures through the editor, rather than being hard-coded.

Of course, it's all just for testing the first attempt at the engine right now, and there's practically no items or monsters or anything of the sort. Items, monsters, terrain types and abilities (currently a spell) do exist though: depth hasn't been added yet because I'd rather get the basics set before committing myself to anything in detail.

One of the next things I have to look at, if I'm to "release early and often" is licenses. I have absolutely no idea of how those go, and I don't want to let anything out on the web before I look into that. More on this after some research.