Let’s Make: Legend of Zelda — Step 01: GameManager

For me, there is no the other series that inhabits the heart quite like Legend of Zelda. Not only was it the first video game I ever played (even before Super Mario Brothers!), but the series has managed to grow-up beside me, evolving in mechanics, story line, and even transmuting between several beautiful art styles along the way. All this without losing it’s essence of adventure and mystique along the way. Impressive, indeed.

So it’s small wonder that many, like myself, will want to recreate the original on our own in Unity. There’s so much the series has to offer that will be good practice for a programmer to redo on their own.

A note: Although I’ll try to make an effort to explain and/or create links to some topics, this series assumes an intermediate knowledge of programming and Unity. Someone following along should understand basics, like the Awake() and Start()functions, as well as variables. Feel free to ask questions though.

First off, it’s dangerous to go alone — So make a GameManager.

Usually, I begin any game with what I call Step 00: The Game Design Document — Game Design Documents are at once a high-level explanation of what a game seeks to accomplish, an art gallery/style guide, and should include at least handy one flow-chart to help define important game mechanics. Although the Game Design Document may seem “boring,” it’s vital in reminding yourself on what you’re doing, especially if you’re prone to dropping your hobby projects for a few weeks/months at a time.

Fortunately, this is a “Let’s Make” project, which already has it’s art and mechanics defined for us, and simply exists as great programming practice. Therefore, I’m going to begin with the GameManager, which will network all of my “persistent” elements together. So let’s begin with this critical question:

What data persists in a single LoZ session, no matter what level/scene the Player is on — And what does the game engine need to know at any time?

• The Player, of course, who exists at all times, even if we transition to a new level (dungeon).
• Player Data, to include how many Hearts (lives) the player has, what critical items they have, weapons the player has collected, and their Rupees (money). (Some of which I’ll be caching to Player Prefs, because this data has to be maintained between game sessions)
• Player Location, which the game engine needs to keep tabs on because the Players will have access to a map function.
• The GUI, because no matter where the Player is or what they’re doing, they’ll need access to the aforementioned Data above, much of which is stored on the infamous LoZ “Sub-Screen.”
• And Camera Utilities — Which deserves a mention unto itself, because the traditional 2D LoZ series has a few screen “effects,” to include that classic screen transition (which I love), and at least one “level” transition when the Player drops into the game for the first time.

Bam! I already have my first set of To-Do’s, just like that, which is very critical to someone like me who works a day-job. If I’m going to make progress on a hobby-project, I’ll need to break it down into easy to cross-off steps. I’ll make it my goal to complete at least one of these To-Dos in any given week, as life allows.

Just One More Note: Because this is Unity, and the sky is the limit, I’m going to give the original LoZ game a face-lift using artwork from A Link to the Past. Because I can ;)

Without further ado, let’s do some programming. Fortunately, starting the GameManager script is quite easy. Simply create the script, and establish it as a Singleton pattern.

After creating the script, and naming it GameManager, Unity will do you the favor of giving it a special Sprocket Icon, which will help make it more recognizable.

Since GameManagers are literally a collection of Global variables and functions, I’m going to write the first variable/property as static. Because I want every script in the game to be able to reference my GameManager at any time.

private static GameManager instance;

public static GameManager Instance {get {return instance;}

I prefer to define my GameManager as a private instance, and then access it via a Public property. Though I’ve seen many other devs variate their Singleton patterns.

To finalize the Singleton pattern, we have to tell Unity that there is only ever one GameManager at a time, and it’s whatever object this class is attached to at any given moment.

private void Awake()
 {
   if (instance)
   {   Destroy(this); }
   else 
   { 
     instance = this; 
      DontDestroyOnLoad(this);
   }
 }

W00T! Step 01 is done!

Next time — Step 02 — Literally, The First Steps. See you then.