Designing the Experience

Level Design is a really important process in the development of a game. Without level design we would only have a pretty space to walk around in. It is much more than just drawing a map that looks cool. This isn’t solely the visual experience but is the way the map, puzzles, and visuals come together to create a cohesive picture. Level design is the process of creating the world that the player experiences. It takes a lot of work and iteration and as a team we have done much of that.

We start with discussing what game elements should be in each level. A list is created of all of the aspects that will make the level unique: the kinds of puzzles, what obstacles the player should come into contact with, as well as the visual aesthetic of each level. The visual aesthetic is extremely important. It tells us the basics of what we can and can’t do. For example, the water themed level should have a lot of puzzles that involve water and swimming, but should not include anything fire or lava related. This limits what we can do aesthetically and what we can do with puzzle design.

whats in each level.jpg
A very early example of going through each level and deciding the elements that will be included.

After the list of all of the elements that should be in each level is created, we begin drawing out maps. This allows us to think visually about the flow of the level design. Drawing out the maps helps us to begin designing the puzzles, thinking through the steps that make a puzzle fun but challenging. There needs to be a variety of puzzle difficulty. Some puzzles need to be difficult and others that the player can solve pretty easily. Additionally, we need to work on the flow and order of the game. Having important concepts introduced to the player in early levels is important so that he or she can successfully navigate more difficult levels later in the game. At the early stages there is no right or wrong design. Many of the best ideas come from the most random encounters.

Great ideas can come about at any time hence this napkin drawing.
Initial Water Level
Some early pencil level drawings of the water level.

Our team comes together after coming up with much of the level design to look at the positives and negatives of each other’s ideas. Working as a group really helps the overall decisions making. Everyone sees things differently which allows for a lot of unique and interesting discussions which lead to better design overall.

Updated water level design after team discussion.

After we have a good idea for different puzzles we begin to build everything out in Unity. Gray boxing is the process of creating a level through the use of basic geometry. It lets us build prototypes of individual puzzles and whole levels that our team is able to play test. We want to make sure the gray box experience is what we want the actual experience to feel like. If a puzzle isn’t intuitive, fun, or working as intended, it will not work as fully functional play experience even if looks pretty. The gray box stage allows us to do lots of testing to refine our game before we start putting in tons of work to a level or area that might get cut from the final game.

At this point we go into each level and do a rough visual pass to make it feel similar to the rest of the game. The visual pass is the process of going through and replacing all of the gray boxes or in our case blue boxes with real assets that the art team has been working on.


This is a great example of gray boxing and first pass on set dressing. You can see the drastic difference between each screenshot.
Top down view of the water level. Left: “Blue” Boxed. Right: First set dressing pass.

After the set dressing pass we push it on to our lighting guy to do an early lighting pass. The lighting pass is an early test of what the overall lighting of the game will look like. This allows the artist to have a better idea of what the space will look like while they do the final set dressing. Once the lighting pass is done we can go back into the space and really refine the visuals. We work to make each level feel unique but also have a cohesion across the game. This is when we introduce more of the individual models of specific pieces needed for each area. For us this includes owl statues, mushrooms, plants, and more.

Our most recent challenge for level design has been reworking our temple level. The temple level is a large temple created by the ancient owl civilization. It is supposed to be grand but dilapidated. It is introduced early in the game and is where you access other levels. It has been a challenge to design this place both visually and mechanically. Originally, this space was supposed to be its own completely contained level. Our project scope was too large for the amount of time we had and we had to make compromises. In order to keep the most important area of our game, without having to cut an entire space, we decided to do some massive changes to how temple level would work. Instead of being complete level it is now a hub space. This allows us to keep the space for use as the end level of the game without having to change much of the original design.


Above is an early design for what the space was originally supposed to look like. Before the redesign you were supposed to do a small puzzle that returns you to an environment similar to each of the past levels you encountered and offers you a chance to further refine your understanding of the puzzle in each area. After completing all of them you would unlock the entrance to the temple.


Thanks for reading and I hoped you learned a lot about how we do our design. Also above is a sneak peak of what our temple hub might be looking like.

-Mitch Design Lead Strix Studio

It’s Not All Fun in Games…

It’s not all fun in games during the development process: while the majority of the time things run smoothly, every development team has it’s share of bugs and bloopers. We’d like to share ours with you, in the hopes you’ll get a chuckle out of it! Now that you know all of the tasks and people involved in making Everend fully realized, it’s time to show you some of the things that can go awry along all parts of the pipeline. Equal parts hilarious and frustrating, we hope you enjoy some of the unexpected, confusing, and downright weird issues our coders and artists have to iron out before the game is released.


There was that one time Kaia was a robot:


And then afterward a strange, checkered alien.

Alien Kaia

After that, her textures weren’t quite right…


But that’s okay, we all know true beauty is on the inside! …Right?


Then Kaia was in motion which created it’s own set of problems, like her unquenchable love for river dancing…


As well as her tendency to occasionally leave some pretty important things behind.


We’re making a horror game now I think,


And I’m not even going to pretend I know what’s going on here.



All in all, bloopers and bugs aside… Development is running smoothly and we’re well on our way to a beautiful, exciting final product. We’ve had our share of laughs and groans along the way, but it’s all part of the creative process. After all, nothing ever good came without a little dancing, suddenly turning into a robot, or without leaving important facial features behind. Or something like that.

We look forward to having you play! Kaia does too.




Water plays an important visual role in Everend. There are plenty of really nice looking shaders already made, but to get the kind of look that cave water has we needed our own. We didn’t need anything too complicated so our water includes only the basics like distortion, waves made up of normal maps, and color change based on water depth.



To get the wave effect we simply used two normal maps scrolling in opposite directions. The immediate effect is an invisible plane, but with the addition of a specular reflection the waves start to show when a light is reflecting off of them.



The water surface at this point is still mostly invisible except for the specular reflection so we added a distortion effect to the water. The refraction part of the shader uses the same normals as the specular reflection. To get this effect we used Unity’s GrabPass to grab what would have been displayed and grab either a pixel offset to the current one based on the color of the normal map. The method to create the distortion is fairly straightforward. The shader needs to grab the red and green color of the normal texture which are between 0 and 1 and transform the values so they fall between -1 and 1. Then it needs to get the position of the current pixel and add the offset to it. Finally use that value as the location of a pixel on the GrabPass texture and return its color. As long as the normal map has smooth transitions so will the distortion. The intensity of the effect can be altered by multiplying the transformed red and green values, and if you pause the scrolling normals then the effect works well for ice.



The last two effects are both based on camera depth. The surface of the water should remain clear, but as its depth increases the color should change and the water get murky. This effect can be achieved by getting the distance between the water plane and the pond bottom and linearly interpolating between clear and colored based on the difference. To get the distance to the surface of the water the shader should multiply the vertex position by the model view projection matrix, and then in the fragment function all you need to do is grab the positions z value. To get the Depth of the pond floor you just need the LinearEyeDepth of the camera depth texture. After that subtract the plane depth from the floor depth and you have the difference (You can divide this by a value that will then control how deep the color starts to change). Then linearly interpolate between your surface color and underwater color based on the difference and return the color.

About the Programming Team

Now that you know a bit more about how the art team’s flow of work goes. I will attempt to shine some light on how the programming team functions. We don’t have a pipeline in the same sense as the artist because our work is based off of things that our design team feels is essential to the game. Which was originally the basic game-play mechanics for the game such as movement in the world and camera movement with the character and then continuing all the way to things such as shader scripting and our own character controller. Along with all the in between programming such as User Interface, Audio, character interaction with NPCs (AI), animation implementation and other things we do that I have forgotten to mention here. All of these can be split up into specific roles that we have on our programming team. So without further wording I’ll dive into our programming teams’ roles that we have, which may be defined differently for us.

Lead Programmer

The lead programmer of the team manages the rest of the programming team by assigning tasks to the other roles as they see fit, keeps track of current development of the game, and works with other other leads on the team to ensure that the game is coming together with art, design, and programming all in agreement so the development process goes more smoothly. The lead programmer also does programming as well, and normally has knowledge of all of their team members roles.

Graphics Programmer

Graphics programmers on our team consist of the programmers who work with shaders and lighting. The shader programming is done using in unity using CG(C for Graphics and some ShaderLab language and more than a few custom shaders have been created. Their uses include: water surfaces, waterfalls, depth masks, double sided planes for models, and an underwater distortion effect. The lighting on our team is not necessarily something needed to be done by programmers, but for our purposes it is. Lighting is just that, making our game have light so the player can see and it looks visually appealing, and it’s not as simple as turning  on a light switch as there are many options that affect lighting. These programmers have to work closely with artists since what they do visually affects the game and needs an artist’s touch.

surface water shader example

User Interface Programmer

Our UI programmers are the ones who implement any and all user interface aspects of the game. This includes our main menu, pause menu, underwater oxygen depletion, interaction prompts, and also included in this are particle effects. Since we are trying to use minimal UI elements our UI programmers for in game content have their work cut out for them and they are doing quite well at it. Along with graphics, UI programmers also have to work closely with artists especially with particle effects to ensure the best quality.

Underwater oxygen particle system in a non set dressed level

AI Programmers

For our team AI programmers, or artificial intelligence programmers, work on things such as our NPC mechanics and how the NPCs react to the player. Things they do include making the fish, bat, mole and eel move, and make all of those NPCs act differently towards the character. For instance the fish is not hostile and may even follow you while the eel hides and lunges out to attack the player underwater.

Audio Programmers

Audio programming is what  you think it is, implementing the sounds effects, and background music in the game so it works with all of the previously mentioned programmers’ tasks. And again since we are going for a minimal UI approach audio will player a large role in our player experience.

Physics Programmers

Our physics programmers are the programmers who work with the player’s character controller and in-game physics based events.The character controller is what allows the player to move the character, while the other physics tasks revolve more around underwater mechanics and also physics based rock movement. The last two thing being the most difficult to work with and hard to refine, but we’re getting there.

Generalist/ Game-play Programmer

The rest of what we do as far as programming is what I consider generalist or game-play programming which consists of refining our game-play mechanics, implementing animations, implementing puzzle mechanics, and overall bug fixing of previously made code. This role for us is more of a catch all role and includes every programmer on the team.

A look at our unfinished player animation state machine made with Unity’s Mecanim.

These are the roles each of our programming team members identify with in some way shape or form and many team members do more than one of these roles. Hopefully this told you a little about what we do, but if you want me to sum it all up: we make the pretty things the artists make move and/or work.

-William, from Strix Game Studio

About the Art Team!

So, we ran into a problem here, folks! We loooooove sharing with you guys, but we also hate spoilers. So while we have been quite busy, there is very little to show you without revealing some pretty major aspects of the game. Don’t worry, by our next sprint in two weeks, we will have lots to show you, including some great art and gameplay videos. But in the meantime, we are going to explain what our art people actually do all day. (aside from eating and shooting each other with nerf guns). Our team artists all tend to have specific things they focus on, like I focus on almost entirely 2D work like graphic design and texture art, but we float between other tasks that need to be done as well. What tasks you say? Well let me tell you!


The Pipeline:

All of these next positions are part of something called “The pipeline”, which is all the steps it takes to smoothly make art assets as a team from beginning to end. The pipeline is what keeps our team moving forward in art production like a well oiled machine c:

Concept Art:

Concept art is how every piece of game art is born. One of our concept artists will take the idea for an asset or character, and sketch out ideas for what it can look like, refining it until we have a final piece of art that will be used as reference for making the object.

Some mushroom concepts by Emily.

3D Modeling:

This is the core of the art we need for Everend, it is making the actual 3D meshes to place in the game. We use Maya for the bulk of the work, and will also go into zbrush as well, if an object needs a lot of detail. The person that does the 3D modeling will make the mesh, which is the polygons that make the object, and then they UV the object. The UV is all the polygons stretched out to lay flat, like a sewing pattern, to be painted on to make our textures. Sometimes the artist will paint their own textures when they are done UV’ing, but they also will sometimes send them to another artist to do the texture work!

Screenshot (64)


This is where the color, texture, glow, and other qualities aside from its shape are created. The artist will paint different ‘maps’ fitting the UV’s of the object, which will each add different features to the object. Every object needs color, which is the ‘texture’, and then from there the objects really begin to vary. Some have normal maps, which add bumps and added small detail, or glow that makes certain areas look illuminated, or maps that add shine and other fancy details.

Here is an example of some objects with all their textures applied!

 Particles (in some cases):

So pretty! Particles are the glitter, sparkle, and pixie dust of the level. They aren’t large physical 3D objects, but animated effects to add detail and character to the game. The particle artist (me) will make the textures and come up with sketches for what the particles will look like, and then work with the programmer in charge of particles (Gabe), to find out the best way to achieve that effect in game.

Particle Concepts
concepts for our particle effects, painted over pictures of the models

Rigging and Animating (for characters):

As you have already seen in Alex’s post, rigging is building the skeleton for moving the models for characters in the game. Once you have the skeleton, the character is posed and keyframed into the animations we need for the game. You can read all about this on our rigger/animator Alex’s post, where he explains the whole process!


Other Art Roles:

Outside of the pipeline, there is still a lot of other art to be made!

Graphic Design/PR/UI:

Graphic Design and UI art is used in the game for menus, buttons, icons, and other 2D pieces of art that are used to help communicate things to the player. Outside of the game, this artist also creates the business cards, pamphlets, websites, presentations, press materials, and all sorts of other printed materials that can be used to help promote and present the game.

Screenshots of the different social media sites we have created


Level Design:

This art isn’t anything you will see directly in Everend, but is vital in designing our game. Level design art is technical drawings that show the layout of different areas, how different puzzles will look and operate, and help concept how different levels can be arranged for the best play experience. Because this art is used to brainstorm ideas for level design, our programmers will also sketch out level design art as well! Level design art is mostly rough sketches and scribbles, but there are some nicer polished pieces we use for presentations and pitching our game.


Thanks for reading, and I hope to see you back next week, when we talk about the different roles on our programming team!




Happy Holidays!

Well, we did it, we have finished the first semester of our project! We are very excited that we have finished the semester. We just did a public play testing on the 14th, where the senior game design teams got to have our games played students on campus, who were attracted by the lure of both playing games and free pizza. We laughed, we cried, we broke our games, we found things that were working great, and we found things that made people want to throw the controller through the screen. But hey, that’s what play testing is all about. We had a great turnout and people enjoyed playing the games. As a group, we got a lot of great feedback for Everend from it that we look forward to working on next semester.

blog post

We also made an appearance at the fall game launch here at Stout to show some previews of what we have so far, and are excited to bring our finished game to the Spring Game Launch next semester on April 27 2016 starting at 7 pm. If you are interested in seeing the final project that we have been talking about, meeting Kaia, and helping her find her way out of the caves, then we really look forward to seeing you there! If you cannot make it to that event we will also be showing the game at the senior show on May 6th. We just went to this semester’s senior show to get ideas and what we want to do, and I found a few ideas that I think may be really fun. I hope to see you at one of these events, and I know the others in the group would be happy to see you as well.

Over this entire semester we have worked hard and we feel confident in what we have accomplished. The artists have worked hard and the game looks great. The programmers have helped the art take flight, quite literally in the point of Kaia, and have breathed life into the game. Being a part of this game has made me very happy. I worked on the lighting of the game and with the help of the artists we have given some very interesting light to the game. Over the next semester I will be working closely with the art team to get the lighting to be what we want for the game. Some of us are taking a short break for about a month to relax and unwind during our winterm, the semester that happens between the fall and spring semesters. Some of us will be working hard through that month to get a head start on the next sprint.We all are thankful for those of you who have been following our progress from the very start, and welcome those who are just starting to check out our funny little owl game. Your support means so much to us, thank you for all that you do. Overall I would like to wish everyone Happy Holidays from Strix Studios, we’ll see you again real soon.

Animations Blog

Hey!  Here’s an update on where we are at with the animations.  As of right now the only thing we have fully modeled is Kaia herself.  It took a little bit of hard work but I think I now have a good understanding of how I want Kaia herself to move.
I’ll be going over the research I did to bring this character to life.

To start I had to give Kaia her bones and controls so that I could move her anatomy just like an ordinary owl.  This process is called “rigging” and it takes a lot of time to get it right.  To keep it simple I’ll give you some pictures of the progress.

kaianorigHere she is looking so pretty. Now let’s take a look underneath the skin. 

CaptureEwww Gross!  I know right but this is necessary to make the character move.  I know it’s hard to see but each one of those small points is a bone, 98 to be exact.  Each one influences a piece of the Kaia’s body.  Once this was done we need to add controls to the bones cause no one in their right mind would want to move 98 separate bones.  That’s just crazy.  

w.controlsThere we go. So we took away the bones and now you can see only 28 controls.  Each one does something different.  I put a lot of control for the feathers because the animators like it when the controls are well designed and best suited for the type of animating you are doing.

Now to animate this thing I first had to become the owl.  So for a whole day I spent acting out how I would think an curious owl would.  Owls can’t move their eyes so if I wanted to look at something I had to move my entire head.  And if I wanted to move somewhere I would crouch down in a little ball and act it out.  If you think I would be crazy enough to do this in front of everyone you’re right!  We animators are pretty crazy but we have to get in character so that the animations reflect how we want them to feel.  During this time I also looked for inspiration on the internet from owls running in slow motion to watching the movie “Owls of Ga’hoole” like 13 times.  Great movie by the way.

So when you are making a game character you have a list of all the different animations you need to complete for each type of input you want your character to have.  I started with the most important ones so that the game would be playable as of right now.  That consisted of running, idle, jump, double jump, and glide.  There are many more that I have yet to do but I wanted to share with you what I have done so far.  

I hope that you are looking forward to the game cause I can’t wait either.  Right now I’m trying to figure out how an owl would swim underwater!  I’ll update you on that once I get it done.  Thanks for checking in and stay tuned for more!