Self-maintaining Savable: For when you're feeling lazy

Hello everyone,
I hope this category is the correct one to post this in.
Essentially, I am currently getting familiar with jME mostly through the docs + trial & error.
Being a C# developer by trait means my code below might be unconventional to trained Java engineers. However, I’m giving it my best to stay true to Java ‘best practices’. (enqueue discussion on what ‘best practices’ are - in any language)

To the snippet:

What’s this about?
I just finished reading up on how to add custom data to Spatials. Savables came up as a good way to implement them, as I can more easily access custom data by grabbing a single Savable instance from the Spatial, instead of calling getUserData & setUserData for every field access.
Besides, it also seemed a chore for someone as lazy as myself to keep track of the read & write overrides whenever I change, add or remove a field.
Remembering that Java is also a reflective language I set out to automate the process of both read & write methods.
I’ve decided to call them Containers in my personal project, as for the reason why they are called such.

Currently only considering public fields, planning on expanding this so you can toggle getter-setter access, too.
Also noteworthy: This was tested with a couple of different member-types. However, not everything was tested, and I’ve also made ArrayList, Map and IntMap members cause a NotImplementedException to be thrown, as I was unable to figure out how to read and write such members - at least I could not find appropriately named methods. Maybe someone can help me out with that?

Anyway, I hope this little lazy-developer-satisfying code can help someone out. At least it did the trick for me.

7 Likes

Welcome to the forums!

I am quite new so the code is a bit above my head but thank you for posting and I look forward to messing around with it. Hope you are having fun with whatever you’re working on :melting_face:

2 Likes

writeSavableArrayList & writeSavableMap. Of course there is the savable part. But a generic ArrayList (such as ArrayList<Int>) can be converted to an array and saved using just write. Then just applying some magic on the reading part.

sorry cant help, since i do not use Savable.

But let me ask, dont you want try use ECS?(its not oop, but helps organize game logic, and you can use simple serialization there)

Please note that while adding data to Spatials have its use case, it is generally NOT reccommended to use it for game logic. Trust me (hence the suggestion of @oxplay2 )…

Oh no worries, the AbstractContainer is just what it says: A (dumb) container without any logic. For instance, I would have a BuildingContainer, which would contain common attributes for buildings. Poor example, since this is not an attribute exclusive to buildings usually, but health would be one.
Logic, as in behaviour, is still encapsulated within Controls.

I’ve read about them but couldn’t find a suitable read method.
But,

This sounds like a solution to the problem.

Generally speaking I’m not disregarding ECS. However, I wanted to start with plain jME and its solutions to common problems first.
/edit:
Well, and I guess my inexperience as a game developer as a whole plays a huge role in my decision to start with jMEs solution. Stretched out the feelers, so to speak. Experience in general software development helps immensively so far, but it still is a different horse.

Well, ofc it is possible without ECS, but even on Wiki there are ZAY-ES / ECS pages for people to understand that they should use some ECS(for medium/bigger games). Please note JME is very modular, but its up to you what you will use.

No-ECS games i would suggest only for a very small and simple games.

1 Like