General Editor Usability

The Defold engine seems very nice and I appreciate you releasing it, but it could definitely benefit from some productivity TLC.

The general theme of all of this is the tool is there to do the work, not the developer. The developer is there to provide the smarts, the tool is there to do the grunt work. Overall there seems to be a lot of go-here-do-this, go-there-do-that in the existing editor design (which is time-consuming, error-prone, and expensive for the game designer). The editor doesn’t provide any sort of guidance or workflow.

All of these comments came up while using version 2 of the editor but appear to apply to version 1 also.

Scripts on objects – instead of having users create a script then attach it to a game object, just have that automatically provided as an option at the game object level. I get you want re-use, but the handling is cumbersome. Scripts are the guts of the game – it should be right-click and type/use existing.

Default values – automatically provide reasonable default values if possible. For example, default the Text object to use the system font instead of throwing an error. The editor already knows about the font! It’s listed right there in the IDE!

Automatic creation of fonts – there’s no reason to have the developer specify font resolution. The compiler can determine what the developer needs at compile time, so it should just create the correct assets automatically.

Automatic creation of image atlas – likewise, the compiler has enough knowledge to automatically create texture atlases at compile time. I recognize that there is an edge condition where you would want to create an atlas for separate delivery but that should be a separate work flow. Again, the editor already knows!

Automatic creation of whatever – if the compiler can figure it out, let it. That’s its job. The days of programmers being able to write better optimized code than compilers ended 20 years ago.

Improve the GUI library – include nodes for the standard GUI widgets used in GUIs including text input, scroll panels, buttons (not just boxes), etc. There’s no reason that every developer that uses the tool should have to reinvent these. Every professional-level game has some sort of GUI, so making this as easy as possible would be a huge benefit to everyone. Yes, it might take a week of development time to add an QA a scroll panel. But it will also take 10000 other game developers a week to do it. Save them the time.

Drag-and-Drop – components don’t seem to allow drag-and-drop to add items to the hierarchy. Minor but kind of strange in a modern tool.

Debugging – I assume that debugger support is just not added yet.

Promotional environment – I assume that at some point in the future your company will develop some sort of app store in the same vein as Steam.

I realize that this is kind of nagging, but I think you have the core of something that could be great. I’d like to see it become a real leader in the market.

1 Like

Thanks. We appreciate all feedback!

Scripts are separate files and, as you say, there is a difference between in-place and file-reference placement of things. We definitely want to make workflows better and at the same time provide clarity and help users in the right direction. We’ll evaluate this idea and see if and how it fits with the rest of the plans.

Actually, the editor knows the font file (since it is part of the project) but the runtime does not. One important principle in Defold is that everything is statically linked. If you add a 100Mb file to your project for testing purposes it will not automatically be part of the build, unless you explicitly add it to a collection that is part of the runtime tree.

There is no way the runtime can know at what size a font is going to be displayed. Consider this code:

local node = go.get_node("text_node")
gui.set_scale(node, my_scale * user_setting_scale)

The target scaled size is only known at runtime and the developer has to make the call at what type and resolution the font should be. Sacrifice memory with a higher resolution may be fine in one case, not in another. Similarly, for atlases you (among other things) want to minimize draw calls and group images based on how they are used in the render pipeline. Also, the runtime Lua code decides what animations to actually play and use which again makes it (even theoretically) impossible to infer what images to include and put on what atlases.

Our approach is to provide a good set of simple building blocks - to not solve game specific things but the problems everyone runs into. Higher level stuff is for libraries and a GUI widget library is a great example of that. We are very limited in staff and time and the success of Defold depends on our community. We try to provide good means for sharing libraries, games and assets. The upcoming “Project Sticky Iron” (see Community pages (was previously “Project: Sticky Iron”)) is intended to help make that happen.

This is planned. See https://github.com/defold/editor2-issues/issues/408

(Please don’t hesitate to report bugs on the editor2-issues Github btw)

Have you tried to debug with Zerobrane? See http://www.defold.com/manuals/debugging/#_debugging_lua_scripts_with_zerobrane

“Sticky Iron” is on its way. It is not intended to be an app store though, but a sharing environment.

4 Likes