Dungeon Ho!

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;

DHU 5

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.

DHU 6

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.

DHU 7

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.

DHU 8

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!

DHU 9

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.

-Steve

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

Dungeon Ho!: Unity – Dev Blog #2

Welcome back, coding fiends!  Today we’re going to look at the core app design for Dungeon Ho!: Unity, from both a project and code perspective.

As I mentioned previously, I decided to go with a single-Scene approach.  Each game menu, screen, and dialog would be organized in a hierarchy of Unity Canvas objects, which will keep me from having to worry about data persistence or nested scene management.  As this will be a single-developer project, encapsulation and decoupling is not going to be my biggest concern.

So, let’s look at the basic scene tree;

DHU 1

As you can see, within the scene I have a GameObject called Game.  This, as the name suggests, is the object that contains the entire game; the map, the monsters, the players, all of that good stuff.  It will also eventually contain things like AudioListeners, high score tables, and so on – but, we’ll burn those bridges when we come to them.  For now, the Game contains our Dungeon, which consists of a Map that has three layers, represented by Unity Tilemap objects; Floor, Walls, and Details.  These layers are separate for both stacking/rendering and collision purposes, which we will set up later.  Floor and Walls are self-explanatory, but what about Details?  The Details layer will represent “props” that decorate the dungeon, like torch brackets, furniture, and cracks in the floor.  By keeping those tiles on their own layer, we can generate a wide variety of scenery without having to make a tile for every possible combination.  The Camera will eventually be attached to our player object, but for now we can let it float free.

Next up is our overall project structure for asset management.  I’ve created some preliminary folders, as shown in the Project view;

DHU 2

As you may already know, the Tile objects are created from sprite sheets sliced from singular images.  Currently, I’m using placeholder art imported from the original Dungeon Ho! assets, but these will eventually be replaced.  The tile assets themselves are kept under the Resources directory so that they can be dynamically loaded at runtime.  I should probably look into making them AssetBundles instead.  We’ll throw that on the ol’ TODO list.

With the initial set of GameObjects created and a basic project folder structure in place, let’s start coding.

There is, of course, a Game.cs script – but as our Game currently does bupkis, it’s simply an empty MonoBehavior.  We’ll fill it in as the game progresses.  The most important thing to do right now is to create our Dungeon/Map classes so that we have something to run around in.  The Dungeon GameObject has a Dungeon.cs script attached to it, which currently (we’ll change this eventually) generates a new dungeon map when the game starts.

DHU 3

Note that we do a GameObject.Find() call to locate the Map GameObject within the class and grab a reference to its DungeonMap component (…which I haven’t discussed yet; it’s the DungeonMap.cs script).  We do this so we can access the script attached to it and manipulate the Tilemap, which we’ll see in a moment.

The DungeonGenerator member variable deserves special mention.  Initially, I had the DungeonGenerator class not inherit from anything (IE, it wasn’t a MonoBehavior or ScriptableObject) that just had a single static method called generateDungeon().  I switched it to a ScriptableObject and made it public so that I could swap out the DungeonGenerator object from within the editor.  This is so that I could dynamically assign different DungeonGenerators to the object, which would generate different kinds of dungeons.  It’s currently using a class called TestDungeonGenerator, which generates a single, simple 10×10 room with a center wall and both entry and exit tiles.  When the actual DungeonGenerator is ready, and I’m done using this small room for testing, I’ll simply swap in the other one.  ScriptableObjects; you gotta love ’em.  I’ll go over that process a bit more next time.

Here’s the DungeonMap.cs;

DHU 4

Pretty straightforward so far.  I’ve defined constants to represent the layers, as well as the different tile types.  There’s an array of Tiles (for our loaded Tile resources) as well as TileMaps (for our Tilemap layers).  We do some Find() calls to locate our in-scene Tilemaps; again, we could easily just have assigned them from the editor, but this is pretty much the same thing (whoops! Took the screenshot before I changed the DETAILS layer to find the “Details” object!  Rest assured this was fixed in the code).  We also define a method to load a particular tileset, which grabs all Tile assets in the provided folder, and a setTile() method that sets a particular tile on a particular layer to a particular index.  We simply pass in the TILE_ constant and the code indexes it into the Tile[] array and finds the proper Tile object to use.  Easy!

Tune in next time, and I’ll show you how I generated the test dungeon… and, if we’re lucky, I’ll also have had time to get a player wandering around in there.

-Steve

Categories: Development, Dungeon Ho!, Unity | Leave a comment

Dungeon Ho!: Unity – Dev Blog #1

Hello, nerds!  Today we’re kicking off the first in a series of Development posts about porting my first Android title, Dungeon Ho!, to Unity.

Dungeon Ho! was a Roguelike written for Android API level 10 and released in the summer of 2013.  It did… respectably for a first solo attempt in a niche with basically zero marketing, but ultimately a bunch of design decisions that I’d made during development came back to bite me in the ass to the point where the planned ongoing addition of new content and features never came to be.

Here’s a screenshot of the game running in either Android Studio, Eclipse, or on my test device.  I forget.

5631_10151355638768124_168043149_n

I’ve had a plan to do a sequel ever since I realized there were a number of ways I could have made the game better, both feature-wise and code-wise.  After all, it was my first Android title and I’d learned so much since (mostly by leveraging the fact that I’d published an app to actually get a string of jobs as a professional Android developer, but I digress.  Even so, Lesson #1: publish something!  It looks great on your resume!)… but one snag came in the form of Unity, which I’d learned during a stint of downtime between jobs.  Unity offered so much stuff in it that I could leverage to make great games, but the tilemap support was still in development and, at the time, didn’t seem that great.  I revisited it recently, though, and that cinched it; rather than re-use my custom Roguelike engine (…which needed refactoring anyway), I would merely port the game to Unity.

Why. though?  After all, refactoring aside, I already had an engine, right?

Well, yes.  But here’s the thing; Roguelikes have a big audience, especially on Steam.  If I could make a stellar sequel, and I did it in Unity, I could leverage the cross-platform building capabilities of Unity to spread it far and wide.  I mean, I did already have one or two people ask me if there was an iOS version, so there you go.

***

Ok, now what?  Well, the first thing I had to do in terms of tech (I already know my feature list) was to analyze the Android build and see where I went wrong, and what exactly needed to be re-done as opposed to just ported to C# from Java.

Here’s my initial list;

  1. UI – When I first moved to Android, I didn’t feel like it would be productive to spend a huge amount of time absorbing all of the new platform’s features.  After all, by this time I had a large amount of J2ME experience and felt that I would be able to leverage my hard-won optimization skills to keep the game small and light.  So, all I learned how to do initially was start a thread that would paint to a canvas, scale it to the size of the device’s display, and that would be enough.  My main concern was that I had no hard data on whether mixing blitted bitmaps with Android’s XML/Layout-based UI would cause performance issues that I wouldn’t start seeing until riiiiight before release, because I was already developing on the Android emulator (I didn’t have a device yet) and figured I’d play it safe.  In the long run?  I wasted a ton of time rolling my own UI components when I could have totally just used Android’s dialogs, buttons, lists, text boxes, and other handy widgets.  For the Unity port, I will definitely be leveraging Unity’s UI canvases.
  2. More robust Command system – To keep the amount of Java classes in the app fairly small, I chose to do a number of things with switch statements rather than polymorphism.  This was fine when the switch statements only had a few branches, but the game essentially takes a different switch branch for every possible command in the game.  This… got ugly.  The Unity version will definitely provide child classes for the TurnCommand class, cutting down on the game loop complexity immensely.
  3. No class-based conditionals – “if (variable instanceof Class)”?  Blargh!  The fact that I kept checking the types of my objects told me that I’d blundered my inheritance chain somewhere.
  4. Better object spawning – For some reason, I chose to do the most basic of object initialization within the SpawnFactory classes, but setting other aspects of the items and mobs was done wherever said item/mob was spawned, leading to me copy-pasting various spawning boilerplate all over the place, so that when a bad spawn initialization occurred I would have to hunt down which spawn chunk-o-code was responsible.  Making the spawn factory more robust, to allow specific kinds of object spawning as well as randomly-generated, is definitely going to be a must.
  5. String formatting, not concatenation – Ugh.  With the amount of text in a Roguelike, you’d think I’d have been smart enough to use formatted strings, but no; I concatenated everything.  The amount of time I spent tweaking my string cleanup routines to remove rogue spaces and such was… a lot more than it needed to be.

That’d do for a start.  My next step was to decide on the overall application architecture within Unity.  After a lot of pondering over things like persistent objects and scene loading, I eventually decided to just keep it simple and use a single Unity scene with a number of switchable canvases for the menus and information screens, both in and out of the game.

And, that’s basically where I am now.  Tune in next time where I’ll go over the initial Unity coding, and how the various game objects (as well as GameObjects) are arranged.

-Steve

 

Categories: Development, Dungeon Ho!, Unity | Leave a comment

A New Beginning

Hey there gamers, how’ve you been?  Has it really been five years since Dungeon Ho! was released on the Android platform?

I’ve been dipping in and out of new projects since then, learning new technologies and dealing with the ups and downs of Real Lifetm – but I’m happy to announce a few happenings that may be of interest.

Firstly, though… how ’bout that Ouya, huh?  Didn’t exactly take off like gangbusters, did it?  I’m kinda disappointed that I wasn’t able to develop anything for that platform after all, but I guess in hindsight it would have been a whole mess o’ wasted effort.  Those of you curious about a followup to Dungeon Ho! are going to be happy, though, as I’ve finalized the design of the pseudo-sequel, Dungeon Ho!: Unity.  DH!U is going to be a spruced-up, refactored port of the Java/Android codebase to the Unity engine in C#.  Big whoop, you say?  Well, the more interesting aspect of this decision is that I’ll be writing a series of Dev Blogs documenting the process which will serve as a pseudo-tutorial of sorts for those of you interested not only in the complete game development process from beginning to end (God willing, anyway) as done by a solo indie developer, but also the ins and outs of developing a 2D roguelike in Unity.  I’d wager there are far more of you in that latter camp than the former, at least for now!

That’s not all I’ll be up to, though; I’ll share development of all of the other projects I’m working on, as I work on them.  Hopefully you’ll find these postings useful in your own game development journey in one way or another.

Steve

Categories: Development, Dungeon Ho!, Unity | Leave a comment

Create a free website or blog at WordPress.com.