Oh hey, it's 2019...
And we're three months in :D

Wait a second, this seems familiar... ah yes dev log #7 was a year ago already! Whew.

2018 was a pretty great year for luxe progress. A lot of big questions were resolved, a lot of progress was made and a lot of potential unblocked. I also became maintainer of Wren with @munificent!

retweet this!

Progress previews

Throughout the post will be a random assortment of some of the things we've worked on over the year while pushing toward the preview builds. These are just for interest sake but should give more indications of what's already in place.

Everything is work in progress, these are previews, nothing is final (any UI, layouts, code - everything).

A brief tour

Below is a 6 minute video showing a brief tour of the very early editors.
The video is fast but it's supposed to be, and it shows things that are new, so we'll briefly touch on some important concepts.

entity + modifiers

luxe uses an entity centered workflow, where modifiers are attached to an entity to make them able to do things. Modifiers can be attached/detached at any time giving a very flexible system for gameplay. If you want your entity to look like a triangle, you attach a modifier to do that for you.

This is similar to other entity focused workflows but with a few important distinctions that will be covered in depth in a future dev log.

A brief tour of the early editor workflow

Obligatory 'delayed post preamble'
It's been a pretty busy year, switching full time jobs, moving to the opposite side of the country and other major life changes - you get the idea.

Anyone following this engine long enough knows that when time gets low, priority goes to the code (finishing the engine) first. Which is good news if you want to use luxe at some point, and bad news if you want to read about it while you wait :c If you've followed on twitter you've seen a few things going on.

More users?!
While I wanted to get the engine into more hands (which I did), it wasn't at the scope I had hoped for in the last dev log. The goal was to have the preview builds available to a wider pool of developers, but given the amount of time we had available, it wouldn't have been possible to manage all that.

We do have a bunch of great people trying it out and giving excellent feedback though.

Having around 20~ new users added alongside others, actively breaking everything trying to make stuff, really helps refine the most blocking issues. More users are being added all the time while I wrap up the last of the dev cycle implementation details.

preview of the tiles editor

2018 goals vs reality

So how did the year turn out, with regards to where we really wanted to be?
Some of these goals were ongoing, some of them emerged based on progress through the year.

deploying to multiple platforms from a terminal

goal: usable for me (but not done)

The one big goal for 2018 was to get to a point where I make a cohesive and whole game with luxe, and ideally not get blocked or have to dive into the engine to change things constantly. This is referring to bigger, more technical games that require custom rendering, custom gameplay systems and so on.

Not necessarily every developer would find that to be true (since I know the engine details inside out) and that doesn't mean it's complete or anything, just that it's usable to that extent for devs like me, already.

goal outcome: success

I'll be making bigger stuff with the engine going forward!
See the end of this post for info about that, and the dev streams.

goal: usable for others (pixel art games, high level workflow)

On the other end of the 'usable' spectrum, certain games don't need a lot of complex or technical stuff to make, and can get really far already.

I wanted to push that a little further as a way to make a game using the editors and engine systems via content only.

The goal here was to validate an editor only workflow (see below re: editors), and the project outlines, which define the base of a project type to work from. The project outline in this case, would provide things like camera handling, correct resolution handling, and make sure everything is configured for pixel art, ready to go.

attaching a custom modifier to an entity

The second part of this is a 'user side' module, which would provide easy to use AABB collisions, physics, player movement, player animation convenience, tile map collisions, triggers and events - all that fun stuff.

Combining the two, and making a game from them, means that I can test the editors, dependency/modules system, the worlds/entity systems, the way you add custom behaviours to the engine, the project outlines and more. It's a full picture kinda test. If I can give someone the engine and they can make a full game on their own, we're on a great track.

automatic conversion of tagged tiles to actor collision bounds

goal outcome: mostly done

I was hoping to get this done for this blog post and embed a playable demo and the timelapse video to create it, but ran out of time. Things left for that to be a success: hooking up the animations via UI, and the triggers aren't done. The rest is good to go! See the main video in the post above.

goal: usable editors (but not done)

Another key goal for 2018 was usable workflow that involves the editors + tools. At least the world editor to get things rolling, but editors have a lot of things that need to work well before they make sense (like undo, saving/loading, copy paste...).

preview of the world editor

re 'code vs editor': I get asked this a lot. While luxe can be used as a code only engine for code focused users, it's also intended to be used by those that want to compliment code with data driven content, and editor created content.

These things are not mutually exclusive, and having tools to compliment the different ways to reach a goal is very important. It's intended for users to use existing modules from others and not open the code at all, as described in the previous goal. You could also just never open the editor.

luxe is also for use in teams, where some people will see only the code and others will see only the editor. There's a whole range of games you can make, some are impossible to make with editors and some are impossible to make sense of as code only. We need both.

the (wip) tiles stack

goal outcome: success

You can use the world editor, tiles editor and ui editor already. You can manage projects and modules. Myself and several testers have successfully used it to make things with so far, including all the undo/redo and workflow things you'd expect.

goal: user workflow design unknowns

On the high level, I also needed to pin down as much of the big picture design requirements, so that projects wouldn't need to be rewritten in a month when everything changes (again). Iterative design driven coding tends to do that.

An older version of the scene view panel

An example: "how do you as a user, implement a custom script based system for the entities to use".

We've had at least 3 completely different versions of this. Refactoring that after finding design problems is crucial for the engine to make sense, and there are a lot of unknowns when implementing something new (especially when it's high level).

But, once the design is settled, the user workflow is well defined and typically doesn't change much.

custom user defined modifiers can have their UI generated automatically

goal outcome: no current major unknowns for preview

Definitely lots to be done, but I currently don't see any major design unknowns, at least as far as the first version of this as a usable engine is concerned.

I could be wrong though!

goal: rapid development cycles + user setup process

One thing I really like is when a user reports a bug and I can fix it in a few minutes, click a few buttons and it shows up on their end as an update. They can click a few buttons and hey look, the bug is gone. They continue with their game.

browsing samples of a locally installed module

Another thing that is nice is when I can just give a user a zip file and they can get tinkering on a game or prototype in a few minutes. The setup process should be fluid and just work.

Typically at larger scale updating like that isn't as clean cut, because of dependencies and scope, but especially now during active development being able to push many builds a day if I need to, is so important. The goal was to bring the CI up to speed, the module system integrated into it, and tools to make my workflow for pushing builds fast.

installing another version of a module

goal outcome: success

That's all good, dev cycles are fluid and fast for everyone involved. Setup is quick and most users haven't had any snags getting going.

goal: user facing preview builds

As mentioned above, it would have been nice but 1. I didn't get all the necessary parts in place for that to be possible yet 2. I wouldn't have had time to deal with that many people at once.

goal outcome: partial success

Partial because I did add a bunch more users and they're using the almost-preview builds, the goal was to get people other than me making things with it. That's already happening.

goal: exposure/feedback

The best case for luxe is when there are people making things with it and for it. And one good way to do that is to get people to know about it early, with enough warning that in the future when choosing for their next project - if viable - they can use luxe.

It's also easier to figure out what's missing and needed by showing people and talking about the engine first hand, in the context of what they're making or would make.

Updating the website last year really helped with getting more eyes to know about luxe as it's meant to be seen (news reached front page in communities), so there's been a lot more word of mouth continuing to build. That was motivating, but also kinda abstract because it was all online.

It's great to see visits from 156 unique countries

For context, I've always lived kinda remote and far away from any "scene", where events happen, or where there are people and studios that exist around me to talk to in person. So this was normal for me...

Moving closer
However in 2018 I moved to Vancouver! Just a few days later I was at SIGGRAPH showing the engine to friends and developers from all different backgrounds. Speaking with middleware companies, comparing notes with AAA devs, indie devs, engine devs from big companies, this all just happened naturally and was a really good experience. People got to see luxe first hand and I get immediate feedback, and lots of questions and thoughts. It was super motivating.

attending siggraph was a really good experience

Plus I live here now, there's a lot of smaller and indie studios, developers and creators that I can gather insight from and have been spending time with. There's a bunch of events, I went to the Full Indie Summit (really good talks btw), the Twitch Vancouver meetups have developers demoing games and people hanging out, plus several other local events.

goal outcome: success

It's been a busy and fulfilling year, and being a lot closer to many of my friends and developers that are interested in using luxe should make for a good year ahead. The opportunity to move was a huge privilege and a side effect of life changes, but it does help the engine a lot.

A random detour - wren/c#/c++

In dev log #5 I mentioned how other languages can be used later, blogged about here.

When I was testing out some implementation details for custom user systems I was curious how wren was handling performance of a specific system, and because of the above, I was able to run it in 3 languages alongside each other to compare. Instead of running all 3 languages at once (which I could do), I ran them individually so the test was easier to compare.

Here's the key facts:

• 3 languages: wren, c# with JIT (mono), c++
• take this test with a grain of salt. Mostly curiosity driven.
• rendering and low level systems managed by the engine
• debug vis + gameplay + measuring, handled from the wren game code
• entities and modifiers owned/managed by the wren game code
• shared engine level data containers for custom modifiers
  • in other words, the way each language works with the data is the same
  • only the tick code + accessing the data per language is different
  • measuring: tick cost + any overhead of talking to the data system
• system to measure: physics and pixel perfect AABB collision system for dynamic actors
  • see Towerfall Physics
  • each actor is dynamic, doing continuous per pixel stepping, at high speeds (which means big distances). Every tick, each actor does many collision and query tests! That's 1000+ tests against the spatial hash for collision alone, for every pixel moved, for every actor. Don't read too much into the numbers total, this is an expensive test :D

Here's the (unsurprising) key take aways:

• a bytecode VM is slower than a warmed up JIT vm (c# jit > wren)
• native c++ code is faster than both (c++ > c# jit > wren)
• The peak of the system in the c++ shows that wren holds up really well in comparison (10k vs 1k dynamic objects)
• The way custom modifiers access data, as designed, will work well for a large number of games (considering this relatively heavy system, written entirely in wren scripts, can still handle a reasonable number of objects)
• Dropping down to a faster or native language for a specific system will be fairly easy, as all the internals are shared and only the meaty code is ported

Play with some of the samples in your browser

Since I recently fixed some outstanding things with web builds, you can now play more of the samples in browser. These samples specifically require WebGL 2 and WebAssembly support.

View the samples

2019 and beyond, what's next?

Wrapping up the core systems

There are a few systems that need to be completed before preview, namely the animation system is undergoing a bit of a refactor after some higher level changes, and the particle system has been implemented but lacks any user facing APIs yet, and the prototype system (prefabs) had to be refactored based on findings in practice.

There's obviously a lot more work on editors, testing, API clean up, documentation, examples, and much more after that. However the preview builds should end up being fairly close to how things should be engine wise, and that means people can be using it and refining it going forward.

I'm going to avoid guesstimating anything, but I still can't wait to get this into your hands.

More outward focus - gamedev using luxe and luxe dev streams

Now that things are shaping up and most of the unknowns are known I'm interested in sharing more of the development and workflow. I'm planning to make a bigger project using the engine and while doing so, live streaming a lot of the development on it, and on luxe.

I'll be talking over engine design details, game design, programming and more.

Follow me on twitch.tv/ruby0x1 while you wait, but I'll announce the schedules/streams in advance when they're luxe related properly later.

Join the discord for live development updates

Remember the community conduct, and join us in the new discord server where we'll be doing polls, talking about the engine progress as it happens, showing off a bunch of in progress projects, and doing some development streaming in the near future. https://discord.gg/5Q8rGZ7

It's the best place to be for luxe news as it happens, as most things aren't "news" but are still fun to show.

News in other forms

You can follow news about luxe on twitter @luxeengine or by subscribing to the rss feed or using the mailing list sign up below.

I'd recommend signing up for the newsletter to make sure you never miss important info. We'll only email for big dev logs or when betas start.
You can sign up below or on luxeengine.com.

Booth 3D model shown is a piece of a model made by Gabby for Celeste.
Tiles shown using Cave Of Gallet by ADAMATOMIC.

Feedback and questions on this post can be posted over here, over email, or via twitter (@luxeengine or @ruby0x1).