Game Art With The Unity Asset Store

With such a limited amount of time to meet the launch deadline for Couch Heroes vs The Dungeon for the new Apple TV, we had to look into Unity’s Asset Store to be able to quickly assemble our ideas for art style, gameplay and overall feel. The Asset Store is a marketplace for Unity developers to create and sell their creativities, but for us it was a gold mine of useful tools to rapidly prototype and assemble a new game.

Here are four things that we did to make Couch Heroes vs The Dungeon happen.

Know your needs

The Asset Store can be daunting with thousands of “free and paid-for 3D models, editor extensions, scripts, shaders, materials, audio files, animations, and more”, but knowing what your game needs to get things started makes the search a lot easier. For us, we knew Couch Heroes would be in a dungeon, so we found a modular dungeon set that allowed us to piece together our dungeon the way we wanted it to look. We also knew we needed our heroes and some monsters, so once we decided they should be low poly caricatures, finding the right assets was simple. With those asset packages available, the game went from prototype “programmer art” to an almost finished looking game.

Customize to make them cohesive

Original downloaded assets pieced together

Almost looking like a finished game and actually looking like one is still a big leap for an artist. The asset models may work together, but because they were created by different developers, the texture work didn’t flow together as well as if one art team had made it. So after a few retexturing tests on some dungeon walls and floors, we decided the direction to go for everything else. Not everything needed to be retextured, mostly larger objects that had a lot of screen real estate; there’s no need to spend time on redoing something that is hardly noticeable after its been changed, so pick carefully. For the Heroes we went with a 5-6 color palette to simplify their texture and pop them off of the environment, as well as make the silhouette of the models do most of the work.

Assets after retexturing
Assets after retexturing

Bang! Pop! Wow!

Lights, particles, screen effects and flashy animations are all awesome to have and really add to gameplay and experience. We used one main Directional Light casting shadows to set the basic mood, then small Point Lights for additional effects for when a monster is destroyed, or for when a player turns into a ghost; they work really well as little flashes of light, used with particles. Our screen effects only consist of a Vignette, blur/depth of field around the edge of the screen and screen overlay to make the center gameplay area more vibrant. This allows focus to be brought to the character and add a little more depth to the dungeon. As for particles, we used the Unity Asset Store again to find a cartoon pack with a lot of great FX used for enemy impacts and deaths.

Optimize for performance

Mage with 512 simplified texture (left) vs 2048 detailed texture (right) - 2.5MB difference
Mage with 512 simplified texture (left) vs 2048 detailed texture (right), a 2.5MB difference

Because we used a lot of purchased assets, not everything was as optimized as it’d be if we had made it in-house. But there’s also not much you can do without spending a lot of time reworking the models and their UVs. What you can do, though, is make sure your static objects are being batched properly and objects and lights that don’t need to cast shadows aren’t. Also, we found that Unity’s default frustum culling didn’t seem to benefit our performance stats, so we set up an LOD Group on objects to ensure that they aren’t being rendered when they don’t need to be.

Visualization of how the LOD Group works with camera distance

With more simplified texture style, we were also able to lower the texture resolution on a lot of the environment and characters. The best way to do this is keep your original source file large, but change the import texture setting size in Unity to be smaller; this will be a personal preference to find the best quality for your game, but lowering the texture sizes can greatly increase performance.

Apple, Apple TV, iPad, iPhone, Siri Remote and tvOS are trademarks of Apple Inc., registered in the U.S. and other countries. App Store is a service mark of Apple Inc.

Procedural Map Generation

How To Do It Well, Based on the Needs of the Game


One of our first major design decisions on Couch Heroes vs The Dungeon was to generate each level procedurally. This was partly because we wanted the experience to be highly replayable, but also because creating levels by hand can take a lot of timewe didn’t know how much time we had before Apple would tell us to submit our game for the tvOS launch. We had done some previous work on procedural map generation in a different project, so we applied what we had learned to this new scenario.

In Couch Heroes we have a grid layout where each point on the grid is a single, small square that can contain one environmental item—for instance, an enemy spawner or loot pickup.

Screen Shot 2015-12-02 at 2.12.15 PM
Points as squares.

However, our previous work was kind of a different beast; those efforts involved generating a grid where each “point” was a actually large town square. Each of these large squares contained an inner courtyard area surrounded by buildings and paths, where each courtyard, path, and building was randomly chosen from a pool of handmade objects. On the one hand, the town square method guaranteed that we would have wide-open spaces, which are excellent for handling the chaotic swarms you get in a top-down shooter, and allowed for each space to be at least a bit different from the one adjacent to it. But on the other hand, this approach was very limiting when it came to level variation because each town square had an identical layout and creating each portion of the square required a lot of work from artists. Plus, paths needed to be lined up with those in adjacent squares in order to prevent them from running into the back of a building in the other square, so generating a random border layout proved to be surprisingly obnoxious.

It was pretty clear that things had to be done differently this time, and so we used a more generalized method. This method created a grid system where each grid point was truly a single small point rather than a large area, which allowed for far more variation in each generated layout.

The Basic Algorithm

Path Sobriety

We start with a “drunken walk”, which begins at a starting position and randomly moves around the environment. The algorithm is constrained by the grid’s boundaries and chooses to turn or move forward based on a given “straightness factor”, which pretty much equates to whether the algorithm is more sober (straighter line) or drunk (lots of turning). The result is a single path weaving throughout the grid.

A “drunken walk” through a less sober path.

Creating Rooms

At this point, the world is still pretty empty and so the next step fills the voids untouched by the path by placing rooms of semi-random size in several of the untouched areas. The rooms then need to be connected to the path, so we look outward from each room in order to find the nearest adjacent room or path and then create a new path from the current room to that point. The catch here is that one unconnected room can connect itself to another unconnected room and vice versa, meaning that even though both rooms are technically connected to something else, they are only connected to each other and neither is connected to the main path.

Then, we have to make sure that each room is reachable by the player, which we do by using an A* search to walk from each room back to the level’s starting position and adding a new connection whenever a valid path can not be found.

Final Touches

Now that the floors are generated, we fill the spaces with other environmental objects. Doors are placed in points that stand between a large area and a small one, like where a hallway meets a room. Destructible objects are placed on points that lie within a room and border a wall. The exit point and resurrection tower are placed in different semi-randomly chosen rooms; in the case of the exit’s room, preference is given to a room that is furthest from the entrance. Enemy spawners are semi-randomly placed in various rooms and loot pickups are sprinkled around the environment.

There you have it: a map generator capable of creating levels with enough variety to provide players with a unique experience whenever they play. Happy dungeon crawling!

Apple, Apple TV, Siri Remote and tvOS are trademarks of Apple Inc., registered in the U.S. and other countries. App Store is a service mark of Apple Inc.

The alcoholic figure is by Rflor from the Noun Project.

3 Keys For Difficulty Ramping In Procedurally Generated Games

For those unfamiliar with the term “procedurally generated game”, this simply refers to a game in which the levels have not been designed and packaged with the game. Instead, the levels are generated each time they are loaded. A lot of care has been taken to make sure that the levels in Couch Heroes vs The Dungeon are not “random” but in fact follow very specific rules on what actually should make up a level.


One of the common issues with procedurally generated games is they can sometimes feel monotonous if the programmer has not taken great care to keep the game interesting. We decided that our primary means of disrupting the monotony would be to ramp the levels in difficulty to make the game more and more interesting the further into the dungeon you go. When you consider that a procedurally generated game has an infinite amount of levels, it can seem like a very daunting task to try and program a difficulty ramp. As you will see in the following steps, the key is to keep it as simple as possible at first.

Start With A Minimal Amount Of Variables

Just like our philosophy with all programming, it is best to start as simply as possible. Begin with the bare minimum amount of variables that you believe you can ramp in order to make the game more difficult. Instead of trying to tackle an infinite amount of levels from the beginning, we decided to really focus in on the first 20 levels to establish the ramp. For Couch Heroes, we decided to start with 3 variables:

Quantity of Spawners

In a complete guess-and-check fashion, we varied the number of initial spawners on level 1 until we felt that we got enough coverage on the map that you would at least encounter some creeps on the way to exit, but not so many that anyone should not be able to make it past level 1. We followed a similar technique on level 20, but this time we assumed that a player all the way at level 20 should face a significant challenge to reach the exit. Once we established this value we just created a linear ramp that could be followed for all levels. We, of course, had to put a cap on the maximum number of spawners for both performance reasons and so that no level would ever be impossible to beat. All spawner locations are completely random, but do take into account the location of everything else on the map so they are not placed on top of anything else.

Types Of Creeps Available

From our initial game design, each creep type has a specific amount of hit points required to die, so I started by ordering them from easiest to hardest. There are 14 total creeps and we decided to introduce them to the game one at a time. So in designing levels 1 – 20, we picked 6 random levels that would not get a new creep introduced. Each level also has access to each previously introduced creep. As a starting point, we made it completely random as to which creep type would occupy each spawner position.

Whether or not there is a revival tower

As a starting point, the revival tower was removed from the 6 levels that did not get a new creep introduced.

Be Conscience Of The Audience You Are Building For

At the project kick off meeting for Couch Heroes vs The Dungeon we made a decision that we were going to build a casual game that anyone would be able to jump right into and require very little knowledge to be able to play. It was important to keep this in mind in designing the level ramp because we are not designing for people that will dedicate countless hours to mastering the game; instead we are focused on people who will hop in and play for 30 minutes to an hour per session just to unwind or pass some time. Knowing this, we could not design the level ramp to make the game too difficult too quickly, because our casual gamers would get frustrated because they are not willing to spend the time to become an expert.

Iterate, Iterate, Iterate

As it goes with anything when you use the guess-and-check approach, we were not correct with our initial ramp. The game was way too easy. One tester made it all the way to level 16 once without firing a single attack and just sprinting for the exit. It was concluded that more variables were needed.

Initial Creeps Spawned On Level Load

Originally, no creeps were spawned until just shortly before the spawner was visible to the player. This made it so that you could just sprint right past the spawner and the creeps would not have a chance to catch you. We corrected this issue by spawning a set number of creeps immediately when the level loads. Similar to the quantity of spawners, we established a linear ramp for this number by guess-and-check on levels 1 and 20 and by putting a maximum cap on the number for the same reasons as before.

This change was exactly what we needed to get the difficulty right where we wanted it for levels 1 – 20. Now, at level 21, we decided that we needed to add in some additional difficulty to make the game really challenging for the dedicated players that managed to make it this far. We are still using the same ramp on the previous variables, but with the maximum caps, the game starts to level out. For our next iteration, we decided to start varying the rate at which the creeps would spawn starting at level 21.

Creep Spawn Rate

We left the spawn rate constant for levels 1 – 20 because we had already zeroed in on the difficulty that we wanted to achieve. We decided to spend the next 15 levels or so ramping up the spawn rate all the way to the point that it matches the player attack rate. What this means is that, at a certain point in the game, you will no longer be able to stand directly in front of spawner and just keep shooting creeps and hope to ever destroy the spawner. As soon as you kill the creep directly in front of the spawner, another creep will be spawned. Once you reach this point, it will be necessary to be able to shoot and maneuver simultaneously so that you can side step a creep to get a clear shot at the spawner.

While this addition most of time made the game significantly more difficult in the higher levels, we discovered an issue with one of our assumptions for the ramp. We originally decided to randomly choose a creep type from the list of available types. While this worked well in the lower levels, there were plenty of occasions on higher levels where we would get a lot of small skeletons (the easiest creep) and very few large dragons (the most difficult creep). So for our final iteration, we changed the probability of getting certain creeps in levels starting at 21.

Probability Of Easy/Difficult Creeps

To start with, we separated the creeps into 2 groups: easy and difficult. Starting at level 21, we start ramping up the probability that a difficult creep will be selected over an easy creep. We ramp this slowly all the way to 95%. So, by the time you reach the 40’s, there is a pretty small chance you will ever see a small skeleton again.

Designing around these 3 keys will get you well on your way to designing a good level ramp for a procedurally generated game. However, you should keep in mind that item 3 does not have to be finished even after releasing the game. We are currently working on a set of updates for the game which will include an additional variable in the level ramping. We will be varying the size and shape of the map as well. Larger maps will make it more difficult to locate loot and find exits. We will also be manipulating the shape of the map in higher levels to make it more difficult. With a square map, there are a lot of different paths that can be taken to get to the exit. However, with a more rectangular map, players will be guided down a more narrow path and forced to interact with more creeps.

Apple, Apple TV, Siri Remote and tvOS are trademarks of Apple Inc., registered in the U.S. and other countries. App Store is a service mark of Apple Inc.

Controlling tvOS Without Controllers

When we got word that we’d be getting one of the coveted tvOS Dev Kits, we immediately thought of local multiplayer gaming. For years, our favorite multiplayer experiences were those where a group of us would gather around a TV and work together to beat a challenging game or battle until one of us won the day. That feeling helped us in our decision to choose Couch Heroes vs The Dungeon as our first game for tvOS.


That said, building a game that supports more than three local players presents a problem on the Apple TV. Out of the box, the Apple TV only has a single controller: the Siri Remote. You can connect up to two more external bluetooth controllers, but we assumed that most people wouldn’t have those controllers on day one. Even so, that only brings us to three players. We wanted to support four.

That brings us to Couch Control. As a solution to our controller problem, we decided to build an app that runs on both phones and tablets. That app would be able to connect to the game over Wi-Fi and act as a controller.

At its core, Couch Control is a fairly simple app. It has a join button which allows you to scan a QR code displayed within the game. Once it scans that code, it extracts the necessary network configuration settings needed to connect to the game’s internal network server. Once connected, it receives information from the game about the needed input settings to provide (touch pad, action zone, accelerometer input, etc.) and what interface to display. After that it just relays the player’s touches and taps along to the game for translation into movement, firing, or any other interaction.

On the game side, we run a Couch Control server which handles adding/dropping connections, deals with the QR codes, and manages the network traffic coming from multiple connected Couch Control clients. This is actually the most complicated aspect of the system.

Network traffic can be messy. Home networks, in particular, are a nightmare of dropped packets and lost connections. Most of the network messages we send are lossy. That means that losing a few won’t really matter because there will be another sent along shortly that has pretty much the same information. We do send some messages in a lossless manner, though. These are generally messages that must get through. Generally, that means stuff like “Pause sending me messages” or “I’m disconnecting from you”.

In the end, Couch Control works perfectly as a controller for Couch Heroes vs The Dungeon. Anecdotally some of our testers want to use Couch Control instead of the Siri Remote. We know that as time goes by, players will prefer full size game controllers, but having Couch Control as an option let’s everyone get in on the fun.

Apple, Apple TV, Siri Remote, and tvOS, are trademarks of Apple Inc., registered in the U.S. and other countries. App Store is a service mark of Apple Inc.

Sprinting to tvOS (Tips and Tricks)

In 2010 I went to my business partner’s house and gathered around the dinner table to crunch over the weekend because we had learned that we would be a launch title for the original iPad. My partner had to be on a plane to Cupertino to test the app on the device in about 72 hours; we had to get it done, and we did. About six weeks ago, we found out that we would get one of the few developer kits from Apple for the new tvOS. With a blurry deadline we committed right then to develop and release a game for tvOS; come hell or high water it was going to happen. The only problem was, this game wasn’t going to be developed in a vacuum; we had our regular projects and clients that we had to continue to serve. We gathered the team and informed them of the opportunity and the idea, and asked for volunteers; it was going to be a nights-and-weekends, run-and-gun effort.

Screenshot 1

What we had on our side was a team of dependable programmers, designers and artists who are 100% committed to what they do. We also inhabit a unique environment in Durham, North Carolina called The American Underground. The AU allows entrepreneurs and developers like us to pivot to meet challenges without the worry of how deeply it’s going to effect us six to twelve months down the road.

Here are six things that we did to make Couch Heroes vs The Dungeon happen.

1. Determine A Minimum Viable Product

How do you eat a whale? One bite at a time. Our list of must-haves for the game was limited, to say the least. When the first SCRUM was done we had three things on the whiteboard. A minimum set of features makes the goal achievable.

2. Make It Playable

From the beginning we knew, that to hit our deadline the game would have to be playable from start to finish. We created all the screens, rudimentary level art and characters, effects, and game play in the first week.

3. Write Tickets

We wrote tickets for every detail, idea, and task in the project so we didn’t lose track of who was doing what or any “nice-to-have” features that popped into our heads.

4. Iterate, Polish and Cut

Cutting features can be painful, but it can be very satisfying. Trimming the fat and polishing constantly creates a streamlined experience for players and each tweak improves the game holistically. And, the good ideas naturally rise to the top. Once the game was playable from end to end, we iterated, tweaked and polished.

5. Fail Early and Often

Don’t be afraid to try something and don’t take it hard if it doesn’t work. Rapid iteration allows you to find out what works and what doesn’t.

6. Count On Your Team

At Third Track, we have always adhered to the philosophy that we are all adults, we can figure out what needs to be done, and we can make it happen.

Apple, iPad, Siri Remote, and tvOS, are trademarks of Apple Inc., registered in the U.S. and other countries. App Store is a service mark of Apple Inc.