An Introduction to Defold for Creating Mobile Apps and Games

There were various predictions about the future of apps — one was that everything would just be HTML5. Or that one language would dominate. What we actually have now are various app targets that most build platforms can target as required. The focus has moved away from a single language or platform and into the more usual methods and processes used to express the designer’s requirements and to manipulate graphical user interfaces (GUIs).

Defold is a new entry into the game builder market, promising simple construction from a single editor/builder IDE: “Defold is built from the ground up as a 3D engine with a special focus on top-notch tools for 2D game creation. Build your games using a component-based system for maximum performance and modularity.”

Two things of interest here are the focus on 2D games, and going straight into a component-based system. So while the engine manages the graphic objects, the developer writes behavior. This is how the main game platforms all work, though everyone is aware of the relative complexity of Unity or Unreal. Not only is looking at a simpler engine a nice way to slide into this world but there is also the suspicion that AI will function more comfortably in a world that can express slightly less user intention.

Defold was developed and used internally at King (the very big mobile game studio that does that confectionary destruction game) for a few years before the decision was made to make it available to developers outside the company.

My aim in this post is to quickly check whether I can build an example, and that I can then easily add UI. So we will flex our design understanding and pipeline muscles. It is themed as an app for making games — but most readers of The New Stack understand that games are now just apps with a focus on story and spectacle. Even corporate apps have the responsibility to “delight users” these days.

It is quick to set up and go. I installed the Mac version of the editor/builder. The “scripting” language — to give the object’s behavior — is Lua. I’ve never used it, but it is has been around for quite a long time. The tutorials are available from within the editor. In fact on installation, you can immediately open one as a project. We will try our luck with the “Colorslide” tutorial that includes a GUI example:

The tutorial starts with an existing game, which we will enhance. Like most IDEs, the editor supports a runtime environment so that we can check that the game runs at any time.

It is a simple game, allowing the user to slide blocks — we must slide them into the same color thus:

It runs as expected. The rules of the game itself are there to look at but don’t concern the tutorial. Note the layout contains the “Colorslide” tutorial in a tab, a file hierarchy on the left, an inspector on the right, and a console at the bottom. This is what it looks like after I finish checking the game:

The tutorial takes you through the project structure. We see the game as split into “levels”, with a starting setup. This will look a bit odd to those used to seeing only programming code in their projects.

It is better to just follow a tutorial, and then explore definitions from there — but it might be useful to grok these central definitions first.

Unity developers also use game objects and components. A game object is used to bind some graphical aspect (like a button or a bullet) with its behavior. The components are specifics of presentation or behavior, like a font or a texture. The collection is the hierarchy of all the game objects that make up all or part of an application. The trick is to remember that Defold wants to manage the graphics, but wants you to manage the organization and behavior.

The tutorial invites you to look at how the game is constructed, immediately presenting the reader with a task to connect the levels with a frontend GUI. We must load the appropriate level (the grid of colored blocks) via buttons.

As you do the first bit of editing, if you are familiar with code development you may be a bit flummoxed by adding specific objects and components to a hierarchy. Why are these not represented as code? Don’t worry, there will be code (or script) soon — but think in terms of what the engine manages (the graphics and messages), what the user manages (behavior), and the bits between. Thread control is not owned by the user, because responding to GUI cannot be done properly in a linear manner.

So in the “Colorslide” tutorial, we are told to add a collection proxy, and we add a loader script — this means we create a file in the left-hand side hierarchy and then add a script component into main.collection.

We are introduced to our first bit of Lua, and some message-passing behavior:

Fortunately, this is pretty basic. There is clearly a message passing backend, and it works by identifying the object from an id, then identifying the function by name. There is clearly an initial load of level 1 in the bootstrap initializing call.

You will find that certain components insist on settings — for example, a text component needs its font to be set.

You will probably wonder by yourself whether you can just “copy” a UI element from the inspector, paste it, then make appropriate changes. You can. Soon you will have an array of four buttons and a heading. But now we have to give the button actions. Creating a “GUI script” was a bit odd (is it not just a script?) You can see when you create the script all the default messages it can receive. But for the tutorial, we need to add behavior into very few.

Soon you will have a nice GUI that can select the game level:

I chose to stick the “select level” text at the bottom, contrary to the tutorial.

The tutorial goes on to add the other things to give the game a proper flow, but by now you should be ahead of the tutorial — just using it to pick out difficult scripts and peculiarities of the platform.

Before I go, let us have a look at the bit of code that allows the button action to connect to the level loading:

Even with minimal knowledge of Lua, we can deduce that the nodes of the GUI (containing the four buttons) are being iterated over. But the nodes are selected by name, so we can deduce that the construction…

…will create a string by concatenation called “level_1”, “level_2” etc to pass to the get_node method on the GUI object. We then check that our input press has happened within the button’s box area using the pick_node method, and if so we post the “load_level” message with the number of the level.

I found the tutorial fairly straightforward, with few assumptions and very little chaining (”to do that, you must first do this”) which has given me a good view of both the architecture of Defold and enough of Lua to see that it isn’t too threatening. You can use Defold to create apps for iOS and Android, so go ahead and experiment.

David has been a London-based professional software developer with Oracle Corp. and British Telecom, and a consultant helping teams work in a more agile fashion. He wrote a book on UI design and has been writing technical articles ever since....

Read more from David Eastman