This is an unusual question, but I’ll ask it anyway. For a published Hosted Game, is it possible to disable (or put extra warnings on) the restart button?
For my next game, I’m planning to have a ten-slot save system (up from three in Dragon of Steelthorne). Additionally, I plan to create a soft-restart function (which I’ll code manually) which allows the player to restart the game and begin a new character without losing their existing saves. This will essentially allow them to have ten save slots which can simultaneously store progress for multiple characters at different points in the story.
I’m planning to create ten sets of copies of every permanent variable to achieve this. However, I’m concerned that if someone hits the restart button by mistake, all ten save slots will be permanently wiped out in an instant. I’m wondering if we can put some kind of safety on the restart button to prevent this (or some kind of warning that it’ll wipe all save slots permanently).
On another note, I have two strong reasons for not wanting to use the new checkpoint feature (code inflation is not one of them) so I’m sticking to the manual system.
There’s a prompt to confirm the restart already so I’m not sure it’s necessary to have an additional one. There’s always putting a note at the start of the game to distinguish the soft restart from the button? Or you could use *save_game which I believe would keep the saves across playthroughs after restart?
Out of interest, what are the reasons not to use the checkpoints? (I assume them being non-persistent is one of them.)
That’s an interesting idea. Once you finish the game, you can export all the save files to the servers, and load them up again whenever you wish.
I might be mistaken on how the checkpoint system works, but for reasons:
I want players to be able to preview key variables (name, difficulty level, days passed) on the choice text in the save slot menu before actually loading a save.
Dashingdon compatibility is still very important to me, as I frequently test my games on my iPhone and use Dashingdon for that. Dashingdon also has a full save system without needing any logins.
Dashingdon uses an outdated version of CS currently. Moody.ink’s version is newer and I believe will be updated in the near future to the newest version.
Moody’s save system is also persistent and works cross-platform.
I honestly do not understand why people still use Dashingdon.
I developed something like this during the Honor Bound beta test. It’s a subroutine that gets called at the end of each chapter (though I could call it whenever I like).
I’ll share in case it’s of use to you or others reading. The *if (choice_saved_checkpoint_hb_save_1) etc on the save choices aren’t strictly needed - it could be done with multireplace - but in HB there are some slightly more complicated things going on that meant multireplace would be more fiddly.
Code below
*label checkpoints
*label checkpoints_choice
Do you wish to save or load your game?
[b]You can also load a saved game from the stats page at any time.[/b]
*choice
#Save the game.
Which slot would you like to save your game to?
*fake_choice
*if (not(choice_saved_checkpoint_hb_save_1)) #Save the game to Slot 1.
Save complete!
*set hb_save_1_chapter {hb_chapter}
*save_checkpoint hb_save_1
*if (choice_saved_checkpoint_hb_save_1) #Save the game to Slot 1 (replace save at the end of Chapter ${hb_save_1_chapter}).
Save complete!
*set hb_save_2_chapter {hb_chapter}
*save_checkpoint hb_save_1
*if (not(choice_saved_checkpoint_hb_save_2)) #Save the game to Slot 2.
Save complete!
*set hb_save_2_chapter {hb_chapter}
*save_checkpoint hb_save_2
*if (choice_saved_checkpoint_hb_save_2) #Save the game to Slot 2 (replace save at the end of Chapter ${hb_save_2_chapter}).
Save complete!
*set hb_save_2_chapter {hb_chapter}
*save_checkpoint hb_save_2
*if (not(choice_saved_checkpoint_hb_save_3)) #Save the game to Slot 3.
Save complete!
*set hb_save_3_chapter {hb_chapter}
*save_checkpoint hb_save_3
*if (choice_saved_checkpoint_hb_save_3) #Save the game to Slot 3 (replace save at the end of Chapter ${hb_save_3_chapter}).
Save complete!
*set hb_save_3_chapter {hb_chapter}
*save_checkpoint hb_save_3
*if (not(choice_saved_checkpoint_hb_save_4)) #Save the game to Slot 4.
Save complete!
*set hb_save_4_chapter {hb_chapter}
*save_checkpoint hb_save_4
*if (choice_saved_checkpoint_hb_save_4) #Save the game to Slot 4 (replace save at the end of Chapter ${hb_save_4_chapter}).
Save complete!
*set hb_save_4_chapter {hb_chapter}
*save_checkpoint hb_save_4
*if (not(choice_saved_checkpoint_hb_save_5)) #Save the game to Slot 5.
Save complete!
*set hb_save_5_chapter {hb_chapter}
*save_checkpoint hb_save_5
*if (choice_saved_checkpoint_hb_save_5) #Save the game to Slot 5 (replace save at the end of Chapter ${hb_save_5_chapter}).
Save complete!
*set hb_save_5_chapter {hb_chapter}
*save_checkpoint hb_save_5
#Go back.
*goto checkpoints_choice
*if choice_just_restored_checkpoint
Loading game…
*return
*goto checkpoints_choice
*if (not(choice_randomtest)) #Load a game.
Which game would you like to load?
*choice
*if (choice_saved_checkpoint_hb_save_1) #Load Slot 1 (end of Chapter ${hb_save_1_chapter}).
*restore_checkpoint hb_save_1
*if (choice_saved_checkpoint_hb_save_2) #Load Slot 2 (end of Chapter ${hb_save_2_chapter}).
*restore_checkpoint hb_save_2
*if (choice_saved_checkpoint_hb_save_3) #Load Slot 3 (end of Chapter ${hb_save_3_chapter}).
*restore_checkpoint hb_save_3
*if (choice_saved_checkpoint_hb_save_4) #Load Slot 4 (end of Chapter ${hb_save_4_chapter}).
*restore_checkpoint hb_save_4
*if (choice_saved_checkpoint_hb_save_5) #Load Slot 5 (end of Chapter ${hb_save_5_chapter}).
*restore_checkpoint hb_save_5
#Go back.
*goto checkpoints_choice
#Continue playing.
*return
I’m not using cogdemos for the moment, but probably will once the code is up to date. Currently I’m just using Dashingdon to link to Honor Bound on itch because of not having checkpoints available (a compiled game on itch can also use save-at-will ala Dashingdon with the ChoiceScript Saving Plugin).
For me, it’s because I know dashingdon and it’s always worked for me and I have a philosophy of ‘if it ain’t broke don’t fix it’. But mainly, it’s a thing of encouragement from seeing the amount of times people have clicked on my demo link. A bit of a vane reason probably, but seeing that number helps keep me striving to push forward and makes me feel like im accomplishing something.
Me too – and I’m also grateful for dashingdon. But it is broke, and getting broker all the time. I’d never put a new game up there now, or on moody, knowing that the sites aren’t going to be kept up. Moving to https://cogdemos.ink/ (which thanks to @EvilChani is actually being maintained) seems like the easiest shift for someone like me who doesn’t want to have to learn the compliing to itch.io route.
Moody (cogdemos) having persistent and cross-platform saves is a fairly strong reason for me to switch, and (I admit) is something I didn’t previously consider.
I’m planning to offer future WIPs on both when I’m ready to present the full beta for my current project.
If you’re using dashingdon right now and are happy with it, you may want to wait to move to cogdemos.ink (aka moody) until the code rewrite is done (it’s being rewritten in Laravel, from the ground up).
At the moment, I’ve got user management and game uploads/playing working. Next up is saves, which may prove to be more complicated.
Still, I had an estimate of 90 days to get it done, and am on target for that. Once it’s rewritten, I’m going to have to work a little behind the scenes magic to get the present db structure to work in the new db structure, which will be another fun project…
Just for the record, moody.ink redirects to cogdemos.ink now. Don transferred the moody domain to me, and I didn’t feel like redoing all my work and just forwarded the domain do cogdemos. Made my life somewhat easier.
You’re welcome. I’m hoping people will be happy with it once the rewrite is done. It will basically operate the same for authors and users, except we’ll be able to name saves (yay!). The number of saves available my be fixed for everyone, so you can either turn them on or off, without choosing how many you want. That’s mainly so the db doesn’t get bogged down with a billion saves.
My plan is to also set it up to allow for local saves (for users who don’t want to log in to play), but that is for after the rewrite is done and everything is working.
Another plan I have is to have several CSS templates available for authors to choose from and, possibly, allow the upload of CSS templates to share. It’s not necessary for functionality, but I figure some people may not like the “sameyness” of the games. Again, that will be for after the rewrite.
Yeah, I think that’s one point for Dashingdon’s favour, people asking why the wip doesn’t have saves (while it does, but they don’t know/like they’re supposed to log in for that).
Because it doesn’t require you to be logged in just so you can save and it also doesn’t quietly log you out after short period, which can easily catch you unable to save after slowly reading for a while.
Being able to backup your local save files is a plus, too. No matter how many save slots you get odds are you’ll eventually find the amount lacking.
It can be as simple as keeping a save from the start of each chapter so you don’t have to play from the start if some fairly recent decision turns out to be a mistake. Or in case the author of the WIP makes changes which force the game to roll back to start of the scene, which tends to cause things go sideways due to how this doesn’t roll back values of variables affected since.
Since most games have more than just few chapters you’ll either be forced to start rotating through the slots, or run out.
It never logs me out; maybe I have just been lucky in that regard, and honestly, this seems like something that is adjustable from @EvilChani 's end.
Hopefully, someone brought this up to her before this, or now that I tagged her in regarding this it can be addressed as well.
Interesting. I never had this issue, so it never dawned on me that people would “run out” of slots.
Perhaps it is just the different ways people test games for others.
This is one more argument to migrate to the latest CS version, so that in-game checkpoints will be there for this exact reason.
Version updates for works in progress break all saves, to my knowledge, if any variable does get changed in the new release. I am not sure how “making copies” of saves prevents them from breaking.
Unless you wish to keep outdated saves for a version of the game that is no longer current; which again, makes no sense to me.
Or it could be browser auto-clearing cookies for some reason (or IP address rerolling or whatever… I’ve seen that happen on a forum a couple of decades ago).
That’s only as long as the person wants to keep saves from the start of the chapter, but it was just an example. They might want to keep them based on in-game time for more sandbox-like IFs, or any other arbitrary criteria.
Also, does the in-game system store game state for each chapter or just the latest one completed? When i last had a look at it, it was the latter, and the former strikes me as a mess in the making i really wouldn’t want to touch, with each save effectively keeping a dozen or more save states instead of one that actually matters. It’s like an overengineered workaround for something that doesn’t need a workaround, just a basic working save system in the first place.
It’s more subtle than that. Changing content of the game script, be it something as simple as text or a conditional or anything else will affect the control checksum, and the game will roll back to start of saved scene when it notes discrepancy. The (layout of) variables may be unchanged and thus the saved state is still theoretically viable for use, but the stored values of variables will reflect the state from the point of save rather than from the start of the scene.
E.g. if MC had strength of 50 at the start of the chapter, got it increased to 70 and then that save gets rolled back to scene start, their strength will be 70 (and they can get another +20 replaying the content all way to where the save pointed in the story) So having a save from start of the scene --which is not necessarily the start of the chapter, mind you-- allows to avoid such change stacking. Without having to replay the game because the author fixed a couple of typos.
Until I manage to get the saves working for those who aren’t logged in, they can always use the CSGT plugin that adds a save system, along with a back button. On mobile, I think you have to use Firefox Nightly so you can add the plugin, but it works great.
At the moment, however, if you try to use that plugin while logged in and trying to save, it goes haywire.
First time I’ve heard of it, and have never experienced it myself. I will look into it, but like @LiliArch said, it could be the browser auto-cleaning cookies. I’ll see if I can find if there’s anything causing it on my end.
