Roguelike

During last 3 years I spent some of my time trying to learn how to write a roguelike. Roguelikes are cRPG games with no graphical mode, where environment is represented with ASCII characters (for example @ is player character). I discovered my first roguelike - ADOM when I was around 13 and I have always wanted to code one. I decided to write a post about developing a roguelike, because it’s a way to summarize some things (and if I won’t write it down it will rot on my hard drive for infinity).

I started by reading tutorials about writing games. In general it’s very hard to find a good tutorial about game writing. Game development, like any other technical activity is about layers of knowledge - you begin with some simple functions that do only one thing, but you organize them into bigger structures that can provide complicated results. Most tutorials contain only the basic steps, but tell you nothing about the upper layers. The best tutorial about game writing I found is Philip Hanna’s CSC207. It’s a university course, and contains many good examples, as well as the game engine written in Java. The engine is written in a very generic way. It allows you to start your own project, but it’s never optimized for it - so sooner or later it forces you to write your own engine - but at that time you already know what you want and how to achieve it. Very good teaching trick Mr Hanna!

I started my game using Philip Hanna’s engine. At the beginning I really liked writing in Java. It was much faster to write than in C or C++. But after a while I became fed up with it - I had to create getter/setter methods for every variable, and the code was hard to change or read. Later I learned some tricks in the Eclipse IDE which helped a lot - automated refactoring and getter/setter creators. But I still wasn’t happy with it. Then I found Python.

Python is probably the best language for hobbyists out there - it’s fun to use, reasonably fast (at least I think so), and with quite good support. At the beginning Python webpage scared me off because there is some new version of Python 3.0 coming out, and no library works with it. But then I realised that nobody uses it yet, and everything works with Python 2.6 (it’s a risky idea to make language backward incompatible).

I decided to start with Pygame - a library which is basically a binding to SDL library written in C. I read some basic tutorials, and started to port my earlier Java code to Python - mostly that meant holding DEL button for a long, long time. Python code is much shorter and easier to read than Java code (however some things are longer - like always including “self” as the first argument to a class method).

Below is a main class of my game - its temporary nickname is Towers :) :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

#File: game.py
#Author: MW

import pygame, sys,os
from pygame.locals import *
from map import Map
from input import Input

# Uncomment the lines below to enable profiling
#import profile
#import pstats

if not pygame.font: print 'Warning, fonts disabled'
if not pygame.mixer: print 'Warning, sound disabled'

class Game:

    def __init__(self,width=800,height=600):
        self._running = True
        self.screen = None
        self.screen_width = width
        self.screen_height = height

    def game_init(self):
        pygame.init()
        self.screen = pygame.display.set_mode((self.screen_width, self.screen_height))
        pygame.key.set_repeat(200,50)
        pygame.display.set_caption('Game')
        self.input = Input()
        self.map = Map(self,self.input,100,100)
        self.clock = pygame.time.Clock()

    def game_input(self):
        self.input.set_events(pygame.event.get())
        if self.input.get_event(QUIT):
                sys.exit()

    def game_update(self):
        self.map.update()

    def game_render(self):
        self.map.render()
        pygame.display.update()

    def main_loop(self):
        self.game_init()
        while True:
            self.time_passed = self.clock.tick(60)
            self.game_input()
            self.game_update()
            self.game_render()


if __name__ == "__main__":
    towers = Game()
    towers.main_loop()
    # Comment 1 line above and uncomment the lines below to enable profiling
    #profile.run('import game; towers.main_loop()', 'profile.tmp')    
    #p = pstats.Stats('profile.tmp')
    #p.sort_stats('cumulative').print_stats(10)

Python allows for both object-oriented and procedure-oriented programming, but my code is rather oo-way. The object of the Game class is created in the if statement at the end of the file. After that the main_loop method is called. At first it calls game_init method and initializes Pygame objects: display and clock. It also creates input object which is a wrapping over Pygame’s event module, and map object which contains the rest of the game. Then it loops infinitely through three methods: game_input, game_update and game_render. Such design separates game logic (game_update) from gathering player input and displaying the game on the screen.

So much writing and code still does nothing, but that’s the beauty of the OOP - you don’t need to know what’s inside the object (the implementation) to write a proper code.