Update Lua to actual version

Dear Amazon,

Do you have any plans about upgrading current Lua library used in engine, and which is kinda old, to most actual version?

1 Like

LuaJit would be indeed awesome! I will definitely stop by at your GDC booth.

Any plan to enable a whole app developed in LUA? if it’s the case, documentation is seriously lacking.

Hey @Kraken,

We are
in the process of supporting multiple versions of Lua in Lumberyard. The new AZ::ScriptContext
is already compatible with Lua 5.2 and 5.3. Actually we had to back port it
to 5.1. Please stay tuned as we will likely introduce Lua 5.3
support as part of a new Lua editor and debugger. We will be at GDC and if you
are around or come to our talks, you will be able to see the tool in action.

The main
reason why we want to support 5.1 is LuaJIT.
LuaJIT is considered one of the fastest dynamic language implementations, and it’s a drop-in replacement for Lua 5.1. Developers who use
Lua extensively (not just to marshal back and forth from C++) will see a big
performance gain.

@blitz

The short answer is yes, we are definitely planning for it
and there is still a lot of work to be done.

We are already working to expose as much as possible
from engine to script, and this includes both Lua and FlowGraph. We do that via
generic script reflection, so you have to reflect to script only once. In
addition we will provide Code-Generator that will accelerate the simple case
even more. In the new entity/component system (early version in Beta is already included) you can write an entire component in Lua, using the “Lua Script” component.

As we progressing on the effort, we are working very close
with the documentation and tutorial teams to make sure that you will have
plenty of great examples and exhaustive documentation.

great.

Lua and flowgraph use different set of exposed API right?

Currently yes. We are looking to achieve parity across scripting environments, so you don’t find yourself often in a situation where you can do X only from Lua and Y only from FlowGraph. In the future FlowGraph will be a super-set of what Lua supports and they will use the same API to expose functionality.

at this point (or GDC version), what’s the percentage of API exposed?

@Kraken

We have considered C# and other languages, instead and side
by side with Lua. It’s our goal to be modular. This is one of the main reasons
why we are switching to generic ScriptContext. The current focus is to improve
and make scripting consistent across different environments Lua, FlowGraph and Python
in the Editor. We want to make sure you can script as much as possible, and
have good tools to do so.

In general C# and similar languages have many advantages
like the ones you listed, they also presents us with extra challenges, like
more complex binding and the fact that some platforms don’t allow us to JIT. In
such scenarios we will either need to interpret and/or compile, which reduces
either performance or iteration time.

Please keep the feedback coming as this will help us make
sure we deliver the best tools for you.

@blitz

The current focus is to have consistent experience across
scripting environments, build a framework that allow easy reflection to script
and provide tools that will be allow you to write and debug scripts as easy and
fast as possible.

As part of the component effort we are improving the
building blocks of the engine and allowing you to write whole components in
script or FlowGraph. As we write those components we are exposing functionality to script as
much as possible. This is an ongoing effort and while a percentage is hard
to compute, the goal is that you will be able to control and script most
components (including engine systems).

@Rosen

Hi. Thanks for your answer, it clarified some things to me.

Just a small question: have you considered about integrating C# (via .NET Core) as scripting language, instead of (or side-by-side to) Lua?

There is some advantages in my opinion, like:

  1. Cross-platform. Same for Lua, but C# support it too :slight_smile:
  2. Visual Studio Communit Ed. as IDE (perfect for Windows developer - intellisense, decent debug, a lot of extensions and so on). In case of Lua & Linux/Mac there is pretty well ZeroBrane IDE.
  3. Run-Time changes are still supported.
  4. Compile scripts into executable - for those who prefer protect their scripts.
  5. Very well runtime performance.

@Rosen any info about the percentage of API to LUA at this point?

heart beats fast adrenaline flowing licks lips sighs dreams of what a wonderful world that would be

@KrakenIf you want to be closer to C#s syntax, look into Squirrel. Its essentially Lua with C similar syntax and a more controllable garbage collector with a bit of a speed decrease as a falloff, but the ability to control the garbage collector can help the you get that speed back through good memory management. Thing is you will have to get your hands dirty with Lumberyards source to implement it and do the bindings yourself by hand or through a Squirrel binding library.

2020/08/05
Debug.Log(_VERSION) => 5.1

I thank you for the good 3D-engine. But how soon are you planning to improve in this thread’s direction?