I played around with it a few months back. Interesting project, but it never quite clicked for me. Sort of for the same reasons I bounced off Wren; both it and Luxe are more carefully structured and verbose than I want from something high-level, but not as flexible as something more low level. For ease of use I'd go with Godot, for control I'd go with something like Raylib.
It's worth noting though that I'm a hobby game dev looking to make smaller solo projects, and Luxe seems more conducive to studio workflows; there's an emphasis on artist-focused tooling, for example. Godot is the obvious comparison for a new open source-ish engine but it's really more of an Unreal competitor.
I'm still keeping an eye on it though, minimal docs/examples made it trickier to learn than it probably is (it is still in alpha after all). I'd highly recommend checking out the blog posts [0], they're great reads that go into a lot of detail.
I've been playing with this engine for a while. I really like the engine. For me the best features are:
- Scripting is really ergonomic, and fairly fast performance-wise. And if you need something to be really fast writing native extension modules for wren is pretty straightforward. So it's a choice between "reasonable" perf scripting and "fast" native code, which is much better than something like Unity where everything is kind of in the middle.
- Wren fibers (a form of cooperative threading) are fantastic for dealing with game logic (NPC state, game AI, etc) without introducing the complexity of true multithreading.
- The graphics/render module is extremely configurable. The whole render module is just a script that sets up a fast c++ execution graph, and you can modify/script this.
- The tools are very nice and a lot of care put into them. I don't use the editor too much, and mostly interact through code, but for things like level design it's really nice to have.
- Many game engines feel like a good fit for a large project or a small one but not both. Luxe is great for small jam games and full-sized projects. A project can be pretty much just a project file, a few configs and a script, or a large structure and the editor encourages (but doesn't enforce) a good project layout.
- Drawing is super flexible. You've got sprites and shapes and meshes and tiles and everything, but there's also an "immediate style" drawing api that is very high quality. Similar to having "Shapes" extension in unity but it's a first class citizen and built in.
- The "Modifiers" (which is Luxe's ECS-like component thing) took me a while to get used to using, and can be a source of friction at first, but once I got it it really feels like a better way to do things. And it's entirely optional so you don't have to if you're still learning.
- Outside of code and raw assets like images and mesh, almost everything is stored in ".lx" files which are very json-like, which can be really helpful for debugging and understanding what's going on, and on many occasions I've been able to automate stuff from script just by writing out or modifying lx files.
- Features and fixes are added constantly, but done carefully in a way that doesn't break existing code too often or without a clear migration strategy (glares at bevy).
It feels like an engine built for small teams and experimental workflows. Especially if you're looking for alternatives to Unity, I'd recommend it.
The "Restrictions" section is incompatible with ever being FOSS, and for people who don't care about that, there's no advantage to this over Unreal or Unity.
It's not pretending to be FOSS. Like other engines, you need to pay them if you make money.
But no advantage seems like a stretch? (or at least, in future, might be a stretch) They're aiming for a superior workflow for small games (e.g. making stylized rendering way easier for non-technical devs). Also their pricing is 10% of Unity's, which is itself around 10% of Unreal's.
Seems like there was a previous version of the engine that was written in Haxe [0]
> alpha - deprecated 2015~2016. unrelated to the new engine! view the new engine here - https://luxeengine.com/
Also, that old version used to be open source, but I think this new one isn't anymore. Old thread mentioned by @pvg still mentions being open source, but right now the repositories only have docs.[1]
From what I read once, Sven wanted to open source it to make it more stable and actually finish it but then realised that doing so could affect his business model
Sometimes, doing something is worse than doing nothing at all.
> For that matter, using licensing to restrict government abuse obviously isn’t going to work, because licensing relies on state enforcement of rights anyway. If the state itself is compromised, having a clever little license isn’t the failsafe the OES thinks it is. It’s really just asking the police to arrest ICE with extra steps. This isn’t hypothetical, this is already codified in the law: even the international treaties that govern copyright have explicit exemptions for government action related to security interests. A license like this one can only ever possibly do harm.
> It is worse than ineffective; it is wrong too, because software developers should not exercise such power over what users do. Imagine selling pens with conditions about what you can write with them; that would be noisome, and we should not stand for it. Likewise for general software. If you make something that is generally useful, like a pen, people will use it to write all sorts of things, even horrible things such as orders to torture a dissident; but you must not have the power to control people's activities through their pens. It is the same for a text editor, compiler or kernel.
The entire video game industry is presently mostly indistinguishable from the gambling industry, and cryptocurrencies are just a special case of cryptographic authentication.
That means these rules are subjective.
Does “military use” include selling games to soldiers to play them whilst on base? Seems like a strict interpretation would say “yes”.
Licenses like this are complete and total nonstarters for anyone serious. It’s risk and potential liability nightmares for no benefit.
Idk that I’d say it’s in 3rd place. My guess would be that something like Source Engine is 3rd.
Having worked with Unreal, Unity and Godot, Godot is extremely rough. It has a terrible scripting language, an abysmal script editing UI, all while lacking the sophistication of Unity and Unreal’s rendering. It gets way too much benefit of the doubt because it’s open source.
We desperately need an open source engine that can compete with Unity and Unreal, but we need to stop kidding ourselves that Godot is serious about filling that role. If they were they would’ve grabbed Lua (or JS, or Python, or anything well established) off the shelf, told devs to use the code editor of their choice, and focused on either building the best rendering pipeline they could with their limited resources, or focused on some sort of clever differentiating feature that Unity/Unreal won’t implement. As it is it’s clear Godot’s team is more interested in reinventing wheels for fun than in making a real contender.
Source isn't really a publicly available engine. Valve doesn't appear to have much interest in licensing it.
You're not wrong about Godot, but;
1. You can always fork/modify it. Getting a source code license for Unity is a 6 figure proposition.
2. Being open source is a big deal. No phone home spyware(Unity). Keep 100% of your revenue.
3. C# support is OK. Its very slowly getting better.
I'm not a Godot zealot, one if it's biggest weaknesses is a community incapacitated of criticism. But still, your getting something very capable for small scale projects for free.
Unity, if Microsoft brought them out and fixed the business side, would easily be my engine of choice.
I learned to program in it. But I don't trust Unity the company. Every time you turn around they're laying off more people or doing something else strange.
Unreal is very bad for the smaller scales projects I actually build.
Lately I've been making weird prototypes using niche engines. I like Raylib, but it's just a rendering system. It's a much harder path to getting a game made.
If you know someone building a better Godot let me know. I'll try it this weekend.
A modified Source 2 is kind of available right now with S&box. It uses C# with the latest .NET, no Mono. Not open source but licensing should be better than Unity.
> If you know someone building a better Godot let me know. I'll try it this weekend.
Three.js is better than Godot. Yes, even though it doesn’t have a real editor. Yes, even though it’s exclusive to the web. It is a useful and functional tool for building 3D experiences. It has compatibility with almost every file type under the sun. It supports modern/cutting-edge features like WebXR. It has a talented and disciplined maintainer (mrdoob) who has steered the ship for almost 15 years through many big changes while maintaining the same solid core. It has hundreds of easily browsable examples that are kept working and up-to-date.
I wish we were in a better place, but honestly this is where we’re at. If you want to build 3D games/experiences and want an open source stack, use Three.js and stick to the web. There are no good options for native.
In 2025, Godot games are being released at 40% the rate of Unreal games. This number is growing for Godot at +100% Y/Y, while Unity + Unreal are growing at +15% (https://steamdb.info/tech/Engine/Godot/?max_release=2025-12-...). By this metric at least, it's a very secure 3rd (with GameMaker in a distant 4th), and could take 2nd in as few as 3 years.
I mostly do agree with what you said, but the project seems (slowly) headed in generally the right direction, and as time goes on, the space of games that only Unity can make will diminish. It's a totally defensible choice for almost any 2D indie game -- which wasn't true just two years ago -- and it's working towards being a viable alternative on XR and consoles too.
> We desperately need an open source engine that can compete with Unity and Unreal
I think this is a pipe dream. There's a lot of money behind Unity and Unreal, that buys a lot of developers.
Actually I think it's amazing how far Godot has come, and what kind of amazing and big updates they regularly do given how little money they get, and being open source.
It's seeing a lot of active development, so it's definitely not in its final form yet. It can still grow to be serious about filling that role...
> As it is it’s clear Godot’s team is more interested in reinventing wheels for fun than in making a real contender.
This is just a bad faith attack on the Godot's team, and not very much appreciated I'm sure.
> I think this is a pipe dream. There's a lot of money behind Unity and Unreal, that buys a lot of developers.
I don’t think it’s a pipe dream. I watched Blender slowly build up from a “nice thing for hobbyists” to “actually kind of professional grade” to “the tool used to make an Oscar-winning film”. Blender and its Foundation provide a blueprint for how open source projects can mount a meaningful challenge in a highly complex and cutthroat space, and anyone looking to do the same for game engines should study their moves.
> This is just a bad faith attack on the Godot's team
I may have been rude, but I was not arguing in bad faith. The decisions they’ve made and their fumbled execution (I could rant for an hour about GDScript’s copious footguns and bad design choices) do not comport with what I expect from a project that wants to one day take on Unity and Unreal.
If Godot is in fact just a fun little hobbyist thing, then yeah, they don’t deserve this level of vitriol from me. But if that’s the case, their community needs to stop overhyping them and suggesting Godot every time people have complaints about Unity/Unreal.
Curious, could you elaborate on what you find terrible about it? I’ve been toying around with GDScript for a little while, and I think it’s actually quite well-suited for developing 3D games.
Or, they get a lot right with gradual typing, reference counting, and low-cost marshalling between native code and the script VM. The language authors know it’s a DSL, so they add specific features such as `$` and `@export` that are idiomatic to the engine’s architecture.
Ironically, both features you mention are ones that seem questionable. `$` feels like a bit of an anti-pattern to me because it encourages hard-coding strings, so if you move, rename, or switch components around, it silently breaks. Unity's encouragement of pointers feels cleaner.
Godot has `@export`, but also `@export_multiline`, `@export_dir`, `@export_global_file`, etc. which produce slightly different behaviors. Unity supports true metadata through C# attributes (https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...) -- with all the power of C#, so you can freely add multiple attributes with parameters (which themselves are type-checked) and even program your own custom ones. You can add custom C# attributes, then use those attributes to drive the display of the inspector, which is a perfect little DSL solution that -- because of GDScript -- feels very far away from Godot at the moment.
Can you please elaborate what you mean by Unity "pointers"? As far as I am aware, in Unity, either you find the node by name via `GameObject.find` or you assign a reference via the inspector. Both of these features also exist in Godot. Actually, thanks to unique names (the `%` notation), I'd say Godot wins overall. But I haven't used Unity in years, so I don't know if they've come up with a better solution (in which case Godot should, obviously, copy it).
I think the concept of a game DSL is cool, but it just feels so undercooked to me.
Like, I'm a huge fan of gradual typing, especially TypeScript's, but gdscript's is just so primitive. Not even to speak of something like intersection or union types, even something basic like an interfaces mechanism is missing. has_method is an awful substitute - in general way too much relies on strings, making even simple refactoring a headache and breaks autocompletion. Lots of things also just aren't typable e.g. because generics are missing, pushing one to Variant. These aren't deal breakers, especially for the small-ish projects I've done, but it just feels bad.
A 'fully realized' version of gdscript would probably be great, but as is I'm just really not very fond of it and progress currently isn't exactly happening at a rapid pace (which is of course understandable).
Also - and this is definitely a lot more subjective - but I find its C++ FFI pretty ugly, even for basic stuff like working with structs. In theory using gsdcript as glue and C++ for the more core things would be a great approach (like unreal with its blueprints), but in practice I just want to avoid it as much as possible.
Yeah like I very much respect their work, and there is some genuine beauty in having this policy such as "have access to > 100k USD in the last 365 days, this tier is for you" or the fact that they seem dedicated to also support small indie creators. However this does differentiate them from true FOSS solutions.
Note that small game devs have many types, and I imagine these "boutique" pricing solutions can work for many.
>Business - If you need more than 16 seats, or you have access to > $1m USD in the last 365 days, this tier is required, you must contact us to customize pricing.
Customized pricing is very scary. It's whatever we feel like charging you under NDA. Why would I pitch this to my boss over using Godot under an MIT license?
Given that the prices are going up in with each tier, and you can get into that tier just by having a lot of money (x users OR x money), I'm not optimistic it'll be cheaper per user.
It's "source available", not open source. Unreal is "source available" as well.
> Where do you see an NDA?
The top price tier says
> If you need more than 16 seats, or you have access to > $1m USD in the last 365 days, this tier is required, you must contact us to customize pricing.
This is really weird, honestly. If you hire a 17th seat your pricing goes from $50/seat/mo to... what? How do I plan around this jump?
I would also like to know what happens if my subscription lapses. Can I continue to use a version I previously downloaded? What if luxe goes out of business or, heaven forbid, suddenly increases their pricing to unsustainable levels? With Unreal I can keep using an old version.
Thanks. Though, I guess I didn't make myself clear. To sell me on the engine working on the web I'd need to see a high quality game/demo running on the web. Instead, the links are to a bunch of game jam games that look no better than raw JS and then several native only games. I'm not trying to diss the engine. It looks great. Rather, I'm suggesting that impressive instant live demos speak louder than words.
I played around with it a few months back. Interesting project, but it never quite clicked for me. Sort of for the same reasons I bounced off Wren; both it and Luxe are more carefully structured and verbose than I want from something high-level, but not as flexible as something more low level. For ease of use I'd go with Godot, for control I'd go with something like Raylib.
It's worth noting though that I'm a hobby game dev looking to make smaller solo projects, and Luxe seems more conducive to studio workflows; there's an emphasis on artist-focused tooling, for example. Godot is the obvious comparison for a new open source-ish engine but it's really more of an Unreal competitor.
I'm still keeping an eye on it though, minimal docs/examples made it trickier to learn than it probably is (it is still in alpha after all). I'd highly recommend checking out the blog posts [0], they're great reads that go into a lot of detail.
[0] https://luxeengine.com/blog/
I've been playing with this engine for a while. I really like the engine. For me the best features are:
- Scripting is really ergonomic, and fairly fast performance-wise. And if you need something to be really fast writing native extension modules for wren is pretty straightforward. So it's a choice between "reasonable" perf scripting and "fast" native code, which is much better than something like Unity where everything is kind of in the middle.
- Wren fibers (a form of cooperative threading) are fantastic for dealing with game logic (NPC state, game AI, etc) without introducing the complexity of true multithreading.
- The graphics/render module is extremely configurable. The whole render module is just a script that sets up a fast c++ execution graph, and you can modify/script this.
- The tools are very nice and a lot of care put into them. I don't use the editor too much, and mostly interact through code, but for things like level design it's really nice to have.
- Many game engines feel like a good fit for a large project or a small one but not both. Luxe is great for small jam games and full-sized projects. A project can be pretty much just a project file, a few configs and a script, or a large structure and the editor encourages (but doesn't enforce) a good project layout.
- Drawing is super flexible. You've got sprites and shapes and meshes and tiles and everything, but there's also an "immediate style" drawing api that is very high quality. Similar to having "Shapes" extension in unity but it's a first class citizen and built in.
- The "Modifiers" (which is Luxe's ECS-like component thing) took me a while to get used to using, and can be a source of friction at first, but once I got it it really feels like a better way to do things. And it's entirely optional so you don't have to if you're still learning.
- Outside of code and raw assets like images and mesh, almost everything is stored in ".lx" files which are very json-like, which can be really helpful for debugging and understanding what's going on, and on many occasions I've been able to automate stuff from script just by writing out or modifying lx files.
- Features and fixes are added constantly, but done carefully in a way that doesn't break existing code too often or without a clear migration strategy (glares at bevy).
It feels like an engine built for small teams and experimental workflows. Especially if you're looking for alternatives to Unity, I'd recommend it.
This looks neat. It uses Bob Nystrom's Wren language for scripting and has been in development for a few years.
The "Restrictions" section is incompatible with ever being FOSS, and for people who don't care about that, there's no advantage to this over Unreal or Unity.
It's not pretending to be FOSS. Like other engines, you need to pay them if you make money.
But no advantage seems like a stretch? (or at least, in future, might be a stretch) They're aiming for a superior workflow for small games (e.g. making stylized rendering way easier for non-technical devs). Also their pricing is 10% of Unity's, which is itself around 10% of Unreal's.
this is dope, made by an all female team.
hopefully the games industry gets more female led, minority led studios
[flagged]
https://anypercent.studio/team/ ?
Yes, both the programmers are male.
Ah, you're one of those. plonk
Well they're not female are they. So it's not an all-female team, nor is this project female-led.
Are you looking at the different page by accident?
> luxe itself is written in c++
Wasn't it written in Haxe originally or am I confusing it with something else?
Seems like there was a previous version of the engine that was written in Haxe [0]
> alpha - deprecated 2015~2016. unrelated to the new engine! view the new engine here - https://luxeengine.com/
Also, that old version used to be open source, but I think this new one isn't anymore. Old thread mentioned by @pvg still mentions being open source, but right now the repositories only have docs.[1]
0: https://github.com/snowkit/old-haxe-alpha
1: https://github.com/luxeengine
It does still mention source here as well https://luxeengine.com/faq/#source-access
Sounds like they might be switching to a source-available model rather than an open-source model.
Armory maybe?
Luxe was initially written in Haxe and they migrated to C++ eventually.
https://news.ycombinator.com/item?id=16616052
Armory did, and it does still look like it's using Haxe - https://github.com/armory3d/armory/wiki/setup - it bundles it in.
A thread in 2018 https://news.ycombinator.com/item?id=16615251
Interesting that they intended to release it as open source in the past, but have instead stayed proprietary.
From what I read once, Sven wanted to open source it to make it more stable and actually finish it but then realised that doing so could affect his business model
Unrelated to https://sillysoft.net/lux/ (I know the spelling is different)
I really wish I was a video game dev. Alas.
I see two games in progress by the engine authors' studio mentioned, but has anyone actually shipped a game in this framework?
I love this bit <3
Sad to see this kind of anti open source licensing which reduces real code reuse.
Yeah, I planned on doing a crypto lottery game with NFTs and bombs as a consequence of losing. Such a shame really.
interesting because you could still make gatcha games which is just like digital gambling
Or you could use it to promote vaping, or a cult! How exactly would you write terms of service to preclude gatcha games? No in game transactions?
Gacha games are unquestionably gambling but you're right that there are loopholes here.
Perfect is the enemy of good.
Sometimes, doing something is worse than doing nothing at all.
> For that matter, using licensing to restrict government abuse obviously isn’t going to work, because licensing relies on state enforcement of rights anyway. If the state itself is compromised, having a clever little license isn’t the failsafe the OES thinks it is. It’s really just asking the police to arrest ICE with extra steps. This isn’t hypothetical, this is already codified in the law: even the international treaties that govern copyright have explicit exemptions for government action related to security interests. A license like this one can only ever possibly do harm.
https://blog.giovanh.com/blog/2021/10/29/ethical-source-is-a...
And if you want something more old-school:
> It is worse than ineffective; it is wrong too, because software developers should not exercise such power over what users do. Imagine selling pens with conditions about what you can write with them; that would be noisome, and we should not stand for it. Likewise for general software. If you make something that is generally useful, like a pen, people will use it to write all sorts of things, even horrible things such as orders to torture a dissident; but you must not have the power to control people's activities through their pens. It is the same for a text editor, compiler or kernel.
https://www.gnu.org/philosophy/programs-must-not-limit-freed...
The entire video game industry is presently mostly indistinguishable from the gambling industry, and cryptocurrencies are just a special case of cryptographic authentication.
That means these rules are subjective.
Does “military use” include selling games to soldiers to play them whilst on base? Seems like a strict interpretation would say “yes”.
Licenses like this are complete and total nonstarters for anyone serious. It’s risk and potential liability nightmares for no benefit.
So no ssl.
It's neat, but not better than real open source solutions.
Pay is what you want unless your at work and then it's price is under NDA isn't friendly.
Godot is still probably the best FOSS engine right now. Arguably it's strongly in 3rd place behind Unity/Unreal.
Idk that I’d say it’s in 3rd place. My guess would be that something like Source Engine is 3rd.
Having worked with Unreal, Unity and Godot, Godot is extremely rough. It has a terrible scripting language, an abysmal script editing UI, all while lacking the sophistication of Unity and Unreal’s rendering. It gets way too much benefit of the doubt because it’s open source.
We desperately need an open source engine that can compete with Unity and Unreal, but we need to stop kidding ourselves that Godot is serious about filling that role. If they were they would’ve grabbed Lua (or JS, or Python, or anything well established) off the shelf, told devs to use the code editor of their choice, and focused on either building the best rendering pipeline they could with their limited resources, or focused on some sort of clever differentiating feature that Unity/Unreal won’t implement. As it is it’s clear Godot’s team is more interested in reinventing wheels for fun than in making a real contender.
Source isn't really a publicly available engine. Valve doesn't appear to have much interest in licensing it.
You're not wrong about Godot, but;
1. You can always fork/modify it. Getting a source code license for Unity is a 6 figure proposition.
2. Being open source is a big deal. No phone home spyware(Unity). Keep 100% of your revenue.
3. C# support is OK. Its very slowly getting better.
I'm not a Godot zealot, one if it's biggest weaknesses is a community incapacitated of criticism. But still, your getting something very capable for small scale projects for free.
Unity, if Microsoft brought them out and fixed the business side, would easily be my engine of choice.
I learned to program in it. But I don't trust Unity the company. Every time you turn around they're laying off more people or doing something else strange.
Unreal is very bad for the smaller scales projects I actually build.
Lately I've been making weird prototypes using niche engines. I like Raylib, but it's just a rendering system. It's a much harder path to getting a game made.
If you know someone building a better Godot let me know. I'll try it this weekend.
A modified Source 2 is kind of available right now with S&box. It uses C# with the latest .NET, no Mono. Not open source but licensing should be better than Unity.
https://store.steampowered.com/app/590830/sbox/ https://sbox.game/give-me-that
> If you know someone building a better Godot let me know. I'll try it this weekend.
Three.js is better than Godot. Yes, even though it doesn’t have a real editor. Yes, even though it’s exclusive to the web. It is a useful and functional tool for building 3D experiences. It has compatibility with almost every file type under the sun. It supports modern/cutting-edge features like WebXR. It has a talented and disciplined maintainer (mrdoob) who has steered the ship for almost 15 years through many big changes while maintaining the same solid core. It has hundreds of easily browsable examples that are kept working and up-to-date.
I wish we were in a better place, but honestly this is where we’re at. If you want to build 3D games/experiences and want an open source stack, use Three.js and stick to the web. There are no good options for native.
Three.js is no game engine, tho.
It can be used to create one and being all Javascript / HTML makes it totally approachable for a task like this.
In 2025, Godot games are being released at 40% the rate of Unreal games. This number is growing for Godot at +100% Y/Y, while Unity + Unreal are growing at +15% (https://steamdb.info/tech/Engine/Godot/?max_release=2025-12-...). By this metric at least, it's a very secure 3rd (with GameMaker in a distant 4th), and could take 2nd in as few as 3 years.
I mostly do agree with what you said, but the project seems (slowly) headed in generally the right direction, and as time goes on, the space of games that only Unity can make will diminish. It's a totally defensible choice for almost any 2D indie game -- which wasn't true just two years ago -- and it's working towards being a viable alternative on XR and consoles too.
> We desperately need an open source engine that can compete with Unity and Unreal
I think this is a pipe dream. There's a lot of money behind Unity and Unreal, that buys a lot of developers.
Actually I think it's amazing how far Godot has come, and what kind of amazing and big updates they regularly do given how little money they get, and being open source.
It's seeing a lot of active development, so it's definitely not in its final form yet. It can still grow to be serious about filling that role...
> As it is it’s clear Godot’s team is more interested in reinventing wheels for fun than in making a real contender.
This is just a bad faith attack on the Godot's team, and not very much appreciated I'm sure.
> I think this is a pipe dream. There's a lot of money behind Unity and Unreal, that buys a lot of developers.
I don’t think it’s a pipe dream. I watched Blender slowly build up from a “nice thing for hobbyists” to “actually kind of professional grade” to “the tool used to make an Oscar-winning film”. Blender and its Foundation provide a blueprint for how open source projects can mount a meaningful challenge in a highly complex and cutthroat space, and anyone looking to do the same for game engines should study their moves.
> This is just a bad faith attack on the Godot's team
I may have been rude, but I was not arguing in bad faith. The decisions they’ve made and their fumbled execution (I could rant for an hour about GDScript’s copious footguns and bad design choices) do not comport with what I expect from a project that wants to one day take on Unity and Unreal.
If Godot is in fact just a fun little hobbyist thing, then yeah, they don’t deserve this level of vitriol from me. But if that’s the case, their community needs to stop overhyping them and suggesting Godot every time people have complaints about Unity/Unreal.
As someone who has barely dabbled in GDScript, I'd like to hear about these design choices and footguns.
> It has a terrible scripting language
Curious, could you elaborate on what you find terrible about it? I’ve been toying around with GDScript for a little while, and I think it’s actually quite well-suited for developing 3D games.
Or, they get a lot right with gradual typing, reference counting, and low-cost marshalling between native code and the script VM. The language authors know it’s a DSL, so they add specific features such as `$` and `@export` that are idiomatic to the engine’s architecture.
Ironically, both features you mention are ones that seem questionable. `$` feels like a bit of an anti-pattern to me because it encourages hard-coding strings, so if you move, rename, or switch components around, it silently breaks. Unity's encouragement of pointers feels cleaner.
Godot has `@export`, but also `@export_multiline`, `@export_dir`, `@export_global_file`, etc. which produce slightly different behaviors. Unity supports true metadata through C# attributes (https://learn.microsoft.com/en-us/dotnet/csharp/advanced-top...) -- with all the power of C#, so you can freely add multiple attributes with parameters (which themselves are type-checked) and even program your own custom ones. You can add custom C# attributes, then use those attributes to drive the display of the inspector, which is a perfect little DSL solution that -- because of GDScript -- feels very far away from Godot at the moment.
Can you please elaborate what you mean by Unity "pointers"? As far as I am aware, in Unity, either you find the node by name via `GameObject.find` or you assign a reference via the inspector. Both of these features also exist in Godot. Actually, thanks to unique names (the `%` notation), I'd say Godot wins overall. But I haven't used Unity in years, so I don't know if they've come up with a better solution (in which case Godot should, obviously, copy it).
Just a reference in the Inspector. I like unique names too; I was just pushing on `$` specifically.
I think the concept of a game DSL is cool, but it just feels so undercooked to me.
Like, I'm a huge fan of gradual typing, especially TypeScript's, but gdscript's is just so primitive. Not even to speak of something like intersection or union types, even something basic like an interfaces mechanism is missing. has_method is an awful substitute - in general way too much relies on strings, making even simple refactoring a headache and breaks autocompletion. Lots of things also just aren't typable e.g. because generics are missing, pushing one to Variant. These aren't deal breakers, especially for the small-ish projects I've done, but it just feels bad.
A 'fully realized' version of gdscript would probably be great, but as is I'm just really not very fond of it and progress currently isn't exactly happening at a rapid pace (which is of course understandable).
Also - and this is definitely a lot more subjective - but I find its C++ FFI pretty ugly, even for basic stuff like working with structs. In theory using gsdcript as glue and C++ for the more core things would be a great approach (like unreal with its blueprints), but in practice I just want to avoid it as much as possible.
Yeah like I very much respect their work, and there is some genuine beauty in having this policy such as "have access to > 100k USD in the last 365 days, this tier is for you" or the fact that they seem dedicated to also support small indie creators. However this does differentiate them from true FOSS solutions.
Note that small game devs have many types, and I imagine these "boutique" pricing solutions can work for many.
The FAQ mentions source https://luxeengine.com/faq/#source-access Where do you see an NDA?
https://luxeengine.com/get/
>Business - If you need more than 16 seats, or you have access to > $1m USD in the last 365 days, this tier is required, you must contact us to customize pricing.
Customized pricing is very scary. It's whatever we feel like charging you under NDA. Why would I pitch this to my boss over using Godot under an MIT license?
I read that as cheaper in bulk, but I see what you mean.
Given that the prices are going up in with each tier, and you can get into that tier just by having a lot of money (x users OR x money), I'm not optimistic it'll be cheaper per user.
It's "source available", not open source. Unreal is "source available" as well.
> Where do you see an NDA?
The top price tier says
> If you need more than 16 seats, or you have access to > $1m USD in the last 365 days, this tier is required, you must contact us to customize pricing.
This is really weird, honestly. If you hire a 17th seat your pricing goes from $50/seat/mo to... what? How do I plan around this jump?
I would also like to know what happens if my subscription lapses. Can I continue to use a version I previously downloaded? What if luxe goes out of business or, heaven forbid, suddenly increases their pricing to unsustainable levels? With Unreal I can keep using an old version.
I'm surprised they do this. The unity rugpull is still fresh in memory and mystery pricing is scary for newcomers.
They’ll learn when there’s no sales
Have a look at the underrated Flax Engine: https://flaxengine.com/
What do you like specifically about it?
What has it shipped?
Maybe I missed them but given they say at the top of the page
> make games for Mac, Linux, Windows, and *Web*
it would help a bunch if they linked to some web demos/games
Some Jam Games with web builds:
https://itch.io/jam/luxe/entries?ref=luxeengine.com
https://ldjam.com/events/ludum-dare/56/terrarium-combinarium
https://joeld42.itch.io/bridges
More jam games that I didn't make a web build for but downloads are available:
https://joeld42.itch.io/lighthouse-keeper
https://ldjam.com/events/ludum-dare/54/cargo-space
https://ldjam.com/events/ludum-dare/53/last-mile
https://ldjam.com/events/ludum-dare/51/artichoke-key
On Steam:
https://store.steampowered.com/app/1836400/Mossfield_Origins...
Thanks. Though, I guess I didn't make myself clear. To sell me on the engine working on the web I'd need to see a high quality game/demo running on the web. Instead, the links are to a bunch of game jam games that look no better than raw JS and then several native only games. I'm not trying to diss the engine. It looks great. Rather, I'm suggesting that impressive instant live demos speak louder than words.
> luxe itself is written in c++
Good, it bodes well for the future of this game engine.
[dead]