In my Last Dream project, I am experimenting something (probably) new with story and endings.
Instead of “ending” the story when the MC dies, I make them “start again” with (almost) no memories of what previously happened.
I call this the “looping story” mechanics, and IMHO; it is a bold choice because instead of resetting everything, the system keeps track of your stats.
I would love to feature these mechanics in the game because it would accurately simulate the philosophical concept of Samsara, which is very important in Buddhism, whose philosophy has a vital role in the game.
What do you think of this story approach?
Is it “dangerous”?
Do you know any other CoG of HG that features it? I would love to draw inspiration from the veterans.
I’m not sure if it’s possible to do something like this in CSscript
How do you plan to implement it? With checkpoints?
Player will only have to hit restart to break that loop. The stats might also balloon out of control if you keep restarting the game through a checkpoint while also recording the stats every time.
I haven’t played your game yet (I think I will later today!), but something similar I can think of is in Paradox Factor. The MC is a time-traveller and there’s a lot of looping so that they remember things from the future. I think the entire game uses only one scene file.
New Game Plus+ is a great trope. Its nice to see more games with this mechanic. Please add easter eggs that change at each iteration to make it more cool! Like the feeling you are not looping totally alone? Dunno…
I have a concept for a game that would be “Ocean’s Eleven” meet “The Edge of Tomorrow” but in a fantasy setting and inspired by the Blades in the Dark ttrpg. So whenever the character died they would restart from a previous checkpoint but keep the memory of what had happened.
This is also partially the reason why I created Softly. I think this is a great idea!
It’s not dangerous, but it could prove to be very difficult.
Hear me out here. So what you’re basically talking about building is multiple separate and different but still linked games. Each game carries over stats into the next. With each successive game you’d have to have some way to “contain” the spreading of stats and to account for an increasing number of potential variables so that the following game doesn’t break or cause issues with inconsistent storylines. If you allow the stats and variables to separate/multiple too much between games, the complexity of stat tracking and length of different options you need to write is going to go up.
Compare that to something like paradox factor which is fairly short and has more of a groundhog day/butterfly effect approach where you’re playing through choices within the same basic story premise over and over and seeing the variation it causes. It still requires careful stat management, but it’s within the same game and short in length, which makes it a bit more easy to handle compared to what you’re suggesting.
You’ve already written a HG so I know you’ll have some idea of what I’m talking about here. It sounds interesting but could easily become too complicated to deal with unless tightly managed through it’s production IMO.
Edit- I think I might have misunderstood and thought you were going for restarts as different characters or eras, but instead it is the same storyline starting over? That would make it more do-able, but is still likely to be more complicated that a standard resettable storyline if a long game depending on how much influence you’re going to cause the previous runs to have. I’m also not sure how you’ll account for someone doing many playthroughs and still make the game satifying to play unless you’re working towards a winnable endstate rather than a normal endgame branching? (You could have a plan here! Just be aware that in polls many people are only playing most games 1-2 times so make sure the extra work you’re putting into this is going to make it worth the effort so will need a way to keep drawing players in for another run through.)
I was once working with the problem of persistence of temp variables in a gosub_scene command when I decided to adopt a pseudo structured approach.
Everytime the scene was called a setter subroutine would “create” all the temps variables my class of set would use.
Them my code would check if any er, “regular expression” (a fancy name for an encripted password I developed) to update the standard values of the variables before run the rest of the scene.
In other words. You can generate a “password” for the player use in case he wants to play a New Game Plus game were in it is stored a compression of all the data the game may need to generate a custom version of itself.
Its very complicated to implement, but also makes easier to make alterations as the chunk with the data altering code can be worked separated from the rest of the scenes.