Re: My experience with Lua so far

["Daniel Collins" <daniel.collins@...>]

> > I have just started using Lua in a mobile phone game
> > I am developing.
> 
> Could you comment more about it?
> Are you developing for BREW or Symbian?

Neither. The project is for WIPI, a South Korean platform similar to
BREW. It is supposed to be a standard, but like so many standards, each
vendor has produced versions that are not compatible with each other.
This is one thing that has motivated me to move towards writing as much
of the game as possible in Lua, since the lua code tends to be very
platform independent. I hide all of those ugly platform problems in the
C side of things.
 
> What kind of binding are you using? tolua,
> "home-made"?

I guess you could call it a home-made binding, since I write all the
binding code myself using the lua C API. Primarily this was because I
wanted to understand the Lua C API, and there is nothing like writing
production code for learning an API. Also it gives me fine control over
exactly how the binding code works. There are no extra steps and no
surprises other than those caused by my mistakes.

I think the point I failed to make in my first post was that I am
surprised by how rapidly my Lua usage has changed from my first
expectations of 90% C code with 10% lua providing some glue and
configuration data to something more like a 50-50 split between C and
Lua code. In particular, I have abandoned my initial idea of having the
C API for my game provide the full feature set that then gets exposed to
lua - essentially a 1:1 mapping between C and Lua functionality. Since
my game only needs to be written in lua, there is no need for all the
extra work that would involve. 

Writing systems in Lua rather than C has not been without some issues
though. I find that since Lua lends itself so well to rapid prototyping
of ideas it can be tempting not to formalise a module or system right
away. This means that by the time I refactor a collection of test
functions into a module there might be quite a bit of code to change,
and the lack of strong typing combined with the adjustment of parameters
to function calls can make it hard to catch errors related to interface
changes. This is partly a judgement call unrelated to the language
though. When does a few local functions warrant promotion to a module in
its own right? And if I was more rigorous in applying unit tests and
contract enforcement I would perhaps have less problems.

Which is another mindset I had to overcome. Lua seems so carefree
relative to C that I had less motivation for rigorous unit tests and
contract enforcement, even though in my C code I am very rigorous with
both. This is just part of my changing perspective on Lua from a minimal
use glue language to a full language in which at least half the game is
written. So now I have unit tests for lua systems as well as the C ones.

I really think I am rambling now, so I will stop.

- DC