Little level dsl tricks

I have been tinkering with how levels are configured and made some minor changes. I’m trying to keep things relatively simple, but at the same time I want to have configuration code to look more like a configuration file than a function definition.

Below is shown a configuration for area called “first gate”. This is the area where the game starts. Two requires at the top are used to signal that I want to use certain macros. (level-config-dsl) is just a cute way to have pile of imports without cluttering the code. After that follows a list of levels, with just single entry. That entry first contains name and description of the level and rest is just configuring how it connects to other levels and how it is going to be generated. I made a post earlier explaining how the level generation works.

Continue reading

Advertisement

Adventures in configuration continue

Adventures in configuration continue. I decided to try and split the project in two: engine and configuration to drive that engine. Most of the changes were surprisingly easy. Apparently I had gotten some things correctly and components were easy to pull apart and move in their own namespaces.

Couple components weren’t so easy though and I was left with nasty references from the engine side to direction of configuration. This of course is against everything I was trying to achieve when I started doing the change.

Two biggest problems currently are the player character creation and randomizing appearance of the potions. Which is partly a good thing, since this gives me a good reason to work on the codes that is responsible holding all various tables used in item and creature generation. I’m probably planning to do simple domain-specific language for configuring those things and try to inject results of the configuration into item and creature generators.

Changes in configuration

In Herculeum I originally had a single class called Configuration that holds configuration for the system and knows how to set it up. It was soon clear that the class would be gigantic in proportions, even when loading of some of the stuff was in other classes. I made little code-pushing today and break off configuration of levels into separate functions in appropriately named modules (configure_catacombs.py andĀ configure_upper_crypt.py):

def init_level(rng, item_generator, creature_generator, level_size):

This function creates configuration for a level (or multiple similarly themed levels).

Calling this identically named functions from different modules started looking like repeating myself. Also, in order to create a new configuration I would have to write the configuration and add call to it in the main configuration class. I wanted to avoid that and added this little piece of code in the original configuration class:

config_names = filter(lambda x: x[0] != '_',
                      dir(pyherc.config.levels))
config_modules = map(lambda x: getattr(pyherc.config.levels, x),
                     config_names)
configurators = map(lambda x: getattr(x, 'init_level'),
                    config_modules)
for configurator in configurators:
    self.extend_configuration(config,
                              configurator(self.rng,
                                           self.item_generator,
                                           self.creature_generator,
                                           self.level_size))

Now I can add new level configurations simply by adding a module with init_level function and placing it in pyherc.config.levels – folder. Building your system to be easily extendable without need to be modified is usually a good thing. Of course one can not anticipate all the changes of future, so some common sense and good judgement is required (as always with software development).