Secret codes for scenarios/Scenario grouping

[titi]

I thought about secret codes for scenarios and scenario bundling.

For the scenario bundling:
Scenarios can be bundled. You select such a scenario bundle like a normal scenario, but when you do so, a new selection shows up showing the parts of this scenario group. ( Technically this can be made with either naming conventions or a new subdirectory structure. )

For the secret codes:
If you want to make  chained scenarios, which are meant to be played one after another secret codes for each part would be great in my opinion.
On the end of every scenario a secret code is shown. To enter the next scenario part, you have to enter the right code, before it starts.
 
Technically this means we need crypted passwords for scenarios. In the glest binary we will have one secret code, which is used to decode/encode these keys. The crypted password can be set in the scenario xml. This will be used to verify access to the scenario and will be shown decrypted when you win a scenario. We need a new tool for scenario creators which will encode the secret words.
 

[PolitikerNEU]

Hmm ... I do like the idea of scenarios being bundled but I don't think some kind of "secret code" is necessary or sensible.

At first, this approach wouldn't really work: Someone could easily write an automatic glest "scenario cracker" using the glest source code working for every scenario - because glest needs to be able to decrypt it. So - if someone wants to cheat, he could anyway - and that's why I propose a different solution - you could cheat more easily there, but I don't think that matters:
Just add a scenario_progress.xml-file which saves your current progress (and maybe add some extra Information about the tries like least time needed you could display) and check the available scenarios based on that file. (A scenario without "win" for a preceding scenario in this xml-file is not accessible)

An approach harder to crack would be to define a special lua-function returning the password on game win. It should return the correct password if the game was really won (based on the current game state) and a wrong one else. The game then tries to decrypt the next scenario using that returned key - if it succeeds, the scneario is available, else not. Using that approach, an automated "scenario cracker" would be really hard to write since you would need to parse the lua source-code so I doubt anyone would do that (you could still manually try to guess the game state using the lua-function).

EDIT: The secret codes could still be used additionally - they are the return-values of the lua-function and could be seperately inserted to make a scneario accessible.

[@kukac@]

Wouldn't it be better, if you write a "do not load" script at the beginning of the scenario, then after the first scenario you run a "next scenario" script? Ok, it can be cracked, but what can not be?

[PolitikerNEU]

Of course there are multiple possibilities to implement this, but your proposal has the disadvantage of not being able to load the scenario if the fomer was won once but the user has exited glest in the meantime.

[titi]

I think the statistics idea storing all the scenarios which are won in the statistics is a good one, but this is another extension. Regarding multiplayer and account based statistics( in the web ? ) this is an endless story of its own. The whole statistic thing is a story of its own, and we should not start it yet in my opinion.

For the secret codes:
I think there is no need to make them really crack  save.
Of course someone could easily look into the code and see the secret code and write a glest password decoder based on this. But I think
this will not really be used by people who want to play. There are several commercial games which use this method and for all of them a password decoder or pw-lists are available soon! But they are still be played the way its meant.
For the player its fun to reach the next level and he can continue later where he stopped. I'm shure this new features will also motivate modders/scenario creators to build us more complex stuff.
And it should not be only a lua function! These basic things should be a part of the normal xml desription of a scenario. In addition lua functions should be able to access this "show code"  things.

I thought a bit more about the code "security"...:
We cannot put the code into the scenario xml-code itself. It would be too easy to crack it, when you modify the xml to show the decrypted code immidiatly with a faked "you win" message. The code should be in its own file and its created using the xml-file itself.
Maybe we should create a checksum or something based on the xml-file.Then we encrypt the scenario password using this checksum. If someone tries to "crack" the password using a modified xml, the checksum will change and it will not be possible to decrypt the password.

[Super Tom]

This is a very good idea and method, I agree with titi way, great!

[John.d.h]

Why not just have something in scenario 1 that writes to file, and then have scenario 2 read from that file?  This could have a lot more implications than just unlocking new scenarios, like having something you did in one scenario affect something in a later scenario, or branching scenarios based on the previous outcome.  Maybe some psuedocode will demonstrate what I mean.

Scenario 1:

Code: [Select]

when beaten,
write to file scenario1 beaten=1Scenario 2:

Code: [Select]

read from file scenario1
if beaten=1
then RUN
else DO NOT RUNScenario 3:

Code: [Select]

when beaten,
write to file scenario3 badguy==alive
then badguyalive=1Scenario 4:

Code: [Select]

read from file scenario3
if badguyalive==1
then run script badguyreturnsScenario 4:

Code: [Select]

when beaten,
if merlin==alive
then merlin_dead=0
else merlin_dead=1Scenario 5a:

Code: [Select]

read from file scenario4
if merlin_dead==0
then RUN
else DO NOT RUNScenario 5b:

Code: [Select]

read from file scenario4
if merlin_dead==1
then RUN
else DO NOT RUN

[PolitikerNEU]

yeah, that's again a really good idea although I don't really thing it would be good to use this as main "scenario-unlocking" thing because then you would have to play the campaign again every time you reinstall Glest (and for me, I do it a lot ...) - so maybe, if the data cannot be found, some "default values" should be used.

And again - even using some sort of "checksum" encryption, an automated password "cracker" could easily be written so that for the user it wouldn't be more difficult to cheat using a password cracker than to cheat with modifying an xml-file saving the scenario progress. And of course you could use the stats-file to link to the scenario-status-save-file where e.g. some values from the previous scenarios are stored so the user could decide which one to take when playing the next scenario in the campaign.

[titi]

OK, its indeed not really possible to have really secret keys and we don't need them.
I just want to describe my initial idea again:
Lets say we have scenario A,B,C which are meant to be played one after another.
If A is successfully finished a code is given that is needed to enter B .
So in the xml-code for scenario part A you will find a win message which contains this entry code for B. What I meant with crypted is only "not instantly readable".
Even simply using the HEX code would be ok as long as its not too easy to read, so no real encryption is needed.  If someone really wants to cheat he can do so and using hexcodes or a bit string will teach those kids something useful for life   .

So what we basically need is:
- A secret code input screen which is shown if needed before a scenario starts
- A standard win message which displays the code for the next scenario
- A lua possibility to show the code for the next part if you want to build your own win message

and the scenario bundling thing mentioned in my first post.

[jda]

and the scenario bundling thing mentioned in my first post.

Ah, that was what I was about to ask, whether it was implemented already (would be nice even without the scenario pre-requisite, be it a code or something else).

I completelly agree with Titi it doesn't need to be "bullet-proof". All codes are breakable anyway and many commercial games actually include "secret codes" to unlock "secret features" (actual CHEATS really), my 10yo stepson finds them all for the PS3 on the Net. His mother keeps telling him that's no fun but I know for a 10yo it is. And he does complete everything without cheats often before he feels like adding an extra layer of "fun" to it.

There's one thing I dislike about the secret codes though: you have to note them somewhere - again reminds me of my stepson with all his little pieces of paper with secret codes.
Couldn't it just be stored somewhere (possibly even just touch a 0-bytes-size file) that scenario A was completed once and you can get on to playing B?
From the player's standpoint it would be like a reminder: "Finish the other g*dd*amn scenario first, it will be a lot more fun than just cheating over it! "
And again, if you don't want to complete one particular scenario... you'll find a way not to anyway.

[titi]

I know it from my sons too.
And ask your son, I bet he had his fun ...

...with all his little pieces of paper with secret codes

Its like gollum in lord of the rings "My treasure.. it belong to me" 

[jda]

LMAO
Oh, that Gollum character sure was fun... 

Yeah, I guess.

[jda]

Sorry for DP'ing, I hadn't really looked at this before. 

Why not just have something in scenario 1 that writes to file, and then have scenario 2 read from that file?  This could have a lot more implications than just unlocking new scenarios, like having something you did in one scenario affect something in a later scenario, or branching scenarios based on the previous outcome.  Maybe some psuedocode will demonstrate what I mean.

I think this is a very good idea though, actually, I think the posted pseudocode is rather limmited. It kinda looks like in all cases it just boils down to whether or not you will be allowed to play the "new" scenario or not. 

But his could actually go much further, like "moving" some sort of game-state from scenario1 to scenario2.
For example, in omega's Labyrinth, it could be used to determine which of the four heroes was still alive from one stage to the next and not bring back those who had already been killed.
This doesn't apply only to fixed-number-of-units scenarios such as that one, it could be used in more "common" scenarios in which you would not only have to beat the oponent but also make sure you still had enough "firepower" to take on the next scenario.
On the other hand, on the first scenario the "foe" might actually be two allied foes (same team) and the winning-condition to beat just one of them. The state of the other foe might carry on to the following scenario too. On the same scenario1 case, the fact the secondary foe was still alive or not might actually be used to choose alternate scenario2 scenarios (say scenario2a and scenario2b).
Still another option would be for you to have your own allied player, and whether it was still standing or not when you beat the foes could have an impact on how the next scenario would be laid out  too.
The possibilities should be limmited only by what the implemented Lua allows you.  

[titi]

Yes, thats all true, Johns idea is very good, but in my opinion its something else.
Of course with these lua functions where a state is written to a file you can do a lot, but this secret code thing is much more simple to handle.
Up to now we didn't see lots of lua based scenarios and this secret code idea will be a first step to just motivate people to produce something fun to play and it will be very simple to setup!

[ElimiNator]

I think what you said is great Titi! I always wanted to make missons, I allredy have but you can play the 10th before the 1st. 

[John.d.h]

Edit: Moved my response to here: https://forum.megaglest.org/index.php?topic=5349.msg47018#msg47018