vValue and DCT

What do you want to see in Armagetron soon? Any new feature ideas? Let's ponder these ground breaking ideas...
meriton
Round Winner
Posts: 256
Joined: Sun Nov 20, 2005 3:33 am

Post by meriton »

Terminolgy should be as simple as possible. Thus, every distinction we make should be because we benefit from making it.

The reason I do not speak about configuration is because I see no additional value in this abstraction. The reason I do not distinguish between code and data is because I see no value of doing so. May I ask you, why we should care whether something we load at runtime is "code" or "data"?

I don't think it makes any sense seperating code from the data it operates on. One of the most important ideas behind OOP is *not* to separate code from data, but treat them as a unit.
Will you be the one explaining that to our users?
This argument amounts to saying we should always use established terminology even if our requirements are different. I disagree. Yes, using another terminology means the user has to learn another word. But it also means the user won't misinterpret the capabilites of a script because it is referred to as "configuration". I prefer an obstacle in plain sight to a hidden one anytime.

And yes, I think it's no big deal to explain this to a user:

Q: "Where are the configuration files of AA? I want to change something."
A: "The behavior of armagetron is defined by scripts, check your scripts folder and see the wiki for a breakdown of what can be adjusted in which script."

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.
But you propose to travel twice as far as neccessary: You build an API to access script objects from C++ and build an API to access C++ objects from script. Isn't it cheaper to build just the former?
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

So, in trying to get everyone on the same page where we're talking about the same stuff so we wouldn't be splitting hairs for lack of understanding, we're splitting hairs over terminology. :) The point wasn't whether or not the definitions were to be used in code, the point was that they're so we can discuss the same stuff reasonably, and I mentioned it only because it looked like we were all using the same words to mean different things. It's not useful at all if we're just going to argue over what the words mean.

Now, definitions do tend to get coded, but "requirements and specifications" include definitions, and where a system has similarities with other systems (in this case the already existing resource system and the WIP scripting system), "specifications" have to describe where the differences are and where to draw the line. Too easy to get sucked into the trap of implementing the same thing in 3-4 different places because of the use of ambiguous specifications (or no specifications at all). We already watched vValue try to turn into a miniature scripting environment, didn't we?
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 »

Lucifer: yes, that's the way things go around here.
meriton wrote:Terminolgy should be as simple as possible.
But not simpler, and it's a mistake to drop well known terms without a very good reason. "Configuration" is a well known term for things you can change without too much risk and without too much knowledge of the whole system. Your web browser allows you to set a proxy server, that setting has no influence on the rest of the system, it's a safe thing to do. "Script" can do anything. It's scary. I don't modify scripts that are in a language I don't understand. I'm afraid to touch my .emacsrc, it's written in Lisp. I only added the very few lines that were explained somewhere where I could easily see how they can be modified to suit my needs. Still, it took some failed starts with debugging enabled to get everything right. That's not the way configuration should be presented to the user. Dropping the term "configuration" is one of the cases where too much abstraction is bad.
meriton wrote:May I ask you, why we should care whether something we load at runtime is "code" or "data"?
Because data is more controllable, it's harmless. Activating a moviepack, a pure data moviepack bringing only new models and textures, does not change the game. Nothing changes but the look, and I can rely on that. If I load in additional code, everything may change. Code may be harmful. Before I install any code manually, I should check whether I trust the author, or check the code itself. That should not be required for data.
meriton wrote:One of the most important ideas behind OOP is *not* to separate code from data, but treat them as a unit.
In my book, the code is usually attached to data types, not the data itself. Things may be degenerate and every object may be its own type, but still: usually, not every object comes with unique code of its own, it's always part of a crowd that shares the same code.
meriton wrote:Q: "Where are the configuration files of AA? I want to change something."
A: "The behavior of armagetron is defined by scripts, check your scripts folder and see the wiki for a breakdown of what can be adjusted in which script."
And here's where 80% of the users who are fine with the .cfg format will run away screaming. We already have enough obstacles between potential server administrators and successfully running servers.
meriton wrote:
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.
But you propose to travel twice as far as neccessary: You build an API to access script objects from C++ and build an API to access C++ objects from script. Isn't it cheaper to build just the former?
First, it's not twice as far. Making C++ classes visible from script is the largest part, wrapping the virtual functions, which are fewer in number, is relatively little work. Second, it's required. If you only build one way, you can't go the other way, and things get impossible. Third, if you only build access to script from C++, you have to move everything that should be accessible from script to script, where it is not now, and where it is hard to access from C++. It's possible to make C++ classes behave exactly like script objects, but you won't get an arbitrary script object natively into C++.
meriton
Round Winner
Posts: 256
Joined: Sun Nov 20, 2005 3:33 am

Post by meriton »

Configuration" is a well known term for things you can change without too much risk and without too much knowledge of the whole system.
Wikipedia disagrees (safety of changes is not mentioned in any article about "configuration"). If we use well known terms, we should use them in the well known meaning ...
Because data is more controllable, it's harmless.
Data need not be harmless; there are webpages out there that crash web browsers trying to parse them.
In my book, the code is usually attached to data types, not the data itself.
Io uses prototype inheritance, there is no distinction between object and class. Why would we introduce one? Security? It doesn't really help, as the more difficult problem of restricting access for code remains unsolved. On the other hand, whatever solution we find for the latter should be trivial to retrofit to protect data.
And here's where 80% of the users who are fine with the .cfg format will run away screaming.
God this sounds like a horror movie ;)

Seriously, obviously this depends largely on the legibility of the scripts in use, but as outlined above I think it is possible to achieve the same degree of legibility with a script. (Or why else would they run? Because "scripts are dangerous"? But if the scripts are properly sandboxed and this is documented, this shouldn't be a problem, should it? I really don't see the stepping stone you are referring to here.)
First, it's not twice as far. Making C++ classes visible from script is the largest part, wrapping the virtual functions, which are fewer in number, is relatively little work.
I don't get that. If we don't need to access the C++ side from the script, why do we need to "make C++ classes visible from script"?
Second, it's required. If you only build one way, you can't go the other way, and things get impossible.
It's not a problem if I can't use armagetron for word processing. I mean, are the things that get impossible things we'd want? I concur that we will need some C++ classes/functions in the script, but I am not sure this will be a significant proportion of the C++ code.
Third, if you only build access to script from C++, you have to move everything that should be accessible from script to script, where it is not now,
I am aware of that. I am not sure if it would be worth it, but at least, this would make for excellent example scripts :) I'd suggest that the approach chosen is decided on a case-by-case basis. In any case, you know Io and the C++ code base better than I, so I'll keep my mouth shut about specifics. I just wanted to point out the alternative in case it would save some work.
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:
Because data is more controllable, it's harmless.
Data need not be harmless; there are webpages out there that crash web browsers trying to parse them.
The browsers in question are at least in part at fault-- data should not be capable of this.
User avatar
Z-Man
God & Project Admin
Posts: 11585
Joined: Sun Jan 23, 2005 6:01 pm
Location: Cologne
Contact:

Post by Z-Man »

meriton wrote:
Configuration" is a well known term for things you can change without too much risk and without too much knowledge of the whole system.
Wikipedia disagrees (safety of changes is not mentioned in any article about "configuration"). If we use well known terms, we should use them in the well known meaning ...
Wikipedia doesn't have a whole lot to say there about software configuration. What it says is so general in scope that it has no meaning. Let's ask google what a configuration file is:
http://www.google.de/search?q=define%3A ... uche&meta=
Some of the keywords: simple, line-oriented, unformatted.
meriton wrote:
In my book, the code is usually attached to data types, not the data itself.
Io uses prototype inheritance, there is no distinction between object and class.
Read my next sentence. The usual operation, even in Io, is that you have a prototype object representing what is a class in C++, and when you clone that object to create an instance, actually no code gets copied at all. So even factually, every object of a class shares the same code. Even in script, the lightcylce objects would usually share their code.
meriton wrote:Why would we introduce one?
To be able to talk at all. If everything is code code code, we won't get anywhere. Grand unifications of terms don't get anything done.
meriton wrote:Seriously, obviously this depends largely on the legibility of the scripts in use, but as outlined above I think it is possible to achieve the same degree of legibility with a script.
Yes, and I don't mind if the configuration files are actually written in script. If you scroll back, I even suggested that. But you really need to be able to do everything you can with the current configuration system with non-scary script commands. Assignments only, if possible. And our standard configuration files need to show that. They need to show the non-scary side of script. I just refrain from calling it all code, because I want to be able to talk effecively about it. If you get your way and everything is code and the users accept it, what does "I think something's wrong with the code" mean? Is it the game code? The configuration? Data files? Who knows?
meriton wrote:
First, it's not twice as far. Making C++ classes visible from script is the largest part, wrapping the virtual functions, which are fewer in number, is relatively little work.
I don't get that. If we don't need to access the C++ side from the script, why do we need to "make C++ classes visible from script"?
Umm, nobody said we don't need access to C++ from script. It's what we need the most. The C++ side is there, and any script we write today needs access to it to be useful. The core functionality of the engine will always be in C++ for efficiency, and the script side won't get anything moved without access to the interfaces of the engine.
me with better emphasis wrote:Second, it's required. If you only build one way, you can't go the other way, and important things get impossible.
meriton wrote:I just wanted to point out the alternative in case it would save some work.
Thanks, but it sounds like more work in the long run to me. But maybe I don't understand what you really want done.
User avatar
Lucifer
Project Developer
Posts: 8640
Joined: Sun Aug 15, 2004 3:32 pm
Location: Republic of Texas
Contact:

Post by Lucifer »

Ok, now that I've worked in some detail with 2 (count them!) programs that use script as configuration, I have to say I'm a believer. And here's where it brings me, probably a bit out of the scope of this thread.

Configuration is defined as we've already defined it here (it took me awhile to refresh my memory of this thread, it should take you awhile too! ;) ). In order to determine when it is loaded and initialized, we need to go up one step (actually two, or 1.5, depending on how you interpret round/match logic). We need to define what I'm calling a segment. A segment is a period of game play. At the beginning of a segment, configuration is loaded and the script file is evaluated. At the end of a segment, everything is destroyed, and another part of the script file is evaluated (or a separate file). So one script is the constructor for the segment, and the other script is the destructor. Right?

So we provide a segment that implements existing match/round logic. Completely. Everything that's there. 1 segment = 1 match, the segment object that provides this game flow has to implement round logic on its own.

We also provide a helper function, either as a separate function or as a method in the segment base class, that loads configuration directives from the old file format. There's your migration path.

In the end, we guarantee that the entire simulation will be reset and reinitialized at the beginning of a segment. If someone wants to do more complex things and persist the end state to the beginning of the next, he needs to use his destructor script to push state to disk and his constructor to load it. We could provide helper methods for that, even.

This feels to me like a cap on the whole discussion, if everyone likes it, and should segue nicely into determining what a segment looks like and starting in on designing the script api we discussed in the 0.3.1 laundry list thread, and giving some hints on where the gGame factoring should go.
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 »

Yep, sounds good. We need to make sure that even the scripted configuration can be simple. I don't want to force users to write functions, for example.
Post Reply