Defold roadmap H1-2019

[britzl]

This roadmap outlines our plans for the first half of 2019. The list of planned new features and improvements are in no particular order and based on the previous roadmap for H2-2018.

ENGINE FEATURES

RESOURCE PROPERTIES

Resource properties will allow developers to define new property types referencing component resources such as atlases, sounds, models and many other things. This opens up a whole set of new possibilities for dynamic content creation. This task remains from the H2-2018 roadmap.

MULTI-TEXTURING

Multi-texturing will greatly simplify the way additional textures are fed into shaders for various effects that are currently very hard or impossible to do in Defold. This task remains from the H2-2018 roadmap.

MODULARIZATION

During H2-2018 we brought our system for native extensions into a stable state. During H1-2019 we will use this system to extract non-vital parts of the engine core into native extensions, thus giving users even better control of what to include in the engine core, as well as opening up for community collaboration and improvements. We will start by extracting the webview into a native extension and then move on to also extract push, iap, iac and the Facebook SDK.

AUDIO

Our ambition was to make major improvements to the audio support in Defold, but due to shifting priorities we need to reduce the scope of this work in H1-2019 and instead ship a number of smaller improvements.

BUG FIXES and IMPROVEMENTS

We will continue our ambition of delivering a stable and bug free editor and engine with the clear goal of no hard crashes. We will continue to work together with the community to identify, prioritize and fix bugs and crashes. At the end of 2018 we made several improvements to engine stability and we’ve managed to reduce ANRs on Android. During H2-2018 we fixed 188 reported engine bugs and 253 editor bugs, not to mention all of the new features and improvements. If you’ve found a bug or have a feature suggestion please get in touch!

PERFORMANCE

We constantly work to improve the performance of the Defold engine and editor. For the engine we focus on maintaining a low runtime memory footprint as well as a small binary size. During H2-2018 we upgraded Emscripten and released Webassembly support for HTML5 builds. During H1-2019 we will continue to improve engine performance in key areas that we identified during 2018. Examples of areas that we will improve are optimization of transform updates (which will help in games with a large number of game objects) and url resolution.

PLATFORM COMPLIANCE

During H1-2019 we will make several changes to comply with new platform requirements. On Android we will add 64-bit support before the August 2019 deadline. On iOS we will add iOS SDK 12 support before the March 2019 deadline. And finally we will also migrate from GCM to Firebase for Android push before the April 11 2019 deadline.

RENDERING & 3D

METAL and VULKAN

With the upcoming deprecation of OpenGL in iOS 12 and MacOS we started working on the new rendering pipeline in H2-2018. For iOS this will mean the transition to Metal, most likely via Vulkan and Molten-VK. We will continue with this work during H1-2019.

IMPROVED 3D SUPPORT

The Defold engine operates fully in 3D, although tools and APIs are geared towards 2D games. Our plan during H2-2018 was to make several larger improvements to the 3D support in the engine. We have decided to reduce the scope due to a shift in priorities and instead focus on a few smaller but still important improvements in H1-2019.

PLATFORMS & SERVICES

NEW PLATFORMS

Our current set of supported platforms have remained the same since the introduction of Amazon support almost three years ago and the more recent additions of sub-platforms such as Facebook Game Room and Facebook Instant Games. The stance which we’ve taken regarding the addition of new platforms has been to explore new platforms when there’s been enough requests from our community. During H2-2018 we started reevaluating this decision and we made some steps in the direction of porting the engine to one of the current gen game consoles. We will continue with this work during H1-2019.

During H2-2018 we started working on support for running Defold iOS builds on the iOS simulator. Even though this won’t replace testing on actual hardware it will be of help to developers with limited access to iOS devices. We will finish this work during Q1-2019.

GOOGLE PLAY GAME SERVICES

Google Play Game Services support has been a long requested feature of Defold. Support for this feature will be added as a native extension during H1-2019.

EDITOR & TOOLS

UNIFIED BUILD PIPELINE

While the migration to the new editor can be considered almost fully completed (some very minor differences still exist) we still only provide the old build pipeline (bob.jar) for users building from the command line. The new build pipeline in the new editor is better and faster than bob.jar thanks to some really great work from the editor team with optimizations and parallelization of tasks. We want command line builds to benefit from these improvements as well and will extract the build system into a standalone tool suitable for command line use. This task remains from the H2-2018 roadmap.

IMPROVED UNDO WORKFLOW

The current undo functionality in the Defold editor works on a global level, meaning that there’s a single list of changes. When an undo is performed the most recent change in the history will be reverted, regardless of which editor tab that is open. This has caused some confusion in the community and because of this we have decided to revise the undo workflow. Work on this started late 2018 and will be finished during Q1-2019.

EDITOR EXTENSIONS

The ability to extend the editor with custom tools will be one of the next really major milestones for Defold during 2019. Editor extensions will open up many new possibilities for developers to improve their workflow and integrate custom tools to speed up content creation. This task remains from the H2-2018 roadmap.

[sergey.lerg]

Resource properties will allow developers to define new property types referencing component resources such as atlases, sounds, models and many other things. This opens up a whole set of new possibilities for dynamic content creation. This task remains from the H2-2018 roadmap.

Will that allow setting different textures for game object’s models from the same factory? Can you please elaborate what is it.

[Mattias_Hedberg]

EDITOR EXTENSIONS

The ability to extend the editor

Quite excited about this. Do you guys have any information if you will give a MVP/Alpha release similar that you did with NEs? What is the intended scope of the feature?

[gianmichele]

Also super excited about editor extensions. Hopefully we’ll not have to learn Clojure to to them

PS: Godot’s editor is fully scriptable in GDscript the same language used to code…hint hint

[Mattias_Hedberg]

If the trade-off is “You have to learn Clojure but it is as extendable as for instance Maya” then I say - sign me up any day.

[britzl]

Can you please elaborate what is it.

It’s an extension of the existing property system where you will be able to do things like:

go.property("my_atlas", resource.atlas("/atlas.atlas"))

function init(self)
    go.set("#sprite", "image", self.my_atlas)
end

In the properties view of the editor you would get a file browser button next to the “My Atlas” property. There will be a number of different resource types that you can set as a property: material, font, atlas, texture, tile source etc

[britzl]

Do you guys have any information if you will give a MVP/Alpha release similar that you did with NEs? What is the intended scope of the feature?

We will start small and release an alpha. We would initially aim for a system where you can hook in your custom scripts for various kinds of triggers within the editor: on file change, on menu interaction, on right clicking an item in the asset view, pre/post build and bundle and so on. You will get some context specific input, run your code and produce some output. For certain hooks you’ll be able to generate menu items. It is very likely that the scripting would be done using Lua (with possibility to run other processes using os.execute()).

[sergey.lerg]

So setting the texture property at runtime (go.set() and properties list in factory.create()) would allow changing the texture resource (different resource path) and not just copy from the property texture into the current texture pixel data?

[Pawel]

Great, really excited about a roadmap few questions ofc: What platform did you mean? Would it be Switch? Or PS4/XBO? How the iOS simulator will work? Will it be a standalone program? Windows/Linux support? Will resource properties be applied to particlefxs too?

[britzl]

What platform did you mean? Would it be Switch? Or PS4/XBO?

We have looked at two different consoles but we have not decided on anything. We would really like to add a console to our range of target platforms, but it all depends on our other priorities for the Defold product as a whole. No promises can be made so please consider it a great bonus if it will happen, do not count on it!

How the iOS simulator will work?

It will be a separate bundle target. @sven knows more.

Windows/Linux support?

What do you mean by this? For the iOS simulator?

Will resource properties be applied to particlefxs too?

Not sure. I’d have to check that on Monday and get back to you.

[britzl]

So setting the texture property at runtime ( go.set() and properties list in factory.create() ) would allow changing the texture resource (different resource path) and not just copy from the property texture into the current texture pixel data?

Yes, you would be able to update the resource path of a sprite with a new texture, defined as a script property.

[Pawel]

consider it a great bonus

I will!

What do you mean by this? For the iOS simulator?

Yes, as I was imagining it as a separated program, but it will come with editor then, right? I would like to thank you in advance for it, because it allows many people, like me, to try to test a project like on Apple’s devices before investing Very noble

[gianmichele]

Love love love!!!

[gianmichele]

No this is referring to the Xcode iOS simulator. You will still need an osx machine to use it.

This is still super useful for example to test your app at different resolution if you don’t have the physical device.

[Pkeod]

Is the possibility for localized UV space for sprites on the radar? Currently if I apply a gradient effect based on UV space it goes over the entire area of the atlas and not just the area of the sprite.

[britzl]

@sven and @jhonny.goransson?

[jhonny.goransson]

We would need to expose atlas size and Sprite texture size via vertex attributes due to batching. individual Atlas images can be rotated so i guess that information is needed aswell. Is this a common feature that people would find useful?

[selimanac]

Is this a common feature that people would find useful?

+1

Need help for Sprite Outline shader

Hi Defold Masters I have a problem with outline shader for sprites. First of all I’m not sure if this is the right way to do it. i’ll be glad if anyone can help me. My problems: Since var_texcoord0 is based on the whole atlas, I couldn’t find a way to calculate the correct offset value. If the atlas is big, than I need a very small float like ‘0.001’. if it is small need something bigger like ‘1.0’. How can I(or should I) calculate the right offset for all ? Here is the dif…

[Pkeod]

Yes, it would be extremely useful for all kinds of shading effects. There are a variety of common shader effects that are possible in Godot or Unity but not so easily in Defold. You should ask your technical artists about it…

Consider too the problem of applying normal map to sprites to light them like with http://www.snakehillgames.com/spritelamp/ I’ve tried hacky ways of doing it but nothing good enough especially with rotation of sprites.

[jhonny.goransson]

Alright, case and point Not sure if we can allocate time for it soon, but there’s an exploration friday next week so maybe I’ll dig into it then!