Is Defold a good choice for an economic strategy game with idle/incremental mechanics?

Questions
#1

Hey there,

Nice to meet you all. I’m looking into a game engine to help me grow my dev game hobby from a dream to reality. I know, I know, it sounds a bit corny but there’s a dream behind any meaningful endeavor isn’t it?

Other than Defold, I’ve been looking into GameMaker Studio 2, Godot and Unity – the usual suspects. I work on a MacBook Pro and the GM IDE and runner have terrible performance. Godot seems a bit disorganized, documentation is hit and miss and you can tell it’s put together by developers who are focused on code first, and user experience second. Unity… Well, we all know it’s a beast and although everyone seems to recommend it as an eaay choice for beginners I just don’t see it. C# looks daunting.

I’m a web designer and developer by trade, so I’m no stranger to code – but I do look for a different experience than the one at work. So less curly braces would be nice.

This should hopefully give you a bit of an insight into my background and what I look for (and don’t) in an engine. From what I’ve seen so far, here’s what draws me to Defold:

  • Clean, simple UI
  • Great docs, good examples – you can tell it’s a work of love, not just the minimum effort (see Godot)
  • From what I gather, deployment should be super straight forward
  • By far the most mature and smart community. It just feels like a good, healthy place of like-minded people I want to be a part of.

These aside, I’m thinking the game I have in mind is pretty UI heavy and Defold seems to lack in this department. How’s this messaging system supposed to work? Is it somewhat similar to Godot’s signal? And what about the game objects? Are they similar to Unity’s in that you attach various components in an ECS kind of programming? Is there something similar to scriptable objects, or how might I go about working with data? I’ve read something about Lua having these tables instead of arrays?

I’m looking for personal experiences and insights to help me draw a picture of what working with Defold feels like. At the end of the day, I care more about the coding experience than speed. I’m in no hurry to launch anything, I’m just looking for a ride I can enjoy in my little spare time.

Thank you for being with me in this long (first) post.

2 Likes
#2

The Defold gui system is indeed based on low level building blocks, but that is intentional. We do not wish to decide for the developer how a button, checkbox or scroll list should be implemented. These things are more high level than what we target with the GUI system and we believe it is better if we let the developers decide those things.

Here are two libraries with support for buttons, checkboxes, scrolling lists etc:

Druid GUI library: https://defold.com/assets/druid/
Gooey GUI library: https://defold.com/assets/gooey/

And a great looking and UI heavy game: Zoo Economy (Strategy-puzzle)

Game objects are the basic building blocks of a Defold game. They have a unique id and a transform (position, rotation and scale) in 3D. You build behavior and complexity through components which you attach to your game objects when you design them in the editor. There are many different components: sprite, particle fx, model, physics sound, script etc (check the manuals for a full list)

The messaging system is an integral part of Defold. The physics engine sends collision messages to your physics components and you can use your script component to react to the messages. You can get a message (or callback if you prefer) when a sound component has finished playing a sound or when the flipbook animation of a sprite has finished.

You can also send your own game specific messages between game objects from your scripts. Examples:

  • The player script sends a “game_over” message to a game controller script when the player health reaches 0
  • The player script sends a “coin collected” message to the in-game UI script to increase the coin counter

You attach scripts to game objects to build your logic. You can also reuse logic in Lua modules which you can require from multiple scripts.

Yes, Lua has a single data structure, the table. And it is great. Here’s an array:

local list = { "tables", "are", "great" }
print(#list) -- 3
print(list[2]) -- are (yes, tables are 1-indexed!

And here’s a map/dictionary:

local enemies = {
    orc = { hp = 5, damage = 4},
    goblin  = { hp = 3, damage = 2},
}
print(enemies.orc.hp) -- 5

We have some interviews with Defold developers on our blog (search for Creator Spotlight):

5 Likes
#3

Thank you @britzl. After seeing you jumping in every time Defold gets mentioned somewhere, I was anticipating your reply :nerd_face:

Regarding the table structure. Let’s say I have several towns, and each town produces and sells different goods. Would I create a town script that I can then attach from the editor to each unique town object? Or do I have to create several scripts, with their own table, one for every town object?

I would very much like to hear more opinions as well – maybe some from other hobbyist.

2 Likes
#4

Yeah, I’m starting to get synonymous with Defold for better and for worse :slight_smile:

It depends :slight_smile: Boring answer, I know! Are you selecting towns from a listor do they exist on a map which you can scroll around on and where you can click on the different towns?

But I think I would put the Lua table data about each town in a single table structure, keyed on something like town id. I would probably keep the data in a Lua module and then look up the data for a specific town using the id of the town. The id could be the unique game object id or a specific script property used for that purpose.

3 Likes
#5

@Pkeod, @dapetcu21, @russelkgd, @benjames171 and many others can probably share their views.

2 Likes
#6

Looks like a classic database approach, the difference being the data is only stored in memory, correct? How would I go next to make it permanent? Json files?

#7

I tend to use Google Docs exported to .csv files for config files, and Defold’s sys.save() for save data. It uses tables straight up, which is very handy.

2 Likes
#8

I have zoos on map, each zoo is game object with same script attached to it. They have an unique id and i use it to look up for any values: animals in zoo, is this zoo is marked, status etc.

I can easily see that each of your tower is a game object with one common script. And you can store goods values, prices etc in each of them. If you often need to check these values it’s probably better to store if differently (in lua module), because if you use messaging system to ask for prices from all your towers, for example, it has limited data size and you won’t be able to send big table over it.

For static data/configs i use json.

4 Likes
#9

Thank you @russelkgd. You gave me some food for thought. I’m going to try a few things and see how I can manage to wrap my head around this. About your UI, did you code everything from scratch or used some kind of assets? Would you say it was a good experience building your UI with Defold?

@britzl’s idea is interesting too. I can see a towns table keeping all the data, and querying what I need by an ID, SQL style.

Are there any prefabs-like structures? Going back to my example how would I make a town entity/object that I can use as a template (to instanciate?) to make other towns?

Good stuff here! Much appreciated.

1 Like
#10

I use Dirty Larry for scrolling and checkboxes, everything else was coded from scratch. But Druid and Gooey is newer than Dirty Larry so it’s probably better to try them. I just don’t have time/will to change to one of them)

Gui in Defold is very powerful, you can build whole game on it. And I mostly didn’t have any problems with it. If i would need to select engine to work with heavy UI i would choose Defold from Unity or Unreal. But it is subject to game genre.

You can create game object (prefab similar to Unity’s prefab) and use factory to create several instances of it. Basically this is exactly what i’m doing. When map is loaded, I’m looping through my zoos list and using factory to create and place them on map. In initial factory call you can pass position, rotation, scale and additional arguments like unique id.

5 Likes
#11

We made Interrogation, which is mostly just UI. We’re also working on Domains of Dusk, which is a strategy game with even more UI (apart from the map, everything is GUI). We use our own GUI widgets library Crit. It has inertial scrolling and a really powerful button module amongst other stuff. The downside is that it isn’t really that well documented. Docs are still a work in progress and not yet very high-priority since effectively two people use it so far.

4 Likes
#12

Thanks @dapetcu21, will grab Interogation and I look forward to learn more about Domains of Dusk – graphics look superior to me.

And @russelkgd that’s very helpful! I appreciate your time. I’d try to do things from scratch as a learning opportunity. Speed is not my priority right now, so much as is learning the ropes.

2 Likes
#13

These are all made with Defold, we have more on the way, and have no plans to use anything other than Defold. We focus mostly on more casual games. If there is anything in our games you want to know how was done I’m happy to share.

You can make games entirely from Defold’s GUI systems which you may appreciate. You can automate build making with bob+scripting so you can 1 click make and deploy all platforms if you set up scripts for that.

For general messaging I like using https://github.com/britzl/ludobits/blob/master/ludobits/m/broadcast.md currently.

Other than getting opinions from users here who are already convinced, you’ll need to put time into learning and experiencing making a project with Defold to know if it’s right for you. There are great games made with all of the other tools you mentioned, but they also all have their own pros and cons be it $ or binary weight or lack of freedom.

8 Likes
#14

@Pkeod Amazing reply. Talking about mature and smart community…

As I’m playing around with Defold, I will happily take you up on your generous offer. Currently I’m trying to fire up a basic GUI container tied to a button click and other than the box and label components I don’t see much else in the way of doing it. Am I correct that clicking on a button requires reading mouse input, getting the mouse coordinates, and applying all of this on a script attached to a go?

In any event, I plan to dig a little bit deeper by myself so I can avoid asking for help on stuff that’s already documented. So far, things are really different coming in from trying all the 3 engines i.e. messages look a bit like Godot’s signals, components a bit like Unity’s – but none of it is actually that similar. Or that’s my initial impression.

3 Likes
#15

Yes, more or less. A button is likely built as part of a gui component and gui components have a *.gui_script with access to the functions from the gui.* namespace of functions to manipulate gui nodes.

Normal scripts (*.script) files have access to the function from the go.* namespace of functions to manipulate game objects and their components.

A button example:

2 Likes
#16

Ultimately I think with the freedom that Defold gives you, how you decide to structure that is up to you as the gameobjects and components are not as predefined as in other game engines that aim to encourage you to use certain types of design patterns over others.

For this specific problem, my own first thoughts on a solution might be to have different towns as different gameobjects but each containing the same script which holds a hash property for which town it is, and then have self.town = module.town_function() create a unique reference to a function in which the property is passed as an argument, which will be used for any necessary dynamic variables or logic based on the property. This allows for some different methods of communication with the town itself through the the unique function that self.town references as well as through the module, which would be nice if it made sense for other moving parts of my game to have access to the kind of data I could reasonably exchange through those channels.

However, someone with a different set of considerations and assumptions might have an entirely different solution than mine, using gameobjects, components, and modules, etc. in a completely different way. This is what I think is great about Defold, as opposed to Godot where the “who’s who” in terms of the building blocks is more defined and makes it at least a little more about “what part of Godot best solves this problem for me” instead of “what kind of solutions can I engineer to solve this problem.”

At least, that’s how I see it - someone smarter and more experienced might say otherwise.

6 Likes
#17

Thank you for your thorough reply. I think it might actually be Defold’s freedom that keeps me on the fence. In this day and age, when so much technology around us tries to improve the quality of our lives, I’m not sure I can appreciate learning game dev with such a barebones tool. To draw some similarities to my field of work (web dev), it’s like building websites without Bootstrap, in a world where Bootstrap exists. It can be done, but why?

I gave it a shot with towns as gameobjects and script properties. However, the options are limited to plain text fields. With Godot’s Resources or Unity’s ScriptableObjects one can add description fields, input ranges or dropdowns (as enums). Using the editor to add content (e.g. quests, items, all kinds of objects) is, to me at least, a better user experience than doing everything from code. Again, it can be done – but why, if there are simpler ways?

I get that Defold’s way is to have a minimum feature set built it that can be expanded through a good deal of external scripts – however, I miss the point where such extensions, most of them created by Defold’s developers themselves, are not part of the engine. If keeping its footprint small is one reason, then why not add some sort of package manager with ‘official’ or ‘supported’ or otherwise external libraries I know I can trust to work through years of updates?

tl;dr; The best experience Defold gave me in my brief time with it was its community. Hats off to all of you. If you’d gather all of your wisdom in some sort of Defold Recipes ebook/site, I think that would help a lot of newcomers – people like me, who are trying Defold along other engines (with not necessarily more features, but more quality of life out of the box). As for me, I’ll stick around for the community but focus my learning towards Godot.

#18

@Pkeod was working on something like that: Book of Defold, though it hasn’t been updated in some time.

1 Like
#19

And thank you for the great feedback! Best of luck with your project!

2 Likes
#20

I’ve been wanting to restart it now that I’ve released a few full games made with Defold since then and have a much stronger mastery of making games with Defold. The vision I have for it now is closer to a recipes list of useful game development concepts with Defold since originally it was meant to compliment the official docs, but the official docs have long since been improved (and some stuff from the project was put into the official docs) and are more complete.

So I’ll probably cut all of the reference stuff out, and instead make it focus on projects/tutorials. I’ll have time after my next game is fully released hopefully.

7 Likes