Geoff the Medio wrote:
Making all game content "scripts", instead of "definitions" as they are currently, sounds fine if you know you to program and write scripts,
And what exactly point to turn all
The point of making as much game content into scripts as possible would be ease of modifying how the game works in a more flexible manner than the current fixed-structure content definitions, which you noted earlier would be an advantage of scripting languages over the current parser. By "content", I mean buildings, techs, ship parts and hulls, specials, and similar game components.
Of course, if there's an object with pre-set fields (like a ship), it's just as well as a table. But then, is there any essential difference between "list of valid fields to be set and their values" that should be parsed and "list of valid variables to be initialized and their values" that should be interpreted? Either way you end up with exactly the same
(save few syntactic trifles):
A = 1
B = 70
C = 4
There's no difference for simple variables like costs, build times or names. The difference would be in the effectsgroups and conditions, which are less flexible with the parser than they could be if done with scripts.
Geoff the Medio wrote:
Making all game content "scripts", instead of "definitions" as they are currently, sounds fine if you know you to program and write scripts, but a lot of people are unable or unwilling to learn how to do those things. Having a more limited content description language that doesn't have arbitrary variables or execution flow control or other programming / scripting language complications makes it significantly more approachable for prospective content designers, even if the actual definition files end up being somewhat complicated (and limited in what they can do).
an interpreted language, just with weird syntax and that needs more code for every new method than is really necessary.
The distinction I'm making is between arbitrary functionality that the content designer needs to write in a full scripting language, as opposed to chosing and combining a limited set of commands that hide all the internal details of how they work and which must be used in a fairly strict format. Right now, to write an effects group, the designer just needs to specify two conditions and the effect to perform on the selected objects. The designer doesn't need to think about the logical steps to get a set of objects from the scripting interface, how to write a filter on those objects or how to use the filter, then how to call various functions of those objects or the universe to modify the objects, or how to use the scripting language's built in features to do logical operations on the contents of sets.
What's "more approachable"? As long as what's needed is exactly the same references and assignments, the difference is only in the syntax. Simple object init: see an example above.
If all a content creator is doing is setting simple values of fields in a data structure, it doesn't really matter to the creator what scripting / definition format is used. For filtering objects and modifying them or the gamestate, needing to call functions or deal with scripting language syntax and flow control, as above, makes things a lot harder to understand for non-programmers.
There are also advantages to having the fixed standard format of the current definition format, which allow the content to be more easily parsed and displayed in the GUI than an arbitrary scripting language implementation would.
Effects: do you think the current implementation is less awkward and more "intuitive" than a real script language would be?
The current probably more awkward and less intuitive than writing a script would be for me, or someone else who's comfortable writing prodecural program code / scripts.
Is "(set! index (+ index 1))
" in a fugly Scheme
that much more cryptic than "SetMaxTrade value = Target.MaxTrade + 1
" in FO-effects? How about "sum = sum + countCargo( unit )
" in clean Lua
Those code snippets don't seem to be doing the same thing, so it's not really a fair comparison, but I'd say the explicit names of the effects and referenced properties in the FO-content-definition-style are the least cryptic of those options.
Beyond this, it's an imaginary problem: designers who will never need to write a script with cycles, aren't required to even know what those are. And those who need, either can do it - or must deal with C++ code in four different files instead.
If everything was scripted instead of defined and parsed as now, effects would need to be implemented in the scripting language... so the content creator would need to know how to write scripts in that language, including flow control and data manipulation. Maybe we're talking about different things or levels of scripting, as this seems quite obvious to me... It's inherent in replacing the parser with scripts for effects and conditions.
It certainly takes time and is a lot more complicated when you get a simpler interpreted language, but must rewrite your own interpreter
every time you want the script to do something new.
Adding a new function to the parser doesn't involve changing anything besides the function that's being added, and the code to expose it. It's certainly not a full rewrite of the parser for each modification... And most of the difficulty in doing that is all the behinds the scenes bookkeeping and safety checking that is done to make a function that's exposed to the parser relatively simple and safe to use.
The idea isn't that content creators will be writing C++ code to create new game content though... They generally don't know how to write programs with scripting or compiled languages, as discussed above. Instead, they can define an effects group or condition as a data structure, and don't need to worry about how it's handled internally.
Of course, there's always some balance between the content and the code, right now it hardly close to an optimum. IMHO rule of thumb is: things that must be fast are better hardcoded and things that have no impact on FPS and not much on new turn generation time may as well be scripted.
No, we're not at an optimium, and a lot of stuff could and should be exposed to Python or otherwise made moddable, but doing this takes time.
If you'll volunteer to work at making more things moddable (without removing all parsing for content definitions), I'll gladly help you get it working.
Also, while more complex scripts may be slow, right now it uses conditions instead of procedures when this isn't really necessary. Would straightforward object and function references be slower than scanning and matching everything for any trivial task?
I'm not sure, but I suspect that conditions as currently implemented in C++ and used when deciding on effect scope or allowed building locations are probably a small fraction of the time it would take to do similar filtering using the existing interface that's exposed to Python. I don't know if this difference would be significant in terms of UI responsiveness (this needs to happen during players turns to indicate whether a particular building can be produced on a particular location) or during turn processing.
But again, that's not really the point...
Yeah, and there's basically two ways for this: either reinvent the bicycle, extending this parser until it's equal to a convential interpreter or get a ready one in some library.
The content parsers would never get as fully functional as a full scripting language. They're always going to give a fixed set of values to define and set of components that can be stuck together in a very controlled structure to definte how content functions in-game.
...the difference between a ruleset and a branch still means lesser moddability.
You don't need to branch FreeOrion to add a new effect or condition... just submit a patch.
It's easier to restart a game than to recompile everything three times over just to tweak a thing or two.
Restarting is all a content designer will do regularly, since they in general won't know how to add a new effect or condition anyway, and we should have a sufficient variety of effects and conditions to work with that they don't feel the need to add more very often...
Let me rephrase it? "It is a limited scripting language...
See above re: my distinction between scripting languages involving programming issues such as flow control and data structure handling, and the current parser which is just a data structure with no execution flow control and a very fixed structure to work with.
...but you have to write everything in C++ first and then refer to it, whenever you do anything not already implemented this very way".
The requirement to write most of the details of implementation of game mechanics for content in C++ before it can be used in content definitions is a limitation. But, the fact that the content creator doesn't need to know about any of these implementation details is a benfit to this arrangement. If we were to instead do all the implementation details in a Python script, it would be more moddable, but it's unlikely we'd want to then still have the extra step beyond that to have a non-programmer friendly non-scripting-language means to define content.
See the problem? If you must dig into the main code anyway, it would take less effort if conditions and effects were simplified and hardcoded even more and implemented as enums and arguments - like ship parts now: class = Stealth|Colony; Capacity = N.
I don't follow your point here... To the content creator, who doesn't mess around in C++, the available effects and conditions are hard-coded, just like definitions of the style class = Stealth, except that effects and conditions can contain other conditions. It's impossible, and unnecessary, to predict all the possible combinations of conditions or effects that a content designer might want, so FreeOrion provides a variety of conditions and effects that can be combined together to create a variety of functions in-game.