We brainstormed 14 potential ideas for our next game. The majority of the games were focused on creating local based games and we were researching if our brainstormed games have been created in the past. Over the weekend the group was assigned to brainstorm and bring in new ideas for the next week. The methods we used were paper jams, talking about what we liked about our favorite games, talking about what we disliked and how we could improve those games, looking into the core of a certain games within genres, physical activities we played in the past, and researching other local based games.
We looked into successful franchises such as rock band, Nintendo, Guitar Hero, Dance Dance Revolution, Wario Ware, etc. The reason why we looked into these franchises was because they were playing the game locally. We grew up with these couch games and had fond memories of playing them. The thought of playing together in one room was an experience we wanted to portray to our players.
As a group, we found a research study about multiplayer games. The study was researching if players were more competitive or cooperative. In the research they found out that the older the player, the less competitive they were. We had to consider who our audience and we found this study to be helpful information.
The next week consists of a pitching to our instructor. We had two plans, if one of our pitches was approved, we would continue working on that game. If the game was denied, we would continue brainstorming and pitch new games to our instructor on the first day of class.
The reason why we put HumaniTsunami on hold was because our instructors asked us to find the core of our game and we were unable to discover the core. Within the last week, we looked for 20 other games that are similar to the game, and find what made our game unique. The core makes the whole experience of the game and what our intentions were for the audience to take away from playing the game. The core that we found was the level design, destruction in the world, and exploration. Our core didn’t seem strong enough and we felt like our game wasn’t able to be completed in time. During the past couple of weeks we ran into technical issues, constant reiterations, and availability to meet together at the same time. Before we had to show our instructor a prototype, we made a decision to put HumaniTsunami on hold.
When the producers of JDE came together to decide on a schedule for the summer, they decided that a submission to the IGF would be the ideal goal for games that we created. Now, the IGF is not the definitive end goal for JDE. In fact, if our games don’t end up as IGF submissions, it will not be the end of the world. However, the producers believed that having it as a goal would be important in ensuring members were focused and had something to look forward to. Initially, the producers wanted to have the majority of the chosen game (at least the alpha) to be completed by the IGF submission deadline, Oct. 26. However, as time went on and the schedule for the JDE changed for the summer, so did our expectations and planned deliverables. Instead of having the alpha completed by submission, a vertical slice for our games would be completed instead. The producers believed that this was way more realistic since our teams split up to work on two games instead of one large game.
For Snow Angel, we decided that our vertical slice would consist of 5 distinct levels. Typically, a vertical slice is a demo of the game and consists of one completed and polished level. However, because our levels are much lake that of Super Meat Boy, which are relatively short and focus on introducing and testing one mechanic, we decided that 5 was realistic goal to achieve. Initially, we thought 10 levels would be appropriate, but quickly realized that it would probably be unachievable given our current timeline. Thus, we wanted 5 levels that represented the typical flow of our game. They break down like so:
- Level 1: Tutorial (Breaking down the basic structure of the game and introducing players to placing platforms)
- Level 2: Introduction to ramps (In addition to adding standard ice blocks, players will learn to change their upward direction via ramps)
- Level 3: Introduction to bouncy blocks (Players are introduced to blocks that allow the player to drastically change their forward momentum)
- Level 4: Introduction to changing direction (Players are introduced to blocks that allow the player to change direction)
- level 5: Mini-Boss (Now that the player has been introduced to the core mechanics of the game, they must use them in tandem in order to conquer the level).
While deciding on a art style for Snow Angel we went through a number of revisions. However, the one thing that became clear as we began working on the game was that we wanted our environments, characters, and aesthetic to evoke the same feelings that a player got from playing classic platformers, like Mario and Sonic. Back in the old days, characters were created to be visually distinct and different from one another. This served a number of different of purposes, all generally beneficial to the game and its characters. The first purpose was creating a visually distinct character allowed the character and the game they inhibited to stand out from the crowd. Furthermore, the focus on a primary character allowed said character to be more relatable and important to the player. Finally, from a purely mechanical perspective, it made the character easy to distinguish when playing, making the game more approachable and fun. At our first pass at the game, we did a pretty good job of making a distinguishable character in the form of a baby penguin:
Now, for the purposes of a game jam, this did a pretty good job of helping the player understand their role in the world, as a crying baby penguin (even from large distances), is easy to spot. However, after we had time to look at our game outside of the jam, we realized that while the character was nice looking, it ultimately did not completely serve the purpose we had intended: to create a iconic character. After all, while a baby penguin is easy to spot, it is still a standard penguin. Therefore, we brainstormed on ways to improve the initial design.
Here is a rough draft of what we were thinking. We thought that we needed to make the art more exaggerated, wild, and slightly chibi. After all, we were not making anything resembling a realistic penguin game, so it was only natural that we go a little wild with the design of the character.
Here is the current penguin, which we have named Ziggy. Now, this is clearly without his crazy hair and backpack, but the differences between the original and the updated version are clear, as Ziggy is more rounded and even cuter. With additional changes (additions to his overall style), we eventually hope to achieve an iconic player character.
This week we decided to finalize our level blockout and change how our level looked. Originally, we were planning to have the level be made as a low poly terrain, until we found out that hexagonal terrain stands out and doesn’t blend with our assets. It looked better than how we originally planned and shifted our level design to be made out of hexagonal pieces. After we completed the level design for one portion of the map, we discussed that the map would be too large. Since one region of the map was too big, it would have been a huge map if we added the other two regions. Since we were restricted on time, we decided to have that one region layout as the entire map. That one region would be split into the three regions that we originally planned (Jungle, Boneyard, and Tar Pit).
Near the end of the week, the basic animations and our character models were completed. We were also designing on how the regions will be split in the level to create an unique experience that allows the player to explore through the level. After finalizing where the regions go, we will be adding the quests and environmental assets into the game. Since we made the hexagonal level change, our programmers were looking into how the player can navigate through the level.
Developers always need time to spend away from computers. Here at JDE, we occasionally take various field trips across Chicago. While JDE is primarily focused on making games, excursions away from games helps to cleanse our creative palates and allow us to come back rejuvenated and ready to look at games from a whole new perspective. After many weeks, the producers decided on sending the team to Chinatown Chicago as a field trip. This past week was spent on reflecting on our current progress into the JDE, as well as determining how we move forward as a group. Therefore, we thought it would be important to take the team to Chinatown and learn about the history of this location, as it would serve to both bring the team together (through bonding exercises) as well as lead the team into a discussion into where they wanted to see use move forward.
“In our Chinatown field trip, we were assigned to look into two leaders that helped create Chinatown. We weren’t inspired with any ideas from learning about the two leaders but it allowed us to start a conversation. The majority of the trip was walking around Chinatown and group bonding. Although we didn’t learn much, it allowed the group to get to know each other more. It created a relaxed environment for us and was a fantastic way for us to go out and get some fresh air. After we returned from Chinatown, we did a mid-mortem reflection on how the program was going. We discussed our issues, concerns, and suggestions in ways to improve the program. I personally enjoyed this field trip and am looking forward to the future field trips.” – Daniel
While Designing levels for Snow Angel, we do so as one large group instead of assigning one person to design each level. We do this for a number of reasons, the biggest being that it allows us to quickly bounce ideas back and forth with each other (including iterations and additions) and gives each team member a voice when making the game. Furthermore, it helps each member of the team stay on the same track and know exactly what they should be working in. We typically go through the following process when creating levels:
- Brainstorm potential additions/interesting ideas for a level. We brainstorm as a team, using a whiteboard, paper, and generally a computer to bring up examples of games or ideas that inspire us. Furthermore, we then breakdown how we think the level will play out (creating a rough draft on a white board).
- After creating a rough draft of our level idea, we go ahead and discuss any changes we want to make (in terms of how easy or difficult the level will be and in terms of what is realistic in terms of production). This process takes the most time, as we want to make sure the level is balanced and is fun to play.
- After deciding on a basic level composition that we will use, we then highlight the various obstacles in the level as well as what the player will do to proceed through the level. For example, I would draw a dotted box to indicate I would place a platform in that location to proceed. We use various symbols to help us reference later when we go about implementation levels.
- With the level composition completed, we then go ahead and break down new assets that are needed for that level. For each level, we only add a list of new scripts, art, and sounds needed. The list pertains only for that level, which helps breakdown workflow for each level. We also use the highlighted object we created in the previous step to help demote where that new asset would be located.
- After creating a list of assets, we (or at least I know I do) “wizard of oz” the level. Basically, I act out the level with my team until everyone understands exactly how the level will work. This is helpful for a number of reasons. First of all, it helps get everyone on the same page, as we only stop acting the level out once everyone understands how the level works. Acting it out also helps everyone remember the intended behavior of character and player.
The designers of the JDE had the opportunity to talk to industry veterans who were also Founders of the former DGE. One of them, Patrick Curry, is a current developer at Unity who gave a lot of insight from his time at DePaul University. Since Patrick has so much experience, Sam, Andy, and I spent our afternoon doing a Skype call with him about the DGE to now.
Lets start with a little about him. Patrick Curry was an employee at DePaul who overlooked the first two DGEs at DePaul. The first DGE was supposed to be a one time thing with the university, Devil’s Tuning Fork. Because the team had so much success and was able to showcase their game at IGF, the school decided to go a second round. This soon led to Octodad, a comedic like adventure that made DePaul what it is today. Once this was done, Patrick Curry and the co founder Alex Seropian left DePaul to come back into the industry.
Going to Bit Bash this year was incredibly useful as a fellow designer and producer of games. The biggest thing that stuck out to me was the focus on couch co-op games. From Regular Human Basketball to Pocket Rumble, we are, at least in the Chicago scene, are seeing a renaissance of sorts in terms of local play games. Even more astounding than a focus on local co-op is the clear dedication to simple, but fun mechanics. Now, a cynic may say that this dedication to simplicity has its roots in the fact that many people at Bit Bash were casual gamers, who were more interested in having a good time then experiencing deep, layered mechanics. However, I would say that this laser focus on the basics allows a team of developers to hang their hats on thoughtful design and smart choices, rather than unnecessary flash and a retread of the past in a different skin. This is a lesson I hope to take with us as we continue to work on our games. Below are some games that really caught my eye while at Bit Bash.
After a week of designing the gameplay of Humani Tsunami, we decided to do a Prehistoric Level for our Vertical Slice. We as a team had to decide on how the terrain would work for the player with our game. The original gameplay consisted of geometric box like terrain, but the question was how it would work with our mechanics. In the original build, the player were only able to do the Humani Tsunami, aka basic hoard movement. Within the last week and feedback from the Public Showcase, we decided to flesh out the player more and have it do more abilities.
Since we’ve created new abilities, there came the question on how to implement abilities cohesively with the terrain. Since we have 4 main abilities within the game, each have different movements and area radius of what it can affect. The Tornado swirls in the sky while the Earthquake trembles the ground. In Humani Tsuanmi’s Prototype, we have Vertical Terrain making abilities a little more complicated. We talked a lot about if we used the Tornado ability on a vertical terrain and how would it would work with programming. We’ve come to a wall with trying to figure out how this would work development wise. We even invited tutors and developers in the Chicago land to try solving this problem. In the end, we found out every solution would be complicated.
We soon asked ourselves if we actually needed the steep vertical terrain. In reality we didn’t because it was just an aesthetic for visuals. Towards the end of the week, we decided to decrease vertical height and add ramps instead. This made things reasonable for the abilities we had and also made programming less complicated. We then used the original concept art for our block out and revamped it one last time.
Humani Tsunami has gone through a lot of design pitches and phases to flesh the gameplay out. The original concept was just destroying objects in this geometric like world, but it seemed too similar to mobile games and other hoard based mechanics. We decided as a team, that we should try making less about destroying and more about the people within the game. People in the team proposed that it should be gory and demolishing worlds while others pitched that it should be narrative like telling a story.
What we forgot to talk about was why the player is doing stuff in Humani Tsunami. We kept thinking about the wrap, but the core reason why there is a Humani in our game. This was a tough challenge to face since some people in the team are currently out of the city doing internships. Instead of brainstorming on the extras for our game, we spent hours talking about why the player is actually doing stuff. Were the Humani trying to do good or bad things in the game? Were there moral based decisions the player had to decide? Is a story needed? Soon we came to the concept of Noah’s Ark from the Bible and how he saved all the animals from a horrid fluid. We thought that’d be something that can work so instead of destroying the world, we would be saving its inhabitants while indirectly destroying whats happening.
This game soon became the idea of Humani Tsunami seeing a vision on how Earth is in danger, so they send out people to save inhabitants over time. Thus being the reason why dinosaurs went instinct. The game soon became the an easter egg like exploration where you venture out across the world and affecting its people.
Snow Angel is a game about guiding and protecting a baby penguin from the dangers of the outside world. Controlling a benevolent “Snow Angel”, players manipulate the environment, placing platforms and other obstacles to ensure the baby penguin makes it home in one piece. The game is inspired by classic games like Lemmings and Super Mario. It blends together the reflexive nature of platforms while focusing on environmental manipulation and quick thinking that makes games like Lemmings such a joy to play. The twist of Snow Angel, however, is that unlike traditional platforms, the player has no direct control over their character. Instead, they must manipulate the environment and place platforms to alter their character’s behavior (speed, location, ect.) and avoid obstacles along the way. Below is a screenshot of the game:
As you can see, Snow Angel is a 2D game. Using the mouse, players place various platforms (in this case, a ramp) that alters the path and behavior of the penguin. In the case of the ramp, the penguin moves the penguin upwards, which is useful for avoiding pits and dodging spikes located on platforms. While a relatively simple idea, the game is built on this core: at manipulating the environment at the right time. Additional levels push this core to its limit and additional blocks also help to push this point home.