Rogue Rover is a 3D, isometric, puzzle game where the player takes control of The Serendipity Rover, a small dog like robot that is fed up with being ordered around by the colonists. Deciding enough is enough, the rover sets out to eradicate the colonists and reclaim Mars as its own.
Used agile and waterfall scheduling strategies
Main point of contact for collaborators
Created and maintained communication plan
Scheduled all tasks
Worked with the team to clear blockers
Collected all feedback from beta testers
Kept Google Play Store up-to-date
Personal Post Mortem
Flexibility Is Key
Our team learned quickly that we wouldn’t all agree on every choice we had to make, therefore we made a point of making sure we were flexible when one member disagreed.
Being able to work around problems that arose from hardware, software, or even interpersonal issues allowed our team to keep moving forward on the project no matter what came up.
Talk It Out
Whether it be a disagreement on a design choice or an interpersonal issues between teammates, it is important that those involved take the time to talk about both sides and try to find a middle ground.
I found it was very important to come together as a team after every milestone to discuss the issues, and victories, that happened during that milestone. This both helped with our best practices and our team moral.
We’re In This Together
Making sure the team created strong team bonds helped the team work through difficult times. These bonds also helped with the sharing of ideas and creative workflows.
Like many teams, ours went through the storming phase: however, with both individual and group meetings the team was able to come back together, stronger than before.
Team Post Mortem
The Rogue Rover team had many goals when we started, many of which we achieved and others we did not. One of our most important goals was to create a game which everyone on the team would enjoy making from start to finish. Since we were making a mobile game, we set our sights on pushing our game to the Google Play Store as well as the Apple App Store. We were able to set up our game on the Google Play Store and create an iOS build that we used at pitch and play, however, the goal of having our game on the App Store was not realized during our project. Another snag we hit was that the team had some difficulties designing and agreeing upon a monetization design. In the end, we were able to implement our monetization design as a team, though it did prove to be a challenge. As a student project, and a project we all would be using as part of our portfolios, it was also a goal to create a well polished, and working game, which we were most definitely able to achieve.
What Went Right
Throughout the whole project, the team made a point of keep each other’s morale high, which in turn kept the overall team morale high. While we did have our rough patches, the team always pulled themselves back together. We never stopped having each other’s backs. We found we all did our best work when our morale was high.
Google Play Store
Our PM, spent a weekend setting up our Google Play Store. Once the Play Store was set up we were able to receive near constant feedback from our beta testers. This saved us time setting up and running so many in-person play tests and gave us a unique opportunity to have our game released to the public.
Modeling to Animation Workflow
Unlike most final projects, our artist was not the same person who was doing the animations for our game. This meant that we needed to create a functional workflow between our modeler and our animator. We quickly worked out a workflow that worked for both parties. Doing this early on in the project saved us a lot of time and pain throughout the project as a whole. The animation mentor was the one who suggested reference files which was instrumental in our workflow as it allowed all animation to be updated with the new model, rig, or skin weights whenever they were changed.
What Went Wrong
Started Off Not Sharing A Vision
In the beginning our team did not share the same vision for the game. At the time we didn’t even realized this was the case until a couple weeks into production. This hurt our team’s productivity as we were all prioritizing different things. In the end we were able to have a meeting about our vision and come to one vision shared among all of us, however our lack of a shared vision forced us to cut levels we could have otherwise had in-game as well as many design changes in the first few weeks of production.
As a small team we knew we had to keep our design small. However, as tends to happen, we unfortunately over scoped our project. We had to cut features we would have liked in game, but our time and resources would not allow us to do so. This forced some design changes that made some work already done by the team unneeded and by extension, a waste of time.
Had A Hard Time Asking For Help
Our sole programmer at times had difficulty asking teachers and mentors for help. While he did improve through the project, and by the end had no problems asking for help, this did force some hard design choices onto the team do to the time that was lost. Once the time was lost at the beginning of the project, the rest of our project was effected. Tutorialization is a important part of any game. Our level designer did her best creating levels for the player to learn the mechanics of our game, however, she left asking for help on how to best teach the player till too late. This forced a tutorial that was less natural than we would have liked. Instead of our players learning through the design of the levels, we had to use text prompts to show the player how to interact with our game.
Don’t Hold Back Questions
Many questions can be answered by a quick google, but some require more help. If you are in a position where you have looked online for a answer, go ask a teacher, mentor, or peer for help. There is no shame is asking for help.
Lay Clear Lines Of Communication
While our team’s communication wasn’t bad, we know that we did have a few miscommunications between team members and between the team and our collaborators. In the future we believe making clearer and simpler lines of communication how have made the project overall easier on everyone and would have saved both the team and the collaborators time and energy.
Make The Vision Clear To The Whole Team From The Start
The next project we work on will make sure all parties involved are clear on what the vision is from the beginning. This will save both time energy, and money for all parties involved. We would do this by starting production with a large meeting with all collaborators and team members were we would go over the GDD and the vision.
Things to Consider
Ask For Help When You Need It
No matter what you are working on, it is always okay to ask someone else for help. This is even more important when you are working in a team. Your teammates are relying on you as you are relying on them. You should always try finding answers on your own first, however don’t sink too much time and energy into finding an answer when you have people around you who can help.
Consider Your Platform
When making a game, the platform is an important choice. PC, console, VR, and mobile all have their own pros and cons. It is very important to look at all technological risks that come with your chosen platform as too many unknowns or technical limitations can force design changes that you may or may not see coming.
Talk To Your Team
Your team is your brothers and sisters in arms while working on a project together. Any ill will can disturb the team culture and morale you have carefully built. If you have a problem with a teammate, take the time to talk to them and work it out. Bring up any issues on the team with the PM if you aren’t comfortable talking to the person on your own. If it is the PM are you are troubles with, go speak with a higher up and ask for advice on how to handle the situation.
Play To Your Strengths And Weaknesses
When you are in pre production, take some time to look at everyone on the team and the strengths and weaknesses they each have. Know where your team is strong and what you can push yourself on as well as where the team could use some work. Always challenge yourself, however, remember that pushing yourself and your team into doing something that is a weakness can end badly. Look at what risks you can take, and when you should play it safe.
Let It Go
A team isn’t a random collection of people, it is a single entity with many minds working together. Everyone on the team needs to be ready to know when they should push for a feature or mechanic and also when they should let it go. Ideas that are suggested to the team become the team’s idea, not just the one person who said it. Ideas and design change, let them and let them grow. Always be ready to let things go.
Rogue Rover is a game the whole team is very proud of. We were able to create a well polished, working game even though we had troubles in the beginning with our vision for the game. We weren’t able to bring the game to the App Store due to both technical and legal reasons, however the game is published on the Google Play Store. Unfortunately we weren’t able to test our game on as many devices as we would have like so our game still suffers from some technical issues on some devices. In the end, we made a game we all loved to make and play, even after all the challenges we faced during the project.