Scrivere con le sillabe - Unity vs Defold post mortem

NOTE: I moved this post mortem/comparison here from the released game list to encourage discussion and feedback without cluttering the original thread (@britzl) .

“Scrivere con le sillabe” is a game to help children learning how to write in Italian. It shows a picture of a word, for example CASA (house in italian) and the user has to tap the syllables CA and SA choosing them among other wrong syllables. Then it starts again with a new word, and so on.

When I chose Defold for this project I did so for the following reasons:
Young but fast evolving game engine.
Focused on 2d.
Concise documentation.
Very nice looking website and forum.
Beginner friendly.

Completing the project with Defold was a pleasant exaperience, and when I had problems the forum was always helpful (thanks britzl in particular!). It has more than 1000 downloads on Play Store, not so bad for a niche game.
After completing this project I decided to give Unity a try, so I made a very similar game “Scrivere con le sillabe 2”, and another non yet published project. At that point I felt more confident with Unity so I decided to spend a few hours to rewrite also “Scrivere con le sillabe”, to better support future updates and improvements.

This is a list of things that I did’t like about Defold during this project:

Intellisense.
In Unity I create an instance of a prefab and assign it to a variable, then Visual Studio Intellisense tells me what methods and properties I can call. Most of the times I don’t even need to look the documentation, because it’s clear what a method or property is for.

Creating instances and communicating with them.
In Unity I create an instance of a prefab and then I call methods or I access properties very easily. In Defold, I need a factory, ask the factory to instance an object, then send it a message, then in that other object I need a handler that receives the message and do something appropriate. The Defold way leads to better programs? I am not convinced, to me it’s a longer process to do the same things.

Readability
This is an example of a piece of code that I hate in my Defold program:
local url = msg.url(“imgparola#sprite”)
msg.post(url, “play_animation”, {id = hash(parola)})
I have a lot of these couples of lines everywhere, they all begin with “local url = msg.url(…” and “msg.post(url…”, but in reality they do very different things. Not only they were harder to write, they are harder to read too.

Script properties can’t be strings, you need to hash them
Why? I come from the early days of C64, when a variable could be a number or a string, and nothing else. I don’t really like to see strings treated as second class citizens.

Click handling
In Unity I simply use OnMouseDown() only where I need it. In Defold input handling is a mess, since all objects receive a click and then it’s their responsability to determine if it was directed to them checking mouse or touch coordinates. I ended up using the module goput.lua (from britzl, if I remember correctly).

Lua
I have previous experience with C#, and I find Lua to be a very limited language. For example in Lua you have only tables as data structures, so in my mind I think at what data structure I would use in C# and then google for a way to implement it with Lua tables.

OOP
If I really had to use Lua, I prefer the approach of Gideros that gives a ready made OOP-like infrastructure.

Debug
I like Visual Studio debugging a lot more than using ZeroBrane

Sound
In Unity I change the mp3 or wav associated to a sound object with a line of code, in Defold I had to create a different sound object for every sound I needed, it was a big waste of time.

10 Likes

Thank you so much for this very candid comparison of Defold and Unity. I’ll answer and comment on a couple of things that come to mind when I read your post:

The Defold API is different in the sense that it operates on data instead of having the data also carry functionality.

local pos = go.get_position([id]) vs local pos = mygameobject.get_position()

This is just the way we’ve decided to design the API. You would still get code completion in the editor for the different API namespaces though.

Yes, in Defold you need a factory component if you need to create game objects at run-time. And we need the factory component with a reference to the game object to easily infer if the game object is in use or not by the game and if it should be included or excluded from the bundle. If the factory component wasn’t required then it would be much harder to infer this through code analysis.

Regarding the message passing: When you create a game object using a factory you can pass it arguments to any go.property() declared properties. This is useful for first time setup. Later on if you need to communicate with the game object then yes, you need to do this through message passing. BUT if you find yourself passing many messages to the game object(s) every frame then perhaps it could be an indication that there is a design issue of some kind and another better approach might be required.

You don’t need to create the URL first. This is enough:

msg.post("imgparola#sprite", "play_animation", {id = hash(parola)})

I can agree with you that this sometimes is very annoying. In general, as you know, string manipulation and comparison is slow and should be avoided, but sometimes it would make sense to pass a string, for instance as a player name or something like that. I’m not sure how difficult it would be to add support for string properties.

The recommended approach is often to have a single or very few input handlers that delegate input to interested parties instead of having many game objects acquire input at the same time. When it comes to click/touch detection and game objects another reasonable solution is to use physics triggers to detect collisions. Like in this example: https://github.com/britzl/publicexamples/tree/master/examples/click_and_drag

Personally I love this simplicity. You can mimic almost any data structure that you need using the Lua tables exactly as they are or with just a few lines of code. Some examples: https://gist.github.com/britzl/001546d7e43ea85d782e894029f03e4b

Lua (and Defold) is not very prescriptive. There are often multiple solutions to a problem and instead of enforcing a specific way of doing things Lua allows you to make the choice. 30log is one OOP solution in Lua and middleclass is another.

I agree. Our current debugger solution is not very good. We need to integrate a debugger in our editor.

We will at some point add support for dynamic loading of sounds, maybe via the buffer API. The reason for the current system is to allow us to very easily figure out which sounds that are used and that we should include in the game and which ones that aren’t used and thus can be omitted.

7 Likes

This is, of course, very nice and convenient. Optimally, you would get completion on the target url and the messages a script component listens to while typing msg.post().

The current design of Defold and the dynamic nature of Lua makes that hard, perhaps even impossible, to achieve. But it’s definitely worth spending time trying to solve for the common cases.

2 Likes

Additional note:

Defold asks the user to do some inial work, like setting up factories and specifying numbers of objects in game settings.

This puts some responsibility on the user up front, which may feel like unnecessary chore, but it has the benefit of relieving the user from a lot of later bookkeeping - and speeds up the builds. In a small project you may not see the benefits but for a larger project you will need to do that bookkeeping (how to use memory, what resources should go into the build etc) at some point. Many (most?) game teams spend considerable time towards the end of the project fitting the game to the target platform and reducing build size. Some of that work is probably unavoidable but we believe it makes great sense to be explicit about those responsibilities and put them up front.

1 Like

Hey there.

I have to confirm what @raffaelet said.
Devoloping in defold isnt very easily. I’ve started my project also in defold and - @britzl and some others know - I really had (and HAVE) problems with it. LUA and the including in defold has a price: Messaging and Hashing for example. A hard thing if you come from a OOP. Always have to send a message and have to receive it and after receiving maybe call a function etc seems to be a worst thing. (Maybe is).
Also hashing. Lot of times I simply need a string (I came from amiga coding @raffaelet - so I am also oldschool). That “hashing-thing” crashes my brain sometimes. Actually I am already stuck at that thing again :frowning: . Using factories drove me really crazy at startup. Lot of things are “laborious”.

Dealing with gui/input is also confusing. Actually I am going crazy with it. disabled gui is already clickable (a mess IMO). Sending messages for clicks is lot of work. having couple of input-handlers (guis and a mouse-GO) also seems to be hard work in debugging and finding problems.

LUA is a simple language. I am new to lua and its a very TRICKY thing with that language. Thinking of the “everything first is a global variable”. You just have the keyword “local” to define right. (Ok, there is also self.). So I went into that shadowing-trap sometimes etc. I also miss tons of easy commands. So lua is a bit strange for me, but I am on it!
But what I really LIKE - and I am impressed of - is tables/maps etc. Hell thats a crazy thing storing any kind of stuff in a list. Thats -IMHO- one of the most great things in lua.

The Defold-Editor is - lets say - really basic. I also know unity. (I’ve started with at game-dev). Unity is much much more easy to deal with. It makes EVERYTHING much easier to handle instead of defold. sorry, but its like that. It helps the dev all the time with drag’n’drop (much faster) etc.

BUT… BUT… @raffaelet

You may ask now: “Hell man, WHY THE FUCK youre at defold ?” :slight_smile:

One simply answer: Its 2D optimized. MUCH more than Unity is!

I am watching unity and lot of unity games and devs for last years now. Unity is growing like hell and is making developing very easy for all newbies (like me).
Tons of games are made in unity and releasing day by day. I am a gamer of cause. Playing couple of unity-games and have to say: Nice to learn, nice to develop - but the result is … everything, but not optimized gaming. You have lags, microlags in nearby EVERY game! I could give you couple of examples!

Unity is nice for 3D, but worst for 2D!
And THATS why I chose defold (and getting mad with lua and defold every week :))

Need an example?
f.e. there is “Streets of rogue” (steam). A very funny and easy and fast 2D game. Top viewer. Nice game - nice idea and funny to play. Easy graphics. Microlags. Every few minutes the game “stucks” for a moment. The moment you die :slight_smile:
Exactly this you can see in lot of unity games - so this isnt bad coding.

Next, Unity is 3D - not 2D. So the base is 3D, which makes the engine and the power needed a mess. Most of the unity games for mobile phones sucks your battery. Youre phone gets hot and needs wast of energy.

The defold-games I’ve tried… easy going for the phone. No battery spattering and my phone dont transform into a “hand-warmer”.

So, yes. Defold is not as easy as unity to deal with and lua is not easy as well. Defold is new and at develop and has to become more easy. But its the right way of having “hardware-friendy builds”. Building and testing is pretty fast and you have GIT support whitch gives you some more possibilities :slight_smile:

Its hard -IMO- but I am already on it (but sometimes really frustrated) :wink:

6 Likes

I think this problem could be alleviated with some editor conveniences. For example if you could drag-and-drop multiple sound files into the outline and have them automatically converted to sound components.


A lot of people seem to expect this feature, even though it requires quite a bit of code behind the scenes, plus collision shapes and data about the active camera/renderer. Maybe using external libraries should be emphasized in the docs somehow. I think marketing Defold as “a turn-key solution, providing everything you need to build a game.” is . . . well, it might give people too high expectations. :stuck_out_tongue: I guess when Sticky Iron comes out it will be easier to find libraries to do this kind of stuff for you (and may encourage more people to share them in the first place).

2 Likes