One of the most difficult things in working with a group is communication. There are many gears turning in the machine of success. Understanding your role in making sure things run smoothly is only part of the machine. Another crucial element is to rely on and trust that your group members are doing their part while you do yours.


Missing two, but here’s most of the team at SGX.16!

Twelve of us have been working on this game for the last nine months and we have had to learn how to work with people that have different personalities and skillsets. We have been using a server that allows us all to work on the game on different computers and whenever we make changes, everyone else receives these updates on their computer. In general, only one person can be in one scene of the project at a time. Otherwise, when two people go to commit their changes to the server in the same scene, one person will lose everything they just worked on. Almost everyone working in the build has had their stuff overwritten at least once during the course of the project. It is usually a very frustrating and disheartening event. However, this caused us to come up with better ways of communication and brought us to using a check-out system.

Our game ended up having quite a few mechanics which caused more bugs than we were expecting including game-breaking bugs. The last couple of weeks mostly consisted of the programmers fixing hundreds of bugs, while the artists worked on bug testing, promoting the game, and polishing the art inside of the game. This also ended up being the most important time for communication and support. When critiquing parts of the game that need to be tweaked, fixed, or removed, it is important to focus on constructive feedback about the game and not focus on problems that someone may have with the person who created it. On the other side, while being critiqued, it is important not to take things personally. Everyone wants the game to be the best it can be and someone else may see issues that you can’t. Staring at one thing for too long tends to give us tunnel vision and we oftentimes need a second opinion on how well something works. Take responsibility for your work and take initiative when offered new tasks. Don’t be that person who constantly makes excuses as to why you can’t complete something and don’t blame others for something that you did. Everyone is in it together which means we all have to be team-players.


Bug testing

This whole process of creating a game with a fairly large team has been a great learning experience. It has taught us all what is required to succeed in creating a large-scale project. We have learned that you might not like everyone on the team, but it is still very possible to get along with and work with them. Overall, we’ve had a great time making this game and have developed many important life-skills along the way.

Stout Game Expo 2016

Stout Game Expo

The semester is drawing to a close, and with it, our production of Building 37. Everything we’ve been working of for the last year is coming together, and at the Stout Game Expo (SGX), we will be showing off our game to the public for the first time. It is at this event that all game design students can show off the games they have been working hard on. Each group will have several computers set aside for anyone who wants the play the game.

As a team, SGX has been our end goal. It is where our friends and family, as well as people from both Stout and the community, can come and play our game.  It is our deadline for which we must have the game done and polished, and while the programmers have been busy squashing all the bugs that pop up, the artists have been hard at work putting together additional materials for both SGX and release. We have a launch trailer and posters to help advertise the game, and for the expo, we have pins, stickers, and postcards to give away to those who play our game. We have worked so hard this year, and now is our chance to show the public just what we have accomplished.

After the Stout Game Expo, we also will be showing off our game at the senior show. This event will go much like SGX, but will reach a different crowd of people. We have also entered our game at Glitchcon, which is April 29th and 30th. in the Minnecade. We are looking to enter the game in different game conferences such as Indicade and IGF (Independent Games Festival). After that, we’ll be making the finishing touches on the game before we release it online for anyone and everyone to play. It’ll be available for both Windows and Mac on Gamejolt and

On Wednesday, April 27th , Building 37 will be playable at The Spring 2016 Stout Game Expo from 6 PM – 9 PM in the Memorial Student Center.  If you can, stop by and play the game for yourself!

Game Launch

Sprint 8: Attack of the Crunch Time

Hello everyone! As we finish off the final week Two Hat games has continued to be in crunch time mode, meaning most of us are losing sleep and drinking way too much coffee. It has truly come down to the point where I can’t tell if the drain is swirling or we are swirling the drain. In this final week before our last build is due to Professor/producer Dave Beck things have really come down to the wire. Everything has now come to a head and we are looking down the barrel of an incredibly stressful week. The stakes are high as an entire feature may be cut if it cannot be fixed in the next two days.


Our war with the twine board mechanic has reached D-day as our programmers focus all their energy into trying to get it to an acceptable state. This feature has been continuously reworked and redesigned throughout the semester as play testing proved time and time again that it was not an enjoyable part of the game for most players. In an effort to keep the game feeling more like an investigation and less like a walk through we have fought not to cut this feature. By making tweaks to the content and UI we have managed to change the board from walls of uninteresting text, to a word matching mini-puzzle. However, in this process of last minute changes we have hit a few snags that may not be fixed in time. Our goal is to produce a game that seems polished and complete. If we are to hit this goal the twine board must be finished. If we can’t get that to happen we are going to have to cut it. For now you will just have to stay tuned to find out if our  last ditch efforts go to waste or if they will be enough to keep the board.


So as I mentioned before we have hit Crunch Time, this is a natural part of everyone’s semester but for most of us it is amplified this time around because this is our final semester before we join the real world. We want to make this project the best it can be seeing as it is a reflection of all the time, blood, sweat, and tears we spent learning and developing our skills here. This amplified crunch time has made all of our mistakes from previously in the semester really stand out. It is easy to look back and say” Man we really should have done it that way.” Or “Why didn’t we see this coming?” The great thing about this though is it shows us what we have learned. It may have been learned the hard way but now we know for our next game/project how to work smarter and do things better. When you think about it, that is the policy here at Stout, we learn by doing. We learn by getting our hands dirty and trying to accomplish something we have never done before. We can all leave this place with the experience of having seen a 3D game project through from start to finish. As Thomas Watson (founder of IBM) Said “The way to succeed is to double your failure rate.” Knowing what doesn’t work and why is just as important as knowing what does.

The build we produce on the 18th will be not be our final public release, it will how ever be the build Professor Beck will be evaluating us on. April 27th is our projected public release date. Building 37 will be playable at The Spring 2016 Stout Game Expo (SGX) Wednesday, April 27 at 6 PM – 9 PM in the Memorial Student Center. It will also be available for Mac and PC on Gamejolt and There will be a second opportunity to come play with the developers at Glitchcon 2016 the following weekend (April 29th and 30th.) in the Minnecade.

I’ll leave you with some final eye candy before you can explore the game yourself.


Environment Artist and PR Manager

Alex Dvorak

This slideshow requires JavaScript.


Bloopers and Easter Eggs

Hello Dear Reader,

Two Hat Games is officially in crunch time according to Professor Dave. ‘Crunch Time’ is something like a final alarm in the midst of an impending Tsunami.  We have two weeks to finish the game, squash all bugs, polish any visual errors, stay hydrated, etc.  We, the artists, are putting all of our faith in our programmers and hoping that we end the year with a fun, enjoyable game.

In order to retain our ‘crunch time’ sanity we decided to compile a few bloopers (or bugs if we’re being realistic) that won’t be in the final build!

Despite what you may be thinking based on the video, we do most things intentionally.  There are 3 Senior Game Design Classes this year and around 5 different games.  We collaborated with a few of the the other teams and placed some of their assets in our game as Easter eggs.

We hope to see you playing the game in May! Our game will be available on and Gamejolt.

If you’re in the UW-Stout area, stop by the Stout Game Expo and play on April 27 in the MSC  6pm – 9pm.

Game Launch 2016 Site

Truly yours ❤


Giving the Game Some Feeling

Trying to find the right audio for the right spot is something that I like to do and something that I feel was not getting done as efficiently as I wanted it to.  I needed to come up with some way to help into the right frame of mind while trying to figure out what sounds fit and with the help of Adam, I realized I needed to use the maps we have made for each of the levels.  These maps, or floor plans, have helped me start thinking and figuring out what needs to go where so that there is always something there to hear, not just dead silence.

Here is an example of what I have been doing:


While it really is not anything too special except writing on a map, it allows me to have some structure on how I am setting things up and getting the correct sounds that we need to make this game feel right and complete.

A game can have truly amazing mechanics and it can play really well, however if you don’t have sound or correct sounds a lot of people will not truly enjoy the game as much as they would like to.

Having the correctly placed sound effect or 3-D sound allows the player to become more immersed in the game.  The whole goal is not necessarily to get the player to hear every different sound, but to have those sounds be played naturally so that you get the sense of space and surroundings.  An example of that, would be you move from one light to another that slight buzz as you get underneath the light just adds to the realism of the game.


Here are some of the trimmed sound effects that we are implementing into the game:



It has been a long process but changing the workflow and having my attention focused strictly to audio and making the game come to life, have me on a great path to the final build of this game.  Building 37.


Scripted, The Story of Events

So we’ve seen a lot of great art, great design work, and even learned about our new voice actors. Something I want to throw at you guys today is some great C# code from the depths of Unity.

The point of the script I’ll be showing off is to create scripted events in a game world. Basically we’ll be taking away the players ability to move so that we can lead our player the right way during critical parts of the game.
As far as actually doing it, all we need here to start is a class to handle the input. We’ll call this ‘InputMaker.’ Inside of this class we’re going to create a static instance of the class itself, so that we have something to call from.

public class InputMaker
    public static InputMaker myInput;

Great start right? So the next part is creating arrays that contain everything about our inputs for our game. In my case, because our character moves around the level, I ended up putting four different arrays here. You can look at the example below.

You’re also going to notice that I create a bool called playerInput. We’re going to use that to tell our game if the player is doing input, or if we are making input for the player!

string[] inputNames = {"ActionOne", "ActionTwo", "ActionThree"};
bool[] inputKeysOn = {false, false, false};

string[] movementInputNames = {"Horizontal", "Vertical"};
float[] movementValues = {0, 0};

int checkNum;

public bool playerInput = true;

Obviously these are all just an example, and go right below the static myInput we created before. To break everything down, the inputNames and movementInputNames are going to be lists of all of your inputs. The first one will be all of your button presses, so any keyboard buttons or controller button input you have. For the movement array, that’s going to be things like a joystick or a mouse that you have that needs to be moved around. That’s why we set the movementValues array to contain floats, because for us movement isn’t just on or off, we have different variants of speed that it can go at.

Now that we have these values, it is time to use them! What we’re going to do next is create some methods to be able to set whether or not we want these keys activated. That way in a script we’re able to call these methods and force our player to have some input.

public void SetKeyOn(string inputName)
    for(int i = 0; i < inputNames.length; i++)
        if(inputNames[i] == inputName) checkNum = i;

    inputKeysOn[checkNum] = true;

public void SetKeyOff(string inputName)
    for(int i = 0; i < inputNames.length; i++)
        if(inputNames[i] == inputName) checkNum = i;

    inputKeysOn[checkNum] = false;

public bool GetKeyOn(string inputName)
    for(int i = 0; i < inputNames.length; i++)
        if(inputNames[i] == inputName) checkNum = i;

    return inputKeysOn[checkNum];

So these three methods will work for the simple button presses, when using the float values you’re going to need to pass in float values for the Set, as well as return a float for the Get.

Now, something I recognize is that having a SetKeyOn AND SetKeyOff can seem a little redundant. However, it doesn’t affect runtime to badly, and as well it makes things easier to trace in the long run. We’ll be able to debug each thing separately.

The last big thing we’ll need to do before actually scripting our events is making changes to our player class. Here I’ll just show a simple example that hopefully you’ll be able to use in your own games! Here we’ll look at what happens when we’re trying to get input from our ‘ActionOne’ button being pressed. Normally it would look like what we have below here.

    //do stuff...

With our system the if statement is going to get a little bit longer, but we’ll have a larger area of control overall with our scripted events.

if((Input.GetButtonDown("ActionOne") && InputMaker.myInput.playerInput) || (InputMaker.myInput.GetKeyOn("ActionOne") && !InputMaker.myInput.playerInput))
    //do stuff...

So now we’re checking who is in control, and if any input is even trying to pass through anyway.

Now, the last thing we need is an actual script to make everything work! So create a simple MonoBehavior script, and inside here is what we do.

public class PressButton : MonoBehavior 
    int currentStep = 0; // This will keep track of what command needs to happen.
    float timePassed = 0; // This will give us time to pass, if needed.

    void Awake()
         InputMaker.myInput.playerInput = false;

    void Update()
        time += Time.deltaTime; // We increment time, important for 
                                // movement commands.
        if(currentStep == 0) // Check the current step.
            InputMaker.myInput.SetKeyOn("ActionOne"); // Here we set the action on.
            currentStep++; // And finally we increment the step, so that we can 
                           // use more steps moving forward!


And there you have it! You will now be able to use Unity to make some great scripted events of your own. I hope you were able to get some good information out of this post, and I’m excited for you to check out all of our scripted events inside of Building 37, being released this May. Here’s a sneak peak at one of our events the player will go through.


– Austin Stewart, Lead Programmer

Finding our Voice

Ladies and Gentlemen, your Detective Ellis and Dr.Shannon!



(Sumner Musolf)                                 (Seth Berrier)

Hey guys and gals this is Jeremy Building 37’s own Game Design –Narrative lead with a special secret post regarding Building 37. You read right building 37 fans we hear at Two Hat Games have found those golden voices that will be our two main characters! Looking for just the right fit for our characters has been going on for about a month now and I am happy to say we have found our matches. We had a lot of people audition and it wasn’t an easy decision to make, yet we as a team are confident that we made the best choices regarding our characters personality. Congratulations to Sumner Musolf (Above Left) and University of Wisconsin – Stout’s very own Seth Berrier (Above Right). We here at Two Hat would also like to thank anyone and everyone who auditioned, it was a great pleasure to see so many interested people wanting to be a part of our game and we are thankful for your time and participation. The voices of Detective Ellis and Dr.Shannon is a huge aspect of our game, it helps engage players and full immerses them into our world and story.

If you don’t know about our characters here’s a little taste of what to expect: Detective Ellis, our main protagonist, is a hardened veteran who specializes in missing person cases. After the war he took his skill in finding people and started his own private investigations firm. Ellis has a slight distain for the way the world is after returning from war, and only goes after cases that peak his personal Interest. Now our Dr.Shannon is a brilliant scientist in the field of “odd” objects, but that was years ago, now after being left alone for many years he had been driven mad, and is now Ellis only help during his investigations. We are excited to bring you Building 37 in the upcoming months, and we hope you are excited to. We are hoping to get moving on with recording later this week and hope to have it in game soon! Thanks for reading, and remember… you didn’t hear this from us.

Branding: The Icing on the Cake

Howdy Folks!

We here at Two Hat Games have touched on the idea of creating a coherent style amongst all our artists. This was back in November when we were finalizing our “Art Bible”, however, by this point not much of our game had anywhere close to finished models, much less textures. The work that we’ve done to focus on a pipeline for every one of our assets, whether it be a one off prop or a repeatable room has now begun to finally pay off.

Without reiterating whats been said before, I want to move beyond art within the game and move to the art and design that we will be creating outside of Building 37. We have not covered much to do with the Graphic Design and branding that has gone into the production of our game up to this point.


Graphic Design is a bit of a passion of mine. Though it is not my focus, I have taken numerous classes and amassed a small portfolio. The design, branding, and marketing of games is the icing on the cake that helps grab and audiences attention. Unfortunately, right after deciding what game we were going to be developing (and maybe even before), I reached straight for that icing before we had really even decided on a style. Luckily, fellow teammates and our producer were able to reel me in and convince that this dessert needed to be saved. I was still able to create a small identity for the game that helped inform decisions later on. The current identity is simple, yet reinforces the idea of redaction and mystery.


Screen Shot 2016-02-25 at 5.09.17 PM

It’s interesting to look back at some of these early, unreleased promotional images and even our first teaser. They may share a similar tone to what we have now, but our aesthetic has changed dramatically.


Screen Shot 2016-02-25 at 5.05.09 PM

Our website launched just after the announcement of Building 37, and despite sporting a striped down aesthetic and color scheme, significant thought was given to all parts of the interaction.

The website beginnings with a large feature image that moves into a description of the game. However, so much is communicated to the user in just this first section. The user now knows the name of the game, the setting (Seattle based on the Space Needle in the skyline), and the parallax movement downward mimics Ellis’ slow downward descent in the game. Other small pieces include Polaroid gallery with red string to mimic our twineboard as well as the extensive use of the redaction motif. We wanted to ensure that many of the ideas and mechanics that the player would discover while playing our game would be introduced in our website experience.

As we come closer our launch day, stress levels are high and moral is always barely fluctuating. Luckily, the last month of our scheduled timeline calls on our artist to change hats to bug testers. Due to this, most of the art will be completed before then. So, along with testing, I will hopefully be furthering some of these early branding ideas that we developed in to a full-fledged identity for marketing.

PS. I also did the very early and very rough identity for our studio, Two Hat Games. I don’t think that we have talked about the origin of 0ur name here before. We had reached a point early in our time together that we needed some moniker to rally under. We threw around names like “Uncle Bison” and even the now defunct “THQ”.


At some point while deciding positions and duties, someone proclaimed “Looks like we’ll all be wearing two hats”. From then on, the name stuck.


So long,

Adam Toth

Lead Artist

Repeatable Game Assets

When creating a game like Building 37 that is architectural in nature, the creation of repeatable assets and general prop models help lend a sense of realism and authenticity for the player.  They help make a game seem “lived-in” and can act as kind of a visual code to inform the player as to the environment they are in.  When you actually sit down and start to list all the objects that are associated with and found in a government facility, or any big business type facility for that matter, the list of stuff can get pretty long.

However, creating only a handful of general assets that you can just duplicate in Unity and change the placement of each throughout the game, saves time, effort, and is more efficient for development.

Therefore, we have been gradually creating objects within our environment that can be used repeatably throughout each level of our game.  Things like trash cans, doorways/frames, desk chairs, office telephone, general office desks, you get the point.  Once the object is modeled, we have also been creating various differences in the textures we apply to them. We apply these different textures to the same objects in order to add to the variation throughout the game.

We are now at the point in development of our game where everything aesthetically is starting to come life.  As we begin to increase are asset creation and implement them into the game, Building 37 is starting to look like an actual lived-in facility.

The images below are only a handful of the repeatable asset we have created for use in Building 37 as general prop models which can be used throughout the game.

This slideshow requires JavaScript.

– Douglas Heinkel

Art by the Bible: an Update

Hey there!

In the last post I made talked about the absolute importance of having written standards for all things Art and Programming in documents regarded as Art/Programming Bibles, respectively. Now that the team has had some time to put these Bibles to use, I’m coming to you with an update of how they’ve (sometimes) saved us a lot of headaches.

Texture work has gone swimmingly ever since we agreed upon a color palette, shown below.

Screen Shot 2016-02-09 at 11.53.02 AM

With the color palette as a sturdy base, we are able to maintain similar room and object styles throughout the game, no matter what artist creates the texture. Shown below are 3 examples of textures created by 3 different artists.

This slideshow requires JavaScript.

Now, if you look closely, you can see the color variance and each artist’s interpretation of the color palette. We all have different styles but the Art Bible directs us closer towards one resolved style. Thick outlines and lines to designate texture are big players in making our art look united. I struggled early on with using black lines to imply texture instead of creating the texture with color and detail, but with practice I’ve been able to replicate the style and nearly match the art of my teammates.

We recently ran into one major issue with programming; programmers, comment your code! There’s nothing worse than, on build day, your script breaking the game but you’re unavailable to come in and work so your teammates have to decipher your franken-code and try to solve the issue. Commenting increases readability for anyone who needs to take a quick glance at your code, and it can be a quick refresher of what your code means when you look back at it in 4 months. It’s a quick summary that can save you a lot of time in the long run.

Overall, our Bibles have been invaluable. I’ve personally gone back time and time again if I ever had a question on a naming convention/UV layouts. Without a dedicated color palette our art would look entirely different. The Art and Programming Bibles are the glue that holds our project together. Coherence is created in our game with both of these documents.

Thanks for listening, and I hoped you’re as excited to see the textures in-game as we are here at Two Hat Games!

Ronnie Smith

Part artist, part programmer