With Unity 4.3 came native supports for 2D sprites. I tried to use these for some game prototypes but found that when I had small sprites that were rotated, I ended up with some ugly aliasing:
I tried a few things to get around this like resizing the texture and playing with Unity’s anti-aliasing settings. Nothing worked until I did the following:
Instead of setting my .png files as Sprites, I switched then over to Textures and made Materials with the Shader set to Transparent/Diffuse.
Disabled the SpriteRenderers I was using and added MeshFilter (Quad) and MeshRenderers.
Edit the art files so the art didn’t go all the way to the edge. Instead I left a transparent border around the sides.
After these changes, things looked smoother:
I did leave all my physics as RigidBody2D and 2D Colliders though, since they were working well for me. I don’t think it would be tough to switch over to regular RigidBody and Colliders, but the PolygonCollider seems unique and I want the keep the option open to use that rather than modeling 3D bounding boxes in a separate program.
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.
I’ve pretty much posted all the basic stuff I’ve learned about Moai already. Does anyone have any suggestions for topics they’d like to see? If so, leave a comment and I’ll do my best!
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:
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!
