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.
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.
So when you have an AI agent modifying your project you can actually understand what it did, vs. the unity yaml based format that is mostly unreadable.
Wonder if their Junie tool will support C# soon, the current features for other languages are already cool: https://www.jetbrains.com/junie/
(I got access to it cause I have the all products pack, pretty good so far)
Game developers don't bring nearly as much revenue as ad serving, which is a sad commentary on the reality of software development and the state of of the games industry.
It’s not the brush that makes the artist.
You can make proprietary changes to the engine without releasing them (unlike GPL). You can freely monetize games built with the engine, and they make some assurances that there won't be a bait-and-switch.
And finally, the reason why this is not Apache 2.0- you cannot monetize (forks of) the game engine itself.
This seems fair and carefully considered. Kudos to the team!
This is what sustainable "equitable open source" looks like. It keeps the team that built the product able to monetize, but it does so without harming or killing the community. The community has full access to the code and can modify it, make money from products made with it, and can presumably take over if the originating organization dies.
The company can choose which services to offer for free and which ones to charge a premium for. Cloud CI/builds and hosting seem like good monetization levers while leaving the engine and editor completely free of charge and open for development and modification. You can build a sustainable lifestyle business this way.
Database vendors should use licenses like this to prevent Amazon from stealing their work and bleeding their cash flow.
Redis and Elasticsearch should have done this before Amazon cloned their products, started making bank on managed versions, killed their monetization efforts, and turned their communities against them.
Matt Mullenweg should have done this instead of throwing a fit.
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.
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.
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.
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.
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?
Seems fair, but sadly not OSS. I wonder why they think it's necessary?
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".
(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.
Edit: clarity
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.
Tbh I'm a little more confused after reading this
Why?
There is the requirement to make the source code available (GPL), as far as I am informed, you can sort of get around this, by delivering the source code with the download, but then "don't advertise" it, as in hide it as much as possible without getting in legal trouble.
(My information may be a bit outdated here) Afaik, the Blender Foundation doesn't even bother to shut these projects down (they do get frequently informed about it, when people discover it).
And this even given the fact, that they would be easy to shut down. The reason for this, is used media in advertising. If you want to sell your 3D package, you need to show some impressive artwork which was created with said project.
Problem is, the images/animations these projects show off on their websites are a) not created with said Blender reskin, but usually in Blender itself and b) they usually don't have permission from the artists.
So even having this quite comfortable handle, BF usually don't care. Which tells a lot about the impact of such copycats.
My takeaway from all this is, the situation would pan out pretty similar for Defold, and they should just dare it and monitor the landscape.
Which of their license changes makes you feel sad and why? Were you planning to sell their editor?
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.
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.
Here's some commentary I made in another thread on this post:
Support [1] page:
> Please contact us at business@defold.se for more information on how we can help you publish great games made with Defold.
About [2] page:
> Product development, marketing, support and sales - Refold AB is owned by members of the Defold team and is contracted to perform most of the day to day work on the Defold product.
Open [3] page:
> Q: Is there still going to be a roadmap for Defold?
> A: The Defold Foundation has decided to no longer share a public roadmap at the beginning of each year.
Status [4] page:
> Defold will never change into a subscription model, request royalty payments, introduce licensing fees or in other ways charge for access to the main (emphasis added) product.
FAQ [5] page:
> Q: What kind of user tracking are you doing?
> A: We log anonymous usage data from our websites and the Defold editor in order to improve our services and product.
They're using a lot of SaaS typical for startup/business growth. Their forums are Discourse [6], they're running a bunch of analytics, SendInBlue for campaigns, etc. That in and of itself doesn't imply anything, but they do seem to be very mindful of their community's health and growth.
There are some very dedicated people at the wheel. It looks like they've carved out enough leeway for commercial and support offerings to sustain themselves and keep others from stealing it like Amazon and others have done to other open source projects in the past, all the while building a cool community-powered open game engine.
[1] https://defold.com/support/
[4] https://defold.com/status/
[5] https://defold.com/faq/faq/
[6] https://forum.defold.com/ ; Discourse is $100/mo or more for custom domains
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.
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...
Here's a recently released 3D game made with Defold: https://forum.defold.com/t/cashchubbies-island/78183/22
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.
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
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!
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?
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.
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!
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.
Purpose is just to try to get an AI to generate code with it.
Teal to lua is what typescript to javascript
Another option is https://typescripttolua.github.io/
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.
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...)? :)
You do need to speak to someone.
Unfortunately not, it's a private repo. I might open source it at some point in the future, though.
https://vxlabs.com./2018/05/18/interactive-programming-with-... https://technomancy.us/188
sylware•23h ago
* -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.