Defold engine code overview
defold.com
defold.com
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.
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!
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.
should have screenshots not artwork. All the artwork tells me is that they employ someone who can draw. I don't care about that.
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.
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.
* 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.
- 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.
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:
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"
I also like the fact that the editor is implemented in Clojure, quite a nice showcase for Clojure.
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.
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.
To summarize, you basically can't use the built-in viewport scaling at all because it breaks mouse input.
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.
> 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.
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.
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.
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...
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.
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.
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.
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.
If I misinterpreted your meaning then I apologise.