pyAngband's thread

[Sirridan]

http://github.com/Sirridan/pyAngband

More is coming, I really can't work on it as much as I'd like except on Mondays it seems (no work on Monday, Fiancee at school).

Right now I need to put in the docstrings, add some more comments, and do all that other stuff. At the moment, I'm working on a small "test" dungeon floor that is static, has a shop or two to test those out (NYI), and to test out other things which will be added soon.

Hopefully sometime before the end of the month there will be something "playable", not anywhere near a finished game obviously, but hopefully something slightly resembling Angband.

Here are the classes as they stand:

Thing -> Base class for anything that can be on the map, it has a position and an ID which tells exactly what something is. (Think of the ID like a tval)

LivingThing -> Anything alive (or undead ) like a monster or the player

Player -> You (NYI)

Status -> A living thing's current status, it's health, stats, etc.

Stats -> A living things stats, STR, DEX, etc.

Resists -> Container for resistances, vulnerabilities, immunities, etc. Also constants for these things

Effect -> Effects like poison, stunning, and so on

Item -> A thing that can be used, picked up, etc.

EquipableItem -> Something like armor, a weapon, etc.

Weapon -> An equipable item that can be wielded as a weapon

Dungeon (NYI) -> The container for a dungeon level, generates levels, etc.

[Derakon]

Haven't taken a look at your code just yet, but I did spend some time thinking about how the dungeon should be set up; here's my take on it:

The Dungeon is, largely, a 2D array of Tiles. Tiles in turn are containers for Creatures (monster/player), Terrain (doors/traps/stairs/etc.), and Items. Everything in a Tile can be interacted with -- for example, if the player chooses the "open" action, then you can look for adjacent Tiles that have closed doors or chests; applying that action to something can mutate it (closed door => open door) or generally change game state (closed chest => open chest and spawn items). Thus each class (Creature, Terrain, Item) needs to have a list of valid interactions that can be performed with it, along with the code to invoke when that interaction is done. A Creature's list could include e.g. Move (if the player moves into a monster, do an attack; if monsters move into each other, either block/swap/destroy depending on the moving monster's flags), Bash, and Target. Each interaction, in turn, has a range specification, which could be either a distance (0 = only current tile, 1 = adjacent tiles, etc.), be everything in LOS, possibly include inventory and equipment, etc.

Anyway, back to work for me, but I hope this proves useful if in no other way than in helping you justify your own design decisions.

[Sirridan]

I was thinking of something along those lines, either one 2D array with a container holding everything for every cell, or multiple arrays, each holding containers only for their type, such as one for terrain, one for creatures, one for items, etc.

For now, I think I'll do the first one, unless it becomes too cluttered, then I'll separate it out into multiple arrays for cleanliness.

[Derakon]

One 2D array that holds containers is functionally identical to multiple 2D arrays that each hold different kinds of objects; however, the first is easier to work with.

[Sirridan]

Added DungeonCell (container for things), and TerrainFlags (flags for the current terrain object)

[Pete Mack]

I think you don't want "Thing" as your base object; Object is already available for that.

I think you're going to want:
GridPoints (locations)
Terrain (Traps, Granite, etc)
Item
Monster

Consider the case of a Xorn vs a Horned Reaper. The former has KILL_ITEM, the latter KILL_BODY.
That means you will need two visitor functions, one to delete items from a grid point, the other to delete monsters.
Sure, you can create another base object type, but don't call it Thing--that's just a synonym for Object.

Edit:
I suspect what you are trying to do is abstract from the *.txt file. That means you have a Tuple aka Record aka (yuk) Entity.
It will have an ID, a name, glyph, color, and (possibly) bitmap [both default and user-defined] for the current graphics model. It may (must?) have a description. So call it an AngbandTuple if you're old-school, or an AngbandEntity if you're new-school. Leave "things" and "objects" as part of the language.

The current implementation of the knowledge menu is based entirely on simple visitor methods. It shows just how weakly associated the different types of objects actually are. (There's almost no duplicated code between the various base implementations.) Look at

typedef struct ... member_funcs

in cmd-know.c. That's pretty much it for a shared object model between the various base classes.

Edit2: More changes for clarity.

[Sirridan]

I think you don't want "Thing" as your base object; Object is already available for that.

Yeah, for everything that can be on the map, which is why it has the ID, and the x and y coordinates, however I suppose those can be moved into the higher classes and Thing removed.

I think you're going to want:
GridPoints (locations)
Terrain (Traps, Granite, etc)
Item
Monster

Pretty much what I'm going for.

Consider the case of a Xorn vs a Horned Reaper. The former has KILL_ITEM, the latter KILL_BODY.
That means you will need two visitor functions, one to delete items from a grid point, the other to delete monsters.

This won't be a big problem.

Edit:
I suspect what you are trying to do is abstract from the *.txt file. That means you have a Tuple aka Record aka (yuk) Entity.
It will have an ID, a name, glyph, color, and (possibly) bitmap [both default and user-defined] for the current graphics model. It may (must?) have a description. So call it an AngbandTuple if you're old-school, or an AngbandEntity if you're new-school. Leave "things" and "objects" as part of the language.

The ID is unique to each type of thing and keys into data that doesn't change, like item_kind type deal. Color/glyph/bitmap are not defined in the code, the code will not care about any of that. It's all defined by the display, which will be as separate from the main code as possible. Pref-file kinda deal.

[Pete Mack]

I don't think items have XY coordinates. This is one place where "Soviet Russia" has it right...

Again, consider a generic Item. It can be wielded, in your pack, on the floor, and in a store. As for monsters, they can be on the floor, in the zoo, stuffed on your wall, or written up in the Encyclopedia of Player Knowlege.

Location is definitely an optional hasA, not an isA. ...And since there are potentially a number of things at position XY, you don't have position XY, position XY has you!

[Derakon]

Agreed with Pete. Containers that have XY coordinates may hold items, monsters, etc. Those items/monsters/etc. can then determine their location, if necessary, by asking their container where they are.

[Sirridan]

So you're saying each point on the map, call it a 'cell', will have the position? Hmm, I guess I like that actually, when monster AI is called, the cell could pass its x,y info to the monster (or whatever) so the monster doesn't really have to care what its x,y is.

So Thing will get dropped in it's entirety, but I'll keep LivingThing so I don't have to rewrite code between Monster and Player that I've already done.

[Derakon]

Monster and Player should definitely be subclasses of the same base class, since they share many things in common. Personally I'd call the base class Creature, but that's just me.

[Pete Mack]

Seconded. I also figured Creature or Animate was the way to go. After all, Undead aren't living...

[Nick]

Monster and Player should definitely be subclasses of the same base class, since they share many things in common. Personally I'd call the base class Creature, but that's just me.

An ELO fan, perhaps

[Pete Mack]

On further thought, take a look at the knowledge menus and various *.txt tables in ../lib/edit in various versions of Angband. (Including eg ToME, NPP, FA, Isoband, UnAngband.)

Your object model should plan for all of these relations.
* Spells
* Objects (with optional hasA spell list)
* Terrain Feature
* Display panel (Isoband)

A few other pointers:
You will need a whole lot of Listeners on game turns ... basically everything in dungeon.c`process_world()
While the process_world() model is poor, the class-level registration model for a big feature like this is worse. You're going to need a data-driven [tabular] registration model for this, too.

[Tiburon Silverflame]

Not to be pedantic, but Spell is not quite the proper base class...Effect is. This allows 5 sub-classes:

Spell (for @'s spells)
MonsterSpell (for those mana bolts, nether bolts, and such)
BreathWeapon
TrapEffect
ItemEffect