If you reset the bank, you have to unlock all the scenes on a new file. Click the top of the 'd' on the title screen to restore all of the scenes.
There could be several explanations for this.
- Hitting the RESET button on the Spank Bank UI will clear the Spank Bank.
- The flags that "remember" which scenes you've unlocked are stored in Unity Options Data, the location and manner I imagine would differ depending on whether you're running on Windows or MAC. If that somehow got cleared out. It could be something like (and I'm just doing a thought experiment here) having the game installed for all users but then you ran the game on a different system login than the one you unlocked the scenes with--something like that maybe.
- There's always the possibility there could be a bug that clears the Spank Bank out. I haven't seen this, but I will check the logic involving the Spank Bank to see if there are any paths that could conceivably clear it by mistake.
I want to provide kind of an announcement/proclamation about version numbers.
TL;DR: The upcoming update will be versioned v0.2.0.
As you know, the current version number for the released "demo" is v1.0.0. In retrospect, it was an unfortunate error on my part. This is my first game and my first attempt at a game and I had always assumed that 1.0 meant "Released to the Public," which is what the demo was. It turns out the traditional understanding for 1.0 for most people is "Finished Software," which this game obviously is not and has never claimed to be. This, of course, introduced a problem where some players saw (and may see in the future) v1.0.0 and assume a finished game.
Up until recently, my view was to just continue on with the "goofy" version scheme and the next content update would be 1.1.0, which in my mind was better than the alternative of "correcting" and retreating to a 0.x.x numbering scheme, which would confuse a whole new group of people. However, I've heard some interesting and persuasive arguments for biting the bullet and contracting the version number back to something like v0.2 and just enduring the short term pain.
So, I am faced with a couple of bad options:
Let me know your thoughts one way or another.
TL;DR: The upcoming update will be versioned v0.2.0.
As you know, the current version number for the released "demo" is v1.0.0. In retrospect, it was an unfortunate error on my part. This is my first game and my first attempt at a game and I had always assumed that 1.0 meant "Released to the Public," which is what the demo was. It turns out the traditional understanding for 1.0 for most people is "Finished Software," which this game obviously is not and has never claimed to be. This, of course, introduced a problem where some players saw (and may see in the future) v1.0.0 and assume a finished game.
Up until recently, my view was to just continue on with the "goofy" version scheme and the next content update would be 1.1.0, which in my mind was better than the alternative of "correcting" and retreating to a 0.x.x numbering scheme, which would confuse a whole new group of people. However, I've heard some interesting and persuasive arguments for biting the bullet and contracting the version number back to something like v0.2 and just enduring the short term pain.
So, I am faced with a couple of bad options:
- Option 1: Do nothing and release the next update as v1.1.0, perpetuating and exacerbating the long-term problem of the perception of a finished game.
- Option 2: Bite the bullet and retreat to something like v0.2.0 for the update, correcting this misstep while the game is still in its early stages, while attempting to relegate v1.0.0 to a point of trivia, along the lines of "Did you know there was a Star Wars Holiday Special?" and "Whatever happened to Leisure Suit Larry 4?"
Let me know your thoughts one way or another.
- Jun 10, 2018
- 1,906
- 2,540
The version of the game doesn't matter to me, you can call it whatever you want, your the dev, it's your choice, i'm just a player that enjoyed it, and if i want to know, i can just read the changelog that's in the op.
The main thing that i look at, what's been added or fix for the game, not what version it is.
- Mar 5, 2018
- 9
- 11
Here's a status I posted from my SS (
You must be registered to see the links
) page (TL;DR the update isn't ready and will need the rest of the month to complete, and hopefully no more than that).
- Mar 5, 2018
- 9
- 11
- Jun 1, 2019
- 53
- 144
December Status
v0.2.0 Where Is It?
The current release candidate is still a bit too buggy for my liking. Also, as I'm playtesting, I often can't avoid the temptation to tweak lines of dialogue in an attempt to expunge as much "cringe" as possible.
I feel like the release is maybe about a week away still and I want the most bug-free version of the game put out as possible. Otherwise, I'll just be spending another two weeks doing hotfixes rather than working on 0.3.0.
As you probably know, this is my first game and this will be my first update to a game and working on a semi-schedule is a new experience for me.
Bugs?
I still have a list of bugs to go through and then test. Most of them are no-brainers, but I did find a nasty one that could be a problem in multiple scripts. Basically, if using Adventure Creator with custom C# scripts, any state/variable that is stored only in that script and not in an Adventure Creator variable will not get saved into save game files created by Adventure Creator, which means they won't get restored when loading.
In addition to the bug I found (related to the multi-day process of letting the war dialer run on MC's computer), I have identified other places where this type of bug exists. Two of which are currently in the demo that you all have:
1) If you go to any outdoor screen and save the game and then keep restoring it, the state of whether it's raining or not isn't saved and will be seemingly on or off at random. Obviously, this is a very low-impact bug and isn't something I would bother hotfixing for.
2) More seriously, Brooke, Meredith, and Lucy all have schedule managers that calculate where they are supposed to be depending on the time of day and day of week. This normally works great, but if you start a game, use the options menu to return to the main screen and then start another game, all of those schedules will get locked into a state where you will never be able to find Brooke or Meredith in any of the places they are supposed to be. Obviously, this is a very serious bug and I've already fixed it for v0.2.0. It's interesting that nobody ever (hopefully) found and reported this bug to me.
v0.2.0 Where Is It?
The current release candidate is still a bit too buggy for my liking. Also, as I'm playtesting, I often can't avoid the temptation to tweak lines of dialogue in an attempt to expunge as much "cringe" as possible.
I feel like the release is maybe about a week away still and I want the most bug-free version of the game put out as possible. Otherwise, I'll just be spending another two weeks doing hotfixes rather than working on 0.3.0.
As you probably know, this is my first game and this will be my first update to a game and working on a semi-schedule is a new experience for me.
Bugs?
I still have a list of bugs to go through and then test. Most of them are no-brainers, but I did find a nasty one that could be a problem in multiple scripts. Basically, if using Adventure Creator with custom C# scripts, any state/variable that is stored only in that script and not in an Adventure Creator variable will not get saved into save game files created by Adventure Creator, which means they won't get restored when loading.
In addition to the bug I found (related to the multi-day process of letting the war dialer run on MC's computer), I have identified other places where this type of bug exists. Two of which are currently in the demo that you all have:
1) If you go to any outdoor screen and save the game and then keep restoring it, the state of whether it's raining or not isn't saved and will be seemingly on or off at random. Obviously, this is a very low-impact bug and isn't something I would bother hotfixing for.
2) More seriously, Brooke, Meredith, and Lucy all have schedule managers that calculate where they are supposed to be depending on the time of day and day of week. This normally works great, but if you start a game, use the options menu to return to the main screen and then start another game, all of those schedules will get locked into a state where you will never be able to find Brooke or Meredith in any of the places they are supposed to be. Obviously, this is a very serious bug and I've already fixed it for v0.2.0. It's interesting that nobody ever (hopefully) found and reported this bug to me.