Zombies have killed your family, eaten your neighbors and destroyed your city. Blinded by rage and seeking revenge, you go to the one place you know you’ll be able to find the undead……the graveyard. Armed with only a pistol and several grenades, you quickly get yourself lost. Now you must fight your way out of the graveyard or risk meeting the same fate as everyone else.

Dead End is a top-down defense shooter. Defend your position against the oncoming hordes of undead.

The full game is $2.99 and features:
- 20 Different Levels
- 20+ Upgradable Weapons and Grenades
- 9 Zombie Types
- 90 Achievements and 20 Rewards
- Endless Mode
- No Ads

There’s also a lite version with 3 levels to try out.

QR Code:

Now I just have to decide when that release will be. Originally I was planning on next week because I will be out of town for a few days this weekend. Of course I still have 3 days until then and plenty of time to fix any bugs that come from the release. Plus, if the game doesn’t completely fail, it’ll make vacation all that much better. If the game does completely fail, then I can use vacation to get my mind off of it. Releasing today is looking like the better option. Stay tuned!

1. Randomly play music from a folder on the SD card. This is mainly to allow custom music to be played while playing the game.

2. Create a lite version. The lite version will have 2 levels and ads and links to buying the game.

I’ll probably test it a bunch while finished those two things up and then (hopefully!) release it next week.

I’m also halfway done with adding enemies to the levels. Only ten more levels to go! I can see why game devs get sick of playing the games they created. I’ve gone through the levels so many times. It’s probably worse with mine since the levels are so repetitive. I do think it’s a fun game and a great time waster. I’m hoping that enough other people feel the same that it will make all the time I put into this game worthwhile. If not, I’m not sure if I’ll be able to convince myself to create something else.

Anyways, hoping I can get all the levels filled with enemies by the end of the week (tomorrow). Then I can get the Endless mode working, tie up some loose ends and I’ll be done! Well, all except for the lite version but that’ll be more about taking away features, not adding to gameplay.

1. Make a list of achievements and make them obtainable.
   - I figure it’ll take me a day to make up the list and a generic way to award, save and load achievements. The longer part will probably be awarding them when specific events happen. That might take me another day. But of course it depends how long I get to work on it.
2. Record stats during level; accuracy, times healed, etc.
   I’ll probably do this before figuring out the awarding of achievements since a lot of that depends upon level stats.
3. Finish up adding level enemies and difficulty tweaking.
   This is what I’m doing now and it will probably take the longest. Getting all of the enemies in there so that it’s not too easy and not too hard is difficult.
4. Add an endless mode.
   This will start at easy level and progress through and never end.
5. Make a lite version.
   This will be when everything is finished. The lite version will have ads and only 2 levels.
6. Maybe a time attack mode.
   I haven’t decided if I want to add this now or in an update. I guess it depends how long everything else takes me but I want to release the game soon and adding this mode will only prolong things.

That’s about it aside from bug fixes and minor additions. Maybe I’ll add another zombie type or something if I think of it.

Oh well, I know nobody reads this but writing all this out does help me focus better on what absolutely needs to be done.

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.

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.

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.

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.