Public Showcase Debrief

Hey everyone, Sam here to tell you about a recent public showcase we had for Gaze. This public showcase largely served as the last big playtest for the game. Being a capstone game, this showcase pretty much marks the end of major game development for the game (at least in the academic sense). While we certainly will continue to polish and refine the game as we continue to submit to prospective festivals, development will be rather limited as the team transitions from students to full time workers. All that being said, we were largely satisfied with the feedback and turnout of the public showcase. Our ultimate goal for the 6 months of capstone was to create a polished 10 minute puzzle platformer experience, and I believe we were largely able to accomplish this goal. Despite performance issues (frame rate dips when players respawn or collect one of the 3 stars needed to progress) and some issues with the stiffness of the controls, most players spent a prolonged time playing our game, which was definitely useful.

Moving forward, the previous mentioned issues (performance problems, stiffness of controls) will be what we focus on to truly make this game a portfolio piece. In addition, a problem that we didn’t realize occurred as players have difficulty even with the first couple of puzzles. While this maybe attributed to the fact that most of the people attended the showcase were non to casual gamers, it still shows tunnel vision on my part for making the game a little too difficult. Since most of our playtesters in our other tests tended to be typical gamers, it is hard to tell in what ways we can improve on accessibility and making this game easy to understand for even people on the more casual spectrum. Thus, we will take this new knowledge with us and do another round of re-designing our puzzles. We won’t make any drastic changes, but reflecting on what we have and in what we ways we can make our game as least frustrating as possible.

 

 

How to design the end?

An important, but often overlooked element in game production is designing and creating an ending. The reasons endings oftentimes feel underdeveloped or badly written is because endings (for the most part) are given the least amount of production time. After all, why spend time crafting the ending of the game when most players quit playing long before the ending? Thus, endings are one of the last things game developers work on. The same is true for our team. While we are only creating a vertical slice of a game, the ending is on the lowest end of the priority totem pole. The focus for us has been on creating an awesome experience, not with crafting a master class ending. However, keeping up with the tradition of KISS (Keep it Simple, Silly), we are using our scope and time restraints to deliver a simple, but thematically consistent ending.

starfoxending

As previously mentioned, the goal of our game is to collect 3 stars to revive a constellation. Now, we also have a basic theme that as the player collects stars, the world gradually becomes brighter and darkness enters the world. So, since we already had a basic but component intro (a simple aerial view of the sky with trees in the breeze with the title of game), it did not make a whole lot of sense to create a brand new ending screen when polishing the game is more important. Therefore, we cloned the intro screen as the ending screen. That may sound silly, but not only does it help with time constraints, it also helps with showing the players impact on the world. The intro screen is dark as light is muted without the constellations. So, by changing the lighting and adding the presence of the stars you, the player, have collected, the end acknowledges your impact on the world. It is a simple change, but it helps sell the player on their importance on the world. In addition, the demo is short, so a simple ending works in favor of this.

Core Puzzle Mechanics

Hey everyone, Sam here to talk to you about our core puzzle mechanics in the game. Of the many elements of the game, the puzzles have been one of the elements that has been constantly revised (whether it was drastic overhauls with different types of puzzles or with minor tweaks to playability). Initially, we had many different ideas on how we wanted to tackle the puzzles in our game (from having blocks that required multiple stars to moving doors). Eventually, we decided to focus on a few core elements that players found fun in play-tests, including: racing against a platform to catch up to it, trying to stay on a platform as it keeps moving, and climbing a huge tower. While these puzzles were received pretty well in playtests, problems became clear the more we playtested the game. The first problem that emerged was not in the puzzles themselves, but in how we laid out the level. We initially decided that it would be best to have players be able to play any puzzle in any order to foster a sense of exploration. However, this meant that puzzles were designed to all be relatively equal in terms of difficulty, which did not allow us to build upon previous levels or properly introduce mechanics to players.

modifers

The second problem that emerged was that the puzzles were not focused. While they did feature the player in a different scenario for each puzzle, the player was basically using the same set of strategies to overcome the puzzle, and the puzzles therefore felt somewhat similar. Additionally, the openness of each puzzle meant players would often lose track of their stars and that the difficulty of missing a jump often resulted in a great deal of lost progress. Thus, to counter these problems, we decided to pivot the core of the puzzle design into something simpler and easier to understand. Instead of focusing on different scenarios, we decided to focus on the 3 basic ways objects can be manipulated: transform, rotation, and scale. This allowed us to create more interesting puzzles that felt more focused that also built upon the knowledge that players had accumulated as they played. In addition, we changed the game from semi-linear to primarily linear to allow for our puzzles to build upon themselves. This has allowed players to actually be able to complete our puzzles and allowed for a lot more players to enjoy the game. KISS (Keep it simple, silly) continues to be a core way to streamline and improve our design.

Designing the Intro

Hey everyone, Sam here to tell you about how we are designing the intro (at least the non-interactive aspect) of our game. One of the problems with a designing only a small fraction of your game (be it a simple prototype or a vertical slice) is in choosing what information to convey to the player (both in terms of story you want to create and also in terms of instructions/tutorial). A game designer’s instinct might be to cram as much information as possible in your vertical slice. After all, the more jam packed your game is with content, the longer people will play it and want to replay it, right? Unfortunately, more content/information != players wanting to continue to play your game. In fact, the opposite tends to be true. Therefore, it is best practice to be very selective and smart about what you convey to your player. As some members of our team like to say, KISS (Keep it simple, silly).

Image result for kiss method

Not only is conveying too much information detrimental to the overall experience of the game, but it also takes away time that could better be spent polishing your game. Therefore, for the intro of our game, we were directly inspired by games like Orchids to Dusk (the game can be found here). Although the intro to that game is very simple (and the story conveyed is also very basic), it gives you all the necessary information you need to start and is very efficient with the information. Thus, instead of trying to convey the very intricate story we mentioned a few weeks ago we are going very minimalist and basic with our approach in order to tease a basic story, but not waste the player’s time. Furthermore, we are designing our demo in that matter as well, keeping things relatively short, so the demo does not become bloated. We would much rather have players want more than for them to lose interest and give up. Below are two examples of screens we plan to use (both are WIP that will be changed as we progress further in development). Tutorial-Example

Loading-Example

Sure, these are super basic, but can breeze through the information if they want to skip it and is not distracting to the overall experience. The second image gives you a little bit of insight into the story, but is deliberately vague and simple to both keep the flow going and to peak a player’s interest. Obviously, these will be fleshed out more as time goes on, but we would much rather design simple and to the point than make something that serves no purpose besides looking pretty.

Laying out the Lore

Hey everyone, Sam here to tell you a little bit about the lore of our game. One of the problems that emerged while working on this type of game was the need for some sort of basic lore in the game, as there were elements in our game that seemed out of place and did not mesh well. Those elements were primarily the platforms in the game. While players loved the general background art in the game, they were not fans of the platforms, which felt out of place with the environment (since they were pretty basic rectangles that feel inconsistent). Thus, we needed to detail the lore for the game way more to help us connect elements that did not match. After a lot of discussion, here is an excerpt of the lore we created:

“In our game, constellations are worshipped because of their ability to grant wishes. Constellations and stars are created by Artemis, goddess of nature, to handle fulfilling dreams for the people of Greece. During this time, Orion, a famed hunter with legendary exploits, wanted even the Gods to recognize his fame and started hunting down every creature in Greece. To protect the animals and teach Orion a lesson, Artemis turned the mortal man Orion into a constellation, with the intent that he fulfill the dreams of the people he hurt . However, Orion, furious that he was changed, unleashed his fury on the animals constellations of the world and severly weakened many of them, leaving them a shell of their former selves. The only animal constellation to survive was the trickster fox, Vulpecula, but she was very hurt and needed to rest in Artemis’ observatory, which serves as the place of worship for the constellations .

Orion grew more and more support from the people of Greece not only for his exploits, but also because the lack of animal constellations meant that dreams were no longer being fulfilled. Therefore, shrines and previous places of worship were largely abandoned by the people of Greece. While the other gods are content with Orion’s actions, as has promised that he will have his followers praise them in his places of worship, Artemis is displeased with Orion’s actions and asks her father, Zeus, to stop this madness. Zeus says that he will intervene only after the animal constellations have proven themselves capable of handling themselves. With Vulpecula being the only remaining animal constellation, Artemis tasks her with reviving the other constellations with her celestial powers and stopping Orion’s lust for power. This is the overall arching story of the game, but for the sake of clarity and a shorter time frame, the player simply wakes up and goes to save one constellation, Corvus.”

That all sound nice and dandy, right? Well, while we did have a better understanding of the world we were building, this is far too much exposition for a brief, 10 minute video. Therefore, we decided to simplify this further and just explain that Orion was a bad constellation and threw the other animal constellations to the Earth, hurting the animal constellations. The stars left an impact in the forest they landed in, causing objects to float in the area effected and are now able to be manipulated by one with the power of constellations (aka the player). This simpler lore still explains the players goals, but ties the mechanics better into the lore and allows us to explain the story in a short amount of time.

DePaul Midyear Showcase

Hey guys, Sam here to go over the most recent showcase that occurred at DePaul. Last week was spring break, and with that comes the half way point of development for our games. Therefore, a showcase was held at DePaul in order for teams to show off the games they were working on. It largely followed the same format that the end of the year capstone showcase takes, but was a great opportunity for an en masse playtest, as we got more than 30 people to play our game within the span of just a few hours. It was not just the quantity of the people that was great, but also the diversity of playtesters that really helped us come to terms with elements of the game that were and were not working. For example, players really enjoyed the intro of the observatory and many cited the sense of accomplishment of escaping the observatory and viewing the beautiful forest as one of the highlights of the game. This was great news to hear and meant that the tutorial of the game was working quite well. The mass amount of playtesters also helped to solidify elements of the game that we needed to focus on, such as the need for some sort of checkpoint system to help player’s keep track of their stars and to help eliminate frustration in the game. The showcase was very informative and also served as a great reality check for our game as well, forcing us to confront issues that we hadn’t thought about. Below are some pictures taken from the showcase.

IMG_1960IMG_1965IMG_1969IMG_1967IMG_1956

World of Tanks – Studio Visit

Hey everyone, Sam here to tell everyone about our recent visit that we had at the Chicago branch of Wargaming. For those unfamiliar with the studio, Wargaming is the company in charge of the popular World of Tanks series. They have studios across the world and the studio we visited, the Chicago branch, is primarily in charge of the console version of World of Tanks. While not all of the team was able to make it to the studio visit, the majority of us were able to make it and the experience was a great learning experience for us all. It was very interesting to see, especially since I am a producer for the team, how Wargaming is able to successfully manage such an ambitious title and large team. The biggest takeaway from our meetings with many of the team members as that you should not rely on any one given style or tool to manage (for example, you can’t just expect waterfall agile development to work in any given circumstance) and that you should create a unique style of sprint that works best for the needs of your team. This is something that I definitely should focus on doing especially for our next quarter of capstone. It was also interesting to see the advancements Wargaming has in terms of playtesting, as they have motion tracking cameras in order to better see and understand the emotions of their playtesters to collect better data. Obviously, we don’t have access to that type of tech, but it’s always great to see what other tools developers are using to maximize playtests. All in all, the studio visit was very insightful and the information we learned we will try to apply to our own team.

Playtest Session #4

Hey everyone, Sam back again to tell you about the progress we made with our current build. We recently did a quick playtest in our capstone class and got a bunch of great feedback. For this iteration of the game, we wanted to test how successful we were at guiding the player to their objective using the environment (in essence, we were testing our level and environmental design). In our previous playtest, we realized that while many players praised the art in the game, the placement of said art left a lot to be desired and served to confuse the player on their objective. Thus, when designing the layout of the level, we decided to use tress in the forest as a natural barrier that guides players to a central location (i.e. the puzzles we want players to solve). Below is an example of this:

Level layout 1.png

As you see, areas with a lot grass and a lack of tress highlight the 3 main puzzles, so the player will naturally be guided to them. It’s a subtle process the players go through, but an important one. Although no player’s mentioned it (which is actually a good thing because this means it is effective), the fact that players have little to no trouble figuring out what to next is a testament to the effectiveness of the level layout in guiding the player. Obviously, more iteration needs to be done, but it is a step up from our previous build. In terms of moving forward, there are two things we really need to address: reducing the penalty for failing a puzzle and improving the controls. These two elements are where most of the negative feedback came from and it is certainly valid. While you never can do in our game, often making a mistake means the player has to restart an entire puzzle again, which creates too much frustration when the intended mood is that of tranquility. Furthermore, the controls serve mostly in making the player make mistakes, so these both need to be addressed and are what we are going to focus on for the next iteration of the game.

Playtest Session #3

Hey everyone! Sam here to tell you guys and gals about the latest additions to the game as well as discuss our findings from the latest playtest. The biggest additions to the game is the rough first pass at implemented art. As you can tell from the above picture, we have made great strides in developing the “ethereal” landscape that we initially pitched. Obviously, this is not the final art for the game, as elements, such as the terrain and grass texture, are still being worked on. However, our implemented art should give you a great idea of what type of mood we are trying to invoke and the overall aesthetic of the completed game. We also had our 3rd major playtest this week and many playtesters felt that the strongest aspect of our game was the visual style. We also received a great deal of feedback concerning game objective and controls. While the vast majority of intended gameplay features are currently integrated in the latest build, they are all in a rough state, especially the level design of the game. Many noted that the art style was particularly strong, but would oftentimes obstruct the player’s view of their objective and other puzzles, which is something that needs to greatly taken into account. Thankfully, we are still relatively early in development (we are not yet in the middle of production), so these changes in environment placement can be iterated on quickly. Another big issue that emerged with playtesters was the controls and movement of the player. Our game uses typically movement for platformers on PC (WASD to move), but we deliberately made the character have weight behind their actions (as foxes cannot turn on a dime) and need to turn before moving in a direction. This was not something that playtesters enjoyed and either wanted the weight behind movement to feel realistic or gone completely. Thus, in our team’s next big design meeting, we will discuss whether or not we want to continue to pursue a weighted movement style or forgo realism for play-ability. In terms of moving forward, we will be primarily tackling art asset creation (mostly concerning our fox character) and level design, as our programmers our out at GDC.

Laying out the level

Hey! Sam here to talk to you about how we are designing the level for our vertical slice. As you can see above, we are dividing the demo into two major parts: the observatory and then the other half of the map is devoted to the main 5 puzzles of the game. The observatory serves as the tutorial of the game, where the player learns the main mechanics of the game in a more constrained and safe space. It also serves as a means to teach the player about their objective in the game (to find and collect the pieces of the Corvus constellation). We chose an observatory to act as a tutorial because it feels natural in terms of the fiction of our game and also allows us to create an excellent framing device for showing off the player’s progress (as the observatory will be broken down and allow the player a perfect view of the sky). After ascending to the top of the observatory and learning about their objective (which will be done using environmental storytelling, as stone slabs of the broken down observatory will serve to show the player their objective), the level then opens up to a much more open environment which features the main 5 puzzles of the level. We are designing the puzzles to be able to completed in any order, so they are all balanced to all be relatively equal in difficulty and are all twists on the main mechanic introduced in the tutorial. While we could have made the game more linear and have a series of more difficult  puzzles, we feel that going for that would feel not invoke the feeling of somber tranquility we are shooting for and feel constrained. A game like the Witness is a great example of this though process, as exploring helps the player be more immersed and they do not feel rushed or constrained to complete the game. Completing each puzzle rewards the player with a star of Corvus and returns the player to the middle of the map (to eliminate player frustration from backtracking). After collecting all 5 stars, the constellation comes to life (lines are connected from the stars and an outline of Corvus appears) and the vertical slice then fades to black. While this is obviously a basic layout that needs to be textured and filled in with environmental objects, it gives you a good idea of how we are designing the general flow of the game.

Playtest #1

Last Tuesday was our first big playtest to test the validity of our mechanics and to get players’ opinions on the art style we are trying to implement. As you can probably tell from the screenshot I took, the game is very bare bones in terms of art, but this initial test was mostly used to test mechanics. In that regard, we believe the playtest was successful in this endeavor,  as the vast majority of playtesters enjoyed the mechanic and puzzles on display, even with the numerous bugs and other issues with the game. It was also encouraging to see many playtesters understand that there was a direct correlation between their speed and jump height and the amount of stars they had. Even without the aid of visual indicators (such as the opacity and color to look drained, which we plan to add in the future), this connection was still clear.  In terms of moving forward, now that we have a solid base, we plan on implementing art and more cohesive level design. As it currently stands, the majority of puzzles involved floating blocks in air, which feels disconnected to the twilight forest aesthetic we are shooting for. Thus, we hope to iterate on the puzzles (and level design) we have now to make the levels feel more organic and make sense with our current art style. For our current sprint this week, we hope to include a placeholder character model with basic animations, as well as environmental objects (such as trees and rocks) and terrain to test whether or not they complement the intended mood of the game.

En”gaze”!

After multiple brainstorming sessions, a global game jam detour, and a pitch presentation, we have begun working intensively on our game, which is known as “Gaze”. Gaze is based on one of the top pitches we had when we started brainstorming and was originally called “Ethereal Cruise”. Inspired heavily by Greek mythology and constellations, Gaze is a 3rd person puzzle platformer where players control Vulpecula, a fox constellation. After the hunter Orion has destroyed the other animal constellations and wounded Vulpecula, you control the fox constellation and help rebuild other animal constellations and yourself. Players do so by controlling each star of your constellation and shooting it at environmental objects, which moves them in predetermined locations. From a gameplay and aesthetic perspective, we are inspired by games like Journey, Okami, Legend of Zelda: The Wind Waker, Gravity Rush, and several other titles. Stay tuned for more updates, including the results of our first playtest!

 

Shooting for IGF Submission

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).

Level 1-1.JPG

level 1-2.jpg

Level 1-3.jpg

Level 1-4

Level 1-5

Art Style & Aesthetic

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:

Penguin 1

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.

Ziggy 1.png

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.

updated penguin.png

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.

Not Just Games….

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

Designing Levels

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:

  1. 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).
  2. 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.
  3. 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.
  4. 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.
  5. 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.

Bit Bash!

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.

regular human basketball.png

pocekt rumble.png

sausage-sports-club-game.jpg

SkySutra_artCover-1.jpg

boxer.png

What is Snow Angel?

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:

Snow Angel screencap

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.