FAQ

Frequently asked questions about the engine, using the engine and more.

Using luxe

What platforms can you develop for using luxe?

With the default workflow, you can deploy to Windows, Mac, Linux, and Web. 

Console support is on the way, starting with Switch.

You can deploy a project to those with a single click (or cli call), from any host platform. That means from Windows, you can deploy builds for Mac + Linux + Web, ready to publish somewhere like itch.io. Or from Linux, deploy for Windows etc.

The web target requires Web Assembly and WebGL2 by default, both widely available.

Which host platforms can you use luxe to develop with luxe?

The editor and engine work from Windows, Mac and Linux (many distros). 

What language is used when making a luxe game?

The primary language for game code is Wren, a small and elegant scripting language.

luxe adds features to Wren like compile time error checking, full code completion, jump to definition and other quality of life IDE experiences. The engine provides an official VS Code extension implementing all that.

Initially, the primary focus will be on Wren but we have other language support on the way (C# and more).

Is luxe code focused or editor focused? 

Both!

The editor is optional. It's a complement to the code only workflow, you don't have to even install it if you prefer working from code only. As a code first user you get a ready function and a tick function and can just start coding.

On the opposite side, through wires, modules and systems exposed to the editor, it will be possible to make whole games from the editor only. We're still working on getting there, but can be made to work that way already. It's important to us!

Does luxe have visual scripting?

It's not ready just yet, but it's currently in development. See the roadmap.

Is there a luxe hashtag for social platforms?

You should use #createwithluxe

Restrictions

Can I use luxe to make another game engine?

We made luxe to be a sort of platform for other tools as well. We want to see those types of workflows thrive, but we are also aware of the nuance.

So while possible, we have the following restriction in place.
Contact us but here is the gist:

If the tool/framework you create requires luxe, uses the luxe mechanics to serve it's purpose (outlines, modules, editors) and the user goes through the regular luxe download flow, and is within the luxe ecosystem, then it should be fine.

Otherwise, don't. Not yet.

luxe may not be used for...

  • military use
  • the gambling industry
  • crypto/NFTs/related

Source access

Will users get access to source?

Everything but the engine runtime core will readily available in the next days. Many existing users already have access to the core - but we'll have more news about wider access in the future.

Pricing

What is a seat? How does all that work?

A seat just means a single person. If you have a seat in whatever form, it's yours and is valid anywhere you are, regardless of where it comes from. e.g You can use it for whatever you need: contracting, freelance, your own games, etc. Our model is based on Pay-What-You-Should-If-You-Can , not strict enforcement.

Where can I manage my subscription?

Visit the subscription page for all the relevant links.

Can I get invoices or payment history?

Visit the subscription page for all the relevant links. The self service portal has your invoices and payment history.

Where do I manage multiple seats?

Visit the subscription page for all the relevant links. The self service portal is where you'd manage seats.

Why a subscription based model?

Software that requires ongoing dev or updates doesn't fit well with a single price model for several reasons in our experience.

Platforms and dev
Engines and games often require updates after release, release isn't the end of it. Several platforms require updates over time in order to keep the game available.

Did you know if you release a game on consoles (and other platforms), they require SDK updates to push builds? If you wanted to push an update for your game, you can get denied if the version of your SDK isn't up to date. The software might even stop functioning if not updated, it's a bit of a treadmill at times!

Pretending that it doesn't work that way is a bit unhelpful, so we prefer people understand the moving parts. That doesn't even cover fixes, improvements, or new features to the software!

Just existing on some platforms requiring ongoing maintenance which doesn't happen magically, someone has to do it.

Motivation and incentives
Imagine you had 10 users using your software, and they already paid a higher price once off. Now you need 10 more users... to survive the next month.

Where does the focus now lie? User acquisition! How do we attract new users? Maybe it's working on adding support for unnecessary tangential industries instead of games, maybe it's adding lots of shiny features outside of the original scope, maybe it's spending more time on marketing or outreach than on dev.

It's very often not going to be focusing on the users you already have, fixing bugs, polishing workflows and strengthening what matters day to day.

The way we view it, subscription based models incentivize focusing on keeping your existing users happy over infinite growth. We like that more.

Affordability
When we lived on a different side of the planet, software would cost an entire year salary to buy. That made it impossible for us to ever consider using it...

When subscriptions became around, we could finally use industry standard software, and be taken seriously more, even if only for 1 month at a time, to do freelance and other work. Don't underestimate the value of an affordable price! It can be life changing, as it was for us.

But subscriptions are evil!
I think it's more common that big companies looking for infinite growth for their shareholders, or needing millions for their c-suite salaries are the real issue, not the payment model itself. We believe it can be done in a better way and aligns well with our goals and needs as a game engine people need to rely on.

A lot of the issue stems from access to the software, not the payment model. With luxe that isn't a concern.

A subscription in a trenchcoat?
A lot of pay once licenses are actually just annual upgrades... which if worded differently, is an annual-ish subscription to upgrade. It's not that different! The big difference is more choice: monthly or annual.

In short...
We'd rather incentivize making the best version of our tools, making luxe affordable and reliable, and supporting the platforms we offer well over time.