Archive for July, 2009|Monthly archive page

things (a roguelike in Python #15)

I haven’t really spent much time yet figuring out what a thing from the Thing class is, so far defining it as an object with a name, speed, position, and maybe a handler for field-of-view or dumb AI. Furthermore the character used to represent it on screen simply was based on its name. Since I knew I wanted to better define a Thing and start figuring out how I want to represent it visually, I’ve started hacking on Thing.

First of all Thing‘s parameters have changed. The __init__ now looks like this:

class Thing(object):
    def __init__(self, name, x, y, properties, *handlers):
        self.name = name
        self.x = x
        self.y = y
        self.properties = properties
        self.handlers = {}
        if not None in handlers:
            for string in handlers:
                handler = eval(string)
                self.handlers[string] = handler(self)
                
        self.things = []
        self.stage = None
        
        self.char_type = self.get_char_type()

As you can see I got rid of the speed parameter, which is now included in properties. A thing therefore looks like this in its yaml definition file:

- iron-barred window
- 35
- 12
- speed : normal
  kind : 
  - window
  state : 
  - none
- 

That definition gives the thing’s name, x, and y attributes. The next item in the list is a dictionary containing the keys speed, kind, and state. This dictionary is passed into a new instance of a thing as properties. The last blank list item is handlers.

It’s all very provisional right now as I figure out how to define a thing. But here’s a closer look at the last statement in __init__, self.char_type = self.get_char_type().

Here’s that function:

    
 def get_char_type(self):
        name = ''
        if self.name in player.ui.char_types:
            name = self.name
        else:
            name_tokens = self.name.split(' ')
            for token in name_tokens:
                if token in player.ui.char_types:
                    name = token
                
        if not len(name):
            for kind in self.properties['kind']:
                if kind in player.ui.char_types:
                    name = kind
            
        for state in self.properties['state']:
            state_modifying_name = ' '.join([state, name])
            if state_modifying_name in player.ui.chars:
                return state_modifying_name
            if len(name):
                return name
            else:
                return 'unknown'

What I’m trying to do is find the visual symbol for a thing (its char_type) based on its name, kind, and state (if any). This is of course not very straightforward and I may have to choose a different method. Whenever a thing’s state changes, its symbol may change as well. There is also the possibility, not accounted for in this code yet, that a thing may have a combination of states that modify its name or kind producing a unique visual symbol. I think I can get this to work but it’ll require some experimentation.

In the meantime I’ll explain how this works. The player.ui.char_types list looks like this:

        self.char_types = ['player', 'unknown', 'ground', 'wall', 'window', \
        'lamp', 'knife', 'door', 'portal']

So the first thing the get_char_type function asks is if the thing’s self.name is in that list; if so, it assigns it to the local variable name, previously set to an empty string allowing it to be referenced later in the function. If the thing’s self.name is not in the list we break up the name into its tokens (parts), and if one of those are in the list, we assign that to name. Keep in mind that name may still be empty at this point.

Next, if name is empty, we see if the thing’s kind is in the list of char_types, and if so, assign that to name.

Finally we combine whatever state the thing might have with its name, and check if that’s in the list. This takes care of things like ‘closed door’. If there’s a match we return it. If not, we see if name is non-empty (there was a successful match earlier) and return that. Lastly if name is still empty, it’s not in the list of char_types and so we call it ‘unknown’, which gets the question mark symbol when drawn to the screen.

Some notes after the cut on how to find symbols for combination of states.

Continue reading

pystil

pystilmockup

I’ve been thinking for a while about something like a drawing tool for writers…something like Alchemy that I would write in Python, maybe using pyglet. I’ve always wanted to make tools as well as make games, but they seemed beyond my capabilities somewhat…I have some specific UI ideas I’d like to try in the software flesh (mainly — bigger text for godsake, though it may turn the tool into one only I would use). A couple of new developments inch me closer to my goal. It’s beginning to look like Nick Montfort’s nn, now known as Curveship, will have a release later this year. And then over at MudBytes in a thread where someone asked for help naming a mud framework/IDE written in Python, I thought of the name pystil. So…a narrative/text generation player/maker? Who knows.

stages (a roguelike in Python # 14)

A few days ago I got to the point where I wanted to add switching levels and a get command. Adding the get command led me to consider how I would represent inventory in the code, and I thought simple, every thing has a list of things it holds.

The new code is after the jump, but first some explanation.

My thought was that a level is simply a thing that holds the things inside it. OK, I was thinking this is good, because I had wanted to have different kinds of levels in the game, like airships, giant woolly mammoths and so forth, and this would potentially make it straightforward to have a giant woolly mammoth walking around that the player could jump on and explore. So I decided a level would be a kind of handler that gets attached to a thing and adds the functionality of a map.

As you can tell I’m not too concerned with representing scale at this point — I don’t think I will be at any point really, this is a game after all. Regardless, I decided to call a level handler a Stage.

You can see in previous postings of the demo that I managed the map in a single World object. So I needed to do some heavy rewriting, and this led me to reconsider the handler/thing structure altogether. As a result I threw out the Brain class and now add handlers directly to a Thing. I think this is simpler overall.

At one point I got sidetracked by the magic of Python’s __getattr__. This is an attribute on every object, that’s executed when the interpreter doesn’t find the attribute it’s looking for as a result of a call on a property or function. So I was doing things like calling thing.foo where foo was actually an attribute on a handler, not the thing itself. However this proved to be more trouble than it was worth (since, as far as I could tell, __getattr__ expects you to return a value when called, and I decided this was too much hassle). The easier solution for me was to rewrite things so that wherever I call an attribute of a handler, I access it through a dictionary of handlers on the thing, like this:

            cells = stage.handlers['Stage'].cells_get(self.thing, self.fov_radius)

A little verbose, but easier in the end, and maybe clearer overall.

Saving the game now means saving the stages in a game. I’ll need to revise this in the future to account for stages within stages though. Switching stages means removing the thing from its current stage and adding it to the new stage. By keeping track of the player’s current stage I know what to draw to the screen. Currently I only update things in the player’s stage, so this will need to be changed in the future so time doesn’t freeze on a stage when the player leaves it. And finally, getting and dropping things means removing and adding the thing to the things that are getting it or receiving it.

There’s a crude inventory display in the upper part of the UI at the moment, but there’s only one thing to get.

Things are now kept in a file by stage, which is named like stage_name.things, and the maps are in stage_name.map.

addendum: With all this talk of stages, it may seem as if something is being left out — namely procedural generation of levels! And for the moment this is true, but as I think I’ve mentioned before I’m not going to focus on generating levels until I have a better idea of what I want the game to be. So for now I’m sticking with hardcoded content to give me a base to test on.

Continue reading

main menu screens and UI (a roguelike in Python, #13)

I spent some time getting a main menu and new/load game screens working, and started to get an idea of what I want the UI to do.

rltestui

After the cut is the current demo code. Note that I’ve now moved the key configuration, the level map, and definitions of things to separate files. The key config file looks like this:

k : north
j : south
h : west
l : east

up arrow : north
right arrow : east
left arrow : west
down arrow : south

keypad 8 : north
keypad 6 : east
keypad 4 : west
keypad 2 : south

p : print history

While the things definition file looks like this, in part:


- 'window'
- 35
- 12

---

- 'closed door'
- 30
- 15

---

- 'monster'
- 20
- 9
- 'AI'

And of course the level file is a hardcoded map.

Next I think I’ll have a go at adding get, drop, and throw commands along with player inventory — this should be a good test of the demo’s structure overall. Initially I added in stubs for get and drop with a key definition for each command, but today I thought about it and now I think I’m going to streamline the interface somehow.

Continue reading

timeless actions (a roguelike in Python, #12)

One last important thing I needed to add to command handling was commands that take no time — certain out-of-game actions or meta commands like switching UI views and things like that. I’m imagining that most commands will take a player’s turn but I wanted to have support for actions that don’t.

At the same time I wanted to centralize command parsing — before commands were enacted by calling the command directly which was OK but made it tedious to add things that would happen when any command was called. So here’s what I came up with — some significant changes to the Command class:

class Command(object):
    def __init__(self): 
        self.playbook = {
                        'north' : ('takes turn', self.move, 0, -1),
                        'east'  : ('takes turn', self.move, 1, 0),
                        'south' : ('takes turn', self.move, 0, 1),
                        'west'  : ('takes turn', self.move, -1, 0),
                        'ctrl north'    : ('takes turn', self.ctrl, 0, -1),
                        'ctrl east'     : ('takes turn', self.ctrl, 1, 0),
                        'ctrl south'    : ('takes turn', self.ctrl, 0, 1),
                        'ctrl west'     : ('takes turn', self.ctrl, -1, 0),
                        'print history' : ('free action', self.print_history, None)}

And now commands are routed through a single function:

    
    def do(self, string, enactor):
        command = self.playbook[string]
        command_name, args = command[1], command[2:]
        command_name(enactor, *args)
        self.history.append((string, enactor.name))
        return command[0]
 

Which gets called like this in the player input function:

        command_name = self.ctrl + self.keycfg[key]
        game.message.text = "Go!"

        if game.command.do(command_name, player.thing) == 'free action':
            self.gameplay_update()

So the command_name is created, for example ‘ctrl north’, and is sent to command.do. That gets looked up in the playbook, and the command is called with its arguments. The lookup also tells the game if the action takes a turn or not — this information is returned to the original call, and if it’s a free action the player input function is called again without a turn passing.

The ‘history’ is mostly a way to test this out. I have a vague idea of allowing playback of moves, but that’s going to require a lot of other work that’s not a priority right now.

oh no you mean I have to add things? (a roguelike in Python, #12)

Up to now I’ve been motoring along quite happy with my simple arrangement — a player, a monster, some lamps, field-of-view, saving and loading. In theory I’d written the code as a framework that would make it easy to add stuff, but…I hadn’t actually added any stuff yet. I knew this was an important step. Would things totally break down? How easy would it be to add stuff?

So I’ve started to add stuff. Let’s see how easy it is to add something. Trying to keep things simple, I’m starting with windows and doors.

Now I already had windows, but these were a part of the hardcoded map. I’ve decided to make them of the Thing class instead, and so the hardcoded map will strictly represent terrain (at the moment just walls and ground). To make a window a thing this is what I had to do:

  • remove the window from game.world.cell_types and the hardcoded map
  • add a test to Fov so that if a cell in field-of-view is a window, it’s marked as transparent in the fov map.
  • add the window to player.ui.chars
  • remove adding the window to the viewport structure in the view.update, as now it’ s just drawn with the other things.
  • create the window thing in Game.

Adding doors followed a similar path as above (minus removing code of course as doors are totally new), but I also had to add the functionality of opening doors. So, I went to the Command class. Here is what the rulebook and rules look like now:

class Command(object):
    def __init__(self):   
        self.rulebook = {
                        'move' : ('cell has monster', 'cell is unwalkable', 'cell has closed door', 'open door implicitly')}
                        
        self.rules = {
                        'cell has monster' : 'game.world.cell_has_monster(thing.x+dx, thing.y+dy)',
                        'cell is unwalkable' : 'game.world.cell_is_unwalkable(thing.x+dx, thing.y+dy)',
                        'cell has closed door' : 'game.world.cell_has_closed_door(thing.x+dx, thing.y+dy)',
                        'open door implicitly' : 'game.world.open_door_implicitly(thing.x+dx, thing.y+dy)'}

So I added ‘cell has closed door’ and ‘open door implicitly’ (bump to open — now that I think of it I might be able to make a general ‘bump to open’ rule). Here are the corresponding methods in World.

    def cell_has_closed_door(self, x, y):
        for thing in game.world.things:
            if (thing.x, thing.y) == (x, y) and thing.name == 'closed door':
                return True
                
    
    def open_door_implicitly(self, x, y):
        if self.cell_has_closed_door(x, y):
            for thing in game.world.things:
                if (thing.x, thing.y) == (x, y) and thing.name == 'closed door':
                    thing.name = 'open door'

Though I set the name directly here, I think I’ll change this later to call a method on Thing to change its name. I’m trying to keep World as a state object only, changing its state from outside this object.

In player.ui.chars I have this:

        self.chars = {
                        'player'    : '@',
                        'monster'   : '?',
                        'ground'    : ' ',
                        'wall'      : '#',
                        'window'    : libtcod.CHAR_DHLINE,
                        'lamp'      : 'Q',
                        'open door' : '/',
                        'closed door'   : '+'}

So when I change the name to ‘open door’, the symbol changes, and the movement test for a closed door will pass as well.

Overall, not too bad. I think I’m going to have to generalize the field-of-view code a bit, as I can forsee adding a lot of special cases as I add objects if I keep doing what I’m doing. So far I’m happy with how the rulebook and rules works too.

update:

To make a close doors command required a few more changes. This requires either a command then command input (like a ‘c’ key then direction) or a combination key like command + command. I’ve decided to go with the latter, and I’m using CTRL + direction. I think I like the idea of extending this in the future into a context sensitive command as well. As libtcod doesn’t currently have an easy way to test for a combined key press (I think it’s slated for 1.5) I just made a boolean in player.input like so:

class Input(object):
    def __init__(self):
        self.update_state = self.intro_update
        file = open('keys.cfg', 'r')
        self.keycfg = yaml.load(file)
        self.ctrl = 0

    def get_key(self, key):
        if key.lctrl:
            self.ctrl = 1
        else:
            self.ctrl = 0
        
        if key.c:
            return chr(key.c)
        else:
            return key.vk

Every time I call get_key() (when a key is pressed) I check if the left control is pressed and then set the self.ctrl value accordingly. Then in Command I can do this:

    def north(self, enactor):
        if player.input.ctrl:
            self.close_door(enactor, 0, -1)
        else:
            self.move(enactor, 0, -1)  

And then add the rules and a command for close_door() like normal.

premature optimization is the root of all…oh wait (a roguelike in python, #11)

Up to now I’ve been running the demo in a rather small window (about 40×20 cells) with a small viewport (19×19). Actually I like the idea of a game this size, but with the demo I’d like to try something bigger. Since I’m scrolling I knew I might run into issues with how fast the screen redraws (as I’m redrawing the whole thing every turn).

So first I put the level in a text file and made it much bigger (it’s now about 80×50), and then I increased the window size, and the viewport size to 40×40. As I found out the game really got sluggish. Reducing the viewport to 30×30 improved things to make it playable, and so I wanted to see exactly where things were slowing down.

To start, I firmly believe in first writing without optimization in mind. Much of what I write is very verbose, using strings insteads of integers for properties and so on. I think that for what I’m doing the bottlenecks are going to come in specific cases, and it’s not really necessary to bitshift when I can just multiply integers, or whatever real programmers do, I’m sure I’m getting the terms wrong here.

As with many things Python makes it really easy to use support modules and tools, at least for basic things. So what follows here is an idiot’s guide to profiling the bottlenecks in your code.

The cProfile module is dead simple to use and in the standard library. I used it in two ways. First, from the command line, you can do this:

python -m cProfile -o nameOfYourOutputFile nameOfYourGameFile

Your output file doesn’t need to exist first. What this will do is start up your game using the cProfile module to time how many seconds are spent in each function call. When you exit your game you’ll find the output file in the game’s directory. Then you can create a simple .py script like so (this is all in the Python documentation for cProfile by the way) — let’s say your output file was called test_profile:

import pstats
p = pstats.Stats('test_profile')

p.sort_stats('time').print_stats(10)

Running this script will give you a breakdown of time spent. You can sort this output in various ways, see the docs for details.

Now what if you want to profile only one function in your code? When I ran the first script I saw that the viewport draw call was taking a significant portion of time, but the output doesn’t break down the draw function itself. All you need to do is something like this, where you call your draw function:

        PROFILER.runcall(self.view.update)
        PROFILER.dump_stats('test_profile')

Remembering at the top of your game file to import cProfile and set up the profiler like so:

#############################################
# imports
#############################################

import os
import random
import yaml
import cProfile


import libtcod.libtcodpy as libtcod


PROFILER = cProfile.Profile()

That’s it. Then you just run the pstats script above in the same way.

These are the calls that take the most time in my draw function:

ncalls  tottime  percall  cumtime  percall filename:lineno(function)
      202    7.430    0.037   16.854    0.083 diana.py:427(draw)
   194171    1.873    0.000    4.267    0.000 C:\Documents and Settings\GO\My Documents\dev\diana\libtcod\libtcodpy.py:58(__mul__)
   194171    1.393    0.000    2.036    0.000 C:\Documents and Settings\GO\My Documents\dev\diana\libtcod\libtcodpy.py:74(int_to_col)
   182002    1.360    0.000    1.647    0.000 C:\Documents and Settings\GO\My Documents\dev\diana\libtcod\libtcodpy.py:448(console_put_char)
   181800    0.926    0.000    0.926    0.000 C:\Documents and Settings\GO\My Documents\dev\diana\libtcod\libtcodpy.py:454(console_set_back)
   194171    0.642    0.000    0.642    0.000 C:\Documents and Settings\GO\My Documents\dev\diana\libtcod\libtcodpy.py:50(__init__)
   181800    0.496    0.000    0.496    0.000 diana.py:415(viewport_ij_to_world_xy)
   181800    0.494    0.000    0.494    0.000 diana.py:117(cell_type_get)
    94940    0.390    0.000    0.390    0.000 diana.py:421(xy_in_viewport)
    83478    0.380    0.000    0.380    0.000 C:\Documents and Settings\GO\My Documents\dev\diana\libtcod\libtcodpy.py:1050(map_is_in_fov)
   194171    0.358    0.000    0.358    0.000 {isinstance}
   203134    0.345    0.000    0.345    0.000 {method 'append' of 'list' objects}
   182002    0.288    0.000    0.288    0.000 {ord}

So it looks like multiplying colors together takes a significant portion of time. I may have to look into precaching this information somehow. However there is an even easier way to speed things up, though it requires a third-party module — the Psyco module.

All you need to do to get Psyco working (after downloading and installing it) is put in your game file like this:

if __name__ == '__main__':
    try:
        import psyco
        psyco.full()
    except ImportError:
        pass
    
    game = Game()
    player = Awesome()

    while not game.exit:
        game.update()
        player.ui.draw()

You can also have Psyco optimize only specific functions in your code — as it uses more memory in its overhead, this may be important for some people.

I did notice a speed improvement with Psyco, but as it’s an external dependency my first line of attack will be speeding up the routines in the draw code itself. It may be enough to keep the viewport a reasonable size, thus drawing less to the screen. Of course I haven’t added any real gameplay yet…now that can’t take much time to compute, can it?

how I love refactoring (a roguelike in Python, a diversion)

In working on adding player memory to the map (so cells not immediatly in field-of-view but previously seen are drawn) I realized something. My scrolling/camera code looked like this:

    def scroll(self):
        self.x_offset = min(max(0, player.thing.x - self.width//2), game.world.level_width - self.width)
        self.y_offset = min(max(0, player.thing.y - self.height//2), game.world.level_height - self.height)

        self.x_left_offset = min(player.thing.x, self.width//2)
        self.x_right_offset = max(0, (self.width//2 - (game.world.level_width - player.thing.x) + (self.width % 2)))
        self.focus_x =  self.x_left_offset + self.x_right_offset

        self.y_top_offset = min(player.thing.y, self.height//2)
        self.y_bottom_offset = max(0, (self.height//2 - (game.world.level_height - player.thing.y) + (self.height % 2)))
        self.focus_y =  self.y_top_offset + self.y_bottom_offset

When it really only needs to look like this:

    def scroll_update(self):
        self.anchor_x = min(max(0, player.thing.x - self.width//2), game.world.level_width - self.width)
        self.anchor_y = min(max(0, player.thing.y - self.height//2), game.world.level_height - self.height)

The problem was I had been treating where the player was rendered as a special case — in effect putting the player and the camera focus position in the same basket. This wasn’t necessary at all — all you need to know is where the camera or view is positioned on the screen (I chose to keep track of the top left corner of the view with the variables anchor_x and anchor_y). Then you just need to translate world coordinates to view coordinates when you deal with the viewport.

I knew the previous code was too complicated. It feels good to get it into shape!

new fov (a roguelike in Python #10)

As I began in the last few days to add more things to the map with a field-of-view (starting with some lamps) it seemed like it was getting harder to work in the field-of-view structure I had. Most of this had to do with translation of world to viewport coordinates, and I realized I was calculating things in terms of viewport coordinates in the field-of-view code. Conceptually this seemed a little strange — I decided to keep all game calculations in world coordinates, and only clip to the view port when drawing to the screen.

After a day of thinking and a night of rewriting I think I have it!

newfov

Some more notes after the cut.

Continue reading