Didn’t see the links where GitHub problem pages. Posted again with corrected links. Sorry for the mistake.
So, I also added this one :
i missed the forum because i don’t regularly check the site for posts.
by far, the biggest pain point is how much the engine relies on extensions for common enough things.
audio effects. setting fullscreen. setting window title. locking and hiding the cursor. markup on text. lighting.
i’m sure there’s many other things that i’ve forgotten that others would like, too.
it’s just kind of annoying to either have to manually implement features, or go through the hassle of getting an extension for something that feels like it should just ship with the engine as-is, and i imagine it’s a big turn-off for people wanting to try out the engine. it makes it feel very incomplete.
and the biggest insult to injury is that a lot of those extensions are made by people on the defold team, so it’s really confusing to me. if the extension is so good, why not just… make it part of the engine?
but also not being able to use go functions in gui scripts. it can be frustrating when you want to attach a UI to an entity and can’t just use go.get_position on it, and instead have to store the position separately. quite inefficient. it feels like a very arbitrary limitation.
but for the record, i think that having a distinct GUI and GO system is beneficial, since it marks the boundary between working with screen space and world space.
2 Likes
Here’s why:
| PLATFORM | DEFOLD 1.10.4 | UNITY 6 (6000.0.23f1) | GODOT 4.3 |
|---|---|---|---|
| Android (arm64-v8a) | 1.97MB | 24.33MB | 24.29MB |
| iOS (arm64) | 1.47MB | 18.03MB | 19.59MB |
| HTML5 (wasm, gzip) | 1.14MB | 8.1MB | 9.0MB |
| Windows | 2.88MB | 91.1MB | 84.1MB |
Test made using an empty project. Exported to target platform using default settings. Release builds. The iOS, Android and Windows numbers represent the size on disk while the HTML5 number is uncached download size when gzipped. No optimizations. Release mode.
Can you be more specific?
I believe these will be added on desktop platforms as part of the window.* functions. We “recently” added window.set_size() for instance. And setting the title is already possible:
One VERY strong argument for having them as extensions, besides a small engine core, is the fact that the extension system encourages user contributions. It is orders of magnitude easier for anyone in the community to contribute an improvement to an extension compared to the engine. Contributions to extensions do not require you to install any additional SDKs or tools, while a contribution to the engine requires you to install SDKs and tools.
10 Likes
Test made using an empty project.
using an empty project as a comparison point isn’t that good considering that graphics, sound, code, and other assets are going to take that up a significant amount of space in comparison to that.
not to mention that 84MB is peanuts on desktop. and even considering mobile and web constraints, every executable has a smaller footprint for those platforms and again, game assets take up space too
by audio effects i mean things like doppler, reverb, that kind of stuff. i’m not saying we need full on Nyquist plugins a la audacity, but having some sort of audio extension system, be it lua or C++, could be very nice
will be added on desktop platforms as part of the window.* functions.
that’s good to know.
the extension system encourages user contributions
i suppose it lowers the technical barriers to entry which is good.
but i think that it has a knock on effect is that less people contribute to the engine than who would have.
but also extensions have their own issue of requiring a build server, of which setting it up locally is not the best defined.
while a contribution to the engine requires you to install SDKs and tools.
there’s a statement to be said here about simplified workflows and technical debt. regardless, i think that it’d be good for the project maintainers to perhaps reach out to the developers of widely-used extensions to see about getting them added officially.
but i suppose the bigger question would be given the above quote, what’s the point of developers ever making contributions if it’s so difficult compared to extensions. and the word extensions is underplaying the power since it is after all C++.
lightweight game engine is a natural oxymoron. Defold sits in this really strange spot between being a fully featured engine such as Godot or Unity, or a handy graphics sound and physics API wrapper like Love2D.
Well, those assets are likely roughly the same size across game engines.
The initial cost is still important, even for desktop (smaller download sizes, faster startup times)
not to mention that 84MB is peanuts on desktop
The point is that we target all platforms. Steam games account for only a small portion of the user base for games using Defold.
i think that it’d be good for the project maintainers to perhaps reach out to the developers of widely-used extensions to see about getting them added officially.
We occasionally add things to the core engine that users initially created as an extension.
but i suppose the bigger question would be given the above quote, what’s the point of developers ever making contributions if it’s so difficult compared to extensions
If it’s a feature that should go into the core engine, then it should go into the core engine.
But as mentioned, most of the use cases are best suited as extensions.
4 Likes
If you’re expecting Defold to ever support desktop platforms equally to mobile ones, save yourself some grief and give up on that idea completely. I argued for it for 5+ years and didn’t get much of anywhere. The team members aren’t even able to recognize their own bias against desktop. In fact they won’t even admit that such a bias could possibly exist (even though the last two comments all by themselves clearly demonstrate it).
The argument about build size is a total “red herring”, a misleading deflection. a) Obviously they’ve added dozens if not hundreds of other new features in the last 9 years 
. b) Most of the code for desktop-related stuff that we’ve been asking for is already in the engine, in GLFW (unless they spent effort stripping it out somehow), it just lacks lua bindings. c) There are already systems in place to strip out unwanted content. d) I haven’t made a study of it, but surely there are mobile or web-oriented features taking up at least a few kb that are not stripped out of the engine for desktop builds, no? Bias.
Queue the: “Please point out exactly what you features you are missing” comments (I’ve done that many times already, go back and look). Volunteer fanboys jumping to defend by saying that they think everything is great, their standard of “support” is much lower than mine (I’m talking about equal support, not minimum support). Etc.
2 Likes
This doesn’t have to be in the survey (probably isn’t an option). But here’s my biggest pain point.
It’s too hard to find useful extensions and there aren’t enough of them to fill in the common stuff people need in a typical game engine.
A good solution to me would be to put a button in the IDE that opens the approved/tested extensions made by the defold team (or partners) and give a list or checkbox you can select to add that extension. Spine extension is a great example of one that should be in this list.
For other extensions, a store front like web page would be great (doesn’t have to be monetized, but even better if it was). Currently the github search and layout just isn’t conducive to finding them.
On the “store front” I can add the extension and it goes directly into my defold extensions list. So in the future I can just select it from the list of extensions that I “bought”.
2 Likes
Do you mean like this or something else?
1 Like
This is an odd take. We do not have a bunch of APIs in the engine for mobile or web APIs either. We provide the same and fairly limited set of functionality for all platforms.
You should make a study. If you do you’ll find that platform specific code is conditionally compiled with ifdefs.
Correct! And now when we have migrated to glfw 3.0 it is easier for us to add Lua bindings. Hence the recent addition to both get and set window size and the window title. Also setting and getting mouse lock exists.
I think this is a really unfair comment. We are not trying to second guess what our users want. We add features that are requested or which we believe will be useful to a majority of users. All issues and feature requests are tagged with glfw on GitHub so it’s pretty easy for us to see what’s requested by the community:
The next desktop specific thing I’d like to see us add next is windowed fullscreen mode. And also migrating from our gamepad bindings to the SDL gamepad database.
5 Likes
Yes I’m aware of this. And it’s just not very good to be honest. It’s just links to different sites or github.
I’m talking about something like Unity and Unreal have. A store where I choose the ones I like and use and they can autopopulate in my list of available extensions. Instead, I have to go play hunt the link, hunt the extension. Which UI did I like can? oh well, let me go research them all again.
I’m saying add a feature with the IDE that let’s us selected them from there. Like in unity I go to buy “purchased” (could be free doesn’t matter) products and I have them all in one place. I simply turn them on.
1 Like
A lot of the great insights in the thread 
I’m slowly going over them and analyse, if raised points have an issue on Github or not, it’s a lot of work, because there is over 1000 Issues on Github for Defold, some might be worth consolidating and some are lacking, so I will be slowly adding them.
I believe with Editor Scripts and UI, Editor can be extended with quite some stuff. I’m waiting for some features like a possibility to have images in Editor ( Custom images for Editor UI icons and buttons with icons. · Issue #10220 · defold/defold · GitHub ) with which I think it will be possible to make quite some interesting stuff - I have an idea for a preview of Assets Portal in game.project, so that you can view assets and just click + if you want to use some, this will copy the link to Dependencies from the latest release on Github, if linked. That would be nice, isn’t it?
5 Likes
It would be cool if new (root) locations could be created rather than having to add to existing menu drop downs. A small QOL, so no big deal really I guess.
The asset thing would be nice, and kick it up a notch, let me add them to my personal account associated library. So they are listed by default as easy to add extensions. Now we are talking 
1 Like
I’d like to challenge the proposal that defold needs more batteries-included stuff baked in.
One of my favorite parts of defold is how minimal and fast it is. Defold actually reminds me of this, for people like me who would prefer to build most things but don’t want to jettison a visual editor altogether:
I would rather encourage the defold team in the opposite direction: keep the core small and make it easier to build robust additions to the core. The recent improvements to editor scripts are a step in the right direction. On the one side there’s my own custom editor scripts to build physics convex hulls from tilemaps and on the other,@aglitchman’s interpolation native extension. Powerful, without any tax on people who don’t need custom hulls or interpolation.
This seems to me like a healthy way to grow: small, fast, well tested and reliable core with powerful extension points… for those who need and want them.
For instance I don’t currently care about audio effects. I’m happy not to bloat executables with things they don’t use.
Sure, if an extension is obviously something that almost every game should use, or its cost is close to zero, bring it in.
Just my $0.02.
11 Likes
+1 to this to be honest.
For extension selection to be your number one pain point you’d need to be starting a new project every week, with completely different feature sets and whatnot. Even then you’d quickly get familiar with what you need.
I start a new project every year or so. It takes me 2 minutes to review my previous game’s game.project and lifting out whatever extensions I need.
I absolutely get that it can be tricky for your first project, but I think the asset portal is sufficient for that.
9 Likes
I’m still thinking having to code yourself all the navigation system when zooming on bigger than screen worlds because Defold doesn’t see relation between the two is a bad thing.
I apologize for the off-topic 
Above we talked about desktop platforms and API, and I wanted to remind of a super important thing for 3D desktop games - adding to mouse locking an option to disable mouse acceleration, which is used in all of first- and third-person games. With the introduction of GLFW 3, adding it has become simple, a “quick win”.
6 Likes
I shouldn’t let things like this affect me, but your post @ross.grams has been percolating in my mind since I read it. I really respect you, yet I find this so aggressive it actually made me a bit sad. My charitable interpretation is that you expended so much effort trying to steer the engine in the direction you thought best that when it didn’t happen you grew a bit bitter.
I’m doing what you predicted so I guess this is aimed at me. I’m shipping successful Defold desktop games (fourth coming up). Am I missing something that I should be mad about? This is partly rhetorical but partly a serious question - I don’t feel hampered and in fact the team is responsive to my desktop specific needs, but as I said I respect you and your knowledge so maybe you genuinely know something I don’t.
Like I said above - I don’t really know what I’m supposed to be missing. The gamepad overhaul mentioned by britzl is something I requested. The initial comment you responded to was about needing to use native extensions, and I don’t see how that is desktop specific. Looking at the donation page it seems that most funding is coming from mobile/web, so makes sense focus is there (you can of course argue what is causing what, but then we’re still back to “I don’t know what I’m supposed to be missing”).
10 Likes