Defold: cross-platform game engine(defold.com) |
Defold: cross-platform game engine(defold.com) |
* -static-libgcc (-static-libstdc++ if c++).
* glibc ABI selection, see binutils documentation, VERSION related page, the second part of this page. This must include the glibc internal symbols. It easy to check the proper ABI with tools like readelf (the VERSION name part), which will tell you everything.
* dynamic loading with fallbacks of all system interface shared libs.
That said, it is exactly the same for the other OSes, this is all about abstraction via tables of functions.
So when you have an AI agent modifying your project you can actually understand what it did, vs. the unity yaml based format that is mostly unreadable.
Wonder if their Junie tool will support C# soon, the current features for other languages are already cool: https://www.jetbrains.com/junie/
(I got access to it cause I have the all products pack, pretty good so far)
Game developers don't bring nearly as much revenue as ad serving, which is a sad commentary on the reality of software development and the state of of the games industry.
It’s not the brush that makes the artist.
You can make proprietary changes to the engine without releasing them (unlike GPL). You can freely monetize games built with the engine, and they make some assurances that there won't be a bait-and-switch.
And finally, the reason why this is not Apache 2.0- you cannot monetize (forks of) the game engine itself.
This seems fair and carefully considered. Kudos to the team!
This is what sustainable "equitable open source" looks like. It keeps the team that built the product able to monetize, but it does so without harming or killing the community. The community has full access to the code and can modify it, make money from products made with it, and can presumably take over if the originating organization dies.
The company can choose which services to offer for free and which ones to charge a premium for. Cloud CI/builds and hosting seem like good monetization levers while leaving the engine and editor completely free of charge and open for development and modification. You can build a sustainable lifestyle business this way.
Database vendors should use licenses like this to prevent Amazon from stealing their work and bleeding their cash flow.
Redis and Elasticsearch should have done this before Amazon cloned their products, started making bank on managed versions, killed their monetization efforts, and turned their communities against them.
Matt Mullenweg should have done this instead of throwing a fit.
It is a really nice and fair source-available license and there should be more of this, but a license like theirs also restricts what kind of software you can make in a rather harsh way.
Since you can't commercialise game engine products and they are defined in a broad way. You could land in legal issues. Game engine products are defined in the license as:
“Game Engine Product” shall mean software used for video game development. This includes both the content authoring software and the software used to show the created content.
IANAL, but map editors, modding tools and many other kind of tools that can be used for developing video games could be in violation of the license.
Since meaning of "commercialise" isn't being defined or narrowed in the license small creators using Patreon or the like while asking donations could be classified as a violation too.
Without RMS swinging hard one way and without Amazon swinging hard the other way, we would not have this license.
It is because all of these shenanigans that we now kind of have a license that solves these issues, and surely when the landscape changes again, a new license scheme will be needed.
Not a choice he had. You cannot relicense GPL code line that. He would have had to write a new system from scratch instead of forking an existing one.
Mullenweg, approximate net worth $400 million, should have thought long and hard 20 years ago if "a rising tide lifts all boats" allows for others to have boats, or just his. There should be a $billions ecosystem around WP even if Mullenweg doesn't get that money.
Why is that a good thing?
>You can freely monetize games built with the engine,
You'd also be able to do the same if it had a GPL license
>and they make some assurances that there won't be a bait-and-switch.
If it was licensed under a GPL license you wouldn't need to rely on "some assurances"
Game dev at the top tiers is an arms race. Being able to do proprietary things is attractive to big players.
>> and they make some assurances that there won't be a bait-and-switch.
> If it was licensed under a GPL license you wouldn't need to rely on "some assurances"
Multiple projects have gone closed-source from open source. Assurances are a nice thing to have (but certainly no guarantee).
> Why is that a good thing?
Instead of writing an internal project from scratch, you modify an existing project and tightly couple it with your internal process. What's wrong with that?
From what I understand it emerged from a gamedev studio from Sweden (King or something?) so there's commercial release pedigree there. I believe their console platform build/release tooling does cost money for game devs because the platform SDKs themselves impose restrictions. But I get the impression that defold as org does seem to put in earnest effort to be fair to game devs with licensing, etc. like others mentioned here.
A team of about 6 people replaced the IDE core and built a dozen tools over a year.
It was a fun project. Not many people can say they built a desktop gui with Clojure!
Ah, the wiki page also mentions the Defold engine, which was first developed in 2007 and acquired by King in 2013, then opened to its current licensing model in 2016.
The other options include MonoGame https://monogame.net/ (Stardew Valley was written in it) and of-course the biggies like Unity or Unreal. A lot depends on how much investment in learning one wants to make, what is the feature set one is looking for, the trade-offs or platforms one wants to keep in mind and which programming language / style one want to use.
This feels similar. Sometimes you can just tell by the communications and the spirit of the language that the team has the goods.
The fact that they have such comprehensive multiplatform export right now is big. One of Godot's biggest hurdles has been console support.
My ONLY beef, from what I saw, was that it was Lua only. If it was C# I would have been more excited. But at least it's not a full C++ recompile like SOME engines. :)
One of the reasons for this is because console plugins can't be developed in the open like the rest of the engine, because the console SDKs are behind NDAs. It's a pretty ridiculous holdover from when consoles were more specialized.
I guess the roots with King have made things easier for Defold?
Here's a recently released 3D game made with Defold: https://forum.defold.com/t/cashchubbies-island/78183/22
Purpose is just to try to get an AI to generate code with it.
There are things that aren't great about lua, and I'm not going to pretend they're not. buuuut...
- It's really perfectly ok if you use competently.
- There are large complex systems and games built using it (eg. factorio) that show that scaling it is both pragmatic and possible.
- It has a big active community.
When you compare it some other scripting solutions (boo, unityscript) that were just incompetently done, or mystifyingly deciding that writing your own language is the solution (jai, gdscript), I feel you have to admit it's a reasonably pragmatic choice.
There aren't a lot of other languages that embed as a scripting layer the same way that lua does, with the same performance.
Many candidates are either very hard to work with embedded (python) or simply lack any feasible way to possible embed them as a runtime scripting layer (go, zig, c, etc).
Maybe there's a future for WASM scripting layers in games, but for now, I certainly haven't seen it done well.
I can confidently say: Lua, the language, is not a minefield. Not to me. Not to you. Not to anyone.
Some projects expose a lua scripting API that is a minefield; ...but those two things are not the same thing, and by all accounts (I haven't used it personally, but just idly reading the forums) the defold scripting layer seems fine to most people.
Teal to lua is what typescript to javascript
Another option is https://typescripttolua.github.io/
https://vxlabs.com./2018/05/18/interactive-programming-with-... https://technomancy.us/188
I assume you've seen:
https://ertu.dev/posts/i-made-an-online-shooter-game-in-lisp...
Context:
Every time a game engine like this pops up I read through the comments noting other engines and various perspectives and criticisms (positive and negative).
I have a game-like music composition project I want to pick back up. Media-intensive with a rich isometric/2D environment, with lots of little animations, which need to be synchronized to perfectly-scheduled audio events.
I develop fully-feature prototypes in the past, most recently on iOS for iPad before there was iPadOS... but using Core libraries hit a performance wall on hardware of that era.
Question:
Who can I consult with up front to get good advice on what technology path to pursue, to realize my project?
WebGL/Webasm would be fine. Cross-platform console targets would be fine. iPadOS would be fine and best, gestures are a core part of the vision.
...and I have no idea where and how to find my way into this.
I follow some GameDev feeds and naturally what I read about is very capable application of engines/environments which are quite close to what I need, but which are (naturally) targetting game dev.
Say you wanted to sit down and make a rich visual sequencer with some DAW-like features? What's the right approach?
It's not a traditional DAW, it's much more about a rich tiled game-like UX; it's not a game, with levels, maps, and such... it's got elements of both. The audio engine needs to be DAW-level, but, synchronized to graphical elements and UX and responsive to gesture in a way that's like game-level.
Any ideas welcome. I think I have a good (layperson's) understanding of the overal architecture I need; but I don't know how my conceptual map translates into different styles of game-engine or more general media-engines.
My hunch is my "solodev" state which was a blocker before when I had no time to quit the day job and learn eg. OpenGL for iOS, is significantly ameliorated today by code assistants... iff they are familiar with <the engine/platform>
Do Claude Code etc. know Unity dev? Engines like this one? I don't know! Naive.
Haaaaalp
Seems fair, but sadly not OSS. I wonder why they think it's necessary?
There is the requirement to make the source code available (GPL), as far as I am informed, you can sort of get around this, by delivering the source code with the download, but then "don't advertise" it, as in hide it as much as possible without getting in legal trouble.
(My information may be a bit outdated here) Afaik, the Blender Foundation doesn't even bother to shut these projects down (they do get frequently informed about it, when people discover it).
And this even given the fact, that they would be easy to shut down. The reason for this, is used media in advertising. If you want to sell your 3D package, you need to show some impressive artwork which was created with said project.
Problem is, the images/animations these projects show off on their websites are a) not created with said Blender reskin, but usually in Blender itself and b) they usually don't have permission from the artists.
So even having this quite comfortable handle, BF usually don't care. Which tells a lot about the impact of such copycats.
My takeaway from all this is, the situation would pan out pretty similar for Defold, and they should just dare it and monitor the landscape.
Which of their license changes makes you feel sad and why? Were you planning to sell their editor?
The website-summarized version of the license says:
> You can not commercialise original or modified (derivative) versions of the Defold editor and/or engine
It sounds like this would only be a problem if you're literally shipping a modified version of Defold. No game with any kind of financial incentive does this for a built-in map or mod editor, because it would make it incredibly easy for other people to then sell a modified version of their entire game.
It's kind of like if Apple made the Xcode source available, and then said "hey you can't monetize a modified version of Xcode." No one is going to ship their app's entire Xcode project to players just so the players can make a custom map.
The normal way for games to do this is to implement a brand-new map-editing UI inside Defold (or Xcode, Unity, Godot, etc.) that spits out custom maps in the exact data format that the game can parse.
Here's some commentary I made in another thread on this post:
They only stopped because of the backlash they received when they tried to. Their initial announcement was about "Defold becoming open source".
https://defold.com/2020/05/20/Some-thoughts-on-the-open-sour...
Games are complicated beasts, something along the lines of C# help massively the development and the avoidance of bugs.
Python, <X>Script and Lua are not languages I'd wish to switch to from the coziness of C#. I'd consider Go or Java (although not as hip as it used to be).
- SDL2 for input and window management
- OpenGL for rendering
- libpd for sound generation and processing
- RtAudio for audio I/O
- sol2 for Lua bindings
- Qt6 for the tile map editor
I'm not targeting the web, though.
> The audio engine needs to be DAW-level, but, synchronized to graphical elements
Are the sounds generated from game events? In that case, time synchronization between game clock and audio clock is indeed an interesting problem with multiple solutions, each with their own trade-offs.
If the game only acts as the user interface, you can treat it like in a regular DAW.
I am torn about backing off to focusing on first getting the UX (which is really "the thing") right, and just emitting a MIDI MPE stream. That obviously has some other benefits but there were things I was keen on having low-level control over... but I can get over that maybe...
Ambivalent also about target—really, the iPad is the ideal and canonical target, in terms of what it can and the UX it affords... but I have this possibly unfounded sense that the amount a coding copilot can assist me is somewhat limited inside the Apple ecosystem... :/
EDIT: oh and is your engine something I can look at (or license or...)? :)
- Give the modding tools for free with the game (like many games do anyway). You're commercializing the game no the modding tools - Make the tools defold-free ? So it reads the game data but its not defold. - Tools for free but charge for support/warranty?, Clause 9 lets you sell support/warranty; you just can’t charge for the software license itself.
Possibly the license text needs to be tweaked to make that more clear (IANAL too) but I read it as meaning that commercial extensions were fine, just not commercialising a patched version of the core code.
Your concerns do seem entirely reasonable, but if, in practice, they become an issue, it seems like the codified-in-law goals of the foundation (see https://defold.com/foundation/) strongly suggest they _would_ tweak the license text as required.
I dunno, I don't think the harsh restrictions you mention exist, and I'd hope that if any actual lawyers read them as existing then their employers will direct them to help get the license bugfixed.
So colour me "cautiously optimistic" here.
Honestly, not great, but that's the world we live in.
It can take hundreds of dev-hours to port your engine to consoles yourself, so having another company handle it for you, for all 3 consoles, for only $2000 is a pretty good deal!
The $2000 is also to port to all three console platforms, it's $800 per. This makes it feasible to say, only target PlayStation with W4 and use the community Switch port.
You just don't have to release the code if you do change it.
Although I'm unsure if selling services on your modified game engine, that you released the source of, counts as commercialization.
> Optional typed Lua using Teal.
If Mullenweg had been the original developer it would be valid criticism.
Yeah, so I don't see how helping out the big players and not everyone else is a good thing.
>Multiple projects have gone closed-source from open source. Assurances are a nice thing to have (but certainly no guarantee).
Yeah but the open source ones ARE guaranteed. Even if they later become closed source, the code up till that point will remain open source forever. So it is guaranteed whereas "some assurances" mean nothing.
If you want your stuff to be private, you have a legal option.
> Yeah but the open source ones ARE guaranteed. Even if they later become closed source, the code up till that point will remain open source forever. So it is guaranteed whereas "some assurances" mean nothing.
I guess? Is that not the case here as well?
The changes from the Apache 2.0 license are sufficiently minimal that you can _still_ fork it from that point, you just (a) won't be able to use the trademark (b) won't be able to sell it.
Given the clearly stated goals of the foundation and hence the project, that seems to be providing exactly the guarantees they intend to provide, and while your point about assurances is entirely fair, I think you're underestimating the level of legal guarantees that you do get here.
Obviously, a few people were like "uh, why would -we- want to help you with that?"
As soon as I saw an example of this existing code, however, I told said people to STFU ... because for some arsef_cked reason I don't understand at all, they'd used EmbPerl of all things for the scripting, which is basically "PHP for mod_perl" and exactly as horrible as you might imagine even when used for its actual purpose rather than in this case for something completely unrelated.
Even if sensible perl would've been an acceptable approach (and speaking as a veteran perl programmer, I would still consider lua to be more suitable; I strongly consider an importand part of the Zen of Perl to be knowing when to use something else) the approach they had taken was an abomination unto Nuggan and very much deserved to die.
What they had was very definitely the sort of perl code that justifiably contributes to people hating perl, and I considered it a service to perl to help them rip it out in favour of lua code that actually made sense.
(I, personally, think perl works very well as a scripting layer for e.g. irssi, though you might come away disagreeing if you read the average irssi script rather than ones written with a little care and concern ... but for a game? Nah, lua all the frigging way)
Obviously any engine will have a lua scripting api written in c++ but if youre somehow casting shade about factorio being a lua success story, youre barking up the wrong tree.
That's the case with assembler too. It's exactly my point.
I love how lua works, is easy to embed, fast, and can compile to bytecode. But I really miss "compile time" checks, but my biggest issues are:
- You have to kind of invent your own modules / class-system. It's a lot of boilerplate and error prone - The 1-based indexing is horrible - Looping over 'arrays' would require sorting the keys first. i.e. there are no arrays.
It's been little over 10 years since I've done lua (gaming). Oh, and I used lua in an nginx handler after that
Unfortunately not, it's a private repo. I might open source it at some point in the future, though.
You do need to speak to someone.
Prototypes I already have made; at this point the goal is get something actually stable. I'm willing to look into any approach that has a stable application doing things that I need. I don't want to make another prototype; but I am open to trying an implementation that might not end up being final.
It's proven remarkably difficult to find who to even consult with. AFAICT it's too rarified a need.
Support [1] page:
> Please contact us at business@defold.se for more information on how we can help you publish great games made with Defold.
About [2] page:
> Product development, marketing, support and sales - Refold AB is owned by members of the Defold team and is contracted to perform most of the day to day work on the Defold product.
Open [3] page:
> Q: Is there still going to be a roadmap for Defold?
> A: The Defold Foundation has decided to no longer share a public roadmap at the beginning of each year.
Status [4] page:
> Defold will never change into a subscription model, request royalty payments, introduce licensing fees or in other ways charge for access to the main (emphasis added) product.
FAQ [5] page:
> Q: What kind of user tracking are you doing?
> A: We log anonymous usage data from our websites and the Defold editor in order to improve our services and product.
They're using a lot of SaaS typical for startup/business growth. Their forums are Discourse [6], they're running a bunch of analytics, SendInBlue for campaigns, etc. That in and of itself doesn't imply anything, but they do seem to be very mindful of their community's health and growth.
There are some very dedicated people at the wheel. It looks like they've carved out enough leeway for commercial and support offerings to sustain themselves and keep others from stealing it like Amazon and others have done to other open source projects in the past, all the while building a cool community-powered open game engine.
[1] https://defold.com/support/
[4] https://defold.com/status/
[5] https://defold.com/faq/faq/
[6] https://forum.defold.com/ ; Discourse is $100/mo or more for custom domains
It does seem like a bit of problem, but it also seems like a very specific thing that could be… cleared up, and then it would be all sorted.
That would be like shipping photoshop with your game to allow people to customize their character’s hair color.
Modding a game engine’s editing tools to the point where they are user friendly enough for your players is almost always a bigger challenge than building basic editing tools using the engine.
This entire argument is insane to me. Someone is releasing something for free with the caveat that you can’t use it for this one specific very uncommon thing. Then people are up in arms “what if one day I want to do this one specific thing? Do you? No but what if I did?” Don’t use Defold.
You do not sell or otherwise commercialise the Work or Derivative Works as a Game Engine Product.
"Work" shall mean the work of authorship, whether in Source or Object form,
made available under the License, as indicated by a copyright notice that is
included in or attached to the work
"Derivative Works" shall mean any work, whether in Source or Object form, that
is based on (or derived from) the Work and for which the editorial revisions,
annotations, elaborations, or other modifications represent, as a whole, an
original work of authorship. For the purposes of this License, Derivative Works
shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of, the Work
and Derivative Works thereof.
(so if the extension API is missing something, contribute the feature(s) you need back to core, then you can write your extension free of issues, so far as I can tell)
For a moment, I was thinking Defold ought to dual-license their engine under both the current non-OSS modified Apache and the GPL. That way, you'd have the option to either:
1. Commercialise software created using modified versions of Defold, without releasing the source of your modified version, as long as you don't commercialize your modified version of Defold itself.
2. Commercialise a modified version of Defold, but you must make the source available under the GPL. (Which would mean that source could be used by the upstream project as well.)
But while typing this up, I noticed the flaw in this plan—the parenthetical isn't true! Because the upstream project would be dual licensed, they couldn't use GPL licensed code.
Of course if they do, I hope they will say "either modified Apache or the GPL".
My company's lawyers made a big stink about us using jQuery plugins that said "and" instead of "or".
There’s no reason to assume that a paid fork would reduce the number of free Defold users; it can happen, but depends on what is built and offered, and sometimes paid forks are good for the ecosystem and increase the number of overall users.
If you need to add an extra API or something to the core to make your paid extension work, you can't charge for that, which I think is designed to incentivise "improve the extension API, contribute that back to the core project, then go wild on your commercial extension and see if you can get people to pay for it."
I have no clue whether this approach will turn out to work in the medium-to-long term, but it's a fascinating idea and seems at the very least like an experiment very much worth conducting.
(it's not)
For example a company might try to sell a version of engine which has been ported to a console which original engine doesn't support. Game porting companies are very common and if it's their main business then they will usually have inhouse libraries or modified engine versions which significantly simplify the porting process.
That's exactly what's happening with open source game engines like Godot. Their documentation lists almost a dozen companies providing porting service for godot games. That isn't necessarily a bad thing, but it's up to author of game engine whether they want to allow others to profit from their work in such way.
Seems like currently Defold supported platforms cover most of the popular consoles, it was probably not the case during early development of engine when license was chosen or in a few years when next generation of consoles come out. Someone might also be selling a better console support than what defold provides out of the box. Beside the consoles there is also stuff like integration with various PC stores like GOG,Epic and others. Its not necessarily a huge work, but plenty of smaller devs want to focus only on the gameplay aspects. So once a game is finished (and you are tired from development process), buying anything which significantly reduces porting/integration effort can be an easy choice.
One more example of major feature which can require tight engine integration and motivate buying a modified version of "free engine" is multiplayer support. Good multiplayer support can be quite tricky with some game genres being harder than others. There have been many attempts at providing magic multiplayer solutions which under the hood automatically synchronizes all game entities without developer thinking about it. Such approach isn't necessarily going to be as good playing experience as designing the game with multiplayer support in mind from day 0, carefully thinking how the game state is organized, what when and how is synchronized. But that requires planning ahead, technical expertise and suitable budget. Commercial multiplayer middleware for existing engines are also not uncommon.
Whether something like that is considered an addon or modified engine version depends on exact licensing terms and the exact implementation details how game engine and addon code is organized.
A slightly different example - game engine built on top of game engine is RPG maker. For a long time RPGMaker has been it's own game engine. But few years ago developers of RPGMaker made a version of RPGMaker which is built on top of Unity. Plenty of other genre specific engines (especially for fighting games) built on top of general purpose game engines. Again the line between modified engine, addon and game with builtin editor is tricky.
Edit: clarity
Why?
Tbh I'm a little more confused after reading this
> “Game Engine Product” shall mean software used for video game development. This includes both the content authoring software and the software used to show the created content.
The license allows redistribution so long as:
> a) You do not sell or otherwise commercialise the Work or Derivative Works as a Game Engine Product; and
So my read is that any tool that allows you to modify game content constitutes a game engine product and they specifically do not allow you to sell a game engine product built with Defold.
This weird technicality that is invented in this discussion about whether or not you're using Defold's built-in engine tools, or developing your own tools on top of Defold is entirely irrelevant to the language of the license.
It’s not enough that your game could be used by someone for video game development, a reasonable person would have to believe you were selling it as video game development software.
There’s definitely some gray area here for something like Roblox which is a game, but also allows people to develop and sell video games. But the risk of Defold suing you and a court finding that the map editor you added to allow people to make free levels for your puzzle game constitutes selling your game as video game development software is so far down the list of things you need to think about at all that it’s not worth considering.
If you want to make something like Roblox that is essentially a game engine, I wouldn’t use Defold. Otherwise I wouldn’t worry even a little bit.
My worry is about 'otherwise commercialise', in cases where the ability to have fan made levels is an advertised feature, as is often the case.
But I agree that this is less of an issue than I first thought, and appreciate your explanation.
Shipping 3rd party engine tooling is not. At all.
The equivalent to what valve did would be if Defold released some games made with Defold and then released the Defold engine, which is basically what happened.
There’s also nothing stopping from releasing your game, linking to Defold and saying use Defold to mod this game.
If they do, look out.
Unlike Defold, both Godot and O3DE are actually free.
That number is vastly smaller.
If Godot games were making anywhere near the revenue that Untity games do, I’m willing to bet they’d there would be an Amazon fork.
(and it's still bigger for Godot)
It also doesn’t matter what the user base is today. It matters what it might be tomorrow. It’s not easy to change your license. If you wait until Amazon is coming for you, it’s too late to do anything to stop it.