vValue and DCT

What do you want to see in Armagetron soon? Any new feature ideas? Let's ponder these ground breaking ideas...
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

I don't feel like naming something that I think is redundant. What exactly does the tree thing give us that scripting doesn't? I haven't seen one thing so far.

One more detail question: How would we export settings/properties/classes from C++?
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

z-man wrote:I don't feel like naming something that I think is redundant. What exactly does the tree thing give us that scripting doesn't? I haven't seen one thing so far.
Already went over that:
Luke-Jr wrote:- Speed and efficiency
- Better prediction
- No scripting overheads
z-man wrote:One more detail question: How would we export settings/properties/classes from C++?
Implementation detail-- I'm not aware of any sane way to do this in C++, short of something like libffi or SWIG.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

Luke-Jr wrote:Already went over that:
Those were the advantages of vValue over script. That's fine. But I STRONGLY doubt that the resolving a tree node by name and converting its value to a specific C++ type is going to be so much faster than script that it's worth caring about. You have to do exactly the same things as you have to do in script: some map lookups from string to tree nodes, checking whether what's there is the right type, and doing an eventual conversion. There is zero room for high level optimization of that process. Plus:
Luke-Jr wrote:I'm not aware of any sane way to do this in C++, short of something like libffi or SWIG.
So it's either going to be insane to specify it in C++, or you have to define the properties externally in XML and the C++ code has to access them via the interface, doing map lookups and conversions at least once per value? So we can choose between inefficiency and hell?

Oh, and it's not an implementation detail as far as I'm concerned. How we programmers are going to use the system is part of its interface. The fact that the players won't see it doesn't matter.
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

I suspect scope creep. :) I thought this was originally just some new way to organize config items? Seems to have grown. A sure sign of scope creep is when a sentence of the form "<something> was originally <something>, but now has grown to <something else>". Which has happened here.

I'm with Meriton, now. Let's have some requirements and specifications before we go much further. Otherwise we're just measuring solutions against each other, when we should be measuring them against the problem they solve.
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

Ok, here's what I demand of a configuration system:
Z-Man's core requirements wrote:- A console mode, available for input on the server and the client. Commands should be as simple as possible, anything more than the name of the setting to change and the value is overhead. The console should also have simple commands for starting new matches, kicking players, that kind of stuff. Again, as little text as possible.
- Configuration scripts where everything you can do at the console, you can do in a file just the same way.
- A subset of the settings should be persistent between sessions.
- A subset of the settings on the client should be server-determined.
- It needs to be simple to add configuration items/commands where they are needed, that means script, resources and C++.
Apart from the last point where things could be a bit simplified (and obviously would need expansion to script and resources), the current system fullfils the minimal requirements. But there are already two areas where the current system proves to be limiting: the configuration for the four local players and the game settings, separated in single player and multiplayer settings. In both of these cases, there are identical groups of settings that just affect different objects; neverheless, you have to make each copy known to the script separately. Other cases like that are on the horizon: you want different physics settings for each team, maybe also different settings for specific team members (think of a special inner goalie in Fortress that has an extra short tail; there also was already the request for fortress zones with different settings) This needs to be improved; therefore, the next-to-minimal requirements:
Z-Man's extended requirements wrote:- It needs to be possible to create multiple copies of a group of settings and apply those copies, with then possibly different values for the settings, to different objects in the game. Creation and application of this don't need to easy, but changing the settings of one copy of the group needs to be just as easy as setting any other configuration item.
Hence my belief that a tree structure is required (to define the setting groups to copy in the first place and to keep the copies organized.)
Bonus requirements wrote:- There should be a mode where copying of config groups is cheap and modifying an original setting will also affect the copy setting as long as the copy has not been touched.

- You should be able to access configuration items from resources, so that you don't have to make 10 maps that only differ in the fortress zone size; instead, you should be able to make the zone size configurable.

- You should be able to compute settings from other settings; wherever you are able to use a setting, you should be able to use directly a function of settings (this goes without saying in script and C++, but is not a given thing in resources)
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

So, your post carries the implication that it needs to be possible to associate a group of settings or a specific setting with a group of objects or a specific object, and to specify a relationship for the association.

Currently we have that, but it's hardcoded. We have settings that apply to one player (and the player is hardcoded in the setting name), settings that apply to all players, and settings that apply depending on whether or not it's 1 human and a bunch of bots or a bunch of humans. We'll also want settings to give specific scripts/objects to control bots, and we'll want to be able to apply them to a group of bots.

And through it all we want something simple enough to type in the console. :)

We currently have what amounts to a hybrid command/setting interface, and it sounds like you'd like to keep it, but I'm thinking we should probably separate commands from settings. We might start by doing the separation, then adding shortcuts. From BASIC:

LET $A="HI THERE!"
$A="HI THERE"

See where I'm going with that?

I like the tree/path setup in supybot so much I've copied it a few times. So we might have something like:

/cycle/wall_length 20
copy /cycle/wall_length team['red']
team['red'][5]/cycle/wall_length 5

Not terribly clean, and probably a little on the weird side, but the idea's there. First you set the wall length for all cycles, then you copy it for red team, then you set red teammate #5 to a much shorter wall length.

FOr a tree, we're not going to be able to avoid having it look like DOM, which brings with it the implication that xml could describe it. Which mixes it with resources.... :) There is a bit of grey area where resources are concerned, which is why I want to combine resources and config, it eliminates the grey area. We could then provide an alternate interface that allows expressing simpler ideas without requiring the complexity of an xml document.

Forgetting my last paragraph, I'd suggest that resources need a way to expose settings, which makes the config system pretty dynamic.

Forgetting both of the last two paragraphs, I'd suggest that all game objects expose settings, and we could use the tree structure inherent in the resource format to expose them. This has the advantage of not requiring the author to expose settings for each object that's configurable, but he still probably needs a way to expose more blanket settings that would affect many objects in the resource at once. Anyway, this might look like this:

/world/map/field/zones/customnamedzone/type DEATH
/world/map/field/zones/customnamedzone/owner Lucifer
/world/map/field/zones/customamedzone/effect owner

As for C++ access, we're looking pretty much at a DOM-like interface. We'll want to be able to do something like Config->GetSettingsFor(ePlayer* thisguy), and some other stuff that should be obvious from there. :)

Off to class!
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
meriton
Round Winner
Posts: 256
Joined: Sun Nov 20, 2005 3:33 am

Post by meriton »

Stop. We were discussing requirements, could we postpone talking about trees just a bit?

First, Z-Man's requirements speak about settings. That sounds to me like the items to be configured are assumed to have constant values throughout the game. I'd like to challenge that restriction. Ultimately, many settings describe things that change during the game, for instance the size of a zone. Presently, we have to map this using a couple of constant settings that interact in a predefined manner (in case of the zone, a function linear in time) to control the dynamic value. This interaction is hard-coded, and the source of considerable complexity in the configuration files.

I therefore suggest:
Extended Requirement 2 wrote:A configurable value may change during the course of the game.
This might be designed by defining a setting to be a function in time, and the configurable value to be the value of that function at the current time.

On a less important note, a corollary of Basic Requirement 5 and the Extended Requirement is that the inheritance relation can not be hardcoded; rather, it must be configurable itself.
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

z-man wrote:
Luke-Jr wrote:Already went over that:
Those were the advantages of vValue over script. That's fine. But I STRONGLY doubt that the resolving a tree node by name and converting its value to a specific C++ type is going to be so much faster than script that it's worth caring about. You have to do exactly the same things as you have to do in script: some map lookups from string to tree nodes, checking whether what's there is the right type, and doing an eventual conversion. There is zero room for high level optimization of that process.
What are you considering as DCT? DCT is the concept of referencing configuration/attributes/objects via a tree interface, not any particular implementation or whatnot.
z-man wrote:Plus:
Luke-Jr wrote:I'm not aware of any sane way to do this in C++, short of something like libffi or SWIG.
So it's either going to be insane to specify it in C++, or you have to define the properties externally in XML and the C++ code has to access them via the interface, doing map lookups and conversions at least once per value? So we can choose between inefficiency and hell?
or we could use libffi or SWIG, like I said. libffi lacks C++ support, but for the most part that can be fixed with a simple mangler function.
z-man wrote:Oh, and it's not an implementation detail as far as I'm concerned. How we programmers are going to use the system is part of its interface. The fact that the players won't see it doesn't matter.
DCT is a concept moreso than an interface at this point.
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

Note that DCT+vValue combined fulfill all those requirements, including Luci's description of what he wants...
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

I disagree with ERQ2 in a sense. The configuration items themselves should be constant. Anything that is not constant belongs to the game state, not into the configuration. It should be a very rare exception that a configuration item has to be retransmitted over the network during a round.

But I also agree: many things and relationships between game physics and setting values that are hardcoded right now, like the relationship between zone conquest counter and rotation speed, the relation between wall distance and acceleration, the expansion radius of the deathzone, the score distribution for zone conquests, should be configurable without writing full blown scripts. Therefore, I propose
Clarified Extended Requirement 2 wrote:A configuration item may be the representation of a function of all other configuration items, the global gamestate, the state of the game object it will affect (both in a standard format), and additional data to be specified in the documentation of that configuration item.
So, for example, the configuration item "cycle acceleration wall_distance_formula" (assuming a tree structure is chosen), giving the dependence of the cycle acceleration as a function from the wall, would specify that "distance" is set to the cycle's distance from the wall, and a possible setting could be

Code: Select all

cycle acceleration wall_distance_formula = method( (cycle acceleration)/(distance + (cycle acceleration wall_mindistance) ) )
Or anything else for method() that indicates the value should not be evaluated immediately. You could access the current speed of the cycle via "currentCycle speed" in this function, the global game time with "currentGame time". Ideally, we'd use vValue for the evaulation in the game later. But actually, all of this is not part of the configuration system, it should be possible with any system. In the extreme case of the current system, you'd just let it store the customizable functions as a string and parse them once at the beginning of a round.

Lucifer: I had written this first in the syntax where / is a config item path delimiter; that got me into trouble where "cycle acceleration wall_mindistance" was referenced. It would be required to write

Code: Select all

cycle/acceleration/wall_distance_formula = method( CONFITEM(cycle/acceleration))/(distance + CONFITEM(cycle/acceleration/wall_mindistance) ) )
to tell the parser that / does not mean division.

A problem with Lucifer's proposed automatic transformation of a XML resource into a setting tree, which I think was also what Luke suggested: That tree would need to be generated as the resource is parsed, and at that point, it is too late for the configuration to change anything. At least in the current flow of things. What could be done is, and I think I said that in some other form:
- The config file says which resource it is going to use
- At that point already, the resource is parsed with a generic parser (no grid is created) and every XML tag is turned into a tree node, and the properties are turned into settings.
- Then the configuration file can override those settings it likes to have overridden.
- When the real parser processes the resource, the values of the settings in the configuration override the values in the XML file.
It's semi-DOM; with full we could also go full DOM and instead of parsing the XML file when it will be needed, we let the grid creator scan the configuration tree. But weren't there some subtle problems with this and undefined order of the XML tags in DOM?

Luke: Now you've got me completely confused. You're saying now that really, DCT is just the concept that "It's a Tree!"? What were all your detailed answers about, then? You're giving it a name without knowing what it is? That's marketing :)

And I disagree then that it fulfills any requirements :) A vague concept, by definition, can't fulfill anything. It can, once turned into concrete specs, maybe fulfill requirements. However, since you're suggesting the possibility of using libffi as the C++ interface rather suggests that basic requirement 5 is far from fulfilled.
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

Ah yes, right, Meriton, now that you mention it, I have grouped config items together and applied them to a whole without using a tree. So that particular requirement doesn't say "we must have a tree", that can only be determined after we've figured out our requirements.

So we have: (italics indicates something added after z-man's post)
Core requirements wrote: - A console mode, available for input on the server and the client. Commands should be as simple as possible, anything more than the name of the setting to change and the value is overhead. The console should also have simple commands for starting new matches, kicking players, that kind of stuff. Again, as little text as possible.
- Configuration scripts where everything you can do at the console, you can do in a file just the same way.
- A subset of the settings should be persistent between sessions.
- A subset of the settings on the client should be server-determined.
- It needs to be simple to add configuration items/commands where they are needed, that means script, resources and C++.
- A configuration item may be the representation of a function of all other configuration items, the global gamestate, the state of the game object it will affect (both in a standard format), and additional data to be specified in the documentation of that configuration item.
- Configuration items can be changed between rounds. If feasible, some configuration items can be changed during rounds, but all config items can be changed between rounds. As a corollary, if a config item can be changed between rounds, then setting it in the current round should cause it to change for the next round, even if the setting doesn't take immediate effect.
- Configuration files and items should be easy and straightforward to exchange between people, machines, and in particular different arma processes. It should be possible for two arma processes to share config files without clobbering each other in any way. It should be possible for two or more arma processes to share some basic config files and have some specific files for themselves.
Extended requirements wrote: - It needs to be possible to create multiple copies of a group of settings and apply those copies, with then possibly different values for the settings, to different objects in the game. Creation and application of this don't need to easy, but changing the settings of one copy of the group needs to be just as easy as setting any other configuration item.
Bonus requirements wrote: - There should be a mode where copying of config groups is cheap and modifying an original setting will also affect the copy setting as long as the copy has not been touched. Let's call this "references", since that's what it is. It's a combination of referencing and copy-on-write.

- You should be able to access configuration items from resources, so that you don't have to make 10 maps that only differ in the fortress zone size; instead, you should be able to make the zone size configurable.

- You should be able to compute settings from other settings; wherever you are able to use a setting, you should be able to use directly a function of settings (this goes without saying in script and C++, but is not a given thing in resources)

- Resources should be able to expose settings to allow resource creators to make more general purpose resources that can be further customized with little effort on the part of the server admin/local game player
I'd like to point out that a function represents a value, so if configuration items are allowed to be functions, it satisfies the requirement that the value not change if the function doesn't change. Obviously we'll expect different values every time we evaluate it, but the function itself doesn't change. So if cycle rubber is configured as sin(gametime), it will be sin(gametime) for the entire round, until the simulation is tore down and rebuilt.

Some more things to throw on the pile to think about, while not necessarily being config items. Configuration doesn't need to be applied when it's loaded from the file. We can collect all the configuration items, and then apply them at the start of every round. That's a sensible approach, considering we already know we want to change configuration every round. In fact, I added it to core requirements. :)

FInally, some words on scope.
Scope of configuration system wrote: The configuration system is different than the resource system. Only in very general terms are they the same thing, in that they allow customizing the game by the end user. Otherwise, they represent different, but related, concepts. (someone else will have to elaborate this, sorry)

The configuration system provides information that is typically only of use to one person on one machine. This includes player name, server name, video hardware configuration, and so forth. Information that is of use to many people in a generalized form is to be handled in the resource system instead. (ok, so I expanded on it, I forgot where I was going with it)
Image

Be the devil's own, Lucifer's my name.
- Iron Maiden
meriton
Round Winner
Posts: 256
Joined: Sun Nov 20, 2005 3:33 am

Post by meriton »

z-man wrote:Anything that is not constant belongs to the game state, not into the configuration. It should be a very rare exception that a configuration item has to be retransmitted over the network during a round.
I propose to include the game state in this discussion. After all, the most complex use of configuration items is the configuration of the game state's evolution, there are unanswered questions in that department, and they look similar to the requirements we are discussing. In particular, core requirements 4, 5, and 6 stem from corresponding requirements for game state.

Based on these similar requirements, I suggest to explore solutions that have the potential to take care of both.
Lucifer wrote:I'd like to point out that a function represents a value, so if configuration items are allowed to be functions, it satisfies the requirement that the value not change if the function doesn't change.
That's what I was getting at :)
Lucifer wrote:Let's call this "references", since that's what it is. It's a combination of referencing and copy-on-write.
In fact, a better word might be "inheritance".
Lucifer wrote:The configuration system is different than the resource system.
I think we should define "resource system" when we refer to it in the declaration of purpose, and if I understand right (i.e. you really suggest to remove cycle physics settings from the the config system and to move them into the resource system), I think we should discuss the resource system as well.
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

z-man wrote:I disagree with ERQ2 in a sense. The configuration items themselves should be constant. Anything that is not constant belongs to the game state, not into the configuration. It should be a very rare exception that a configuration item has to be retransmitted over the network during a round.
Regardless, DCT should support ERQ2 since it moves game state into the same realm as configuration items.
z-man wrote:Lucifer: I had written this first in the syntax where / is a config item path delimiter; that got me into trouble where "cycle acceleration wall_mindistance" was referenced. It would be required to write

Code: Select all

cycle/acceleration/wall_distance_formula = method( CONFITEM(cycle/acceleration))/(distance + CONFITEM(cycle/acceleration/wall_mindistance) ) )
to tell the parser that / does not mean division.
Good point. Perhaps we can borrow :: from C++ for a delimiter.
z-man wrote:A problem with Lucifer's proposed automatic transformation of a XML resource into a setting tree, which I think was also what Luke suggested: That tree would need to be generated as the resource is parsed, and at that point, it is too late for the configuration to change anything. At least in the current flow of things.
Moving the game state into DCT would need to eliminate the "too late" stage.
z-man wrote:What could be done is, and I think I said that in some other form:
- The config file says which resource it is going to use
Under DCT, the config file (or script, or whatever) would set /currentGrid to loadResource(bla).
z-man wrote:But weren't there some subtle problems with this and undefined order of the XML tags in DOM?
Only with our usage of <Point .../> I think
z-man wrote:Luke: Now you've got me completely confused. You're saying now that really, DCT is just the concept that "It's a Tree!"? What were all your detailed answers about, then? You're giving it a name without knowing what it is? That's marketing :)
I'm saying it's the concept, not necessarily the implementation.
z-man wrote:And I disagree then that it fulfills any requirements :) A vague concept, by definition, can't fulfill anything. It can, once turned into concrete specs, maybe fulfill requirements. However, since you're suggesting the possibility of using libffi as the C++ interface rather suggests that basic requirement 5 is far from fulfilled.
In that case, libffi would be the interface from DCT to C++ objects/etc. The interface to the DCT itself would be simple.
meriton
Round Winner
Posts: 256
Joined: Sun Nov 20, 2005 3:33 am

Post by meriton »

Here's a tentative design for

- game state
- configuration items

---

Game state is organized in objects and their slots. Game objects may inherit slots from their prototypes, but also override them as needed. Each slot contains an evaluation method yielding the slot's current value.

Game state objects are created and initialized by scripts, which can therefore introduce and refer to auxiliary objects as needed.

Replication of state is achieved by replicating objects that hold raw state, those who hold derived state need not be replicated.

Persistence of state is achieved by serializing the current object graph. (Most scripting languages provide this capability natively.)

---

This design meets all requirements for the configuration system:
Core Requirements:
1. a script console (the user can be prevented from modifying replicated state by following the evaluation of each command with a fresh replication. Perhaps we also find a faster way ;) )
2. reading a script from a file before interpreting it ;)
3. addressed above
4. addressed above
5. provided by scripting language
6. provided
7. what about making scripts resources?

Extended/Bonus Requirements:
E1 / B1. Use a scripting language with prototype inheritance, such as Io.
B2. resources are scripts. Load them into a common virtual machine.
B3. resources are scripts. Either require all slots to contain functions or use a scripting language where it doesn't matter.
B4. resources are scripts. We define the capability to import resources in resources.
Luke-Jr
Dr Z Level
Posts: 2246
Joined: Sun Mar 20, 2005 4:03 pm
Location: IM: [email protected]

Post by Luke-Jr »

meriton wrote:Here's a tentative design for
And how does any of this work when scripting is disabled? How does it allow non-programmers to design maps or other resources, or modify game logic/physics/rules?
Post Reply