lua-users home
lua-l archive

report on the Lua in the Gaming Industry Roundtable at GDC 2004

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


The moderators have kindly shared with us their report. So here it is.
--lhf
 GDC 2004 - Lua in the Gaming Industry Roundtable Report
Moderators
 Jon Burns [1]
 David Eichorn [2]
 Microsoft Game Studios
Abstract
 The embedded programming language Lua is becoming more and more widely
 used in the gaming industry. The beauty of this language is in its
 simplicity and flexibility; several games within Microsoft Game
 Studios employ the use of Lua for many aspects of their architectures,
 including scripting, game balancing, AI decision making, driving
 animations, UI layout, and level building. The purpose of this
 roundtable discussion is to bring developers from the industry
 together to share in their experiences integrating Lua into their game
 projects. The goal is to spread awareness of the most popular uses of
 Lua and to also make any short-comings or pitfalls apparent to those
 developers evaluating the use of Lua in their games.
Session Format
 The roundtable was broken into two sessions. Not knowing the actual
 experience level of the participants, the discussion topics were wide
 open; anything related to Lua was fair game.
Attendance
 The first session had approximately sixty attendants, primarily all
 developers. The second session had approximately forty five
 attendants, again, primarily all developers. The first session had
 many more active participants, approximately fifteen, as more of this
 group had some good experience working with Lua on their projects. The
 second group was less experienced; only approximately seven
 participated actively. Some attended to share their experience while
 others simply wanted to learn more about Lua's impact in the industry
 or evaluate it for possible use.
Key Discussion Points
 Lua 4.0 vs. Lua 5.0
 Users of both stated that they have observed as high as a 20%
 performance improvement when moving to Lua 5.0. It was concluded that
 it would behoove any teams using older versions of Lua to switch over
 to Lua 5.0, the latest release version.
 Lua vs. Python
 The comparison of Lua and Python was a major theme of both sessions.
 The general consensus here is that Lua is much faster, uses less
 memory, has a smaller footprint, and is easier to get up and running
 and hooked into a game than Python. Python, however, is much more
 scalable than Lua. Python has a good set of modules for specialized
 tasks which makes it a good language to use for cross-platform
 development, while in Lua you'd have to write much of it yourself.
 Many developers use both languages for different purposes - Lua is
 most often used for small-scale while Python is used for large-scale
 tasks (such as tool development efforts). Lua is often used for game
 scripting, Python for tools. One developer even said he had written
 his Lua debugger in Python!
 Lua vs. XML
 A question was posed regarding using Lua or XML for data definition.
 The general consensus was that Lua is much more compact and readable
 than XML. XML is good for describing small sets of data and
 web-related data, and it was suggested that a team could use XML as a
 meta-language to express game data in binary, which would be good for
 cross-platform development. Most agreed it is much easier to find
 XML-savvy editors than Lua editors.
 Lua's easy ramp-up time
 Most developers heavily experienced with Lua said Lua is a language
 that developers can learn in about 10 minutes and that non-programmers
 can pick up at a fairly quick pace. Certain scripting applications
 using Lua could be a good way for junior programmers to get into the
 business.
 There is good documentation for Lua, which aids in the ramp-up
 process. There is now a Lua Programming book, reference manuals, and a
 good community support web site [3] [4].
 Non-programmers using Lua
 There was general agreement that non-programmers - game and level
 designers, perhaps artists - can learn to understand the syntax of the
 language and write small bits of code with excellent results, but that
 learning how to actually program in Lua is a challenge. The risk here
 is the higher chance of subtle bugs being introduced into Lua scripts
 from these non-technical people.
 For example, some devs had problems with their artists not knowing
 good naming conventions and programming concepts well enough to do a
 good job in Lua. One suggestion was to use a tool named Ultraedit that
 color-codes the Lua script - this developer claimed his artists found
 programming in Lua much easier in this editing program.
 It was also suggested that data-driven design support in Lua is better
 for these non-technical people. One developer suggested creating a
 multi-tiered system that added increasing levels of abstraction - each
 level increasing the ease of use for the non-technical people using
 Lua. He claimed it has worked very effectively in his project.
 Binding Lua to C++
 Many less-experienced Lua users asked about binding Lua with C++. Some
 developers are using the Luabind tool which does this quite
 effectively, though some cautioned that the compile times are much
 longer. One mentioned that the tool ToLua is no longer supported, so
 use of it should be transitioned to another automatic binding
 generation tool. Other tools mentioned included LuaPlus and Swig. Some
 developers found it easier to write their own in-house tools to bind
 Lua and C++ because it is quite easy to do.
 The discussion produced this word of caution: the easier it gets to
 bind Lua to data objects in the game source, the easier it is to fall
 into the trap of binding *everything* to Lua, which is dangerous...
 Issues encountered when using Lua in game development
 The attendees had many suggestions on avoiding pitfalls:
 Avoid using Lua in "every frame" actions as performance drops
 dramatically. For example, don't use Lua to do animation updates; set
 up parameters for the animation in Lua and do the updates in C/C++
 code.
 Avoid using Lua for large game development tasks; rather use Lua in
 quick small-scale actions.
 Avoid using extremely large table sizes as performance drops in table
 access actions.
 Store state information outside of Lua in C++ objects, only bind when
 necessary.
 Be careful about what data is bound to Lua. Having careful control of
 this data can result in a good, stable environment regarding security
 measures.
 Call garbage-collection routines explicitly only when free cycles come
 up. Some devs found that Lua was doing garbage collection at
 inopportune times.
 One developer cautioned against using incremental garbage collection
 as he observed noticeable slowdown. Because it is a new functionality,
 however, this claim wasn't discussed much.
 Good things about Lua
 The attendees had the following to say about what appeals to them
 about using Lua:
 Lua coroutines work "reasonably well" for cooperative multithreading.
 One developer said they have about twice the overhead of a function
 call (negligible), and that having 3-4 works just fine.
 All of the developers love the fact that licensing Lua is so easy, and
 especially so free.
 In event-based and polling systems, many of the developers claimed
 they observe no noticeable bottlenecks caused by Lua.
 New features/tools coming into the Lua scene make it more attractive
 day by day: Lualint and the new standard debugging library provided in
 Lua 5.0.
 All devs unanimously agreed that the support for Lua is great, whether
 off of the Lua homepage or the community sites, etc.
 Experiences applying Lua
 The group shared some of their own personal uses of Lua that were
 particularly memorable and successful:
 One developer created a cutscene handler in Lua that managed the
 triggering of cutscenes in his game project. He found it easy to
 manage in Lua.
 One developer was able to setup a record / replay system for all UI
 actions.
 One developer was doing unit code testing in Lua.
 One developer was able to derive game objects in Lua, and assign
 functions to these objects in order to test their attributes, etc.
 more easily.
 One developer integrated Lua with their physics engine to allow more
 accessibility to tweak physics scripts dynamically.
Summary and Conclusions
 This roundtable focused on the hands-on experiences of people using
 Lua in the gaming industry. Attendees were encouraged to share their
 personal experiences with Lua in order to spread awareness of the
 benefits and pitfalls of this embedded language. The two sessions
 accomplished this goal quite successfully (we as moderators were very
 surprised at the interest in Lua in the gaming industry based on the
 number of attendees both days and in the discussion that came about) -
 there was good conversation in both roundtable sessions that conveyed
 several things, most notably: 1) The diverse uses of Lua that are
 specific to games development, 2) What not to use Lua for in games
 development, 3) The ease of ramp up time for users of Lua, and 4)
 Comparisons against other languages and even older releases of Lua.
 This is where most interest lay for both days.
 There are definitely a handful of very experienced Lua users in the
 gaming industry that are doing some very impressive work in their
 projects with the language. Future roundtables on this topic can begin
 to explore more of what the industry would like to see as features of
 the language itself and how the community support for games
 development can expand more effectively...
References
 1. mailto:jkburns AT microsoft.com
 2. mailto:deichorn AT microsoft.com
 3. http://www.lua.org/
 4. http://lua-users.org/wiki/

AltStyle によって変換されたページ (->オリジナル) /