alexanderberry
commented
6 years ago Alright, there are a couple ways we can go about implementing data storage with LibGDX. These vary in difficulty and efficiency, so I'll leave it up to a full vote of the group tomorrow to decide them.
- Use the LibGDX JSON class to serialize our model classes, and dump the file on internal storage. Implementation would include helper classes and whatnot.
Pros: Very easy, very quick. Just shoot the file across the server and we're done.
Cons: Inefficient, lazy, and occupies a lot of avoidable processing power.
- Use Kryo to serialize our game state and other things to be stuck in the database's POJOs/POKOs automatically and synchronize over the network.
Pros: Easy, efficient, supports deep/shallow copying/cloning for object to object field transfers, works with databases pretty seamlessly.
Cons: Needs reconstruction of objects that cannot be serialized like TextureRegions and Textures, necessitating a handler class and AssetManager preloading.
- (Basically 2a) Use Kryo with Kryonet to handle server transfers.
Pros: Remote Method Invocation, which allows for methods on sent objects to be invoked remotely. Auto-serialization of objects, seamless integration without any fiddling with Kotlin/JS.
Cons: Would require yet another backend overhaul and I don't know if Chi can take that this late in the project. Also RMI has some overhead, so it might not be the best.
kyroschow
If the model classes are located in core, then how would we do the Room database instead? The major problem is about the annotations on the instance variables.