I haven’t posted in a while, since I got caught up playing Dark Souls and that took a long time to finish up. Once I finished though I wanted to revisit working on a game. I also read that Unity was starting to offer free iOS/Android support, so I decided to check it out. It turns out that it is pretty simple to use, so I am switching my development over to that platform. Here are my concerns about the current state of Moai:

• While working with Moai is really simple (write up Lua scripts and run them through the compiled executable), the platform seemed to be losing momentum. As far as I know Doublefine’s big Kickstarter project is still using it, but Shadowrun switched over to Unity during their development. Without more big projects to drive the codebase forward, it will probably stop getting support.
• One of Moai’s developers posted on the forums saying that while the engine isn’t dead, he is too busy with their regular projects to be actively spending a lot of time working on it.
• Moai still has some bugs that seem pretty bad which don’t seem to have solutions.  One thing I remember reading is that sound on the PC is supposed to be buggy.  Since the released projects have all been on iOS/Android, I don’t think the other platforms like PC/Mac/Linux are getting much attention.
• Lua is really flexible so you can write cool frameworks to handle different things you are trying to achieve.  However, since it is pretty freeform, it becomes pretty difficult for other people to pick up and read your code without studying all of it.

I gave Unity a shot and here are my findings:

• Re-implementing some of my game prototypes I had in Moai in Unity was really simple.  I could save a lot of time here.
• The interface is kind of similar to 3d modeling programs, which I am pretty comfortable with.
• Deploying projects to various platforms (so far I’ve tried PC, Web, iPad, iPhone) is really simple.  Being able to get stuff loaded onto a website is especially helpful when trying to get other people’s feedback on a prototype.
• The way you write C# scripts to add functionality to objects results in a lot of small scripts, each of which tries to accomplish a single thing.  This is pretty modular and I think easier to understand for people looking at your code.  You don’t need to know how all the classes work to understand one specific class.  You do need to know how the Unity classes work though, which is all documented online.
• With Unity 4.3, 2D/Box2D support is built in and easy to use.
• Loading levels/objects from output of other programs like Tiled is a little messier, since you need to parse the file and then manually generate Unity objects with them.  It seems easier to just use the built in level editor and do everything “their way”.

As I get further along I’ll try to keep posting updates on this blog.  I’m not going to be documenting techniques/tutorials though, since that stuff seems pretty well covered in general on the internet.

If you search through general Box2D help or tutorials, you’ll realize that there are references to many functions that are not available in the Moai.  This is because everything we can access in Lua has to be exposed in the C++ source code, and they only did this for certain important functions.  Some examples of missing functions are ray casting or getting a list of fixtures for a given body.  Since Moai is open source, we can download the code, edit it and then have your own custom build that lets you access this extra functionality.  However, this sounds like a lot of work, and there is an easier way.

Since getting a list of fixtures is conceptually pretty simple, we can actually implement it ourselves in Lua.  Whenever someone calls the add* functions on MoaiBox2DBody (like addCircle() or addRect()), we want to keep track of the result and store it in a list.  Then we need to create a new function getFixtureList() that returns this list.  Using the same technique as I showed last time to override the dofile() function, we can override the add* calls to keep track of the fixture list.  It looks something like this:

Continue reading Maintaining Fixture Lists for Box2D Bodies →