Lua is a powerful scripting language. Do you want imperative programming style? You have it out of the box. Do you want functional programming? Lua actually encourages such type of programming. Do you crave some object oriented style? Even if Lua does not provide object oriented mechanisms as it is, rest assured that you can quickly implement them thanks to some of its most used built-in features, like tables, metamethods and metatables. Lua’s original purpose was to be easily embedded in native host applications for scripting them. And as such, it thrives. That’s why it has been used for scripting in some of the biggest games in the industry, like this and this. And that’s why, when we talk about contemporary mobile game development, Lua seems to be prominent. Corona SDK, Gideros Mobile and MOAI SDK are probably the best solutions for cross-platform mobile game development and may be different in many respects, but they certainly share something in common. And that is Lua.
That said, let’s talk about the Spellbind engine. First of all, there are the screens. Each one is a class (basically a table defined in a file) and has a load() and delete() function with obvious purposes. There is a file for each screen of the game. And there is always the current screen, that is to say the screen that the player currently resides. When player leaves a screen and moves to another, the current screen is deleted and the next screen is loaded in its place. That way, only one screen is loaded in memory at a time. For keeping global information available to all screens, I use two global hash tables, one with boolean values and one with values of other types (string or numerical). When a screen is loaded, I use these two tables for deciding what to load and what not to. Transitions between screens are handled by a number of global functions. Save and restore functionalities are implemented by simply writing and reading the hash tables to the disk along with the items that exist in inventory. And that is all. Everything else is handled by Corona so I am free to deal with the actual scripting of the game.
So let’s say that player is currently in the cellar and decides to light a candle. That changes the image frame of the candle to a frame of a lit candle. A boolean value like “cellar_candle_lit” is stored in the hash table and it is set to true. Player leaves the cellar and comes back after a time. When the screen is loaded, the code checks if the “cellar_candle_lit” is true. If it is, the lit frame of the candle is rendered. If it is not, the default frame of the candle is rendered instead. And the same thing applies to every other changeable object of the screen. Simple as that.
One might argue that this approach involves rather complex “if-else” structures in the loading code of every screen. Well, this maybe the case, but so far I haven’t encountered any problems in finding my way among these structures and besides that, I believe that this approach of coding suits me just fine. Additionally, I can test any screen I want by just loading it and directly manipulating the values in the hash tables. Simplicity is a major priority for me, for practical but also for psychological reasons. And it seems that this “architecture” does its job well in that respect.
So far I’ve tested it in an iPad 2 with iOS 5.1 and it works just fine. I’ll try to do my tests in more than one android devices also. I have some considerations about the memory fragmentation on the device but I’ll deal with it when it is necessary. Till then, I will continue developing Spellbind as I’ve described.