4 ms·

I enjoyed playing around with this a lot, and it was infinitely easier to make progress hacking around than Unreal or Unity. I got stuck because I couldn't get

I enjoyed playing around with this a lot, and it was infinitely easier to make progress hacking around than Unreal or Unity. I got stuck because I couldn't get over the lack of AAA graphics and physics that LOVR lacks, compared to Unreal... Lua also shouldn't be used. It's a beautiful tiny embedded language, but I don't want to use it, and I don't want you to use it either.

signa11 5y ago
may you please elucidate why you dissuade the use of lua ? thank you kindly!
- etaioinshrdlu 5y ago
  It's the automatic type coercion (strings <=> numbers), the overusage of tables as a universal data structure with bad API, the bizzare syntax. It might as well be Perl. I don't want you to use Perl either.
- lasagnaphil 5y ago
  Lua is a language that I started programming with, and has a special place in my heart even if has some crappy parts. The main issue I have with the language is with table accesses and 'nil'. Tables in Lua are the most fundamental type of object in the language, it can be either an array (1-based index) or a hashtable. In this language objects are basically just tables with fields in them, and with metatables you can basically emulate all the features in a typical OOP language (classes, inheritance, traits, operator overloading, etc.) Field access in objects are just table accesses (like what you can imagine with Javascript). However, when you try to access a field in a table that doesn't exist (such as 'print(table.key_that_doesnt_exist)'): no errors or exceptions are explicitly raised, it just silently returns nil. This is such a dealbreaker that makes the language much harder to debug than other languages (at least Javascript returns undefined, which is different from null! Oh well, that actually has problems of its own though....) Some more horror: global variables are also implemented as tables (imagine that there's a table _G at the top of the scope). This means that any spelling mistakes with variables will also just silently return nil, since if it doesn't find any variable names at the local scope, it tries to find at the global scope. The global variable thing was actually such a big problem that people came up with some voodoo metatable trickery script like strict.lua (https://github.com/deepmind/strict/blob/master/strict.lua https://github.com/deepmind/strict/blob/master/strict.lua) that prevents this from happening (a showcase of the language's power, but probably not its proudest). I'm sure you could also do this with table creation (make a wrapper function tbl() that automatically adds metatables to tables to prevent invalid field access, so every time you need to do things like 'pos = tbl({x = 1, y = 2})') But still, there isn't a solution baked into the language, and it's cumbersome to do this (and I'm not sure about the performance implications of this addition). Right now I'm trying to integrate Squirrel (http://www.squirrel-lang.org/ http://www.squirrel-lang.org/) instead of Lua as a scripting language into my game. Squirrel is an embedded scripting language that's hugely inspired from Lua, but also fixes this shortcoming of the language by making invalid table accesses runtime errors. And when you want to add new fields to a table you need to explicitly do so via the <- operator: table = {} // print(table.x) (Runtime error) // table.x = 1 (Runtime error) table.x <- 1 table.y <- 2 print(table.x) // Outputs 1 which is much more explicit and less error-prone.
  - vkka 5y ago
    Lua gives you means to build your object system anyway you want. A trivial example to protect a table below: local p = { x = 1, y = 2 } print( p.x, p.y ) setmetatable( p, { __newindex = function() assert( false ) end, __index = function() assert( false ) end } ) print( p.z ) -- you get assertion failure p.k = 12 -- you get assertion failure too
    - lasagnaphil 5y ago
      I’ve already mentioned how to do this with metatables. But you still need to wrap this in a function and call it every time, it’s quite cumbersome. And the whole thing falls apart when you start using other people’s libraries (For example, you enabled strict.lua in your codebase, but then it starts affecting other libraries which relied on the original Lua behavior… Or you’ve made your own object system, but that one library you’ve imported uses middleclass and another uses rxi.classic, and you need to go though the headache of making sure they’re all compatible)
- billfruit 5y ago
  Lua feels so rigid, inflexible compared to something like JS. If you want abstractions, and want functions to be first order objects etc, does Lua help. Does Lua have "eval" or something similar?
  - nonbirithm 5y ago
    Yes. You can compile Lua code with `loadstring("return 1 + 1")`, which returns a function that runs the provided code. `loadfile()` does the same thing with files. You can also change how the import mechanism works to load compile-to-Lua languages or similar. There are also first class functions and functional programming libraries. I'm personally a fan of luafun. Usually when programming Lua I can remember every detail of the language without having to consult a reference or wonder which library does what, because it's so simple. I understand that too much simplicity might be an issue for other people, though. I sometimes wish that JavaScript was as simple and easy to understand as Lua is, and Lua is also free of many of JavaScript's warts, but the lack of proper OOP support seemed to kill adoption of the language in projects like Torch. It's still possible to use Lua's prototype-based paradigms to implement OOP, but the implementation details vary depending on which OOP library you choose, and the lack of first-class support is unsatisfying for many people. For me it was more of a mindset thing, and I found I was happier settling for a limited version of OOP or eschewing it for prototype-based programming instead, as it was simpler and satisfied all my needs.
Koshkin 5y ago
But this one is a framework for Lua.
voxl 5y ago
Many game development scripting applications disagree with you. Including: DotA Workshop, Tabletop Simulator, Galaxy Editor (for StarCraft 2), and many others unlisted. Of course, this only matters because you're pretensions about what other people ought to use to develop or script games.
trainsplanes 5y ago
>I got stuck because I couldn't get over the lack of AAA graphics That's an artist problem. Not a programmer problem. I've used Lua for gamedev before. I've also used C#, C++, Python, and Javascript. Nothing was more fun to work with than Lua. If Unity announced they were dropping C# support and switching over to Lua, I'd probably buy a bottle of top shelf champagne to celebrate.
- etaioinshrdlu 5y ago
  In particular, shadow maps, raytracing/global illumination were built-into Unreal but basically a Phd project in LOVR.
  - jmiskovic 5y ago
    Just this week I got the shadow maps working in LOVR, so that at least should land into example section soon. Raytracing shouldn't be too hard to get started, just draw a full screen plane using a standard raytracing shader (but it's not well suited for VR because you cannot keep the camera steady while scene is traced). GI is way above my level. I agree it is much harder than clicking a checkbox in Unreal/Godot. The LOVR exposes low-level OpenGL to Lua, but in a boilerplate-free way, hiding many obscure and obsolete options. This means that there is a steep learning curve, on the other hand you have power to do things differently. Not only the code architecture of project (functional and dynamic VS object-oriented and stateful), but also how you utilize the graphics card. While it can be painful and frustrating, iterating Lua with low level bindings gives you a powerful way to experiment with gfx. I guess LOVR would mostly appeal to people who want to learn details of hardware, but don't necessary want to create (and support) another engine. LOVR is high quality readable C code and Lua API is well thought out.
brainless 5y ago
> It's a beautiful tiny embedded language, but I don't want to use it It seems like you have some unresolved issues with it. If a language is "beautiful" then, yes, I would like to use it.
- mastax 5y ago
  Its beauty comes from being small and orthogonal, but flexible enough to expand to accommodate the project. It's great for embedding, batteries-not-included; when you're writing your `class` implementation you can integrate it with your engine's object system. But many modern engines lean more in the data driven direction. Most or all of the game logic is implemented in config files and the embedded language. You're not writing scripts that manipulate game systems built into the engine, you're building your game systems in the embedded language. Now you want a bit more heft from your language.

signa11 5y ago

may you please elucidate why you dissuade the use of lua ? thank you kindly!

etaioinshrdlu 5y ago
It's the automatic type coercion (strings <=> numbers), the overusage of tables as a universal data structure with bad API, the bizzare syntax. It might as well be Perl. I don't want you to use Perl either.
lasagnaphil 5y ago
Lua is a language that I started programming with, and has a special place in my heart even if has some crappy parts. The main issue I have with the language is with table accesses and 'nil'. Tables in Lua are the most fundamental type of object in the language, it can be either an array (1-based index) or a hashtable. In this language objects are basically just tables with fields in them, and with metatables you can basically emulate all the features in a typical OOP language (classes, inheritance, traits, operator overloading, etc.) Field access in objects are just table accesses (like what you can imagine with Javascript). However, when you try to access a field in a table that doesn't exist (such as 'print(table.key_that_doesnt_exist)'): no errors or exceptions are explicitly raised, it just silently returns nil. This is such a dealbreaker that makes the language much harder to debug than other languages (at least Javascript returns undefined, which is different from null! Oh well, that actually has problems of its own though....) Some more horror: global variables are also implemented as tables (imagine that there's a table _G at the top of the scope). This means that any spelling mistakes with variables will also just silently return nil, since if it doesn't find any variable names at the local scope, it tries to find at the global scope. The global variable thing was actually such a big problem that people came up with some voodoo metatable trickery script like strict.lua (https://github.com/deepmind/strict/blob/master/strict.lua https://github.com/deepmind/strict/blob/master/strict.lua) that prevents this from happening (a showcase of the language's power, but probably not its proudest). I'm sure you could also do this with table creation (make a wrapper function tbl() that automatically adds metatables to tables to prevent invalid field access, so every time you need to do things like 'pos = tbl({x = 1, y = 2})') But still, there isn't a solution baked into the language, and it's cumbersome to do this (and I'm not sure about the performance implications of this addition). Right now I'm trying to integrate Squirrel (http://www.squirrel-lang.org/ http://www.squirrel-lang.org/) instead of Lua as a scripting language into my game. Squirrel is an embedded scripting language that's hugely inspired from Lua, but also fixes this shortcoming of the language by making invalid table accesses runtime errors. And when you want to add new fields to a table you need to explicitly do so via the <- operator: table = {} // print(table.x) (Runtime error) // table.x = 1 (Runtime error) table.x <- 1 table.y <- 2 print(table.x) // Outputs 1 which is much more explicit and less error-prone.
- vkka 5y ago
  Lua gives you means to build your object system anyway you want. A trivial example to protect a table below: local p = { x = 1, y = 2 } print( p.x, p.y ) setmetatable( p, { __newindex = function() assert( false ) end, __index = function() assert( false ) end } ) print( p.z ) -- you get assertion failure p.k = 12 -- you get assertion failure too
  - lasagnaphil 5y ago
    I’ve already mentioned how to do this with metatables. But you still need to wrap this in a function and call it every time, it’s quite cumbersome. And the whole thing falls apart when you start using other people’s libraries (For example, you enabled strict.lua in your codebase, but then it starts affecting other libraries which relied on the original Lua behavior… Or you’ve made your own object system, but that one library you’ve imported uses middleclass and another uses rxi.classic, and you need to go though the headache of making sure they’re all compatible)
billfruit 5y ago
Lua feels so rigid, inflexible compared to something like JS. If you want abstractions, and want functions to be first order objects etc, does Lua help. Does Lua have "eval" or something similar?
- nonbirithm 5y ago
  Yes. You can compile Lua code with `loadstring("return 1 + 1")`, which returns a function that runs the provided code. `loadfile()` does the same thing with files. You can also change how the import mechanism works to load compile-to-Lua languages or similar. There are also first class functions and functional programming libraries. I'm personally a fan of luafun. Usually when programming Lua I can remember every detail of the language without having to consult a reference or wonder which library does what, because it's so simple. I understand that too much simplicity might be an issue for other people, though. I sometimes wish that JavaScript was as simple and easy to understand as Lua is, and Lua is also free of many of JavaScript's warts, but the lack of proper OOP support seemed to kill adoption of the language in projects like Torch. It's still possible to use Lua's prototype-based paradigms to implement OOP, but the implementation details vary depending on which OOP library you choose, and the lack of first-class support is unsatisfying for many people. For me it was more of a mindset thing, and I found I was happier settling for a limited version of OOP or eschewing it for prototype-based programming instead, as it was simpler and satisfied all my needs.

Koshkin 5y ago

But this one is a framework for Lua.

voxl 5y ago

Many game development scripting applications disagree with you. Including: DotA Workshop, Tabletop Simulator, Galaxy Editor (for StarCraft 2), and many others unlisted. Of course, this only matters because you're pretensions about what other people ought to use to develop or script games.

trainsplanes 5y ago

>I got stuck because I couldn't get over the lack of AAA graphics That's an artist problem. Not a programmer problem. I've used Lua for gamedev before. I've also used C#, C++, Python, and Javascript. Nothing was more fun to work with than Lua. If Unity announced they were dropping C# support and switching over to Lua, I'd probably buy a bottle of top shelf champagne to celebrate.

etaioinshrdlu 5y ago
In particular, shadow maps, raytracing/global illumination were built-into Unreal but basically a Phd project in LOVR.
- jmiskovic 5y ago
  Just this week I got the shadow maps working in LOVR, so that at least should land into example section soon. Raytracing shouldn't be too hard to get started, just draw a full screen plane using a standard raytracing shader (but it's not well suited for VR because you cannot keep the camera steady while scene is traced). GI is way above my level. I agree it is much harder than clicking a checkbox in Unreal/Godot. The LOVR exposes low-level OpenGL to Lua, but in a boilerplate-free way, hiding many obscure and obsolete options. This means that there is a steep learning curve, on the other hand you have power to do things differently. Not only the code architecture of project (functional and dynamic VS object-oriented and stateful), but also how you utilize the graphics card. While it can be painful and frustrating, iterating Lua with low level bindings gives you a powerful way to experiment with gfx. I guess LOVR would mostly appeal to people who want to learn details of hardware, but don't necessary want to create (and support) another engine. LOVR is high quality readable C code and Lua API is well thought out.

brainless 5y ago

> It's a beautiful tiny embedded language, but I don't want to use it It seems like you have some unresolved issues with it. If a language is "beautiful" then, yes, I would like to use it.

mastax 5y ago
Its beauty comes from being small and orthogonal, but flexible enough to expand to accommodate the project. It's great for embedding, batteries-not-included; when you're writing your `class` implementation you can integrate it with your engine's object system. But many modern engines lean more in the data driven direction. Most or all of the game logic is implemented in config files and the embedded language. You're not writing scripts that manipulate game systems built into the engine, you're building your game systems in the embedded language. Now you want a bit more heft from your language.