They have gone with an interesting licensing solution here. I really appreciate that it is labeled as a source-available license instead of Open Source.
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 an awesome license. More products should be source-available like this.
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.
At least they mention that it is source-available, but they still mix "open source" into the mix on their site.
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.
- 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.
They seem to be fairly explicit that _they_ believe that extensions aren't covered by those restrictions.
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.
People don't have such hindsight. And we can't ask them to have it, as it is impossible to predict the future with such accuracy.
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.
I thought that copyright holders could relicense code however they wanted? I don't think GPL or not is the issue, but whether or not all third-party contributors have assigned the copyright of their contributions to the party trying to relicense. My understanding is that this is often difficult or even impossible in practice to obtain after the fact codebases with large numbers of contributors over the years if signing something ahead of time wasnt't a requirement previously, and I don't have any insight into whether Wordpress is in this situation or not, but I don't think whether the code is GPL or not is relevant to this
Yes, the copyright holders can relicense, but its highly unlikely they will do this to enable a fork to have a different license, and wordpress started as a fork of b2.
If Mullenweg had been the original developer it would be valid criticism.
Really what it means is there is one entity entitled to monetize the project, so it will probably just die if their monetization ideas or execution are lacking or their enthusiasm wanes. GitHub is full of dead projects like this because monetizing software is hard, building important software is hard, and doing both is even harder. Open source should be funded, but this isn't an efficient way to do it.
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.
Consider the space we're in. For game development you're going to have a lot of developers with a lot of different ideas about how to make a game, all utilizing the same engine. If the engine doesn't come with a feature I need, I'll probably have to code it myself, but seeing as the whole purpose of me making this feature is for my game, then it makes sense that I should be able to keep my game's feature private/proprietary without the need to push that feature back to engine which might not even want my feature to begin with. This is why GPL is not a good choice for game engines.
GPL doesn't require you to push a feature/change/etc back to the engine devs, it only requires you to make it available to others. You can just keep your changes in a ZIP file alongside your game's data - which is what a bunch of games built on the GPL releases of id Tech already do.
> Game dev at the top tiers is an arms race. Being able to do proprietary things is attractive to big players.
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.
> 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.
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.
> Yeah, so I don't see how helping out the big players and not everyone else is a good thing.
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.
>> You can make proprietary changes to the engine without releasing them (unlike GPL).
> 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?
I like the licence, and it is for me open source in spirit if not in letter, but there is a case that could cause problems : what if you sell services for a closed source version of defold ?
It specifically says you are not allowed to commercialize the engine or a derivative, so that sounds like something that is not intended to be allowed, though I feel like it might take a lawyer to decide whether or not that is technically allowed by the license.
Major props to them for not only calling it "source available" (and not trying to misuse "open source" like so many do), but also for highlighting the additions to their Apache-based license: https://defold.com/license/
IANAL but seems like the only addition is preventing you from selling a game engine based on it. So you can sell a game, but not an engine. I wonder where a game with built-in editor ranks.
Seems fair, but sadly not OSS. I wonder why they think it's necessary?
I don't know what they think, but I think it is not necessary. Let's draw a comparison to Blender here. Blender is GPL, and there is a long history of questionable projects that relabel Blender and try to sell it.
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.
This was my question to. I suspect they're worried about someone making a paid version with extra features which aren't contributed back to the community.
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.
Why do you assume the problem won’t exist, when this exact thing happens all the time? Just to name a tiny handful of obvious examples: Oracle, Canonical, GitHub, RedHat, DataStax. Not only could someone add enhancements that justify the price, like several other comments have pointed out here, they could also simply offer support that Defold doesn’t offer, and they could do marketing that Defold doesn’t do. The number of paid products that are equivalent to and/or based on free products is innumerable.
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.
Paid extensions are allowed, which seems like a neat compromise.
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.
If they didn't prevent selling derivative game engines, someone could fork it and add a valuable feature that was only available in the paid fork. This could split the community.
That’s because the user base isn’t big enough yet for Amazon to make a paid version. Or no one at Amazon has figured out a way to monetize a game engine yet.
You can’t really look at overall user base, you have to look at the number of users making enough money off of Godot that they’re willing to pay for commercial features.
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 now I’m clarifying that I should have been more precise when I said user base. Amazon clearly doesn’t care about users that aren’t going to make them money.
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.
The modified engine someone else is selling could have a potentially important extra features.
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.
RPG in a Box[0] is the first example that sprang to mind when I read these comments. It transforms Godot into a more generalized "game maker" but could arguably be considered selling the engine.
It says why multiple times, right on the page parent linked to. They want Defold to be free to use, they are trying to guarantee it’s always available to developers free of charge, and that the source remains always available. Why do you ask?
I ask why because tons of other software achieve being free to use, free of charge, without preventing the software from being commercialised by a third-party. Why do they feel the need to prevent their software from being commercialized? The only reasonable answer seems to be jealousy.
The main repository (github.com/defold/defold) is the only one with the Defold License (ie the modified Apache license). There's also around 80 or so MIT licensed repositories with Defold engine plugins for things such as analytics, monetization, ads, attribution, game servers as well as tools such as Spine, Tiled, Rive etc.
They called Defold "open source" at the beginning and only changed the wording later when people started reacting, so this could be an artifact left from that.
I think there's a misunderstanding about the license. The license doesn't care at all about whether or not you're using the tools from Defold. They care about whether or not you're giving the ability to modify game content in a commercial product.
> “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.
After reading the license more thoroughly this is actually even less of an issue. The key thing about the wording is that it says you may not sell it “as a game engine product”.
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.
Shipping the custom tools the developer built to make content for their game is relatively common.
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.
You wouldn’t ship your game with built in editing tools from the engine. Those editing tools are not restrictive enough to just hand out to the general player base. They’re too powerful and too hard to use.
Maybe, but this isn’t remotely common with existing open source game engines.
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.
The license doesn't indicate that you can get out of the terms by developing your own map editor. A map editor would qualify as a game engine product because it can edit game content and their license specifically prohibits you from redistributing a game engine product that's built with Defold.
If the map editor is an extension (and they have lots of example extensions on github, all of which I've checked are under normal open source licenses) rather than a set of patches to the core code itself, it isn't subject to the Defold License in the first place.
(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)
> I wonder where a game with built-in editor ranks
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.
I remember this was initially developed at king games (candycrush saga authors) before they got acquired. Probably that's the reason for the weird licensing model
This looks similar to the classic "enterprise support" and "distribution" lifestyle business play, which is incredibly sustainable and benefits both the software community as well as the maintainers. From their website:
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.
I've had a soft spot for defold, partly because they're unique in the gamedev space. For example, the GUI editor that is built-in is done in Clojure! https://github.com/defold/defold/tree/dev/editor (cljfx for the GUI, I am rooting for seesaw though :))
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.
It’s cool to see this mentioned. I worked on the editor back in the day. It’s actually the second IDE for Defold. The original one that we replaced was built on Eclipse.
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!
If it is King, then it's got a huge (financial) backer; King is one of the most profitable game publishers thanks to e.g. Candy Crush that made their revenue jump from $62 million in 2011 to $1.88 billion in 2013. It was bought in 2016 by Activision Blizzard, which in turn was acquired by Microsoft in 2023.
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.
Yes, this happened early in 2020. Defold has been a public product longer with the Defold Foundation than with King. King has not been affiliated with Defold for a very long time.
Defold has been there for a while, not sure of why this in on the front page right now. Anyways, Defold is good, the community, docs etc. are on the lower side as compared to Godot.
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.
I remember when Unity first appeared and what it felt like to read its materials, its pitch. It was like... whoa, this might actually be something.
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. :)
Godot does support consoles, they just choose to move that to third parties. There's community Switch support if you're a registered Switch developer, and W4 Games licenses export plugins.
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 wish people would stop mentioning W4 Games as a porting option.
their lowest revenue tier costs $2000 a year. most indie games sell a few hundred copies.
You'd be hard pressed to find console support for much less than that - compare it with Unity or GameMaker's console support tier and you'll find it's pretty similar.
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!
Most indie games sell on Steam/Steam Deck first and port to consoles later, usually after being picked up by an indie publisher.
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.
The situation with systemd cannot be compared to special circumstances of Godot and shady practices of its management. It's an essentially open core but privately owned product. I guess this is a better arrangement than Unity but it is not a true FOSS engine in the sense of the word.
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).
C# support is still experimental and under development, but it is at least ready for testing for those that are curious. Note that it is C# with Native AOT so it's compilation and linking involved, not "scripting and hotreload".
How does it compare to Löve 2D, other than shipping with a IDE? Looks like Defold supports more platforms, but I guess there are some strings attached since packaging games for various consoles usually come with very non-open dependencies.
In the game industry, "C-like C++" is the norm. Games often don't use modern C++ features like exceptions, RTTI, multiple inheritance, etc. for very good reasons.
It's less featured and has limited 3D support, but Defold is great for making smaller games aimed at the web or mobile. It has a much smaller binary size and it's generally more stable, especially in terms of physics. If you take a look at the showcase it's mostly webgames and a few smaller indies.
Thank you, I started Godot recently and I'll take a look at Defold as this is the exact thing I am doing - and Godot seems a little unstable with the APIs. Every tutorial I find is for Godot 3, and Godot 4 seems quite changed.
The version 3 to 4 transition was used to make breaking improvements to many things. The API is intended to remain stable within major versions. The docs also cover the major API changes from 3 to 4 and comprehensive docs exists for both version and you can still use Godot 3 if you want to.
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.
I remember some years ago we got somebody joining irc.perl.org #perl to ask for help replacing perl with lua as a game scripting system.
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.
> - It's really perfectly ok if you use competently.
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
It's also being funded by a number of corporate sponsors. As I understand it, a studio or publisher will fund the development of a specific feature, while general development is mostly just spare time and donations.
No, Defold is developed by six full time and two part time developers. All developers are fairly compensated. Most of the work done on the engine is "general development" funded by corporate partners, studios and publishers. There is quite a bit of overlap between the needs of specific partners and the general development roadmap.
I am looking for a game framework that allows interactive programming
like LISP for browser games. So far I have tried love2d, TIC-80, and
defold. Fennel (Clojure like language for Lua) works with love2d and TIC-80, but I could not get
emacs repl to connect to TIC-80. Also I couldn't get Fennel to work
with defold. Maybe there's a way I haven't found yet, but for now the
only way to achieve interactive programming is to use love2d (love2d +
fennel + emacs repl).
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.
I'm building 2D computer game environments for musical performances and interactive installations. I ended up developing my own little engine. The current iteration is based on:
- 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...)? :)
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.
Hopefully their build scripts are sane for native elf/linux support:
* -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.
After spending time with Cursor/Junie/Copilot etc., game engines are starting to feel slow and behind the curve. I’d love to see faster adoption and deeper LLM integration (as native features, not just some random third-party plugins). Whoever builds the first “Cursor for games” is going to disrupt the market.
I am rooting for Godot here because it has a human readable scene file format.
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.
The problem with Unity is not their marketshare of game developers (which they have in spades), but rather their market share of ads which they completely missed out on.
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.
They have gone with an interesting licensing solution here. I really appreciate that it is labeled as a source-available license instead of Open Source.
https://defold.com/license/
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 an awesome license. More products should be source-available like this.
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.
At least they mention that it is source-available, but they still mix "open source" into the mix on their site.
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.
The only options i see are:
- 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.
It could be nice if they had some sort of easy approval process for small Patreon users to commercialize the building of tools for their platform.
They seem to be fairly explicit that _they_ believe that extensions aren't covered by those restrictions.
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.
People don't have such hindsight. And we can't ask them to have it, as it is impossible to predict the future with such accuracy.
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.
> Matt Mullenweg should have done this instead of throwing a fit
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.
I thought that copyright holders could relicense code however they wanted? I don't think GPL or not is the issue, but whether or not all third-party contributors have assigned the copyright of their contributions to the party trying to relicense. My understanding is that this is often difficult or even impossible in practice to obtain after the fact codebases with large numbers of contributors over the years if signing something ahead of time wasnt't a requirement previously, and I don't have any insight into whether Wordpress is in this situation or not, but I don't think whether the code is GPL or not is relevant to this
Yes, the copyright holders can relicense, but its highly unlikely they will do this to enable a fork to have a different license, and wordpress started as a fork of b2.
If Mullenweg had been the original developer it would be valid criticism.
Really what it means is there is one entity entitled to monetize the project, so it will probably just die if their monetization ideas or execution are lacking or their enthusiasm wanes. GitHub is full of dead projects like this because monetizing software is hard, building important software is hard, and doing both is even harder. Open source should be funded, but this isn't an efficient way to do it.
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.
I agree that the license looks fair. Not everything has to be OSI-compliant open source. They even support WASM!
> You can make proprietary changes to the engine without releasing them (unlike GPL).
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"
Consider the space we're in. For game development you're going to have a lot of developers with a lot of different ideas about how to make a game, all utilizing the same engine. If the engine doesn't come with a feature I need, I'll probably have to code it myself, but seeing as the whole purpose of me making this feature is for my game, then it makes sense that I should be able to keep my game's feature private/proprietary without the need to push that feature back to engine which might not even want my feature to begin with. This is why GPL is not a good choice for game engines.
More importantly, a successful game is likely to need porting to proprietary platforms, with APIs behind restrictive NDAs.
Honestly, not great, but that's the world we live in.
GPL doesn't require you to push a feature/change/etc back to the engine devs, it only requires you to make it available to others. You can just keep your changes in a ZIP file alongside your game's data - which is what a bunch of games built on the GPL releases of id Tech already do.
>> You can make proprietary changes to the engine without releasing them (unlike GPL). > Why is that a good thing?
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).
> Game dev at the top tiers is an arms race. Being able to do proprietary things is attractive to big players.
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.
> 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.
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.
> Yeah, so I don't see how helping out the big players and not everyone else is a good thing.
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?
>> You can make proprietary changes to the engine without releasing them (unlike GPL).
> 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?
I don't think that violates the GPL, it does only if you distribute the modified version without also providing the source changes.
I like the licence, and it is for me open source in spirit if not in letter, but there is a case that could cause problems : what if you sell services for a closed source version of defold ?
It specifically says you are not allowed to commercialize the engine or a derivative, so that sounds like something that is not intended to be allowed, though I feel like it might take a lawyer to decide whether or not that is technically allowed by the license.
You'd first have to make proprietary changes, which you are not allowed to release, and so there's nobody to sell those services to.
> You are free to distribute original or modified (derivative) versions of Defold
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.
Major props to them for not only calling it "source available" (and not trying to misuse "open source" like so many do), but also for highlighting the additions to their Apache-based license: https://defold.com/license/
IANAL but seems like the only addition is preventing you from selling a game engine based on it. So you can sell a game, but not an engine. I wonder where a game with built-in editor ranks.
Seems fair, but sadly not OSS. I wonder why they think it's necessary?
I don't know what they think, but I think it is not necessary. Let's draw a comparison to Blender here. Blender is GPL, and there is a long history of questionable projects that relabel Blender and try to sell it.
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.
Wouldn't the artists be the ones to have standing, instead of the Blender Foundation?
Because they don't want somebody else to sell their game engine? It's pretty clear, isn't it?
Why would anyone buy their game engine when it is available for free? Seems like a solution for a problem that doesn't/won't exist.
This was my question to. I suspect they're worried about someone making a paid version with extra features which aren't contributed back to the community.
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.
>dual-license the engine under both their current non-OSS modified Apache and the GPL.
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".
Why do you assume the problem won’t exist, when this exact thing happens all the time? Just to name a tiny handful of obvious examples: Oracle, Canonical, GitHub, RedHat, DataStax. Not only could someone add enhancements that justify the price, like several other comments have pointed out here, they could also simply offer support that Defold doesn’t offer, and they could do marketing that Defold doesn’t do. The number of paid products that are equivalent to and/or based on free products is innumerable.
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.
Paid extensions are allowed, which seems like a neat compromise.
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.
If they didn't prevent selling derivative game engines, someone could fork it and add a valuable feature that was only available in the paid fork. This could split the community.
Yeah, just look at how fractured the Godot community is.
(it's not)
It is a bit fractured - there is a Redot fork. But that was caused by governance issues, not anyone's desire to sell the engine.
That’s because the user base isn’t big enough yet for Amazon to make a paid version. Or no one at Amazon has figured out a way to monetize a game engine yet.
If they do, look out.
Godot's user base is already bigger than Amazon Lumberyard's (now O3DE).
Unlike Defold, both Godot and O3DE are actually free.
You can’t really look at overall user base, you have to look at the number of users making enough money off of Godot that they’re willing to pay for commercial features.
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.
It's you who brought user base size in.
(and it's still bigger for Godot)
And now I’m clarifying that I should have been more precise when I said user base. Amazon clearly doesn’t care about users that aren’t going to make them money.
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.
The modified engine someone else is selling could have a potentially important extra features.
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.
RPG in a Box[0] is the first example that sprang to mind when I read these comments. It transforms Godot into a more generalized "game maker" but could arguably be considered selling the engine.
[0]https://rpginabox.com/
Edit: clarity
(Action Game Maker)[https://store.steampowered.com/app/2987180/ACTION_GAME_MAKER...] seems like its the same thing - it's built on Godot and seems like it's trying to provide a no-code interface to it.
That doesn't answer the question of why.
I feel like the answer to "why" is on the website if you read about the foundation's objectives:
https://defold.com/foundation/
> Prevent the Defold software from being commercialised by a third-party.
Why?
It says why multiple times, right on the page parent linked to. They want Defold to be free to use, they are trying to guarantee it’s always available to developers free of charge, and that the source remains always available. Why do you ask?
I ask why because tons of other software achieve being free to use, free of charge, without preventing the software from being commercialised by a third-party. Why do they feel the need to prevent their software from being commercialized? The only reasonable answer seems to be jealousy.
≥Support the open source community and the use of open licenses.
Tbh I'm a little more confused after reading this
The main repository (github.com/defold/defold) is the only one with the Defold License (ie the modified Apache license). There's also around 80 or so MIT licensed repositories with Defold engine plugins for things such as analytics, monetization, ads, attribution, game servers as well as tools such as Spine, Tiled, Rive etc.
They called Defold "open source" at the beginning and only changed the wording later when people started reacting, so this could be an artifact left from that.
Yes it does, it’s one of their stated goals: “Prevent the Defold software from being commercialised by a third-party.”
Dare I ask why?
> Seems fair, but sadly not OSS.
Which of their license changes makes you feel sad and why? Were you planning to sell their editor?
The current license makes it unclear whether it would be a violation to distribute a commercial game that has a built-in map editor.
For an unusual license, it is sort of impressive that this is the only issue folks can come up with in this thread.
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.
It’s not an actual problem. Games don’t ship with the editing tools from the engine because engine editing tools aren’t suitable for that purpose.
That would be like shipping photoshop with your game to allow people to customize their character’s hair color.
I think there's a misunderstanding about the license. The license doesn't care at all about whether or not you're using the tools from Defold. They care about whether or not you're giving the ability to modify game content in a commercial product.
> “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.
After reading the license more thoroughly this is actually even less of an issue. The key thing about the wording is that it says you may not sell it “as a game engine product”.
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.
I agree with your emphasis on 'as' in 'as a game engine product', and I think you're making a good point.
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.
Plenty of games have, with the most famous example being Valve's games, which (eventually) ship the same tools Valve uses for game creation.
Shipping the custom tools the developer built to make content for their game is relatively common.
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.
You wouldn’t ship your game with built in editing tools from the engine. Those editing tools are not restrictive enough to just hand out to the general player base. They’re too powerful and too hard to use.
Maybe they would (different games foster different cultures). Maybe they'd use it as a starting point and derive something more friendly.
Maybe, but this isn’t remotely common with existing open source game engines.
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 have have to write your own map editor if you want to sell it, yes.
The license doesn't indicate that you can get out of the terms by developing your own map editor. A map editor would qualify as a game engine product because it can edit game content and their license specifically prohibits you from redistributing a game engine product that's built with Defold.
If the map editor is an extension (and they have lots of example extensions on github, all of which I've checked are under normal open source licenses) rather than a set of patches to the core code itself, it isn't subject to the Defold License in the first place.
(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)
> I wonder where a game with built-in editor ranks
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.
I remember this was initially developed at king games (candycrush saga authors) before they got acquired. Probably that's the reason for the weird licensing model
Yes, you are correct. An MIT license was preferred by the Defold team but the modified Apache license was what was decided upon in the end.
There are a lot of reasons to go "source available", such as preventing hyperscalers or enterprises from lifting your product.
Here's some commentary I made in another thread on this post:
https://news.ycombinator.com/item?id=43728095
What product? They aren't selling anything. Like at all.
This looks similar to the classic "enterprise support" and "distribution" lifestyle business play, which is incredibly sustainable and benefits both the software community as well as the maintainers. From their website:
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/
[2] https://defold.com/about/
[3] https://defold.com/open/
[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
Thanks, I honestly tried looking for that, but I couldn't find it.
> (and not trying to misuse "open source" like so many do)
They only stopped because of the backlash they received when they tried to. Their initial announcement was about "Defold becoming open source".
The Defold Foundation immediately stopped calling Defold open-source when it was pointed out that the license was in conflict with the OSI definition.
https://defold.com/2020/05/20/Some-thoughts-on-the-open-sour...
I've had a soft spot for defold, partly because they're unique in the gamedev space. For example, the GUI editor that is built-in is done in Clojure! https://github.com/defold/defold/tree/dev/editor (cljfx for the GUI, I am rooting for seesaw though :))
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.
It’s cool to see this mentioned. I worked on the editor back in the day. It’s actually the second IDE for Defold. The original one that we replaced was built on Eclipse.
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!
If it is King, then it's got a huge (financial) backer; King is one of the most profitable game publishers thanks to e.g. Candy Crush that made their revenue jump from $62 million in 2011 to $1.88 billion in 2013. It was bought in 2016 by Activision Blizzard, which in turn was acquired by Microsoft in 2023.
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.
Given the addictive nature of Candy Crush it’s a little bit like a drug lord building a hospital.
Candy Crush is less deadly than drugs, but a game engine is less useful than a hospital
AFAIK, King spun Defold back out as a foundation.
Yes, this happened early in 2020. Defold has been a public product longer with the Defold Foundation than with King. King has not been affiliated with Defold for a very long time.
Defold has been there for a while, not sure of why this in on the front page right now. Anyways, Defold is good, the community, docs etc. are on the lower side as compared to Godot.
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.
Because this story about Lua made the front page and they use Defold
https://news.ycombinator.com/item?id=43723088
I cannot stress enough how much I love Monogame. Its been a joy to work with.
Related ongoing submission here[1], about a game with 60k LOC of Lua using this engine.
[1]: https://news.ycombinator.com/item?id=43723088
I remember when Unity first appeared and what it felt like to read its materials, its pitch. It was like... whoa, this might actually be something.
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. :)
Godot does support consoles, they just choose to move that to third parties. There's community Switch support if you're a registered Switch developer, and W4 Games licenses export plugins.
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.
Yeah I really like Godot and you're right, the third parties are working hard on that front. It's been a trial for them though.
I guess the roots with King have made things easier for Defold?
i wish people would stop mentioning W4 Games as a porting option. their lowest revenue tier costs $2000 a year. most indie games sell a few hundred copies.
You'd be hard pressed to find console support for much less than that - compare it with Unity or GameMaker's console support tier and you'll find it's pretty similar.
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!
Most indie games sell on Steam/Steam Deck first and port to consoles later, usually after being picked up by an indie publisher.
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.
That third party is owned by Godot's leadership and management. Your Godot contributions go towards their pockets.
Here's a list of other 3rd party porters: https://docs.godotengine.org/en/stable/tutorials/platform/co... Stop spreading FUD. It's FOSS. It's like saying contributing to systemd lines the pockets of Red Hat.
The situation with systemd cannot be compared to special circumstances of Godot and shady practices of its management. It's an essentially open core but privately owned product. I guess this is a better arrangement than Unity but it is not a true FOSS engine in the sense of the word.
How do you expect W4 games (or any other porter) to release FOSS exporters to proprietary consoles, when they rely on SDKs that are covered by an NDA?
Exactly, read Lua and got out instantly.
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).
If you just want static typing, you can write Typescript and compile to Lua: https://typescripttolua.github.io/
The Defold site recommends:
> Optional typed Lua using Teal.
https://defold.com/product/
https://defold.com/assets/teal/
https://github.com/teal-language/tl
Also https://ts-defold.dev/
They recently added C# support: https://forum.defold.com/t/defold-c-support/79479
C# support is still experimental and under development, but it is at least ready for testing for those that are curious. Note that it is C# with Native AOT so it's compilation and linking involved, not "scripting and hotreload".
I'd love to see a more in-depth comparison in terms of features with Godot. Seems the latter is much more advanced, at least in 3d capabitilies.
Defold isn't really intended for 3D games at all. It's got a much stronger focus on 2D mobile/web.
Not entirely true, but sure, there are fewer bells and whistles in Defold compares to Unity, Unreal and Godot when it comes to 3D.
Here's a recently released 3D game made with Defold: https://forum.defold.com/t/cashchubbies-island/78183/22
I’ve used to follow this few years ago. This is a game engine created by King that they then set free after deinvesting from it themselves.
How does it compare to Löve 2D, other than shipping with a IDE? Looks like Defold supports more platforms, but I guess there are some strings attached since packaging games for various consoles usually come with very non-open dependencies.
https://love2d.org/
Looking into the code ... Wow ... This is not C++, it is C with classes ... https://github.com/defold/defold/blob/dev/engine/dlib/src/dm... Any reasons to use these wrappers instead of modern C++ capabilities?
There's a great post on that by the lead Defold dev: https://defold.com/2020/05/31/The-Defold-engine-code-style/
In the game industry, "C-like C++" is the norm. Games often don't use modern C++ features like exceptions, RTTI, multiple inheritance, etc. for very good reasons.
How does this compare to something like Godot?
It's less featured and has limited 3D support, but Defold is great for making smaller games aimed at the web or mobile. It has a much smaller binary size and it's generally more stable, especially in terms of physics. If you take a look at the showcase it's mostly webgames and a few smaller indies.
Thank you, I started Godot recently and I'll take a look at Defold as this is the exact thing I am doing - and Godot seems a little unstable with the APIs. Every tutorial I find is for Godot 3, and Godot 4 seems quite changed.
The version 3 to 4 transition was used to make breaking improvements to many things. The API is intended to remain stable within major versions. The docs also cover the major API changes from 3 to 4 and comprehensive docs exists for both version and you can still use Godot 3 if you want to.
google "godot 4 tutorial", not "godot tutorial"
is Teal widely used? https://github.com/teal-language/tl
Teal to lua is what typescript to javascript
No. But I've used it for Pico-8 development. I had to write a tool that turned it into mygame.tl into a mygame.p8 cart on save though.
I tried to use Teal before and had some issues even getting it to compile ... but the Lua language server actually has pretty good type checking.
Another option is https://typescripttolua.github.io/
No, but Luau (which is more of a fork) from the Roblox studio is seeing growing adoption. Notably, it was used for Alan Wake 2.
I was curious about VR development, and after reading this, I'm still not sure: https://forum.defold.com/t/official-refold-stance-on-vision-...
Scripting in Lua sounds good.
For small scripts. Lua is a huge minefield
That seems kind of unfair.
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.
I remember some years ago we got somebody joining irc.perl.org #perl to ask for help replacing perl with lua as a game scripting system.
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)
FWIW, Factorio is primarily C++, with Lua for mods and map editor.
… space age is a mod.
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.
> - It's really perfectly ok if you use competently.
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
https://blog.luden.io/what-do-i-think-about-lua-after-shippi...
Am I correctly understanding that this is a for-profit endeavor that’s relying solely on donations?
It's also being funded by a number of corporate sponsors. As I understand it, a studio or publisher will fund the development of a specific feature, while general development is mostly just spare time and donations.
No, Defold is developed by six full time and two part time developers. All developers are fairly compensated. Most of the work done on the engine is "general development" funded by corporate partners, studios and publishers. There is quite a bit of overlap between the needs of specific partners and the general development roadmap.
Looks like they offer paid support, and the console branches obviously aren't public so you'd have to make a deal to access those.
No. Wrong. Console branches are available for free if you are approved by the vendor.
Noticed it wasn't on Nixpkgs, so... https://github.com/NixOS/nixpkgs/pull/399843
Does anyone know if Defold can be used without the UI? Eg. just running it as a library or using scripting to do everything the game engine UI can do.
Purpose is just to try to get an AI to generate code with it.
In theory yes, data is just stored in json and there's a CLI utility [1] for building. It's pretty awkward though.
[1] https://defold.com/manuals/bob/
No, data is stored in protobuf text format (and at runtime compiled to binary protobuf files ofc).
Defold is good, been around a very long time, but it's just rough around the edges, once you get used to it it's pretty smooth sailing though.
Related: code-oriented C++ 2D game engine - Axmol Engine. It's an actively maintained Cocos2D-x fork: https://axmol.dev
So, it mentions to support PS4/5 and Switch but doesn't mention FreeBSD? Both these platforms are FreeBSD based.
I am looking for a game framework that allows interactive programming like LISP for browser games. So far I have tried love2d, TIC-80, and defold. Fennel (Clojure like language for Lua) works with love2d and TIC-80, but I could not get emacs repl to connect to TIC-80. Also I couldn't get Fennel to work with defold. Maybe there's a way I haven't found yet, but for now the only way to achieve interactive programming is to use love2d (love2d + fennel + emacs repl).
https://vxlabs.com./2018/05/18/interactive-programming-with-... https://technomancy.us/188
If you get it working, please share..
I assume you've seen:
https://ertu.dev/posts/i-made-an-online-shooter-game-in-lisp...
In terms of maturity, how does this compare to Godot?
A game engine that's opensource and supports Linux. Love it
It's not open source, it's source available.
How many of these are there?
Ask-HN:
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
I'm building 2D computer game environments for musical performances and interactive installations. I ended up developing my own little engine. The current iteration is based on:
- 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.
Thanks for this!
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...)? :)
> EDIT: oh and is your engine something I can look at (or license or...)? :)
Unfortunately not, it's a private repo. I might open source it at some point in the future, though.
You can't create prototypes in Godot, etc to test out your idea but you want to try someone's half-baked project instead?!?
You do need to speak to someone.
If you mean me,
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.
Hey, my project is quarter-baked at most!
How does it compare to Godot?
Hopefully their build scripts are sane for native elf/linux support:
* -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.
After spending time with Cursor/Junie/Copilot etc., game engines are starting to feel slow and behind the curve. I’d love to see faster adoption and deeper LLM integration (as native features, not just some random third-party plugins). Whoever builds the first “Cursor for games” is going to disrupt the market.
If Unity ever wanted to regain market cap, now’s the time. The solution seems obvious from my armchair.
I am rooting for Godot here because it has a human readable scene file format.
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.
The JetBrains Rider IDE also works pretty well with Unity.
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)
The problem with Unity is not their marketshare of game developers (which they have in spades), but rather their market share of ads which they completely missed out on.
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.
of course that exists, it was posted on this site even! i wouldn't be surprised if there are several by now. check out Rosebud.ai
https://news.ycombinator.com/item?id=38868185
The market for bad games?
It’s not the brush that makes the artist.