Infectious Entertainment

I’m making progress with Dead End and think it might actually be finished in the near future. I still have to add enemies to all the levels and increase the number of enemies, enemy damage and cash for the difficulties. Some other stuff needs to be done but that’s the main work left. I’m not sure how long it will actually take because it seems like some tweaking with weapon costs and enemy amounts will need to be done to make the difficulties work properly.

I just wanted to take a moment and mention how thankful I am for project hosting. I have Dead End’s source privately hosted on Unfuddle. This allows me to use tickets to track work needing to be done and more importantly, they have all of the source code in a Subversion repository.

I didn’t find out how glad I was to be using Unfuddle until my hard drive crashed and I lost everything on it. Since I’m developing Dead End by myself I really don’t have a need for source control other than it helps me stay organized. I could just as easily stored the project locally but then it would all be gone.

If you’re starting out a solo project and storing it locally, either make frequent backups or consider using a project hosting service like Unfuddle. It’s free for the first project so there’s nothing to lose.

If you’ve checked out the alpha release of Dead End, you will have noticed that the primary way of controlling the player is through the use of the accelerometer.

The accelerometer measures the force of gravity on the phone’s X, Y and Z axes relative to its current orientation. On earth that would mean that value can be between +/- 9.8 (although my phone maxes out at +/- 10.5, I don’t know why). Take the Z axis for instance. The Z axis runs directly perpendicular to the screen of the phone. If you have the phone standing vertical with the screen facing you, the Z axis will be completely horizontal and the accelerometer will give a 0 value for that axis. If you tilt the screen forward until it’s facing the ground then you will get the max value on that axis.

In Dead End, I take the value the accelerometer gives me and I translate this into a rotation degree for that axis. Turning the phone all the way to the left should rotate the player 90 degrees to the left. So the max value of the accelerometer corresponds to 90 degrees and the angles in between can easily be interpolated.


int mAccelMax = 10;
float mAccelMult = 90 / mAccelMax;
if(y > mAccelMax)
  y = mAccelMax;
else if (j < -mAccelMax)
  y = -mAccelMax;


rotate = y * mAccelMult;


Here, y is the accelerometer value for the y-axis. We define a value which is the accelerometer value at which the rotation should be 90 degrees. Here I made that 10, roughly the max value my phone reports. The multiplier is what interpolates the values in between. Since the max is 10 and we want to go a total of 90 degrees, each time we go up 1 on the accelerometer, we want to rotate 9 degrees. At 10, this will be 90 degrees.

If you want to make the tilt control more sensitive then all you have to do is lower the max value. This will cause mAccelMult to increase which increases the rotation each time we go up 1 on the accelerometer.

You can also redefine the center of rotation, the point where the accelerometer reports 0 and rotation is 0. This allows players to decide how the orientation that they hold the phone at rather than defining it for them. To do this, just subtract the accelerometer value of the point you want to be the center from the current reading.


y -= mHorizontalCenter;


int mAccelMax = 10;
float mAccelMult = 90 / mAccelMax;
if(y > mAccelMax)
  y = mAccelMax;
else if (j < -mAccelMax)
  y = -mAccelMax;


rotate = y * mAccelMult;


As you can see, this is the same code as before except for the very first line.

It's easy enough to use the options menu to allow the player to set tilt sensitivity and horizontal/vertical centers.

Next time I'll post about a problem I had with tilting the phone too much in one direction while having a custom centering point.

Coming from a C++ background, I never really had much experience with garbage collection before working with Android. Sure, I’ve used Java and Flash/Flex quite a bit but I never had to worry about it since I wasn’t working on performance critical code. Created objects would automatically get cleaned up and I didn’t care how.

In C++, every object that you create needs to be explicitly released. With Java, you don’t explicitly release objects. You just remove all references to an object you don’t need anymore and the garbage collector will eventually come along and release it for you.

This works fine when you don’t care about performance. However, when you’re creating a game on a mobile device, you need all the processing power it has and you’re definitely going to notice when the garbage collector is running. Throw in the fact that you have no idea when it’ll run and you have a problem. Depending upon how much memory is being released, you might see your program/game skip every few seconds or a few times per second.

How do you know the garbage collector is to blame for this problem? Simple. Watch the log output in the DDMS while your program is running. It will continually show lines like

GC freed 1307 objects / 88360 bytes in 159ms

every time it skips. Fixing this problem isn’t the hardest thing in the world. It’s more tedious than anything else.

The first thing you need to know, is what will cause the garbage collector to run. Since it works by releasing any unreferenced objects, the more objects you stop using, the more often it’s going to run. “Object” here mainly refers to a variable that at some point was assigned a value using the “new” command. This applies to basic arrays (new int[5]), class objects and also iterators for ArrayList and Map collections. It’s important to note that primitive types (int, float, double, etc.) DO NOT cause garbage collection. I’ve seen some places claim that they do and that completely screwed up some of my code in the very beginning. However, if you use a wrapper for a primitive type (Integer, Float, etc.), then unreferencing that WILL cause garbage collection.

Like I said before, fixing this is pretty easy but can be time consuming. Take the following code for example:

for(int i = 0; i < 10; i++) {
  Object obj = new Object();
}


Every loop creates a new object while unreferencing the old one. Those unreferenced objects will eventually need to be cleaned up by the garbage collector. A better way to handle this would be:

Object obj = new Object();
for(int i = 0; i < 10; i++) {
  obj.init();
}


Rather than creating a new object every loop, just reinitialize the existing one.

Here’s another example that will eventually cause the garbage collector to run:

public void createObject() {
  Object obj = new Object();
}


Everytime this method runs, a new Object will be created. If you’re not holding onto that object somewhere, it’s going to get unreferenced and collected. A better way would be to do this:

private Object mObj = new Object();
public void createObject() {
  mObj.init();
}


This way, the object is only created once and then reinitialized every time the method runs.

This can be applied to groups of objects as well. If you have multiple objects of the same type that can be created or destroyed at any point, then create an object pool. An object pool is just an array that holds objects that aren’t currently being used. When you need an object, check to see if the pool is has one. If so, reinitialize the object. If not, create a new object. Then when you’re done with an object, clean it up and stick it into the pool to be used later.

The last thing you need to know is how to find the problems. You could search through all of your code but if you’re not aware of this problem at the very beginning, that could take a very long time. The other option you have is using the Allocation Tracker in the standalone DDMS. You can find the DDMS in the Android tools folder that is installed with the SDK. Here’s the info on working the Allocation Tracker. This will show you exactly where objects are being allocated. If you see any excessive memory allocations (objects being created in a loop) that are unnecessary then you can use the previous tips on cleaning them up.

Hopefully this helps somebody out there. It’s a bit of a pain in the ass to explain properly so if you have any questions, just let me know.

Some of the feedback for Dead End was mentioning that the tilt controls were too jerky. I’ve noticed this before and tried to fix it before but never did. It was especially noticeable when using the tilt aiming in a moving vehicle or while a little kid is jumping on the couch next to you.

Last time I tried to fix this, I googled for “Accelerometer Smoothing” and picked one way of handling it. The fix was way too complicated and didn’t work. Coming back to the problem, I did the same thing again and this time found a much, much simpler approach. I have no idea how I didn’t find this solution before but I’m glad I did because now the tilt movement is way smoother.

The solution is called a low-pass filter. It essentially filters out any drastic changes to the accelerometer values so that objects controlled by the accelerometer move at a more gradual pace.

float accelFilter = 0.25f;
x = x * accelFilter + lastX * (1 - accelFilter);
...
Do something with accelerometer values
...
lastX = x;


That’s really all there was to it. Incredibly simple and yet for some reason it took me this long to find it.