Here’s my entry to the 2nd Procedurally Generated Graphics Contest on the Kongregate forums. It’s also a preview of the next tutorial I’ll be doing!

Here we go: (Click to generate, press any key to save a screenshot)

I’m fairly pleased with the end result but had planned a LOT more. I’ve had to stop early to begin marking a mountain of work; I could quite happily work on this for a long while (and probably will do in months to come). My plan had 16 different ‘cities’ – as you can see, I’ve only managed 2 of them so far.

Hope you enjoy the results, I’ll see you in the tutorial!

Nice and simple this time around; we’re going to make a game like ‘Copter’. I’ve covered this in the video but I’ll mention it here too: Copying games can be a nice way to learn, just don’t make a habit of it. If you’re developing something for commercial purposes you’re not going to make any friends by ripping other people off. The people who made the original Copter can’t lay claim the genre, so feel free to do your own thing with it (as Halfbrick have done with ‘Jetpack Joyride’) but make sure it is unique enough to not be considered a clone.

With that out of the way, hop into the video to make something like this:

Video:

Source files:

• EndOfPart1
• EndOfPart2
• EndOfPart3

The video doesn’t cover everything from the sample game above, so there are plenty of extra bits for you to look in to. As a rough guide, the clouds are basically the same as the blocks (without collision) and the steam at the back of the chopper is very similar to the explosion pieces. I used the random hills project as a background and various other little techniques from the Point, Click, Win! tutorial series to do the rest.

Your turn! Show me what you’ve got

Ant

I’m away on holiday for a little longer but, don’t worry, I haven’t dropped off the planet and I am still open to tutorial suggestions for when I get back from my travels. I obviously haven’t been able to answer emails and/or YouTube comments recently (and that will continue for the rest of the week) but try again if you’re still stuck next week and I should be able to respond.

Happy Easter and Antiversary!

The end result can be a computer hog, so only click it if you’re not doing anything too important

Here are some pictures of various results:

And here’s the SWF:

After a lot of failed attempts to make this as a video, I’ve resigned myself to a written tutorial. I found I was waffling too much about pointless stuff – we can attempt to cut to the chase here.

So, here’s a little example of the sort of product you could use pathfinding for (if you fancy yourself as a Frankenstein-esque, life-giving, scientist type):

Live my pretties!

Before you continue, make sure you have read this page on A* pathfinding theory. The link suitably covers the logic we’ll be working to throughout this tutorial.

Click to download the tutorial source files

Explanation of grid files: (Click here to skip straight to ‘Using the grid files’)

The chances are, if you’re at a level suitable for attempting pathfinding, grids are fairly trivial to you – but I’ll explain it anyway!

Before starting any pathfinding, I created 2 classes that combine to make a basic grid: SimpleCell and SimpleGrid. Now, there are hundreds of ways to implement grids and to store the information about cells for use in pathfinding; this is just a quick one put together to provide a platform for the pathfinding. The SimpleCell stores information about its position in the grid and the f, g, h and parent values mentioned in the theory. You could write a pathfinding system that generates all this information each time the grid is used – but that requires making and deleting a lot of objects dynamically. This setup makes the grid and cells at the start, then simply reuses them in the pathfinding logic.

The whole SimpleCell class in one go; it’s a glorified collections of numbers, really. Public variables are used because the pathfinding will eventually need access to everything. This could be done with private variables and get/set functions if you like. The numbers are all integers to keep things simple; the pathfinding would be more accurate if floating point numbers were used but it’d be more expensive in terms of processing time. The f value isn’t stored, it’s simply calculated on request by adding g and h (theory page!). The constructor takes a cell value (in this tutorial, 0 means walkable and any other number is a wall), an x and a y position for the cell.

“Simples”.

The SimpleGrid has a bit more to it, so I’ll break it down into sections:

The class doesn’t extend anything, because it’s just a bunch of numbers and some functions to process them. However, Sprite has been imported so the class can draw itself to another object if required. There’s no reason for the grid, width or height to be edited from outside in this example; if you want a dynamic grid, you might reconsider this – or at least add some functionality to alter the value of cells.

The array is 1-dimensional (what, for a 2D grid?? Madness!) because it’s easier to draw out in code and, arguably, faster to process at runtime. I’ll explain this a bit more further down

The width and height properties will have get functions (explained in the random hills project), so they are led by an underscore. The cellSize represents the size, in pixels, of each cell and is public so that the characters can use it later on (again, this could have just been a get function).

The constructor takes 4 pieces of information:

1. A value for width – as mentioned above, this is the width, in cells, of the grid
2. A value for height – as above but for height!
3. A value for cellSize – this is the width and height of each cell of the grid in pixels
4. An array of cell values – not SimpleCells – a list of integers to determine which cells are passable

The first 2 lines of code in the body set the width and height of the grid based on the values passed in. If they look odd, it’s because they make use of the ternary or conditional operator – not something I’ve ever covered in a tutorial. It’s a shorthand version of an if/else statement… so:

Could actually be written as:

They mean the same thing. There’s no noticeable performance boost from using the short version (possibly the opposite) but given that this tutorial is quite advanced, it can’t hurt to add stuff like this in for some extra learning . Back to the constructor…

The cellSize, array and grid being set are nothing new – we’re just making sure they exist to prevent errors in future. The section developing the grid array, however, is new. Let’s take a closer look:

The while loop will run until the grid array’s length matches the grid’s area (width x height for the area of a rectangle). The if statement decides if there was enough information passed in to the constructor to populate this cell. If there was, we use the given information. If not, we generate a default (walkable in this case) cell.

The trickiest part of the constructor is figuring out the x and y positions of the cells when working with a 1-dimensional array. The image below has a comparison of 2 grids: one is stored in a 2D array (an array of arrays), the other is 1D:

The text to the right of the grid explains where the cells are located in the array(s). In our array (1D) we take the x value and add y*_width to find that particular cell. In our current predicament, we need to reverse engineer this sum to get the x and the y from the final index.

This image shows the formula rearranged to make x or y the subject. In our code, the index is grid.length (the next element to be added to the grid array), so we substitute it in. If the % symbol is foreign to you, it means Modulo and it gives the remainder of number 1 after dividing by number 2. I also changed the y formula a touch – removing the need to take x away from the index by dismissing anything after a decimal point (by converting to int).

Yikes… can you see why I was struggling to cram all of this into an hour long video yet?

An easy one, yey! This function simply returns the cell at the specified position, using the formula for index mentioned earlier. The if checks that x and y are in the grid’s range; if not, a new, impassable cell is returned.

Get functions for the width and height, not much to see here!

This function returns an array of cells adjacent to the specified cell, provided that cell actually belongs to the grid. The comments sum it up fairly well but I should point out that it makes use of the following function to decide whether diagonal cells are accessible from the current position. Remember, the getCell function from earlier will return an impassable cell if the supplied position was out of bounds; bear that in mind if you ever choose to change the way that function works.

The passable function determines if movement between the given cells is possible. It’s inaccurate for cells that are not actually touching but we don’t really need to worry about that given how it is used in this class. There’s some more use of the ternary operator to decide where the top left point of the check area is. Once the start point is determined, a square of cells finishing at the end point is checked for walkability. If any of the cells are walls, movement is deemed impossible, as below:

Note that in the right hand image, movement between the 2 cells is technically possible but the function is only there to determine direct movement, so it would return false in that case.

… and finally:

This optional function will draw your grid to a given Sprite-based object. For more information about drawing with code, check the Random Hills project.

Phew!

Using the grid files:

Make sure your SimpleCell.as and SimpleGrid.as files are in your working directory. You can make a default 10×10 grid by simply making a new instance of SimpleGrid:

The grid will have cells 10 pixels in size and they will all be walkable. You can see this by drawing the cell to any old Sprite/MovieClip object. The code below is thrown into the Actions box on the first keyframe of a new Flash file:

… and it produces the following:

That’s great and all… but let’s add some walls.

The SimpleGrid constructor accepts an array of numbers to generate walls – 0 for walkable and anything else means a wall. You could cram your array declaration into the SimpleGrid creation line but I’ll spread things out a little:

Gives us:

We have a wall! The SimpleGrid class is doing it’s job and populating the grid with empty cells where we haven’t provided any information.

Let’s step it up a notch and make a full grid:

… makes:

You get the idea! Now, adjust the values and array you pass into the SimpleGrid class to make a grid to your liking:

… and I’ll finish this section of the tutorial with:

Time for some pathfinding I suppose!

Explanation of pathfinding file: (Click here to skip straight to ‘Using the pathfinding files’)

I’ve tried to stay close to the theory page‘s logic – so, again, make sure you’ve read and understood it.

The start of the file is fairly standard:

No import necessary, although mine originally had Sprite and Event imported so I could make it generate over time and draw itself to the screen. Most of the variables used are also remnants of that system; you could generate most (all) of them at the time of use, rather than storing them all the time. The comments explain the variables appropriately, no need to hang around here any longer.

The constructor takes and stores a reference to the grid being used. This is actually another remnant of the generate-over-time version of the system and could just as easily be passed into the pathfinding function later on, if you prefer.

Just before the pathfinding begins, I’m going to explain the function that calculates a cell’s heuristic (h score):

I’ve gone for the Manhattan method mentioned in the theory page but also left in a slightly more accurate and costly version should you choose to swap. The Manhattan method works, funnily enough, like Manhattan… it’s not possible to navigate diagonally through blocks, so the distance is calculated by zig-zagging around cells. The result is the difference between the start and end x position, plus the difference between the start and end y position, all multiplied by 10. See below:

We multiply by 10 so that the distance is in the same format as the 10 or 14 used to generate the g scores in the theory. With that done, let’s look at generating the path:

Here’s the first snip of the real pathfinding code. This starts the process by taking start and end co-ordinates from the user (feel free to use 2 Points instead of 4 integers), creates the open and closed lists and checks that the start and end points are valid. You can change the logic if you want your pathfinding to target invalid cells – you might want a ‘near as possible’ type solution when the goal itself is invalid.

Nothing groundbreaking there, so let’s look at the real brains behind the system:

The cell found at the starting coordinates is stored as the current cell. As it is the first cell in the path, it has a g score of 0 (it’s 0 distance along the path). We calculate its h (heuristic) with the getH function mentioned earlier and set its parent to null to prevent infinite loops further down the line. Once all the appropriate values are set, we add the starting cell to the open list and start a recursive function to generate the path. If recursive is a new word to you, it means a function that calls itself. Clever use of recursive functions can cram seemingly large calculations into a tiny number of lines of code. Below is a fairly common example; it returns the cumulative total of all numbers up to, and including, a specified number:

Just before I explain the recurseToGoal function down, let’s finish off the getPath function:

After the recursive function has done its work, the cells in the grid will contain all the necessary information to generate the path. A new array named path is made and we work backwards from the current cell (which will be the target of the path if any path existed) until we hit the cell we started from.
The cells are added to the start of the path array (hence the use of unshift instead of push) and the current cell is swapped for its parent. If the current cell has the same x and y as the start of the path, we have completed the path and the while loop stops. The final unshift call puts the starting cell at the top of the path and we can finally return the list of cells to whatever requested the path in the first place!

I hope at least some of this is sticking

Ok, the recurseToGoal function:

Eek!, better break it down a little:

The function takes no additional information as it is all saved in the class variables. Following the logic of the theory site, we removed the current cell from the open list (there’s no reason for it not being in the open list but I put a check just in case). We then add it to the closed list.

If the current cell is the cell we are trying to reach, we end the pathfinding with a return command.

We make use of the getAdjacents function from the SimpleGrid class to get a list of cells to check. You’ll need to do this differently depending on your grid/nodes. Note: at this point you could shuffle the array to make the pathfinding a little more random; as it stands, the system will take the same route for a path every time that path is checked. That might not sound too bad (it’s not, really) but you might want your characters to go down and around a single piece of wall once in a while, rather than up and around every single time.

For each cell in the list of adjacents, we check to see if it is already in the closed list. If it isn’t, we set its h score with the getH function from earlier. If the cell being checked is already on the open list, we figure out what its g score would be if the current cell was its parent. To calculate the g score we’re using a very basic function called getDistance (explained further down) that returns either 10 or 14 depending on the distance from the current cell to the one being checked. If the new g score is smaller, we make the current cell the parent of the one being checked.

If the cell being checked is not already on the open list, we calculate its g score and set the current cell as its parent, before adding it to the open list.

When every adjacent cell has been checked, we go through the open list to pick the cell with the lowest f score (g and h combined) to act as our current cell next time this function is called. This is done with a standard for loop and there really isn’t much more to point out here.

If the open list was empty (our nextCell variable will still be null), it means there is no path between the 2 points. At this point we can find the cell in the closed list with the lowest h score to act as a replacement for the full path. This will give us the nearest cell ‘as the crow flies’ to the desired target.

If the open cell wasn’t empty, we will have a non-null nextCell variable to work with. We change the current cell variable to hold the nextCell and call the recurseToGoal function again. This repeats everything you’ve just read using a different cell and, by repeating it enough times, the goal is eventually either found or deemed inaccessible.

And that’s the hard part done! Let’s just have a quick look at the getDistance function:

It’s taken for granted that this function is working with touching cells, so the logic is fairly straight-forward. If the x values are equal or the y values are equal, the 2 cells share a wall. If not, the cells are diagonally spaced. A value of 10 is used in A* to make the numbers workable; 14 is a close replacement for the actual distance between 2 diagonal cells (using an integer makes for faster processing).

“Yeah, yeah, yeah Ant… just tell me how to use the thing…”

Using the SimpleAStar class:

Make sure you have the SimpleCell, SimpleGrid and SimpleAStar class files in your working directory. The key to everything, the point of the whole tutorial, is the getPath function inside the SimpleAStar class. Everything below is a means to give that function space to operate.

Draw an object to use as a character, I’ll stick with the dot from the project preview example:

The character can be entirely controlled on its timeline if you like but I’m going to stick to AS files for this one:

Let’s take a quick look at the class in smaller pieces, starting with the constructor:

The Dude takes in a reference to the grid he/she (Dudette?) is part of, a reference to the pathfinding system to use, a starting position and a speed. A blank array for the path is created and an event listener is added that will update the Dude every frame.

The loop function is where the pathfinding and the grid are actually put to use:

The logic, in a nutshell, is:

• If there is a path to follow
• Move towards the next node
• If the node is reached in this step
• Delete that node from the path
• If there wasn’t a path to follow
• Attempt to make a new (random) one

The path array starts empty, so the very first thing the loop function will do is attempt to generate a path. grid.cellSize is used to make sure all the measurements relate to the grid spacing. Bear in mind that the pathfinding itself just works with integer-based grid coordinates.

That’s about as simple as it gets! Now, if we throw a Dude into our grid from earlier:

Here’s the code for you copy/paste types:

We get:

That is as far as the sample files go. If you are interested in making a character move towards a click, follow along below.

Start by removing the else part of the main loop in the Dude class. We don’t want him/her to choose a random path when the end of the current path is reached.

Now we’ll add an event to the stage (not always a good idea, but it will give you an idea of the thought process) that listens for a click. To guarantee that the stage is available, we will only add the listener after the Dude has been added to the stage, which means updating the constructor too:

For the click listener to work, we need to make sure that MouseEvent is imported at the top of the class, or that the whole events folder is imported if you’re feeling particularly lazy:

… or…

For the purposes of this tutorial, I’m going to assume that your grid starts at 0,0 on the stage and there’s no funky scaling and/or other movement that would mean that the position of the mouse on the stage is different to its position in the grid. If your project is different, you’ll have to adjust the mouseX and mouseY values accordingly.

Using the getPath function in almost the same way as before, we simply swap the random location for the position of the mouse cursor:

And there we have it!

We finally got there! It’s time for my keyboard to take a well earned break. Feel free to discuss or ask any questions in the comments below and make sure you show me anything you make .

For the pros out there, there are plenty of ways you can improve/build on this system; even typing it out again made me cringe at some of the code. Why not try:

• Making it more universal, so it accepts any type of grid?
• Making the whole system 1 standalone class (generate the cells when the getPath is called?)
• Making it a static class so we don’t need to instance/reference it?
• anything else that you can think of

Any feedback is welcome – if you’re a regular I’d be interested in how you rate it against my videos (more text in future?!)

Finally, if you scrolled down hoping to make the little town at the top, sorry! I can’t give everything away at once! Let’s just say you’ll need to skew your grid Sprite and add some other graphical jiggery-pokery. I’d advise you to resist the urge to decompile it too, as the code inside it is horrendously rushed and ugly.

See you next time.
Ant

Here’s a quick look at what’s in store for you in the next project – A* pathfinding!

It’s slowed down a touch so you can see it ‘thinking’. Click on any passable (white) grid space to move to that space.

It’s a tricky subject – and one I hadn’t actually looked at in over 5 years – so all the theory is from an excellent and easily accessible source: http://www.policyalmanac.org/games/aStarTutorial.htm. Go swot up .

This is basic grid-based pathfinding; if it’s something that appeals to you, this is a decent start but it’s only a very small section of the bigger pathfinding picture. Even so, I’m still struggling to cram it all into the hour I allocate for videos at the moment; it should be with you within a week *fingers crossed*

Ant

Update: Couldn’t help pushing it a bit further:

Source files:

• File at the end of section 1
• File at the end of section 2
• Final .fla

Sample file:

I’m hoping that there are now enough of you watching these videos to make some healthy competition possible. Using the Randomly Generated Hills tutorial and resulting classes, I want you to make something impressive to share with other readers/viewers.

I’m aiming to make these little competitions every 2 months, so try to be finished by March. I’ll pick a few of my favourites (from different ability ranges) and post them on here. If you can’t make the March deadline, share it anyway!

Post links to your SWFs or videos on this thread and include a bit about:

• Your programming experience level
• Your influences
• Any other useful tutorial links that you used

Impress me!