Dungeon Ho!: Unity – Dev Blog #3

Welcome back, Unity fans!  Today, I’m going to show you how to use the Tilemap objects created last time… as well as the basic object/entity hierarchy that’ll finally get a player into the maze.

The cornerstone of all Unity objects is the GameObject, and we’re going to utilize this beast for all of our mobs (old-school speak for Mobile Objects), items, and of course, the player.  We need a base class script that we can attach to a GameObject so that Unity knows it’s one of our Entities… so, enter the Entity class;


The Entity is a MonoBehavior, because there’s some functionality in that class that we’ll need down the road… primarily the gameObject member variable.  At the very least, we need to be able to modify its position in the game world!  And speaking of that game world, let’s backtrack a bit since I did promise to show you how to generate a very simple test map to run around in.


As you can see, our TestDungeonGenerator inherits from our DungeonGenerator ScriptableObject, and I’ve added a CreateAssetMenu tag at the top of the file so that I can automatically create a new Asset of that type.  We’ll need to create one as a prefab so we can assign it to the DungeonGenerator variable from Dungeon.cs, swapping out the (currently) empty original DungeonGenerator.

This TestDungeonGenerator overrides the generateDungeon method of that class to create a simple 10×10 dungeon full of empty tiles, denoted by the tile constant TILE_EMPTY.  We then set all of the tiles on the border of the map to TILE_WALL, and set two of the empty tiles to our up and down stairs, respectively.  We also throw a single solid wall into the center of the dungeon to test collision and pathfinding, once we’ve got them in.

Now that we have somewhere for our player to go adventuring, let’s continue inspecting the object hierarchy.  We’ve got an Entity, which forms the basic building block of all of our in-game objects.  Item objects will inherit from Entity, once we are ready to equip our Mobs, and (you guessed it) the Mob class will inherit from Entity.  Currently, the only member variables Entities have are weight and flags, but we’ll be adding to that later on.  Note that the Entity class defines a Start() method, which Unity calls when the object is first created/activated (and, for our purposes, is basically the same thing).  The Start() method sets the name of the entity so that we can quickly identify it in the Unity scene tree.  All subclasses will override this method, as you’ll soon see.

Naturally, the Player class inherits from Mob, so here’s our inheritance tree;

Entity > Mob > Player

Next, it’s time to port over the master ObjectSpawner class from the original Dungeon Ho! codebase.  This factory class, as its name suggests, is responsible for spawning every kind of object the game could possibly need.  Right now, we need it to spawn us a player.  Eventually, we’ll need it to spawn a player from a specific set of characteristics, like character class and gender, but for now all of that will be set to temporary defaults.


The spawnPlayer method creates a new, blank GameObject and attaches a Player component to it, representing our Player.cs script (which, currently, merely sets the gameObject’s name to “Player” – similar to how the Entity class does).  It then attaches a SpriteRenderer, and loads one of our existing sprite assets from the Resources folder to serve as its sprite.  Note that the sortingOrder is set to DungeonMap.RENDER_LAYER_ENT; this is a convenience constant I defined to put all of the spawned sprites in front of the TileMaps that make up the dungeon.  Once all of that is done, the method returns the newly-created gameObject.  Let’s see where this is all tied together… in our Dungeon class.


The Dungeon keeps a reference to the player (we’ll need it later), and it grabs a reference to the newly-spawned player’s Player component (we can always access the gameObject directly through it).  Although, I may want to simply return the Player component from the ObjectSpawner, now that I think of it.  It’ll save me from having to manually do that every time I spawn anything.  Let’s put that on the ol’ TODO list.  Anyway, once we’ve got the player we set his position (I added a setPosition() method to the Entity class that changes the gameObject’s world position by passing it a new Vector3.  We’ll take a quick look at that next time when we cover movement), and parented the player’s gameObject to the Dungeon itself, so it appears under the Dungeon in the scene tree.  Hmm, may want to wrap that in a method as well.  To the TODO list it goes!

Eventually, this spawn code is going to be moved out of the Dungeon.start() method, but it’s okay for now.  Let’s see our results!


Not too shabby!  Tune in next time when I take our intrepid adventurer out for walkies, creating the object command queue processor and handling collision with the TileMap.


Categories: Development, Dungeon Ho!, Unity | 2 Comments

Post navigation

2 thoughts on “Dungeon Ho!: Unity – Dev Blog #3

  1. darkgnostic

    Do you plan to make code available as a downloadable resource?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: