Sorry for the "reply spam" but I have narrowed down the cause of the error! It is related to map size, I had no issue saving and loading a default 32x30 map and somehow when I generated the 64x60 map it saved "fine" but when I tried to load it I got a NullReference error. So it seems to be related to the saving and loading system not being geared for maps larger than default
Viewing post in Version 8: Return to War comments
Excellent work tracking down the repeatability. Sadly, this implies it's an issue we struggled with for over a month, before literally rolling back the entire project to a version of Unity from 2015. It's probably a problem in Unity itself, we were unable to get any form of useful error message, and the crash happens at random parts of the saving process (implying there's a second thread, made by Unity, which either times out or crashes).
The best we're likely to do is to try to compress the save files down a bit before they're passed to the save/load function, and decompress them at the other side. There are some easy ways to do this, and some hard, so we'll see how many we can get done for the next version.
Regarding the private data in the output file, that's just yet more annoying Unity stuff. In general, I think Unity's a decent enough engine, and the game wouldn't be possible without using a third-party engine like this, but some of the decisions the devs made are perplexing to me. My name is in the credits and the github repo, so I'm not too concerned, it's just irritating and odd.
Thanks for your work tracking down the issue, sorry that I can't promise a full fix. We'll look into what can be improved.
Hey its alright, I have encountered similar issues with a proprietary game engine just not being nice about savedata handling or dealing with large multidimensional arrays, though unity really should be able to handle all that data, is it all stored in map tile objects or something like that? That might be it, try storing the map separately from agents and nobles and stuff, like maybe its expecting to write a block of data each iteration of the writing loop that is much less complex, IDK. I know of unity games that supposedly handle equal, if not larger and denser amounts of data.
If all fails, then I can recommend Godot, much better licensing(you don't have to pay a single dime no matter how much you make, you can release your games and software with any license you want, you fully own the product of your own design and labor), skills carry over just fine from Unitys SDK to Godots SDK. You got full access to source engine code, too. Engine is written in C++ and it supports both C# and their own (very trivial to learn) python or JS like language for scripting, and the community is really, really helpful and supportive.
Regardless, I wish you the best of luck in making this game, I love playing it!
Okay. It is fixed.
The issue was the third-party open source library we were using to save/load was based entirely on a recursive algorithm. Once the number of people grew too large, it kept just going through their social relationships, calling the recursive function each time it encountered a new person. As such, the thing hit a stack overflow due to having, for every person, called a new recurrence of the function.
Technically it worked, it just scaled so badly that once people hit a certain threshold Unity died.
I've reworked how people refer to one another. The new implementation is technically ugly, and goes against accepted best practices, but it at least works.
At least, I hope. New bugfix version is available for download.
Saving and loading 64x60 map is flawless, testing autosave now, when I have finished testing on this save I will stress/chaos test it by trying double, quadruple, octuple, etc. sizes of maps and if you want I can try and hexedit a test save to be some insane dimensions, with either cloned or random data. :) I really enjoy helping you out here. Will report back if there are any further bugs, crashes or oddities!
We've got no current bugs which need tracking down, thanks. The TODO file has a few things, but they're mostly just missing features and gameplay adjustments.
Of course, since it's open source, if you really want to see how it works you could even recompile from source (as long as you can find a version of Unity old enough). The code base is somewhat organised, but has had to compromise in a few areas. Certainly not my best code, but sadly not my worst.
Thanks again for the help, though. Glad to have save/loading actually stable and functional for all known configurations. One problem taken care of for the immediate future, leaving more time to implement vampires and zombies.
Gotcha! I'll keep playing the game, might actually buy the game soon, it being "name your own price" priced after all, I'll probably pay an equivalent of a few packs of cigarettes or a bag of coffee beans, a box of energy drinks, whichever "programmer stimulant" you favor :) Good luck with the development!