Solution for random chance events and reloads

[Kaz]

I think I have an idea that could deter players from reloading over and over to get the best results in events based on chance. It's pretty simple, and I wouldn't be surprised if others have suggested this..

 

Once a player commits to a random event, the game globally stores and locks that variable for that specific play through.

 

For implementation this means assigning a unique ID to every new game you create, and making sure save games that branch from it inherits the same ID. You'll also need a file to store all of the random checks the player makes. With this system if the player fails or succeeds at any check, the event is recorded on a file independent from your save game and associated with the play through. Once you fail or succeed in a pickpocket check, the result will always be the same for that party on that particular check no matter how many times you reload.

 

Now, cheaters will always cheat, and this is by no means a way to secure that data. If someone really wanted to alter that file it would be a fairly easy task. No the point is to make the designer's intention more black and white for the player. It was never intended by the original designers to allow thieves with 15% pickpocket to steal plate mail by reloading a bunch. But because it was possible using only legitimate features like "load game" it allowed for a lot of gray area.

 

This system still leaves room for the player to reload if there's a negative result and avoid the check altogether, but it prevents him from reloading until there's a positive one.

[quechn1tlan]

Why, because you can't live with someone somewhere liking to reload until he\she gets satisfactory results?

In FO I shoot and reload untill i hit enemies. Also with no points invested in thieving I steal everything not bolted down. I like it, and it's not a game mechanic that hinders anyone anythere. It's not a feature but a way to play the game. So don't tell others that they're doing it wrong.

[Kaz]

While we're at it let's ask for a game mode where every check made auto succeeds. There you go, I just saved you a ton of reloads Or are you saying you derive pleasure from the re-loading process itself?

 

But seriously let's look at the attainable rewards / loot that's locked up behind random chance. The reloading play style would unlock almost all of it while the "honorable non reloader" only receives a fraction of it based on the skills s/he picked. From a design standpoint that means you're rewarding reloading behavior while punishing players who try to role-play or just try to stay away from cheese. That feels broken to me, but that's how the games were made and I see no problem with your play style because you were leveraging legit game features. A question for you is - given the opportunity to redefine these things from the ground up, would you choose to implement game mechanics that reward players who reload over and over? And why would a developer choose to do so?

 

If we can I'd prefer to discuss ways to minimizing reloads in stead of focusing on whether reloading itself is right or wrong.

[Nerei]

Basically what you want is the game to save the random seed. That is a fairly common method actually, Firaxis did it in the 2012 Xcom game and from what I remember have done it in basically all Civilization games since III (or allowed it as an option)

 

The problem I see with it is how to do it effectively in a very freeform game. Either you have to write it into the savegame post creation, which I would say will likely increase the chance of corrupting it, especially if you save infrequent.

I still remember trying ToEE ironman 3 times and all 3 failing due to corrupted savegame files so I am quite paranoid with tampering with them, be it me or the game doing it.

Also it would just mean that players would have to create more than one savegame (say save + quicksave to keep it fast) to cheat the system and if it is that easy to beat, is it even worth it then? Naturally you could write to all files, but that could be a real mess.

 

If you take the Xcom approach and basically roll a huge number of virtual dice then the player just need to go pickpocket a random peasant (or whatever activity would use that variable) to burn that bad roll and it is back to square one. This approach (which IMO is by far the better as it does not tamper with files post creation) is fairly bad for freeform games.

 

 

That said I really do not understand this obsession with such systems. I really think it is up to the player to decide how to play the game, not the devs or other players. If you want to have such restrictions, I honestly think you should impose them on yourself (or at the very least have it as an option) instead of imposing them on everyone.

Had this been a MMO or a competitive multiplayer game I would understand it, there it spoils the game for other people if you do it. However for a game that are very unlikely to even include multiplayer so it would just affect the player. It really feels like imposing something on players needlessly (and not even that effective a system either) and wasting limited resources doing so.

If there should be a feature to save the random seed it definitely should be optional.

 

There is also the Ironman (or trial or iron as they call it) mode that pretty much prevents all kinds of reloading, with that already there I do not see any reason to create another softcore ironman mode.

[Kaz]

The problem I see with it is how to do it effectively in a very freeform game. Either you have to write it into the savegame post creation, which I would say will likely increase the chance of corrupting it, especially if you save infrequent.

I still remember trying ToEE ironman 3 times and all 3 failing due to corrupted savegame files so I am quite paranoid with tampering with them, be it me or the game doing it.

Also it would just mean that players would have to create more than one savegame (say save + quicksave to keep it fast) to cheat the system and if it is that easy to beat, is it even worth it then? Naturally you could write to all files, but that could be a real mess.

 

This is entirely up to the method of implementation. But yeah that's why I suggested the file which keeps track of these checks be a separate file as there is no need to retroactively write anything to the save file this way. The game could just reference the external file when it encounters a check that's been made already.

 

I didn't want to go in this direction but here goes..

So every time a similar point is made on reloading behavior I often see these kinds of responses.

- Don't force your play-style on me

- People should have more will power and resist reloading

- Including measures against reloading is like hand holding for the weak who can't govern themselves

 

If I made a thread saying, hey I really think the default shortcut for the game menu should be the escape button and not "o", no one would care. But since I often see strong reactions like the above you guys obviously do care, and there's interest in keeping things the way they are. Disregarding playstyles for a minute, one forth of the skills available to the thief class was effectively a dump stat if you played the reload game. I think a lot of people would objectively look at that and say, hey that's a bit broken. What are the arguments in favor of choosing to leave things the way they are?

 

Like I said in a post above somewhere, given the opportunity to build a new game, why would you be against attempts to minimize situations where it's advantageous for the player to reload? Shouldn't we be working towards the opposite?

Edited November 11, 2012 by Kaz

[Kaz]

Btw, sorry if i sound angry / confrontational, i just want to understand the other side of the argument. Love you guys

[MReed]

Hey, I've got an idea -- maybe when the player dies, the game should notify a central server that you are no longer eligible to play, format your hard drive, then start a self-destruct sequence on your computer which will result in an explosion that will cause your house to burn down. That would be really hardcore, wouldn't it? And at the same time, if the player takes any damage at all, the player character dies, but monster's require roughly 2 billion hits to kill -- that way, there would be loads of strategy, because the only way to have any strategy in the game is if there are real consequences, right?

 

Or, just maybe, the game developers should spend their time making a fun game, rather than attempting to dictate the "right way to play the game" to the player. Nah, that's obviously crazy talk -- there really is only one way to play the game, everybody else is doing it wrong, right?

[Sacred_Path]

The game should be designed in a way that accomodates no-reload play more. For instance, if you have only very small chances of stealing something, and if failure means your entire game goes to hell (because of guards spawning that kill you), the only option in a no reload game is to avoid stealing altogether.

[rjshae]

For implementation this means assigning a unique ID to every new game you create, and making sure save games that branch from it inherits the same ID. You'll also need a file to store all of the random checks the player makes. With this system if the player fails or succeeds at any check, the event is recorded on a file independent from your save game and associated with the play through. Once you fail or succeed in a pickpocket check, the result will always be the same for that party on that particular check no matter how many times you reload.

I think it's easier than that: at the start of the game a global random key is generated. During the game compile, each randomly branching outcome is also assigned a random value. During play, each branching outcome is determined using an XOR operation between the global key and the outcome random value. Thus the game save only needs to store one key.

 

And yes I've suggested this before.

Edited November 11, 2012 by rjshae

[Nerei]

The problem I see with it is how to do it effectively in a very freeform game. Either you have to write it into the savegame post creation, which I would say will likely increase the chance of corrupting it, especially if you save infrequent.

I still remember trying ToEE ironman 3 times and all 3 failing due to corrupted savegame files so I am quite paranoid with tampering with them, be it me or the game doing it.

Also it would just mean that players would have to create more than one savegame (say save + quicksave to keep it fast) to cheat the system and if it is that easy to beat, is it even worth it then? Naturally you could write to all files, but that could be a real mess.

 

This is entirely up to the method of implementation. But yeah that's why I suggested the file which keeps track of these checks be a separate file as there is no need to retroactively write anything to the save file this way. The game could just reference the external file when it encounters a check that's been made already.

 

I didn't want to go in this direction but here goes..

So every time a similar point is made on reloading behavior I often see these kinds of responses.

- Don't force your play-style on me

- People should have more will power and resist reloading

- Including measures against reloading is like hand holding for the weak who can't govern themselves

 

If I made a thread saying, hey I really think the default shortcut for the game menu should be the escape button and not "o", no one would care. But since I often see strong reactions like the above you guys obviously do care, and there's interest in keeping things the way they are. Disregarding playstyles for a minute, one forth of the skills available to the thief class was effectively a dump stat if you played the reload game. I think a lot of people would objectively look at that and say, hey that's a bit broken. What are the arguments in favor of choosing to leave things the way they are?

 

Like I said in a post above somewhere, given the opportunity to build a new game, why would you be against attempts to minimize situations where it's advantageous for the player to reload? Shouldn't we be working towards the opposite?

 

The real problem I see with saving the random seed (or pre-generating it or whatever) is that you do not affect my need (or interest in) reloading, only my ability to do so. That is why I have a problem with it as a mechanic. It just restrict my options without giving anything.

Cheap results will stay cheap and mechanics like "save or die" will stay the same.

Rolling a "9" when you have to roll "10" in order to avoid dying is not changed, only my ability to try again should I want to do that.

If such mechanics is included or not is about game design which is where you should look in order to reduce the need for reloading, not in locking the random seed.

Locking me to a result of a check will just lock me to results of cheap mechanics if these are in the game. It will not make me feel those results are less cheap and make me less inclined to reload.

 

If it affected my need to or interest in reload I would have no problem with it, but I really do not see how it can do that. It just makes it harder to do so when I want to do that.

 

 

Finally If it is possible to fairly easily defeat the anti-cheat mechanic (which will likely be discovered within weeks of the release if there is a decent amount of people interested in doing so), what is then gained?

You have just added another step to my reload sequence giving me more busywork to do (or forced me to take another route to get the result I want). It would not make me do it less unless it was such a long and annoying process that I would rather stick with my old result, which is not exactly good either.

 

In short, make the game so I do not want to or do not feel the need to reload, not a game where it is hard to reload. Locking the random seed is the latter.

 

Edit: I cannot speak for other people than myself, but I have no problems with your post. Also if any of my posts sound harsh then I am sorry that is not the intention

Edited November 11, 2012 by Nerei

[mstark]

For implementation this means assigning a unique ID to every new game you create, and making sure save games that branch from it inherits the same ID. You'll also need a file to store all of the random checks the player makes. With this system if the player fails or succeeds at any check, the event is recorded on a file independent from your save game and associated with the play through. Once you fail or succeed in a pickpocket check, the result will always be the same for that party on that particular check no matter how many times you reload.

I think it's easier than that: at the start of the game a global random key is generated. During the game compile, each randomly branching outcome is also assigned a random value. During play, each branching outcome is determined using an XOR operation between the global key and the outcome random value. Thus the game save only needs to store one key.

 

And yes I've suggested this before.

I had a similar idea when I read the OP, but I think there might be a serious problem with something like pre-calculating the lock picking skill needed for every single lock in game for each play through. You could end up seeing tutorials encouraging scenarios like this: If you always start the game with X in lock picking, and increase it to Y over the course of your play through, you will succeed at all XOR checks. In addition to this, if you fail a check, you could presumably increase your skill level and come back at a later point for another XOR check. This could encourage things like abusing potions or spells (together with reloads) to reset the XOR check, since it would have to perform a new check every time your skill value changes.

 

I think the PE devs mentioned they are planning to have a minimum required skill in order to execute certain actions in game, there'll essentially be a black zone: your skill is too low to ever succeed at picking this lock. A grey zone: With a few tries, and using up a number of lock picks (money sinks), you may succeed at picking this lock. A white zone: Your skill is so overwhelming you will unlock this chest immediately. This, while discouraging at least some save scumming, still keeps the random element in game. It also has a similar effect as what using a global key would have, for pre-determining what you can and cannot do with a certain skill range.

 

In short, make the game so I do not want to or do not feel the need to reload, not a game where it is hard to reload. Locking the random seed is the latter.

This. This is the essence of good design.

 

The reload feature of the IE games was amazing, and part of what made the game great. There's nothing wrong with that feature in itself. Unfortunately, the entire game system (D&D) used in the IE games was never meant to allow for something like reloading. I'm both happy and anxious about the PE team developing their own system .

Edited November 11, 2012 by mstark

[rjshae]

I had a similar idea when I read the OP, but I think there might be a serious problem with something like pre-calculating the lock picking skill needed for every single lock in game for each play through. You could end up seeing tutorials encouraging scenarios like this: If you always start the game with X in lock picking, and increase it to Y over the course of your play through, you will succeed at all XOR checks. In addition to this, if you fail a check, you could presumably increase your skill level and come back at a later point for another XOR check. This could encourage things like abusing potions or spells (together with reloads) to reset the XOR check, since it would have to perform a new check every time your skill value changes.

How is that a problem? It's realistic to come back to an unsolved problem when your skills have improved. I'd just call that a good simulation.

[rjshae]

In short, make the game so I do not want to or do not feel the need to reload, not a game where it is hard to reload. Locking the random seed is the latter.

This. This is the essence of good design.

 

Ah, so every game that has ever been made is a bad design? You're espousing nonsense. Making the game especially hard to reload just encourages a different path through the game; one that requires dealing with failure rather than just reloading until you obtain success.

[mstark]

I had a similar idea when I read the OP, but I think there might be a serious problem with something like pre-calculating the lock picking skill needed for every single lock in game for each play through. You could end up seeing tutorials encouraging scenarios like this: If you always start the game with X in lock picking, and increase it to Y over the course of your play through, you will succeed at all XOR checks. In addition to this, if you fail a check, you could presumably increase your skill level and come back at a later point for another XOR check. This could encourage things like abusing potions or spells (together with reloads) to reset the XOR check, since it would have to perform a new check every time your skill value changes.

How is that a problem? It's realistic to come back to an unsolved problem when your skills have improved. I'd just call that a good simulation.

I think it actually encourages for more abuse/reloading with this system, since there'd likely be ways to alter your skill (equipping items, drinking potions, using abilities, spells...) to trigger another XOR check. You could just keep altering your skill until you succeed with the check, making the system not much different from the original one, in my opinion just adding further annoyance rather than solving the problem.

 

I quite like the system suggested by the PE devs, but I can't remember where or when :/

[mstark]

In short, make the game so I do not want to or do not feel the need to reload, not a game where it is hard to reload. Locking the random seed is the latter.

This. This is the essence of good design.

 

Ah, so every game that has ever been made is a bad design? You're espousing nonsense. Making the game especially hard to reload just encourages a different path through the game; one that requires dealing with failure rather than just reloading until you obtain success.

No, I didn't say this, you're putting words in my mouth.

 

I absolutely agree that I want the game to have consequence (and I will very likely play the game on Trial of Iron on my first play through), but I don't think the system suggested actually solves the problem, even if it's a step in the right direction.

Edited November 11, 2012 by mstark

[rjshae]

I had a similar idea when I read the OP, but I think there might be a serious problem with something like pre-calculating the lock picking skill needed for every single lock in game for each play through. You could end up seeing tutorials encouraging scenarios like this: If you always start the game with X in lock picking, and increase it to Y over the course of your play through, you will succeed at all XOR checks. In addition to this, if you fail a check, you could presumably increase your skill level and come back at a later point for another XOR check. This could encourage things like abusing potions or spells (together with reloads) to reset the XOR check, since it would have to perform a new check every time your skill value changes.

How is that a problem? It's realistic to come back to an unsolved problem when your skills have improved. I'd just call that a good simulation.

I think it actually encourages for more abuse/reloading with this system, since there'd likely be ways to alter your skill (equipping items, drinking potions, using abilities, spells...) to trigger another XOR check. You could just keep altering your skill until you succeed with the check, making the system not much different from the original one, in my opinion just adding further annoyance rather than solving the problem.

The key difference is that you're attacking the problem using in game mechanisms. This isn't a problem because it fits what happens in reality: finding a better tool to do the job. Let the player drink potions, use better tools, or level up. It's a core element of the cRPG that you can solve problems this way. What the developers would need to do is to allow multiple attempts to solve the problem, so that the player can expend resources to get past that obstacle, if they so choose.

Edited November 11, 2012 by rjshae

[mstark]

I had a similar idea when I read the OP, but I think there might be a serious problem with something like pre-calculating the lock picking skill needed for every single lock in game for each play through. You could end up seeing tutorials encouraging scenarios like this: If you always start the game with X in lock picking, and increase it to Y over the course of your play through, you will succeed at all XOR checks. In addition to this, if you fail a check, you could presumably increase your skill level and come back at a later point for another XOR check. This could encourage things like abusing potions or spells (together with reloads) to reset the XOR check, since it would have to perform a new check every time your skill value changes.

How is that a problem? It's realistic to come back to an unsolved problem when your skills have improved. I'd just call that a good simulation.

I think it actually encourages for more abuse/reloading with this system, since there'd likely be ways to alter your skill (equipping items, drinking potions, using abilities, spells...) to trigger another XOR check. You could just keep altering your skill until you succeed with the check, making the system not much different from the original one, in my opinion just adding further annoyance rather than solving the problem.

The key difference is that you're attacking the problem using in game mechanisms. This isn't a problem because it fits what happens in reality: finding a better tool to do the job. Let the player drink potions, use better tools, or level up. It's a core element of the cRPG that you can solve problems this way.

I absolutely agree with this. However, do we also agree that the problem with the IE games was the highly random element to success involved in any action, encouraging you to keep re-loading until you succeeded ("save scumming")?

 

The system suggested by you, assuming D&D game mechanics in the final product (which we know won't be the case), would allow you to do the exact same thing: you'd just have to swallow your potion that increases thieving by 20 and try again, then equip a robe that increases it by 5 and try again, then equip gloves that increases it by 15 and try again. You simply try all your equipment in different combinations in order to get the maximum amount of XOR checks out of every skill check encountered. Just like the IE games, it's possible to abuse the system. In this case, it encourages "equipment scumming" (lol) rather than save scumming. We could choose not to to reload, or not to test all our equipment, but it's the most effective way of playing the game. So, in my opinion, the core of the problem hasn't been solved, just been given a new name.

 

I still prefer a system that is less random (immediately discouraging save scumming, and instead encouraging raising your skills), as suggested by the devs (wish I could find where!).

Edited November 11, 2012 by mstark

[Utukka]

Personally..who cares. I like to play ironman/hardcore, w/e you want to call it, the majority likes to play softcore(diablo style). I'm not saying you should just give people everything because they're just gonna reload till it works but that's part of the point. If he's gonna reload/cheat, he's gonna do it and it doesn't affect my style, hell, if he wants to spend 30 minutes reloading till it works, all the more power to him. The bottom line is, the role play element is available for ME to use to guess what, roleplay the way I want to. I suppose if you're looking to post on youtube/forums, "look at me guys, I beat this challenging unabusable game before everyone else!" or "look at me, I'm one of the few that could make it through super duper hard mode", then I suppose trying to force the player to play a certain way makes sense.

[Kaz]

@Utukka - I'm totally cool with this being an option you can trigger at the start of the game.

 

@rjshae

@mstark

I think we're all on the same page here and the only misunderstanding is in the implementation. The random element (the seed) that is involved in the equation is only generated once at the start of a session / play through. No more random numbers are generated after that. From there every time the player triggers a check, the game takes the seed and makes a blind decision whether it succeeded or not. It then considers the variables like difficulty of check, character's skill, gear, buffs, and alters the outcome using multipliers and additions. This means it's possible to bend the odds in your favor through skills and temporary tools like potions of master thieving, but the initial random number is always locked in place no matter how many times you reload or switch items around.

 

This may have been the intent anyway but consumable items like lock picks could serve the function of re-seeding, i.e. reloading in the old sense, while potions that increase the skill of the thief could pad the result determined by the original seed. When allowing consumables I think it's also important the game informs you whether it's even worth dumping more lock picks or not. If your skill level is simply not within the threshold to pick that lock the game should give you some feedback like "Despite your best efforts this lock's mechanism appears to be too complex for you" While if you are within the threshold but was simply unlucky it might tell you "You come close to picking the lock, but suddenly the lock pick breaks in half". I'm not a writer but you get the idea.

 

Also @rjshae - I knew something simple as this would have been thought of already. It was an interesting read, thanks for the link!

Edited November 11, 2012 by Kaz

[Utukka]

@Utukka - I'm totally cool with this being an option you can trigger at the start of the game.

 

I suppose I don't even get the point of it being an option for a single player only game. It's a waste of design time and effort. Design and balance the game as if people wont be saving/reloading for best results. Can you really not restrict yourself from abusing the game? Is it an ego thing that you want people to know for a fact that you couldn't have abused to get past? What's your reasoning for that they should focus on stopping them from reloading? Do your accomplishments feel marginalized to you if you know others didn't absolutely play through the way you did? Do you feel the developers will design the game in the idea that people will reload? Would it make you feel better if the developers said they ARE NOT taking into account that you can save/reload? Should the game be unmoddable so others can't take out the difficulty/intended gameplay?

Edited November 11, 2012 by Utukka

[Utukka]

If we can I'd prefer to discuss ways to minimizing reloads in stead of focusing on whether reloading itself is right or wrong.

 

Missed that line, my bad.

[Hassat Hunter]

This sounds like a case of "medicine worse than the disease"... taking D&D as base a player with a seed of 1 will be screwed... all game long. The player with seed 20 will succeed at everything. If it uses a system like random number 0-10 and each check has 10 different values based on the seed... WASTED DEVELOPER TIME!

Seriously, why is this an issue?

 

I much rather have less random elements out of combat (no rolls, just a lockpick requirement) than this. Same result, not the same crap/time to implent.

[Kaz]

Taking randomness out of non-combat skill checks is fine, I can roll that way too. But I think leaving a little random influence in there adds excitement. It allows for funky scenarios like a fighter getting extremely lucky in bashing open a locked chest after a failed attempt by your thief. It gives incentive for players to try things, even when the odds are stacked against them. If checks were static, once you knew the threshold for a lock you would never bother with it until you had enough skill points. A little off topic but I've read somewhere that humans draw more pleasure from random rewards compared to predictable ones. I think it explains why people enjoy gambling, or grinding for hours in an MMO for random drops. I'm not suggesting turning PE into a Diablo clone, but it's something to consider.

 

This sounds like a case of "medicine worse than the disease"... taking D&D as base a player with a seed of 1 will be screwed... all game long. The player with seed 20 will succeed at everything. If it uses a system like random number 0-10 and each check has 10 different values based on the seed... WASTED DEVELOPER TIME!

Seriously, why is this an issue?

 

I much rather have less random elements out of combat (no rolls, just a lockpick requirement) than this. Same result, not the same crap/time to implent.

 

Where you misunderstood me, and I should have made this detail clear, is that even though you're only rolling a random number once at the start of each game, the result for each check will be wildly different. To explain, let's say you could peek at the excel sheet that tracks all of the locks in the game. That file would likely track information like the area the lock is in, difficulty rating, what kind of loot it holds, etc. All I'm suggesting is to add another column to track a unique ID for each lock / skill check. Let's also say the random number generated for a particular play through was 454364. Every time you make a skill check the game takes the game seed and checkID number and manipulates them together to produce a two digit number. At this point the number has no meaning, it's the same thing as rolling a number between 0 and 99. It would then account for skill level, bonus and buffs and if the resulting number is higher than the difficulty rating, yay you succeeded. What's important is that the base number is random, unique for every check, and is consistent between reloads.

 

As for the "wastes dev time" argument, adding another column to a spreadsheet (randomly generated numbers at that) is not labor intensive.. don't know what else I can say about that.

Edited November 14, 2012 by Kaz

[AGX-17]

The problem is that often times, the sorts of results you're talking about are insufferably slim, and if a player were to play the game through 100 times, they might never get the ideal result because it's still based on chance. All you're doing is permanently locking some players out of content based on chance, period.

Edited November 14, 2012 by AGX-17

[Kaz]

I'd say that's a balancing issue, not a fault of the system.