Unity’s Performance Debugging Tools

Posted on April 24, 2018 by blargzor

Last week I discussed some of the basics of how rendering works in Unity. As I mentioned, all of that was setup for this week’s blog post. Since I’m working on rendering optimization now, I figured it would be a great time to go over the debugging tools Unity provides in order to aid rendering performance. Online resources can be a little scarcer for rendering than they are for other aspects of coding, so hopefully anyone who’s working on their own game might glean some useful information from this post. And even if you’re not working on anything right now, I hope you follow along and maybe learn a bit!

Unity is a nice little game engine, and, as such, it does a lot of the work for you. For the most part, when making a game, you don’t have to worry about the nitty-gritty stuff like rendering. When building for mobile, however (especially when you have specific graphics/lighting customization), you might have to descend into shader-land. Fortunately, Unity provides a few tools that can help you to deal with optimizing your rendering pipeline.

Profiler

The first step in fixing rendering performance issues is to know about them. The best way to do that is with the Profiler window (Window -> Profiler). While you’re running your game, the Profiler keeps track of a lot of incredibly useful information, like how long each frame takes to render, split up by category. For instance, the Profiler will tell me that a frame took 60 milliseconds to run, 40 of which were due rendering and 15 from script execution, etc. This is the first place you should check when trying to improve performance – there’s no point in optimizing your rendering if it’s actually your scripts that are running slowly!

So much information!

For the purposes of rendering, there’s an entire Profiler section! The Rendering Profiler keeps track of the number of batches, setPass calls, triangles, and vertices in each frame. Looking here for inconsistencies, spikes, and just high numbers in general is a good way to get an idea of why your game is taking so long to render. The Profiler also has a lot of other info that’s useful for diagnosing and debugging performance problems. I really recommend profiling your game and thoroughly looking through the results to get as much information about how your game is running as possible.

Android Debug Bridge

While profiling in the editor is pretty useful, it doesn’t tell us much – of course our game will be fast on a great big computer, but how does it run on a crappy phone?

The is where ADB, or the Android Debug Bridge, comes in. ADB allows your computer to communicate with your Android phone about all sorts of stuff. Specifically (for our use cases), it allows you to profile your game while it’s running on a device. If you plug your phone into your computer, build the game directly to your phone, and open the profiler, you should see some results. This is the information we want, because it tells a much truer story about how your game runs on a phone.

Where Shadows Slumber, for instance, runs at ~200 fps in the Unity editor. When I plug my phone (the Google Pixel 2) into the profile, I get a framerate of ~60 fps. This is pretty good, so I know our game can run on newer devices. However, when I plug in my old phone (a broken HTC One M8), I get closer to ~12 fps. Looking at the profile during this run will give me much more useful information about what I should fix, since this is the device where performance is actually suffering. If you’re making any big decisions or changes based on profiler results, make sure those results come from your actual targeted device, and not just from the editor.

ADB usually comes with the Android SDK – if you have the Android SDK set up with Unity (which allows you to build to Android devices), then you should be able to use ADB with the profiler pretty painlessly.

I should also mention that there might be an equivalent tool for iOS debugging, but, as I do all of my development on a Windows machine, and all of my testing on an Android phone, I wouldn’t know what it is. Sorry!

Frame Debugger

The next most important tool for rendering performance is the Frame Debugger (Window -> Frame Debugger). While the Profiler tells us a lot about what’s happening during rendering as a whole, it still treats the rendering process as a black box, not letting us see what’s actually happening. The is where the Frame Debugger comes in – it allows us to see, step by step, exactly what the GPU is doing to render our scene.

As I mentioned last week, the GPU renders the scene through a bunch of draw calls. The Frame Debugger allows us to see what each of those draw calls is drawing. This allows us to determine which materials/shaders are causing the most draw calls, which is one of the biggest contributors to rendering lag. It also provides a bunch of information about each draw call, such as the properties passed to the shader or geometry details. The important thing that it tells you is why this draw call wasn’t batched with the previous draw call.

All of this happens in a single frame

Batching is Unity’s first defense against rendering lag, so it makes sense to batch as much stuff into a single draw call as possible. Because rendering is such a complex process, there are a lot of reasons why draw calls can’t be batched together – certain rendering components simply can’t be batched, meshes with too many vertices or negative scaling can’t be batched, etc. The frame debugger will tell you why each draw call isn’t batched with the previous one, so you can determine if there are any changes you can make that might reduce the number of draw calls, thereby improving rendering performance.

For example, in Where Shadows Slumber, we re-use meshes in certain places. Sometimes, if we require a “mirrored” look we’ll reuse a mesh, and then set the scale to -1. This was before we really looked into rendering performance, and, unfortunately, it causes problems – a mesh with negative scaling can’t be batched with a mesh with positive scaling, so this ends up creating multiple draw calls. Rather than setting the scale of the object to -1, we simply import a new, mirrored mesh and update the object, allowing these draw calls to be batched and improving performance.

Stats

That’s it for the heavy-hitters; between the Profiler, Frame Debugger, and ADB, you should be able to get a pretty good idea of what’s going on in render-land. Unfortunately, digging through them can take a while – sometimes you just want a quick indicator of what’s going on in your scene. Enter the Stats window.

The Stats window (click “Stats” in the Game View) is a small overlay in the game view which gives you a quick rundown of various rendering indicators in real time. It’s not as in-depth, but it gives a much quicker picture of performance.

That’s a lot of batches!

While it sounds like the stats window doesn’t add much – after all, the Profiler can give you the same information – I’ve found it to be very useful. The Profiler is probably better when you’re actively debugging rendering performance, but the stats window allows you to notice places where rendering performance might take a hit, even when you’re doing other things.

When I’m testing some other part of the game on my computer, I’m not going to notice any rendering lag, because my computer is so much more powerful than a phone. I’m also not going to be looking at the Profiler or Frame Debugger, because I’m not worrying about rendering at the moment. However, if I have the stats window open and I notice that the number of draw calls is in the hundreds, then I know something is going on. At that point I can get out the Profiler and see what’s happening – but I wouldn’t even have known there was anything amiss if it weren’t for the stats window.

Scene View Draw Mode

As we get further and further down the list, we’re moving from “debugging all-star” to “it’s useful, but you probably won’t use it much”. Scene View Draw Modes fall into this category, but they’re still good to know about. You can access different Scene View Draw Modes by clicking the drop down menu at the top right of the scene view window.

The Scene View in Unity is one of the main windows that you use to make your game – it shows everything in the scene, allowing you to move around through the scene and select, move, rotate, scale, etc., any game objects. Usually the Scene View just displays the objects exactly as they would be displayed in the game. However, it has a bunch of other modes, and some of them are actually pretty useful. The two that I find the most useful when considering rendering concerns are listed below, although they’re all worth checking out:

Shaded Wireframe: This is my default draw mode, as it looks pretty similar to the normal shaded mode. The difference is that it also shows all of the triangles and vertices that you’re drawing. This is useful because certain shader operations are performed once for every vertex. Decreasing the number of vertices in your scene can give you a bit of a performance boost, and the shaded wireframe draw mode helps you see when you might have too many vertices.

The shaded wireframe shows that there are too many polys.

Overdraw: This mode draws each object as a single transparent color. This makes it very easy to see when multiple objects are being drawn in the same spot on the screen. Since the GPU has to draw every pixel of each object (even if that pixel will be overwritten later), it ends up wasting some calculations. Areas that are very bright will waste even more calculations. Switching to this draw mode every so often lets you know if there are any places where you might want to remove some meshes.

The Internet!

It should pretty much go without saying, but one of your best resources for debugging performance is the internet. Unfortunately, when it comes to rendering in Unity, the information out there is pretty scarce. Unlike with normal imperative coding, where you can simply Google “how to pathfinding” and get 30 implementations, you have to work a bit harder with rendering stuff. I find it’s best to do what you can and only resort to the internet with very specific questions. That said, there is still a lot of helpful information out there. You just have to know going in that only one of every three stack overflow questions makes any sense, and only one of every four Unity forum threads are using the most recent APIs. It’s like “Googling: Nightmare Mode”!

For anyone reading this post who is actually working on rendering stuff – I’m very, very sorry. I hope that this post and the tools I discussed help to shed at least a little bit of light in the dark underworld that is shader-land, and I hope you can achieve your rendering goals and make it back to the mortal realm before your soul is forever lost.

For everyone else who hasn’t done any rendering stuff, I hope you learned a bit, and that maybe I inspired you to get involved with some rendering code! It’s really not that bad, I promise!

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

If you didn’t already have a working knowledge of rendering, I hope this post helped! If you do know about rendering stuff, I hope you don’t hate me too much for my imprecision! You can always find out more about our game at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebook, itch.io, or Twitch, join the Game Revenant Discord, and feel free to email us directly with any questions or feedback at contact@GameRevenant.com.

Jack Kelly is the head developer and designer for Where Shadows Slumber.

Rendering in Unity

Posted on April 17, 2018 by blargzor

As you probably know, Where Shadows Slumber is starting to ramp up toward a release this summer. It’s an exciting, terrifying time. We can’t wait to share the entirety of what we’ve been working on with the world, but there’s also a daunting amount of stuff to do, and not much time to do it.

If you’ve played any of the recent beta builds, hopefully you like what you’re seeing in terms of design, functionality, polish, art, and sound. Unfortunately, if you’ve played the beta on anything other than a high-end device, you’ve probably noticed something that you don’t like: lag.

Lag is annoying. Lag is something that can take a great game and ruin it. It doesn’t matter that your level design is perfect, your models are beautiful, and your music is entrancing if it only runs at 10 frames per second. If that’s the case, nobody is going to enjoy playing it. And, regrettably, that happens to be the case for Where Shadows Slumber.

Like butta’!

So, one of my biggest tasks before we release is to optimize the game, making it run faster and allowing us to have higher frame rates. The area with the most opportunity for improvement is during rendering. A game consists of a lot of logic – Obe’s location, things changing in shadow, etc. – but rendering is the process of actually drawing the scene onto the pixels of your screen.

Earlier this week, I started a post about the different tools you can use to help optimize your rendering performance. It seemed like a good idea, since that’s exactly what I was doing. However, I realized that if you don’t know how rendering works in the first place, most of it is complete gibberish. So I’m gonna leave that post for next week, and this week I’ll give a quick introduction to how 3D rendering works in Unity.

Rendering

Rendering is the process by which the objects in your game are drawn to the screen. Until it’s rendered, an object in your game is just a collection of information about that object. That information gets translated from information the game engine understands into information the GPU can understand. There are a few important concepts to understand here:

An object’s mesh describes the shape of the object. It consists of a collection of vertices and triangles.
An object’s material is a description of how that object should be drawn. It encapsulates things like colors and shininess.
Every material uses a shader. This is the program which calculates exactly what color each pixel should be, based on the information in the mesh and material.
World space is the 3D coordinate space in which all of your game objects live.
Screen space is a 2D coordinate space that represents the screen to which the game is drawn.

The basics of rendering are pretty easy to understand, at least from a high-level view. The meshes for the objects in your game are translated from world space to screen space, based on the camera that’s doing the rendering. For instance, in Where Shadows Slumber, objects that are further away in the x-axis will be higher up and more to the right when viewed on the screen. Fortunately, we don’t have to mess with this too much – Unity’s cameras do a good job of making this translation.

Once we know where each pixel should be drawn, we need to determine what color that pixel should be – this is where the material and shader come in. Unity provides a whole bunch of information to the shader (position, angle, information about lights in the scene, etc.). The shader uses that information, plus the information from the material, to determine exactly what color the given pixel should be. This happens for every pixel on the screen, resulting in a beautiful picture of exactly what you expect to see.

The GPU

Now that we understand the basics of rendering, let’s take a deeper look into how it actually happens: the GPU.

The GPU, or graphics processing unit, is the part of the computer in charge of calculating the results of our shaders to determine a pixel’s color. Since modern phones have over 2 million pixels, our shader code must be run over 2 million times per frame – all within a fraction of a second.

How does the GPU manage to do so many calculations so quickly? It’s due to the design of the GPU, and can be summed up in one very important sentence: the GPU is good at performing the same operation, a bunch of times, very quickly. The key thing to remember here is that it’s good at performing the same operation; trying to perform different operations is what slows it down.

Specifically, switching from one material to another causes a bit of a hiccup in terms of speed. The properties of the material are passed to the GPU as a set of parameters in what is known as a SetPass call. SetPass calls are one of the first and most important indicators when it comes to optimizing rendering performance, and are often indicative of how quickly or slowly your game will run.

Because SetPass calls take so long, Unity has a strategy for avoiding them called batching. If there are two objects that have the same material, that means they have the same parameters passed to the GPU. This means that those parameters don’t need to be reset in between drawing the two objects. These two objects can be batched, so the GPU will draw them at the same time. Batching is Unity’s first line of defense against rendering slowness.

The CPU

While the GPU is the star of the show when it comes to rendering, the CPU, or central processing unity, still does some important stuff that’s worth mentioning (even if it doesn’t have a huge bearing on the optimization steps we’ll be taking). Of course, the CPU is in charge of running your game, which includes all of the non-shader code you’ve written for it, as well as any under-the-hood things Unity is doing, like physics and stuff.

The CPU does a lot of the “set up” for rendering, before the GPU comes in and does the heavy number-crunching. This includes sending specific information to the GPU, including things like the positions of lights, the properties of shadows, and other details about the scene and your project’s rendering config.

One of the more important rendering-related things the CPU does is called culling. Since the CPU knows where your camera is, and where all of your objects are, it can figure out that some objects won’t ever be viewed. The GPU won’t know this, and will still perform calculations for those objects. In order to avoid doing these unnecessary calculations, the CPU will first remove any of the objects that won’t be drawn, so the GPU never even knows about them.

All of these Hitlers would be culled by the CPU (image credit: smbc-comics.com)

Since we’re talking about performance, it should be noted that the GPU and the CPU are two different entities. This means that, if your game is experiencing lag, it’s likely due to either the GPU or the CPU, but not both. In this case, improving the performance of the other component won’t actually make your game run any faster, because you’ll still be bottlenecked by the slower process.

So, now that we know a little bit more about how rendering actually happens, maybe we can use that knowledge to improve performance! At least, that’s what I’m hoping. If Where Shadows Slumber never comes out, then you’ll know I’ve failed. Either way, I’ll see you next week for a look into the tools you can use to help you optimize rendering performance in Unity!

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

Jack Kelly is the head developer and designer for Where Shadows Slumber.

Unity 2018!

Posted on January 30, 2018 by blargzor

For those of you who haven’t been keeping up with current events in the indie game development space, there’s something really important that’s happened recently that you should probably know about.

It’s 2018!

Which leads me to another topic that we can spend some time discussing – Unity 2018!

Unity

Before we talk about Unity 2018, let’s discuss Unity itself. Unity is the game engine in which we’ve been developing Where Shadows Slumber for the past two and a half years, and even longer ago, when we were working on SkyRunner. Developing in a game engine makes things a lot easier for the little guys like us, because we don’t have to worry (as much) about things like platform-specific dependencies, rendering pipelines, mipmap implementations, etc. Without having to worry about that nitty-gritty stuff, we can spend our time focusing on the more grandiose parts of the development of WSS.

So the question is – how has working with Unity been?

Unity!

Overall, Unity is awesome. It has somehow managed to find the right balance between an engine that you could use to make a AAA game, and one that you can use in a small, bureaucratically-challenged team. This alone is a great reason to use Unity – compared to using more complex engines like Unreal, it’s much easier to get up and running from scratch.

Of course, there are trade-offs, and this is a particularly big one. In order to avoid inundating newer users with game development intricacies and high-level concepts, Unity does a lot of that stuff for you, behind the scenes. While this is awesome in a lot of cases, there are some cases where it can be more of an issue. Imagine you’re an experienced game developer, with a sizable team, who wants to do something very specific in the backend. There’s a decent chance that Unity will have hidden that part of the engine from you, or at least made it difficult to interact with.

This tradeoff is, at its core, the reason that you would or wouldn’t want to use Unity. The next most important feature is the ease with which Unity allows you to develop on multiple platforms. All of your development is platform-agnostic, and you only choose the platform as you’re compiling. Is your Android game a success, and you want to build it for PC? Simply hit a different button, and Unity takes care of the rest. I don’t have too much experience with other engines, but this seems to be a place where other developers give Unity a lot of credit, and I think it’s deserved. I can’t imagine having to go through all of the development we’ve done multiple times for different platforms.

Beyond these bigger points, there are a few other things that might sway you, though they’re probably a little less important:

Unity is very UI-based, which means that it might be a little annoying for a hardcore programmer, like myself, whereas this probably makes it easier for someone with less coding experience, like Frank.
Unity is a sort of one-size-fits-all solution, whereas some other engines are ready-made to create certain types of games. For example, Unreal has good support for creating FPS games. If I were to make an FPS game, using Unreal would probably give me a bit of a head start on Unity.
The only language Unity supports is C#. C# is a pretty awesome language, but for those of you who hate C#, or strongly-typed languages in general, it may take some adjusting.

Again, I want to say that Unity has been great for us, and I would probably use it again if I were to start another game. Frank and I wouldn’t have gotten to where we are with Where Shadows Slumber if it weren’t for Unity.

Unity 2018

I mentioned earlier that Unity does a lot of stuff for us, and I specifically brought up rendering pipelines. The danger of using a game engine (that you didn’t make yourself) is that other people are making decisions for you, and those decisions are set in stone to a certain degree. On one hand, we didn’t want to mess with the collision system, so we were glad to have it. On the other hand, we ended up in a position where we did want to mess around with the rendering pipeline, and we weren’t able to.

Enter Unity 2018.

The Unity UI, blatantly stolen from one of their blog posts.

I normally don’t pay too much attention to the ins and outs of the various updates that Unity makes. They’ve been marching out updates, both major and minor, for a while now, and we’ve just been going with the flow. Unity 2018, however, has managed to catch my eye. Unity recently released a blog post describing the updates they’ve been making to graphics and rendering in Unity 2018, and I have to admit that I’m pretty excited about it.

As I mentioned before, Unity does a good job of riding the line between too-complicated-for-new-users and not-powerful-enough-for-power-users, and the updates described for Unity 2018 somehow manage to play to both sides. If you’ve ever held a conversation with me about Unity and Where Shadows Slumber, then you know that I’ve been struggling with getting shadows to render the way I want, while also maximizing the efficiency of the rendering pipeline. Fortunately, Unity 2018’s focus on graphics and rendering has provided two huge features in this area, one for each of the two camps.

Scriptable Render Pipelines is the feature that I’m excited about, as it’s the feature aimed toward the entrenched coder. Rather than using the hard-coded rendering pipeline that we’ve been wrestling with for the past two years, we can create our own rendering pipeline that does exactly what we need it to.

“Programmers can now write custom renderers tailored specifically to their project.”

This is a huge boon to us, and to game developers everywhere. Rather than hacking together a shader that uses Unity’s shadow-mapping inefficiently, we can (hopefully) create a rendering pipeline that performs shadow-mapping exactly how and when we need it. This should result in more efficient rendering, along with less headache while writing shaders.

Shader Graph is the other great feature Unity 2018 will have, and is targeted toward less code-inclined users. Unity provides a standard shader with a bunch of options, so you can create the materials you want. However, if you need more customization than the standard shader provides (like we do), you’re suddenly thrust into the depths of shader-writing. With a masters degree in computer science, I’ve been just barely keeping up with writing our shaders, and there’s no way that Frank would have been able to do it. This is really a bummer, as the artist tends to know a bit more about the “look” they’re trying to get.

“[I]t’s simple enough that new users can become involved in shader creation.”

Unity 2018’s Shader Graph changes this – rather than writing complex shader code, Unity exposes a simple interface for creating shaders graphically. This would allow an artist with no coding experience whatsoever to build a custom shader to display things exactly as they want – giving the artist the control they need over the “look” of the game, and allowing the programmer to focus on the game itself.

A sneak preview of Unity 2018’s Shader Graph UI

I’m sure that Unity 2018 comes with quite a few quality-of-life updates, as well as some other new and interesting features. For me, however, it’s all about those rendering updates!

Beyond Where Shadows Slumber

A friend of mine recently asked if I would use Unity for my theoretical next project, and if I would recommend it to someone just starting on a game. The answer I gave him is one that applies to every question – it depends. In fact, it mostly depends on the factors described in the first section.

Overall, I’m inclined to say that I would use Unity again. After over four years, I’ve come to know it pretty well. It’s powerful, and allows you to create and iterate pretty quickly. That said, there are some exceptions; I would probably pass on Unity for my next project, or at least do some more research, if:

I had very specific backend/optimization requirements
I were working with people who had a lot of experience with a different engine
The scale of the game were much bigger
The game involved a lot of networking/server concerns

There are probably other factors that come into play – basically, it pays to do some research before you dive in. I would recommend Unity, but more than that, I would recommend knowing what you’re getting yourself into. There’s nothing worse for your game than getting halfway through it in an engine that won’t work for you in the end.

If you’re anything like me, at this point the word “Unity” no longer sounds like a word. I’m gonna take that as a sign and wrap this post up; I hope I was able to answer any questions you might have had about working with Unity, and that I got you pumped for Unity 2018!

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

If you have any questions about working with Unity, or if you have any other questions about Where Shadows Slumber, feel free to contact us! You can always find out more about our game at WhereShadowsSlumber.com, find us on Twitter (@GameRevenant), Facebook, itch.io, or Twitch, join the Game Revenant Discord, and feel free to email us directly with any questions or feedback at contact@GameRevenant.com.

Jack Kelly is the head developer and designer for Where Shadows Slumber.

An Indie Developer’s First Trip to Unite

Posted on October 6, 2017 by Yoshgunn

I’ve been an avid Unity user for nearly 5 years at this point. Without this creative tool, I would not be making games. It’s as simple as that. I owe a lot to this engine; it’s making my dreams come true. It’s even changed the landscape of the commercial game engine market. (Remember when the Unreal Engine 4 had a monthly subscription?)

Despite my love for Unity, somehow I never had the chance to attend Unite, their flagship conference. At Unite, they gather developers, influencers, sponsors, speakers, and Unity employees under one roof for two days of workshops. I finally decided to go when I saw they were holding one in Austin, Texas. Just a short plane ride away, compared to some of the other places they hold this show. Just in the next few weeks, they have three events across the globe: Unite Melbourne, Unite Singapore, and Unite India!

Have you ever been to Unite? No? Then this is the blog for you. It’s a straightforward account of my travels this past week to Unite Austin 2017. If you’re deciding whether or not to go, I hope this honest blog helps you make a decision.

Day 1: “Keynote? Never Heard Of Him.”

Time to confess… there is one problem with this blog: I completely missed Day 1 of Unite, so I can’t tell you what it was like!

I meant to be there, but my flight got rerouted in mid-air to Dallas because of weather in Austin. We stayed at that airport for 2 hours before taking off again. I was supposed to have gotten in around 4:30, which would have been just enough time to check into my hotel and walk across the street to the Austin Convention Center. Instead, we landed at 8:00 pm… right when things were wrapping up and badge pickups had already closed. Damn!

Perhaps you can consider this a cautionary tale. If your travel plan relies on everything going perfectly, you’re not planning – you’re dreaming.

You can check the schedule to see what happened, because your guess is as good as mine. There was a keynote talk, and I’m sorry I missed it! They put it online here.

Day 2: Party Time!

Day 2 was my first real day at Unite. This was my chance to familiarize myself with the main showcase, the talks, and the crowd. My first impressions:

Unity gives out free food at breakfast and lunch and it’s really good
There weren’t as many people as I was expecting. Or perhaps Unity chose a convention space that was a bit too large for this show?
The main showcase seemed underwhelming…

The negative first impressions didn’t really last though. As I went about exploring I found there was plenty to do and tons of people to meet. In fact, Unity scheduled some meetings with me prior to the show, which surprised me! Their Analytics team wanted to meet face-to-face to ask me user questions. I really appreciated that, even if I didn’t personally gain from it. The fact that they want feedback that badly shows me they care about constantly improving the engine, which is a good sign.

The schedule for the talks is online (you can find them here), but if you were wondering what was in the main showcase, I saw the following:

(a) This live talk show segment being filmed that you could watch

(b) A live demo area that was for mini-classes

(d) Unity demos with members of the company nearby to explain the tech

(e) The usual showcase of professional, released games Made With Unity

(f) A separate showcase for VR titles Made With Unity

(g) A gallery of printed images, which I was not expecting!

(h) Booths for sponsors and partner companies, like Nintendo

I didn’t realize this, but Day 2 is also party night apparently! Unity knows how to throw an awesome party. I went to three! First, there was an Amazon App Store party. I believe they invited us because the Where Shadows Slumber demo is on their store. After speaking with one of their developer outreach leads, they even gave me an Amazon testing device!

What an unexpected surprise!

Then I went to the Unity Analytics party, which was a happy hour before the real deal – the Unite party. It was insane, man. They rented out an entire venue called Fair Market and had the whole thing catered! There were taco stations, chili bowls, dessert food trucks, an open bar… I went a little wild. I didn’t leave until 10:30. :0

It might seem weird to keep mentioning the parties and the food, but it gets to the core of what Unite is. Don’t go into this expecting some kind of staid business trip. You can totally get a lot done – just networking with Unity employees was worth the money. But I think the real way to enjoy Unite is to treat it like a big gathering of indie devs who just want to talk, hangout, and get to know each other. I wish I knew that going in.

Recognize that the price of admission also covers events that are meant to promote bonding and companionship. Take the name literally! It’s not just wordplay – this is really about remote developers coming together and uniting!

Unity takes their food seriously.

Day 3

By Day 3, I found my footing. I went to a steady stream of talks, with time in between to attend some of the mini-lessons given by Unity. Their employees are so friendly! I missed an entire talk about the Unity Profiler, so I went up to the presenter and asked for help. Not only did he help me, we went to the Ask The Experts section and spent a full half-hour going over Where Shadows Slumber and how to optimize mobile games. It was incredible!

The talks I went to definitely varied in quality. There were some I was looking forward to that really disappointed me (the “Lessons Learned from PSVR” one was not as fun as the description indicated), and others that didn’t seem relevant at first, but totally inspired me. By far, the best one was a talk about this Walking Dead mobile game by Jason Booth of Disruptor Beam.

Go find this online when he posts it. There’s so much information coming at your face, your face is going to leave your body to find a new one. And that that body will EXPLOOOOODE WITH KNOWLEDGE! He wasn’t shy about the parts of Unity that he didn’t like. That just made me trust him more! Essentially the talk was all about how they got this ridiculous massive world to show up even on lower-end mobile devices. His command of graphics and optimization was impressive.

Hoping to Return

I’m writing this from a hotel room in Los Angeles. (I went straight to IndieCade after Unite) Now that I’ve attended my first Unite, I’ve got just one piece of advice for anyone attending: fill your schedule. When I planned this trip, I allowed for gaps in my schedule to explore the main expo hall. I was expecting something along the lines of GDC – a massive expo hall you could never possibly see all of. Instead, I found it to be a bit lacking. I was able to make the rounds in an hour or two. So, avoid gaps in your schedule and fill your time with meetings or talks! You’ll find that more helpful than wandering around aimlessly.

I hope to return to Unite America next year! (I’m calling it “Unite America” because I don’t know if they’ll be in Austin again.) However, my one condition is that I’d like to return to give talks about Where Shadows Slumber and maybe have a booth in the Made With Unity showcase.

Which reminds me of another talk I saw, all about Unity Connect… time to jump on that!

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

You can find out more about our game at WhereShadowsSlumber.com, ask us on Twitter (@GameRevenant), Facebook, itch.io, or Twitch, and feel free to email us directly at contact@GameRevenant.com.

Frank DiCola is the founder of Game Revenant and the artist for Where Shadows Slumber.

Game Revenant

The video game is the defining art form of our generation.

Tag Archives: unity

Unity’s Performance Debugging Tools

Profiler

Android Debug Bridge

Frame Debugger

Stats

Scene View Draw Mode

The Internet!

Rendering in Unity

Rendering

The GPU

The CPU

Unity 2018!

Unity

Unity 2018

Beyond Where Shadows Slumber

An Indie Developer’s First Trip to Unite

Day 1: “Keynote? Never Heard Of Him.”

Day 2: Party Time!

Day 3

Hoping to Return