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!
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, 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.
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.
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.
Fair enough. I guess what I am asking is: What is special about this license? Is it more permissive? Does it address a specific issue better than other licenses?
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.
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?
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.
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.
> 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.
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.
> - 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
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 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).
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.
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.
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!
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"
Honestly, not great, but that's the world we live in.
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).
Yeah, so I don't see how helping out the big players and not everyone else is a good thing.
>Multiple projects have gone closed-source from open source. Assurances are a nice thing to have (but certainly no guarantee).
Yeah but the open source ones ARE guaranteed. Even if they later become closed source, the code up till that point will remain open source forever. So it is guaranteed whereas "some assurances" mean nothing.
If you want your stuff to be private, you have a legal option.
> Yeah but the open source ones ARE guaranteed. Even if they later become closed source, the code up till that point will remain open source forever. So it is guaranteed whereas "some assurances" mean nothing.
I guess? Is that not the case here as well?
> 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?
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.
This is what sustainable "equitable open source" looks like. It keeps the team that built the product able to monetize, but it does so without harming or killing the community. The community has full access to the code and can modify it, make money from products made with it, and can presumably take over if the originating organization dies.
The company can choose which services to offer for free and which ones to charge a premium for. Cloud CI/builds and hosting seem like good monetization levers while leaving the engine and editor completely free of charge and open for development and modification. You can build a sustainable lifestyle business this way.
Database vendors should use licenses like this to prevent Amazon from stealing their work and bleeding their cash flow.
Redis and Elasticsearch should have done this before Amazon cloned their products, started making bank on managed versions, killed their monetization efforts, and turned their communities against them.
Matt Mullenweg should have done this instead of throwing a fit.
It is a really nice and fair source-available license and there should be more of this, but a license like theirs also restricts what kind of software you can make in a rather harsh way.
Since you can't commercialise game engine products and they are defined in a broad way. You could land in legal issues. Game engine products are defined in the license as:
“Game Engine Product” shall mean software used for video game development. This includes both the content authoring software and the software used to show the created content.
IANAL, but map editors, modding tools and many other kind of tools that can be used for developing video games could be in violation of the license.
Since meaning of "commercialise" isn't being defined or narrowed in the license small creators using Patreon or the like while asking donations could be classified as a violation too.
- 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.
Without RMS swinging hard one way and without Amazon swinging hard the other way, we would not have this license.
It is because all of these shenanigans that we now kind of have a license that solves these issues, and surely when the landscape changes again, a new license scheme will be needed.
Not a choice he had. You cannot relicense GPL code line that. He would have had to write a new system from scratch instead of forking an existing one.
If Mullenweg had been the original developer it would be valid criticism.
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.
Seems fair, but sadly not OSS. I wonder why they think it's necessary?
There is the requirement to make the source code available (GPL), as far as I am informed, you can sort of get around this, by delivering the source code with the download, but then "don't advertise" it, as in hide it as much as possible without getting in legal trouble.
(My information may be a bit outdated here) Afaik, the Blender Foundation doesn't even bother to shut these projects down (they do get frequently informed about it, when people discover it).
And this even given the fact, that they would be easy to shut down. The reason for this, is used media in advertising. If you want to sell your 3D package, you need to show some impressive artwork which was created with said project.
Problem is, the images/animations these projects show off on their websites are a) not created with said Blender reskin, but usually in Blender itself and b) they usually don't have permission from the artists.
So even having this quite comfortable handle, BF usually don't care. Which tells a lot about the impact of such copycats.
My takeaway from all this is, the situation would pan out pretty similar for Defold, and they should just dare it and monitor the landscape.
For a moment, I was thinking Defold ought to dual-license their engine under both the current non-OSS modified Apache and the GPL. That way, you'd have the option to either:
1. Commercialise software created using modified versions of Defold, without releasing the source of your modified version, as long as you don't commercialize your modified version of Defold itself.
2. Commercialise a modified version of Defold, but you must make the source available under the GPL. (Which would mean that source could be used by the upstream project as well.)
But while typing this up, I noticed the flaw in this plan—the parenthetical isn't true! Because the upstream project would be dual licensed, they couldn't use GPL licensed code.
Of course if they do, I hope they will say "either modified Apache or the GPL".
My company's lawyers made a big stink about us using jQuery plugins that said "and" instead of "or".
There’s no reason to assume that a paid fork would reduce the number of free Defold users; it can happen, but depends on what is built and offered, and sometimes paid forks are good for the ecosystem and increase the number of overall users.
(it's not)
If they do, look out.
Unlike Defold, both Godot and O3DE are actually free.
That number is vastly smaller.
If Godot games were making anywhere near the revenue that Untity games do, I’m willing to bet they’d there would be an Amazon fork.
(and it's still bigger for Godot)
It also doesn’t matter what the user base is today. It matters what it might be tomorrow. It’s not easy to change your license. If you wait until Amazon is coming for you, it’s too late to do anything to stop it.
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.
[0]https://rpginabox.com/
Edit: clarity
https://defold.com/foundation/
Why?
Tbh I'm a little more confused after reading this
Which of their license changes makes you feel sad and why? Were you planning to sell their editor?
It does seem like a bit of problem, but it also seems like a very specific thing that could be… cleared up, and then it would be all sorted.
That would be like shipping photoshop with your game to allow people to customize their character’s hair color.
> “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.
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.
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 website-summarized version of the license says:
> You can not commercialise original or modified (derivative) versions of the Defold editor and/or engine
It sounds like this would only be a problem if you're literally shipping a modified version of Defold. No game with any kind of financial incentive does this for a built-in map or mod editor, because it would make it incredibly easy for other people to then sell a modified version of their entire game.
It's kind of like if Apple made the Xcode source available, and then said "hey you can't monetize a modified version of Xcode." No one is going to ship their app's entire Xcode project to players just so the players can make a custom map.
The normal way for games to do this is to implement a brand-new map-editing UI inside Defold (or Xcode, Unity, Godot, etc.) that spits out custom maps in the exact data format that the game can parse.
Here's some commentary I made in another thread on this post:
https://news.ycombinator.com/item?id=43728095
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
They only stopped because of the backlash they received when they tried to. Their initial announcement was about "Defold becoming open source".
https://defold.com/2020/05/20/Some-thoughts-on-the-open-sour...
From what I understand it emerged from a gamedev studio from Sweden (King or something?) so there's commercial release pedigree there. I believe their console platform build/release tooling does cost money for game devs because the platform SDKs themselves impose restrictions. But I get the impression that defold as org does seem to put in earnest effort to be fair to game devs with licensing, etc. like others mentioned here.
A team of about 6 people replaced the IDE core and built a dozen tools over a year.
It was a fun project. Not many people can say they built a desktop gui with Clojure!
Ah, the wiki page also mentions the Defold engine, which was first developed in 2007 and acquired by King in 2013, then opened to its current licensing model in 2016.
Candy Crush is less deadly than drugs, but a game engine is less useful than a hospital
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.
https://news.ycombinator.com/item?id=43723088
This feels similar. Sometimes you can just tell by the communications and the spirit of the language that the team has the goods.
The fact that they have such comprehensive multiplatform export right now is big. One of Godot's biggest hurdles has been console support.
My ONLY beef, from what I saw, was that it was Lua only. If it was C# I would have been more excited. But at least it's not a full C++ recompile like SOME engines. :)
One of the reasons for this is because console plugins can't be developed in the open like the rest of the engine, because the console SDKs are behind NDAs. It's a pretty ridiculous holdover from when consoles were more specialized.
I guess the roots with King have made things easier for Defold?
It can take hundreds of dev-hours to port your engine to consoles yourself, so having another company handle it for you, for all 3 consoles, for only $2000 is a pretty good deal!
The $2000 is also to port to all three console platforms, it's $800 per. This makes it feasible to say, only target PlayStation with W4 and use the community Switch port.
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).
> Optional typed Lua using Teal.
https://defold.com/product/
https://defold.com/assets/teal/
https://github.com/teal-language/tl
[1]: https://news.ycombinator.com/item?id=43723088
Here's a recently released 3D game made with Defold: https://forum.defold.com/t/cashchubbies-island/78183/22
https://love2d.org/
Teal to lua is what typescript to javascript
Another option is https://typescripttolua.github.io/
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.
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
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.
Purpose is just to try to get an AI to generate code with it.
[1] https://defold.com/manuals/bob/
https://vxlabs.com./2018/05/18/interactive-programming-with-... https://technomancy.us/188
I assume you've seen:
https://ertu.dev/posts/i-made-an-online-shooter-game-in-lisp...
Context:
Every time a game engine like this pops up I read through the comments noting other engines and various perspectives and criticisms (positive and negative).
I have a game-like music composition project I want to pick back up. Media-intensive with a rich isometric/2D environment, with lots of little animations, which need to be synchronized to perfectly-scheduled audio events.
I develop fully-feature prototypes in the past, most recently on iOS for iPad before there was iPadOS... but using Core libraries hit a performance wall on hardware of that era.
Question:
Who can I consult with up front to get good advice on what technology path to pursue, to realize my project?
WebGL/Webasm would be fine. Cross-platform console targets would be fine. iPadOS would be fine and best, gestures are a core part of the vision.
...and I have no idea where and how to find my way into this.
I follow some GameDev feeds and naturally what I read about is very capable application of engines/environments which are quite close to what I need, but which are (naturally) targetting game dev.
Say you wanted to sit down and make a rich visual sequencer with some DAW-like features? What's the right approach?
It's not a traditional DAW, it's much more about a rich tiled game-like UX; it's not a game, with levels, maps, and such... it's got elements of both. The audio engine needs to be DAW-level, but, synchronized to graphical elements and UX and responsive to gesture in a way that's like game-level.
Any ideas welcome. I think I have a good (layperson's) understanding of the overal architecture I need; but I don't know how my conceptual map translates into different styles of game-engine or more general media-engines.
My hunch is my "solodev" state which was a blocker before when I had no time to quit the day job and learn eg. OpenGL for iOS, is significantly ameliorated today by code assistants... iff they are familiar with <the engine/platform>
Do Claude Code etc. know Unity dev? Engines like this one? I don't know! Naive.
Haaaaalp
- 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...)? :)
Unfortunately not, it's a private repo. I might open source it at some point in the future, though.
You do need to speak to someone.
Prototypes I already have made; at this point the goal is get something actually stable. I'm willing to look into any approach that has a stable application doing things that I need. I don't want to make another prototype; but I am open to trying an implementation that might not end up being final.
It's proven remarkably difficult to find who to even consult with. AFAICT it's too rarified a need.
* -static-libgcc (-static-libstdc++ if c++).
* glibc ABI selection, see binutils documentation, VERSION related page, the second part of this page. This must include the glibc internal symbols. It easy to check the proper ABI with tools like readelf (the VERSION name part), which will tell you everything.
* dynamic loading with fallbacks of all system interface shared libs.
That said, it is exactly the same for the other OSes, this is all about abstraction via tables of functions.
So when you have an AI agent modifying your project you can actually understand what it did, vs. the unity yaml based format that is mostly unreadable.
Wonder if their Junie tool will support C# soon, the current features for other languages are already cool: https://www.jetbrains.com/junie/
(I got access to it cause I have the all products pack, pretty good so far)
Game developers don't bring nearly as much revenue as ad serving, which is a sad commentary on the reality of software development and the state of of the games industry.
https://news.ycombinator.com/item?id=38868185
It’s not the brush that makes the artist.