Category: Software Development

Previously I Implemented the A* path finding algorithm so the people in Pineapple Town or wherever this game takes place can actually walk to wherever it is that they’re going. I was pretty excited about that, it was probably one of the more complex things to tackle in the making of this game and now I had finally finished it time for celebration! Well not quite. Actually all I had done was write the code to return a path for the Walker, as I dubbed the people trapped in my simulation, and now I needed to write the code for them to actually follow the path.

Following the Path

This wasn’t really that big of a deal, as you may remember from last time the final path returned is a series of locations for the walker to follow, and we can just generate a vector for the walker to travel along for each step of their path. That code ended up looking like this:

public void followPath()
{
    if (path == null)
    {
        System.out.println("path is null");
    }
    else // if a path exists then go to it step by step
    {
        dx = (path.getX(stepNum) - x);
        dy = ((path.getY(stepNum) - 72) - y);

        double factor = speed / Math.sqrt(dx * dx + dy * dy);

        dx *= factor;
        dy *= factor;

        // if they are at the next step check if its the end of the path and move up
        if (Math.abs(path.getX(stepNum) - x) < speed && Math.abs(path.getY(stepNum) - 72 - y) < speed)
        {
            setX(path.getX(stepNum));
            setY(path.getY(stepNum) - 72);
            dx = 0;
            dy = 0;

            stepNum++;
            if (stepNum == path.getLength())
            {
                status = 2;
            }
        }
    }
}

Here we set a static value for the walking speed of the walker, which is essentially how long it should take the walker to move from one step to the next. We divide that speed by the Pythagorean length of our travel vector to get a scalar value we can use to modify our total x and y distance that we move each frame. The checking if the path is null is really just a last resort to warn me something terrible has happened because there are other systems in place here to stop the null path from getting this far. The last if statement tells us the walker has reached the end of the path, and changing the walker’s status to 2 essentially just tells the walker to execute whatever they are supposed to be doing at the location they arrived at.

So that is how the walkers follow their paths. I went so far into detail about this because it is instrumental to understanding how they wait in line, as its a fairly simple modification to this.

Waiting in Line

For waiting in line I initially considered making the walkers recalculate their route to a predetermined “end of the line” tile which would change whenever it was occupied. But to me this sounded too complicated to implement, instead I decided to go for a more organic approach. Instead of artificially defining a line I would let how the walkers spawn and make their way to the lemonade stand dictate how the line forms. Lets look at the code and some game footage to get a better idea of what I mean.

if (stepNum == path.getLength() - 1)
{
    status = 2;
}

isWaitingLine = true;

The journey of our line starts here, if the walker’s destination is the lemonade stand then we check to see when he arrives at the step of the path before he starts buying lemonade. Once he is we then execute this code:

if (status == 3) // is waiting in line
{
placeInLine = path.getLength() - stepNum - 1;

if (isWaitingLine)
{
 dx = 0;
 dy = 0;
 if (walkForwards.getCurrentFrame() != 6)
 {
 walkForwards.update();
 }
}

We set this walker’s place in line relative to how many steps he has taken to get to the lemonade stand,  giving priority to whoever is closest to the lemonade stand and then also whoever walked the furthest to get there. However, since this walker doesn’t have anyone else to deal with, he just keeps walking to the lemonade stand. So he enters status = 2 which will execute this code:

if (status == 2) // Arrived at end of path, is first in line
{
    dx = 0;
    dy = 0;

    if (wantsLemon)
    {
        inLine = true;
        placeInLine = 0;
    }

Now to see how our line develops we need to look at the collision code for when walkers walk into each other. Lets introduce a second walker to the situation.

if (collision(walkers.get(i), walkers.get(j), false))
{
    hasCollided = true;

    // if they are going to the lemonade stand
    if (walkers.get(i).wantsLemon)
    {
        // if they collide with somebody in line and we are not in line then get in line
        if (walkers.get(j).inLine)
        {
            // our walker is now in line, one place behind the person they collided with
            walkers.get(i).inLine = true;
            walkers.get(i).setStatus(3);
        }

Here we will say i is the new walker and j is the one who just arrived at the lemonade stand. We are checking if they collide with someone who is waiting in line, in this example our original walker who was just about to buy their lemonade. We tell our current walker that they are now in line and their place is defined by the code executed in status 3, the waiting in line status. So now we have two walkers who are next to eachother, they both want lemonade, and they are both technically “in line” and have placement to say who gets priority. Next we just tell the walker with the lowest priority to wait until all other walkers with higher priority leave, and that’s it! We’ve got a line going on.

else if (walkers.get(i).status == 3) // if the walker is in line
{
    // if they do not collide with somebody who is ahead of them in line then go forwards otherwise just hang out
    boolean hasCollidedNextPerson = false;

    for (int j = 0; j < walkers.size(); j++)
    {
        // If it is the same walker then move on
        if (j == i)
        {
            continue;
        }

        // if they collide with somebody ahead of them in line
        if (collision(walkers.get(i), walkers.get(j), false) && walkers.get(j).placeInLine < walkers.get(i).placeInLine)
        {
            hasCollidedNextPerson = true;
        }
    }

    // if they don't collide with anybody ahead of them in line and they are waiting then move up
    if (!hasCollidedNextPerson && walkers.get(i).isWaitingLine)
    {
        if (walkers.get(i).placeInLine != 0)
        {
            walkers.get(i).stepNum++;
        }
        walkers.get(i).isWaitingLine = false;
    }

Here we are manually advancing the step of the path that the walker follows when they meet no opposition from someone who is also in line and has a higher priority than them. This code may seem to jump around a lot but that’s because it takes advantage of 3 systems I already had in place for controlling AI, the collision system, path following system, and their “status” system. I think it was a good design decision to make use of those tools instead of creating an entirely new system to handle waiting in line. Now lets take a look at the code in action to confirm it does indeed work.

I just spawned a few walkers and disabled buying anything to display the line forming. We can see that there is actually 2 lines forming here but that actually doesn’t provide any conflict as their place in line is not based on how many people are physically ahead of them but rather how close they are to the lemonade stand. Now lets wrap this up by finally looking at how I “implemented” the walkers cutting each other in line.

Emergent AI Behavior: Its a Feature not a Bug!

So something I quickly noticed when testing this code is that the walker’s don’t always let the person who has waited the longest go first, because their place in line is based only on their distance to the lemonade stand and how long it took them to get there. Instead of fixing this bug I decided to encourage this behavior ,cause you know what, in real life people don’t always let the person who waited the longest go first so why should my game do that! Call it a metaphor for the capitalist themes that Lemonade Stand is pushing, its survival of the fittest when you’re thirsty and the lemonade stand can only serve one person at a time. I accomplished this by addressing the edge case for when the walker encounters someone who has the same place in line as them:

else if (collision(walkers.get(i), walkers.get(j), false) && walkers.get(j).placeInLine == walkers.get(i).placeInLine)
{
    // if someone is in the same place in line as them let them cut you cause they're so mean
    walkers.get(i).placeInLine++;
}

So whoever we check first will end up letting the other person have the right of way. Technically in the code this means that its just this one guy being excessively nice but I like to think of it as him being taken advantaged of. Here’s some actual footage of this occurring:

I also made it so there is a delay when they buy lemonade, to make lines more likely to form. So really here I decided to change the code to favor a stylistic outcome that is probably not the “ideal” outcome you would initially expect. I think that this will add a lot to the game though, if the walkers only formed one line and always let the person first in line go that would perhaps look better, but I think this more organic system will help add character to the walkers. That is actually one of my primary goals for this game, and I think this was a good step to achieving it. Thanks for reading all the way through this marathon of an article, see you in the next update!

In a previous article I mentioned how I had some issues with the way I decided to render isometric tiles, and implementing pathfinding. So lets talk about how it is I overcame those problems and why implementing A* was way more difficult then it should have been. First, so we are all on the same page, lets go over the A* algorithm itself.

The A* Algorithm

What A* is meant to do is find the shortest and most efficient path to get from point A to point B. Its important to make the distinction that not only is it the shortest as in the most direct path, but also the most efficient. The reason that this algorithm is so widespread is that it can adjust for both distance and efficiency.

This algorithm creates the best path by testing every node that is accessible to the object it is moving. In our case, a node can be a tile on a tile map. It tests every object for two values. First, its g cost which is usually the physical (or digital) distance that the mover would have to go to reach that node or tile. The second value it tests, is the node’s heuristic a value that estimates how cheap it is to go to that node. As an example, say you are racing in a dirt bike trying to escape from a bipedal amphibious radioactive monster. You come across a turn in a road that goes around a pit of quicksand. The shortest distance from point A to point B, that is, your current location to a nuclear bunker stocked with bipedal monster repellent, would be to cut across the muddy path. So your g cost tells you to keep going straight. However, the heuristic of the dirt road is way less than the heuristic of quicksand so the best path is to stay just on the edge of quicksand.

That’s what makes A* so convenient, it can be applied to myriad of situations and is (usually) not to hard to implement. Lets look at how we would go about implementing in java.

Implementation

A* works by keeping two sets or lists of nodes to check and compare their heuristic and g costs against each other. The first set is called the Open Set which contains all the nodes to be checked. Nodes are added to the open set based on if they are adjacent to either the starting position, or adjacent to a node in the closed set. Nodes are added to the closed set when their g cost and heuristic are calculated. The algorithm decides which nodes from the open set to check by defaulting to the one with the lowest combined g cost and heuristic. You can see how easy this would be to achieve in Java by using a SortedList for the open set and an ArrayList for the closed set. The open list is sorted by the combined g cost and heuristic of every node, the f value. However in order to populate the lists with nodes we need to define what exactly a node is.

private class Node implements Comparable<Node>
{
    private int x;
    private int y;
    private int cost;
    private float f;
    private float heuristic;
    private Node parent;
    private int depth;

    public Node(int x, int y)
    {
        this.x = x;
        this.y = y;
        f = cost + heuristic;
    }

    public int setParent(Node parent)
    {
        depth = parent.depth + 1;
        this.parent = parent;

        return depth;
    }

    public int compareTo(Node other)
    {
        if (f < other.f)
        {
            return -1;
        }
        else if (f > other.f)
        {
            return 1;
        }
        else
        {
            return 0;
        }
    }
}

So this is the creation of our node class, basically it is defined by its x and y values, which are taken from our level data array. Its other attributes are its ability to have a parent node, basically it saves the node that it is connected to so we can later recreate the pathway once the algorithm is done. Also it has a depth value, telling us  how many levels we are within the algorithm and also the number of nodes that make up the path. Finally it can be compared to other nodes based on what its f value is, a prerequisite for being included in a SortedList.

Before going into how g cost and heuristics are calculated lets look at a visual representation of the algorithm using what we already know.

Here we can see the open circles represent nodes in the open set while colored nodes are in the closed set. The more green the color is the closer to the goal the nodes are. Right away you can see how the algorithm investigates all the nodes in a straight line towards the goal until it hits a barrier, because those nodes all have much lower f values than the nodes way back by the starting position. Once it hits the barrier then it doubles back and investigates those nodes around the start.

Understanding nodes and the open and closed sets is all well and good, but how do we go about calculating the g cost and heuristic?  Here is where it gets a little tricky. Lets start with the g cost.

// Get movement cost of node
public int getMovementCost(GameObject mover, int sx, int sy, int tx, int ty)
{
    CoordinatePair start = map.tileToCoords(sy, sx);
    CoordinatePair target = map.tileToCoords(ty, tx);
    int dx = Math.abs(target.getX() - start.getX());
    int dy = Math.abs(target.getY() - start.getY());

    if (dx != 0 && dy != 0)
    {
        return 108;
    }
    else
    {
        return 208;
    }
}

This function accepts the type of object that is being moved (in case you want a person and a car to behave differently), the starting x and y coordinates, and the target x and y coordinates. I convert the values from level data coordinates to actual x and y coordinates using my function I detailed in a previous article and then get the distance between the two point on the x and y axis. I then check if the mover is moving on more than one axis i.e. diagonally, and give it a lower movement cost than if the mover were to go directly up, down, left or right.

This is to avoid people from walking in crazy zigzag patterns that don’t make any sense, which did happen a lot prior to fine tuning the movement cost of the two different types of moves.

We then calculate the heuristic by finding calculating the Euclidean distance between the node we are investigating and the goal.

// Get Heuristic of node
public int getHeuristicCost(GameObject mover, int x, int y, int tx, int ty)
{
    CoordinatePair start = map.tileToCoords(y, x);
    CoordinatePair target = map.tileToCoords(ty, tx);
    int dx = Math.abs(target.getX() - start.getX());
    int dy = Math.abs(target.getY() - start.getY());
    return (int) Math.sqrt((dx*dx)+(dy*dy));
}

An alternative to this is calculating Manhattan distance, essentially just adding the difference between the x and y positions of the two nodes without square rooting or squaring them. This would obviously be much faster, but does not work with the “zigzag” style system we are using to store our level data. This leads well into the next topic, the problems introduced by using zig zag style isometric rendering, which are not introduced when using “normal” style isometric data. More info can be found in the aforementioned previous article.

Problems with Isometric Data

As mentioned in the previous article, I am storing all my level data as an offset grid to better approximate how the level data will actually look in the game. An array of tiles might look like this:

[[1,1,1,1,1],
  [1,0,0,0,1],
 [1,0,0,0,1],
  [1,0,0,0,1],
 [1,1,1,1,1]]

While Manhattan distance works just fine with a standard grid, this offset data will not work at all with that distance calculation. This is because the tiles directly above the starting tile are actually either to the left or right of the starting tile, and not just above it. This is also why we needed to convert the coordinates of the nodes to actual pixel coordinates, because the cell coordinates of where the node is located in the array are inaccurate to where it is located on the screen. Essentially the need to convert the data slows down the algorithm with extra calculations.

Now to the issue that gave me the most trouble with implementing the A* algorithm into the zigzag data: selecting adjacent nodes to enter the open set. Lets start by looking at what we want to do, select the 8 nodes around the starting position.

The green color denotes our starting position, while the red show the tiles with the smallest movement cost and the blue are the larger movement cost. You can immediately see a problem when looking at the coordinates shown on the image. If the algorithm simply added and subtracted 1 to the x and y location of the node, it would not get the right nodes at all. Instead the algorithm needs to take into account 5 different rows of data, with a different number of  columns for each row. My solution to this is certainly not the cleanest but I couldn’t think of some kind of miracle equation that would give me all the correct adjacent tiles mathematically, so I had to iterate through each row individually. Here’s what the code looks like:

// Look at each tile neighboring our current one in a diamond pattern
for (int y = -2; y < 3; y++)
{
    // Check if y is odd to offset accordingly on the diagonal neighbors
    int offsetX;
    if ((current.y & 1) != 0)
    {
        // cellY is odd and y is odd
        offsetX = 1;
    }
    else
    {
        // cellY is even
        offsetX = 0;
    }

    // Make sure the diamond is wide enough in each row
    int numXNodes = 3 - Math.abs(y) + offsetX;

    // Add enough new x nodes per row to make a diamond
    for (int countX = 0; countX < numXNodes; countX++)
    {
        // Define each x starting place, sure wish I had some kind of formula for this.
        int x;
        if (y == 0)
        {
            x = -1 + countX;
        }
        else if (Math.abs(y) == 1)
        {
            x = -1 + countX + offsetX;
        }
        else
        {
            x = 0;
        }

        // if this is the node we are on then skip it
        if ((x == 0) && (y == 0))
        {
            continue;
        }

        int xp = x + current.x;
        int yp = y + current.y;

So that’s how I added eligible tiles to the open set. After I got that out of the way it was pretty much standard implementation from there, you would check all the surrounding nodes for the one with the lowest heuristic and g cost then move onto the next one. That code looks like this:

if (isValidLocation(mover, sx, sy, xp, yp))
{
    int nextStepCost = current.cost + getMovementCost(mover, current.x, current.y, xp, yp);
    Node neighbour = nodes[xp][yp];

    if (nextStepCost < neighbour.cost)
    {
        if (open.contains(neighbour))
        {
            open.remove(neighbour);
        }
        if (closed.contains(neighbour))
        {
            closed.remove(neighbour);
        }
    }

    if (!open.contains(neighbour) && !(closed.contains(neighbour)))
    {
        neighbour.cost = nextStepCost;
        neighbour.heuristic = getHeuristicCost(mover, xp, yp, tx, ty);
        maxDepth = Math.max(maxDepth, neighbour.setParent(current));
        open.add(neighbour);
    }

This code essentially removes a node from the open list and into the closed list if it has a lower f value than its neighbors and then uses that node as the next starting point. The maxDepth is the predetermined limit to how long the algorithm will search before it gives up.

All of the previous code is executed in a loop until either maxDepth is reached or the goal is found by the algorithm. The while loop saves the closed set and exits where a Path is constructed. This part is made much easier by having the nodes save their parents!

// If finding a path was unsuccessful return null
if (nodes[tx][ty].parent == null)
{
    return null;
}


// We have now definitely found one, build the path starting from the target and work our way backwards using the parent identities
Path path = new Path();
Node target = nodes[tx][ty];
while (target != nodes[sx][sy])
{
    CoordinatePair targetCoords = map.tileToCoords(target.y, target.x);
    path.prependStep(targetCoords.getX(), targetCoords.getY());
    target = target.parent;
}

return path;

Finally we return Path and the algorithm is complete. The path is essentially a collection of the x and y values for the mover to follow, in the next update I’ll go into how this path is followed by a walking person and how it was adapted to also serve as the code for waiting in line too. I hope you enjoyed the article, I’ll see you in the next update!

 

In a previous article I talked about why a business simulation even needs graphics. Moving beyond the psychological ideas of why a graphical based interface is much more exciting than simply watching numbers go up, the main concern was introducing other levels of user interaction beyond setting some initial variables like price and then watching the game play itself for a few minutes. Having a robust graphical interface is necessary for these other levels of interaction occur in a meaningful way. In this article I’ll go into detail about this supposedly “robust” graphical system, or in other words, lets talk about the graphics.

When I first started making this game I wanted to try a new graphical style; previously I had made Flash based side scrolling platformers and shooters Though a side scrolling platformer business simulator would certainly be interesting, I was thinking more along the lines of a top down or isometric style game. I quickly decided on pursuing the latter, mainly because I wanted to push my boundaries more, and I thought that the coding implementation between a side scrolling view and a top down view was too similar. Also I noticed a trend among simulation games I had played, namely RollerCoaster Tycoon and SimCity: they also were all isometric. Also, to make AI pathfinding and rendering more simple, a tiled system was an easy approach to take.

When I started researching ways to implement an isometric rendering system I found that there were basically two main ways to go about drawing isometric tiles. The first and perhaps most common is where the world is viewed as a diamond.

The Diamond Approach

The information describing the map is arranged in a standard grid like so:

[[1,1,1,1,1],
 [1,0,0,0,1],
 [1,0,0,0,1],
 [1,0,0,0,1],
 [1,1,1,1,1]]

A simple two dimensional array, that looks and functions exactly the same way as one for a top down or side scrolling grid would. The difference here is that the rendering code interprets the grid as:

..  ..  1  ..  ..
  ..  1   1  ..
..  1   0   1  ..
  1  0     0  1
1  0    0    0  1
  1  0     0  1
..  1   0   1  ..
  ..  1   1  ..
..  ..  1  ..  ..

There are two ways to achieve this. First, you could create a new area holding level data, and populate all the cells where the dots are above with null data, but this removes the advantage that this diamond rendering approach has, that the data does not need to be changed at all. Instead we can edit the code used to render the tiles to rotate them 45 degrees to one side. Some sample code might look something like this:

level_data[][];

for (cellY = 0; cellY < level_data.size; cellY++)
{
    for (cellX = 0; cellX < level_data[cellY].size; cellX++)
    {
        draw(
        level_data[cellY][cellX], 
        screenX = (screen_width / 2) + (cellX * tile_width / 2) - (cellY * tile_width / 2) 
        screenY = (cellY * tile_height / 2) + (cellX * tile_height / 2));
    }
}

This is a pretty simple nested for loop, iterating through each dimension of our level data. For simplicity’s sake lets say that level data is the array shown above. This function iterates through every “row” of tiles and draws them diagonally. It does this by changing both the x and y coordinates of every subsequent tile drawn by one half of the tile’s size. Its only half a tile size because the tiles are stacked diagonally on each other, so there is overlap of the tile’s dimensions but graphically looks correct.

This method will render the tiles in this order:

Each new color is a new column or cellY value, so you can see how it is rotated 45 degrees to the right. This approach of rendering from the back to the front also makes sure that tiles of varying height like buildings appear correctly.

This diamond approach has one major failure however, and that is if you want your level to fill the entire screen you need to have a lot of empty data to fill out the corners of the screen. Enter, the other “zig zag” method, the method I decided to use for my game Lemonade Stand.

The Zig Zag Approach

Lets start by taking the same level data array I had before:

[[1,1,1,1,1],
  [1,0,0,0,1],
 [1,0,0,0,1],
  [1,0,0,0,1],
 [1,0,0,0,1],
 [1,1,1,1,1]]

The zig zag approach would render it like this:

..  ..  ..  ..  ..
   1   1   1   1
..   1   0   0   1  ..
   1   0   0   1
..   1   0   0   1  ..
   1   0   0   1
..   1   0   0   1  ..
   1   1   1   1
..  ..  ..  ..  ..

That’s a little hard to visualize so lets look at another informative gif made by yours truly:

This looks more complicated than the diamond approach at first, and that’s because it is a little more complicated. The major benefit that the zig zag method has is you need far less dummy data to fill an entire screen, and the level data in a two dimensional array gives a better approximation of how the level will actually end up looking compared to the diamond approach. For these benefits, the code used to implement it is a little more tricky and a simple nested for loop isn’t going to cut it.

Luckily it only really requires an extra if statement that checks which row we are currently rendering and then shifting all the tiles over the appropriate amount. Here’s some code that I use in my game to convert cell coordinates to actual screen coordinates:

// Convert Cell data from tile map to x and y coordinates
public CoordinatePair tileToCoords(int cellY, int cellX)
{
    int x;
    int y;
    int offsetX;

    if ((cellY & 1) == 0)
    {
        // cellY is even
        offsetX = 0;
    }
    else
    {
        // cellY is odd
        offsetX = TILE_WIDTH / 2;
    }

    x = ((cellX * TILE_WIDTH) + offsetX) - TILE_WIDTH;
    y = ((cellY * (TILE_HEIGHT / 2)) - ((TILE_HEIGHT / 2) + TILE_HEIGHT));

    return new CoordinatePair(x, y);
}

This is really the only part that’s different from the rendering code, you would still need to use a nested for loop but here there’s an extra step of checking if you are on an even or odd row. I do this by checking the last bit of the integer to see if its a 0 or 1; if the bit is 1 then the number is odd, otherwise its a 0 and the number is even. If you don’t understand this application of binary I encourage you to experiment with this handy learning tool courtesy of Harvard’s into to computer science course, CS50. Mostly by entering a number and toggling the first bit or “bulb” from one to zero (or on and off) to see how the number changes from even to odd.

So anyways as I mentioned before, ultimately I chose the zig zag method over the diamond one. This was mostly because at first glance I thought the code would be easier to implement, though that turned out to be not really correct. Also I didn’t want to have to fill my array with so much empty data that wouldn’t be shown on screen. In hindsight, and for any future isometric games, I’ll probably use the diamond method. This is because later on in development I found that the zig zag data is much harder to work with when implementing pathfinding, while the diamond data is essentially the same as a regular grid system and requires no extra code to work with.

I hope you enjoyed this article/tutorial thing, in the next update I’ll go into detail about overcoming these pathfinding issues and talk about the A* algorithm. See you then!

When you’re writing the software framework for your game, one of the first things you need to do is establish the game loop. Naturally, when I started learning about Android development this was also one of the first things I looked into. For a few months I used the basic design outlined in the Lunar Lander Example that came with the Android SDK, and on the surface it appeared to work fine. It turns out that implementation of the game loop has a bug where anytime the game screen’s activity is exited and restarted, the game crashes as it fails to compensate for the activity life cycle. Essentially this means anytime you get a phone call, navigate to a different app, pause the game, or open up a menu within the game, restarting the game’s activity would result in a crash.

If you are unfamiliar with the android activity life cycle, or activities in general, these resources will give you a deeper understanding onto whats going on here, but if all you need is a refresher, lets take a look at a handy infographic on what happens during the life cycle:

 

We can see from the flowchart that in the majority of instances where onStop is called, the activity actually is is killed and is wiped from memory. This happens whenever you get a phone call, or if you exit the app with the back button, all things that you can expect to happen a lot when someone is playing your game. The problem with the game loop outlined in the Lunar Lander example is that it creates a game loop separate from the Activity, and thus is not killed when the activity is. This causes issues when the user navigates back to the activity that initiated the game loop, because it tries to start a thread that is already running.

A very common solution is to encapsulate the entire thread in a while loop that is dependent on a boolean variable. When onStop and onStart are called you can simply set the variable to true and allow the thread to “start” and “stop” without accidentally re initializing it. This code would essentially look like this:

while(running)
{
    startTime = System.nanoTime();
    canvas = null;

    //try locking the canvas for pixel editing
    try
    {
        canvas = this.surfaceHolder.lockCanvas();
        synchronized (surfaceHolder)
        {
            this.level.update();
            this.level.doDraw(canvas);
        }
    } catch(Exception e) {}
    finally
    {
        if(canvas != null)
        {
            try
            {
                surfaceHolder.unlockCanvasAndPost(canvas);
            } catch(Exception e) {e.printStackTrace();}
        }
    }

    timeMillis = (System.nanoTime() - startTime) / 1000000;
    waitTime = targetTime-timeMillis;

    try
    {
        this.sleep(waitTime);
    } catch(Exception e) {}

    totalTime += System.nanoTime()-startTime;
    frameCount++;
    if(frameCount == FPS)
    {
        averageFPS = 1000 / ((totalTime/frameCount) / 1000000);
        frameCount = 0;
        totalTime = 0;
    }
}

That critical running variable would be set to false in the onStop method of the parent activity, and to true in the onStart method. However because the game thread we create is running separate from the UI thread that activities run on, it might take a few tries to stop it so that code would look like:

public void stop()
{
    boolean retry = true;
    while(retry)
    {
        try
        {
            thread.setRunning(false);
            thread.join();
        } catch(InterruptedException e) {e.printStackTrace();}
        retry = false;
    }
}

This solution is pretty easy and quick to implement, but it suffers from one flaw depending on the implementation. That is persistence. When I used this method I found that every time I exited and restarted the activity, the game loop was wiped clean. This meant every time I exited and reentered the game all progress in that specific level would be lost, sending the player back to square one. Obviously that’s not ideal. This issue centered around the above solution stopping the game loop from running at all, so when it would be restarted it would not have saved any of the variables it was previously manipulating.

An alternative solution that I implemented in tandem with the one above is using Synchronized Pause Locks to halt the thread from running within the update of a single frame.  This is where a generic Java Object is created and halts a loop mid update  while it awaits a resume command. Very similar to the above example, with the main difference being the usage of an object instead of just a boolean, and the ability for the loop to save its state while being paused. This code would be added to the bottom of you while(running) loop from the above block of code.

synchronized (mPauseLock)
{
    while (mPaused)
    {
        try
        {
            mPauseLock.wait();
        } catch(InterruptedException e) {}
    }
}

mPauseLock is just a regular object and mPaused is a regular boolean declared like:

mPauseLock = new Object();

mPaused = false;

The only tricky part here is that synchronized tag. It essentially allows the object to be interacted with in 2 different threads, in this case the Activity’s UI thread and the Game Loop thread. This also circumvents the issue described earlier about how we had to try multiple times to stop the game loop thread using just a boolean from the UI thread. The way we lock and unlock this object is using synchronized functions and the notifyAll method. They would look like this:

public synchronized void onPause()
{
    synchronized (mPauseLock)
    {
        mPaused = true;
    }
}

public synchronized void onResume()
{
    synchronized (mPauseLock)
    {
        mPaused = false;
        mPauseLock.notifyAll();
    }
}

This allows us to communicate with the game thread from outside of it. The notifyAll method wakes up the game loop thread now that mPauseLock is no longer telling it to wait.

In my current game loop implementation I use this synchronized code block to put the thread to sleep and wake it up whenever the user navigates away from the thread, and I use the first implementation of setting runnable to false and clearing the game loop data when the user quits the application, when onDestroy is called.

I hope you found this more technical article useful, I’ll see you in the next update!