Best way to add properties to game objects

Questions
#1

New to Defold, programming in Lua a decade or so.

The actual problem I am trying to solve right now is hide/show of objects, and am using scale to 0 to hide the objects. Works fine. But the problem is restoring the object if the original scale was not 1.0. I do a similar thing ‘restoring’ objects moved to their starting place in a lot of games, restoring to default of many attributes is a technique I use a lot.

My typical solution in other Lua-based game engines is to create custom properties to store the original scale or position or color or whatever. In Lua, it is easy, just object.property = whatever. But Defold has disabled setting arbitrary properties, and I get the ‘large team’, ‘corporate long-term support’, structured programming reasons for this (but I am now a retired solitary programmer). I am struggling to find a workaround.

Using go.property seems reasonable, except that it puts the property on a script, not on the object, so other scripts (eg common modules) have to jump through hoops to find them and it also requires having a script attached to every object, which seems silly. Similar with using messages to store information. But I guess putting a script on every object and sending it a message or creating script properties are perhaps the only choices I have?

For now, I am creating a storage module (shared) in which I have a table where I put original scale for every object before changing the scale. This is not a bad solution, I think.

What is the right Defold way to save/restore information like this? Is there a way to change or subclass the game object to put these extra properties on all of my game objects by default?

Thanks for any help.

#2

There are no “type system” facilities in Defold unfortunately, besides what standard lua offers. In your case, it seems like simply indexing a table by game object id and then holding states in that could be an option? There is no point in trying to attach the properties to objects if they don’t need to be able to access them themselves (i.e. having a script attached to every object).

#3

First things first: Welcome to Defold and the forum!

Some thoughts:

Don’t hide by setting scale to 0. It’s much better to disable the components on the game object by sending a disable message to it. Disabled component will require no computations and no rendering, while a scaled down game object would still be active within the game. Disable it like this:

msg.post("mygameobject", "disable")

Now, the question is from where you wish to disable it. If a script on the game object itself is responsible for enabling/disabling it then you can store this information on the self object you get passed to every script life cycle function. You can and should use the self object to store other things as well, such as initial scale:

function init(self)
	self.initial_scale = go.get_scale()
end

If it’s something outside of the game object that manages the enabled/disabled state then perhaps map game object ids to their state:

self.objects = {}
for i=1,10 do
	local id = factory.create("#factory")
	self.objects[id] = { enabled = true, foo = "bar" }
end

It’s hard to give very generic advice since the solution really depends on the case. In most cases I do not disable game objects at all. I delete them (go.delete) when I don’t need them and create new ones (factory.create) when I need them again.

#4

Thank you both for the suggestions, that is great. As for Ragnar’s suggestion, that is what I am doing, it is what I meant in the next-to-last paragraph (“For now, …”), though you explained it more clearly. In a module, I have a table indexed by object id and store state there.

Britzl, thank you for the ‘disable’ suggestion, that is clearly better, and just what I wanted. I somehow missed that. Delete and create I use a lot also, depending on what I am trying to do. I typically would have to preserve state anyway after deleting because in my unhide, I have to have it be where it left off.

Thank you both, I am getting to like Defold. I can move a lot of my games to this environment, but for some of the more educational (content-heavy) apps, I still have to learn about doing picklists or some selection UI. The drawing seems pretty primitive, seems easier to use scaled rectangle images, but maybe I’ll find what I want yet.

2 Likes
#5

Yes, the gui in Defold is very basic, but it doesn’t get in the way either. For some examples maybe look at the Dirty Larry UI lib for Defold.