Introduction and Overview
The journey of Pepperbox Productions was a rollercoaster ride of both fun and frustration throughout the timeline of our project. A mix of “a-ha” and “oh-no” moments, this project helped us as a team and individually collaborate over pitching an evocative game idea. It gave us an experience and opportunity to understand how tackling challenges would feel like in a professional world. Pepperbox Productions is a faculty sponsored game project that aims to create a pre-production package for a student pitch game that stakeholders would want to invest in in a hypothetical professional setting through delivering compelling art and visuals, narrative and gameplay design. We were a team of 3 designers and 3 artists.
- Em Tyminski
- Saylee Bhide
- Sheenu You
- Brendan Valley
- Josh Li
- Andrew McLamb
The deliverables for our project are a comprehensive game design document that covers everything from art, gameplay, level design, UI, story, and demographic. We are also submitting an art documentation that will map our journey from inspiration to completion of our renders for character, environment, and world building props. Lastly, we will be submitting a demographic analysis of the customer base document.
In our story, you play as Peck, a flightless bird who works at the post office in the forest. One day, many deliveries come in and need to be made throughout the surrounding areas, but none of the other delivery birds are willing to do it, so they are given to Peck to complete. They excitedly head out to prove themselves just as capable as the other birds. As Peck goes through different areas, the more they focus on using their own ingenious ways of maneuvering around biomes without being able to fly and make sure all the unique citizens they meet receive their mail, the more successful they are. They realize their success comes from them doing things their own unique way and connecting with the community they delivered to.
Our main approach was to create a well explored and well communicated document about the game for the production team in future. Since we did not have a time constraint for the production of the game, we did not limit ourselves and decided to think beyond the limits of a 14 week project semester.
What went well
As we launched into the semester, we were given an option of either following a prompt from the advisors or pitch our own ideas without considering any bounding box. Enthusiastic to explore the game ideas space, around Week 4, we came up with our own ideas to pitch. Although we took some time ideating, throughout the process, we were happy to realize that all of the ideas were innovative and are unexplored areas in genres that are quite well established. The spirit of rebellious innovation was high from the start. Since the team went their separate ways during the ideation phase, the brainstorming process was smooth and conflict-averse. Also, we all were flexible and open to fleshing out each of the ideas which helped us explore and understand our reasoning behind our pitches in a more collaborative and well rounded way. This helped us pitch all 3 ideas collectively as a team wherein each of us were involved and excited for every single one to come through. We believe that this was a robust initial milestone to achieve given the challenges of the vast space as well as a lack of any technical constraint in a fully remote/virtual environment.
After the selection of the pitch, the artists were quickly able to sketch out their own visualizations for our main character Peck. With continuous feedback on the shape language, characteristics, attributes and overall look from the team and advisors every week, the character iterations saw a lot of progress eventually leading to a strong character design towards the ending of the semester. It gave enough time for the 3D artist to create a 3D model from the concept art. As a validation of our strong character design, the playtest results on the playtest day were in tandem with our expectations of our character’s personality and profession. Since our game revolved around Peck, this communication indeed was an achievement we were really proud of as a team.
Additionally, very early in the semester each of the team members had identified their forte and were dedicated to completing our individual tasks/deliverables concurrently along with the collaborative tasks. Initially, we struggled to have an efficient communication between the designers and artists since we had many aspects to cover, in addition to the core gameplay ideas being fuzzy and unresolved. However, with time, the workflow between designers and artists became more fluid and faster as seen from our world building documentation, supporting character visualizations, and level design layouts for environments. These parallel tracks enabled us to speed up the pipeline and be able to achieve most of our key goals in our project.
The biggest note of our project was that we were NOT making a demo. Yes, you heard it right. We wanted to focus on an airtight communication of our game rather than focusing on a demo. However, throughout quarters this decision made by our faculty advisors welcomed a lot of mixed reaction from the other ETC faculty. They were not sure as to how we were going to convey the feel of our game. The pressing question was “how are you going to show your mechanics?” One of our designers got down to building a demo that would communicate the base mechanics of our game. We did not plan to provide this as a deliverable, but only as a medium to show the mechanics. This served us really well towards the end since it was able to show off the mechanics just enough for the audience to understand.
We did not want to cross the line between a pre-production package and a production package. However, we realized that communicating through documentation would be slightly risky and therefore we decided to create foundational mockups of each of our domains. We had all the elements to be carried forward to 3D, but it was on the production team to take it further by drawing inspiration from it and actually building it. Similar to the demo, the level designer on our team designed level design grey boxes for each of the biomes in our game world. We believe that this along with the concept art will now be able to give a clear picture to the next team about both look, feel and playability of this game. Overall, we feel that although this project might take more than 14 weeks to complete, the scope of it has been well documented and explored in the game design document made by our designers. The GDD is an extensive piece of documentation containing everything from the story, characters, gameplay, mechanics, level design and UI. We believe this would help the future teams to get a big picture of our game and be able to scope it the way they want.
What could have been better
Our game was inspired by Kiki’s delivery service and Mario Odyssey. As we were brainstorming about our story, we took several different paths and got slightly lost in the scope of our game. The focus went away from story and more towards gameplay and art due to time constraints and requirements. We had different paths for stories, but we never really sat down and discussed as a team each of our thoughts until much later. We were yet to decide if our characters had a personality and both the design and art team had different views about the same. After talking to our advisors and our outside friend Kate, we were finally able to come to a conclusion. However, it was a little too late in the semester to really nail down the story beats. We feel that dedicating a good chunk of time to hammering down the story would have helped us in not only having a concrete storyline to bank on but also be able to reduce the competition of resources between design, art and story.
Moving onto level design, the team struggled somewhat throughout the semester. Level design and gameplay design almost always go hand in hand in a real-life professional setting. Level design serves gameplay while gameplay checks if the levels squeeze out every ounce of potential gameplay. The problem with this semester long is that there is simply not enough time to figure out either to a shippable standard to pass onto a production team as references. For example, levels that lean towards a wide-linear progression requires a different design mindset from traditional platformer levels that stress clear and narrow level progression. Meanwhile, the design team had to come up with new and fresh gameplay mechanics that work well with the levels. Having these two essential elements under development is no easy task.
As mentioned above, the story should be focused in the initial leg of the project irrespective of the subject matter of your game. It is very crucial to sit together and nail down the story beats. This would also help to create a mockup of how level works if you have a visualization of the story. Approaching the story from different angles is key to ideation. Continual feedback from advisors and peers is also important for eventually having a concrete storyline. The second lesson we learnt was that, regardless of whether the pre-production package was going to be used by the next team or not, it is important to not overscope your project. Since we did not have any constraints we were thinking big. The time challenges we faced could have been mitigated had we constrained ourselves much earlier. Creating a timeline for the project along with identifying key milestones and deliverables during the start of the project would have been beneficial to bring the scope in perspective. It is also important to create a fluid communication channel between the designers and artists. Establishing that would help reduce conflicts, communication gap and effective use of resources. Lastly, as a pre production package team we were not sure how we should be balancing time and resources between ideation and brainstorming. A schedule of some kind would have really helped us in this situation.
In terms of level design, a good thing to keep in mind, especially for designing platformers, is “Kishōtenketsu”. ‘Ki‘ / introduction: a new mechanic or situation is introduced in the leve. This part of the level essentially demonstrates to the players how this new mechanic works. Players then try out the new mechanic in a safe and controlled environment to get familiar with it. ‘Sho‘ / development: The next section of the level features the same mechanics. Gone is the “safety net” in the previous section that guarantees player progression. The solution to these new challenges stays the same, but to proceed further the game demands more from player skills. ‘Ten‘ / twist: The mechanic introduced and developed in the previous section of the level is now turned on its head, requiring the players to think from a new perspective in order to solve these new challenges. ‘Ketsu‘ / Conclusion: All types of the previous challenges are gathered here for a final test of player skill. However, these challenges are not as hard as the “Ten” section. The goal here is to give the player a sense of achievement.
Overall this project was a different experience of its own. Certainly a challenging one but with massive learning rewards. We all got to explore our own interest areas further along with learning the skill of collaborative working in a remote environment. Despite the challenges, we are now close to completing all our deliverables with extensive work to show. Although we had lots of opposing views, we also had innumerable interesting and fun conversations. As mentioned earlier, we grew both in our domains and as collaborators. To conclude, we were able to bring an interesting idea into this world as a team, an idea we all loved and were proud of – which made this game something we all are confident of looking forward to if it ever went in production!