Moving monster and item definitions to config

[wesleywerner]

I propose moving monster and item data to a config level. They will live in dungeons.conf. I have a working branch of this where all monster data is loaded dynamically.

monster list = rat, killerrabbit, troll, zombie

All monsters listed there will be used in game. I will remove killerrabit and it will act analogous to how Frost commented it out to exclude it from the game.

There is a .test_config.py unit when run will load the config and syntax check it. Good to run before commits.

Config is loaded into the global variable config, of type ConfigParser.

To grab monster data into a dictionary:

>>> monster = dict(config.items('zombie'))
>>> monster['hp'], monster['xp'], monster['flavor']
('20', '35', 'a walking corpse that shambles in your general direction.')

Of course the .items('zombie') part above is for demo, we load level monsters from monster list.

Majority of code only affects the place_objects() function. I had to place the entry code under a "main" check to allow the unit test to import our dungeons.py file properly.

Items need some love. Each one has its own cast method, they seem to be categorized:

• healing (affects player)
• ai change (i.e. confusion - affects enemies)
• point attack (targets one enemy)
• splash attack (targets any in radius)

These can easily be moved to the .conf too, after which adding new items would be much easier:

[wand of torture]
char = /
color = [115, 255, 255]
type = point attack
damage = 30

for example.

What do you all think?

[DebianJoe]

I think that sounds like a nightmare to migrate....DO IT! Unless we get some more Bangers in here tossing up code, I don't feel the least bit nervous about what you guys want to do. You and FrostLock have a pretty solid grasp of the language and general program design. So far, other than me having to manually merge some of the changes a few days ago, I haven't felt the need to touch any of your work. It may not always start out beautiful, but it does do what it says on the package. That's the important part, especially since we're looking at making such drastic changes to the code over time. As we start to divide it into smaller sections, we might find it to be beneficial to really focus on one area. For monsters/item/inventory layout/etc, these are areas that should be more flexible to allow for ease of design later on. Why use classes at all if we aren't going to make them portable? I don't see any reason to try to box ourselves in with the current structure. If you feel that it would be best served by migrating files outside of the main script, then by all means, do it. With the 3 of us who are currently working on the project, I can manage to get some coding done and handle merges without too much effort. If we start getting a lot of new scripters in, though, I may have to get some help in that department. I've heard it said that for every 30 minutes of coding, you'll debug for 2 hours. If we eventually have 10 people coding for 2 hours a day....I'm not going to be able to keep up without some help. For now, though, everything is pretty smooth and I say that it might be in the best interest of future design to split up whatever code you wish to set as a divided object now (before it starts to grow.) -joe

[DebianJoe]

Closing issue, refer to above thread.