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’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!
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.
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:
At 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
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:
