vValue and DCT

[meriton]

That is works without scripting is not part of the requirements. Of course, we can debate whether it should.

IMHO, non-programmer contribution would not be harder than it is now. You don't have to understand all details of a programming language to tweak parameters, and every scripting language supports comments ...

For instance, the resource file for standard fortress could contain (sorry for syntax errors, I don't know Io well):

Code: Select all

Fortress := Zone clone do {
    size := 30;
    spin := integrate(0, spinAccel);
    spinAccel := attackers count * 0.3 - defenders count * 0.2 - 0.1;
    attackers := ... // list of attackers currently in this zone
    defenders := ... // list of defenders currently in this zone
}

Team := Object clone do {
    fortress := Fortress;
}

GoldTeam := Team deepclone do {
    name := "Gold";
    color := ...
}
BlueTeam := Team deepclone do {
    name := "Blue";
    color := ...
}

Of course, this is but a tentative design, but I don't think it would be harder to understand than our current configuration or resource files.

[Z-Man]

Meriton: yes, I think that pretty much matches what I had in mind, and what I think I was proposing some pages ago Just. Use. Script. What may have made us not understand each other is that I gave so much C++ code and that I considered it given that the gamestate would be exported into script and didn't mention it

Yes, scripts should be resources in one form or another. Either standalone XML files with a big "this is script" part, or small XML wrappers combined with a raw script file. I'd prefer the first if it doesn't make string quotes awkward.

I'm not so sure about resources beign scripts, as you can see. There is something like too much flexibility, it makes map editing tools really hard to write (see static vs dynamic typing ) It wouldn't hurt, though, to allow arbitrary script commands anywhere in resources, and stick to Lucifer's proposed way of mapping the elements of a resource to game state objects of well defined names, so that the scripts in a resource can find the stuff that was just created.

Small correction in your example: It would probably be

Code: Select all

spinAccel := method(attackers max * 0.3 - defenders max * 0.2 - 0.1)

if we both assume that attackers and defenders give a list of attackers and defenders.

That is works without scripting is not part of the requirements.

Well done

[Luke-Jr]

That is works without scripting is not part of the requirements. Of course, we can debate whether it should.

"Optional" has always been a requirement for scripting.

IMHO, non-programmer contribution would not be harder than it is now. You don't have to understand all details of a programming language to tweak parameters, and every scripting language supports comments ...

Markup like XML is inherently simpler for a non-programmer to work with. Not to mention UIs.

Yes, scripts should be resources in one form or another. Either standalone XML files with a big "this is script" part, or small XML wrappers combined with a raw script file. I'd prefer the first if it doesn't make string quotes awkward.

I believe we can embed scripts within XML easily using the CDATA construct to allow things like < and > properly. This would allow scripts to specify requirements like language version-- perhaps even allow mixing multiple languages within a single resource.

[Z-Man]

"Optional" has always been a requirement for scripting.

Nope, not scripting in general. It never has been. And any reason you may bring up why it should be optional will also apply to libxml2.

Strangely, I agree with the rest of that post Apart from that, until I see proof to the contrary, I think that multiple scripting languages can't be supported at once and that independently of whether it's possible, we shouldn't do it.

[Luke-Jr]

"Optional" has always been a requirement for scripting.

Nope, not scripting in general. It never has been. And any reason you may bring up why it should be optional will also apply to libxml2.

I wouldn't assume that. libxml2 is only in regular use in between rounds, not every frame.

[Z-Man]

As is script if it is used only for the configuration and tournament game modes.

Another reason not to make all resources scripts is the security aspect. Resources are downloaded and we'll run all scripts in them with appropriately restricted rights. It may make things more difficult if every desired effect of resources needs to be directly achieveable with script, that puts a lower bound on the rights we can grant downloadable code. The same desired functionality, accessible via XML files, is easier to control because the format alone imposes restrictions. We have higher freedom to choose the rights granted to downloadable code if resources are XML interpreted by parsers.

[meriton]

yes, I think that pretty much matches what I had in mind, and what I think I was proposing some pages ago

I think it doesn't. The basic idea is the same, but the architecture is very different: You propose to define game state in C++ (as requested by resources) and expose it into the script. I propose to define game state in the script, and expose it to the C++ renderer. This moves the entire game logic into a scipt, including prediction and replication (the C++ code would assist in the replication, but the data is kept in the script environment, in a shape defined by the script). It is unclear to me how replication of configuration-defined game state would be handled in your proposal.

I'm not so sure about resources beign scripts,

Neither am I, but we should consider the possibility. For instance, zone locations are currently specified in the map, but the script defines their behaviour (and what of moving zones?). It makes sense to provide as seemless integration as possible, and that would require a mapping from zones to script variables; if we don't describe this in a scipt, we'll need another compatibility layer. For instance, to implement the bouncing ball in styball, the definition of the ball is in the script, and needs access to the location of the bounding walls, which are defined in the map.

There is something like too much flexibility, it makes map editing tools really hard to write

I agree. On the other hand, we could dispense with a compatibility layer, but I concur this doesn't seem worth it.

Markup like XML is inherently simpler for a non-programmer to work with.

I contest that. In simple use, a script is such a series of nested attribute definitions, just like XML. There really isn't much of a difference between the user seeing

Code: Select all

<zone x="0" y="0" size="10" color="ffffff"/>

and

Code: Select all

zone := Zone clone do {
    x := 0;
    y := 0;
    size := 10;
    color := "ffffff";
}

Not to mention UIs.

Since you don't mention it I can needn't answer that.

Another reason not to make all resources scripts is the security aspect. Resources are downloaded and we'll run all scripts in them with appropriately restricted rights.

Io doesn't support access control ...? Even if it doesn't, we can load different scripts in different VM's, and expose some variables of one virtual machine into the other. (Access control is something we'll probably want anyway, we wouldn't want a user's local camera script to modify game state, for instance.) But I suggest to define isolation requirements before choosing the method of isolation.

[Z-Man]

Io doesn't have access control. The plan was to use isolated virtual machines for the different security levels. One unrestricted level for scripts we provide or the user installs by hand. One where security critical parts, like file access, are unavailable, for use by automatically downloadable scripts. Access to gamestate would still be full here; the server-client model already prevents cheating. And maybe one with severe restrictions that don't allow access to the game state for scripts the user uploads to the server or other clients. Self-written bots, scripts that allow to display text on your trail, that kind of things. I'm not sure whether we will need that.

And well, since all of our code currently is in C++ and will stay in C++, it makes sense to define the gamestate there and export it to script. Script extensions of that will be possible, of course, so as soon as you create a derived class of gCycle in script and one of gGame and register them so they'll get used in place of the C++ classes, it will be them defining the gamestate. The plan is to make it so that neither C++ nor script can tell the difference between C++ objects and script objects without a microscope.
It would be one monster amount of work to be done all at once if suddenly, the script should be the one that determines everything. It would be another monster amout of work to make the C++ bit listen to the script. We can't do that. We need to take small steps. Start from the way it works now and expose one class after the other to script.

[Lucifer]

Oh yeah. Now that I'm more awake.... I'm writing this in the present tense for a future version.

This part is probably already known to everyone, so I'm writing this just to make sure we're all on the same page. Game state is two pieces of information. It's "game" (heh), which is the simulator itself, game rules, and how all of that goes together. It starts after you connect to a server (or start a local game) and ends when you leave the server (or the local game). "State" is itself two things. It's a single frame in the simulation, which contains a snapshot of everything in the game. It's also things that change during the game, but not necessarily every frame, but have to be checked every frame, like player's score. So I'll call the first part the game simulator, which includes the game rules and the physics simulation. Game rules are applied, evaluated, and run both during actual play (when the physics simulation is running), and outside of play (between rounds, when the physics simulation is tore down and reassembled).

Ok, so configuration isn't game state. Configuration provides initialization for the game simulator in the form of specifying game rules, specifying physical rules (such as providing a gravity function), specifying which game objects are to be used in the game, how they fit into the rules, and how they will be controlled (which ai, if any, how to match them up with human players, etc). Configuration also provides constants that are used in evaluating existing game rules. Where configuration differs from resources is tricky to define, which is why I keep suggesting resources and configuration be merged instead. Most of this paragraph is true about resources as much as its true about configuration, with the exception that a resource defines a whole, but configuration defines a part. So it could be said that resources are essentially just groups of configuration, making it reasonable to consider that maybe specific parts of resources should be console commands. Anyway, we can figure out where the line is drawn, but I think we have to draw the line somewhere.

So, a script ccould be considered configuration. If a script provides a game object, it's obviously not configuration. Configuration is required to specify the game should use the new scripted game object. On the other hand, a script could provide a function for cycle movement, in which case it is configuration, and configuration is required to tell the game to use it.

Scripts can also be considered resources. If a script provides a game object, it may be considered a resource. This isn't quite as obvious, but I'm thinking we'll be letting users provide their own cycle resources for others to download and see. This is essentially the same thing as a script providing a game object, only the script would be expected to also provide an ai for the object. But a script that provides tournament logic and rules is a resource for the reasons I mentioned previously. It's general purpose and has use on many servers, not just one single machine.

So I'd suggest we explicitly define scripts as a third thing that can be referenced in resource files and also referenced in configuration, but neither resources nor configuration should be script. Now, given some time we might decide otherwise, but I don't think building these systems separately will create too much work should we decide to merge one or more of these systems in the future, nor will it create a barrier to doing that work. On the other hand, I think conceptually the grey areas are making the discussions on all three topics difficult, with people seeing things subtly differently (or outright completely differently), and maybe not even realizing they're not looking at things the same way.

[meriton]

game-state in script:
I have a reason to suggest this: I think we agreed that it should be possible to add new game modes without changing the client binary. New modes can introduce new behaviour for game objects, which must be known to the client to enable prediction.

And well, since all of our code currently is in C++ and will stay in C++

What code? You can't mean all code, otherwise we wouldn't need scripting at all.

Script extensions of that will be possible, of course, so as soon as you create a derived class of gCycle in script and one of gGame and register them so they'll get used in place of the C++ classes, it will be them defining the gamestate.

And if this class merely forwards all inquiries to the script, this is what I am suggesting.

The plan is to make it so that neither C++ nor script can tell the difference between C++ objects and script objects without a microscope.

I was hoping to expose only a tiny subset of C++ functions to the script, not the entire C++ view of the game state. Rather, the script should access its model of the game state.

Note that this is the long term perspective, I am aware that we will need to make tiny steps, but it helps to know where we are going.

[meriton]

part of game state kept across rounds:
I know.

"Ok, so configuration isn't game state."
No, but, together with state updates caused by the user, it exhaustingly describes the game state. Therefore, defining game state is equivalent with providing the configuration describing it.

"So it could be said that resources are essentially just groups of configuration"
I currently think of them as deployment units for configuration, which in essence is a group of configuration with some meta-information (such as dependencies).

"If a script provides a game object, it's obviously not configuration"
Apparently my terminology is unclear, so let me sketch how a new game object would be defined, and what part of this I call providing the game object. Assume a script says:

Code: Select all

ball := Zone clone do {
    // some definitions
 }

The client executes that script, and reflectively enumerates the slots in the Lobby, creating game object proxies for those objects for whose type a renderer is known, in our case, this creates a new zone proxy that delegates to the Io object "Lobby ball".

In such a design, designing (=configuring) the object in the script amounts to creating it in the game as well, which is why I refer to this as "providing a game object". Likewise, the script configures the game object and thus acts as configuration.

"grey areas", "misunderstandings", "build seperate systems":
No ambiguous term has become clear by splitting it in two by an ambigous criterion. We should do the opposite: We should clarify the meanings of the terms involved. I think we do not need the term configuration if we configure using scripts.

[Z-Man]

Hmm, maybe you're not aware of how script export is supposed to work?
- The script can create C++ objects and manage them
- The script can call C++ functions, all parameters and return values are properly converted, returned C++ object pointers are usable just like C++ objects created in script
- The script can derive classes from C++ classes, all extensions naturally are available from script
- The script can override virtual C++ functions, if the virtual functions get called from C++, they call the script implementation

All this together has one effect: it's more or less pointless to debate where something is to be implemented. Nobody can tell the difference. The only feelable limitation is that you can't create script objects from C++ like you create C++ objects from C++, to hide that, we'll have to use factories. There also is no point in asking whether it's C++ state that is visible from script or script state visible from C++. As long as the state is represented by virtual functions (resp. their return values) on the C++ side, there is no difference. However, it makes good sense to keep the data storage we already have in C++ and not to move it to the script; it's just so much tighter packed in C++ objects than it ever can be in script.

The step by step transition should happen as follows, IMHO: class after class and function after function, we create the script wrappers. Once the framework is complete, that is only a matter of listing the names of member functions you want to have in script. Important classes and functions go first, obviously. There is a point where we should stop, it doesn't make sense to export everything, and there is a memory cost and small startup time cost attached to every export. In parallel, the C++ code is rearranged so you can customize it in C++ by registering factories that create alternative game objects whose functionality is altered by overriding virtual functions. Those classes are exported to script as well and voila, you can now extend that game aspect in script. We'll start with simple, isolated things, obviously. The zones, AIs, game mode management.

[Lucifer]

Ok, now the "configuration" script says:

Code: Select all

tank := eGameObject inherit do {
    // some definitions
    ....
    // ai
    ....
    // player controller definitions
    ....
    // rendering
    ....
}

You're trying to blur the definitions I gave. You don't have to accept them, but it would be more helpful if you rejected them by providing alternate definitions. The reason I gave definitions you pretty much summarized with that post.

No, but, together with state updates caused by the user, it exhaustingly describes the game state. Therefore, defining game state is equivalent with providing the configuration describing it.

...

I currently think of them as deployment units for configuration, which in essence is a group of configuration with some meta-information

...

Likewise, the script configures the game object and thus acts as configuration.

...

No ambiguous term has become clear by splitting it in two by an ambigous criterion. We should do the opposite: We should clarify the meanings of the terms involved.

The last sentence I quoted is exactly what I was trying to do.

[meriton]

Hmm, maybe you're not aware of how script export is supposed to work?

I considered this to be part of the debate. Is it not?

Yes, what you describe makes it a moot point, but it also appears laborious. Is that impression wrong?

@Lucifer:

You're trying to blur the definitions I gave. You don't have to accept them, but it would be more helpful if you rejected them by providing alternate definitions.

I didn't try to blur them, I provided alternate definitions. Sorry if they look fuzzy to you, they don't to me. I'll try again.

Game State is represented by a federation of game objects. A game object contains names slots, who contain a value that may change over time. A slot is called defined iff for every time, its value can be determined. A game object is called defined iff all its slots are defined.

Game objects are defined by scripts (we also say the script "provides the game object").

The deployment units of scripts are called resources.

The term configuration is deprecated.

[Z-Man]

Hmm, maybe you're not aware of how script export is supposed to work?

I considered this to be part of the debate. Is it not?

Not this one. Actually, the "what can we do with script for configuration" debate as a whole should wait until we know what we can do with scripting, and the various script choices to make should simply maximize our general possibilities. Configuration is only one possible application.

Yes, what you describe makes it a moot point, but it also appears laborious. Is that impression wrong?

Partly. Sure it's a lot of work, but that's not because of the chosen way, it's because of the long distance. There is no magic wand that can link script and C++, even SWIG needs some help, especially if you do crazy things on the C++ side.

The term configuration is deprecated.

Will you be the one explaining that to our users?
Q: "Where are the configuration files of AA? I want to change something."
A: "There are no configuration files. Configuration is a thing of the past. We only have scripts."
Q: "?????"

The way I see it, the difference between configuration and resources is the granularity. Both configuration and resources come in larger files, but with configuration, it always makes sense to tweak a single element, a single line of a file. You can split a configuration file in two halves and get two working configuration files. Configuration is fine grained. Resources are coarse grained. Changing a single line in a resource file usually does not make sense, you destroy the file level syntax elements, you move a piece of wall that was supposed to meet up with another piece of wall defined somewhere else in a file, you change one team's home zone size and destroy the game balance. Splitting a resource file in two gives you two useless files.
That distinction is foggy, too. Configuration items depend on each other, and then they stop to be fine grained. It makes perfect sense to change many lines in isolation in any given resource file. But I think it has to be that way because the fundamental facts are foggy. Think of it as a Heisenberg uncertainty principle. In the end, everything is just bits and bytes, you can't even properly distinguish between code and data. Are scripts code or data? If they just serve configuration needs, they're data in a sense. If they define new game objects, they're code. If you can't draw a sharp line between code and data, how can you distinguish resources and configuration?

So I wouldn't try to categorize script as code or data, configuration or resource. Yes, I agree with Lucifer, it's a third (fifth) thing. Script is a mean to possibly express configuration, resources, code and data. It doesn't have any "a IS b" relationship in any direction with the other four things. The possible relationships are "a contains script", "a is implemented with script" and the like. The things I would allow here are

- resources are all XML; they may contain script passages.
- there shall be resources that, apart from the thin XML shell that declares name and version, consist purely of script.
- configuration is implemented as script; a script file shall be considered configuration if it only contains assignments and copy operations.
- With the exception of the special script resource type, resources and configuration should both be more data than code. They should not usually contain control logic or functions. They certainly should not contain new game object behaviors.