Preventing Duplicate dofile() Calls in Lua

I’m using dofile() to pull in support files, similar to how you would use #include <filename> in C++.  However, you can’t do the C++ #ifdef syntax to prevent a file from getting included more than once. You can however customize the dofile() function to do something similar.  Remember that all function names are variables that you can assign in Lua.  Here’s the code:

local oldDoFile = dofile
local loadedFiles = {}
function dofile(filename)
  if loadedFiles[filename] ~= true then
    print("Loading " .. filename)
    oldDoFile(filename)
    loadedFiles[filename] = true
  else
    print("Skipping load for " .. filename)
  end
end

First you save a reference to the existing dofile() function, but call it oldDoFile.  We also have a local table to store all filenames that have been loaded called “loadedFiles”.  Then we can redefine dofile() to check this table before calling the oldDoFile() function.  Now you can add dofile() calls to the tops of your various .lua scripts without worrying that a file will get included twice!

Handling User Input – InputManager

There are two ways to handle user input in Moai – by polling or registering callback functions.  I’m going to focus on polling for now, since that is what I am using.  Moai provides some ways to check for input through the MOAIInputMgr.device and it’s properties.  Depending on your device/host, there will be different properties like MOAIInputMgr.device.touch (touch input on a phone) or MOAIInputMgr.device.mouseLeft (left click).  To use these you could do this:

if MOAIInputMgr.device.mouseLeft:down() then
  print("the left button is down!")
  --do your logic here
end

However, this will fail if your device doesn’t actually have a left mouse button, like on an iPhone.

Continue reading Handling User Input – InputManager

Managing Game State – SceneManager

We have a bunch of scene definitions now, but how do we keep track of them and transition between them?  A solution is the SceneManager class, which maintains a stack of Scenes and handles adding/removing/updating them.  Here’s what the stack might look like, with each layer being a Scene:

sm_exampleAt each step, only the top Scene on the current stack will be updated and drawn.  As Scenes are added to the stack, they are initialized, and as they are taken off, they will be cleaned up.  The interface for the SceneManager will be as follows:

  • pushScene(scene) – add a new scene to the top of the stack
  • popScene() – remove the top scene
  • update() – should be called every loop iteration, calls update() on the top Scene

Continue reading Managing Game State – SceneManager

Defining Game State – Scenes

Now that we have a lot of the basic pieces in place to make a simple game, we need to think about how to keep track of game state.  For example, how do you know to start with a start menu?  How can you transition to the actual gameplay?  What if user wants to pause the game or quit?

We do this by defining each one of these game states to be a Scene.  Some examples are:

  • Start menu
  • Settings dialogs
  • Credits scroll
  • Game level
  • Game map
  • Pause menu

Continue reading Defining Game State – Scenes

ResourceManager – Keeping Track of Decks and Props

Remember in Moai, you think of graphics resources in terms of Decks and Props. Decks are the actual definition of the resource – the vertex locations, texture data, etc. A Prop is a reference to a Deck and any information used to actually draw an instance of it – the actual location or any other transformation. In order for this to work though, you need to keep track of all your Decks in order to create new Props. I wrote up a class called ResourceManager to help with this.

ResourceManager = {}

--cache of filename -> deck
local cache = {}

Since we want this to be accessible anywhere, I’m treating this like a static class. That means I don’t need to use the CreateClass() function I introduced earlier – I just need to create a global scoped table and add some functions to it. Since there will only ever be one instance of this, I can create private variables by just declaring them local. Here, “ResourceManager” will be the name of the class, and we have a private table “cache”, which we will use as a dictionary with a string (filename) to Deck mapping.
Continue reading ResourceManager – Keeping Track of Decks and Props