Design Journal: DOOM

This is the first of a series of design journal entries I plan on posting online. My goal is to talk about my observations (both design and general) after playing a game. I will talk about things that I thought were noteworthy or thought provoking. I will also talk about what worked (for me), what did not work, and what I would have tried to do differently. These posts are designed to be quick and to the point so that I can cover a breadth of games.

Summary: DOOM’s focus on nurturing a smooth core game loop keeps the player engaged and often fulfills the power fantasy it promises. Its levels incorporate loops and verticality to encourage the player to keep moving, which gets more fun as the player’s arsenal grows. The enemies are designed to challenge the player in unique ways, encouraging a change in weaponry depending on the current circumstance. When the player is in need of health or ammo the game avoids pauses by rewarding glory and chainsaw kills with health and ammo, keeping the player in flow.

As a newcomer to the series, the first level of DOOM felt like I was playing a single player campaign on a multiplayer map. The level design was not linear and had no clear destination due to the primary objective of eliminating all demons in the area. I found myself lost and confused, especially during a moment where I could not find the last demon remaining in the area. As my arsenal grew however, I began to see the reason why the levels were structured this way. The levels practically scream at the player to keep moving due to their lack of dead ends and looping structure. When I say looping structure I don’t mean the level ends where it began, I mean that individual sections of the level are designed using loops and those larger sections are connected mostly linearly with one another.

Looking back, I think what caused my discomfort during the first level of DOOM was my limited selection of weapons. Since my tools were a weak pistol and the combat shotgun with limited ammo, I often found myself charging up to a demon and melee hitting them, which does little help if they haven’t already been damaged into their vulnerable state. My expectation from standard FPS games was that if I could get close enough to a grunt to melee it would be an instant kill or at least a decent knock back. This was not the case, and my unmet expectation resulted in confusion and dissonance with the game. To try and avoid this, I would have introduced the chainsaw earlier so that the player would feel more comfortable getting up close to enemies when they have no other alternative.

As my arsenal grew however, my enjoyment with the game grew with it. With so many weapons, I found myself knowing which tool I liked using for which enemy. I switched between them seamlessly since their order became ingrained in my memory. It has a nice flow to it and it makes me feel like a super soldier. The chainsaw mechanic does a fantastic job of merging the need for resupplying with a game loop that relies so heavily on constant mobility. This mechanic keeps the player in flow during combat, allowing for each combat encounter to be smooth and exhilarating from beginning to end.

Finally, one of my favorite mechanics in the game was how a weapon’s final upgrade is a challenge instead of a resource cost. This gives the player a fun secondary objective to focus on during combat and helps them master the skills required for that weapon. However, I think the feedback on your progress with those weapons is poorly communicated as I often forgot what the quest for a weapon was or how far I had gotten in it. This was mostly caused by the large quantity of weapons available. I think a small HUD tool-tip that displays when you switch to a weapon with an active quest would be enough to remind the player of its existence.

Other features I found interesting: The use of green lights to indicate what ledges you can climb up on. The use of colored keys and doors to break up levels into smaller objectives which force you to explore the environment. Secondary objectives in each level reward the player for changing up their play style by achieving more difficult glory kills or finding collectibles.

Remembering to play my own game

As I work with my team to wrap up and ship Among the Clouds, I want to share something I learned over these last few months.

Summary: I made the mistake of not playing my own game once the development cycle shifted from prototyping to full development. I learned the importance of finding and maintaining the fun of my game at all stages of development. The benefits include having a more accurate picture of where the game needs to go next, receiving better playtest data since you are not getting bogged down with surface level feedback, and allowing for more meaningful polish when reaching the end of development.

There is a big difference between testing your game while you are working on implementation and actually sitting down to play your own game with the goal of having fun. One of the many things I have learned this semester is to ensure that the fun I found during the pre-production stage is not forgotten over the course of development. This is what happened this last year when, after deciding on the vision of our game, my team and I stopped playing our own game until it a few weeks ago when it was nearly complete.

During pre-production, when working on finding the original vision for the game, one of the things I was in charge of was to have every member of the team play the game for a few minutes a week and provide feedback as to if they liked the direction the game was going and what they would like to see in the future. However, this stopped being a priority once we transitioned over from the prototyping stage to the implementation stage. The difference was in my mentality. My priority from that point on was to get the prototype from Unity transferred over to our new custom engine as quickly as possible (before deadlines). It was not until recent weeks where I noticed that I had not actually played my own game in months.

What triggered this realization was that we were having trouble getting good feedback from playtesting because the game was basically unplayable. I attributed this to all the game’s missing features and it being incomplete. I was wrong. The problem was that I was building the mechanics we knew had potential from our prototype and immediately moving on to implementing the next part of the game. The missing step there was not taking a day to play with that feature and make sure the usability was out of the way so we could test how fun it was.

What surprised me the most once I started playing my own game was how many of the issues blocking the player from having fun were simple fixes that took no more than 10 minutes a piece. So many of the things stopping the robot player, who’s goal is to blend in to the crowd, from hiding were little bugs or tweeks such as the movement speed and misplaced AI waypoints. Those quick little changes were what had been holding back the playtesting data to the surface level feedback rather than the more crucial feedback about what was actually fun or not fun in the game. It is the difference between having to explain away the state of the game and search through a lot of bug reports in my playtesting notes and being able to actually put our game in front of players and see how people interact with the game.

What I found most helpful when playing the game was to constantly ask myself, what is stopping me from beating my fellow designers and developers. If we can get the game to the point where I can legitimately blend in and trick the other devs, then we can rest assured our playtesters have a chance at doing so as well.

One of my biggest takeaway from this year is that I should be in this mentality during every step of the process. It is so important to have the game I am working on remain playable at all stages of development. The best way to ensure my players have a chance at having fun is to play my own game, because if I cannot enjoy my own game, how can I expect my players to?

 

Learning From Prototypes

Coming up with a good game idea is hard. Especially when you want to get a whole team of people from different disciplines excited about it. This semester I joined a 16 person team consisting of seven developers, three designers, four artists, and two sound designers. After months of developing countless prototypes and taking part in almost weekly brainstorming sessions I have experienced some very successful strategies and some very disruptive mistakes. I want to share some of the things that I have learned during this ongoing project.

When your goal is to find a golden idea, the first thing that you have to accept is that every idea is flawed, and you cannot get attached to your personal favorite. Getting into this mindset is essential to making sure you are working efficiently. If every idea is flawed then your first priority should be to find out what the flaws of each idea are so that you know the hurdles you are going to face in the future before spending countless hours of valuable time on an idea that may not be fun or even possible.

There isn’t a universal way to prototype an idea. Each one is going to require a different approach. What is important is that you find the easiest way to create the core experience of the idea as quickly as possible. This could take the form of a quick example made in a pre-made engine like Unity, a paper prototype, or even a simple visualization of an example segment of gameplay. It is very easy to want to create a more holistic experience from the get go but in the end your energy would have been better spend moving on to the next idea and discovering what its flaws and potential gems are. I liked the way Kevin Sheehan, a DigiPen alumni, put it: If you are working on a prototype for more than four hours, you have moved on to its development stage not pre-production. This is because you should not be prototyping what you know you can make. You should be trying to build a sample of what you are unsure will work, so you can learn early if you are going to have to work around an issue or simply move on to a different idea.

At some point you have to stop prototyping ideas and select one to move on to development. You might find that one of the prototypes instantly stands out as “The One” and the choice is simple. But if you are working with a group of people, it might be more difficult to choose an idea that everyone will be happy with. This is where all the work you did prototyping comes in very handy. Now that you know which ideas have the most challenges to overcome you can narrow the choices down to the most realistic candidates. From there you can discuss each ideas potential and choose the one you are most excited to work on. Every group dynamic is different so how your team goes about this decision may be unique, however, there are some mistakes that I have made which are best to avoid.

The biggest mistake to make when deciding between multiple different game concepts is to break the idea down into chunks. We tried to drill controversial ideas down to singular mechanics or themes in order to see if we could merge the ones we liked or incorporate them into a different idea. This turns out to be catastrophic. The problem is that individual mechanics are rarely appealing when out of context. Talking about an idea’s individual aspects without the bigger picture will make it unappealing even to the original advocate and can really degrade the creative flow of the team.

If it comes down to a vote, what we found to be successful has been to vote for your top few out of the total and eliminating the idea with the least votes, then repeating the process. The reason why this tends to work well is because people are voting for the ideas they want to work on. If your favorite idea was eliminated, you still have the chance to vote for your second favorite in the next round.

Once an idea is selected, you have nailed down what the core experience you are trying to deliver is. It may not end up looking exactly like what you initially intended for, but everything you do from now on can focus on delivering what was promising about that initial concept. This not the end of prototypes for the project. Instead of prototyping overall game concepts, the same strategy can now be used for experimenting with individual mechanics within your game.

Lessons From My First Puzzle Game

Recently I submitted my frist puzzle game Directional for my Mental Challenge project in my GAT250 (2D Game Design 1) class. I had 5 weeks to make this project from start to end. Although the resulting game was simple, I learned so much from my first attempt at making a puzzle game. Download and try the game here if you haven’t done so already.

What is a Mental Challenge game?

A mental challenge game is a game who’s primary focus is to make the player think. While most games have mental challenge mixed in along with other forms of engagement, this project challenged us to make a game who’s primary engagement was mental challenge.

So the primary goal of the game was to make the player think and from there have them feel smart for overcoming the challenge you put before them. Due to limited time, I had to come up with an idea fast and get something up and running as soon as possible. I went through a few ideas but by the end of the week I had a game where the player would pick from a selection of directional tiles and tried to make his way to the yellow tile. This was a simple idea that was scoped appropriately for the 3-4 remaining weeks.

Before the game seen in the image above, the player was able to choose from 5 different tiles (as opposed to 2). The tiles could not be random because there would be no way of guaranteeing that there would be a path to the goal, so they had to be predetermined. This meant that I needed to make sure that the player was going to have exactly what they needed when they needed it, which resulted in a dull experience. To try and fix this I reduced the amount of selection the player had while still giving them a preview of the two upcoming tiles to allow them to plan ahead. This helped solve part of the problem because it meant that the player had less resources to work with, resulting in a more calculated use of tiles. However, the problem still remained that the player had exactly what they needed, when they needed it. From this problem emerged one of the most prominent mechanics: storing tiles.

Giving the player the ability to store one tile for future use was a positive addition to the game. This mechanic allowed me to not always give the player the correct tiles at the right time, and puts them in a situation where they have to decide which tiles they want to save for later and which they want to use now. This solved the big design problem I was dealing with and as a result the player felt smart when they figured out when to use and when to store tiles. Going through this process taught me an important lesson about puzzle games.

Lesson Learned

Giving the player different tools to interact with existing resources increased my opportunities as a designer to create interesting challenges.

This sounds simple, but in practice it is easily forgotten and is a useful thing to keep in mind. The more tools the player is given to interact with the resources in the environment, the more opportunities you will have to make interesting challenges. At the start, this game only gave the player one way to interact with the puzzle: select a tile. I tried adding additional mechanics to the environment like gates and switches, but they did not make the game much more interesting because they rarely changed the interactions the player had with the game. Adding the store tile mechanic gave the player more tools and therefor increased the opportunity to create rewarding challenge in the game.