Handling Collisions in Box2D

You can read about how collisions in Box2D work over in this tutorial, but in Moai you will find that a lot of the functions referenced there don’t actually exist.  There is no way to get the full contact list of everything that is colliding through getContactList().  However, Moai does provide one way to respond to collisions – the MOAIBox2DFixture’s setCollisionHandler() function.

Here is an example of how you can call it:

function handler(phase, fixtureA, fixtureB, arbiter) 
  print("we had a collision!")

myFixture:setCollisionHandler(handler, MOAIBox2DArbiter.END)

Continue reading Handling Collisions in Box2D

Box2D Basics

Box2D is a simple open source 2D physics engine.  It was written as part of a GDC talk in 2006, and a lot of famous iPhone games like Angry Birds use it.  You can find more information about it over at its website. I also found a great set of tutorials here, which introduce a lot of the concepts behind Box2D.  These tutorials are in C++, but you can get the general idea and apply it to Moai/Lua.  Moai has built in support for Box2D, so you can use it without referencing any additional files.

I’m not going to go too deep about how to use Box2D, but I’ll provide some general guidance to get you started.  In this post I’ll show you enough to demonstrate a simple ball bouncing on a floor.

Continue reading Box2D Basics

Moai Main Event Loop

The previous Moai example I posted before only setup a scene, but it didn’t have a main game loop.  The main loop can be important if you want to try to do something at a regular interval, like polling for input or advancing some game logic.  Here’s a basic example you can add to the bottom:

gameOver = false

local mainLoop = MOAICoroutine.new ()

mainLoop:run (
  function ()
    while not gameOver do
      -- Do processing here
      coroutine.yield ()
    print("Game Over!")

Continue reading Moai Main Event Loop

My Proposed Lua Style Guide

I don’t know much about how people typically style their Lua code, but I’ve picked a few guidelines I’m going to try to stick to.  They seem consistent with what the Moai SDK uses, and if you end up working with my code, please try to stick to it:

  • Always keep the scope as small as possible, which means marking most things “local”, including local helper functions.
  • Local variables are in camel case, starting with a lowercase character, without any kind of Hungarian notation.  For example “local numberOfItems”.  Since these are local, if you want you can go with “local number_of_items”, since it only affects the scope you are working on, so I don’t care so much.
  • Global variables are in camel case, starting with an uppercase character.  This includes classes and global functions.  For example “SpriteManager = CreateClass()” or “MyGlobalVariable = 1”
  • Keys in tables are in camel case, starting with a lowercase character.  This includes function names in classes.  For example “function SpriteManager:draw()”.
  • File names are all lowercase with underscores separating words.  For example “sprite_manager.lua”.
  • Tabs are 2 spaces.
  • Comment on any global variables that get created in functions.

Other than these items, I am not following an other strict style guide.  I did come across the style guide the Moai developers follow, and it is super long and really specific.  I haven’t found that it is worth it to care so much about such little things.  Also when in doubt, just match the code around what you are working with.

As a general design principle, I am still trying to stick with the general OOP concepts you would use in C++/C#/Java.  I’ve read that the “Lua” way to do things is not do use all these OOP patterns and just keep things as simple as possible, but I can’t imagine that scales well to larger projects, or would be easy to port to other languages.

Of course since I’m just starting out here, things might change, and if you can think of a better way to do things, let me know!