Creating Good Level Design Documents


When making levels for a game it is important to document your ideas, this way if your on a team everyone is on the same page and if your working by yourself you have something to work off of. A one page level design document can make the process of creating a level much easier. The methods that I am going to discuss have worked well for me but like anything in agile game development none of these rules are set in stone.

Level Drawing:

The first thing I like to do is make an illustration of the level this can be done in any program you prefer such as: Photoshop, Adobe Illustrator, or even Google Docs. If you have created a concept sketch digitizing that will make the process easier. It’s important to remember that if your level is 3D then you are making a 2D drawing to represent it, this can lead to confusion. In the cases where I have intricate 3D levels I like to have a top down drawing and a side drawing, this will help anyone else who sees the document understand the space. Once the drawing of the level is complete I like to draw arrows to the most important parts of the level and have boxes of text explaining any special mechanics that happen in those areas. If you document is for a single player level it is important to make a golden path. The golden path is the most ideal path a player can take to complete a level. Multiplayer levels do not have golden paths because where the player needs to go changes as the match progresses. The last thing you need once your drawing is complete is to make a key to show what certain symbols represent.

Asset List:

Another important thing you need to have in a level design document is a asset list, this is a list of every art and sound asset that the level will need to be completed. This is very helpful if you are working with artists and other designers. The list will also give you an idea about how long it will take to complete making the level.


Level design documentation is very important if you are working on a team but it can also help you if your working by yourself. When making a level design document remember that no matter how good of a level idea you have it does not matter if your document is not readable.

Sound Design

This week I started working on the sound design for Space Dunk, I am not in charge of making the music but rather all the sounds effects. The sound effects in a game give the players vital feedback that they can’t necessarily get from just visuals. The sounds in the game need to accompany each interaction however it is easy to add too many sound effects and then the player will be overwhelmed. The hardest part about sound design is finding the happy medium between too much sound and not enough sound. I started this process by making a list of all the sounds we need for the game. I separated the sound into three groups: Crowd Noise, Announcer Lines, and Game play Sounds. The crowd noise is cheering and chants that you would encounter at a sporting event, these noises are essential to help immerse the player. The Announcer sounds are also used to help immerse the player but it also gives the player feedback when someone scores a point. The sounds that give the players the most feedback are Game play sounds, these sounds are what is played when there is any interaction between players. Instead of finding samples to use I am planning on recording my voice and using synths to make all the sounds. Once all the sounds are recorded I will begin mastering them so that the volume levels on all the sounds are appropriate. Sound design is a lot like programming, it requires you to keep making tiny changes until something feels right. Sound is one of the most important aspects of a game, it gives the player feedback and also helps make the world you create feel more alive.

Creating Level Concepts

This week I have been working on creating as many concepts as possible for potential arenas for the game Space Dunk. This process is one of my favorite aspects of game design because it allows me to flex my creative muscles and create a compelling environment for the player to explore. I wanted to use this blog post to give some insight into my process and hopefully help someone else who is stuck in the concept stage.

Starting Out:

When starting out a new level there are a lot of things to think about and this can get very overwhelming. The first thing I like to think about is: “What is this level teaching or emphasizing to the player” this gives me a jumping off point. When thinking about what the level is emphasizing to the player I don’t necessarily mean a set piece moment (although that can work too), but rather a primary game mechanic. One example of this in Space Dunk is a level concept I created that was made to emphasize passing the ball, passing is one of the primary mechanics in Space Dunk and by making a level centered around it I can help the players master this mechanic which will help them get better at the game. Once you have an idea about what you want your level to emphasize the next step is to begin sketching.

Drawing Your Level Concept:

I like to sketch out my ideas before I make a digital version, I find it easier to get all my ideas out. The most important thing I can tell you about drawing level design concepts is: do not be afraid to start over if an idea isn’t working out, that’s the beauty of sketching things out, its supposed to be quick and rough. However if you do end up starting over NEVER throw away your old design, even if you hate it. It always good to keep things around to inspire you later or just to remind yourself what NOT to do. It’s not important for the sketch to look nice, I am not very good at drawing but this step allows you to just put down as many ideas as possible as quickly as possible.


The last step is to show it to your group members to get feedback before you continue forward. If your working by yourself show it to someone who plays games. I have always found it useful to get a second pair of eyes to look at something, sometimes they notice something obvious that you have overlooked. Once you are happy with your level concept it is time to move on to making a Level Design Document and then blocking out the level.

Space Dunk Initial Blog Post

This week I returned to Champlain College for my final semester, last semester I worked on a game that was cut and now I have joined a new team working on a game called Space Dunk. Space Dunk is a first person competitive multiplayer sports game that takes place in zero gravity arenas. The Space Dunk team asked me to join them to help them create more levels. During this first week we met and talked about what the teams goals for this semester are and what they wanted the new members to focus on. We discussed each of the mechanics that are already implemented and then talked about what mechanics we wanted to add this semester. I spent a lot of time this week doing research into different sports to help inspire my level design. The first thing I did was research real sports like Golf, Football, and Basketball, I wanted to know what made these games compelling. I honestly don’t watch sports but I have several friends that love professional sports and I talked extensively with them. I also looked at other sports games that are not realistic like: Rocket League, Unreal Tournament’s Bombing Run game mode, and Griff ball.

I started conceptualizing a bunch of different ideas I have, at this point in the development process I just wanted to create as many ideas as possible. I showed the list of all the level concepts to the team and had them tell me which ones they liked the best. Now that the list is narrowed down I am going to start sketching out a few different concepts and try to figure out what assets each level will need. The team is in constant communication at this point in the process and its really exciting to see the excitement that everyone has for this project.

Korku Postmortem

Where We Started:

When we started making Korku we wanted to make a multiplayer FPS game where the players could customize their mech’s load out. We quickly realized that with the time we had available this idea was over scoped. We eventually settled on a cooperative player vs AI game. We wanted each of the two players to feel important so we tried several different ways to divide up the tasks that each player had to do. The second player was given a UAV to scout the area and a buffing mechanic to power up different parts of the mech. The first player controlled the mech and fired the main weapons. We also decided to have our game set during World War 1.

Where We Ended:

When we presented the game to the faculty we had come a long way. We had improved the second player’s mechanics to streamline their game play and allow them to be more active in combat. We gave the second player heavy weapons to give them a role in combat and cut the UAV mechanic. The biggest change for the second player was changing the buffing mechanic from its original puzzle based game play to a resource management mechanic. Through QA testing we balanced the weapons and got the shooting to feel right. We ended up cutting the customization mechanic from our original idea since it required a lot of art assets and we only had one artist. Our final level had the player destroying a convoy and escaping the area.

What I Learned:

The biggest lesson I learned this semester was the importance of communicating with my artists during level design. I had worked on level design before but it was by myself, this was the first experience I have had working with another person on a level. When creating our games level I would send the changes I made to my artist and he would give me feedback. The entire team agreed that this helped improve the level a lot. I really liked having a second pair of eyes on the level to help me make it feel populated and interesting. This is going to be a very useful lesson next semester because I am doing level design again for a different team and I will be working with the same artist from my old team. I also learned about the dangers of making a game with networking. We had the two players in our game connect to each other using a online network, this ended up causing a lot of problems for us. We did not realize how difficult it was to get a network working without bugs. We had problems testing due to networking issues and we also had network problems during our presentation to the faculty. Another lesson I learned that will be helpful next semester is ways to cut down on the amount of memory a level uses. My artist showed me ways to conserve memory which will be helpful next semester when I am creating levels and want to optimize them so they work on lower end computers.

What Went Wrong:

There were only a few things that went wrong this semester. The biggest thing that went wrong was our networking issues. Our game required a working network to play and when we presented to the faculty we had issues that caused our game not to work during the first play session. We got it working by the final play session but the damage was done, not everybody got to play it and it was clear that the issues left a bad taste in peoples mouths. The other big mistake we made was over scoping, our initial idea was really ambitious and we quickly realized that we needed to scope down. Once we took out the player vs player aspect we did not want to take out much more, however the game was still over scoped and I feel that we were worried about scoping down any more even though we should have.

What Went Right:

There were a lot of things that went right while creating this game. I had an amazing team working with me, everyone was always communicating and the meetings had a friendly atmosphere. Nobody in the team was afraid to speak their mind and everyone took critiques very well. The strength of our team was the reason we wanted to make Korku, we had two other potential ideas for games to make but even though Korku was the most ambitious we all loved mech games and we knew our team could pull it off. Another thing that went right this semester was our QA sessions, we went to QA at least once a week and got great feedback about the game. There were several testers that were super excited about our game and we were happy with the responses.

Joining a New Team

The Senior Capstone class at my college (Champlain College) is set up so that after the first semester half the teams working on games are cut and added to other teams who are also working on their own games. My team was unfortunately cut however I was given an offer to work on a game called Space Dunk.  The team liked the level design work I did on Korku and wanted me to do level design work for them, I accepted their offer but it got me thinking about what its like to join a new team and work on another persons creative property. I would like to use this blog post to talk about the integration process to hopefully give people in the same situation some ideas about where to start .

Meeting the Team:

The first meeting we had as a new team was very helpful, we talked about what the original members of the team wanted the new members to focus on. I had the advantage of going to class with many of the members of my new team so learning everybody’s name was easy. I asked the team to see their design documentation so that I could familiarize myself with the game systems, if I want to design good levels I need to know how the game works inside and out. After everyone was acquainted we decided to hang out as a group to get to know each other better. We went to a bar and talked for a while, it was a very friendly environment and I really recommend doing something similar to this (although it does not have to be in a bar). By meeting everyone in a non work environment it was easy to get to know each other without the pressure associated with a formal environment. The meeting was a very helpful way to get acquainted with the team and I am super excited to work with them further.

Adding Members:

I have had experience with getting new members on a team that I have been working with. The last game I worked on was originally a team of five and grew into a team of ten. The biggest tip I can give to teams that are getting new members is to be open to changes they want to make. New members of a team are always worried about making too many changes and stepping on the original team members toes, however a new set of eyes on a project can open up doors the original team did not even think about. Even if you don’t like an idea show them that you are grateful that they are trying to help make the best game that can be made, if you make someone feel uncomfortable about speaking early on they may not bring up good ideas later in the project.  When I had new members join my team last year I was worried that my vision for the game would be changed but I was pleasantly surprised with the awesome ideas they contributed to the game.  Working on new teams can be a scary experience but it will help you grow as a designer and as a teammate.

Designing Weapons

When designing a shooter game creating fun and interesting weapons is one of the most important parts of the design process.  The weapons are going to be used by the player for the entire play experience so they better be compelling and fun to use. When designing weapons there are a lot of details that need to be considered for example: how many weapons the player can hold at once, if the weapons have alternate fire modes, what kind of ammo does the weapon use, and how much damage it does.

Less is not always More:

There are a lot of things to take into consideration when deciding how many weapons the player can carry at once. There are advantages and disadvantages to each method and its important to pick the one that supports you game better. Many modern shooters (such as Halo, Call of Duty, Destiny, and Gears of War) limit the player to only a few weapons, this allows for a more realistic feel since in real life a person can only hold so many weapons. The limited weapon method also allows for more resource and choice driven game play, the player only has a few weapons so when they start to run low on ammo then they are forced to search for more or get rid of the weapon. The limited number of weapons also creates player choice since the player can’t hold the entire arsenal they have to make choices about what weapons they want to hold. The player may need certain weapons to get past certain areas so they are forced to drop a weapon they are holding. On the other side of the coin is letting the player hold the entire arsenal, this method was used a lot in older shooters (such as Doom, Half-life, and Quake). The advantages of allowing the player access to the entire arsenal is that it allows them the freedom to approach each combat situation the way they want to. The big draw back of this method is that it becomes very important to balance each weapon so nothing is too overpowered. Each of these methods can improve the experience of a shooter if its used in the right way.

Fire Modes:

When designing weapons one way to make the weapon more interesting is to give it multiple fire modes. This allows a weapon to have more versatility in combat. There are many games that have weapons with alternate fire modes such as: Bulletstorm, Unreal Tournament, and Painkiller. Different fire modes create the opportunity to make a weapon more memorable, or help compensate for the weapons short comings. In the game Unreal Tournament there is a weapon that shoots a fast beam projectile but the alternate fire shoots a slow moving ball, if the ball is shot by the primary fire the projectiles explode for extra area damage. The alternate fire does not need to be a different projectile, in the game Perfect Dark Zero there is a weapon that has an alt fire that turns it into a turret. Weapons with multiple fire modes give the player more options of how to deal with enemies and in a shooter the more ways the player has to deal with the enemies the longer they stay interested.

Weapon Design In KorKu:

The weapons in KorKu were designed around the level and the enemies. We wanted a long range weapon so I created a laser that had a slow rate of fire but had long range and high damage. The laser was the most popular weapon in testing due to its accuracy and damage. The other weapon the pilot has is the shotgun, this weapon has a high rate of fire but lower damage. This weapon was harder to aim but the spread allowed player to shoot multiple enemies at the same time. The second player had one weapon which was a heavy weapon on the shoulder. This weapon did the most damage but the projectile moved slow so the player had to lead their targets.  We designed this weapon to he harder to use but very satisfying when it was mastered. The cannon could kill any enemy in one shot but hitting that enemy was another story, this created a challenge for the second player to master in order to succeed in combat.

The Devil is in the Details

Designing games is one of the most fun things you can do, however many people don’t realize how many tiny details need to be tweaked and iterated on. One of the things that my team and I worked on a lot is the targeting reticle. A reticle is and UI element that is used in video games to show the player where they are aiming their weapons. The reticle may seem like a small detail but if the reticle does not read well the shooting will not feel as refined. It was a really interesting experience working on a reticle and I wanted to share it with all of you.


I decided to look into other shooter games to see how they handled their reticle design. The first games I looked at were other mech games such as the Mechwarrior series and Chromehounds. The biggest thing I gained from looking at games like this was that most of the reticles were designed to look like targeting systems that are found in modern fighter jets. The look in games like this is supposed to remind the player of military equipment, this is due to the fact that the game wants to give the experience of being in a futuristic military setting.  A lot of the more modern shooters have much more simple designs for their reticles. Many games want to keep the UI as minimal as possible to make their game more realistic.

Designing for Korku:

When designing the reticle for Korku my artist and I first started by talking about the kind of sights that would be found on WW 1 artillery. My artist created a bunch of different ideas for the reticle and as a group we discussed the pros and cons of each design.

img_20151111_165422_1024 This picture shows the first pass on the different reticles. The biggest complaint with our original reticle is that it was very large and did not feel like it was accurate. We quickly decided that each player would have a different reticle depending on what role they were playing (Pilot or Engineer). The pilots reticle ended up being the square one in the bottom row. Since the pilot had a shotgun we wanted something that showed where the spread was going to go. The final design for this reticle did not have the dots in it, we felt that the dots gave players the wrong idea about where each shot is going to go. The design that we picked for the engineers reticle is number 12, the engineer had heavy cannons as their weapons and we decided that we wanted a reticle that looked like an old artillery sight.  We made a few changes to the original design, we wanted the bottom of the reticle to come together like a V, the dot in the middle was where the bullets were going to go and player responded really well to it.


The biggest lesson I learned from designing a reticle is that the first thing to do is decide what kind of weapon the reticle is representing. If the weapon is very accurate you probably want a small reticle, if the weapon is futuristic you may want to help show that with the design of the reticle. The biggest thing to remember is that if the reticle does not read well the player will feel like the weapon is not very accurate. The reticle may seem like a small detail that will go unnoticed but its going to be something the player is looking at the entire time they are playing your game so it is important to make it interesting but also useful to the player.

Project Update

I have been using this blog to discuss different design practices based on what I was working on for my Senior Capstone game, this update will show where the game has gone from the beginning of the semester. The team I have been working with has been hard at work creating an interesting co-op mech experience that is as fun to play as it was to make.

Humble Beginnings:


The gif above shows the game at its earliest playable form, at this point in the project we had basic movement and shooting as well as the radar set up. This version of the game was pretty rough but it was just a proof of concept so most of the mechanics had not been developed yet.  As the game advanced we added a second player to the mech which created one of our biggest game mechanics. One of the biggest hurdles that we had to overcome was getting the shooting to feel satisfying, in this early build when the player aims the targeting reticle it moves around the screen as opposed to most FPS games where the reticle is locked and the entire screen moves when the player aims. When we finally got aiming feeling satisfying it felt like an entirely different game. The next big task the team needed to overcome was dividing up the tasks that each player will have to complete to be successful. We used QA testing to help us narrow down what the tasks could be and how to best divide them. We ended up taking the two most popular divisions and combined them together to make our current gameplay.

Bringing the Experience Together:

As the semester went on we started focusing on making changes to our established gameplay to make the game feel more interesting. One of our mechanics was a buffing system where the second player could route power to different systems in the mech to aid the first player in combat. The mechanic started out as a puzzle style game as you can see from the gif below.


The system was based around rotating arrows to direct power to the nodes (the squares with circles inside). We wanted the second player to focus more on combat so we decided to make the system more of a resource management system. This not only streamlined the gameplay for this mechanic but we also found through testing that it was more popular with the players.


The new buffing system was easier to understand and looked a lot cleaner. We spent a lot of time getting this system looking right and feeling right. I spent a lot of time at the end of the project balancing all the different buffs to make sure none of them were too strong or too weak.

Final Push:

In the weeks leading up to the final presentation the team was working on getting all the final tweaks into the game. I spent my time working on level design with my artist Kody. I was given a lot of objects that I could populate the world with to give it a more realistic feel.  I would make changes to the level and then I would send them to Kody of feedback, he would give me ideas about how to better use the play space. The picture below shows some of the feedback he would give me.


The communication between the art and design disciplines made making changes to the level easy, I also feel that it never hurts to have a second pair of eyes looking at a problem never hurts. We also added a lot of our art and animations in during our final push, this not only helped our game space feel more realistic but it also helped give the players more feedback. The team really came together in the last few weeks to make a product that everyone is really proud of.


Our game did not move forward into the next phase of senior production but we did come a very long way from our game’s humble beginnings. The team worked really hard on this game and I have a feeling that this is not the last time people will be hearing about Korku. Check out the gameplay video below to see what the final version of the game looked like.


Designing UI

While working on my Senior Capstone I have been doing a lot of work on designing UI. For anyone not familiar with game design lingo UI is short for User Interface, there are many things that can classified as UI but most of the time UI refers to any element that tells the player something about their stats for example: health bars, ammo counters, and speed gauges. There are many types of UI and deciding what type of UI to use depends on what kind of game experience you want the player to have. Designing UI may seem like an easy task but UI is one of the most important ways the player gets feedback so it is important that a game has clear UI that does not clutter up the screen.

Getting Started:

When starting to design UI the first thing I like to do is make a list of all the mechanics that require UI elements, this gives you an idea about how many different UI elements you are going to need. Once I have figured out what UI elements that I am going to need I organize them based on how important they are to player feedback. The image below is the list that I created with my artist for our co-op mech game, we made a list of what each player needed to see and organized it by importance.


When this list is complete I begin thinking about what type of UI will best fit each element. There has been a lot of research done on type of UI and currently it is accepted that there are four types of UI which are: Diegetic, Non-diegetic, Spacial, and Meta. Each of these types of UI are useful for different game play experiences and I will discuss what types of UI work better for different games.


Diegetic UI is a UI element that is in the game world (the player character would be able to see it) an excellent example of this is in the Dead Space games. The main characters health is displayed on his back so the player can always see it, all the other UI elements are also on the characters armor so the player can always see their stats but the screen is not cluttered by the UI. Diegetic UI works really well in horror games because it doesn’t clutter up the screen giving the player more room to see whats going on around them. Games that have a heavy focus on realism are also good choices for diegetic UI because the UI elements being visible to the character makes sense.


Non-diegetic UI is the most common form of UI and it refers to UI elements that only the player can see. A good example of non-diegetic UI is World of Warcraft. This form of UI is useful in FPS and RPG games since the player has a lot of stats to keep track of. Non-diegetic UI is good for player feedback because the player can always see what their health, ammo, and other stats are at. The drawback of this form of UI is that the screen can get cluttered if there are a lot of UI elements, it is very important to be aware of how much of the screen is devoted to the UI.

Spacial UI:

Spacial UI is a UI element that exists in the game world (like diegetic) but the player’s character does not see it, an example of this is in Left 4 Dead the player characters have outlines around them that can be seen through walls. Spacial UI is commonly used to complement other UI elements, like in Left 4 Dead the players heath, ammo, and equipment is Non-deigetic but the players are outlined using Spacial UI.


Meta UI are elements that are not spatially visualized for the player the most common form of meta UI is in the Call of Duty series the player has non-diegetic UI for their ammo and grenades but meta UI for their health (the screen gets covered with more and more blood the closer the player gets to death).


Once you have decided what form of UI you want and what systems need UI you can begin creating the UI assets. While working on my Senior Capstone I worked with my artist a lot creating UI elements that are easy to read and understand. Don’t feel like you are limited to a simple bar either there are many different ways to make interesting and unique UI elements. Remember that UI readability is the most important aspect of UI design, if the player can look at a UI element and not immediately know what it represents then you have done something wrong. Finally the last piece of advice I have is to not be afraid to combine UI elements from multiple UI types, many games have diegetic elements along with Meta elements. The beauty of game design is that there are no real rules just guidelines so feel free to explore when creating UI elements.