Campaign lobby

[John.d.h]

I originally posted this over on the Megaglest board, but I think it's more fitting as a new thread, and although I'm planning on having it work with both engines, my priority will be getting it to work with GAE.

I've just started dabbling a bit in Python, and I think I'm starting to get an idea of how to implement something in an external script that might work for launching campaigns.  In effect, the python script would create a sort of lobby from which you could launch your game and a script would run alongside the game, reading and writing data to an external file.  This could be something as simple as "you win the scenario, so write such-and-such to some file", or something that hooks more calls based on lua events.  I still need to look into some things to see if this is even remotely feasible, but if it is, then I pretty much know how to do it.

What (I think) we need for this to be possible:

• A way to launch Glest/MG/GAE with parameters that would make it run a specific scenario, so we can do something like os.system("glest -scenario %(user_selection)").  No idea if this is possible, presently or in the future.
• The ability to hook function calls from Glest and launch a script based on these calls.  For example, when the player beats the scenario, the runtime script launches a write-to-file script.  I think this is doable, but I need to learn a lot more about hooking.
  

If these two things are possible, I believe it will be possible to run campaigns for all three engines without modifying the engines themselves.
Here's my initial concept of what the lobby would do:

First, prompt the player for new campaign or resume campaign.

1. If resume, then look for associated files that tell us the player's progress.
2. Print a list of the campaigns the player has current progress in and prompt the player to choose.  E.g. "Resume which campaign?: (a) Scrambled Eggs, (b) Eye of the Walrus".
3. From an external file, build a list of the scenarios in that campaign that the player has unlocked, then print and prompt for a choice.  E.g. "Which scenario would you like to play?  Unlocked scenarios: (a) Atrium, (b) Green Tea, (c) Stairway to Utah".
4. Launch the game with that scenario (os.system blah blah from above) and launch the runtime script to hook function calls.

1. If new campaign, look for associated files that list available campaigns.
2. Print a list of them and prompt the player to choose.
3. Launch the game with the first scenario of that campaign and launch the runtime script to hook function calls.

Then the runtime script would intercept Glest's function calls and/or lua events and write relevant ones to an external file (from which the lobby will read later).  If we're able to read lua functions, then we could write a lot of "plot" information (like what jda was talking about) and have branching scenarios based on that, or even write directly to (a copy of) the lua file and run the modified version.
It looks pretty straightforward to me, but I might need some help sifting through Glest's functions to see what we need.  My exams are over on the 3rd, so I'll start looking into this with more intent around that time.

[hailstone]

It might not be secure allowing people to use system calls.

[John.d.h]

What do you mean?

[jda]

I actually doubt python will be able to "hook function calls from Glest and launch a script based on these calls" without the Glest (or GAE/MG) code itself setting up the apropriate python bindings itself. ÃŽf I'm right changes to the engine code would be required.

I think no proper OS would allow an application to actually hook onto another without the second explicitly establishing it can be hooked, what parts of it can be hooked, how and by "whom". It would be like entering your neighbours house without permission!
Then again, on Windows side, the g*dd*amn*d system has so many security holes you might actually find one big enough to actually be "documented" on the Net as a feature!!!

But I think what hailstone is talking aoubt is: even if GAE's code allows your python script to hook into it... one thing is to grant that access to your script, a completelly diferent one is for your script to lend its grant to whomever can copy-paste a LUA line.

Still... Glest itself is only a game. And if the hooks erm hook only on gamestate stuff and issue commands such as those you can issue from the game's menus, then the worse that could happen would be an unimportant crash of Glest, such as "file not found".

And in brief: I like your idea very much, John!
But I do think it will need code changes (I might be wrong) and to that effect, I am completelly unaware whether some other code-changing aproach would be better or not.  

[John.d.h]

You may be right about it requiring some engine changes.  I really haven't done my homework enough to know that yet.  If it does, I still think the changes would be much smaller than they would to fully integrate campaign mode into the engine, so I think my way is a safer bet from a stability/bugs standpoint.

But I think what hailstone is talking aoubt is: even if GAE's code allows your python script to hook into it... one thing is to grant that access to your script, a completelly diferent one is for your script to lend its grant to whomever can copy-paste a LUA line.

I don't really understand what you mean.  Are you saying you're concerned with people writing malicious scripts and executing them from GAE?  If so, I think people writing malware have much better resources at their disposal.  If you mean that they could somehow "crack in" to GAE, then um... ?

Maybe I didn't explain myself all that well.  What the runtime script does (hypothetically) is watch the Glest/GAE application and when it makes a function call for something like winning or losing the scenario, a player getting defeated, etc., it would write these things to a text file.  For the unlocking mechanism, maybe the scenarios could be stored in a format that Glest/GAE can't run (like *.txt), and then to unlock the scenario, the script reads the file and copies the contents to a new GAE-readable scenario file (*.xml, I think?), optionally with parameters determined by the previous scenario.
Example:

Player launches the lobby.  The lobby prompts Player, and Player chooses the campaign he wants to run.

Welcome to the Glest campaign lobby.  Please enter you selection:
1. New campaign
2. Resume campaign

>2

You have chosen to resume a campaign.  You have saved progress in 2 campaigns.  Please enter your selection:
1. Scrambled Eggs
2. Eye of the Walrus

>2

You have chosen the campaign "Eye of the Walrus".  You have 3 scenarios unlocked.  Please enter your selection:
1. Atrium
2. Green Tea
3. Stairway to Utah

>3

You have selected to play the scenario "Stairway to Utah" from the campaign "Eye of the Walrus".  Your game will now launch.

The lobby now launches the game client and tells it to run stairway_to_utah.xml.  It also launches the runtime script.  As Player battles against his vicious foes, the runtime script takes notes of what happens and writes values to predefined variables in a text file.  In this particular scenario, Player has to fight against two AI opponents while trying to keep his AI teammate alive.  If the teammate dies, the runtime script makes a note that teammate_dies=1.  Otherwise, it leaves the value as 0.  Also, in this scenario, the runtime script is told to make a note of the player's gold stash at the end and write it to the variable finishing_gold.

When Player beats the scenario, the runtime script compares variables and checks the campaign file to see if it should unlock another scenario (or cinematic?).  The campaign file says that if teammate_dies is equal to zero, the runtime script should unlock unicorn_city.xml, and if it is equal to one, then it should instead unlock faculty_and_staff.xml.  In this case, Player was careless and let his teammate die, but he saved up 1500 gold.  So, the runtime script finds the un-runnable version of the scenario, faculty_and_staff.txt, makes a copy, and changes the extension to *.xml (thereby "unlocking" it, or making it playable).  In faculty_and_staff.xml, the runtime script writes that finishing_gold from the previous scenario was 1500.

[jda]

You may be right about it requiring some engine changes.  I really haven't done my homework enough to know that yet.  If it does, I still think the changes would be much smaller than they would to fully integrate campaign mode into the engine, so I think my way is a safer bet from a stability/bugs standpoint.

I wouldn't know whether the changes would be smaller or not as I'm unaware of other aproaches being discussed (on the MG thread, Titi already said implementing anything beyond scenario1_completed=>unlock_scenario2 would not be contemplated any time soon; I'm unaware of another discussion on this subject on this GAE board).

But I think what hailstone is talking aoubt is: even if GAE's code allows your python script to hook into it... one thing is to grant that access to your script, a completelly diferent one is for your script to lend its grant to whomever can copy-paste a LUA line.

I don't really understand what you mean.  Are you saying you're concerned with people writing malicious scripts and executing them from GAE?  If so, I think people writing malware have much better resources at their disposal.  If you mean that they could somehow "crack in" to GAE, then um... ?

First and foremost I was trying to interpret hailstone's comment, an atempt which I may have been succesful in or not, hailstone is the only one who can clarify that.
My view: Am I correct in assuming you're a Windows user?   Linux aproach to security is far tighter and far simpler than Windows (which IMO simply has no pro-active aproach on security, it just tries to mend the holes ). On (at least old school) Linux, you don't have an application (e.g. a firewall) trying to watch over every other application running on the system, usually by allowing only firewall-knowledge-based so called "safe applications" to realize "safe actions" or by relying on the user's decision to allow it or not (being that in 99% of the cases, the user doesn't really have a clue).
So, hipothetically... now... on your Windows you have a "safe application" allowed to do something which is actually unsafe but it must be done eventually (everything on a computer system must be allowed to be done sometime, otherwise there's no point in having it on the system anyways, is there?) and that particular application is meant to perform that unsafe action so, for that app, it's a "safe action". Now... the application was developped to perform that action but, for some reason, its developpers decided to read when and how to do it from an unencrypted plain-text file... Wonderful... you don't even need access to the application itself to completelly messup your computer, just to the text file... (considering most Windows single-user machines run their user sessions as administrators... it's all wide-open ).

The old school linux aproach is to make each application responsible for nto doing/allowing such silly mistakes. It's a different culture and the popularisation of Linux may actually break it. Look at the Slackware linux distro for one that (I think) follows this kind of old school and only includes this kind of really safe applications. Debian (on which e.g. the popular Ubuntu is based) Stable flavour might be an almost as safe and more user-friendly distro alternative.
On my Ubuntu, most updates I get are security updates directly from "upstream" Debian. Some of these refer to stuff such as "memory leak leading to possible root privlege escalation", vaguelly meaning something as elusive as your bad allocation of RAM for your app might lead to a malicious person to gain ownership access to your machine.  
Some video cards out there (to which Glest will have (almost) full access might get get phisically damaged from issuing an unfriendly (from that card's "perspective") command.  
So... in this example... between your script and the card, you've got Glest. For glest, between itself and the card it has OpenGL or DirectX. Between these and the actual card, there's the card driver. Linux aproach is to NOT solelly relly on the driver's, nor the 3D access layer's, nor Glest's nor your python script's safe practices but to expect each and every one of them implements them thouroughly.   Preferably, the end-user should be educated to not break that either.
That's why Linux is (more) secure and Windows apps claiming to keep your PC safe are nothing but frauds.

Maybe I didn't explain myself all that well.

I think most of what you explained was beuatifully done so, hence I'll just quote and post my concerning doubts:

What the runtime script does (hypothetically) is watch the Glest/GAE application and when it makes a function call for something like winning or losing the scenario, a player getting defeated, etc.,

How does the runtime script do that? Through the said hooks? Is that possible with current Glest's? Have you tryed it yet?

it would write these things to a text file.  For the unlocking mechanism, maybe the scenarios could be stored in a format that Glest/GAE can't run (like *.txt), and then to unlock the scenario, the script reads the file and copies the contents to a new GAE-readable scenario file (*.xml, I think?), optionally with parameters determined by the previous scenario.

I have nothing to object to this. Honestly. I just wanted to say it sounds great. I'll quit it now and really only post my doubts.

The lobby now launches the game client and tells it to run stairway_to_utah.xml.

How? I am unaware of any command-line arguments (parameters passed to Glest on invocation) but my unawareness of this by no means mean there aren't such parameters.  

It also launches the runtime script.

I assume the "runtime script" is the one watching the Glest/GAE application, right? Again... how? Did you test this?

As Player battles against his vicious foes, the runtime script takes notes of what happens and writes values to predefined variables in a text file.

"What happens" and what "notes to take" being controlled by the earlier mentioned python hooks, right? Again, have you tested this yet? Can it actually be done with either of the current engines?

Hope that helped.  

[Yggdrasil]

• A way to launch Glest/MG/GAE with parameters that would make it run a specific scenario, so we can do something like os.system("glest -scenario %(user_selection)").  No idea if this is possible, presently or in the future.

This should be easy to add. It's similar to the map preview for the map editor.

• The ability to hook function calls from Glest and launch a script based on these calls.  For example, when the player beats the scenario, the runtime script launches a write-to-file script.  I think this is doable, but I need to learn a lot more about hooking.
  

This is unnecessary bloat with not much use. I would just use the return value of the glest process to indicate the result of the game, just win or loose. You can then catch this value in python and interpret it as you like.

If these two things are possible, I believe it will be possible to run campaigns for all three engines without modifying the engines themselves.

As you see it needs changes in the "engine". I'm also not really a fan of such frontends for things we better have integrated. But if you want i can add the mentioned stuff above. Maybe also interesting for people trying to test their scenarios.

[John.d.h]

First and foremost I was trying to interpret hailstone's comment, an atempt which I may have been succesful in or not, hailstone is the only one who can clarify that.
My view: Am I correct in assuming you're a Windows user?

Let's just say I'm a reformed Windows user.  I've been using Ubuntu as my primary OS for quite some time now.

something as elusive as your bad allocation of RAM for your app might lead to a malicious person to gain ownership access to your machine. 
Some video cards out there (to which Glest will have (almost) full access might get get phisically damaged from issuing an unfriendly (from that card's "perspective") command. 
So... in this example... between your script and the card, you've got Glest. For glest, between itself and the card it has OpenGL or DirectX. Between these and the actual card, there's the card driver. Linux aproach is to NOT solelly relly on the driver's, nor the 3D access layer's, nor Glest's nor your python script's safe practices but to expect each and every one of them implements them thouroughly.

Interesting.

Windows apps claiming to keep your PC safe are nothing but frauds.

You can't protect people from their own stupidity.  The only way to keep a Windows box safe is to turn it off and unplug it.

How does the runtime script do that? Through the said hooks? Is that possible with current Glest's? Have you tryed it yet?

Dunno yet.  Hopefully.  Dunno.  Nope.

"What happens" and what "notes to take" being controlled by the earlier mentioned python hooks, right? Again, have you tested this yet? Can it actually be done with either of the current engines?

Yes, or somehow specified in the scenario/campaign file.  Not even a little bit.  Your guess is as good as mine.

• A way to launch Glest/MG/GAE with parameters that would make it run a specific scenario, so we can do something like os.system("glest -scenario %(user_selection)").  No idea if this is possible, presently or in the future.

This should be easy to add. It's similar to the map preview for the map editor.

Sweet. :thumbup:

• The ability to hook function calls from Glest and launch a script based on these calls.  For example, when the player beats the scenario, the runtime script launches a write-to-file script.  I think this is doable, but I need to learn a lot more about hooking.
  

This is unnecessary bloat with not much use. I would just use the return value of the glest process to indicate the result of the game, just win or loose. You can then catch this value in python and interpret it as you like.

Sounds good to me, but I was thinking there could be more values than just "win" and "lose", so that a player's actions could have much more impact on future scenarios.  That would certainly be a good (and easier) starting point, though.

If these two things are possible, I believe it will be possible to run campaigns for all three engines without modifying the engines themselves.

As you see it needs changes in the "engine". I'm also not really a fan of such frontends for things we better have integrated. But if you want i can add the mentioned stuff above. Maybe also interesting for people trying to test their scenarios.

I have no problem with someone integrating it directly into the engine.  I was just going with the front-end idea because it's something that I could do (mostly) on my own and with probably less modification of the engine, so hopefully without screwing anything up or introducing a slew of new bugs.

[silnarm]

Interesting proposal, I can only echo the sentiments of my 'colleagues' This would be better if were more tightly integrated with the engine.  That said, the hooks you require would, as Yggdrasil pointed out, not be difficult to add, so if you wish to pursue the idea, you will get the engine support you require.

For the future, I think a campaign sub-menu, effectively specified in XML & Lua, to control what is available and what isn't. So to start with only the first scenario button is enabled, the others 'greyed out'. This would also allow complete modder control of how a campaign progresses, also supporting 'branching' campaigns out of the box.

Food for thought. Also, note that you can save files from lua, you could save whatever information you might need later while in a scenario, and load it all in the sub-menu scripts to decide what options to enable/disable/show/hide... etc.

[jda]

Food for thought. Also, note that you can save files from lua, you could save whatever information you might need later while in a scenario, and load it all in the sub-menu scripts to decide what options to enable/disable/show/hide... etc.

Heck, the darned hooks I was suspicious of aren't needed at all! LMAO! And it's secure as the python script won't need to do system calls on the engine to get the infos...

But I agree with silnarm's perspective (better done in-engine I guess) would be best. And all in the post sounds good to me.  

[John.d.h]

Interesting proposal, I can only echo the sentiments of my 'colleagues' This would be better if were more tightly integrated with the engine.  That said, the hooks you require would, as Yggdrasil pointed out, not be difficult to add, so if you wish to pursue the idea, you will get the engine support you require.

I'll be looking into this more in the weeks to come, but there are still a lot of things I need to learn how to do.  I'm glad to have the support, though.

For the future, I think a campaign sub-menu, effectively specified in XML & Lua, to control what is available and what isn't. So to start with only the first scenario button is enabled, the others 'greyed out'. This would also allow complete modder control of how a campaign progresses, also supporting 'branching' campaigns out of the box.

Food for thought. Also, note that you can save files from lua, you could save whatever information you might need later while in a scenario, and load it all in the sub-menu scripts to decide what options to enable/disable/show/hide... etc.

Well that makes my job a lot easier, I think.