Defold engine code overview(defold.com)
defold.com
Defold engine code overview
https://defold.com/2020/12/27/engine-overview-pt1/
45 comments
> Why HTTP/S sockets rather than raw UDP
Because Defold targets mobile mostly and https/websockets does better at working with corporate firewalls and VPNs.
Also mobile games typically aren't as latency-sensitive as real-time desktop games since they often have to work over slow/unreliable wireless cell networks.
Because Defold targets mobile mostly and https/websockets does better at working with corporate firewalls and VPNs.
Also mobile games typically aren't as latency-sensitive as real-time desktop games since they often have to work over slow/unreliable wireless cell networks.
Hi! Defold Foundation member here.
1. The first lines of Defold code were written more than 10 years ago and at that time Cap'n'Proto and Flatbuffers didn't exist. One could argue that we should change to a newer format, but for our purposes protobuf still works really well.
2. Defold uses LuaSockets to make TCP and UDP sockets available to developers through our Lua API. And we also make TCP sockets available to our C extension system.
3. The next big task which we will start the new year with is a full review of our texture compression formats. Basis Universal is on our list of formats to investigate.
4. While we do support import of basic 3D models our focus has been mainly on 2D content. We are currently negotiating funding for improved 3D support in a work package for 2021. If all goes well you can expect some major improvements in this area.
Feel free to ask more questions!
1. The first lines of Defold code were written more than 10 years ago and at that time Cap'n'Proto and Flatbuffers didn't exist. One could argue that we should change to a newer format, but for our purposes protobuf still works really well.
2. Defold uses LuaSockets to make TCP and UDP sockets available to developers through our Lua API. And we also make TCP sockets available to our C extension system.
3. The next big task which we will start the new year with is a full review of our texture compression formats. Basis Universal is on our list of formats to investigate.
4. While we do support import of basic 3D models our focus has been mainly on 2D content. We are currently negotiating funding for improved 3D support in a work package for 2021. If all goes well you can expect some major improvements in this area.
Feel free to ask more questions!
I feel strongly this page: https://defold.com/showcase/
should have screenshots not artwork. All the artwork tells me is that they employ someone who can draw. I don't care about that.
should have screenshots not artwork. All the artwork tells me is that they employ someone who can draw. I don't care about that.
Screenshots are not going to tell you anything more. You should go get the game from the app store and see them running.
Of course they are going to tell me something more. They will tell me what the actual game looks like.
...Which will only tell you that they employ someone who can draw. Which you don't care about.
Great feedback! Thanks. You should be able to click on any of the games to get to a store page or similar where you can see screenshots of each game.
That's missing the point. I first have to decide whether I want to click on one and if so which one I want to click on.
The illustrations don't help me decide. They don't even particularly encourage me to click.
I'm sure if you came to it cold you'd see what I mean. Great illustrations aren't a rare commodity on the web - people want to know what the actual game will look like.
The illustrations don't help me decide. They don't even particularly encourage me to click.
I'm sure if you came to it cold you'd see what I mean. Great illustrations aren't a rare commodity on the web - people want to know what the actual game will look like.
Sure, I get what you are saying, and yes, perhaps we should also include screenshots. I'll see what we can do.
But keep in mind that the showcase page isn't there to sell the games. It is there to show that professional games have been released using Defold. And to show to that you can be productive and release games when you use Defold. Screenshots or illustrations does not matter in this case. Neither says anything about the quality of the engine. And we opted for illustrations as that works better on a showcase page.
But keep in mind that the showcase page isn't there to sell the games. It is there to show that professional games have been released using Defold. And to show to that you can be productive and release games when you use Defold. Screenshots or illustrations does not matter in this case. Neither says anything about the quality of the engine. And we opted for illustrations as that works better on a showcase page.
I get your position, but I also expected that "showcase" was going to be showcasing your engine or at least features of your engine.
This is a very good point! Looking at our top menu items again I can see how it looks for a new visitor.
* Product (https://defold.com/product/) lists engine features. This should probably be renamed Features.
* Showcase (https://defold.com/showcase/) shows games made with Defold. It is not so much a showcase for specific engine features but rather a showcase of different kinds of games that has been made with Defold. Perhaps we should rename it to Games.
As a side-note regarding games: We will start posting developer case-studies in a few weeks. These case-studies will show both the games and the features of the engine as well as clever solutions to problems and how Defold has helped the creators while developing their games.
* Product (https://defold.com/product/) lists engine features. This should probably be renamed Features.
* Showcase (https://defold.com/showcase/) shows games made with Defold. It is not so much a showcase for specific engine features but rather a showcase of different kinds of games that has been made with Defold. Perhaps we should rename it to Games.
As a side-note regarding games: We will start posting developer case-studies in a few weeks. These case-studies will show both the games and the features of the engine as well as clever solutions to problems and how Defold has helped the creators while developing their games.
to each their own. i personally like direction they took. it's minimal and gives more of a teaser. like a movie poster or game box art. I'd find adding screenshots everywhere is a little too much towards a specific niche detail
There are a few other serious options for Lua game engines/frameworks worth mentioning when Defold comes up:
- Love2D : https://love2d.org/
- Solard2D : (previously corona sdk): https://solar2d.com/
I would really like to read a good comparison between the three one day.
- Love2D : https://love2d.org/
- Solard2D : (previously corona sdk): https://solar2d.com/
I would really like to read a good comparison between the three one day.
Perhaps ask Mike from GamesFromScratch to do a comparison video?
One thing that will differ between the engines is the number of support platforms.
But apart from that I believe there are many similarities. Most engines today have long lists of features and they are all quite powerful. But something that usually isn't immediately obvious from a feature list is how it is to work with the engine and tools day in and day out while developing games. What are the pain-points and what are the time-savers of each engine?
We list a few things Defold does really well here:
https://defold.com/why/
One thing that will differ between the engines is the number of support platforms.
But apart from that I believe there are many similarities. Most engines today have long lists of features and they are all quite powerful. But something that usually isn't immediately obvious from a feature list is how it is to work with the engine and tools day in and day out while developing games. What are the pain-points and what are the time-savers of each engine?
We list a few things Defold does really well here:
https://defold.com/why/
As a side note and credit to the parent author I really appreciated the work you did and helper libraries you provided (it helped me learn a lot about some of the greater functionality that the defold engine provided. I also think the choices made for this engine were under appreciated at the time (and still are given its lack of notoriety) I thought Kings move to give it a much more liberal licence might have put it in a place competitively (for 2d at least) to Godot, but I guess their momentum and ambition overshadow the great work everyone who has worked on defold (and surrounding communities has done) - not to say godot isn’t an amazing accomplishment in its own right (which it is and their ide alone a testament to the quality of craftsmanship)
I've always enjoyed Lua. Does anyone have any experience with Defold? I'd like to make a little puzzle game, but I don't have dozens/hundreds of hours to learn Unity or a big fancy engine. Is Defold learnable enough for someone to make a game on the weekends over the course of a few months?
Here's a forum thread created by a relatively new Defold user documenting part of the process from prototype to finished game: https://forum.defold.com/t/apple-spider-casual-arcade-action...
Another from a more experienced team, but new to Defold:
https://forum.defold.com/t/travel-blast-by-mpgames/66089?u=b...
"Low entry level compared to Unity. Lua is easy to learn programming language. One of our UI designers became Defold developer in a month"
Another from a more experienced team, but new to Defold:
https://forum.defold.com/t/travel-blast-by-mpgames/66089?u=b...
"Low entry level compared to Unity. Lua is easy to learn programming language. One of our UI designers became Defold developer in a month"
Personally I'd look at https://love2d.org/ if the game is 2D. It's a much more manageable scale for very small teams.
I love love2d. But one thing to take notice of when comparing, is that love2d is a game engine. Defolds ships game engine and IDE.
You can get in touch with Defold users here: https://forum.defold.com/
Defold looks pretty nice if you're looking to make more simplistic games. I wish it could target Playstation and Xbox as well though. But I heard its tools are really nice to work with.
I also like the fact that the editor is implemented in Clojure, quite a nice showcase for Clojure.
I also like the fact that the editor is implemented in Clojure, quite a nice showcase for Clojure.
We are actively investigating additional console support (we only support Nintendo Switch) in 2021. Follow us on Twitter (https://twitter.com/defold) to not miss any annoucements!
Anyone give a comparison between Defold and Godot [1]?
[1] https://godotengine.org
[1] https://godotengine.org
One point to consider: Godot is FOSS, but Defold is only visible-source.
Seems more nuanced then that. You can use Defold to make commercial games for free. You can even extend and modify Defold and use your modified version to make commercial games for free too from what I understand.
And you can also change and modify Defold and distribute your changes and modifications to others, but you can't do so commercially. That said, I think others could still use your modified Defold to make commercial games, just you can't take any money for it.
So it seems to be much more than just visible source. Basically the only thing it doesn't allow is for you to commercialize the Defold engine or some derivative engine based on it. Everything else seems allowed.
Caveat: I am not a lawyer.
And you can also change and modify Defold and distribute your changes and modifications to others, but you can't do so commercially. That said, I think others could still use your modified Defold to make commercial games, just you can't take any money for it.
So it seems to be much more than just visible source. Basically the only thing it doesn't allow is for you to commercialize the Defold engine or some derivative engine based on it. Everything else seems allowed.
Caveat: I am not a lawyer.
I feel like saying "more nuanced" is misleading. It doesn't change the answer to "is it FOSS?" from "no" to "maybe", but rather to "no, but...". Defold's license unambiguously does not comply with either the Free Software Definition or the Open Source Definition.
Completely true. Defold is not FOSS. And we do not claim that it is.
We initially said that Defold was open source when we actually should have said source available. And we got an unbelievable amount of flak for it! I even received a very disturbing message sent to my private email from a FOSS "champion". And the president of the OSI got in touch as well.
More here: https://defold.com/2020/05/20/Some-thoughts-on-the-open-sour...
We initially said that Defold was open source when we actually should have said source available. And we got an unbelievable amount of flak for it! I even received a very disturbing message sent to my private email from a FOSS "champion". And the president of the OSI got in touch as well.
More here: https://defold.com/2020/05/20/Some-thoughts-on-the-open-sour...
I was referring to the "visible source" comment. The Defold license allows much more than just seeing the source.
And I do think the way I've seen people almost "warning" others that Defold isn't "open source" is misleading to most game developer. Unless you plan to sell a commercial game engine and editor and want it to be based of the Defold source code, then you've got access to all the same pros/cons of any other true (based on OSi) open source game engine and editor.
At the end of the day that's what I care about if I'm picking a game engine for my game.
And I do think the way I've seen people almost "warning" others that Defold isn't "open source" is misleading to most game developer. Unless you plan to sell a commercial game engine and editor and want it to be based of the Defold source code, then you've got access to all the same pros/cons of any other true (based on OSi) open source game engine and editor.
At the end of the day that's what I care about if I'm picking a game engine for my game.
It's a little bit of a strawman on your end. What you imagine to be the intention/argument on the other end isn't the one intended, so a comment like this one ends up dismissing the real issues brought up by people pointing out it's not FOSS.
There is no shortage of discussion these days about independent devs feeling suckered into doing free support for corporations by way of FOSS. At least in that situation those programmers get some form of equity out of the bargain, given the terms of the actually-FOSS licenses. In the case of Defold, they've taken the Apache license and changed it to diminish even that in a way that's directly meant to benefit Defold. There's also the matter of people just not wanting companies to be able to reap undue rewards out of association with FOSS if they're not actually doing FOSS.
It's honestly not a reaction that should be considered surprising. Want to hawk your wares as FOSS? Okay, FOSS licenses exist. Want to take one of those licenses and then alter it in such a way that it's no longer FOSS? Okay, then don't call it FOSS. It's a pretty fair deal.
There is no shortage of discussion these days about independent devs feeling suckered into doing free support for corporations by way of FOSS. At least in that situation those programmers get some form of equity out of the bargain, given the terms of the actually-FOSS licenses. In the case of Defold, they've taken the Apache license and changed it to diminish even that in a way that's directly meant to benefit Defold. There's also the matter of people just not wanting companies to be able to reap undue rewards out of association with FOSS if they're not actually doing FOSS.
It's honestly not a reaction that should be considered surprising. Want to hawk your wares as FOSS? Okay, FOSS licenses exist. Want to take one of those licenses and then alter it in such a way that it's no longer FOSS? Okay, then don't call it FOSS. It's a pretty fair deal.
The Defold Foundation does not call Defold FOSS. PERIOD. Stop saying that we do.
Next: The Defold Foundation is a foundation, not a corporation, and it is registered in Stockholm, Sweden. It has a different legal status than a corporation and while it is allowed to make a profit there are no stock holders or owners that can profit from the earnings.
Also, as a foundation, it has a clear set of goals that cannot be altered:
1. Make the Defold software available to the public.
2. Make the Defold source code available free of charge to a third-party.
3. Manage the Defold software through updates, modifications, development and support.
4. Prevent the Defold software from being commercialised by a third-party.
5. Support the open source community and the use of open licenses.
The reason we had to modify the Apache 2.0 license to add non-commercialization of the engine+editor was to fulfil goal #4.
You might now think that it's pretty stupid to use a modified license since goal #5 says "support the use of open licenses". I agree. I would have preferred an unmodified OS license for the main repo. BUT the Defold Foundation also maintain ~60 other open source repositories, most of them with an MIT License. 32 of these are Defold game engine extensions to interface with things such as In-App Purchases, Analytics, Ads, Camera etc.
Finally I want to say that we are not interested in "independent devs feeling suckered into doing free support". We obviously accept and appreciate contributions, but it is not our goal to make Defold into an engine which relies purely on community contributions to thrive. Defold depends on corporate sponsorships for long-term sustainability, not community contributions. And if we see prominent contributions coming from individuals we are very open to properly compensating said individuals from the funds of the foundation.
Next: The Defold Foundation is a foundation, not a corporation, and it is registered in Stockholm, Sweden. It has a different legal status than a corporation and while it is allowed to make a profit there are no stock holders or owners that can profit from the earnings.
Also, as a foundation, it has a clear set of goals that cannot be altered:
1. Make the Defold software available to the public.
2. Make the Defold source code available free of charge to a third-party.
3. Manage the Defold software through updates, modifications, development and support.
4. Prevent the Defold software from being commercialised by a third-party.
5. Support the open source community and the use of open licenses.
The reason we had to modify the Apache 2.0 license to add non-commercialization of the engine+editor was to fulfil goal #4.
You might now think that it's pretty stupid to use a modified license since goal #5 says "support the use of open licenses". I agree. I would have preferred an unmodified OS license for the main repo. BUT the Defold Foundation also maintain ~60 other open source repositories, most of them with an MIT License. 32 of these are Defold game engine extensions to interface with things such as In-App Purchases, Analytics, Ads, Camera etc.
Finally I want to say that we are not interested in "independent devs feeling suckered into doing free support". We obviously accept and appreciate contributions, but it is not our goal to make Defold into an engine which relies purely on community contributions to thrive. Defold depends on corporate sponsorships for long-term sustainability, not community contributions. And if we see prominent contributions coming from individuals we are very open to properly compensating said individuals from the funds of the foundation.
> The Defold Foundation does not call Defold FOSS. PERIOD. Stop saying that we do.
How about instead of telling me to stop doing something, you point to the place where I ever did? It's ridiculous that you responded to my comment complaining about strawmanning with... another (even worse) instance of it.
There are so many misdirected arguments in this comments that it doesn't even make sense to try responding to them.
How about instead of telling me to stop doing something, you point to the place where I ever did? It's ridiculous that you responded to my comment complaining about strawmanning with... another (even worse) instance of it.
There are so many misdirected arguments in this comments that it doesn't even make sense to try responding to them.
I'm sorry, but your entire post sure sounded like you are upset with Defold claiming the product to be FOSS when in fact we do nothing of the sort.
If I misinterpreted your meaning then I apologise.
If I misinterpreted your meaning then I apologise.
Defold is a great commercial engine used to ship real games, but has its own license "derived" from Apache 2.0. You'll have to understand it before building on the engine.
Godot is a hobby engine with a standard MIT license, but with some major issues that make it unusable for any serious work. I worked with it for 3 months at the end of last year, but had to abandon the project after logging a few serious bugs in the issue tracker.
Godot is a hobby engine with a standard MIT license, but with some major issues that make it unusable for any serious work. I worked with it for 3 months at the end of last year, but had to abandon the project after logging a few serious bugs in the issue tracker.
Thanks! Can you give a bit of detail about the bugs you ran into?
If you save a reference to a game object in the scripting language, then if the object is removed from the scene by another system, the object pooling system will re-use the old object resulting in your script holding a reference to the wrong object! Will not be fixed to version 4.
Example, I was building a tower defense game and each tower would hold a reference to the enemy they were shooting at. When the enemy took damaged and died it was removed from the scene. The towers reference to the enemy would sometimes point to some new random object in the scene. There are workarounds, but wtf.
There is also some cyclic reference bug in the scripting language that is impossible to predict or work around.
And then there are little things, like there is no selection outline around objects in the scene, makes it almost impassible to build a complex scene. Not a bug, but a weird choice.
Example, I was building a tower defense game and each tower would hold a reference to the enemy they were shooting at. When the enemy took damaged and died it was removed from the scene. The towers reference to the enemy would sometimes point to some new random object in the scene. There are workarounds, but wtf.
There is also some cyclic reference bug in the scripting language that is impossible to predict or work around.
And then there are little things, like there is no selection outline around objects in the scene, makes it almost impassible to build a complex scene. Not a bug, but a weird choice.
This is a pretty maddening bug that I ran into: https://github.com/godotengine/godot/issues/30215
To summarize, you basically can't use the built-in viewport scaling at all because it breaks mouse input.
To summarize, you basically can't use the built-in viewport scaling at all because it breaks mouse input.
The Defold license: https://defold.com/license/
The only thing you can't do is sell Defold itself (ie the engine and editor). You can commercialise your games in any way you want and you can modify the engine and editor without having to share your modifications.
The only thing you can't do is sell Defold itself (ie the engine and editor). You can commercialise your games in any way you want and you can modify the engine and editor without having to share your modifications.
Interesting, my experience is the reverse.
I shipped a 3D game with Godot on Steam this year and it's been pretty smooth sailing.
I wasn't impressed with defold, both editor and ecosystem.
I shipped a 3D game with Godot on Steam this year and it's been pretty smooth sailing.
I wasn't impressed with defold, both editor and ecosystem.
I'm with you on this. I tried Defold for prototyping a game concept and was less than impressed. It got in the way in a framework sense, and didnt seem to provide much bang for buck (ie it consume more hours of my time learning its perculiar ways of doing things than it probably have taken to roll my own). Of course peoples mileage may vary. I was expecting things like auto atlassing, batch processing on import, proper layer z-order (versus using a 3d style z value). I recall the UI did weird stuff like sorting alphabetically, instead of by creation order or z-order. The message passing thing was annoying. I guess it was a bad choice for me. I'm probably more productive with a library and tools approach, rather than "opinionated" engine. It felt like someone was caught up in an architecture more suited to creating very large games and applied it here. It felt like it was created by too many programmers working to a feature list, rather than creating a useful cohesive tool.
Defold is definitely not for everyone and not for all kinds of games. Defold is better at 2D than 3D for instance. But it is a 3D engine so it will sort everything on z-value.
> It felt like someone was caught up in an architecture more suited to creating very large games and applied it here.
Defold is supposed to be the exact opposite. The two initial creators of Defold worked at a big AAA developer and with Defold they wanted something different from their day-to-day experience working on huge console games. They wanted a small and performant engine with quick turnaround time on changes.
This is why it is somewhat opinionated regarding certain things. To avoid some of the costly things that usually comes with huge productions and big complex engines.
It is also why you can usually build and bundle your game in seconds to any platform without any setup.
It is the reason why you can hot reload your changes into a running game to further reduce iteration time.
> It felt like someone was caught up in an architecture more suited to creating very large games and applied it here.
Defold is supposed to be the exact opposite. The two initial creators of Defold worked at a big AAA developer and with Defold they wanted something different from their day-to-day experience working on huge console games. They wanted a small and performant engine with quick turnaround time on changes.
This is why it is somewhat opinionated regarding certain things. To avoid some of the costly things that usually comes with huge productions and big complex engines.
It is also why you can usually build and bundle your game in seconds to any platform without any setup.
It is the reason why you can hot reload your changes into a running game to further reduce iteration time.
AFAIK King is moving everything to Unity, so they have dumped their proprietary engine on github.
King still has one internal engine used in most of their franchise titles (Candy Crush, Farm etc). Defold was used internally for several years, but the major adoption was seen outside of King, so it made a lot of sense to make Defold completely independent of King earlier this year.
I have a couple of random questions, in case someone who knows the answers sees this:
1. Why protobuf and not Cap'n'Proto or Flatbuffers? Last I checked, both were better at zero-copy decoding, which might be a big deal for an engine with a message-passing architecture. Cap'n'Proto has had a lot of improvements for RPC use over the past few years.
2. Why HTTP/S rather than UDP? Both in terms of throughput and latency, UDP tends to come out ahead. Was it just not an issue?
3. Why WebP for compressed textures rather than KTX2, which offers BasisU supercompression? Doing so can get similar compression and greatly improve performance when decoding to GPU formats.
4. Any plans to support GLTF2? It has potential to replace custom engine formats, at least those that don't store data for easier GPU consumption, especially if used with meshopt. Unless the Defold format stores data in a GPU-ready format, it might be a good future option, and doing so would simplify asset pipelines a bit.