Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Variants

Reply
 
Thread Tools Display Modes
Old April 22, 2012, 20:41   #21
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 5,054
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate Send a message via Skype™ to Magnate
Quote:
Originally Posted by Derakon View Post
By "hierarchy of message categories", are you saying something like "each message has a priority, and we display all enqueued messages in priority order"? That might work, but what we really want to ensure is that related messages show up together, and I'm having trouble seeing how we'd do that with a message prioritization scheme unless each message knows about the other messages that have already happened so it can position itself appropriately...and that sounds complicated.
Well, by 'hierarchy' I meant something like (off the top of my head):

- initiation messages (entity X starts action Y - "it mumbles", "you activate it")
- action messages (effect X reaches target Y - "something hits you", "the foo glows brightly")
- reaction messages ("the critter shrieks in pain")
- consequence messages (effect X affects target Y - "you feel yourself moving slower", "the foo is empty")
- cleanup messages ("you combine some items in your pack", "the critter is no longer afraid")

... so I was envisaging a 'threading' mechanism where the same effect would have its messages threaded together and presented in that order, iterating over targets, unless it triggers another effect etc.
Quote:
The short version of this is that you need to make your program exactly as abstracted as it needs to be, and no more. If it's insufficiently abstracted, then making minor changes becomes painful (imagine if every monster were defined in the code, with no monster.txt). However, if it's excessively abstracted, then making minor changes becomes painful again (because the abstraction introduces its own layers of complexity) and the engine becomes impossible to work with because it has to deal with all those abstractions.
Yes, I see that - thanks for the excellent illustration with the tax example.
Quote:
My current plan for spells is that spellbooks will be containers that hold spell "items". So it's not that the spellbook will have an onUse effect, but that the spell in it will. In the sense that every spell is a conceptual item, then, spellcasting will work the same for psionics as for normal spellcasting. The big question with psionics is how to handle bookless casting. I admit to not having a good answer for that right now.
Your system should work providing one can have a non-object container for spells (@'s mind). As you say, the spell itself is the OnUse item, not the container.
Quote:
I'm not going to try to replicate every possible trigger right now -- that's detail-filling-in work. There will be room for those in the engine though. Adding a new trigger should just be a matter of adding new functions and then calling them at the appropriate times.
That's great, but I hope this doesn't apply to effects themselves. My aim was to enable new effects to be created in edit files by defining their targets, range/duration and what they modify (be that knowledge, terrain, stats, etc.) Were you thinking along the same lines?
Quote:
It's clear that various parameters for the effects will need to be able to take "arguments" of some kind so we can generate values the way we want to. For example, damage scaling with the user's device skill, level, hitpoints, etc. There's various more- or less-complicated methods that could be used here (anywhere from "adapt the "10+4d6M8" system" to "pass this string to eval()"); I'll need to spend some time evaluating my options.
Ok, that's fine - I wondered for a moment whether you were going to decide that effects shouldn't take variable arguments, that's all.
Quote:
Some of this will be down to Terrain stuff, some of it to Item instances. Terrain instances (which include the basic empty floor) will include their light levels, and like other entities will need to track how much the player knows about them. Likewise, at some level we'll have to store "player knows what this thing is", "player knows where this thing is", and "player knows this thing exists" booleans. These will probably be properties that go all the way up to the basic Thing class, since I can see uses for "I know there's an X there, but not what it is precisely" for items, monsters, and terrain as well (c.f. traps).
That sounds fine, though I'm not sure I understand "other entities will need to track how much the player knows about them" - it reads as if "them" refers to "terrain instances" - if that's right, why wouldn't the terrain instances themselves track what the player knows about them?
Quote:
My current assumption is that procs will invoke "bolt", "ball", "LOS", etc. handlers, which will then do the appropriate breakdown.
Right, this is exactly what I was trying to refactor out of the current codebase. The ball/bolt/los handlers are just wrappers for project(), so why not specify the details in the effect itself?
Quote:
I do want to emphasize that Pyrel is still more talk than action so far. There's only so much you can do in 2k lines of code! But I do appreciate all the feedback and support I've been getting from this forum. Hopefully Pyrel will soon be at the point where other people can start poking at it.
Looking forward to that, but however long it takes you're to be congratulated on the clarity and thoroughness of your thinking - typing in the code is trivial by comparison.
__________________
"3.4 is much better than 3.1, 3.2 or 3.3. It still is easier than 3.0.9, but it is more convenient to play without being ridiculously easy, so it is my new favorite of the versions." - Timo Pietila
Magnate is offline   Reply With Quote
Old April 22, 2012, 22:48   #22
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,047
Derakon is on a distinguished road
Quote:
Originally Posted by Magnate View Post
Well, by 'hierarchy' I meant something like (off the top of my head):

- initiation messages (entity X starts action Y - "it mumbles", "you activate it")
- action messages (effect X reaches target Y - "something hits you", "the foo glows brightly")
- reaction messages ("the critter shrieks in pain")
- consequence messages (effect X affects target Y - "you feel yourself moving slower", "the foo is empty")
- cleanup messages ("you combine some items in your pack", "the critter is no longer afraid")

... so I was envisaging a 'threading' mechanism where the same effect would have its messages threaded together and presented in that order, iterating over targets, unless it triggers another effect etc.
Hm, I'm still not quite understanding, but I think there'll be time enough to deal with this later.

Quote:
That's great, but I hope this doesn't apply to effects themselves. My aim was to enable new effects to be created in edit files by defining their targets, range/duration and what they modify (be that knowledge, terrain, stats, etc.) Were you thinking along the same lines?
To the extent that a new effect doesn't require anything fundamentally different from an existing effect, they should be fully specifiable without modifying the Python code. So for example, if you have a "slow monster" effect, you can make new bolts/beams/balls/LOS/selected-target-species "slow monster" effects based on it. But you couldn't make an effect that slows only monsters that are at full health, because we don't have any existing effects that use that conditional.

Quote:
That sounds fine, though I'm not sure I understand "other entities will need to track how much the player knows about them" - it reads as if "them" refers to "terrain instances" - if that's right, why wouldn't the terrain instances themselves track what the player knows about them?
What I meant is that every entity -- every Terrain, Item, and Creature instance -- needs to track what the player knows about it. Items need to know if the player knows their type, which runes have been ID'd, etc. Creatures need to know if the player knows their species and subspecies (assuming we do something like fuzzy telepathy). Terrain needs to know if the player has ever seen it or can see it right now.

Quote:
Right, this is exactly what I was trying to refactor out of the current codebase. The ball/bolt/los handlers are just wrappers for project(), so why not specify the details in the effect itself?
I'll need to look at what project() does exactly -- it's not code I've ever really investigated -- but if I find myself writing lots of code that's basically "simple redirect" code (e.g. the "bolt" proc just calls project(BOLT) or whatever) then certainly that's the kind of thing that should be moved to the edit files.
Derakon is offline   Reply With Quote
Old April 22, 2012, 23:29   #23
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 5,054
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate Send a message via Skype™ to Magnate
Quote:
Originally Posted by Derakon View Post
To the extent that a new effect doesn't require anything fundamentally different from an existing effect, they should be fully specifiable without modifying the Python code. So for example, if you have a "slow monster" effect, you can make new bolts/beams/balls/LOS/selected-target-species "slow monster" effects based on it. But you couldn't make an effect that slows only monsters that are at full health, because we don't have any existing effects that use that conditional.
Yes, and doing that in edit files would get you to the making-your-own-language problem. But I was thinking of a slowing effect that only affected dragons, for example. We don't have exactly this effect at the moment, but if the code allows "all entities in LOS with RF_DRAGON" as a valid target, it should be possible to create it without any new code. That's the kind of thing I was getting at.
Quote:
What I meant is that every entity -- every Terrain, Item, and Creature instance -- needs to track what the player knows about it. Items need to know if the player knows their type, which runes have been ID'd, etc. Creatures need to know if the player knows their species and subspecies (assuming we do something like fuzzy telepathy). Terrain needs to know if the player has ever seen it or can see it right now.
Yes, exactly. Great.
Quote:
I'll need to look at what project() does exactly -- it's not code I've ever really investigated -- but if I find myself writing lots of code that's basically "simple redirect" code (e.g. the "bolt" proc just calls project(BOLT) or whatever) then certainly that's the kind of thing that should be moved to the edit files.
project() is the function that actually iterates over every grid in range and applies the effect to that grid - calling out to project_[m|p|o|f] if it needs to apply an effect to a monster, player, object or feature. The main reason I wanted to refactor effects in the first place was because of the limitations of this setup (e.g. the stuff I mentioned about variable amounts/durations/saving throws not being resolvable once you're inside project). I figured that moving the beam/bolt/LOS type determinants out to edit files would be better - but I'm happy to wait until you get there and see what you think.
__________________
"3.4 is much better than 3.1, 3.2 or 3.3. It still is easier than 3.0.9, but it is more convenient to play without being ridiculously easy, so it is my new favorite of the versions." - Timo Pietila
Magnate is offline   Reply With Quote
Old April 23, 2012, 02:18   #24
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,047
Derakon is on a distinguished road
Just a quick status update -- the first pass at a proper "equip item" command is done. Items go to their proper slots, and if another item's already there, it's unequipped. I haven't yet decided how to handle the prompting where there's ambiguities (e.g. trying to wield a ring when there's already two equipped rings); my current Prompt framework may need to be expanded. But I'm saving that for later -- let it percolate in my subconscious while I work on other things and maybe I'll have a good idea.

(Quick lesson on programming: if you've been working on the same problem for more than half an hour, or maybe even just fifteen minutes, and you're no closer to finding a solution, then stop working on it and do something else. You'll make no more progress by holding at it, and odds are good that other activities will jostle the appropriate neurons to guide you to a good solution)
Derakon is offline   Reply With Quote
Old April 23, 2012, 11:51   #25
Gorbad
Apprentice
 
Join Date: Sep 2008
Posts: 73
Gorbad is on a distinguished road
Quote:
Originally Posted by Derakon View Post
Hm, I'm still not quite understanding, but I think there'll be time enough to deal with this later.
Probably something like (forgive the not 100% correct Angband messages)

Code:
[
    {"messages":{
        "init":["it mumbles"],
        "action":["something hits you"],
        "result":["you feel your life draining away","you feel less powerful"],
        "cleanup":["you die"],
        },"actor":"monster_123"
    },
    {"messages":{
        "init":"you activate the Bronze Wand",
        "action":["it glows brightly"],
        "reaction":["the snaga shrivels away in the light!","Ugluk the Uruk is unaffected!"],
        "result":["the Bronze Wand of Light has no charges left","you no longer have the Bronze Wand of Light"],
        "cleanup":["you combine some items in your pack"]
        },"actor":"object7"
    }
]
Where you first buffer all the messages and can then iterate over the actors, and print their messages in order.
Gorbad is offline   Reply With Quote
Old April 29, 2012, 20:47   #26
Narvius
Knight
 
Narvius's Avatar
 
Join Date: Dec 2007
Location: Poland, Katowice
Age: 25
Posts: 588
Narvius is on a distinguished road
The only sane way to handle multiple eligible equipment slots is likely to diplay a list of possible slots and let the user pick one. Especially once we consider monster races anything less specific starts to fall apart.
Even if we consider two ring slots, one occupied, one free, and the user equipping an additional one, automatically filling the free slot may not always be the desired behavior.
__________________
If you can convincingly pretend you're crazy, you probably are.
Narvius is offline   Reply With Quote
Old April 29, 2012, 21:46   #27
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 5,054
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate Send a message via Skype™ to Magnate
Quote:
Originally Posted by Narvius View Post
The only sane way to handle multiple eligible equipment slots is likely to diplay a list of possible slots and let the user pick one. Especially once we consider monster races anything less specific starts to fall apart.
Even if we consider two ring slots, one occupied, one free, and the user equipping an additional one, automatically filling the free slot may not always be the desired behavior.
I haven't seen the code yet but I'd hope it's flexible enough for a variant maintainer to define extra equipment slots in a single place (array, dictionary, whatever) ... and then define object types that can be wielded in those slots. Further down the road there will be display issues (I'm thinking less of the equipment screen than the character sheet), but I assume there won't be hard-coded references to slots anywhere in the game engine.
__________________
"3.4 is much better than 3.1, 3.2 or 3.3. It still is easier than 3.0.9, but it is more convenient to play without being ridiculously easy, so it is my new favorite of the versions." - Timo Pietila
Magnate is offline   Reply With Quote
Old April 29, 2012, 22:29   #28
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,047
Derakon is on a distinguished road
The plan, which isn't yet fully implemented, is that any time there's an ambiguity about where an item could be meaningfully equipped to, the user will be prompted for choice. That means that if an item can only go to one slot type, and the user only has one slot of that type (e.g. normal Angband and weapon slots), then the item is automatically equipped to that slot, displacing whatever may be there already. Likewise if there's only one eligible type and there's a free slot of that type, then the item automatically goes there (e.g. equipping your first ring). If all eligible slots are occupied, or there's multiple eligible slot types, then the user is prompted.

The only use cases I can think of for items that can go in multiple equipment slot types are bastard swords (one- or two-handed) and maybe shields (on the arm or strapped to your back), but that's enough that it seemed worth designing in from the start.

Quote:
Originally Posted by Magnate View Post
I haven't seen the code yet but I'd hope it's flexible enough for a variant maintainer to define extra equipment slots in a single place (array, dictionary, whatever) ... and then define object types that can be wielded in those slots. Further down the road there will be display issues (I'm thinking less of the equipment screen than the character sheet), but I assume there won't be hard-coded references to slots anywhere in the game engine.
Equipment slots are defined entirely in the edit files -- you declare which slot types a creature has and how they're described, and items declare which slot types they can be equipped to. In the event that an item cares about which slot it is equipped to, that would probably be handled in code by a proc.

For example, the player's creature template:
Code:
{"name": "player",
"display": {"ascii": {"symbol": "@"}},
"category": "You",
"type": "player",
"equipDescToSlot": {
        "for melee": "weapon",
        "for ranged": "launcher",
        "on left finger": "finger",
        "on right finger": "finger",
        "around neck": "neck",
        "providing light": "light source",
        "on body": "body",
        "on back": "back",
        "providing cover": "shield",
        "on the noggin": "head",
        "on hands": "hands",
        "on feet": "feet",
        "holding ammo": "quiver"}
},
and the amulet template:
Code:
{"type": "amulet", "templateName": "amulet",
"display": {"ascii": {"color": "flavor", "symbol": "\""}},
"equipSlots": ["neck"],
"flags": ["FLAVORED"],
"weight": 0.3},
Status update: I'm still working out the best way to handle equipment that give bonuses to other equipment when wielded (and other similar effects). I need to refactor some code, too -- procs are going from being standalone functions to being class instances, so they can preprocess their arguments. I hope to get some of that done later today.
Derakon is offline   Reply With Quote
Old April 29, 2012, 23:16   #29
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 5,054
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate Send a message via Skype™ to Magnate
Quote:
Originally Posted by Derakon View Post
Equipment slots are defined entirely in the edit files -- you declare which slot types a creature has and how they're described, and items declare which slot types they can be equipped to. In the event that an item cares about which slot it is equipped to, that would probably be handled in code by a proc.
It's funny, I nearly said that I hoped equipment slots were entirely configurable in text files, then I remembered your previous post on the limits of that - but I'm really glad to see that they are.

Can you tell me what you mean by "proc"? Google's first result is the definition I use - http://www.wowwiki.com/proc. But I suspect you mean something more like the 5th result? A sort of multi-purpose function?
__________________
"3.4 is much better than 3.1, 3.2 or 3.3. It still is easier than 3.0.9, but it is more convenient to play without being ridiculously easy, so it is my new favorite of the versions." - Timo Pietila
Magnate is offline   Reply With Quote
Old April 29, 2012, 23:52   #30
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,047
Derakon is on a distinguished road
Quote:
Originally Posted by Magnate View Post
Can you tell me what you mean by "proc"? Google's first result is the definition I use - http://www.wowwiki.com/proc. But I suspect you mean something more like the 5th result? A sort of multi-purpose function?
I'm using "proc" to refer to a set of functions that can be referred to (and parameterized) in the edit files, keyed to "go off" on various trigger conditions. So for example, if you had a D&D-style "flameburst" weapon (has a chance to deal 2d6 flame damage on striking), then the object entry would have an "onStrike" condition that invoked the "damageOpponent" proc with parameters "2d6" and "fire". "damageOpponent" would then be a function in the main code base that looks up the target of the attack and invokes some more generalized function to deal some amount of damage (in this case, 2d6) of some appropriate element (in this case, fire) to that target. That generalized function would take into account resistances and things of that nature.

The standard definition of "proc" that I'm aware of is like the flameburst enchant -- it's an effect that can occur when you hit something (in the case of weapons) or are hit by something (in the case of armor). I'm extending that to include more trigger conditions and to allow for non-instantaneous effects though.

The reason I need to refactor the procs to make them into class instances instead of straight-up functions is that some procs will have an effect that is variable on an item-to-item basis but constant for any given item. For example, Rings of Prowess have an onEquip proc that attaches a prowess bonus to a specific equipment slot; the bonus is constant for a specific ring but different rings give different bonuses. If I just left the proc as a straight function then each time you called it, it'd have to recalculate the bonus and would give a different result every time -- and of course, you wouldn't be able to tell what the bonus was without equipping it, since it wouldn't display properly in ID.
Derakon is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Angband 3.5-dev Magnate Vanilla 70 July 2, 2012 17:47
JBand progress log. PaulBlay Development 38 June 27, 2009 10:19
Hackers triumph over pricing.log beast-file ... Magnate Vanilla 3 April 23, 2009 00:00
Angband/65 development log PaulBlay Development 0 April 16, 2009 19:55
Export entire message log to text file PaulBlay Vanilla 2 February 28, 2009 20:24


All times are GMT +1. The time now is 06:10.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2017, vBulletin Solutions, Inc.