Managing instances of custom types

[bitbrain]

The problem

PandoraEntity is stored inside res://data.pandora, meaning that it usually ships with the game and is read-only. One could make changes to loaded entities while the game is running but there is really no way of saving these changes. Also, next time the entity is loaded the changes would be reverted.

This is why Pandora has the concept of PandoraEntityInstance which can be created as follows:

var instance = entity.instantiate()

The instance then is a "copy" of the original entity but with the ability to change its attributes and save and load it to a custom save game via Pandora.serialize() and Pandora.deserialize() - the idea with #41 is to even support auto-migration of changes, e.g. if the entity changed, all its instances will get the changes automagically.

While this works great, this becomes problematic once we use custom scripts:

class_name Item extends PandoraEntity

var instance = item.instantiate() # instance is still of type PandoraEntityInstance

this means that while custom scripts allow us to be very specific about properties (and introduce type-safety), instantiating them loses that type-safety. To solve this, one would need to introduce a custom script like so:

class_name ItemInstance extends PandoraEntityInstance

and then inside Item do this:

class_name Item extends PandoraEntity

func instantiate() -> PandoraEntityInstance:
   return ItemInstance.new(...provide custom params here that are implementation detail to Pandora)

and then one could do:

var instance = item.instantiate() as ItemInstance

Pandora even maintains this type via Pandora.serialize() and Pandora.deserialize() but it has some disadvantages:

• any custom type requires effectively 2 scripts
• both the entity script and instance script would require the same "custom functions" to be compatible

This leads to massive overhead and is rather error prone.

Any ideas would be greatly appreciated.

[MarcusRiemer]

I'm not well versed in Pandora (yet), so my advice is based on intuition and not an expertise. But to me this sounds like your approach outlined in #41 is enough to tackle the problem. Supporting incompatible data schema and code versions seems like a great hassle with comparatively little benefit in a scenario with usually tiny databases. I would prefer to update the whole state of my database at once via migration scripts.

[bitbrain]

#41 is about migrating data, while this discussion here is about custom types. Those are two independent concepts. The purpose of custom scripts is so you have type safety and can express your data model via types in GDScript (rather everything having the same type). However, this currently does not scale well with instances.

[bitbrain]

Idea: remove PandoraEntityInstance

Instead of relying on instances, what if instantiating a PandoraEntity would look like this:

var entity = Pandora.get_entity(Items.SWORD)
var sword_instance = entity.instantiate() # returns PandoraEntity

print(sword_instance.is_instance()) # true
print(sword.is_instance()) # false

and only values of instances can be changed (e.g. it could throw an error if trying to set a value on a non-instance).

This mechanism would allow any custom script to "just work":

var entity = Pandora.get_entity(Items.SWORD) as Item
var sword_instance = entity.instantiate() # returns Item

print(sword_instance.is_instance()) # true
print(sword.is_instance()) # false

[eth0net]

This looks like a pretty good approach to me, cutting down boilerplate and making the whole flow simpler.

I've not got any experience with this specifically however, but from an outside view it looks approachable and sounds like an improvement!

[bitbrain]

This proposal is implemented by #102