Thrash Planet
THE VIDEO IS LOADING...
GENERAL INFO
High Concept
Trash Planet is a 3D, Third-person Runner game where you play as a little robot with a hoverboard that tries to clean up the Earth in the fastest way possible. Collect trash cans in order to boost your speed, but stay away from cars and other obstacles, they'll slow you down... How fast can YOU be? Challenge a friend!
The Mission
During my time at Futuregames, this was our first actual game project, and the purpose of it was to prepare us for upcoming game projects. The task was to create a simple game in two weeks, with accessibility in mind. The game should also be fully playable with Xbox Adaptive Controllers. We had the previlege to have the playtest session AND gold presentation at "Tekniska Museet" in Stockholm.
TARGET AUDIENCE: CHILDREN: 10-12
DEVELOPMENT TIME: 2 WEEKS
GAME ENGINE: UNITY
TEAM SIZE: 10
MY CONTRIBUTION
Summary
* Product Owner (Vision holder, Documenting, Pitching, Leading)
* Game Design Generalist
​
Product Owner
As Product Owner, I was the vision holder for this project. I had to make sure that everyone on the team shared the same vision during the entire production. In my role I felt a strong need to communicate with every department as often as possible, to make sure that everyone was on the same track and that the development moved forward in a way that felt good to everyone.
​
Being a PO was tough but also a lot of fun. As the project lasted only two weeks, I worked mostly as a producer, focusing on creating a smooth pipeline and making sure the working conditions were positive. I kept an open dialogue with the team and emphasized collaboration, especially when it came to decision-making and planning for the entire project period.
We worked together and tried to stay organized via MIRO. Updating tasks was something we all did.
TEAMWORK CHALLANGES
During development, I became aware that one team member wasn't feeling good about the project at certain levels. In order to address the issue, I reached out to the individual in charge of our game design education for advice. The problem was that I had failed to give responsibilities to all team members. The person felt confused and neglected due to the fact that they didn't know what to do. As it was our first project, I was blinded by our task and forgot about the team. After adressing the problem, it became a little bit better.
MEETINGS AND STAND-UPS
With previous experience from Tomteland - the theme park I co-own, stand-up meetings were nothing new to me. I led our daily stand-ups and tried to stay updated with our progress. We got side-tracked a few times, but all in all, it worked well
CREATED AND MAINTAINED THE GDD
During the project, I took on a lot of responsibility for keeping the game design document alive and updated. Whenever we had meetings or discussions about mechanics, graphics, systems, or product information in general, I took the time to write it down in our document.
In my role as product owner, I always directed my teammates to the document. In some cases, it worked well, in other cases, it didn't. I think the information in some sections may be clear and helpful for some, but that doesn't mean it is for everyone else.
PITCHING AND PRESENTING
For the final day of the course, I prepared a PowerPoint presentation that detailed the sources of inspiration for our idea, as well as the feedback we received from both the children and the jury members. I aimed to make the presentation easy to follow and understand, with a vibrant approach - regarding the colors and fonts.
FEEDBACK AND ADJUSTMENTS
Initially, we had designed pickups that should look like solar energy spheres to increase the player's speed. However, after the first playtest and receiving feedback, it became obvious that the narrative aspect was unclear. Luckily, we had garbage cans as obstacles in the game, and we ended up using them as speed boosters instead. This decision gave the game mechanics a deeper meaning.
​
Below, there are some images I made for the pitch - to showcase the feedback & adjustments.
Game Design Generalist
GAME PROGRESSION
We received feedback that the experience lacked variety. During week two, I prepared the images you see below. The goal was to convey a progression structure to the team. The concept was that the player would go through three courses: an easy one, a medium one, and a hard one. At the end of each course, the player would be rewarded with a bunch of speed boosters leading to a ramp jump, which would lead the player to the next course. We also discussed having unique environments for each course: a park, a village, and a city. Unfortunately, we didn't have time to develop that.
CONTROLS SCHEME
The game was designed to be accessible to all players, especially to those with disabilities. The player character always moves forward, as in most runner games, which worked great for our design approach. To ensure simplicity, the player can only control the character's right- and left movements.
I made the Controller Scheme images on the right.
Click for a better view
ASSISTING THE LEVEL DESIGNER
We developed the game using several level blocks for a complete random generation of smaller level sections. That way, the player would have a different experience when replaying the game.
We designed several level blocks according to the three courses mentioned in the GAME PROGRESSION section above.
​
I designed some of the building blocks in Paint,
​
then our level designer put those together in Unity.
REFLECTIONS
What went well?
1. The overall feel of the gameplay ended up in a satisfying way.
2. In the end, we received good feedback from the jury, target audience, and play-testers.
3. We managed to create a good balance regarding the accessibility limitations we had, and it didn't conflict with the player progression.
​
​
​
The time for pre-production was little to none.
We rushed and began developing the game without knowing much about our limitations. We also didn't take the time to really get to know each other, which ended up in people feeling uncertain about their work. If we would have taken an extra day to really gain some knowledge about our different strengths, maybe the product would've turned out better.
SCRUM? What's that?
We only had a pretty unorganized MIRO board that was cluttered with everything. As a Product Owner, I tried my best to communicate my vision, but since we had no structure, people didn't know what others were working on. This resulted in a lot of waste of work.
Challenges along the way?
Lessons learned?
1. Without any project management, the collaboration within the team will suffer.
2. It's important to know your team. Talk and discuss a lot, figure out what each person can bring to the table, and have fun doing it.
First Playtest - Week 1
Final Version - Week 2
