How to declare properties that have string value

[Mathias_Westerdahl]

The reasoning comes from place where games do an inordinate amount of string based stuff.
Stuff that isn’t easy to optimize at the end of the project.
Therefore, we try to keep that gate closed unless absolutely necessary (or the situation is well defined and small enough).

There is care about performance of strings, but much of the SDK uses Lua api calls (vmath a classic example) where if you call alot of vmath functions you will create the same “string” styled issue

There are many areas in the engine that could use more care and probably some optimizations. I hope we can get to work on those areas too.

[ additional q ] What would be the appropriate method for “getting” text associated with a game object that has been generated in the game object (not for display btw - for data reasons). How would you attempt this via a message? ( req → resp? )

For text associated with a script, I’d use hash properties, e.g. go.property(“TEXT_ID”, hash(“TEXT_ID_BOSS_NAME”)).
That way I can look up the localisation in another Lua module depending on currently selected language.
E.g. something like this:

local go_text_key = hash("TEXT_ID")
...
local text_key = go.get("#script", go_text_key)
local text = localization.current_language.texts[text_key]

[dlannan]

@Mathias_Westerdahl

For text associated with a script, I’d use hash properties, e.g. go.property(“TEXT_ID”, hash(“TEXT_ID_BOSS_NAME”)).
That way I can look up the localisation in another Lua module depending on currently selected language.
E.g. something like this:

I need the text as original text at the other side of the get (its string based data - think similar to utf8 but not used for textual output). Turning it into a hash obviously isnt ideal

Also in this example would go_text_key need to be a property? Or is this in a module (like above) ?
I dont mind using modules, but I kind of would like to be able and cut and past the string between objects in the editor - this data is coming from Blender btw, so this is a very very very … edge case

[ note: ] yes Im doing probably very weird and stupid things to your Defold

[Mathias_Westerdahl]

@dlannan

Turning it into a hash obviously isnt ideal

I’m not talking about turning the payload into a hash, but getting the key.
The payload would be stored in plain text in a regular lua module.

[dlannan]

Ahh yeah. ok sorry. Thats kinda something I have been playing around with. Dynamically it is kinda ok (quite long winded), but as I said it’d be nicer if you could “cut and paste” the string from one go property to another in the editor. I wonder if I can use a texture resource… might try that out.

[gianmichele]

While I understand and agree with the reasoning of this, it also has a toll on creating re-usable script components in the sense that the UI/UX exposed to the user has lots of limitations.

For example in all the camera extensions, choosing the projection method is relegated to multiple checkboxes which is not really good from a user perspective and should be handled by a dropdown that return a string.

I think there is room to improve the presentation from the data itself. I would really love to be able to have a property that is a vector4 but is for example presented to the user as a color picker

Thoughts?

[dlannan]

Hrm. From an architectural pov, I see that as a very different issue. Please note I am making a number of assumptions about the source code, so if Im way off, please correct me.

As I understand it, there is a basic loose coupling between gameobjects and components (ie you dont have to have them). As a script is essentially a type of component, the designation of a property within the script to be mapped to a gameobject should be quite trivial, and be completely referenced (much like resources I assume should be), so referencing a string should be no different. Thus the why I feel the ‘performance’ criteria seems a little misplaced. More importantly, if you use pure lua text then the cost should be extremely minimal, and you could easily automate string pools (Ive done this myself in luajit systems) allowing you to track and and manage heavy string workloads, if there are any, at runtime.

Again, this makes many assumptions about the underlying SDK source. From the editor perspective, components like cameras I would also expect to be referenced, but they are also a very different type of component and thus would be managed as such. I dont think its either bad or otherwise that you have a number of properties that reference each other, engineering wise, it really doesnt matter. What I think (and remember, just my opinion) is that editor priority would be squarely aimed at allowing users to feel comfortable using the system How that actually happens is far less important since it can be massaged when packaging resources and compiling scripts.

If I were to do something like this, providing base lua types (because remember this is coming from a script - properties that is) number and string seem like a very straight forward thing to support. Supporting a selection of Defold specific object (userdata I assume) types like vector3 etc makes good sense, theres no need to expose everything. Having vec4 limited to a color picker does seem a little odd - but I suspect that is because there is no “color” type specifically which means determining the use case for the property just from the userdata would be tricky - maybe add a color type in name only, and have it cast to vec4 on property use?

Anyway, its worth chatting about this, but I think I really need time to get into the source which I intend to do soon. Then I’ll be able to make more sensible suggestions

[gianmichele]

The vector4 example is a bit extreme I agree.
The point that I’m trying to get across is to present that data in a more user friendly way for users. So for example even a simple integer/float number would still be just that in the data but maybe presented in the properties panel as a slider with limits rather than just an input field?

[Mathias_Westerdahl]

I agree, but I’d rather see us adding a ticket/feature request for this separate topic than use this other topic for the discussion

[Haath]

@dlannan

so referencing a string should be no different.

Except you don’t know how much space a string needs in memory. With all the other properties, the memory for each gameobject can be statically allocated in advance. Not relying on runtime heap allocations more than necessary I think is a pretty decent choice for a game engine.

And it’s not like you are blocked from passing strings to objects, you can still use messages and lookup tables.

One of the things I love the most about Defold is how minimal it is. And in my opinion, to make a small(?) engine compromise for some minor UX convenience, which is entirely on the editor side, would be an odd decision.

[dlannan]

Thats not quite the case if you are using Lua strings. All strings are interned and converted to hash lookups (thats all of them). So you certainly do know their sizes and capacity when you go to execute the bytecode (thats when it happens). This is one of the very awesome benefits of luajit (and string buffers in luajit are even more powerful). Additionally in the editor - you would certainly know the size, just like any other resource.

The particular problem I have is related to how I use strings to move data around the framework (which means its a not very applicable use case to most anyway). It is very useful to be able to do this via simple copy/paste mechanisms (from a users point of view) and in editor - the performance benefits are completely moot. Because when you run the build process you can easily capture the property strings and literally use them just like a normal resource (like a texture as mentioned above). I have done this in other luajit systems quite a bit (Ledwerks and Shiva for instance). Its brilliant for localization for example, cos you just pool all the strings into a cache and have selectable hash lookups in lua.

The hashing to put a string into the engine and then get it back out again, I get, would be problematic and I think this is what people are referring to as a performance issue - but I think that this is looking it at from the wrong direction. The string is just a byte array, like a texture… like a shader… like a audio sample… they are all the same, they just have different associated meta data to determine how they operate. Hence, why it seems odd strings are not provided for - as I understand it, it would be as simple as copying say the vertex shader object (which is a text block) renaming it to a strings object and blam - you got strings. Add a “New strings file” to the resource pool voila.

I know I have said the above a couple of times. I’ll leave it at that. And sorry @Mathias_Westerdahl if this has been a bit ov erkill. Its one of the extremely few ‘odd’ things I have come across in Defold - and honestly this is more about user editor front-end simplification not technical underlying issue (theres a number of ways around the problem, they are just a bit more messy for the user).