Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Doing something when a user loads a savegame. [SC2]

My current RPG project using SugarCube 2 is going to be released in episodes (drip feeding the story rather than release it as one big file, which is also being done for practical reasons). At the moment I'm using three numeric variables:

$playep = current episode the player is on
$gameep = current episode the game has reached
$slflow = point in the story line the player has reached (related to the episode the player is on)

As the game is part "open world" and part storyline driven (which can be totally ignored) I have an indicator on when the user should save as they've reached the end of the episode. Now it's fine when they save at that point and don't go any further and reload, but as they can continue to play the game and do side quests while waiting for the next episode it gets really complicated as I need to check where they're at for a quick "Previously..." intro for the episode (just like on TV) and possibly change a few things as well (at two points the map expands so I need to shift the x and y locations where the player is at around so if the map extends to the left and the x location is 3 it becomes 4).

I've kind of bodged a quick work around, but it requires me placing it at every point in the game, and there are points that it breaks the flow of the game or seems out of place. Is there are relatively simple way of doing this with a special passage or something so that it happens as soon as the player loads the save rather than my current approach?

Comments

  • How are you releasing these episodes? As separate files which players load their saves into or simply more content within newer versions of the same file? It sound like the latter, but….

    How were you hoping to do the "previously" screens? Are you limiting the maximum number of states/moments?
  • How are you releasing these episodes? As separate files which players load their saves into or simply more content within newer versions of the same file? It sound like the latter, but….

    How were you hoping to do the "previously" screens? Are you limiting the maximum number of states/moments?
    I'm building on the same file, just adding more code and passages as I go along.

    The "previously" bit will actually just be a highlight of the storyline so far and not the user actions that aren't related to the storyline. So if, for instance, in the previous episode you had a storyline quest in the episode to destroy a pirate cartel that will be in the highlights, but the fact you traded 10 tonnes of materials that wasn't a quest won't be recorded (or at least not as a highlight). The text will be more or less static apart from a few quests that have different outcomes and then it's just a case of checking which of the outcomes happened.
  • The "previously" bit will actually just be a highlight of the storyline so far and not the user actions that aren't related to the storyline. […]
    That's not what I meant. How are you hoping to display the "previously" information? On it's own screen, at the top of the currently loaded passage, etc?

    Also, you didn't answer my final question. Are you limiting the maximum number of states/moments?
  • Ah sorry. I've misunderstood, what you meant by states/moments, hence the comments about what would be on the screen.

    It would be it's own screen (although 2 in certain cases as I have a couple of fun things in the pipeline).

    If by states and moments you mean whether there is any specific time it would trigger, I'd only need it once per episode, and it should be able to trigger anywhere they're on a base (I'm disabling saving during travel, fights and random encounters). There are only really going to be bases and travelling in the game (no real dungeons as such), so they'll be in a base when they reload anyway. If this isn't what you mean could you please explain? :)
  • edited August 2016
    If by states and moments you mean
    States and Moments in this context relate to Passage History (which passages the reader saw and the state of the variables in each of those passages) and the related Undo/Redo buttons.

    TME is basically asking if you have changed the Config.history.maxStates configuration setting or disabled the history Undo/Redo buttons. One reason he may be asking about this is because the Passage History is stored within a Save.
  • edited August 2016
    I solve this issue with something like this:

    <<click "Load Game">><<set $saveactivated>><<script>>UI.saves();<</script>><</click>>

    I can then use $saveactivated in PassageDone to do something conditional.

    Eg if I put this in PassageDone:
    <<if $saveactivated and $time is 4>><<script>>var $titles = $("#titles");
    TweenLite.to(titles, 0, {text:{value:"This is Day 4 and you have one new message at your private terminal", delimiter:" "}, ease:Linear.easeNone});
     <<set $saveactivated to false>><</if>>
    

    Then my GSAP text div will flash that message up whenever the player loads a save and the $time variable is also 4.


    The code is just quickly written though, and has a hole in that it doesn't have a way to respond to situations where the player closes the save ui without loading a game. You can address that in several ways though.



  • I'm currently developing a game for both Android and iOS in Spanish and releasing new chapters roughly every month (Google Play). I'm using the latest version of SugarCube and I must say it works great! I have even upgraded SugarCube once and the users's savegames stored on their mobiles still worked with the new version. The credit is all yours, @TheMadExile!

    My number of states/movements is set to:
    Config.history.maxStates = 0;
    
    and my "previously on" scene consists of a single passage where I basically check
    <<if visited("passage_name")>>…
    
    and then I do a
    <<timedremove>>
    
    and
    <<timedcontinue>>
    
    to show and then remove meaningful paragraphs from the previous chapters.

    If there's anything I can help with, I'm right here :smile:
  • bruno wrote: »
    I'm currently developing a game for both Android and iOS in Spanish and releasing new chapters roughly every month (Google Play).
    That looks pretty cool. Now you've made me wish I knew Spanish. :)

    bruno wrote: »
    My number of states/movements is set to:
    Config.history.maxStates = 0;
    
    That removes the limit on the number of states/moments that the history may hold, which I do not recommend as you will eventually run into problems because of the ever increasing size of the history. To put it another way, even if you keep your story variables under control, an unbounded history will very likely eventually become problematic in a long running game due to the sheer number of states.

    The default value is 100, which should be more than sufficient in most cases. If that's not enough for your tastes, I'd recommend simply setting it to a larger value, e.g. 200, rather than removing the limit altogether.

    Just a suggestion.

    bruno wrote: »
    I have even upgraded SugarCube once and the users's savegames stored on their mobiles still worked with the new version.
    I do not often make changes to the internals of the saves format, so breaking saves by upgrading to a newer version of SugarCube, within the same major version, shouldn't normally be a concern. That said, I have needed to do so on a few occasions. Whenever I have, however, I've tried to include automatic converters that upgrade old saves, so that players never notice that anything has changed.

    I try very, very hard not to break saves.
  • edited August 2016
    Okay, @AntonMuerte. I believe that I've come up with something which should do what you want in SugarCube 2.

    Place the following within your script section (Twine 1: script-tagged passage; Twine 2: Story JavaScript):
    /*
    	StoryRecap script (for SugarCube v2.7.2+).
    
    	Important Notes:
    	  1. To make this work, the saved history is truncated down to the moment
    	     which was current at the time that the player saved—i.e. if the history
    	     looks like [A, B, C] and the player navigates back to moment B and then
    	     saves, the save will contain a history which looks like [A, B].  This
    	     is required to allow the StoryRecap special passage to alter the
    	     story variables—which was one of your requirements.  That might
    	     sound scary, but in actuality it's fairly innocuous.
    	  2. The history controls are hidden on the StoryRecap special passage,
    	     since allowing the player to navigate the history from there would be
    	     weird.
    */
    (function () {
    	Config.saves.onSave = function (save) {
    		save.state.history.splice(save.state.index + 1);
    	};
    	Config.saves.onLoad = function (save) {
    		var current = save.state.history[save.state.index];
    		current.variables._recapTo = current.title;
    		current.title = 'StoryRecap';
    		jQuery('#ui-bar-history').hide();
    	};
    	window.continueFromRecap = function () {
    		var
    			recapTo = State.variables._recapTo,
    			current = State.index(State.activeIndex);
    		delete State.active.variables._recapTo;
    		State.active.title = recapTo;
    		current.title = recapTo;
    		current.variables = State.active.variables;
    		Engine.show();
    		jQuery('#ui-bar-history').show();
    	};
    })();
    
    EDIT: A small update to smooth any changes made during StoryRecap into the history better.

    Then create a special passage named StoryRecap and set it up like the following:
    /*
    	Your recap descriptions and story variable changes go here.  You may
    	treat this like a normal passage for the most part.
    
    	Warning: Do not provide a means of leaving this passage other than the
    	call to `continueFromRecap()` below.
    */
    
    <<click "Continue">>
    <<script>>continueFromRecap();<</script>>
    <</click>>
    
    You may change the text of the <<click>> or even replace it with a <<button>> or something else if you wished. The call to continueFromRecap() is the important part.
  • The default value is 100, which should be more than sufficient in most cases. If that's not enough for your tastes, I'd recommend simply setting it to a larger value, e.g. 200, rather than removing the limit altogether.

    Just a suggestion.

    Well, I shall implement your suggestion (I believe you know what you're talking about :smile:).
    I do not often make changes to the internals of the saves format, so breaking saves by upgrading to a newer version of SugarCube, within the same major version, shouldn't normally be a concern. That said, I have needed to do so on a few occasions. Whenever I have, however, I've tried to include automatic converters that upgrade old saves, so that players never notice that anything has changed.

    I try very, very hard not to break saves.

    From my experience, you're not only trying but succeeding. I've updated the game many times now and, aside from testing it myself, nobody has had any problems with loading their story and continue playing it. I can update the story's html regularly and as long as their save's stored on the application's folder everything works as it should. The only "problem" is that if they uninstall the app the save is lost.

    Once again, gracias (see? you know some Spanish), SugarCube is an amazing tool and I made sure to include your copyright notice in the game's credits.


  • Greyelf : I've learned something today :) . I need to write a crib sheet with all the terms lol.

    Claretta: I completely forgot about passagedone and I feel like a noob again lol.

    TME: Thank you ever so much. I actually understand what most of it does, even though I can't get my head around Javascript totally.

    Bruno: Hola. My bodge job did something similar, although it checked 3 variables as I needed various conditions to be met. BTW, although I'm English I more or less grew up in Spain as my family had a place in Benidorm. The moment school ended for half term or end of term I was straight over there. Happy days.

    Once again, to you all, thank you so much :)
  • Bruno: Hola. My bodge job did something similar, although it checked 3 variables as I needed various conditions to be met. BTW, although I'm English I more or less grew up in Spain as my family had a place in Benidorm. The moment school ended for half term or end of term I was straight over there. Happy days.

    Now I understand your username, a bit dark huh? :smiley: Benidorm sounds just like the place to be this time of year, I'm not enjoying the 30 something degrees we get daily here in Madrid. Anyway, nice to meet you! ¡Encantado!

Sign In or Register to comment.