View Single Post

Default 

May 2nd, 2013, 19:00
Originally Posted by GhanBuriGhan View Post
Why "save anywhere" would be a problem seems harder to understand for me but I'm not a programmer.
Since unity was created with intended applications beyond games, it doesn't have a suitable built in save-game function that can be called with a few simple commands. So unlike things like gamebryo or other game engines, implementing a save anywhere feature isn't as simple as calling an extensible function which automatically saves or loads relevent game-state information.

The way you'd want to do it in a unity 3d game like shadowrun would be to serialize your classes (not rpg classes - think of this as all the variables that describe the game state) and write them to a file. The problem with this is that it would create save games which would be inherently incompatible if patches made changes to the classes/variables being loaded. You can reduce the likelyhood of encountering this issue as well as load time by writing a save script which specifies sets of relevent classes but this would still be broken whenever any of those were changed in revisions of the game. That solution would also mean some classes would revert to default values (to be initialized by your load-game script) each time you reloaded which limits how many things you'd want to actually exclude.

The other option is to write an intelligent parser which effectively converts previous version saves to be compatible the first time they are loaded with a new revision. That would have to be updated for each rivision which broke save games but for which you wanted to allow save game compatibility. This might be viable for release versions and even late betas, but would be prohibitive during earlier phases where things are changing significantly and often.

From what little I do understand, a memory snapshot would be no less problematic in terms of compatibility and trouble-shooting and merely mean larger save files and loading times.

Basically the way Unity3d is, what I'm saying is that instituting a save anywhere system as opposed to a checkpoint system does add a significant amount of work to the development process and introduces a good deal of added complications to the testing process.

Depending on how scripting is handled in the editor/executed in the game it might not be entirely unworkable for someone writing a custom campaign to implement a save anywhere function within their campaign though I'd suspect they might want to use a checkpoint save system until they have a near-final version. Even then it would probably take some fiddling beyond just serializing and writing all classes to a file - which would not be assumed to be able to be read by the game's own load-game function.

What you might be able to do though, or at least try, is creating a custom inventory item that brought up a dialogue menu when used. Options within that menu could then call the custom save and load functions you would have written. I imagine though that you might need to run the game in administrator mode to ensure these non-standard save files would persist. This would also depend on whether the scripting used in the editor and edited in the game is javascript (or C # or boo) or whether they're using their own simplified scripting language. The former could allow for modders to do things like this possibly while the latter would be more far more limited and would likely require a script extender to add required functionality. Presuming the functionality was there (or could be added by a script extender) saving the game would probably be the easier part compared to loading the game if you couldn't create saves the load-game function it ships with recognized. Not sure how viable creating a workable load-game function that could execute within an active game would be.
Last edited by jhwisner; May 2nd, 2013 at 19:33.
jhwisner is offline

jhwisner

SasqWatch

#17

Join Date: Nov 2006
Posts: 1,549