pyAngband's thread

[Pete Mack]

@Tiburon...
Yes, that is pedantic

Spell has a long history in *Band for this kind of thing (spell effects used to be called x-spell.c in the bad old days.) So I stick to "Spell" for some kind of non-standard "invoked" action.

Don't forget, there are other Effects, such as move, shoot, attack, open, disarm, bash, etc.

For this model, what we have now is Command. You might want to generalize it to Action, which basically is a map() call to a group of objects.
(The objects may area, or it may be a player, grid point, or monster alone.)

Actions:
* on behalf of an actor
* take a unit of time (decremented from the actor)
* have an (uniform) affect on a set of Objects, determined by some apply function.


Of course, this kind of thing is bog-standard FP and OO modeling. It's a very cool problem.

Best of luck!

[Sirridan]

Spell type things take the "caster", "target", and "world" as arguments, just to be standard. A potion of cure light wounds will not care about target or world, but *destruction* does not care about target, etc.

Still no work till Tuesday, so I'll do what I can to have a basic thing working. I want at least a few weapons, armors, an ego or two, maybe an artifact, and a test monster and one or two consumables, just so I (we? ) can get this design model somewhat more concrete before continuing further.

[Sirridan]

Tval and Sval's are being worked on, here's some output:

>>> SVAL_NAMES['edged'][1]
'Dagger'
>>> SVAL_NAMES['edged'][0]
'Long Sword'
>>> SVAL_NAMES['edged'][5]
'Falchion'
>>> SVAL_NAMES['edged'][BLADEOFCHAOS]
'Blade of Chaos'

[Sirridan]

Man, made some big changes to things.

For now, edit files are just big python dictionaries, just formatted to be easy to read.
Item, Creature, Monster, etc, just copy the values into their own class, much like how it already works in V.

Will upload later, so essentially, everything that's on Git now is being replaced.

[Tiburon Silverflame]

If Effect covers move, bash, et al...that's IMO VERY poor wording. Move is not an effect, it's an action.

And the reason I prefer 'Effect' to 'Spell' is that it's more general; it covers spells, plus things that can't be construed as a 'spell', like a breath weapon. Also, 'Spell' doesn't work well for side effects, such as "hit to confuse" which does damage, AND has an Effect of possibly confusing the target.

The better hierarchy is something like this:

Command: operates strictly at the UI level. There are non-action commands, such as setting options.

Action: move, shoot, bash, browse, cast spell, etc. These are the actor's options to interact within the game. Actions have very few options *in themselves*...most of the options exist at the next level down. That is: when you cast a spell, the *spell* knows its targeting options. With something like 'activate a wand', the detailed sequence would be:

action:
invoke item
update world

item:
check for legal use (has charges left)
go through Effect (my use) to determine targeting.
make activation attempt;
if successful,
apply Effect to Target
decrement charge count/force item recharge
end
exit

Move, open, attack, bash, disarm, and tunnel (at least) all have 1 parameter: direction. Fuel, Read, Quaff, Use staff, Aim wand, Zap, and Activate all use the Invoke Item model. Fire and Throw use ranged targeting, which should be a static call (with a param of max range) which is also used as necessary for Effect's targeting.

Effect has, I believe, the following:
--representation of the effect (what does it do): its apply() method
--range
--target (self, square, or 'victim')
--target type (self, monster, or world)

'victim' is used for side effects, such as Hit to Confuse. Hit to Confuse is an Attack, so its parameter is direction. Its apply() makes the swing, and assuming a hit, does the damage, THEN calls a ConfuseTarget Effect with a set target (the critter to which the damage is being applied) and applies it.

Note that this creates a very natural approach to create, for example, Confusion or Slow weapons/ammo for @'s use, as well as facilitating all the monster special attacks.

[Derakon]

Moving is an effect that is invoked when the player presses one of the movement keys, which teleports the player from one square to an adjacent unoccupied square. I don't see the problem. There's no need to differentiate between simple and complex actions if you can contain them both under the same umbrella without jumping through hoops.

[Tiburon Silverflame]

Because it's not nearly as clear, Derakon. You're intermingling 3 logically different things: Command, Action, and Effect. Those are distinct, and are NOT handled necessarily the same, all the time. This is a uniform, cascading sequence: Command invokes UIRequest or Action; Action has fairly extensive specific implementers, but probably only a very few patterns which can largely be re-used.

But the key is the well-defined, clear stages. VERY extensible, VERY maintainable.

[Sirridan]

In terms of pyAngband, here is how these types of words are defined:

Effect: Something that happens after an item is used, such as a potion, wand, artifact activation.

Action: Anything the player does. (Or monster)

Command: What the user tells Angband to do, Actions can be the result if the command is valid.

In terms of code, right now Effects are functions defined like this:

def some_effect(thing, target, world):
    #thing is whatever creates the effect, such as the potion, or spell
    #target is the target of the effect, this can be None
    #world is the current dungeon level, important for effects like *destruct*, -teleOther, etc and of course to have access to the world itself to do targeting ;)

Each item, spell, or what have you has it's own effect key, which then allows the code to select an effect from a dictionary of effects, so that code can be reused. Cure light wounds is cure light wounds even if from a staff, potion, priest, or mage. However this could pretty easily change.

EDIT: Code for how I'm doing things, just for others to critique:

Potion edit file:

    TV_POTION:   {
        POT_CURELIGHTWOUNDS:   {
                weight: "4",
                value: "30",
                rarity: "0",
                depth: "0-15", 
                thrown_damage: "2d3",
                effect: (EFF_CURELIGHT, 0, 0)
                }
        }

Effect file:

def cure_light_wounds(target, world):
    print "Cure light wounds!!!" #Obviously not yet implemented (nyi)...

effects = { EFF_CURELIGHT : cure_light_wounds }

[Sirridan]

I have a few thoughts on edit files, since Magnate mentioned a new syntax that Elly did, plus the fact that making them as just python code like I have been is a bit tedious.

Anyway, I have come up with two axioms for such files:

1. A correctly constructed edit file shall not break code. A correctly constructed edit file is one where all entries are complete and have proper formatting.

2. Any addition or subtraction from the edit files shall not cause pyAngband to fail if and only if any changes leave the edit file correct.

So, with that, I want everything in the edit files to be as separate from the code as possible.

I thought this posed a problem for dungeon generation at first, but I figured that you can separate out some terrain types so that it doesn't break.

One terrain type must be OPAQUE and UNBREAKABLE like current Angband's permanent rock. Another type must be OPAQUE and BREAKABLE like current Angband's Granite. Digging code will assume these types exist, and provide them if they do not (at least these two types).

Another thing is object classes (TVAL) and object subclasses (SVAL) will be purely defined in edit files, which means all my work on objects and items will need to be scrapped... oh well.

I'm also thinking about making spells and effects defined in the files as well, what would you guys think? This would mean having a bunch of very generic spell functions which can be chained together into one spell. Examples:

Magic Missile: SpellType = Bolt, SpellElement = Mana, Effect = [Damage(2d4)], Range = 15

*Destruction*: SpellType = Area, SpellElement = None, Effect = [Remove(Monster, Item),Earthquake(), ApplyStatusCaster(Blind, 2d4)], Radius = 15

Stuff like this, so that most of the game can be defined in edit files, and in that way many variants could be created *without* changing any of the basic pyAngband code.

Any thoughts?

[Derakon]

I'm leery of making magical effects be in edit files in a non-code format, mostly because it means you'll end up writing your own language to be general enough to encompass all the kinds of effects you want. Or else you end up with the current system where you can't usefully create new magical effects without modifying the code anyway.

That said, not everything has to be code. I could certainly see an argument for having monster entries be more concise than a Python dict, for example, if for no other reason than that writing out the keys of the dict would get old fast (creating highly redundant files). Ultimately, you should use the right tool for the right job, and the right tool for one edit file may not be the right tool for another edit file.

However, I also think there's a lot of value in having a simple, if clumsy, system that works so you can focus on more important issues. If you have working monster loading right now, then who cares if it's not ideal? Your first goal, right now, is to get the code to a state where you can do basic in-game actions (create a character, wander around, interact with a monster, pick up an item, equip it). Once that's done you're much closer to being able to get other people helping you out. You can swap out the edit-file interactions later for a friendlier format.

[takkaria]

Another thing is object classes (TVAL) and object subclasses (SVAL) will be purely defined in edit files, which means all my work on objects and items will need to be scrapped... oh well.

I've been staying out of this thread, but maybe it would be useful if I fed in what I'm thinking.

I would suggest it is better to get something less "correct" and working rather than more "correct" and nonexistent. Choosing your class hierarchy and expecting it not to have to be refactored significantly when you actually start writing the proper game code is extremely optimistic, to say the least... It is better just to get going and try and get the game logic in there ASAP.

When it comes to what you said above about keeping tvals entirely defined outside the game, I thought this through for V and decided it wasn't that useful an idea. There may be advantages to defining some aspects of their behaviour in edit files, but for them to be *entirely* defined there would be mostly pointless.

First, I'm not sure how to handle money being defined entirely in edit files-- you need special generation functions to assign it value, and to handle picking it up. Dungeon generation wants to make gold sometimes-- e.g. in vaults. As does your monster drop code.

Second, wielding, wearing, and taking off can all be done easily enough (tval -> equip slot mapping), but then you come to 'E'ating and 'q'uaffing. You could have each object class have a flag saying "this class can be eaten", "this can be quaffed", etc., but I don't see the point. It doesn't actually gain you any flexibility, since commands can only be defined in code anyway, so you'd effectively be writing a fair bit of extra code for very little gain.

The reason the edit files work is because each instance of those classes is more or less the same, give or take a few values, but the difference between classes is not expressible except in those places in the code where the difference matters. In other words, you're not going to get rid of special-casing by moving stuff to the edit files, because gold *is* a special case, as are (the behaviour of) potions, and staffs, and wands...

Your axioms seem to be trying to idiot-proof the edit files. Maybe you should rethink that. I don't think there's any harm in requiring gold to be defined in object.txt, or that it's a requirement that the game should function with empty/missing edit files (which is a consequence of your second axiom).

Oops, that was a bit long. I'll keep quiet in future.

[Sirridan]

Oops, that was a bit long. I'll keep quiet in future.

Quite the contrary, I hope you don't! I'm trying to post my thought process more so that I keep more motivated to keep working (since maybe someone out there wants to see results) and two to get advice, especially from those who have worked on maintaining V and/or variants thereof.

So thank you

I'll push more code out tomorrow or Sunday, with something "playable".

[Sirridan]

It's "Playable" hah, you can move an '@' around the screen. Hopefully tomorrow there will be a character pane, and the ability to equip/drop items!

EDIT: Windows only, I may/may not post the curses version for linux folks, depends if I can get a chance later tonight before bed.

[Sirridan]

Thinking again, how should I handle display? I'm thinking of two options:

1. Angband has a "Display" class which follows a certain interface (to hide implementation) so Angband does not know HOW things are displayed, but still controls where and such (IE it knows about screen size, text resolution, all that). This is how Vanilla does it I believe.

2. Angband provides information about what is going on so that the game client controls how and what is displayed.

Any thoughts? They both have their advantages, with number 1 making things easier to port (in general) because you just plug-and-play display functions. The second one keeps display code away from game logic nearly entirely, so game changes are easier but client code is more difficult to maintain. I'm a bit stuck on the fence on this one.

[takkaria]

Thinking again, how should I handle display? I'm thinking of two options:

1. Angband has a "Display" class which follows a certain interface (to hide implementation) so Angband does not know HOW things are displayed, but still controls where and such (IE it knows about screen size, text resolution, all that). This is how Vanilla does it I believe.

2. Angband provides information about what is going on so that the game client controls how and what is displayed.

Any thoughts? They both have their advantages, with number 1 making things easier to port (in general) because you just plug-and-play display functions. The second one keeps display code away from game logic nearly entirely, so game changes are easier but client code is more difficult to maintain. I'm a bit stuck on the fence on this one.

V is moving (roughly) from 1 to 2. Conceptually it's a little more difficult but the payoff should be worth it.