Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serialization for C# Games

chickensoft.games

Post reply on HN
Print view View original

31–40 of 51 posts

Re: Serialization for C# Games

#31

Post by whoknowsidont »

smartis2812 wrote: post #27
flohofwoe wrote: post #23

If I learned one important lesson from writing savegame systems: don't directly serialize your entire game state on the "game object level" (e.g. don't create a savegame by running a serializer over your game object soup), instead decouple the saved data from your game logic internals, have a clear boundary between your game logic and the savegame-system, keep the saved state as minimal as possible, and reconstruct o…

[flagged]

Please don't put comments like this in threads. There is a button for it.

Re: Serialization for C# Games

#33

Post by superfist »

isthiseasymode wrote: post #7

Naive question: is there a reason why SQLite wouldn’t work for something like this?

Because that would require additinal step: object graph conversion to relational database representation when saving and reverse process when loading. It is simpler to save graph right away.

Re: Serialization for C# Games

#36

Post by voxic11 »

flohofwoe wrote: post #23

If I learned one important lesson from writing savegame systems: don't directly serialize your entire game state on the "game object level" (e.g. don't create a savegame by running a serializer over your game object soup), instead decouple the saved data from your game logic internals, have a clear boundary between your game logic and the savegame-system, keep the saved state as minimal as possible, and reconstruct o…

If your game engine is built on a data-first architecture like ECS then it can be pretty trivial to directly serialize your game state. I have had good luck with this using bitECS https://github.com/NateTheGreatt/bitECS/blob/master/docs/INT...

Re: Serialization for C# Games

#37

Post by flohofwoe »

voxic11 wrote: post #36
flohofwoe wrote: post #23

If I learned one important lesson from writing savegame systems: don't directly serialize your entire game state on the "game object level" (e.g. don't create a savegame by running a serializer over your game object soup), instead decouple the saved data from your game logic internals, have a clear boundary between your game logic and the savegame-system, keep the saved state as minimal as possible, and reconstruct o…

If your game engine is built on a data-first architecture like ECS then it can be pretty trivial to directly serialize your game state. I have had good luck with this using bitECS https://github.com/NateTheGreatt/bitECS/blob/master/docs/INT...

Agreed, when the data is already in a table format (instead of an "object spider web") the idea to automate serialization makes more sense, it essentially becomes a "database problem". I would still very carefully consider what data columns need to be persisted and which should be reconstructed, and I wouldn't try to come up with a too generic solution.

For instance in some games it might not be necessary to save a reference to a targeted object, if the gameplay targeting mechanism picks up a target in the first frame after loading a savegame anyway (etc etc...). Whether that target is exactly the same as at the time of creating the savegame might not be relevant (but very relevant for other games).

I guess the TL;DR is: in many cases it might be much easier to come up with a specialized per-game savegame system instead of coming up with a generic savegame system that works for all types of games.

Re: Serialization for C# Games

#38

Post by jayd16 »

wheybags wrote: post #29

In my experience, the pain of dealing with changes outweighs the pain of dealing with boilerplate, so it's better to explicitly write out save and load functions manually than rely on reflection. Also means you can do stuff like if(version<x) { load old thing + migrate} else {load new thing} very easily. And it's just code, not magic.

Something like DB schema upgrading would be good but if you have versions you should be able to do that just fine. Reflection and changes are not at odds.

Re: Serialization for C# Games

#39

Post by jayd16 »

isthiseasymode wrote: post #7

Naive question: is there a reason why SQLite wouldn’t work for something like this?

When N=1 normalizing and denormalizing the data would be slower and more cumbersome than just reading and writing the whole blob.

You could use DB schema upgrade tooling to accomplish some of what's done by this library but now you're at SQLite+. If you have a tool you already like then that's perfectly ok.

Re: Serialization for C# Games

#40

Post by freedomben »

bob1029 wrote: post #30
jameshart wrote: post #10

Earlier quoted context omitted.

Well you still need to solve for what happens when a new version of your app (maybe with a new embedded version of SQLite) loads up an old data file saved by an old version of your app. The old version might not contain all the tables you need, and the ones it has may not have the columns you expect. So you need to run some data migrations on the database. Now you no longer have a serialization problem but instead yo…

https://www.sqlite.org/pragma.html#pragma_user_version I use SQLite for game state management. It's just like any other database scenario. I write migrators that check the user_version of the database. It's just a for loop from user_version to current version. The migrators themselves can be arbitrary methods that sometimes modify game state to bring it up to date. The most common scenario is adding a new property to…

I do the same thing, but I have increasingly found myself wanting to serialize json into columns because having a rigid schema can sometimes add a lot of friction. Experience has taught me though, that it's worth the extra effort to define a schema, because nine times out of 10, the flexible json will ossify into unexpected format that the code relies on anyway, but now the database doesn't help enforce integrity. I would definitely recommend defining a schema and doing it right the first time. It will save you time in the long run, and make for much fewer bugs.
Post reply on HN