Pogo Pirate
Team Project
Fall 2019 - Spring 2020
An educational project created by the multi-disciplinary team Unicode Snowman at the DigiPen Institute of Technology.
Full Project Breakdown
Pogo Pirate was a multi-disciplinary project for my GAM200 course.
You may skip down to the videos, each represents a larger step in my iterative process for this project.
Initially upon being “hired” by Unicode Snowman, I was excited about working on the project that they had explained during my interview. I was glad to have been hired by Unicode Snowman, because they seemed like a competent and well-organized team. Their pitch of “a 2D platformer where the player is always jumping” got the whole team brain-storming ideas for theme and gameplay.
In regards to the gameplay, despite wanting to work on a more turn-based strategy idea that’d been rattling around in my head, I felt that the team’s idea was much more within the scope of the course, so I decided it’d be best to set my idea aside.
In regards to our game’s theme, I spent a few days considering what themes would work. And I came to two different themes. Medieval and Pirate. I preferred the Medieval theme, even though it has been done countless times before, but the most of the team felt that Pirate was more interesting, especially after I pitched it being a pirate hopping on a single peg-leg. This then became “Sky Pirate” in order to lower the chances of having the same theme as any other teams within the course.
Each team in this GAM200 course was required to create a prototype in Unity to be used as a guide for the custom engine that each team’s Tech sub-team would work on.
I began working on our Unity prototype, trying to get an idea of how the platformer movement would work. After a day or so, I had the prototype ready for testing. It was very basic, a bouncing 2D primitive that moved based on player input, a following camera and a tilemap. I had also implemented a drop-down in the pause menu which would change the movement between three different options, for ease of playtesting for both myself and our team’s other designer.
I planned to have playtesters test the three different types of controls, two for one type of movement, and one for the other. The two types of movement were “Strafing”(moving left and right in classic platformer fashion) and “Rotating”(moving more like how a real Pogo stick works). The results from my testing was that the “Strafing” was the best option. The other designer and myself both felt that even though the rotation-based movement was more interesting, the complexity/difficulty would shrink our game’s audience.
The Process
Pogo Pirate v0.2
For the second build of the game, I added two new mechanics that I had suggested and that the team had agreed upon. A charge jump, and coin collectibles.The charge jump turned out to be interesting and well-received by playtesters, but I still felt that something was off, and it was a feeling that would bug me until after our first milestone.
​
We had passed our first milestone, presenting version 0.2 to our professors. It was at this point in which I realized what felt off about our game. The core mechanic of the player always jumping was not being supported by the charge jump mechanic. The charge jump would halt player movement and interrupt the flow of gameplay. I spent a couple of days trying to determine what changes would help mitigate or eliminate this issue. It hit me that a double jump would be more forgiving and wouldn’t break the flow of gameplay.
Pogo Pirate v0.3
For our third tested iteration (there had been many iterations over the course of the prototype that went untested(due to tweaks requested from within the team)), art assets, music and sound effects, and better feedback had been implemented into our Unity prototype. I also simplified the coin pouch, to better represent how the game would look in our custom engine, after discussing limitations with our tech team. I had also created two separate versions of the same build, one testing charge jump, the other testing double jump.
​
After the previous playtesting had been done, I brought the data that myself and the other designer had gathered before our team and explained how replacing the charge jump with a double jump would benefit our game. After a bit of deliberation, the team agreed that the double jump would be a beneficial change to our game.
Pogo Pirate v0.4
For version 0.4, I added hazards into the game to act as another form of tension.
Pogo Pirate v0.5
Version 0.5 integrated more art and sound assets into the prototype so that the other disciplines could see and hear their work in the game.
Pogo Pirate v0.6
Version 0.6 had new revised levels, an Intro level where the player doesn’t have their double jump yet, and a Hook level where they are able to double jump. This iteration also had more updated art assets, a parallax background, and an animated flying pirate ship. I implemented all of these features in order for our prototype to represent what we wanted to replicate in the custom engine.
​
Following this iteration, the Unity prototype was to be retired and my work was going to continue in our team’s custom engine. I am quite proud of how much work I was able to get done within the Unity prototype, and I am glad that our team’s artists and sound designer could have a place to see their work in the game so as to have a better idea of how it meshes with the finished product.
​
Here are the documents used throughout our project.
Documentation
You can download these PDFs to get a closer look at the documents that guided the design process of Pogo Pirate.
Pogo Pirate v1.0
This is where the GAM250 course began, our goal was to replicate the Unity Prototype for Pogo Pirate in the custom engine that had been built by our tech team during GAM200.
The video (shown above) is the functional build that we showed off to professors at the first milestone of GAM250, mostly demonstrating that we were on track to get all of the features/functionality from the Unity Prototype, with plenty of time for polish. It'd been nearly a month into the semester, but now the Design team could work on coming up with low scope ways to improve the game from a gameplay standpoint, while Art, Tech and Sound worked on polishing/improvements.
Pogo Pirate v1.1
This was an update to the game three days after the previous version. I had been spending my spare time working on the level shown here in the month prior. We had decided that the introduction/hook needed to be stronger, so I suggested that the tutorial section should teach basic movement before introducing the player to the double jump as a pickup. This level was designed around that idea.
As well as the idea of non-linearity, and having players move upwards more than they move horizontally (over the course of the whole level). I tried to give players multiple paths to reach the same destination, with one seeming more high risk/high reward, and the other appearing to be the safer option. From both a game feel and flow standpoint, something felt off, the movement needed to be adjusted in not only values, but also introducing player to a more drastic movement change.
Our Design Professor for the course Rich Rowan suggested that we try implementing a super jump where the player presses space when they hit the ground and will gain extra height. Initially, I was hesitant, as I never take design feedback and immediately try to make a change to appease said feedback. I had considered a mechanic like this previously, but I dismissed it because I figured that it could be too complex (too much cognitive load) for players. But at Prof. Rowan's request, I planned to implement this mechanic.
Pogo Pirate v1.2
Over the weekend following the previous iteration, I was able to implement this "super jump" mechanic as we called it.
Unsurprisingly, Professor Rowan was absolutely correct, the super jump mechanic helped gameplay feel less monotonous and require more focus from players. It still needed some fine-tuning the get the actual "physics" of the movement feeling good, but that was mostly ironed out over the course of the rest of the semester.
​
Sadly, I was unable to really focus on level design until much later in the project because I was needed by the rest of the team to help sort out Lua-scripting issues (specifically about getting Spine animations to play at specific times, and not have any overlap).
Pogo Pirate v1.3
For this iteration I had been unable to make any levels, with my focus mostly directed at Systems and UX issues, as well as scripting basic functionality for basic cutscenes, upgrades, tutorialization, and the double jump pick-up that would either be utilized in this iteration or the next.
Pogo Pirate v1.4
Aside from assisting with the significant graphical overhaul, I was able to get the other levels that myself and our other designer had been working on into the game. Levels 2, 3 and 4. Our other designer had worked on the layouts of Level 2 (Prickly Peaks) and Level 4 (Gusty Heights), and I had placed the hurt-boxes and adjusted the placement of some of the assets before pushing them on through to the game. Level 1 (The Outskirts) and Level 3 (The Cliffs) were the two maps that I worked on. And before this iteration, I made some minor changes (with the permission of our other designer) to improve upon the flow and layout of Level 4 (Gusty Heights).
​
For Levels 3 and 4, I drew some rough sketches in Paint.net (of which, I didn't save to show as examples here), those sketches gave me a rough layout for how I wanted each level to "feel". Each sketch wasn't focused on the level as a whole, but more on a section that would support the feeling of that level.
​
Level 1 had been more or less set in stone, with some minor tweaks needed since it's inception, and had gone through the most testing out of all of the levels in our game. I'm sure that Level 1 could have been improved upon, but for the scope of this project, spending more time on it would have diminishing returns.
All in all, I think that Level 1 was the most refined, and Level 3 was experimental but turned out to be my "favorite" in terms of flow as well as being the most enjoyable to work on. And I am satisfied with the edits that I made to Level 4, as I believe that they improved the flow and feel of the level, making it a compelling conclusion.