Postmortem
Spaceshark Studios' Game Designer, Tyler Morgan, teaching some valuable lessons
WHAT WENT RIGHT
We embraced the vision
-
At the beginning of development, the team struggled trying to create a shared vision. After a very succesful Vertical Slice, where we managed to show what our game was about, we decided to make some hard choices and discarded all game elements that didn't fit the Vertical Slice level. We changed our game name to "Gravitas", and then recovered at an incredible speed, delivering a top quality game by the end of development.
A draft of the "new progression chart" that the team made after the Vertical Slice milestone.
We playtested every week
-
After Vertical Slice, we made playtesting a core element of our development pipeline. We decided to playtest every week, and observe people while they played. We learned to interpret playtesters' reactions while they played. Could they solve the puzzle? Did they see the goal? Did they understand the mechanic? Where did they struggle? Playtesters' feedback was carefully evaluated and prioritized. By the end of development, we had a simple moto: "If it does not show in playtest, it may not exist".
One of the Production Schedules created by our Producer Kevin Morris, for the second internal milestone during Alpha.
We adapted scrum to our needs
-
It quickly became clear that the traditional Scrum with Scrum Boards and very detailed task breakdown, was not working for own team. We decided to apply an alternative Scrum, where we agreed on "Sprint Goals", which were tasks that each department had to complete by the end of the sprint. Each department lead had the responsibility to make sure these goals were achieved. If the task was not completed by the end of the Sprint, the department had to then make adjustments accordingly, including cuts to focus resources on high priority areas of the game.
Spaceshark Studios during one of the playtest sessions at the Guildhall. For important milestones, both Capstone teams playtested together.
WHAT WENT WRONG
Analysis paralysis
-
Before Vertical Slice, we had a tendency to over analyze every problem that we faced, having lengthy discussions and long paper design sessions. We quickly realized that designing on paper was good, but that paper designs were bound to change and that creating the "perfect paper design" was not possible. Once we realized, we stopped spending so much time in discussions, and more iterating in Engine. We decided to create a "good and functional" paper design, and make it great iteration by iteration.
We planned almost every puzzle on paper at the beginning of development. Soon we realized sketches and engine whiteboxing was a better approach.
We didn't let go of some ideas until it was too late
-
It took a long time before we realized some ideas from our original project, SkyArk, were not feasible. Discarding ideas was a complex and tedious process, because we were afraid that by discarding them we would hurt some of the team members' feelings. Many ideas that didn't work well with the game stayed in the pipeline for too long, with the team wasting a lot of time trying to make them fit the vision.
Lead interaction was initially insuficient
-
Coming from a 7 person team, the leads were not ready to deal with a team double the size. At the beginning of the project, we didn't meet enough or made sure that we were all in the same page. This had repercussions on our own departments, since the developers counted on us to learn about any important changes to the vision.
The initial maps included lasers that could open doors and activate Gravity Fields. The mechanic was confusing but it took us time to finally get rid of it.
WHAT WE LEARNED
Prototype early and quickly
-
Something that we learned early on was that discussing the potential fun of a mechanic was not as beneficial as prototyping the mechanic, and testing it on engine. We learned to make quick, throwaway prototypes of different mechanics in order to see if they fit our game. In puzzle design, we realized that quality came with iteration, and that the first version of a puzzle did not need to be perfect.
A very early prototype of one of the levels
Making hard choices is necessary
-
One of the most important lessons that we learned was that trying to please all team members was not only impossible, but it let to never ending discussions. We, as leads, learned to make hard choices that not everybody liked, but that were what we considered best for the game. The other developers embraced our role as leads too, because making decisions meant that we could move on and keep working to make the game better.
Gravitas was originally called "SkyArk", and it took place in the sky, in a spaceship overgrown by nature. After the lost of two artists, the team made the choice to scrap the setting and choose a new one that fit our resources.
It's all about the pipeline
-
When a bug or problem was found, developers would always consult leads first, so that they were aware of the problem. In many cases, leads would tell the developer to work with some other person to fix the bug, because that person knew about the topic more than them. In some cases, the lead would refer the developer to another lead, if the problem belonged to another department. This pipeline was extremely beneficial for us, because it kept leads updated on the state of the project, and it let us organize tag teams to solve problems, with the members who we knew were the best to tackle the issue.
First pass of the LD pipeline, that we later improved and simplified.
