Ivan-Assen Ivanov is CTO for Sofia Bulgaria-based Haemimont Games who have been around since 2000, independent since 2004 and who became heavy users of Lua in 2008. The H talked to him about what they do with Lua.
The H: What software have you produced with Lua?
Ivan-Assen Ivanov: All our games since 2008 – the city builders Imperium Romanum (2008) and Grand Ages: Rome (2009), the satirical political simulations Tropico 3 and Tropico 4, the action adventure The First Templar, and our latest project, the turn-based strategy game Omerta, built on the same evolving code base, are written in large part in Lua.
The H: So where does Lua fit in to your architecture?
IAI: We have a C++ base engine which handles the OS stuff (files, memory, etc.), and the rendering, but everything above that – all the UI code, the game logic, and networking – is in Lua. For example, the previously mentioned city-building games have no notions of "money", "buildings" or "citizens" in the C++ side; these concepts are part of the game code, and exist solely in the Lua side.
The H: Do you use Lua outside your game code base?
IAI: We use Lua for internal tools (e.g. build system, localisation, etc.) and for our back-end servers (matchmaking, leaderboards, chat rooms etc.). We also use Lua tables (think JSON, but with Lua syntax, parsed by the Lua runtime) instead of XML for all non-binary data in the games.
The H: How do you treat Lua as a language?
IAI: We consider Lua a "real" programming language, a very flexible, powerful, concise and expressive high-level language, to be used by full-time programmers – as opposed to a "scripting" language to give to handcuffed designers for mission logic, for example. Our game designers create mission logic using even higher-level tools written in, you guessed it, more Lua – they don't type straight Lua in a text editor.
The H: What are your favourite features of Lua?
IAI: We like coroutines – essential for game logic, UI code, networking – we use them as cooperative threads and run several thousands of them simultaneously on a single Xbox 360 core (which is not the fastest of CPUs, especially for general-purpose branchy code). Also, Lua doesn't have a class system, but provides powerful instruments which allow you to build your own class system to your exact specifications – which we have done, and evolved over the years. Also we like the small, easy to embed runtime, with good and predictable performance and the decent garbage collector, which we have to hand-hold only in some critical points and even then only on the Xbox 360.
The H: Does working in a high-level language bring any particular benefits?
IAI: Lua is a very high level language, with very high expressive power – you can do a lot with very little code. We enjoy the the ability to do live reloading on code while you work on it – we literally start the game executable in the morning and never quit it all day long, reloading hundreds of time the code we are working on. And with so much code in Lua, the C++ layer is relatively small and compact – we have something like 250k lines of C++, which compile and link under a minute on a single PC, as opposed to the all too common situation in game development where executables take hours to compile and developers have to resort to solutions like Incredibuild, unity builds etc.
The H: All of this sounds good – does it also make business sense?
IAI: The heavy use of Lua allows us to work with very fast iteration, which in turns leads to quick development cycles and more time for polishing. In game development we often speak of giving better tools to our content creators – the designers and artists. You can think of a very high-level language, customised to your environment and workflow, as a better tool to give to your programmers. Lua fits the bill nicely, and I heartily recommend anyone who accepts as a universal truth that "games are written in C++" or that "Lua is just for scripting, not a real language" to give it a second thought.