What is Defold and what does it eat?

This is a small analysis of the Defold game engine on a practical example (under Andoid), as well as some subjective criticism and praise, well, in general, a review. Who is interested to learn more about this engine, there is one interview, read . Information about Defold in the network is small, so it will be a contribution to a very small piggy bank.

Little foreplay

So, Defold is a relatively young (since 2011), cross-platform engine with a visual editor like Gobot, Construct or Cocos Creater. It is mainly intended for 2D (there are still not enough tools for working with 3D), the programming language is Lua. It differs from similar engines in stable performance on mobile (flat 60 fps without lags with sound), small build size (2-4 mb depending on platform), convenient gui and go system, steep animation settings (curved keys), and also completely subordinate editor (I will tell below, intrigue). The site, under the account, it is possible to store project files. Any authorized team member can make changes to the project, which is generally convenient, although I myself could not always use it, because our working proxy does not give the editor access. Have defold ' and there are features in writing code, although I would take them to the minuses (details below). And yes, I almost forgot, Defold team is very responsive, deserves respect. He applied for help to the forum several times - right there, within 10 minutes, they answered and helped. Once there was a problem when launching the editor on Ubuntu, the guys could not help at first, but after a couple of hours their leader contacted me and resolved the situation. It turned out that linux has a bug with standard firewood on the video, so you need to install the native ones. Also on the site there are assets, where without them. Well, let's finish the prelude, let's go! Once there was a problem when launching the editor on Ubuntu, the guys could not help at first, but after a couple of hours their leader contacted me and resolved the situation. It turned out that linux has a bug with standard firewood on the video, so you need to install the native ones. Also on the site there are assets, where without them. Well, let's finish the prelude, let's go! Once there was a problem when launching the editor on Ubuntu, the guys could not help at first, but after a couple of hours their leader contacted me and resolved the situation. It turned out that linux has a bug with standard firewood on the video, so you need to install the native ones. Also on the site there are assets, where without them. Well, let's finish the prelude, let's go!

We start!

We register and download Defold version 2 editor on the site (1 is no longer supported), we also create our project and download it there. The project is then stored on the website, or locally (if we are afraid that the cunning Defold will spy). Next, open your project through the editor (in the pictures will be mine), we look: On the left are the files, on the right is the inside of the selected node, in the middle is the editor. I will not enthrall you with the analysis of the interface, you can study it yourself. See the builtins folder? There, a standard set of scripts, fonts and other things for the operation of the engine, you can study. Everything else is your own files. In the project settings (in the image in the middle) there is a line (highlighted) of the Main collection, there is a link to the main collection file with which your application starts, open it:







Yes, yes, it is this mess you will have in the editor, because there is no way to hide the unnecessary (we put in the minuses). Let's first understand what a collection is. When I wrote above about the subordinate editor, it was meant that each project file, no matter which extension it is, is a text file and can be edited independently. So, a collection is also a text file with a description of internal objects.



A collection can contain any objects (scripts, sprites, sounds, etc.), as well as other collections enclosed in it. All its contents will be created when executed, the scripts are initialized. Collections can be wrapped in Proxy. Proxy is a great thing, they are usually wrapped in various levels of your game, for example. They can be shipped, loaded (the nested collection is created during loading), paused, slowed down, accelerated processes.

Also, a very handy thing - Factory and Collection Factory. These are wrappers for objects that are indispensable if you need to create and delete objects dynamically, in the process of execution. Here is a good example of a dynamic collection. This is a thorn, it is loaded with a random algorithm at the level and deleted, once it drops out of the camera view, so as not to waste resources.







This script is inside the spike, in the update method it checks if its own position is less than the position of the character (player in the center of the camera) plus a small margin, then deletes itself. By the way, you can hang properties on scripts. For example, I have a factory collection object, inside which is a npc sheep. Here is our npc, it has such properties on the script as running speed, stride, jump strength and endurance. When creating an instance, I randomly prescribe these properties to it. We create npc: The internal script instance changes its properties (uniqueness through self.): And now our sheep run at different speeds:

















By the way, about the code editor - it is primitive. Methods can not be folded (as for example in Sublime), and when the lines become many, you have to turn the wheel for a long time and painfully, looking for the right one. There is also no increase in scale, but these are trifles. Defold Assets has instructions on how to teach Sublime to populate methods from the editor.

As for the particles, there is a convenience - if you select an emitter in the editor window and press the spacebar, you can immediately see the result.

Well, now how the engine works

Defold accepts two separate branches for rendering, these are GUI and GO.

GUI - as the name implies, this is a user interface. It exists separately, is configured on the screen and is always rendered on top of everything else. The GUI has its own methods that are not related to GO, although they are similar to it. This is also a collection, but with restrictions. On one GUI one script is accepted, with the .gui_script extension. An excellent and convenient thing, although there is a nuance - from the GUI you cannot directly access any game objects, only through global variables, or through messages (I’ll tell you later).

GO is a game object (something like a transformation node) that contains information about movement, rotation, scale, etc. Inside takes everything, including other GO. Used for collections, it is an obligatory wrapper for any number of objects (as if a group).

Further, the fun begins. On Defold, I moved from a friendly Android Studio with Libgdx, and this is what shocked me: objects can not be accessed directly, only through kostylnye methods or through messages that still do not give creative freedom, there are serious limitations. If we compare it with the same Libgdx, there I could easily rewrite the existing class from the Lib library and access it already. In Defold, alas, you use what you have, and if something is missing, ask the developers to add the necessary function, or you are looking for a detour. For example, when working with sound, you can not know whether the playback is over! I had to add a crutch, recognizing the duration of the sound on the file being played. As for the simplified Box2D (criticism suddenly rushed off), so did the glorious methods of detecting and processing before, during and after the collision! Instead, a message (not always every frame, especially on a mobile) with collision information arrives in a script that is in the same GO with a physical body, and that's it. It is also impossible to move the body if it is physical, only kinematic can be, and this property cannot be changed during performance. GO cannot be scaled along with the physical body, in the editor it will change the scale of you, but not in the game (they seem to have promised to fix it). GO cannot be scaled to negative (for example, mirrored by X), everything will work out in the editor, but in the performance it will return to the original one. In general, I rebelled a little about this and (having solved these problems through crutches) calmed down, after all, the speed of Defold and his editor outweighed the braking Libgdx (Let the readers forgive me for my subjectivity!

The msg.post () method and how to treat it

In general, each object has a url (for example, “main: / main_pers # spine_anim”), by which you can send a message, and even attach variables to it. Messages fly directly to the addressee, without waiting in the queue for processing. This is both convenient and sometimes confusing. Messages are often needed in order to send information from the GO to the GUI (for example, your sheep caught a bubble with fruit, update the score of points in the GUI). and vice versa (the energy is over, we inform the sheep that it is time to sleep). Problems arise when the variables calculated in one of the scripts in the update method do not have time to update, because the messages are out of turn. But this is nothing important to get used to.









Another nuance is the addresses of the objects. In essence, these are strings, however, on mobile platforms, strings are disabled to save resources (where the fuck is this written !?), hash goes instead. It seems nothing, yes, but if your game logic sends messages through edited lines, then expect trouble, the postal service will not hand the letter to the addressee. Therefore, reserve addresses to variables through the msg.url () method and do not touch. Actually, these are trifles, but at first, terribly takes precious time. For example, in order to find out whether a sheep is worth on the ground, you need to add an additional kinematic body just below the legs, and ask him if there is an entry into the ground.

Dragon bones instead of Spine

No problem, we use a dragon, because the call is very paid. But as always there is a but. The spine has a function - the skin, the dragon does not have it. How to solve? Hands Opens json from spine and look where there is skin, analyze, copy, paste into our json from the dragon and rule as it should, that's all. The python script saves you a decent amount. As for the scripts, it is generally a fairy tale. Since all files are text files, then editing can be automated. Here, for example, I collected a level in the editor using a general atlas with a large number of textures (more than 300), but I didn’t use everything, only about 100. In order not to go through my hands, I use the Atlas optimizer - everything used in the collection remains, discarded. Very handy when you can automate something.

Share and Admob

The Share button can be found in assets and attach in a couple of minutes. Caution with Assets! Asset Admob, for example, significantly slows down the build, and is also not given at all when there is no connection to the network. In the case of Admob (I will not write how to embed it, everything is in the documentation for the githaba), I still have to do a check on the platform, otherwise the build on the windows will give an error. Therefore, in the development, postpone advertising and other assets at last, because Build at Defold without them is very fast. As for localization, you can create yourself such a dictionary:

   dict["ru"]["lang"]="Я русский"
   dict["en"]["lang"]="Ya ne russkiy"

and change the text during initialization, addressing as follows:

 language=sys.get_sys_info().language 
   label.set_text("game:/go#label",dict[language]["lang"]

That is, in principle, everything, according to the results, Defold is very cool (when he figured it out), so I advise everyone. Who cares what came out of it for me, see the trailer here (not for the sake of PR, my target audience is children).