Tanabata - 2D Flying Sidescroller
What is Tanabata?
Tanabata is a sidescrolling game about a magpie collecting stars. Each level works off of a three-star system, where the player can earn all three stars by completing the level, collecting all the collectible stars in the level, and finishing under the allotted time limit.
Tanabata was made in a custom C++ engine in my sophomore year at DigiPen Institute of Technology with a team size of 6-9 people. Our team’s initial lineup was made up of 3 designers, 4 programmers, and 1 sound designer with a estimated development time of 7 months. It was almost all of the team’s first time working in a inter-disciplinary team. Prior to this we had only worked with other designers or other programmers.
What Did I Work On For Tanabata?
My main responsibilities for Tanabata were as the UI/UX Designer and as the producer and also helped Brianna with level design of the levels. I focused on creating the necessary graphic elements of the game from the menus to the HUD elements (which were later scrapped due to the necessity of cutting major aspects of the game).
UI/UX Designer
As the sole UI/UX Designer on the team I was in charge of designing the entire layout of our menus and UI as well as creating all the necessary assets for the game excluding the obstacle and character assets which were done by Brianna. Since we were working on an engine that we needed to build from the ground up I worked on much of my UI outside of the engine in Photoshop making sure to seperate them into individual pieces that could be implemented once we reached the put when I could put the assets in engine. Once we reached the point in which I could work on the menus and implement them in-engine it was my responsibility to implement all the UI using the XML documents we were using to store the data for our levels.
Level Designer
As the secondary level designer my main job was to help Brianna with her designs of the level, at each step of the creation of the levels I would take a quick look at the levels and give my feedback as well as help with placing the obstacles and stars around the planned levels. Additionally, even though all three designers had a hand in implementing the levels, all of the levels were implemented entirely or partially by myself because of my knowledge and experience working with XML.
Producer
As the producer of the team my responsibilities were to organize the project and help produce the pipelines for communication and implementation of art assets and audio assets. I also tried to keep morale up throughout multiple phases of the project and throughout multiple issues various members of the team were having outside of school. This was my first time being a producer on an inter-disciplinary team.
What Did I Learn From Tanabata?
- COMMUNICATION IS MORE THAN JUST TALKING – Tanabata was a project plagued with problems from the very beginning. My first task I set out to setup as producer of the team was to setup solid lines of communication for talking outside of the teamspace to this end I setup a discord that everybody could use to communicate, however everybody did not use it to communicate. We had multiple issues with people never checking their discord and missing messages and even when they were texted directly on their cell number they did not answer, this led to various issues with source control and other stuff causing large portions of the engine to get overwritten and having to be redone. In addition to that our sound designer vanished early on in the project and then left the team without notice about a quarter way through the project. Though I learned multiple lessons about communication after this project my first big wake-up call for how to organize a team communication was with Tanabata.
- SCOPE CREEP AND EXPECTATIONS – Though our intitial concept for the game wasn’t wildly out of scope for a complete professional engine, it was out of scope for a custom engine created by college students. Though our programming team worked hard and accomplished good things with the project it wasn’t anywhere close to what we thought we were gonna be able to accomplish. In addition to that we, the designers, had thought we would be able to implement things throughout the production of the engine, however due to the many technical issues as well as social issues within the team we weren’t able to begin implementing the game in earnest until more than half-way through the project’s development.
- ENDURE AND SHIP – Throuout the projects development I attempted to keep morale up and keep the team together. Nearing the end of the first half of the project we had to let go of someone in the team and also officially removed the sound designer from our team. It was at this point the programming team brought up concerns about not having enough manpower to produce the project, so I along with the help of our Tech Lead Aidan hunted down three new programmers to bring the project home in the final half of development. It was in this second half of development that we reorganized our team and then worked on refactoring and cutting various aspects of the project to produce a shippable game that met the expectations of our professors. It was in this last stretch that we fit cohesively as a team despite some still lingering issues between some of the team.
Design Team
- Brendon Banville - Producer, UI Designer, UX Designer, Level Designer
- Brianna Ferderer - Creative Director, Level Designer
- Harrison Green - Design Lead, Systems Designer
Tech Team
- Aidan Keane - Tech Lead, Architecture Programmer
- Benjamin Earles - Systems Programmer
- Mubarak Al-Sabah - Gameplay Programmer
- Jack O'Brien - Gameplay Programmer
- Craig Williams - Gameplay Programmer