Luxe Game Engine(luxeengine.com) |
Luxe Game Engine(luxeengine.com) |
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.
- 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.
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.
hopefully the games industry gets more female led, minority led studios
Wasn't it written in Haxe originally or am I confusing it with something else?
> 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]
You may not use luxe for the following, no exceptions:
* military use
* the gambling industry
* crypto/NFTs/relatedThat 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.
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.
> make games for Mac, Linux, Windows, and *Web*
it would help a bunch if they linked to some web demos/games
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...
Good, it bodes well for the future of this game engine.
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.
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.
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.
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.
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.
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?
> 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 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.
https://store.steampowered.com/app/590830/sbox/ https://sbox.game/give-me-that
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.
It can be used to create one and being all Javascript / HTML makes it totally approachable for a task like this.
> 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...
To go a step further. DRM is the bad kind of this, and it exists and is used by corporations to restrict freedom. You can't use an indie devs code for war or gambling is the good kind of this. More that and less corporate DRM, please.
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.
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.