DCoward
|
|
« Reply #20 on: July 18, 2016, 03:16:44 AM » |
|
Wait, why would I convert to JSON if I am trying to serialize to XML?
The XML Serialization script is one I got from a Udemy course, and AFAIK all of the code is correct, but I don't know if I am using it correctly for what I need.
I mean in the simplest of terms, all I want to do is save information that is inherited from other classes, and not simple stuff like ints and floats. I want to save classes that HAVE this information, but I don't know how to do that.
That's what this is all about for me. I need to save things like which Type a character is, since that decides a player's stats. I need to save the Job they are and persist it so they'll be able to use specific weapons.
I mean to be honest I'm a little amazed I haven't been able to find this information since it seems like a VERY necessary requirement for any game that is supposed to persist beyond a single play session. I might just not be looking where I need to so I can learn the code in order to do this, but I've definitely been trying.
/Shrug
TL;DR: I don't know what exactly I'm not doing correctly, and I've definitely been trying things, but I'm lost and all I'm trying to do is save player data (currently trying XML) :/
|
|
|
Logged
|
|
|
|
oahda
|
|
« Reply #21 on: July 18, 2016, 03:42:23 AM » |
|
Oh, I had no idea XML was involved. There's no mention of XML anywhere in your gist thingy.
Not sure why you think JSON couldn't save these things if XML can; they're both basically the same thing with a different syntax.
But yeah, if the serialisation thingy you've got doesn't seem to be working I would at least try the JSON thing instead. Do you have to use the Udemy thing?
Anyway, what I think you should do, is make a separate test project, and try to serialise something very simple first and if not even that works you can try to figure it out, and if it does, you can perhaps keep adding complexity to bring it closer to your game's use case and see if it starts failing somewhere...
|
|
|
Logged
|
|
|
|
DCoward
|
|
« Reply #22 on: July 18, 2016, 04:03:54 AM » |
|
Oh, I had no idea XML was involved. There's no mention of XML anywhere in your gist thingy.
Not sure why you think JSON couldn't save these things if XML can; they're both basically the same thing with a different syntax.
But yeah, if the serialisation thingy you've got doesn't seem to be working I would at least try the JSON thing instead. Do you have to use the Udemy thing?
Anyway, what I think you should do, is make a separate test project, and try to serialise something very simple first and if not even that works you can try to figure it out, and if it does, you can perhaps keep adding complexity to bring it closer to your game's use case and see if it starts failing somewhere...
In the most recent update I gave (here is a repost: https://gist.github.com/alucard55/91e78c0488e84ccafa5aa183857d1686 ), I have an XML Serialization file. And no, I mean it's not like I have to, I just don't understand why I would. By all means, if there's a reason I should, I'll do it. I jsut wanna know. And really it's pretty much what I explained where I started to have problems (in response to making a test project and working up, because I did do that -- that's why I went here to ask for help). When I try to pull information that is not a float, int, or string, I start getting not what I want. Stuff like me not wanting just a blank profile of a character (as in all the stats are zero, text fields null, etc) but not knowing how to go about changing that. I mean I'm the first to admit I am new and unknowledgable, but I just don't know where to go to read up more about this stuff, since what I need is more specific than most people are going to teach, and I'm not skilled enough to know what to search to fill those gaps yet.
|
|
|
Logged
|
|
|
|
oahda
|
|
« Reply #23 on: July 18, 2016, 04:41:33 AM » |
|
Sorry, I guess I've been bad at following along throughout the entire thread. I haven't used the things you are using, so I really can't help you there then, I'm afraid. All I can say is that I've successfully converted somewhat complex objects with nested structs and stuff to and from JSON, so if you absolutely cannot get it working with your current method, you can try that at least. :c
|
|
|
Logged
|
|
|
|
darkhog
|
|
« Reply #24 on: July 19, 2016, 11:44:57 AM » |
|
Maybe it's because I'm superstitious, soon-to-be 26 year old, old fart, but from my experience using serialization to make a save system for anything important (like player progress, but not e.g. options/settings) is a bad idea. Why? Because one change to the class that is being serialized means "old" saves no longer work because it can't deserialize properly. And "change" can be anything simple, even changing variable name during refactorization. That's why in my game I've made custom binary format (or formats, since I'm saving player progress and levels like this), based on BinaryWriter/BinaryReader classes and file streams so I can have full control over the file format and break it only when it's absolutely necessary. //edit: In case you're wondering how I'm doing this, each class that is supposed to be written to/loaded from file has Read and Write functions that accept a reference to BinaryReader/BinaryWriter. Example (actual code from my game): public static void Write(BinaryWriter bw, LevelHeader lh) { if ((lh.checkString == null) || (lh.LevelAuthor == null) || (lh.LevelName == null) || (lh.LevelDescription == null) || (lh.forVersion == null)) { initLevelHeader(lh); } bw.Write(lh.LevelName); bw.Write(lh.LevelAuthor); bw.Write(lh.LevelDescription); bw.Write(lh.ParInSeconds); bw.Write(lh.checkString); bw.Write(lh.forVersion); } Then there's a master loader/writer that sets up streams and binarywriters/loaders and then run them in appropriate order: public static void SaveLevel(string filename, LevelHeader lh, LevelGoal lg, LevelObject[] objects, List<DialogList> dialogListList) { FileStream fs = File.Create(filename); BinaryWriter bw = new BinaryWriter(fs); LevelHeaderData.Write(bw,lh); LevelGoalData.Write(bw,lg); foreach(LevelObject lo in objects){ LevelObjectData.Write(bw,lo); } bw.Write(Globals.LEVELBLOCKEND); DialogueListWriterLoader.WriteDialogueList(dialogListList,bw); bw.Close(); fs.Close(); }
|
|
« Last Edit: July 19, 2016, 11:52:34 AM by darkhog »
|
Logged
|
Be a computer virus!I cannot C well, so I stick with simpler languages. There are no impossible things, there is only lack of skill.
|
|
|
Taugeshtu
|
|
« Reply #25 on: July 21, 2016, 05:57:14 AM » |
|
Just to contribute a little - every time I need something saved in file I use protobuf-net. It's really easy to use, supports lists, dictionaries and all your basic data types. Just decouple your data-containing classes from your logic-driving classes (and preferably from visualizing classes as well) and then it's super-easy.
|
|
|
Logged
|
We LOVE you. We MADE you.
|
|
|
Kylotan
|
|
« Reply #26 on: July 27, 2016, 06:46:12 AM » |
|
It sounds like you got a bit confused because serialization means several different things depending on the context: a) The method Unity uses to implement prefabs, object duplication, saving scenes and data edited in the engine; b) A generic term for taking in-memory data and writing it out as a long line of bytes so that it can be read in and reconstructed later. Obviously these are different aspects of the same thing - both taking stuff and putting it on disk - but "Unity Serialization" is talking specifically about being able to expose parts of your objects to the editor interface and remembering those values when you save a scene or a prefab. Can you repurpose or re-use Unity serialisation for your save-game functionality? Probably. Should you? Almost certainly not. Values that you expose in the engine are saved within your scene and prefabs, so they don't need to be saved out for a savegame file. It's hard to work out exactly what your approach is since I don't know what your code means by 'paradigm' or 'prototype' (though I expect one or both refer to what this link calls a Type Object). But in your situation it almost sounds like you just want to write out (a) which type it is (as a string, or integer, whatever), (b) which job it is (same), and (c) any transient values (current health, etc). And when you load them in again, you use the values read in from disk to find out which type or job to hook up to. You wouldn't need to load the whole type or job because they're already present in the system, either hard-coded or edited in the Unity editor on an invisible gameobject.
|
|
|
Logged
|
|
|
|
goa
Level 0
|
|
« Reply #27 on: July 30, 2016, 03:44:19 AM » |
|
I would triple-underline and emphasize what Kylotan says: Unity Serialization is NOTHING TO DO WITH saving and loading files or levelsIt is a core part of the engine, and is an internal service that is used extensively to implement many (nearly all, in fact!) of the Editor's functions and features. It is a poor design, deeply flawed, but it was good-enough back in 2004 (or whenever Unity's 3 man team originally wrote it). It is not good enough any more, but Unity is now a huge engine and replacing something so core is (apparently, according to the unity staff that have tried it) an enormously difficult process. So ... not only you SHOULD NOT be using Serialization for saving/loading, but if you choose to: you're using a known weak, slow, buggy, serialiazation system. It is NOT designed for saving/loading levels - and it is optimized very poorly for this. JSON serialization is what most people tend to use at the moment because its fast and easy to debug. When you get onto a huge game, you'll switch to a binary de/serializer - but not Unity's. An off-the-shelf C# one that runs much better
|
|
|
Logged
|
|
|
|
darkhog
|
|
« Reply #28 on: September 03, 2016, 04:00:37 PM » |
|
Again, I'd reiterate what I'm doing for my own game: I've wrote my own save/load system that implements custom file format using standard C# file streams and BinaryWriter/BinaryLoader. It's really easy and since you have very fine control over how it saves, it will only break if you do either something stupid or you need it to break (e.g. when you can't extend save format "as is" anymore - for me it's a non-issue since I've designed my format to use chunk system, each chunk having its separate writer/loader so if needed I can add "patch chunks" with new data while maintaining backward/forward compatibility, but it may be an issue for more rigid format).
|
|
|
Logged
|
Be a computer virus!I cannot C well, so I stick with simpler languages. There are no impossible things, there is only lack of skill.
|
|
|
Kylotan
|
|
« Reply #29 on: September 08, 2016, 05:20:10 AM » |
|
Personally I'd just write save data in JSON. It handles new or removed fields gracefully, is easy to parse (with plenty of existing libraries), compresses well, and is human-readable (which is useful during development).
|
|
|
Logged
|
|
|
|
cow_trix
|
|
« Reply #30 on: September 27, 2016, 08:58:05 PM » |
|
We've been using Paradox Notion's FullSerializer architecture. Can't recommend it enough, it's solved all our complex serialization troubles. We can now serialize pretty much anything. For instance, it's now trivial to serialize a list of interfaces, where the interfaces are UnityEngine.Objects and contain other object references. It all just works - I can never go back!
|
|
|
Logged
|
|
|
|
|