Monthly Archives: November 2013

Post Mortem #3

Catacombs One Sheet

We just got done with our final pitch for Catacombs.  It went very well.  We decided to do a live, multiplayer demo of our game because it was so stable.  We used the main 80″ screen in the studio and found another 60″ screen for the second player and had them showing the point of view from each player so the audience could know what was going on.  Sean did a little play-by-play explanation of the game while Shane and I played it.  It went over very well and I am proud to have worked on such an amazing team.

Things we did well

One thing we did that I’m very proud of, is that we all were able to understand exactly what the game was going to be early on.  We were able to communicate effectively and respectfully to each other so we were able to work as a cohesive unit instead of a group of individuals.

Another thing we did well is that we set clear, weekly goals and we worked hard to hit those milestones in the time we gave to ourselves.  The first week we had to learn what we were capable of and because of this, we did have a late night, working well into the morning.  I think I had time to go home, shower, eat, and come back, ready for the pitch.  After that week, though, we got better and better about hitting our deadlines and using the time we had more efficiently.  I think that was due, in part, to that late night the first week.  None of us wanted to do that again.

Things that weren’t so good

It took us a while to bite off chewable sections of this project.  At first, when we asked everyone how long they thought it would take to finish a certain task, they responded that everything was possible, which isn’t true.  As stated above, we learned that lesson quickly and learned what we were capable of as a team.  This is probably something that every team has to go through in order to be effective, but I’m glad we learned that it was a problem so quickly.  It could have seriously effected the quality of the game if we did not learn quickly.


We made a design pivot mid-way through the build.  If you have read all the posts up to this point, you may remember that I didn’t want to do this again.  In this case, the pivot was both good and bad.  It was bad because we decided to drop one of my favorite features of the game because we didn’t have time to finish it.  The “trust” element of the game was something that we worked very hard on developing and was a major part of our pitch.  Without it, we weren’t sure how to sell the game.  Past that, it made the prototype better.  Since our resources were no longer spread out in an attempt to make this feature work, the rest of the game got stronger.  In this case, I’m glad we did it.  We found out that we didn’t need it to sell the game after all, and we made a much stronger showing with our live demo than we could have otherwise.


Thank you to the whole team for doing an amazing job and showing that a solid idea backed up by hard work will almost always pay off.


As much as we didn’t want this game to turn into “just” a cooperative, dungeon, puzzle-solver, we have decided (based on the time we have to finish the prototype) to lay aside the trust element of the game and create the best cooperative, dungeon, puzzle-solver we can in the time that we have.  After showing the game to the Executive Producers, and based on several play tests, we realized that the game was already pretty fun and that adding the trust element might muddy the waters of an already decent game.  Also, to do the concept justice, it would take far more time and thought than we currently have time for.  So over the next week we are going to work on the player experience.  We will try to make everything more clear and help the players navigate the game with as little instruction as possible.  Sadly, because of this, we will not be able to implement some already designed puzzle rooms.  That’s okay though.  They were interesting to create and I learned a lot about how to give the player an interesting multiplayer experience with simple mechanics.  I hope someday we will be able to use the designs, but for now, I’m happy with the direction we are going.

Puzzle Rooms

I’ve been doing a lot of research this week on puzzle rooms.  I’ve watched a lot of videos of Little Big Planet and Zelda and Antichamber and custom built Minecraft puzzles, but it turns out, the thing that helped me more than anything was the Leadership Reaction Course that can be found on Army bases across the country.  When I was in high school, our church group took a trip to Camp Williams in Utah and did the course which consists of obstacles that required teamwork and ingenuity to complete.  Generally passing one of the courses consisted of getting over a certain span of dirt or water that represented death and/or dismemberment using a limited amount of tools and man power.  In task #6, for example, your team needs to climb through one of two metal tubes with an ammo box and two planks.  You must place the planks on cement pillars to get the ammo box and the rest of your team from the tube to pillar to pillar to safety.  Task #6

I took this idea and tried to design a room that required the participation of both players and expanded on the idea of task #6 in the Leadership Reaction Course.

Pillar Level

As you can see, there are more pillars, fewer boards, and a couple of death traps.  The players start at the top of the room and one player takes the board and places it from the initial platform to the first pillar.  They walk out to the first pillar, turn around, pick up the board, turn back around, and place the board on the next pillar.  They make their way from pillar to pillar until they get to the red pillar and hit the first switch (Red lightning bolt).  When they hit that switch, the red pillar will begin to move down toward oblivion and the red platform will move up, making it possible for the second player to cross to the other side of the room.  The second player hits the second switch (Orange lightning bolt).  This switch raises the orange platform, allowing the first player to avoid death and the players can leave the room together.  I’m afraid now that I’ve told you the answer to this room, you can no longer play the game.  Sorry.

I’m going to try to design at least 2 more rooms for the prototype, we’ll see how much time we have to implement them.


It’s that time again.  Time to start a new prototype with a new set of constraints from the EP’s.  The requirements for this prototype are:

  1. Use an existing game engine tool like Unity, UDK, etc.
  2. Create the game for an indie audience
  3. Use an indie aesthetic
  4. Base the game on a random “lens” that the EP gives us

I guess I need to explain what a “lens” is in this context.  In the book “The Art of Game Design,” by Jesse Schell, the author teaches you to look at any game you design through a set of lenses in order to separate yourself from the project somewhat and look at it from another point of view.  Often when developing games or making movies or writing music or doing any large, creative process one begins to see only their favorite parts of the project and fails to see how the end user might interpret it or how it might affect the end user.  An example of these lenses is the one our group was assigned, the lens of Competition vs. Cooperation.  Schell advises that in order to use this lens you must look at the balance between competition and cooperation in your game.  He suggests that you use these questions to help in this process.

  1. If “1” is Competition and “10” is Cooperation, what number should my game get?
  2. Can I give players a choice whether to play cooperatively or competitively?
  3. Does my audience prefer competition, cooperation, or a mix?
  4. Is my team competition something that makes sense for my game?  Is my game more fun with team competition, or with solo competition?

As a group we decided that instead of creating a game that was on one side of the Competition vs. Cooperation scale or the other, we wanted to attempt to make a game that was equal parts, or a 5 on the scale.  This choice was likely not the wisest decision due to the difficulty of deciding exactly how to make an equally competitive and cooperative video game.  But the idea intrigued us so much that we couldn’t help ourselves.  We spent all of the first day just trying to figure out what in the world a game like that would look like.  Even then, we had some major problems with trying to develop trust between the players while convincing each player to work against the other at the same time.  Through much discussion, the following is what we came up with.

The game is a cooperative puzzle escape style game with two characters that start out locked in separate cells in the same room.  We’ll call the characters Red and Blue for ease of communication.  These characters must work together to escape their cells and then the room.  Red can only see clues and tools that relate to him and Blue can only see clues and tools that relate to him.  This creates a dependency on the other character since they won’t be able to escape without the clues and tools the other character has access to.

Along with the cooperative goal to escape the room, the players are presented with an alternate goal that conflicts with the first one.  A third character, whom we will call Green, will try to build mistrust between the other two characters.  At first, Green will send messages to both characters at once saying things like “Oh my goodness, how did you get in there?  Let me help you out,” as though he were looking at the other two characters on a video system.  Slowly Green will send messages to individual characters instead of both saying things like, “You can’t trust that other guy,” and “You’re never going to figure out how to get out.”  These comments will build in mistrust until Green says flat out, “He’s going to kill you!” and, “Kill him and I’ll let you out.”  During this time each character will find various pieces of a gun and when they have the whole gun, they will be able to kill the other person and win, or work together with the other person to win.  Depending on how much trust was built up between the players, they will choose one or the other.

We’ll see how it works.  There is definitely more to figure out, but we all love the idea behind it and I think the whole team is willing to put in a little extra work to make it work.


Post Mortem #2


First of all, thank you to the entire team for working so hard on this prototype.  We had a lot of problems along the way but you guys dealt with each one of them with strength and poise and we never lost our heads no matter how difficult it got.  Congratulations on a great prototype.

The last week of prototyping before fall break was, as you might imagine, jam-packed with all sorts of fun.  Some of the biggest problems involved our original selling point, gravity.  I may have mentioned this before, but when our main character collides with a dirt square, he digs.  When he falls, he collides and he digs and therefore, it was impossible to dig a straight, horizontal corridor because he would fall as you moved and make a sort of arc as you moved from one side to the other.  He also continued to dig any time you stopped.  We decided that we were running out of time to include this feature and we would much rather have a working game than a broken game with a single working feature that may or may not be fun.  So, like the original Dig Dug, we made the gravity affect only the rocks in the level rather than everything.  We also implemented a grid system so the character could create more narrow passages, increasing the chance that he will be able to squish the bad guys.  With these two changes, a scoring system, and a dragon that was far less formitible (he was almost impossible to beat originally), we were able to deliver a decent prototype to the executive producers.  It wasn’t exactly what we expected to deliver, but we delivered.

Most of the things that could have been done better came down to planning and communication.  We took far too long deciding on the technology we wanted to use to create the game.  Because of this, we wasted an entire week of work when the time frame was so short that we couldn’t spare a day.  More research early in the process on a tool that would serve our purposes best would have saved a lot of time in the long run.  Also, we had some problems understanding and expressing exactly what the game was, exactly.  Communicating what the game is needs to be one of our greatest skills, not one of our greatest weaknesses.  We’ll have to practice this one.

Some of the things we were able to do well was the implementation of project management software and keeping focused on the important features instead of getting caught up in unneccessary features or mistakes we may have made.  We used some online software called Trello for the first time during this project and, though it took some getting used to, we found it to be very helpful in keeping all of us accountable to the tasks we needed to perform.