O.C.: Have you consulted about this “tables” approach with other Lua developers?
I.T.: After that, I went back to Dmitry and asked him if my understanding of “everything is a table” was correct and, if so, why Lua was designed this way. Dmitry told me that Lua was created at the Pontifical Catholic University of Rio de Janeiro and that it was acceptable for Pontifical Catholic Universities to design programming languages this way.
Lol what? Is there some kind of inside joke about Catholics and tables?
My understanding of the joke is less about tables, more about pontification; I.e. “it is so because we say it is”.
… the lack of an increment operation, no “continue” instruction, and array indices starting from 1 instead of 0. These differences can be jarring
Understatement
When I read this kind of stories about game dev where unit tests are very optional, I don’t really regret not working in this industry, especially now with all the layoffs.
Working in enterprise software development really hammers in the importance of unit tests and integration tests.
It seems that obscure bugs are a much bigger deal when the customer is a billion-dollar bank compared to a single player, not that surprising really!
to be fair, the testing surface is significantly more varied in a game than in the average application
your average api is probably stateless, and input probably tops out at like 100 lines of json
a game uses probably like 8gb of memory to store its state
I wish we held game developers to the same level of scrutiny.
Different industries have different priorities, if the big boss says concentrating on features or releasing sooner is the priority then such is life
It doesn’t necessarily work that way, though. If tests tell you you broke something immediately, you don’t have time to forget how anything works, so identifying the problem and fixing it is much faster. For the kind of minor bug that’s potentially acceptable to launch a game with, if it’s something tests detect, it’s probably easier to fix than it is to determine whether it’s viable to just ignore it. If it’s something tests don’t detect, it’s just as easy to ignore whether it’s because there are no tests or because despite there being tests, none of them cover this situation.
The games industry is rife with managers doing things that mean developers have a worse time and have the opposite effect to their stated goals. A good example is crunch. It obviously helps to do extra hours right before a launch when there’s the promise of a holiday after the launch to recuperate, but it’s now common for games studios to be in crunch for months and years at a time, despite the evidence being that after a couple of weeks, everyone’s so tired from crunch that they’re less productive than if they worked normal hours.
Games are complicated, and building something complicated in a mad rush because of an imposed deadline is less effective than taking the time to think things through, and typically ends up failing or taking longer anyway.
Love Lua. I just wish the ecosystem wasn’t a choice between a fast JIT implementation and a traditional one that’s compatible with the latest version of the language.
Fun related fact: both Hades and Hades II are also mostly Lua scripts. And they ship the source code with both games so you can just go look at things like how fishing probabilities are implemented directly in the script.
Coming from Rust I am toying around with Lua at the moment. Lua is a small, simple and I would say a very neat language. But for big projects like an entire game I would personally much prefer a “traditional” compiled language like C/C++, Java/C# or Rust. Scripting langs are great for small scopes, but they quickly become a burden for bigger things in my opinion.