# Game Developers Need Lua AiR

Paul Klint, Loren Roosendaal, Riemer van Rozen

## ► To cite this version:

Paul Klint, Loren Roosendaal, Riemer van Rozen. Game Developers Need Lua AiR: Static Analysis Of Lua Using Interface Models. ICEC 2012 - 11th International Conference on Entertainment Computing, Sep 2012, Bremen, Germany. pp.530-535, 10.1007/978-3-642-33542-6_69. hal-00758607

HAL Id: hal-00758607

https://inria.hal.science/hal-00758607

Submitted on 4 Jul 2017

HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Game Developers need Lua AiR
## Static Analysis of Lua using Interface Models

Paul Klint<fnref n="1" />, Loren Roosendaal<fnref n="2" />, and Riemer van Rozen<fnref n="3" />

**Abstract.** Game development businesses often choose Lua for separating scripted game logic from reusable engine code. Lua can easily be embedded, has simple interfaces, and offers a powerful and extensible scripting language. Using Lua, developers can create prototypes and scripts at early development stages. However, when larger quantities of engine code and script are available, developers encounter maintainability and quality problems. First, the available automated solutions for interoperability do not take domain-specific optimizations into account. Maintaining a coupling by hand between the Lua interpreter and the engine code, usually in C++, is labour intensive and error-prone. Second, assessing the quality of Lua scripts is hard due to a lack of tools that support static analysis. Lua scripts for dynamic analysis only report warnings and errors at run-time and are limited to code coverage. A common solution to the first problem is developing an Interface Definition Language (IDL) from which "glue code", interoperability code between interfaces, is generated automatically. We address quality problems by proposing a method to complement techniques for Lua analysis. We introduce Lua AiR ( Lua Analysis in Rascal), a framework for static analysis of Lua script in its embedded context, using IDL models and Rascal.

# 1 Introduction

Game developers use script languages to develop and maintain game logic sep-
arately from game engine libraries. Lua is a script language [1] in the form of
an ANSI C library<fnref n="4" /> developed by Ierusalimschy, de Figuieredo and Celes. Dur-
ing its evolution [2] Lua has gradually matured and has remained light-weight.
Moreover, it is an embeddable, minimalistic yet extensible, general purpose,
dynamically typed script language. Its language design trade-offs, displayed in
Table 1, have shaped the co-development of the embedding API and script fea-
tures [3]. Lua is popular in game development. Using Lua, developers can quickly
create prototypes. However, using Lua also comes at a cost. In later development
stages, when larger quantities of engine library code and game script are avail-
able, developers encounter maintainability and quality problems.

<footnote n="1">¹ Centrum Wiskunde & Informatica**</footnote>

<footnote n="2">² IC3D Media</footnote>

<footnote n="3">³ Amsterdam University of Applied Sciences**</footnote>

<footnote>** This work is part of the EQuA project. http://www.equaproject.nl/</footnote>

<footnote n="4">⁴ http://www.lua.org/</footnote>
<table><caption>Table 1: Lua Design Trade-offs</caption><thead><tr><td>Lua feature</td><td>Trade-off</td><td>Mitigating argument</td></tr></thead><tbody><tr><td>Light-weight</td><td>Large responsibility to its users</td><td>Well-defined responsibilities</td></tr><tr><td>Dynamic typing</td><td>Lack of static type checking</td><td>Flexibility of use</td></tr><tr><td>Maintainable C</td><td>Lack of pure speed</td><td>Embedded in efficient C</td></tr><tr><td>General-purpose</td><td>Lack of domain-specific features</td><td>Extensible script language</td></tr><tr><td>Simple</td><td>High use of few APIs</td><td>Low learning curve</td></tr><tr><td>Embeddable</td><td>Need for interoperability code</td><td>This code can be generated</td></tr></tbody></table>

First, using a standard generator for the coupling between Lua and the game libraries sacrifices speed, and maintaining a hand-written coupling with domain-specific optimizations is labour intensive and error-prone. Second, assessing the quality of Lua scripts is hard due to a lack of tools that support source level *static analysis*, which entails computing information about scripts before run-time. The commonly used Lua scripts for dynamic analysis only report warnings and errors at run-time, and are limited to code coverage. Static analyses do exist, but are mainly applied to intermediate representations in Single Static Assignment (SSA) forms for run-time optimization, e.g. LuaJIT<fnref n="5" /> and the run-time specializations of Williams et al. [4].

Both problems increase with scale and special measures are necessary for ensuring maintainability and code quality. A common solution to the first problem is to develop an Interface Definition Language (IDL) from which optimized "*glue code*", interoperability code between interfaces, is generated automatically. However, code quality problems remain to be addressed. Quality problems are not unique to Lua. Blow [5] expresses increased complexity and lack of development tools and White et al. [6] describe the need for better script notation. Ramsey and Assis [7] express the need of the Lua community for machine-checkable APIs including types, whole-program and modular static analysis and static type inference. Providing practical methods for static analysis of Lua is hard because static analysis algorithms are subject to a trade-off between speed and precision and developers require exact and immediate feedback during development.

We address script quality problems by proposing a method to complement analysis techniques of Lua. We describe an approach in collaboration with IC3D Media that uses the Rascal Meta-Programming Language<fnref n="6" /> [8]. IC3D Media is a Dutch SME located in Breda, active in games for entertainment and training. We introduce Lua Analysis in Rascal ( Lua AiR ), a framework for static analysis of Lua script in its embedded context, using IDL models.

## 2 Static Analysis of Lua

We can think of scripts as having many run-time states reachable via possibly many execution paths. Running every program path is infeasible, but abstracting

<footnote n="5">⁵ http://luajit.org/</footnote>

<footnote n="6">⁶ http://www.rascal-mpl.org/</footnote>
<table><caption>Table 2: Static Analysis: Features and Tools</caption><thead><tr><th></th><th colspan="5">Tools</th></tr><tr><th></th><th>LDT</th><th> Lua Inspect</th><th> Lua Checker</th><th> Lua for IDEA</th><th> Lua AiR</th></tr></thead><tbody><tr><td>tool characterization</td><td>Eclipse IDE</td><td>SciTE/VIM plug-in, HTML output</td><td>command-line simplifier & checker tools</td><td>IntelliJIDEA plug-in</td><td>Meta-Framework, Eclipse IDE</td></tr><tr><td>based on</td><td>Metalua</td><td>Metalua</td><td>lex/yacc, Lua</td><td>Kahlua</td><td>Rascal MPL</td></tr><tr><td>affiliation</td><td>Eclipse, Sierra Wireless</td><td>David Manura</td><td>Google</td><td>Jon Akhtar</td><td>HvA, CWI, EQuA project</td></tr><tr><td rowspan="13">Features</td><td>1 globals & locals (definition and use)</td><td>yes</td><td>yes</td><td>strict declare before use</td><td>yes</td><td>yes</td></tr><tr><td>2 var use must be undefined</td><td>no</td><td>yes</td><td>yes (locals)</td><td>yes (locals)</td><td>yes</td></tr><tr><td>3 var use may be undefined</td><td>no</td><td>no</td><td>no, disallowed</td><td>no</td><td>not yet</td></tr><tr><td>4 link a definition to its uses</td><td>highlight all</td><td>yes</td><td>no</td><td>yes</td><td>yes (no color)</td></tr><tr><td>5 link a use to its definitions</td><td>occurrences</td><td>yes</td><td>no</td><td>yes</td><td>yes (no color)</td></tr><tr><td>4 definition must be unused</td><td>no</td><td>yes</td><td>no</td><td>yes</td><td>not yet</td></tr><tr><td>5 definition may be unused</td><td>no</td><td>no</td><td>no</td><td>no</td><td>not yet</td></tr><tr><td>6 duplicate local declaration</td><td>no</td><td>yes, mask(ed)</td><td>yes</td><td>no</td><td>yes</td></tr><tr><td>7 assignment discards expression</td><td>no</td><td>no</td><td>no</td><td>yes</td><td>"unbalanced"</td></tr><tr><td>8 assignment implicitly deletes var</td><td>no</td><td>yes, value nil</td><td>no</td><td>"unbalanced"</td><td>yes</td></tr><tr><td>9 operator applies coercion to operand</td><td>no</td><td>no</td><td>no</td><td>no</td><td>limited</td></tr><tr><td>10 constant folding</td><td>no</td><td>"infer value"</td><td>no</td><td>no</td><td>limited</td></tr><tr><td>11 dead code detection</td><td>no</td><td>not working</td><td>no</td><td>no</td><td>no</td></tr><tr><td>12 type inference</td><td>no</td><td>"infer value"</td><td>no (todo)</td><td>"infer nullity"</td><td>no</td></tr><tr><td>13 function signature inference</td><td>no</td><td>not working</td><td>no</td><td>no, call sites show definition</td><td>static IDL</td></tr></tbody></table>

from specific execution states enables us to reason about software properties and to compute them timely. Static analysis refers to the extraction of information about states and behavior from a software application without executing it.

Table 2 enumerates static analysis features applicable to Lua and compares existing analysis tools. Features include distinguishing between global and local variables (1) and relating declarations to uses (4), possibly using syntax highlighting. Many of these features (1-6) can be approximated by data flow analysis techniques [9] such as *reaching definitions*, which computes for each program point which assignments can reach it. Others features require no flow analysis (7, 8) or require more advanced inference techniques (9-13). Figure (n) illustrates features described in Table 2 using comments and references (fn), where (a) illustrates features 1, 2, 4, 7, 8 and 9 and (b) shows features 1-3.

<figure><img src="image_2.png" /><figcaption>(a) Sequential Assignments</figcaption></figure>

<caption>(b) Event Handler</caption>

<caption>Fig. 1: Lua Script demonstrating potential errors that static analysis can find</caption>
<figure><img src="image_3.png" /><figcaption>Fig. 2: Lua AiR Model Transformations</figcaption></figure>

Koneki Lua Development Tools (LDT)<fnref n="7" /> is an Eclipse plug-in that provides remote debugging and rudimentary static analysis for highlighting and refactoring. Lua Inspect⁸ is an experimental static analysis tool that infers values, but incorrectly for conditional assignments. Lua Checker⁹ is a basic command-line tool that checks local variable declarations against their uses. Lua for IDEA¹⁰ enriches call sites with API structure (e.g. for World of Warcraft). LDT and Lua Inspect are based on Metalua [10], a Lua extension for static meta-programming.

## 2.1 Lua AiR Framework

This section explains the approach of the Lua AiR framework. IC3D Media has developed two languages for interoperability between Lua and their Logos3D game engine called Interface Definition Language (IDL) and Interface Generator Language (IGL). IDL defines function signatures and data types. IGL defines the generator format of the mapping between engine functionality defined in IDL models and Lua. Unlike other approaches shown in Table 2, we utilize information from the embedded context in our analysis. Functions and data structures exposed to Lua, and managed by the Logos3D engine, are statically defined and strongly typed. Sharing function signatures and data types modeled in IDL between the embedded environment and Lua enables checking function call site arguments against formal parameter types. Furthermore, it reduces the need for type inference and saves computation time in inter-procedural analysis. Additionally, code documentation can be shared between script proxies and the embedded context.

Lua AiR is a Rascal meta-program that implements the analysis as a pipeline, as illustrated by Figure 2. Rascal generates a specialized Eclipse IDE for Lua editing, highlighting, and static analysis. The analysis consists of the following model transformations. 1) The Lua script under analysis is fed into the parser

<footnote n="7">⁷ http://www.eclipse.org/koneki/ldt/
⁸ https://github.com/davidm/lua-inspect
⁹ http://code.google.com/p/lua-checker/
¹⁰ https://bitbucket.org/sylvanaar2/lua-for-idea/wiki/Home</footnote>
<figure><img src="image_4.png" /><figcaption>Fig. 3: Increased Complexity requires Separating Concerns</figcaption></figure>

generated by Rascal from our *Tarantula Grammar* (130 LOC). This produces a *parse tree* (a), depicted as a triangle. 2) The *implode* function matches the nodes of this tree to an Algebraic Data Type (ADT) that represents our Abstract Syntax Tree (AST) (b). This model transformation relies on compatible names and types between the Lua grammar and the ADT. 3) *Reduce* and *Expand* rewrite the AST to simplify the analysis (c). 4) The *Checker* provides static type checking and annotates the AST with scope information (d). 5) Given this AST, the *Control Flow (CF) Analyzer* generates a Control Flow Graph (CFG). 6) The *Reaching Definitions (RD) Analyzer* uses the CFG and performs fixed-point computation over *generate* and *kill* sets to generate the reaching definitions. Finally, the tool displays a log and the view in the IDE is updated by annotating the parse tree with results. The meta-program currently comprises approximately 3 KLOC.

# 3 Discussion and Future Work

This section discusses problems and describes opportunities for future work.

**Empirical validation.** We believe that providing developers with better tools will improve code quality, but we have no proof yet this assumption is correct. Our approach can be validated by verifying if programmers can improve code quality by using our framework.

**Improved precision.** Our analysis is *context insensitive* with respect to individual program states and execution paths and lacks type inference. Our analysis can be improved by using context sensitive techniques based generating and evaluating logical constraints [8, 9].

**Tool integration.** Our framework cannot be used yet by existing tools. We plan to create a *Query API* to interface with other tools.

**DLSs.** Lua lacks the domain-specific notation which non-programmer game developers need to model software artefacts. A separation of concerns, as shown in Figure 3, is necessary to tackle challenges resulting from increased complexity in game development. Games can be modeled using sets of complementary light-weight little languages, one for each concern, as demonstrated by Palmer [11] and advocated by Furtado [12]. We observe that Lua AiR can be extended to support DLSs for higher level game concerns such as world events, character behavior and mission design, using IDL bindings to check if models conform to the interfaces of their library foundations.
# 4 Conclusion

In this paper we related Lua script quality problems to a lack of tools that support its static analysis. We evaluated the features of available tools and proposed a method to complement techniques for analysing Lua. We introduced Lua AiR, a framework for static analysis of Lua script in its embedded context, using IDL models and Rascal. Its main goal is to provide the immediate script analysis developers need to improve code quality. Preliminary results show that Lua AiR can provide additional information about Lua scripts. In future case studies we plan to use Lua AiR to analyse existing game code on a larger scale.

**Acknowledgements** We thank the reviewers for their constructive comments.

# References

1. Ierusalimschy, R.: Programming in Lua, Second Edition. Lua.org (2006)

2. Ierusalimschy, R., de Figueiredo, L.H., Celes, W.: The Evolution of Lua. In: Proceedings of the third ACM SIGPLAN conference on History of programming languages. HOPL III, New York, NY, USA, ACM (2007) 2–1–2–26

3. Ierusalimschy, R., De Figueiredo, L.H., Celes, W.: Passing a Language through the Eye of a Needle. Commun. ACM 54(7) (July 2011) 38–43

4. Williams, K., McCandless, J., Gregg, D.: Dynamic Interpretation for Dynamic Scripting Languages. In: Proceedings of the 8th annual IEEE/ACM international symposium on Code generation and optimization. CGO ’10, New York, NY, USA, ACM (2010) 278–287

5. Blow, J.: Game Development: Harder Than You Think. ACM Queue 1 (February 2004) 28–37

6. White, W., Koch, C., Gehrke, J., Demers, A.: Better Scripts, Better Games. Commun. ACM 52 (March 2009) 42–47

7. Ramsey, N., Assis, F.: Almost Good Enough to Scale: A Lua Mail Handler and Spam Filter (presentation slides). In: Lua Workshop. (2008)

8. Klint, P., Storm, T.v.d., Vinju, J.: RASCAL: A Domain Specific Language for Source Code Analysis and Manipulation. In: Proceedings of the 2009 Ninth IEEE International Working Conference on Source Code Analysis and Manipulation. SCAM ’09, Washington, DC, USA, IEEE Computer Society (2009) 168–177

9. Nielson, F., Nielson, H.R., Hankin, C.: Principles of Program Analysis. Springer-Verlag New York, Inc., Secaucus, NJ, USA (1999)

10. Fleutot, F., Tratt, L.: Contrasting Compile-Time Meta-Programming in Metalua and Converge. In: Workshop on Dynamic Languages and Applications. (July 2007)

11. Palmer, J.D.: Ficticious: MicroLanguages for Interactive Fiction. In: Proceedings of the ACM international conference companion on Object oriented programming systems languages and applications companion. SPLASH ’10, New York, NY, USA, ACM (2010) 61–68

12. Furtado, A.W., Santos, A.L., Ramalho, G.L.: SharpLudus Revisited: from ad hoc and Monolithic Digital Game DSLs to Effectively Customized DSM Approaches. In: DSM’11. SPLASH ’11 Workshops, New York, NY, USA, ACM (2011) 57–62