Forums » Feature Wishing Well » Read Thread

I should probably focus on finishing my first storygame before I worry about the sequel, buuuut... my storygame has stats. It would be nice if the user got to keep their stats in the next game.

Thanks in advance for any help!

-Morgan

I've moved this to the feature wishing well. I'd love to see it happen.

Even if we could just select a Page and Copy it and Paste it back into the same Story with all the same Links, Restrictions, and Scripts - that would be Tremendously Useful!

^this.

Please?

(I'm guessing both of these would actually be a fair bit of work, though.)

Yep, would get pretty complicated b/c you have PageIDs, LinkIDs, ItemIDs, etc to deal with...

This would also have the added benefit of taking out the "Codes" that are required for games like 'The Tower' and worrying about people remembering these codes in order to play the sequel.

I also would looove to see this.

I can't think of any reasonable technical way to implement this... at least the way current storygmames are done. I divulged a bit of the technical details when talking about copying storygames, so maybe you guys can think of something...

Yeah, it seems like each storygame is it's own individual thing. I don't know how saved games work, but I would imagine that's probably where the solution lies. Ask if the user wants to save the game after the end, and somehow have the next game load that saved game and look at all it's stats/items and such at the time and somehow interpret that and load it into the new game.

Though without knowing the limitations of what storygames can see/access, and how saved games work, I can't think much further lol. Of course, even with this solution the author would still have to take some time and interpret their saved games, but the functionality could at least be there for those who wanted it.

I don't think anyone is worried about cheating in storygames? If so, I can move/delete this post out.

The "StoryState" is what the storyengine uses to determine where you are in the story, what you've done, etc. Your browser stores the StoryState and sends it back to the server when you click a link, and save games are merely just storystates stored on the server.

A StoryState is just a structure of data that consists of the following:

• StoryGameID <integer>
• Current PageID <integer>
• Visited PageIDs <list of integers>
• Visited Links <list of pairs>:
  • LinkId <integer>
  • TimesVisited <integer>
• Inventory Items <list of pairs>:
  • ItemId <integer>
  • TimesUsed <integer>
• Variables <list of pairs>
  • VariableName <string>
  • VariableValue <integer>

So, you can see this storystate is a fairly complex data structure. Getting another story to read this would be quite an undertaking... even for advanced/scripting users, as there's no good way to represent complex objects like this (lists/arrays, mostly) in CysScript w/o redoing the scripting engine (which, God help me if I ever have to!).

I don't really think anyone is too worried about cheating, but you may have to ask the authors of more complex storygames that question.

Well, provided all the lists/arrays are pairs, you can simply convert them to a bunch of name/value variables. Variables and items are really the only two things authors will care about carrying over (at least all they should, as anything can just be kept in that form), and the only aspect of items that should matter if it they actually had it in their inventory (so ITEMSTATE). So the way I see it, the way around this would be to create another data type (like storystate), that stores all of these simplified variables.

After this is created, storygames would need a way to read/access these. I imagine a new section where you edit storygames would need to be created for this to happen. Something simple like "Load previous storygame", where the author says what storygame this one needs to access the new type of save file from, and then it would load up the names of the variables it would give access to (since it's just the template it wouldn't have any values for the variables).

After that, the author would have to (probably on the first page), initialize all their storygame variables, setting them to the values brought in by the new data type. Or maybe they could set the starting value of their storygame values by linking it to a loaded variable.

Of course, this is the method if you want to be really really thorough and give them access to everything from their previous storygame lol. Another way would be to create this new data type, but have a fixed number of variables, and then have the author set what they are at the end of their storygame. That would then be loaded into the next storygame that it is related to. This would just eliminate the need for the system to translate the storystate structure into something else, and instead simply give the author a way to pass a bit of info over and use that as they please in the next installment of their series. In all likelihood, the storygame would only need a couple variables from the previous one, not all of them.

Then again, it's late and I'm tired, so maybe none of this makes any sense right now lol.

Ah, an interesting idea, and you're right, exporting variables could solve it; you'd have to recreate items, etc anyway, so may as well use variables.

So, this makes it separate from a "save state", and would mean we'd need to store, at a minimum, an End State consisting of "StoryGameID, Username, List<Variables>".

Some more things to think about...

• Does this happen automatically?
• What about multiple end states? Should one just overwrite the next?
• If there are multiple endstates stored, is just the latest endstate read in?
• Since there's no concept of "related storygames", how would you know which games are related (and therefore should read eachother's endstates?)
• Can any Storygame read any other's end state? IF not, how can this be restricted?
• What would be the syntax for reading another storygame's EndState?
  • e.g.: %MYVAR := $GAME223:VARNAME
• What if a user doesn't want the game to utilize endstate? The author could work around this with an option at the beginning I suppose...

 

• I think the author should have the option to prompt the user after the game is done (around the time you get to rate the game). Otherwise we'll have a bunch of these created for no real reason
• I think too many different EndStates would just get confusing, so yeah, only have one saved, and if the user completes the same game again, give them the option to overwrite the previous one, or keep the previous one instead
• I think the easiest way would be to just make all storygames by the same author related. The author will be the one controlling what they actually use from their own storygames.
• Only allow storygames made by the same author able to read each other's endstates
• I was thinking just use dot notation, assuming that's possible the way it's done now.
  • %MYVAR := %MYGAMES.GAME223.VARNAME OR just
  • %MYVAR := %GAME223.VARNAME
    • and in the latter case just throw an error if it's not actually their game they're trying to access.
• If the user doesn't then they'd just have to either choose the option to not save their ENDSTATE from the previous game, delete their ENDSTATE from the previous game (in a location such as mysaves), or the author would give them the option to load the ENDSTATE into the game or start a brand new game at the beginning of the storygame

 

I think if this is done properly, we could give a storygame access to it's own endstate, which would allow it to carry variables through to a second play-through, and unlock additional things that time around. I think that would be pretty cool to do too.

The way you could do this, if I am understanding correctly in my currently addled brain, is that the user/author could add a "Save Game and End" rather than "End Game," a feature which doesn't currently exist. That link would then save a particular variable into memory, much like the Save Game link already does for the story place. Then, in the next story, there could be a Load Game State link which loads that variable.

So, in other words, Mr X has 100 STR 100 INT 100 DEX. He finishes the game and gets to the place where there would normally be and End Game static link.

The code now has a Save Game and End and a  Load Game State, both built into the system much like $Pagetext or $ITEMSTATE or whatever - I can't remember all the pre-coded variables at this point .

When one clicks "Save Game and End" it saves the variable(s) that the user has defined as persistent variables, like "STR," "DEX," "INT," and puts them into the persistent, specific variable for that user. So "$ENDSTATEALEXP := "STR 100, DEX 100, INT 100"

Then, when the game is loaded and that link clicked on, it remembers by the USERID and his "saved" game and repopulates.

I am talking nonsense, possibly, regardless of brain addling, because I do not know if this is horrible amounts of work.

Interesting idea, though.

To play devil's advocate, one could write a story like Magus: Betrayal, and just trust the reader not to "cheat." We all - well some of us - remember reading those old storybooks and possibly jacking up our health, for instance, when we would have died otherwise. There are always back buttons, but one could literally create a page for "transferring one's character," and just ask the reader to input the correct values from the last story, making the maximum still a difficult challenge. That way, if someone "cheats," the game/story is still challenging.

For your last point I'd disagree. The second story could build off of the choices in the first story (carried over through variables), and the variables themselves. You'd pretty much have to prompt the user and ask "What decision did you make before?", and "What was your strength in the first game?" a whole bunch of times, and just hope they remember it. Not to mention if we're dealing with a variable that could be a whole bunch of different numbers (EG - Strength could be a 4, or 8, or 12, or 16, etc), the author would need to give as many options as there were possibilities, which just wouldn't be viable for many variables.

I mean, for simpler stories sure, they could do it your way, but it's not exactly an alternative for those with complex storygames.

Okay, so what about going outside the "StoryState" box? You could add... achievements. Like trophies, but users get to define them and dole them out in their storygames. Once you have an achievement, you have it -- it doesn't matter if you restart the game. Games can also check to see if you have a particular achievement. So, people who like players to play their games in sequence can give an achievement at the end of one game, and check for it at the beginning of the next.

If you were feeling extra-super-nice, you could add a hidden variables list to the achievement, so we could stuff data into it and get it back out. But even without that, I think you could do a ton with a binary "has/doesn't have" achievement system.