Getting to Know Lua

I’ve been spending the last few weeks looking over the Lua programming language as part of my effort to expand my knowledge.  I wanted to pass on a few thoughts and impressions from developer perspective of someone who has many years of coding experience in C/C++, C# and JavaScript.

When I first started to view the syntax of Lua, it reminded me of a language that was closer to Visual Basic and JavaScript rather than C++ or C#.  The former being high-level, interpreted, non object-oriented and the latter having strong types, polymorphism and low-level constructs such as pointers.

I’m not going to digress into a long list of pros and cons.  That’s really a perspective best suited when there is a very specific goal in mind.  In my case, the goal was just to learn the language.  I might inject a personal comment here or there on items I found cool and items I thought might have been done differently.

First-off, resources:

• Lua Interpreter / Main site : http://www.lua.org
• Lua Community Forums : http://www.lua-users.org
• Lua.Net – Integrating Lua with .Net : http://www.codeproject.com/KB/mcpp/luanetwrapper.aspx

There are many other resources out there if you have a particular project or focus for Lua.  Just use your favorite search engine.

One of the early things I heard about Lua is its performance and interpreter size being great for embedded designs.  These turned out to be true.  The code runs very fast and the disk and memory footprints are minimal compared to other interpreted environments.  This was so much part of the vision for Lua that even the regular-expression-like string capabilities are reduced to the most popular portions to minimize the performance and size of the environment.

Lua is not strongly typed.  Variables are able to change their type and be overridden at anytime.  This is similar to JavaScript.  The most interesting type in Lua is the Table type.  It is a combination of an Array and a Dictionary found in other languages.  Here is a list of the built-in types:

• Boolean – Your basic true / false
• Number – Floating point numbers (similar to JavaScript)
• String – Character Arrays
• Table – Mix of Array and Dictionary
• Function – Code
• Nil – Special (think of undefined in JavaScript)
• Other – This represents extensions to the Lua language through the interpreter environment, often extended in C/C++.

Because Lua is a Reflective language, the developer is able to query the type of a variable by utilizing the type(<variable>) syntax.

While basic Lua does not have support for inheritance, polymorphism, etc… there have been some libraries created to emulate and add this functionality.  This is often done by manipulating a namespace table to override functions, yet still call a base implementation.

Namespaces can be implemented through a table and a little bit of Lua syntax sugar.  This creates a set of functions and properties that are scoped and can be instantiated to provide what looks to be class support in the code.  Note: This made me feel more comfortable with the Language coming from an object-oriented background.

Packages are a Lua concept to break a program up into modules and load those packages via a “dofile(<package name>)” function.  Package dependency can be specified via a “require <package name>” syntax often found near the top of a file.

One concept that took me a bit to grasp was that variables created are by default global in scope.  Only by prefixing variable declaration with the local keyword will the scope and lifetime of the object be limited.  Keeping this in mind is important if you are writing a large application or a library of functionality.

If you would like a more comprehensive description of the language, I encourage you to read the Wikipedia article (http://en.wikipedia.org/wiki/Lua_programming_language) or visit the Lua site, download the interpreter environment and play with it!

Under Penalty of Death

As one discusses life in a virtual world, one must also discuss death in that same world.  Fortunately, death in a virtual world is no where near as devastating as real life.  That said, depending on how death is implemented (or not), a player may experience a range of emotions from almost comical to outright grief depending on the penalties associated with death of their character.

A virtual world has many options when it comes to handling the death of a character.

• No Penalty
• Repair Costs
• Vitae Penalty
• XP Penalty
• Loss of Items
• Permanent Character Death
• No Death

Some games do not need the concept of death of a character.  The virtual world may be more socially structured and avoid combat or experiences that could lead to character death.  Such worlds solve the death problem by never introducing the circumstances by which a character can die. 

Another world may change the meaning of death to another term (morale comes to mind) so that characters automatically flee when their morale is gone.  In the spirit of this discussion, that would just be a story-telling spin on death and the players will still view it as death (or simply a loss).

By having the penalty for death be minimal, the environment encourages the players to throw caution to the wind and try things that would otherwise be impossible to near impossible.  If not carefully checked, players may also utilize this circumstance to leverage death for other game benefits (teleportation comes to mind).

With a high penalty for death in a game, players are discouraged in taking chances.  Also, there is a greater sense of loss when the character death does occur.  This can lead to players leaving the game after a perceived devastating loss.

Many of today’s popular titles utilize a minimal cost approach.  The idea being to avoid adding a game mechanic that induces frustration for the player and possibly leads to them leaving the game.  This can be seen at a deeper level as characters continue to become more overpowered compared to their non-player counterparts in the game.  This behavior has left many more hard-core players with comments like “Everyone can reach the highest level now.”

For the game designer, the choice between normalizing the game so that more players enjoy the experience versus creating a world where only great players can reach the highest levels is one that often leads to the former.  That said, the indie game designer may opt for a higher penalty to provide a higher-valued experience for their limited player base.  Especially, if the world is meant to represent something historically authentic.

Where will I go with this?  Unknown at this time, although I lean more towards the lower penalty as I cannot immediately justify a valid reason to be more severe on the penalty of death.  That said, as the world design progresses, I will have to address this question.