Tag Archives: iDevBlogADay

There’s More To Video Games Than Just Playing Them

Teaching Kids How To Make Video GamesLast week we did something very different – we went back to high school! Cathy and I spoke at James Cardinal McGuigan Catholic Secondary School in Toronto to nearly 200 kids over 4 class periods about how we make video games.

Part of our mission here at Rocket 5 is that we want to teach kids and parents that there’s more to video games than just playing them and that kids might want to consider a future in the industry that provides them with so much fun and entertainment. There are tons of different job skills that are needed to make video games in areas ranging from the very creative to the very technical, so you might be surprised to learn that some things you’re already interested in might help you get a job working in the games industry someday.

Teaching Kids How To Make Video Games

To give you some idea of the skills involved in making games, here’s a partial list of the jobs found in a typical medium to large sized game studio. When you work in a very small studio like Rocket 5 or if you’re making games by yourself or with a couple of friends, you’ll need to learn how to do many of these skills yourself, which is totally possible given all of the free resources available online these days.

  • Game Designer: Develops the game concept, defines everything that will happen in the game and communicates those ideas to the rest of the team.
  • Level Designer: Builds the environments (buildings, tracks, terrain) that the characters will interact with and scripts the game’s encounters and challenges.
  • Writer: Writes the game’s story and dialogue.
  • Programmer: Writes the code that handles everything from rendering the game to the screen to player movement to gameplay systems.
  • 3D Artist: Uses 3D modeling software to create characters, level art and props.
  • 2D Artist: Uses 2D image editing software to create character and world concepts, paint textures for 3D models and more.
  • Lighting Artist: Places lights in the game’s levels to create atmosphere.
  • Visual FX Artist: Creates everything from sword trails to sparks to fire.
  • Animator: Brings the characters to life through movement.
  • Technical Artist: Bridges the gap between art and code.
  • Producer: Coordinates the development of the game.
  • Sound Designer: Creates all of the sound effects that you hear in a game.
  • Composer (music): Writes and records the music for the game.
  • Voice Actor: Acts out the game’s dialogue lines so they can be recorded and played back in the game, similar to a TV or movie actor.
  • Tester: Test the game for “bugs”, reports problems to the developers.
  • Marketing & Sales: Brings the product to the attention of the public.
  • Accounting, Finance and Executives: No game studio could survive without the skills that these people provide.

Teaching Kids How To Make Video Games

Getting back to the presentation – the last thing we wanted to do while talking to a room full of teenagers, was to bore them to death with an hour long powerpoint presentation (although we did start with a short powerpoint to introduce who we are). So I thought a good way to teach them about how to make video games was to show them how a game is made and then let them play it. On the Saturday before the event, I prepared for our presentation by making a 4-player cooperative “Capture the Flag” style game. I then broke the game down into basic components so that I could re-make the game “from scratch” in front of them in about 20 minutes. While I remade the game, I talked about the various skills involved – starting with the initial idea, writing/brainstorming the idea into a design document, and then I got to work on the gameplay prototype. At the end, the kids got to play the final game.

[gn_media url=”http://vimeo.com/43750939″ width=”100%” height=”400″]

We also gave the kids a handout with information and links to lots of freely available resources to help them get started making their own games. If you know of any additional resources (especially if they’re free), please let me know and I’ll add them to the list.

Toronto Game Dev Community:

Hand Eye Society: The Hand Eye Society is a not-for-profit coalition of projects and people in support of Toronto’s videogame communities.

International Game Developers Association: The mission of the IGDA is to advance the careers and enhance the lives of game developers by connecting members with their peers, promoting professional development, and advocating on issues that affect the developer community.

Gamercamp: Toronto’s festival celebrating the artistry, innovation and power of play.

TOJam (Toronto Game Jam):  A great local game incubator where for 3 days once a year, hundreds of people gather together to make games over a 3 day weekend.

Academy Of The Impossible: Teaching each other that our dreams can come true, and how to achieve them, through innovative artistic, technological, social and literacy programs.

Game Development Tools:

Scratch: Scratch is a free programming language that makes it easy to create your own interactive stories, animations, games, music, and art — and share your creations on the web.

Stencyl: Free tool for making iOS and Flash games (free to use, subscription required to publish games). The programming interface is similar the one used in Scratch making it easy for game designers of all ages.

Unity: Free tool for making Web and Desktop games. Unity is a feature rich, fully integrated development engine for the creation of interactive 3D content.

Corona SDK: Free tool for making iOS and Android games (free to use, subscription required to publish games).

Adventure Game Studio: Provides the tools to make your own adventure games, for free!

3D Modeling Tools:

Blender: Blender is the free open source 3D content creation suite.

Maya: The industry standard 3D modeling and animation program (free education edition available).

2D Tools:

Inkscape: Free open source SVG graphics editor that’s similar to Illustrator.

Gimp: Free image authoring, photo retouching and composition software that’s similar to Photoshop.

Online Tutorials:

Digital Tutors: Software educational site ($400/year).

Lynda.com: Software educational site ($375/year).

Audio Tools:

Audacity: Free open source software for editing sounds

SFXR: Free tool for generating 8-bit sound fx.


Sissy’s Magical Ponycorn Adventure: A game made by a 5 year old girl and her dad!

Gamasutra: News about game development.

Game Glossary: A reference of the language of games.

I mentioned before that I made the game we used in the presentation on the weekend before the event. Since I knew that I would be making the game in a short amount of time, “game jam” style, I thought it would be fun to take a time-lapse video of the development to help give people an idea of just what goes into making a game like this. I used a Terminal script to automatically capture a screenshot every 5 seconds during the (roughly) 10 hours that it took to make the game and then used QuickTime Pro to compile and export the 4,896 frame image sequence.

[gn_media url=”http://vimeo.com/43737244″ width=”100%” height=”400″]


In the end I think the kids were really excited to hear what we had to say, we fielded lots of questions and they really liked getting to play the game we made for them!

If you’re in the Toronto area and you would like us to speak at your school or event, feel free to contact us at rocket5[at]rocket5studios.com or through our Facebook page.

This blog post is part of iDevBlogADay, a collection of indie developers writing about their development experiences.

About the author

Tim MillerTim Miller is a veteran game developer with over 15 years experience in the video game industry working as a Level Designer and Lead Level Designer at LucasArts, Secret Level and Nihilistic Software. He co-founded Rocket 5 Studios with his wife Cathy and their dog Rocket in 2009. Twitter, LinkedIn, Portfolio

Make A 2D Game With Unity3D Using Only Free Tools: Beginning Enemy AI With A* Pathfinding

Make a 2d game in unity3d part 5In This installment of our 2D tutorial series, we will be adding enemy AI to our Lode Runner clone using A* Pathfinding. This post has been guest written by Adrian Seeto of Fun Mob Games who was also kind enough to write the AI scripts that are a huge part of bringing the game to life.

Adding the enemy AI required changes to many of the scripts that we added in the previous tutorials. You can download the complete project here which has been rebuilt to support the new prefab system in Unity 3.5x. If you’re using an older version of Unity (pre 3.5), then you should download this version. You can also follow the steps below to update your existing project. I recommend following along with the tutorial as there’s tons of great information on implementing the AI with A*. You can also play the game as it will be at the end of this tutorial here.

Installing the A* Package

  1. Import the free version of Aron Granberg’s A* Pathfinding Project into Unity3d
  2. Create an empty GameObject and rename it A*. Make sure it’s positioned at 0,0,0
  3. Drag the /AstarPathfindingProject/Core/AstarPath.cs file onto the A* GameObject
  4. Click on the A* GameObject and disable the “Allow Javascript” option

Importing game C# scripts

Many of the scripts have been modified since Part 4 of this series, so you’ll need to update them. If you’ve made changes to your own scripts then you’ll need to merge your changes into these new scripts.

  1. Copy these scripts into your Assets/Scripts/ folder:
    1. Player.cs (updated)
    2. PlayerAnims.cs (updated)
    3. xa.cs (updated)
    4. ChangeBehaviorGUI.cs (new)
    5. Character.cs (new)
    6. Enemy.cs (new)
  2. Copy this script into your AstarPathfindingProject/Editor/GraphEditors folder:
    1. MyGridGeneratorEditor.cs
  3. And finally copy this script into your AstarPathfindingProject/Generators folder:
    1. MyGridGraph.cs

Configure The xa.cs Script

Create a new Layer by going to Edit –> Project Settings –> Tags and then enter “Enemy” in one of the empty User Layer slots.

  1. Select the Global/Scripts/xa GameObject
  2. Set Ground Mask field to “Ground
  3. Set Ladder and Rope Mask field to “NoDraw
  4. Set Enemy Mask field to “Enemy

Miscellaneous Project Changes

Note that some of these may be unnecessary or redundant depending on how your project is currently setup.

  1. Expand the Global game object in the Hierarchy and then select the “border bottom” and “border top” GameObjects and set their layer to Ground.  This is so enemies can stand on it if/when we dig a trap above the bottom border and our enemies fall into it they won’t fall continue through the border into the great abyss.
  2. Select the player object in the Hierarchy and then change its Tag to “Player
  3. Select the OT/View object in the Hierarchy and uncheck “Always Pixel Perfect“. Note I’m not sure why Adrian turns off pixel perfect, feel free experiment on your own.

Configure A* Pathfinding For Our Level

A* is a graph traversal algorithm widely used in computer science, and commonly used in games for path finding.  A full discussion of A* is beyond the scope of this tutorial, but there is some terminology you should be aware of.  A graph consists of nodes and the network of connections between them.  Once A* has been provided with a graph, you can query it to find the shortest path from one node to another.  A* will return a path way list of all the nodes that you must travel along to get from your start node to your end node, in the shortest path possible.  

More accurately, the path returned is the “least cost” path, because nodes have a specified penalty cost for traveling along it.  A* will attempt to create a path which incurs the least cost.  The unit of a penalty is up to the application developer.  For example, in an isometric RTS game the terrain tiles would be nodes, with 8 connections per node (except for the boundary tiles).  We could have the penalty cost units be related to the time it takes to travel on it.   A swampy area might therefore have very high penalties on the nodes in it, while the grass land nodes surrounding the swamp have smaller penalties.  A computer-controlled tank which wants to get from one side of the swamp to the other may then plot a course around the swamp if it costs less, even though it is physically further (i.e. more tiles must be travelled, but the total travel duration is less) . Of course, it is up to us as the game developer to implement all the code to actually slow the tank down if/when it travels over swamps, A* is only the pathfinder.

We don’t make use of penalties in this game because traveling along ropes, ladders, the ground, and falling is all done at the same speed.  If gravity in our game was a useful non-lethal force (i.e. falling is faster than climbing and just as safe) then we can set node penalties so that A* would return a path where jumping off a platform would be a preferable shortcut to climbing down the ladder. If your game enforces lethal falls from great heights, then you would need additional logic.

A game could have multiple graphs, for use by the various units (ships have different travel behavior to an infantry man for example).  For this tutorial, we only need to create one graph.  In the graph one node will be created for every tile in a 2d grid-like layout.  Each node may have up to 4 connections (up, down, left, right).  Aron’s A* Project includes several different path graph generators, such as GridGraph, ListGraph, and NavMeshGraph.  The GridGraph is a suitable starting point for our game.

The node connections generated by the base GridGraph are always bidirectional (if it creates a connection from from node1 to node2 then it will also create a connection from node2 to node1) which is not necessarily what we want.  Bidirectional paths are fine for ladders, ropes, and the ground because you can go up and down a ladder, and both left-to-right and right-to-left on rope and ground.  The problem arises when you want to include fall lanes. A fall lane is a term I’ve made up for a vertical one-way path that you can only travel on by falling.  Fall lanes exist under the ropes (you can let go of a rope and fall) and off of cliff edges (you can run off a cliff and fall down to a lower platform).  Once on a fall-lane you can’t travel in any direction but down until you’ve hit bottom.  This is a uni-directional connection so the nodes on a fall lane only have one connection each: a connection to the node directly below it.  Other nodes in the level will have between 2 and 4 connections each.  

We could use the base GridGraph and not bother about having any fall lanes, it would just mean that our AI would not plan any paths that involve letting go of ropes or running off platforms.  In this scenario you could still have your AI let go of ropes in a “reactionary” manner i.e. if it’s already on the rope and see a player below it, it could let go.  You would do this will “special case” code in your enemy AI loop.  However, its important to understand this is different from forward planning a route which takes into account the ability to jump off ropes.  In order to that kind of path planning with A*, you need to provide that information in the graph, via the fall lane concept.  

I’ve created a new generator class called “MyGridGraph” which inherits from GridGraph and overrides the Scan() and IsValidConnection() functions.  Our new MyGridGraph class implements the fall lanes idea so let’s add it the scene.

  1. Select the A* GameObject
  2. Click the Graphs -> Add Graph button
    1. Add a new “My Grid Graph
    2. Width: 26 (these dimensions match our level)
    3. Depth: 20
    4. Node Size: 1
    5. Aspect Ratio: 1
    6. Center: 0, 0.3, 0.01 (y is 0.3 so that our nodes are centered in the middle of each tile (which we already previously aligned at 0.3), the z is 0.01 because the integer coordinates used for Aron’s A* node positions have a fixed precision of 0.01 and anything smaller than that would cause troubles.)
    7. Rotation: -90, 0, 0 (rotate x because our grid is for a side-on view rather than the expected top-down view)
    8. Disable Cut Corners checkbox
    9. Connections: Six (we only need 4 connections per node up/down/left/right, but we don’t have that option)
    10. Disable Collision testing checkbox
    11. Disable Height testing checkbox
    12. Level Layers: Ground and NoDraw
    13. Scroll to the bottom and enable the Show Graphs checkbox then hit Scan

If it worked right you should now see the A* graph layout in your game/scene window (enable Gizmos) similar to the following image (click to see a larger version).

2dGamePt5 pathfinding

The red squares represent nodes that the AI can not travel on.  All the bricks should have a red node centered on them.  Much of the black “air” tiles should also have a red square gizmo.  The tiles without the red gizmos are the nodes the AI can travel on.  The blue line represents the connections between nodes. You should therefore see that the AI can travel along the surface of ground tiles, along ropes, and up and down ladders.  You should also see the vertical fall lanes under ropes and over the edge of a platform.  If you are very perceptive you will see that the blue lines come in 2 thicknesses.  A thick line means that the connection is bidirectional (the line gizmo was rendered twice, once each way, making it thicker).  A thin line represents a unidirectional connection.

Making Enemies

Our enemies and the player classes both derive from the Character class which implements the movement code.  In this way we can ensure that the enemies and player move with the same constraints to help prevent giving either an unfair advantage, and just general time-saving and efficiency.  The character class does have a movement speed variable, so we can give the enemies different movement speeds than the player, if desired.

Below we create 2 enemy game objects.  I’ve just reused the player sprite for them, and I’ve given each one a different tint so I can tell them apart (helpful during the development stage). If you create your own different enemy sprite go ahead and use it.

  1. Create an empty GameObject called Enemies to use as an organizational holder.
  2. Clone the player GameObject in the hierarchy and rename it to enemy-1.
  3. Drag the enemy-1 to child it under your Enemies GameObject.
  4. Drag the /AstarPathfindingProject/Core/Seeker.cs script onto your enemy-1.  The script’s defaults are fine.  Go ahead and break enemy-1’s connection to the player prefab when prompted.  The Seeker provides the enemy with the ability to use A* path finding.  It has gizmos which paint green lines representing the found path.
  5. Expand the enemy-1 GameObject to see it’s children.
  6. Delete the “shoot parent” child.
  7. Add an empty GameObject child under enemy-1 named “path target”.  Local Position 0,0,0 Local Scale 1,1,1. This will be a transform that the enemy script will move around to place on the desired target for our path finding AI.  Useful during debugging to see what it is targeting.
  8. Duplicate “path target” and rename to “tile bounds”.  Add a box collider to it, set to Trigger and centered at 0,0,1 and scale 1,1,1.  This is so that when we trap an enemy we can walk smoothly on top of it’s head as if it was ground.
  9. Select the enemy-1 game object and set its Layer to Enemy and apply to children.  Set its Tag to Enemy (leave children untagged).
  10. Expand the enemy-1 Player script component.  Drag the /Scripts/Enemy.cs script onto the Player Script field to replace it with the Enemy script.
  11. The Enemy script has 3 slots that need to be filled: Player and Player Tr (drag the player gameobject to those slots), and Target (drag the path target gameobject to this slot).
  12. Expand the enemy-1 OTAnimatingSprite script.  Set the Material Reference slot to “tint”.  Set the Tint Color to red (or your preference) to visually differentiate it from the player.
  13. Clone enemy-1 as enemy-2 and give it a green tint. (You may have to redo the Red tint on the other enemy due to an OT quirk).
  14. Drag the enemies to suitable spawn points in the scene.
  15. Optional: Select the Enemies root GameObject.  Drag the ChangeBehaviors.cs script onto it.  Set the Enemies array size to 2, and drag enemy-1 and enemy-2 into the slots.  This script will allow you to modify an enemy’s behavior on-the-fly via GUI between a “plain A* to Player” and a “Lode Runner-esque” behavior.  The A* to Player behavior simply follows the shortest path toward the player’s exact position.  The Lode Runner-esque behavior still uses A* but also tries to reimplement some of the reactionary quirks of the original game, especially with regards to ladder use.  See the Enemy.cs file for details.  You can disable/remove the ChangeBehaviors.cs script when you are done testing it out.


While the enemy AI is not a completely faithful recreation of the original, it is hoped that it will provide you with enough of an idea on how you can use and implement A* path finding in your own creations.

If you have any questions about the tutorial, please let us know in the comments below. Your support helps to keep these tutorial coming so be sure to follow us on Twitter and Facebook. This blog post is part of iDevBlogADay, a collection of indie developers writing about their development experiences.

More Tutorials In This Series

Make A 2D Game in Unity3D Using Only Free Tools Part 1
Make A 2D Game in Unity3D Using Only Free Tools Part 2
Make A 2D Game With Unity3D Using Only Free Tools Part 3
Make A 2D Game With Unity3D Using Only Free Tools Part 4
Make A 2D Game With Unity3D Using Only Free Tools: Beginning Enemy AI With A* Pathfinding

And here’s another tutorial series that uses Sprite Manager 2 for the sprite display and animation duties:
Creating 2D Games with Unity3D Part 1
Creating 2D Games with Unity3D Part 2
Creating 2D Games with Unity3D Part 3
Creating 2D Games with Unity3D Part 5

Show Your Support

If you find these tutorials useful, please considering buying one or more of our games and apps for iPhone and iPad. Your support helps to keep the tutorials flowing!

  • Giant Moto: High flying arcade style motocross action!
  • Small Space: Fly a spaceship, eat space creatures, score point!
  • Holeshot Drag Racing: High speed drag racing action!
  • Alien Booth: Transform pictures of your friends into awesome aliens!
  • iSpoof Walken: A hilarious look into the world of Christopher Walken!
  • Gaga Eyes: Transform pictures of your friends to give them huge anime eyes!

About the author

The AI scripts and this tutorial were contributed by Adrian Seeto of Fun Mob Games, creators of Pocket BMX game for iOS, a free-roaming 2D bike tricking game with physics.  You can check them out at FunMobGames.com or on twitter @FunMobGames.

Christmas Carnage, Game Jam Style!

This past weekend we took part in the 10th installment of the Game Prototype Challenge, a monthly game jam billed as “a spur of the moment motivator for making games”. Not that we need any motivation since we’re always working on games here. But what we like about jams is that they get us to think about games differently since they usually involve including some kind of theme (“dreams” and “collectibles” for this jam) and they always have a very short deadline which gets us to try new things quickly without worrying about making the code necessarily clean or efficient.

Rocket 5 participated in GPC v.2 earlier this year with our game Snowball Jones And The Last Crusade, which I co-developed with Kevin Feraday.

This time around our Art Director (AKA my wife Cathy) and I took a stab at the challenge with a holiday themed, tongue-in-cheek spoof of the wildly popular game Angry Birds.  In our game, titled A Very Angry Christmas, you control the hero from our upcoming game XS Force as he steps up to defend our hungry friends the pigs from those incessant birds.  For us the game actually serves two purposes:  for the Prototype Challenge, and as an interactive holiday card that we’ll send around to all our friends and business partners.

A Very Angry Christmas

This was Cathy’s first time participating in a game jam and this was my third time.  We used Unity3D to make the game and we used pre-existing gameplay code from XS Force for the player controls.  We revised the input from touch screen to keyboard and mouse so that the game could be played in a web browser (and it works great on the iPhone too, using our existing touch controls).  I also relied on several excellent Unity plugins including:  iTween for various text and effect animations, 2D Toolkit for the animated sprites and RageSpline for the level background, which, next to iTween, is easily the best Unity plugin I’ve ever used.  Cathy did all of the character art and animations in Flash which were exported as .png’s and then added as sprites to Unity using 2D Toolkit.

If you happen to live in the Toronto area, you can play our games at the #GPC Arcade: Year-One Roundup presented by the Toronto Skillswap community at George Brown College on Friday December 16th. And if you’re not going to be there, you can play A Very Angry Christmas right here on our website!

Thanks for stopping by and please let us know in the comments if you have any thoughts on the game, and especially if you find any bugs :). This blog post is part of iDevBlogADay, a collection of indie developers writing about their development experiences.

Make A 2D Game With Unity3D Using Only Free Tools Part 4

Make A 2D Game In Unity3d Part 4This is part 4 of our tutorial series on making a 2D game in Unity3D with freely available tools and plugins. Part 1 introduced you to the tools we’re using, in Part 2 we built our first level and in Part 3 we hooked up the control scripts and setup the ladders and ropes so that the player can navigate levels. In this article we’re going to create a pickup item, hook up the scoring system and add the interface text which reports score, lives and level.

Hopefully you already went through part 2 and part 3 of the series, if you haven’t already you might want to go back and do them now so everything in this part will make sense.

If you’d rather skip ahead, you can download the project up to this point. You can also click here to play the game as it will be at the end of Part 4.

Adding The Scoring and Pickup Scripts

The game is working great so far – the player can move, climb ladders and shimmy across ropes. Now we’re going to add a “gold chest” pickup item and an interface to track scoring, player lives and the current level.

  • Download scoring and pickup scripts and unzip the file somewhere on your hard drive.
  • Copy Scoring.cs and Pickup.cs from the extracted .zip file and paste them into your project’s Assets/Scripts folder.

Modifications To Existing Scripts:

You’re going to need to make a few changes to the scripts from part 3 so that these new scripts will work.

  • Open xa.cs script and then uncomment the first line in the Class:
public static Scoring sc;
  • In the Start function, uncomment this line:
sc = (Scoring)(this.gameObject.GetComponent("Scoring"));
  • Open Player.cs, find the OnTriggerEnter function (line 256) and then uncomment the following code block:
if (other.gameObject.CompareTag("Pickup"))
	if (other.GetComponent<Pickup>())

Making The Pickup Sprite

You might remember from part 2, that you already added the pickup.png to the level sprite atlas and then created a level container object that points to the sprite atlas so we don’t need to do any additional Container setup to create the pickup.

  • Drag & drop the Sprite object from Orthello –> Objects –> Sprites into the Hierarchy or Scene which will create a new object named something like “Sprite (id=-3700)“. Rename that object to “pickup“.
  • Drag the level object that we created in part 2 from OT –> Containers and drop it on to the Sprite Container slot in the Inspector.

Your sprite will appear but it looks like the brick sprite that we made before, that’s because the brick is the first texture on the Sprite Atlases index.

  • Click and hold your mouse over the word “Frame Index” in the inspector (with the pickup object selected) and then drag the mouse to the right to scroll through the textures on the sprite atlas. The pickup texture is at index 16 so set it to that. The sprite should now look like a a white rectangle with a red box in the center and a black background.

Adjusting The Collision:

The sprite is a square, but we only want the object to be picked up only when the player touches the white part of the pickup.

  • Check the Collidable checkbox to add collision to the object.
  • Open up the drop down list next to Physics and then select Custom.
  • Under Box Collider, set the Center Y to -0.15, Size X to 0.8 and Size Y to 0.5. Leave Size Z set to 0.4.

Setting The Tag:

We need to tag the pickup so that the player will trigger it when touched.

  • Create a new tag by going to Edit –> Project Settings –> Tags
  • Add a new Tag in the Tags list (probably in Element 3 if you’ve been following the series) named “Pickup” (without the quotes). It’s important that the name is correct since Player.cs looks for this exact name.
  • Select the pickup object in the Hierarchy, then click on the drop down list next to Tags at the top of the Inspector and then select Pickup.

Add The Script and Make It A Prefab

Now we just need to add the Pickup.cs script to the sprite so that it will get “picked up” when the player touches it and we also need to turn it into a prefab so that it’s easy to place in all your levels.

  • Drag the Pickup.cs script from the Project Scripts folder and drop it on to the pickup sprite in the Hierarchy.
  • Drag the pickup object from the Hierarchy into the Prefabs folder in the Project tab to create prefab from the object.

The pickup is designed so that you can snap the bottom edge (the black part) of the sprite to the top edge of a brick sprite the white part of the powerup will be the correct height from the top of the brick. Duplicate your new pickup prefab a few times and place it around you level.

If you followed all of the steps so far, your pickup should look like this:
2dGamePt4 pickup

Add The Interface Text

At this point if you place the pickup in your level so that the player can pick it up, the sprite will disappear correctly as if he picked it up, but you’ll get some errors in the console because the Scoring script isn’t in the scene yet and we don’t have any UI to report the score. So let’s fix that.

  • First add the Scoring.cs script to the scene: Drag Scoring.cs from your Project’s Scripts folder and drop it on to the Scripts object in the Hierarchy. If you select the Scripts object, you’ll see that the Scoring script has a bunch of slots for text objects that we need to add – but first we need to create the text objects.
  • Download the G7 Silkworm font and unzip the file somewhere on your computer. This font isn’t exactly the same as the one used in the original Lode Runner game, but it’s pretty close. If there’s another font you’d rather use, go for it. And if you find a font that’s closer to the Lode Runner font, please let me know in the comments.
  • Create a new folder in your Assets folder named Fonts, locate the silkworm.TTF font on your hard drive and then copy it into the Assets/Fonts folder.
  • In Unity, select the silkworm font in your Project’s Fonts folder and then in the Inspector set the Font Size to 26.

Adding The Score Text:

  • Drag the silkworm font from the Fonts folder in the Project panel and drop it into the Hierarchy. This will automatically create a new GUI Text object in the Hierarchy using the silkworm font.
  • Rename the object to “Score Label
  • In the Text field under GUIText in the Inspector, type “SCORE” in all caps without the quotes. The Silkworm font only has uppercase letters so don’t try to use lowercase letters.
  • When you add a font to the scene, the X and Y position are automatically set to X 0.5 and Y 0.5, but we’re going to set the position of our fonts using the Pixel Offset so reset the X and Y Position to 0.
  • Change Pixel Offset X to 16 and Pixel Offset Y to 592. This should position the SCORE text to the upper left hand corner of the Game view (note you won’t see the text in the Scene view so look at the Game view to help position the text).

We also want to keep the scene nicely organized and make it a little easier to hook up the interface objects to the Scoring script later on. You’re going to make the Score Label object a child of the Scripts object and then you’ll duplicate each of the other text objects from this one in order to save a few of the setup steps.

  • Select the Score Label object in the Hierarchy and then drag and drop it onto the Scripts object in the Hierarchy so that it becomes a child of the Scripts object.
  • Expand the little arrow next to the Scripts object, select Score Label object and then duplicate it.
  • Rename the new text object to “Score Value“.
  • Change the Text to 0000000 (7 zeroes).
  • Change the Pixel Offset X to 150 and leave the Y set to 592.

Adding The Lives Text:

  • Select either the Score Label or the Score Value text object and duplicate it.
  • Rename the new text object to “Lives Label
  • Change the Text to LIVES.
  • Change the Pixel Offset X to 348 and leave Y set to 592.
  • Duplicate Lives Label object and rename it to “Lives Value“.
  • Change the Text to 000 (3 zeroes).
  • Change the Pixel Offset X to 480 and leave Y set to 592.

Adding The Level Text:

  • Select one of the other text objects you already created and duplicate it.
  • Rename the new text object to “Level Label
  • Change the Text to LEVEL.
  • Change the Pixel Offset X to 576 and leave Y set to 592.
  • Duplicate Level Label and rename the new object to “Level Value
  • Change the Text to 000 (3 zeroes).
  • Change the Pixel Offset X to 710 and leave Y set to 592.

Hooking Up The Scripts:

Now we need to connect the interface text objects to the Scoring script.

  • Select the Scripts object in the Hierarchy. Under the Scoring script in the Inspector, you’ll see slots for each of the GUIText objects we just created.
  • Select each of the text objects from the Hierarchy and drag and drop them into the corresponding slot on the Scoring script. For example, drag Level Label and drop it on to the Level Label Text field.

Once all of the text objects are connected to the Scoring script, press Play in Unity. You should see the SCORE, LIVES and LEVEL text turn to a red color that matches the border color and the number of lives should change to 005 and the level number should change to 001.

Now if you run the character over a pickup object in the game, the Score should increase by 250.

Make The Top Border

To help keep the interface text separate from the gameplay area, we’re going to add a thin border just under the interface text.

  • Create a new cube by going to Game Object –> Create Other –> Cube
  • Rename the object to “border top“.
  • Set the Transform Position X to 0, Y to 8.7 and Z to 1.
  • Set the Scale X to 26, Y to 0.2 and Z to 1.
  • Find the border material in the Materials folder and then drag and drop it on to the border top object. We created the border material in a previous article.

If you followed all of the steps above, then your Hierarchy and Inspector (with the Scripts object selected) should look the following:

2dGamePt4 Scoring Text

Creating The GLOBAL Prefab

Next we want to do some things to keep the scene nicely organized and also to make it easy to add the key components to any new levels that you create. We’re going to create a GLOBAL prefab that contains the Main Camera, the Scripts (which includes the interface text objects) and the top and bottom borders.

  • Create an empty game object by boing to Object –> Create Empty, zero out the transforms so that it’s at 0,0,0 on the X,Y,Z and then rename the object to “GLOBAL“.
  • Select the Main Camera in the Hierarchy and then drag and drop it onto the GLOBAL object so that the Main Camera becomes a child of GLOBAL.
  • Select the Scripts object in the Hierarchy and drag and drop it onto the GLOBAL object.
  • Select the border bottom and border top objects (make sure they’re not already a child of some other game object first) and drag and drop them onto the GLOBAL object.

That’s everything we need for the GLOBAL object, so now let’s turn it into a prefab that can be easily added to other levels and updated later if we need to make changes.