Tricky, easy? Let me know.
I had not a single clue about the challenge but that’s par for the course in this Save/Load section!
That out of the way, is this type of save system is used in real games? My expectation is that if I hit Save in scene 1, run to Scene 2 and hit Load, I’d expect to be thrown back to Scene 1.
I haven’t come across a linearly progressing game where I want to have load points dependent on the level I’m in at the time of saving but maybe this is standard in games like Diablo and I’m just ignorant! I’ll admit I haven’t played a great deal of RPGs.
At the end of the section we get to loading the last scene. These are just the building blocks.
1 Like
Thanks, Sam! Good to know, I thought I was missing something that was common in RPGs.
This lesson was a bit tough, but it was a good exercise in figuring out how to design around a problem with an end-goal in mind. I feel like this implementation may be hard to reuse in other projects, though? Like,my brain didn’t want to wrap around that ‘CaptureState’ was updating existing data, and that saving relies on loading. But, the way it’s being done now works and makes sense for the project, but it feels kinda weird to me.
Is it standard practice (in either game development or just general coding) to load binary data, decrypt it, save/append to it, re-encrypt it and then resave it in this way?
I caught a bug where ActionSchduler was trying to cancel the current action when there WAS no current action (pressing play and then immediately loading) so I fixed that easily enough).
Yes, with the exception that the industry is running away from binary save files in favor of text formats like Json and XML. Of course, you can still encrypt those, like my Json saving system which will encrypt the Json and encode it in an unreadable text file.
Good to know, thank you!