Stitches was a video game made during the summer of 2019 spanning a 3 month development period.  Through many ups and downs, the team managed to turn out a solid demo that displayed the overall gameplay loop and the general visual style.  While we are proud of the work we did as a whole, the actual process for developing Stitches was a very rocky one for quite some time.

During this postmortem, there are a few key things we wish to touch on regarding our general development experience.  

• The struggles and successes of working under a Product Owner that had never been in a leadership role before.
• The scheduling and time management issues that plagued the early-mid stages of development.
• The Ups and Downs of communicating through an inconsistent messaging service and how it led to more in-person communication.
• The struggles of getting too caught up in the future of the project while the “Here and Now” was left to burn.

Now, before we actually get into the “What went wrong…” and “What went right…”, I would like to answer the simple question of…

What is Stitches?

Stitches is a puzzle/platformer set in the year of 2006, on a seemingly random day in March, a human being was placed into an undiagnosable coma.  At the same time that this person fell unconscious, many others awake to the unique ability to traverse the minds and memories of others. Soon after the first comatose victim appears, that number begins to skyrocket and after many tests, the cause is determined to be the work of a paranormal force researchers are referring to as Demons due to similarities to mythology and folktales.  

As a game, Stitches is meant to be a fairly challenging puzzle game that is interacted with from two unique perspectives, a first-person view, and a “Rotation” view.  The game switches between a normal 3D first-person movement system and a view that shows the current room/level that the Player is currently in.  

All of the levels in Stitches are very similar to things like Escape Rooms.  They usually require multiple smaller puzzles to be solved before the big puzzle can be.  What makes these puzzles interesting though is the previously mentioned “Rotation” view. While in this view, the player can move the room itself around similar to a Rubix cube with some variations.  

The platforming sections are mostly attributed to attempting to reach a specific exit point in every level known as a “Memory Fragment”.  This exit point is what allows players to progress through the game and appears in every level. The platforming can be as simple as jumping up some evenly placed ledges to as complex as jumping around on floating furniture in the middle of the room.

Stitches as a game was designed around both of these core concepts in addition to the original goal to tell a complex and compelling narrative, but that will be touched on later.  For now, it would be good to talk about the first thing that we did right with this project…

What Went Right

1. A devoted and motivated team.  In order to make any piece of collaborative media work, the people working on it need to be up to the task and ready to handle any hardships or roadblocks that might come their way.  That was us throughout most, if not all of the development time for this project. On paper, this game should’ve fallen apart very early on just going by our team structure alone. Our development team consisted of 5 designers, 1 producer, and 2 artists.  You’re reading that right, we had a whole 0 dedicated programmers. Was that a problem? Well, it should’ve been. However, we had two designers step up to the position of programmers very early on and they brought us through the absolute thickest of it.  

Of course, that wasn’t the end of of either, both of our active level designers had never worked as puzzle designers before.  Much like in the previous instance though, they put their nose to the grindstone and learned as much as they could about it to put together some very solid puzzles for the game.  Everyone on the team was able to show their adaptability and drive to make this game succeed in one way or another.  

Even when the team ended up losing 2 of its members midway through production, we were able to adapt, reprioritize, and work through the rest of the game while still keeping pace with the original goal for the game.  

2. Communication lines were always open.  One of the most important things for a collaborative team to have is communication between its members.  Our team was no different and we had this communication in spades. While our interactions between each other at first were fairly minimal, as soon as the production of Stitches was in full swing, it was an oddity for anyone on the team to not be constantly communicating with each other.  The usage of meeting essentially every single day and working on the game together made the overall production process much less stressful and more productive too.

Being able to walk a few feet to ask a team member what they’re working on, or what they meant by a line of code made it so much easier than sending a message through an online message board and waiting to hear back from them.  In-person meetings were essentially the saving grace of this project and for very good reasons.  

Even during the times that the meeting got off-topic, it only helped to bring the team as a whole closer together.  While we weren’t as productive during these times, it definitely helped to make the project a lot more personable. That’s an important factor too, when people like the team they’re working with, they’re more likely to want to do work for that team.  The production process is meant to be fun, and a good chunk of that is having a team of people you work well with.  

3. The drive to improve.  Everyone in the team went about some kind of personal growth during the production of Stitches, as mentioned before, many of our teammates were ready and willing to put their noses to the grindstone and make sure that we had what we wanted.  However, the lack of any super strong egos and the whole team’s general willingness to be open to peer feedback was incredibly helpful as the development process continued forward.  

For some of us it was improving our time management skills, for others it was expanding our knowledge of our current roles, and for others it was simply learning how to work better and more efficiently with others.  Regardless of what members of the team you would look at, by the end of the development process, they had grown substantially both as a team member and as a game developer.  

Giving a more specific example, our Product Owner and Creative Lead began this project just as a designer.  During development though, they had to learn how to properly manage a team and how to divide up each team members time during every week long sprint.  In addition to this, they also had to handle what pieces of the game would be worked on during each week. While at first, they were really not good at this and it caused some issues that will be talked about a little later.  As the development process went along, they slowly began to get the hang of things by the end of things it was hard to tell that they had started out in such a shaky manner.

4. Documented tools and scripts.  A major help during development was how well documented a lot of the programming things were.  There were pages of documentation that taught team members how to properly use Git, our narrative script, manipulate our in-game sounds, and many others.  This made a lot of the general issues that we as a team could’ve had simply not exist. The documentation being readily available for us was a massive help as we didn’t have to wait on someone in order to answer a simple question.  

What Went Wrong

1. Learning the tools.  While not always a consistent issue, there were plenty of team members who were in a state of anxiety over using some of the tools that were being used by the team as a whole.  While in the long run this didn’t cause too many hassles, it was still something to make note of. While we did document a good chunk of the things we had planned to be using, there were some members of the team that had trouble gaining confidence in the usage of these tools strictly through reading documentation.  

This also leads into a bit of repository management.  When working collaboratively, it is always good to learn the best practices for these tools as well.  A major issue that ended up appearing on multiple occasions were issues with the repository. Some of these issues were minor and easily fixed, but some of them were massive issues that almost cost us the entire project.  There are a lot of things we could’ve done to prevent these things, but the simplest one was to branch our repository more often. There were multiple points during production where we could’ve easily had every member of the team working in a different branch, but that wasn’t what happened.  

This lead to team members needing to manually adjust their versions to match others, or in some cases just completely remove their work and have to redo it.  With such a simple solution ahead of us, it was unfortunate that we still run into as many problems as we did.  

2. Lacking feedback.  A major recurring issue with our QA sessions was not necessarily with our game itself, but with the questions we were asking our players.  In the short time we had to ask our testers questions, we opted to focus on specialty points in every test instead of getting our players views on the game at a general baseline every time.  This would’ve really helped to see how our testers thought about our game as a whole instead of just getting their input on very specific pieces.  

In addition to this, we should’ve made plans around the fact that we knew we would only be getting a minor amount of official QA sessions and opted to send whatever builds we had out to trusted friends or other people within the curriculum to get feedback and used that as well.  While unofficial QA isn’t always as reliable, it would’ve definitely helped to get some extra feedback and thoughts on the direction the game was taking.  

3. Planning too far ahead.  This is something that was mentioned earlier on, but we had a very bad habit of talking about features and pieces of the game that wouldn’t be relevant until later on and left some of the “here and now” features and game pieces to fall to the wayside.  This caused some very rushed work in certain sprints that had to be worked on again, or even fully replaced later on.  

In many cases, we were thinking about the final end goal of how the game would play and what it would look like without actually planning out how we were going to get there.  This wasn’t a fully consistent issue as our team leads began to crack down on these issues later on into production, but it made the early stages of development very sloppy in some areas.  

Going off of that, the overall vision of the game ended up missing pieces as well.  While our team had an idea in mind of what we wanted to create and what we wanted to base our experiences around, we waited a very long time to get a fully painted picture of what our final product would look like and play like.  Much like many of the other issues in here, this caused some unfortunately packed sprints that gained more work about halfway through because something was forgotten about when originally sprint planning.  

4. Early stages of communication.  This was one of the weakest aspects of the team early on in production.  While many of these issues were fixed as production continue forward, not all of it was resolved in a timely manner.  In the beginning of production, we had about 1 “work meeting” a week at most. This means the team was, for a majority of the first half of development, working separately of each other.  This caused a rift in some ideas and made it difficult to tell what each team member was working on.  

Another issue that came up were some technology issues with our messaging board called Mattermost.  We ran into multiple unexpected issues like team members not receiving messages properly, or being logged out of the program and not being made aware of it, as well as a lack of being able to schedule certain things like daily scrum review.  

Speaking of scrum review, this was another issue that persisted for most of development.  From the beginning we never really had any sort of standards or scrum structure introduced to the team.  On many days that we would meet in person, instead of a review of what we had fully done, responses would be kept to something like “no work done since the meeting”.  There were some instances where team members would follow the general daily scrum structure of “What did you work on? What are you planning to work on? and, Do you have any impediments?”, but they were few and far between.  

At the End of it All

There were many rough patches during the development of this game, but there were even more areas where we, as a team and as individuals, were able to grow and this allowed us to create something unique and fun.  Is it the best it’ll ever be? No, not even close, in fact there’s probably still a ton of room for it to grow and be even better than it is right now. That being said, at the end of it all, we worked our butts off to make this and it definitely shows.  
Stitches originally started out as a chibi detective game that took place inside the minds of criminals with bright flashing lights and anthropomorphic animals.  Change is a part of the game development process and everyone on the team has experienced it in one way or another. This is probably the most important thing about this whole experience, is that now we know for a fact that we can do it better next time.