Effects: Describe/Implement as Python-scripts?

[Yoghurt]

As effects are soon to be implemented, I would like to propose to describe them as Python-scripts instead of XML files. I will post a specific outline in the next days (right now it's 1am), so I will now just write down a few thoughts pro Python:

1. The description for "simple" effects will as easy as XML ones. Mockup

   Code: Select all

   Effect( name="Orzian *Camper*",
    type = BUILDING
    result = AddToMeter(HAPPYNESS, +3)
   )

2. More complicated effects could be defined in the same file

   Code: Select all

   class Frobnicator(Effect): #quick mock-up
     def Result(self, fleet):
       for ship in fleet:
         ship.Name += "frob"
         ship.MaxWarpSpeed += 3

3. It will be a good testbed for the python integration, as AI will have to interfere much more with the rest of the game. Effects (at least 0.3 one) will more or less modify a few variables.

If you have serious doubts about this, let me know, so we can decide on that before I implemented most of it in vain.

PS: Please forgive my english, it's even worse when I'm tired

[Geoff the Medio]

I infer you are proposing python to define game objects like buildings, specials, techs, etc. I infer you aren't suggesting the actual code to modify the gamestate be in python... so there would still need to be a C++ function available that does the "real" work. So the python effectively replaces the XML, and nothing more... Is that accurate?

Are python scripts stored in standard text files?

What about the non-effects part of buildings, specials, techs, etc? However game objects are defined, they'll need some data other than effects, like visual representation, cost & build time and various other properties (weapon strengths, engine speed, tech / resource / other prerequisites to build, what space monster AI to use...). Would this sort of information be stored in the python script, or would a separate file be needed (or desirable if not absolutely needed)?

[Ellestar]

My IMHO.

Bad sides
1) Speed. How slow is Python? I don't know, but i heard that interpreters can easily be 100x slower than C++. That makes modern computers as "fast" as 486DX2-66 or something like that. Of course, if we'll "compile" operators of XML scripts in function calls and we'll use an array of function pointers, it will work slower than C++ code too, but still faster than interpreters.

2) Optimizations. With a custom interpretator, it's easy to make them because we're just changing our program (we're optimizing C++ functions and/or using optimized variants for a most used functions). Now, with Python scripts, most optimizations must be made in scripts (but i doubt that designers will be able to do that). Now, add to that p. 1 and problem with optimizations becomes real.

3) Encyclopedia. If we'll write a descriptions for XML operators in effect group(whatever it be - conditions, effects etc.), then we can show it to a player as a description of a building or a technology in encyclopedia instead of writing a non-fluff part of a description for each object. Also, that way inormation will be always up to date.

4) AI. I think, it's possible to write an AI that will decide, if it's better to make a building that gives +10 to a meter on 3 nearby planets or it's better to make a building that gives +5 to 7 planets across an empire. But if we use a Python scripts, then we'll need analyzer of a python scripts. AFAIK it's practically impossible. With our own XML format, we'll not need it.

Advantages.

1) Flexibility. In Python we can do almost anything with exposed objects.

2) Faster development time. As i understand, we want Python anyway. So, if we implement effects in Python, then there is no need to write an additional modules in a program.

[muxec]

IMHO:
Monolanguage code is
a. faster
b. easier to understand
c. more flexible

C++ implementation with arrays and bitflags is fast, easy and universal.

Remember sometimes it's better to work without classes and objects.

Bitflag here means flags like 100100100111. If we make biwise OR with sample flag we can easily know what effects aply on the object, quickly add required effect to object with simply parser, prevent stacking of unstackable effects.

For example if we have a flag "building type" and first bit means research we get Ox:00000001 for Research lab... Comparing the flag with pattern flag we know what effect to add and simple C++ procedure can easily handle all effects at once.

[Marijn]

I think implementing all game logic in C++ will not be a lot of fun. A python script will not be much slower than XML that has to be interpreted by the program and it will be a lot more flexible. Besides, these are not things that have to happen thousands of time per second. We're talking about a turn based game here. In my humble opinion implementing only these 'effects' in a scripting language is not taking it far enough, but I understand no one wants to go back and reimplement existing stuff in Python (although it would not be a lot of work - the algorithms exist and Python to C++ conversion is very straightforward - wel... except for all the esoteric boost stuff).

[Yoghurt]

Apart from what Marjin said, we should (IMHO) keep most of the game logic writting in Python. One thing is, that is isn't much more difficult/slower than write it in C++/XML, the second reason is that the game logic will be the primary thing that modders what to modify; and I doubt that every mod will just want to tune some XML files; they might want to add a whole new class of effects.
Of course, they can write this in C++, but then they will have to offer a downloadable compiled version for every architecture FO supports (or will by the time of 1.0): Windows, MacOS, BSDs, different Linux distributions (believe me, some binaries can not easily run on other distros), etc.

Having them offer a .pyc file for download is much easier, IMHO.

BTW: I will post a draft soon, am very busy lately; sorry for the delay

[Yoghurt]

1) Speed. How slow is Python? I don't know, but i heard that interpreters can easily be 100x slower than C++.

"Easily" is quite exeggarated. It might be possible to write code that slow, but then you would port C-code 1:1 on python.

Most things you need in everyday work are already available to python (and most of the time written in C), as hash-maps, sort algorithms, etc. You also must not forget that Python code is around 10 times shorter than equivalent C++-code, so the interpreter has less things to do.

Besides that, I doubt that effects will include specifications like "solve these differential equations subject to the following constraints"... And if they do, these parts will be "out-sources" to C++

2) Optimizations.

"Preliminary optimization is the root of all evil" - Knuth
This said, you can optimize python-code to a certain degree, and if you still have a huge bottleneck in a routine, re-implement this (transparently(!)) in C++

3) Encyclopedia

I don't understand this one, I think. We can do the same when using Python-scripts (we could use the docstrings, for example)

4) AI.

AI will (mostly) be written in Python; even if it won't, there is no need to parse the python, as C++ can access the effect-classes the same way python can.

[Geoff the Medio]

...I doubt that effects will include specifications like "solve these differential equations subject to the following constraints"... And if they do, these parts will be "out-sources" to C++

Based on the v0.3 doc, the most mathematically involving things about effects would probably be some of the conditions that are applied to repeatedly to possibly large number of objects, such as "distance" (subtraction, multiplication) and "starlane jumps" (limited graph traversal). If actually implimented in Python, the code for the Create Object effect (class?) would probably be rather involved as well. Other than those, most aspects of effects are pretty simple object data setting or checking.

There might be a lot of it to process though...

[Ellestar]

"Easily" is quite exeggarated.

I said IMHO. By the way, i can't find a word "exeggarated" in a vocabulary. What's that?
Ok, i looked in inet and it seems that Python is 25-50 times slower than old C/C++ compilers on average. By the way, Lua interpreter is 5-10 times faster than Python. So, we'll get an equivalent of a 486DX4-100 - P1-133.

3) Encyclopedia

I don't understand this one, I think. We can do the same when using Python-scripts (we could use the docstrings, for example)

If we'll do effects in XML, then we'll get data that we'll use like a scripts. With Python scripts, we'll get only scripts. That's a big difference in some cases because we can use same data in another places too (like encyclopedia, tooltips), but we can't use scripts that way. But of course it can be done manually.

4) AI will (mostly) be written in Python; even if it won't, there is no need to parse the python, as C++ can access the effect-classes the same way python can.

Again, same issue. We can use XML data about effects in AI as just a data to process and choose more efficient ways by the AI. If we'll have only Python scripts, then AI must be coded to optimally use everything. If we'll use just priorities for different things, then we'll get a standart crappy AI like in most other TBS.

Actually, IMHO AI is the biggest problem. What's the reason give modders more flexibility in moding if most of them will not be able to change the AI? No, physical ability to change AI doesn't mean that they can change AI so it will be able to play relatively good. A standart AI will not be able to handle mods because a game will not be able to translate Python mods to a data AI can use.

[noelte]

hey, why don't we give Yoghurt a chance to prove that pyhton is worth a second look. If it is fast enough and easy to integrate, it would make modding fo much more easy.

[Ellestar]

What if it will be possible to call Python-implemented effects from XML, and game will be implemented in XML? That way, modders will be able to make what they want, but it will work faster than only Python scripts and it will be possible to make AI that will work without changes with XML mods.

hey, why don't we give Yoghurt a chance to prove that pyhton is worth a second look. If it is fast enough and easy to integrate, it would make modding fo much more easy.

We'll see if Python is fast enough only when a game will be released. It will be too late to change anything, that's why i'm worry now.
So, "hey, why don't we give Yoghurt a chance" actually means "let's make all in Python and pray that we'll not regret it at the release".

I guess that some other games were already made in Python. Maybe someone have an information, how fast they are (we need informaiton about games that are more complicated than tetris).

[noelte]

@Ellestar:

I guess arguing with you is hard stuff!? (must ask Geoff)

All i'm saying is if Yoghurt has finished the python integration, we will have a look. if we today see an speed issue, then python might be doomed. if not, we have to decide if python adds value to fo.

when i hear you talking about python, it reminds me on how i thought about java vs. c years ago

BTW: i would use python only at places within fo where it makes sense, but not everywhere!

[Tyreth]

I'm not convinced that python is slow, and I'm not sure how you obtained a result of a 486DX4-100 - P1-133. That's pretty slow, and python isn't slow. Besides, most of the parts of the game where speed is a problem are being developed with C++.

The Temple of Elemental Evil used Python:
http://www.pygame.org/interview/stevemoret.shtml

And then there's all these simple games made using python:
http://www.pygame.org/projects/

Also this game which is a space strategy game, made entirely out of python. If it runs reasonably when it's all python code, then FreeOrion will run even faster since most of it is using C++:
http://www.ospace.net/index.en.html

With a little bit of research into python implementations, a comparison to a 486DX4-100 - P1-133 seems completely unreasonable.

[Ellestar]

Besides, most of the parts of the game where speed is a problem are being developed with C++.

For TBS, part of the game where speed is a problem is end of turn. And you want to code biggest part of economy processing and AI in Python?

Also, do you see downsides in my idea?
What if it will be possible to call Python-implemented effects from XML, and game will be implemented in XML? That way, modders will be able to make what they want, but it will work faster than only Python scripts and it will be possible to make AI that will work without changes with XML mods.

[Yoghurt]

What if it will be possible to call Python-implemented effects from XML, and game will be implemented in XML?

I see no good reason for it, except that it would partly be more consistent with respect to all the other XML files. See my first example; it's pure python and as descriptive as XML will be.