_____________________________________________________________________________________
Forest of Madness
Group 5, Unit Three project
Summary:
A cooperative tabletop game for two players trying to escape from a seemingly haunted forest. They must collect keys and then reach the exit, while struggling against the temptation of insanity. The game starts cooperative, but can turn into a player vs player depending on how the game goes. Players who enjoy either player vs player or cooperative play will find something that appeals to them here. Our target age range is from late teens to early 30s. Targeted player types are achiever, competitor, explorer, and joker.
Problems & Solutions
Once we settled on our current concept, everything went pretty smoothly with no major setbacks. However, we didn't settle on this concept until halfway through the development process. We spent a lot of time working on a completely different experience, called "Three Paths". It was an experiment in an entirely audio based game, with a very abstract and surreal objective.
The first playtest basically told us what we suspected anyways: players were very confused. No one really understood the objective, ourselves included. We misunderstood the requirements of this project, and thought we were given a great deal more freedom than we actually were. We still think it's a very cool concept, and plan on developing it further as a personal project, or returning to it in a later class.
The second playtest for this project went surprisingly well. Thanks to our clean and readable rule sheet (albiet with some minor errors), players were able to figure out the game very easily. Players were clearly having fun, and they were all able to finish the game successfully. The first group of players leaned more into the cooperative style of play. After they finished, we chatted with them to get their feedback. Our observations and feedback allowed us to to make a quick and much needed revision before the next group. The second group was a lot more fun to observe, but their feedback was not quite as useful. It was clear from the start that they had little interest in cooperating. They were having a good time already, but it was even better once one of them reached an insanity score of 3, turning the game into a player vs player style. Much of their feedback echoed the points raised by the first group. Observations and feedback from the playtest were immensely useful for revising the game.
Lessons Learned
Part of me is actually glad we spent the first few weeks working on something completely different. It allowed us to experiment with something bizarre, which was great for me since I am a bizarre individual. Even if that project was aiming for a completely different goal that the actual assignment, it allowed us to stretch and exercise our creativity. Experimentation is always great in my opinion, so I do not regret that part of the process. Since that first concept was entirely audio-based with no physical board, meeting in person seemed less crucial. We could theoretically do our work remotely, but it was not wise. The benefit of meeting face-to-face is immeasurable, even in projects where it's not strictly necessary. Group 5, Unit Three project
Summary:
A cooperative tabletop game for two players trying to escape from a seemingly haunted forest. They must collect keys and then reach the exit, while struggling against the temptation of insanity. The game starts cooperative, but can turn into a player vs player depending on how the game goes. Players who enjoy either player vs player or cooperative play will find something that appeals to them here. Our target age range is from late teens to early 30s. Targeted player types are achiever, competitor, explorer, and joker.
Problems & Solutions
Once we settled on our current concept, everything went pretty smoothly with no major setbacks. However, we didn't settle on this concept until halfway through the development process. We spent a lot of time working on a completely different experience, called "Three Paths". It was an experiment in an entirely audio based game, with a very abstract and surreal objective.
The first playtest basically told us what we suspected anyways: players were very confused. No one really understood the objective, ourselves included. We misunderstood the requirements of this project, and thought we were given a great deal more freedom than we actually were. We still think it's a very cool concept, and plan on developing it further as a personal project, or returning to it in a later class.
Once we got past that distraction, things were very easy. We looked back at ideas we brainstormed at the start of the process, and chose the one that would eventually become Forest of Madness. After solidifying the rules and procedures, we built a prototype and started playing. Playing the game gave us ideas for adjustments to make and elements to introduce. From there, it was a cycle of playing and
revising the game over and over until we refined the game into its current version.
The second playtest for this project went surprisingly well. Thanks to our clean and readable rule sheet (albiet with some minor errors), players were able to figure out the game very easily. Players were clearly having fun, and they were all able to finish the game successfully. The first group of players leaned more into the cooperative style of play. After they finished, we chatted with them to get their feedback. Our observations and feedback allowed us to to make a quick and much needed revision before the next group. The second group was a lot more fun to observe, but their feedback was not quite as useful. It was clear from the start that they had little interest in cooperating. They were having a good time already, but it was even better once one of them reached an insanity score of 3, turning the game into a player vs player style. Much of their feedback echoed the points raised by the first group. Observations and feedback from the playtest were immensely useful for revising the game.
Lessons Learned
_____________________________________________________________________________________
Protect the Herd
Group 1, Unit Two project.
Summary:
Play as a herd of dinosaurs migrating to reach your nesting grounds. Build a loadout of different dinosaur types to survive four rounds of randomized events and reunite with the other half of the herd.
Problems Encountered:
Our game’s development had some significant problems right from the start. Our prompt was to make a logic game, themed around dinosaurs, for ages 40 and up. We had no idea what to do with it. Dinosaurs naturally appeal more to kids than to adults, and we had some difficulty with finding a solution that emphasized logic. We were concerned that the game would drift into the strategy genre if we weren’t careful.
At the end of the first day, we still didn’t have a single coherent idea for the game. I did find an image of a dinosaur wearing a lab coat for inspiration, but it wasn’t very useful. My brainstorming approach was to spit out words stream-of-consciousness style until something sticks. Nothing did.
Before the next class meeting, we chatted with another group and bounced some ideas around. We came up with three ideas. One of them became Protect the Herd.
Now we had something to work with. We were still worried that the game didn’t have enough logic, but that problem seemed to solve itself with time. Once we played our first version, we started to see the logic in it.
The two playtest sessions yielded different kinds of results.
On the first day, we got to see our game played basically the right way. One of the testers had a harder time with our rule sheet, but his partner understood things and helped him out. The next group seemed a little unsure of themselves while playing but executed everything correctly. We observed them mistakenly drawing two extra cards at the start, but it didn’t affect how the game plays out. In fact, it made more sense that way, so we incorporated it into our new version. After finishing the game, one of them mentioned that he would have preferred having options to be competitive and harm the other player. The game is meant to be cooperative, so our solution was to emphasize teamwork instead of doing what he suggested. We were already talking about incorporating co-operative event cards, so this observation told us to comit to that path.
On the second day, we got to observe very confused people reading our rule sheet. We had just revised it for clarity, but apparently it made much less sense than before. The first group barely got to start playing the game before time ran out. When we actually got to observe the game, we discovered an issue that never came up in the previous groups: people who do not play Dungeons & Dragons do not know what is meant by “D4”, and we cannot assume that game design students (or 40+ year olds) play Dungeons & Dragons.
We placed two four-sided dice in the play area. The rule sheet listed a “Four-sided die” among the components, but the text on our event cards read “Take 1 d4 damage”. Nowhere did we explain the connection between the two. This caused a great deal of confusion. The first group had no idea what to think when they came across it. The second group interpreted it as “Take 1 damage”. They all ignored the dice on the table.
We never got a chance to see our new mechanic in play. This was likely the result of rushing things during the final steps. We already had the co-op cards working so that we could play with them, but updating the rule sheet deserved more time than we gave it.
Play as a herd of dinosaurs migrating to reach your nesting grounds. Build a loadout of different dinosaur types to survive four rounds of randomized events and reunite with the other half of the herd.Problems Encountered:
Our game’s development had some significant problems right from the start. Our prompt was to make a logic game, themed around dinosaurs, for ages 40 and up. We had no idea what to do with it. Dinosaurs naturally appeal more to kids than to adults, and we had some difficulty with finding a solution that emphasized logic. We were concerned that the game would drift into the strategy genre if we weren’t careful.
At the end of the first day, we still didn’t have a single coherent idea for the game. I did find an image of a dinosaur wearing a lab coat for inspiration, but it wasn’t very useful. My brainstorming approach was to spit out words stream-of-consciousness style until something sticks. Nothing did.
Before the next class meeting, we chatted with another group and bounced some ideas around. We came up with three ideas. One of them became Protect the Herd.
Now we had something to work with. We were still worried that the game didn’t have enough logic, but that problem seemed to solve itself with time. Once we played our first version, we started to see the logic in it.
The two playtest sessions yielded different kinds of results.
On the first day, we got to see our game played basically the right way. One of the testers had a harder time with our rule sheet, but his partner understood things and helped him out. The next group seemed a little unsure of themselves while playing but executed everything correctly. We observed them mistakenly drawing two extra cards at the start, but it didn’t affect how the game plays out. In fact, it made more sense that way, so we incorporated it into our new version. After finishing the game, one of them mentioned that he would have preferred having options to be competitive and harm the other player. The game is meant to be cooperative, so our solution was to emphasize teamwork instead of doing what he suggested. We were already talking about incorporating co-operative event cards, so this observation told us to comit to that path.
On the second day, we got to observe very confused people reading our rule sheet. We had just revised it for clarity, but apparently it made much less sense than before. The first group barely got to start playing the game before time ran out. When we actually got to observe the game, we discovered an issue that never came up in the previous groups: people who do not play Dungeons & Dragons do not know what is meant by “D4”, and we cannot assume that game design students (or 40+ year olds) play Dungeons & Dragons.
We placed two four-sided dice in the play area. The rule sheet listed a “Four-sided die” among the components, but the text on our event cards read “Take 1 d4 damage”. Nowhere did we explain the connection between the two. This caused a great deal of confusion. The first group had no idea what to think when they came across it. The second group interpreted it as “Take 1 damage”. They all ignored the dice on the table.
We never got a chance to see our new mechanic in play. This was likely the result of rushing things during the final steps. We already had the co-op cards working so that we could play with them, but updating the rule sheet deserved more time than we gave it.
_____________________________________________________________________________________
Pentataire
Group 4, Unit One project.
Summary:
This is a modification of solitaire that is very similar to the standard gamme, but with the addition of a fifth suit of cards. Cards in the fifth suit are wild, and can be moved around between columns regardless of the red/black pattern requirement. Like the other suits, they are sorted into their own pile in the end. This is targeted towards explorer and craftsman player types.
Problems & Revisions:
We tried a few different ways of implementing an expanded deck and settled on this solution because it seemed the best way to avoid creating impossible or frustrating scenarios.
The very first obstacle we encountered was that neither of us brought a deck of cards. That was easily solved by rushing to the campus store, buying a pack of index cards, and making our own deck. I drew the red cards, and Alex drew the black ones. Neither of us had any ideas yet, so we just started playing solitaire to see if that sparked any ideas. The first thing we tried was changing the arrangement of the play area (number of columns and cards in each column at the start) to see how it would affect the pacing. The first layout we tied had nine piles of three cards each, and a tenth column that starts empty. This made the game a lot faster and easier to start. The next step was to think of a mechanic that would slow the game down as it goes on. Our improvised deck helped us figure out what to do for the new mechanic.
When making the cards, I grabbed a pink highlighter and scribbled a heart or diamond in the corner of each card. Alex used a blue and green highlighter with no icon to indicate suit. Being able to immediately identify any given card seemed important, so we re-did these cards to follow the same standard. At this point, we got the idea of adding cards to the deck. We drew up two new suits: moons (red), and stars (black).
Our first iteration introduced two new suits, a red and a black. We continued tweaking the arrangement of the play area to tune the pacing. There needed to be a way to trim down the extra playtime added by a larger deck. Each playtest lasted about 20 minutes and ended in defeat. After testing some different arrangements, we concluded that the 78-card deck did not add much except for pain and time.
In our second version, we removed the 6th suit and made the 5th suit wild. There were specific rules for how these cards could be used. A wild could take the place of a red or a black card in the columns, but the original red/black pattern must be maintained. It was fun and we liked the idea, but it wasn’t working. All our playtests ran overtime and ended in impossible scenarios. We kept experimenting with the rules and column arrangement. Next, we added the rule that placing two wild cards in sequence would switch the red/black pattern for the column. Then we modified it so that using two wild cards gave players the option of switching the pattern but did not require it. I finished three successful games with these rules, but it was still taking too much time. Each of my games lasted about 30 minutes, and I had one defeat.
Once we got to the third version, things went very smoothly. Our testing led to the conclusion that the rules for wild cards were too restrictive and caused the game to break in unexpected ways. Our solution was to give players the ability to switch the color pattern using only one wild card. With this rule, the game took about 15 minutes to play.
Play-testing in class mainly highlighted problems with our rule sheet. It led to some amusing results but told us very little about the game itself. Our document spent too much time explaining the basic procedures of solitaire and did so in a confusing way. The first playtester I observed misunderstood
Reflection on development process:
Our development process was highly experimental, and it worked very well. Whenever we had an idea for a solution, we immediately tested it to see what we could learn from the experience. That way, bad ideas were identified quickly before wasting too much time on them. Once we found something that worked, we kept it and continued experimenting to make it better. We could have improved by doing more research throughout the process. When we first decided to add suits to the deck, we thought it was so clever and original. Turns out it’s been done before, and we didn’t learn about it until our rule sheet was almost finished. We also could have been more experimental than we were. Once we settled on expanding the deck, we stopped considering other options. In the future, I would like to put more thought into the changes being made to the game.
