Roguelike News

From time to time, the original post,
email or web pages news provides more
information that can be added to the
news sections.

Main | News | Development | Archives | Articles
Links | FAQs | Contact : rogue@skoardy.demon.co.uk
Robert Ruehlmann's plans to introduce Python scripting to (Z/K)Angband.
Mark Howson and I are planning to add scripting support to KAngband and
ZAngband.  We decided to use Python (instead of S-Lang) for it.  Most of the
things mentioned here apply to both KAngband and ZAngband, and all other
variants that want to support Python as well.  So I'll just write *band.

Why adding a scripting language?
- At the moment every minor change in the *band source code requires
  the game to be compiled for all systems.  This takes some time,
  especially for the more exotic systems.  Often the new version
  appears just after an older version was ported to other systems.
  A script just needs to be written once, and will work on all systems.
  You just copy the new script files and get the new feature.
- Many players want to write quests, create new items, monsters, ...
  At the moment this almost always requires changing the *band
  source code.  Scriptfiles allow adding new things without changing
  the *band source code and are far more powerful than the datafiles
  used until now.

Why Python?
- Interpreted language
- Object oriented language
  The *band data and functions can be wrapped into Python classes.
- Available for almost any computer system (All *band systems are supported)
- Easy to learn
- Very clear syntax
- Automatic memory managment (garbage collection)
- Embeddable (Python can be integrated into *band)
- Extendable (All *band functions/data can be made accessible from Python)
- Large number of external modules (for GUI, networking, ...)
- Free and Open Source (and it's not under the GPL, so adding it to *band
  doesn't require to change the Angband licence)
- Very good documentation, several books, tutorials
- Large user base, newsgroup, mailing-lists
- easy integration of C code, especially with SWIG ( http://www.swig.org )

What will it be used for?
- New types of quests
- New artifacts, terrains, items, monsters, player classes/races, ...
- More interesting dungeon layouts
- Cross platform compatible user-interface using the Tk library
- *band Borg
- Multiplayer support
- talking NPCs
- ...

What do I need to play *band with Python support?
- You will just need to install *band, since the Python interpreter
  will be compiled directly into *band. (embedded)

Won't this make the *band executeable much larger?
- Python makes the DOS version about 350 kByte larger.  I think other
  versions will grow by about the same size.  Systems with support
  for shared libraries (DLLs in Windows) can use one library for
  all *bands.

Will *band with Python be slower?
- Interpreted languages are generally slower than compiled languages
  like C.  But since all *band core functions are written in C this
  won't have a big influence on gameplay.

Will scripts for KAngband and ZAngband be compatible?
- We are trying to make our implementations as compatible as possible.
  We can't promise that any script will work on both variants since
  some functions are very variant specific, but we will try our best.

How does a Python script look like?
- I prepared a small example that adds a *silly* quest.  It is longer than
  necessary because I've added lots of comments (# starts a comment in
  Python).  The real code in this example is just 17 lines long (and it
  could be even shorter).

<EXAMPLE starts here>

# Example for a "slime mold" quest (eat 5 slime molds)

# First we import some functions that implement various *band functions
from event import *
from ioc import msg_print

# The class definition for the "slime mold" quest
class slime_mold_quest:
    # The constructor (called when an object of class "slime_mold_quest"
    # is created)
    def __init__(self):
        # The version number of the quest (for converting older savefiles)
        self.version = 1
        # The number of slime molds the player has eaten while in the quest
        self.slimemolds = 0
        # First add ourself to the event for eating something.
        # Our quest object will be activated when the player eats something.
        callback(EAT_EVENT).add_hook(self)
        # Print the quest info
        msg_print("""There is a family of slime molds running wild and
            pestering the local citicens.  We'll be eternal grateful
            if you can find a way to remove them.""")

    # This function will be activated when the player eats something
    def eat_hook(self, sval):
        # We are only interested in slime molds
        if (sval == 36): # sval of the slime molds
            # Another poor little slime mold was brutally killed
            self.slimemolds = self.slimemolds + 1
            # The whole family was killed!
            if (self.slimemolds >= 5):
                # Give some feedback to the player
                # Normally we would give the player an reward,
                # but killing innocent slime molds is not an action
                # that should be rewarded.
                msg_print("You have finished the slime mold quest!")
                # Clean up
                callback(EAT_EVENT).remove_hook(self)

# Init the quest (this creates an object of class slime_mold_quest)
slime_mold_quest()

<END OF THE EXAMPLE>

I don't want to use Python.  Will versions without it still be updated?
- I'll try to make the Python scripting language in ZAngband optional,
  so that the game can still be run on the low end machines where every
  byte of memory counts.  But of course you won't get the more advanced
  features like quests.  In the long run most new features will be added
  via Python, so in the non-Python versions these new features won't
  be accessible until somebody ports them to C.

Robert Ruehlmann ( rr9@angband.org )
"Thangorodrim - The Angband Page" : http://thangorodrim.angband.org
© Copyright 1999 Darren Hebden.