COcorysama·May 20, 2025
At the indie studio I used to work at, we had some folks with engine experience. So, we rolled our own 3D engine and asset pipeline from scratch. But, we didn't have the budget for an editor. Instead we set up the asset pipeline to hot-reload everything. Meshes, scenes, materials and animations from Maya. Textures from Photoshop. Audio as a pile of WAVs. Scripting in Lua. UI layout in XML. Changing the asset files would change the game live.
Then we added "State machines as Lua exported from Excel". Rows are states, columns are events, cells are code to execute given a state+event combo. I've done this a few times. It makes huge state machines manageable.
Our games were very stats-heavy and our designers liked Excel. So, a new thing we added as "Dynamic data sources as grids of Lua exported from Excel". So, fill out Excel sheets like norm
Read the rest
al. But, instead of Excel script, every cell is evaluable Lua code. Strings, numbers, bools, functions are all values in Lua. So, a cell might contain a number. Or, it might contain a function checking the contents of two other cells and optionally triggering an event on some other object.
We shipped multiple games on a single executable using this system. Artists could lay out 3D scenes and 2D UIs with hooks for the Lua to control it. And, the designers could populate scenes and UIs from Excel dynamically according to the state of the game. The programmers mostly worked on game-agnostic features in C++, and the heavier side of scripting in Lua for game-specific features.
Aside: Lua is being so dynamically typed makes it not great for large-scale software engineering. But, https://teal-language.org/ might be a good TypeScript-For-Lua. I haven't tried it. Also, are there any Lua debuggers newer than the ancient https://github.com/unknownworlds/decoda that require zero integration? Decoda just need a pdb of your executable and it can automatically debug any scripts passing through the Lua library.
Eventually, we switched to Unity for corporate reasons. As a primary implementer of our custom engine, I think the switch was overall a good thing. Our games had started to outgrow what our little engine team could deliver. The artists reported they felt slightly less productive working in Unity's editor. I switched roles to finding and working around the undocumented bugs in Unity that we ran into. Then later finding which bugs had been fixed without being mentioned in the release notes so I could delete my work-arounds. It was a very boring couple of years until the company burned to the ground because of the same corporate reasons that lead us to switch to Unity :P