Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Get the latest Education e-news
  • Postmortem: Magnet Ball

    - Livio De La Cruz
  • This article was originally posted on my blog Superheroes in Racecars.

    The following is my honors thesis, which is a research paper that I had to write in order to graduate with Honors from the University of Arizona. While I did try to adapt the tone of the paper to be more fitting for online reading, the paper is mostly unmodified, aside from a few major additions made to part four.

    I'm going to warn you now; this paper is LONG. One of the goals when I was writing this was to show enough detail so that students who wish to try running a project like this could learn from our process and our mistakes. This project was a ton of fun, and I hope you'll have fun reading about it.


    This paper is a retrospective for a game development project that was run by a team of nine undergraduate students from March 2012 to January 2013. Our main goal was to make a student submission to the 2013 Independent Games Festival (IGF). Our submission (Magnet Ball) failed to get nominated for the IGF, but the project did fulfill its underlying goal, which was to help us gain experience with important software engineering and project management skills.

    The bulk of the information in this paper is about how we experimented with both our development process and our creative process. Unlike most software engineering projects, game projects require a rather large amount of design work. The creative process that one follows is often tightly dependent upon one's development process, and vice versa. Therefore careful thought must be put into how to balance both the technical and creative needs of a project. During the first half of this project, we ran into many problems due to several flaws in our development and creative processes. However, during the second half of the project, we were able to fix these problems by mastering rapid-prototyping techniques.

    The Team

    This project was put together entirely by undergraduate students at the University of Arizona. Below are descriptions of everyone and their contributions:

    Livio De La Cruz (Game Designer, Programmer, Project Lead)

    Livio is a computer science student, an aspiring game designer, and the founder of the UA GameDev Club. He worked on the game's design and programming, while also working with Tyler to manage the project.

    Tyler May (Producer, Project Lead)

    Tyler is a business management and creative writing student, an aspiring game producer, and president of the UA English and Creative Writing Club. He started the project with Livio, and was responsible for helping all of us coordinate and communicate with each other.

    Zuoming Shi (Game Designer, Programmer)

    Zuoming is a computer science student, an aspiring game designer, and president of the UA Asian Music Club. He worked with Livio on game design problems and the game's programming.

    Amy Pribadi (Artist, Animator)

    Amy is an art student, who was primarily responsible for creating both concept art and in-game artwork as well as animations.

    Pooria Rashidi (Artist)

    Pooria is an art student and aspiring concept artist. He contributed a lot of concept artwork as well as background artwork.

    Valerie Dugie (Writer)

    Valerie is a creative writing student, an aspiring game writer, and published author. She was in charge of writing the game's narrative.

    Scott McGowan (Sound Designer, Musician)

    Scott is a computer science student, and he's a member of a band. He worked with Logan to write songs for the game, and they also wrote programs to modify the musical experience of the dynamically based on events.

    Logan Barnes (Sound Designer, Musician)

    Logan is a computer science student and musician. He worked with Scott on the music and sound effects for the game.

    Teresa Frazier (Programmer)

    Teresa is a computer science student who contributed to the programming of some of our prototypes.


    Magnet Ball is a two-player, physics-based, Flash game, where players use attraction and repulsion powers to shoot magnetic blocks into the other player's goal. You can currently play the game at:

    Magnet Ball Slopes

    The purpose with this project was to submit a game for the 2013 Independent Games Festival (IGF), which is a highly respected festival that features some of the best independently-published video games of the year. Throughout the course of this project, we ran into countless problems that almost killed the entire project, but we were able to pull through by being adaptive and quickly learning from the mistakes that we were making.

    Adapting to your mistakes is not an easy thing to do, because it often involves making painful and risky decisions. For instance, when we were a few months into the project, we decided to abandon the game that we had built so far and restart the entire project from scratch-just two months before the submission deadline. This was an extremely bold decision, but we felt it was necessary because we desperately needed to fix many of the mistakes that we had made at the beginning of the project.

    Fortunately, the project reboot worked remarkably well, and it didn't have as bad of an effect on team morale as we expected. More importantly, we learned a lot of lessons about how to approach the pre-production phase of a game project, how to manage a team of students, and how to maintain a healthy creative process while still following a productive development process.

    This paper will tell the story of the entire project, from both before and after the reboot. Specifically, it will focus on the various things that went right and wrong, how we adapted to our mistakes, and what we learned from this experience.

    PART ONE: Recruiting and Managing People

    Starting the Project

    This project started in March of 2012 while I was attending the Game Developers Conference (GDC) with my friend Tyler May. Walking around the career pavilion and talking to recruiters really helped us realize how important it is to have completed at least one long-term game project. Since the University of Arizona did not have a formal game development curriculum, Tyler and I already knew that we would have to work on extra-curricular projects in order to gain the experience that we needed to get hired. However, being at GDC really instilled a greater sense of urgency within us, and we also found ourselves excited and fired up over the idea of starting a new game project.


    After we attended the conference's awards ceremony, part of which featured the IGF Awards, Tyler decided that he wanted to start a game project with the goal of submitting it to next year's Independent Games Festival. The deadline for student submissions was on October 31st, which meant that he only had about six months to put a team together and make something. I initially resisted joining his team, because I knew that I definitely didn't have the time for it. But as I offered him advice on managing the project, I quickly caved in and joined, mainly because the project sounded like it'd be too much fun to pass up.

    We knew that this project was going to be a great learning experience, not just for us, but for everyone who would eventually join the team. Knowing this, we decided to not worry so much about whether we were doing things the "right" way and to instead focus on doing whatever worked best for us. This was a great decision, because otherwise we would have simply found ourselves trying to mimic different project management techniques without ever really understanding those techniques. What we instead did was to actually manage the project, rather than foolishly expecting a step-by-step development methodology to manage the project for us. This meant that when things went wrong, it was our job to understand what part of our process was broken and how to fix it.

    This really put our project management skills to the test, and it encouraged us to experiment with different techniques and strategies for managing this project. These experiments did in fact lead to many of the things that went wrong with the project, but the lessons that we learned from these experiments were invaluable to developing our understanding of how student project teams work and how best to manage them.

    Designing the Team Experience

    One of the best things that we did for this project was to set design goals for the kind of experience that we wanted our teammates to have while working on this project with us. We understood that we were asking people to sacrifice a lot of their time, without any compensation, for a crazy project that would most likely fail. And so I suggested that we approach the problem from a game design perspective in order to make sure that the project was as fun as possible for everyone involved.

    Tyler and I eventually came up with a very clear vision of what the team experience should be like for this project. We wanted to create a team that we would all love to work with, a team that would want to stick together even through the most difficult hardships. We hoped to make every individual teammate feel like this project was their game, something that they would each feel passionate about. We also wanted every team member to feel a strong sense of camaraderie and attachment to their teammates.

    For me, having this kind of team experience had always been a dream of mine, and it was the main reason why I decided to join this project. I was much more interested in the adventure of trying to make it to the IGF rather than actually making it, and having a good team experience was a very crucial ingredient in order to make sure this adventure was as fun and as exciting as we wanted it to be.


    At the time, we knew that perhaps the most rational way to put the team together would have been to figure out what kind of game we were going to make first, and then put a team together based on what skills we needed for that project. However, in order to create the kind of team experience that we were aiming for, we instead chose to recruit the entire team first and then decide what type of game we were making later based on what the team could do.

    We did this because we wanted to include everyone in the initial brainstorming and pre-production sessions in order to give them a greater sense of ownership over the game. This was a very bold decision, and we saw it as a way of demonstrating just how much we valued the team experience above the quality of the final product.

    This isn't to say that we weren't serious about our goal to make it to the IGF. In fact, we took this goal extremely seriously, which is partly why we were putting so much effort into setting up the right team. If our team members didn't think we were taking this challenge seriously, then they would have been much less interested in joining us on this crazy journey.

    The Recruitment Process

    Once we had defined our vision for the team experience, we had to figure out how to convey this vision in order to attract potential teammates. Since Tyler was the team's producer and since he was better at communicating with people than I was, we decided that he would be in charge of setting up the recruiting process. We made a webpage with information about the project, and we tried to make sure that people understood why the IGF was worth aiming for, what kind of team experience we were aiming to create, and why people should trust us as teammates.


    Unlike most student projects, which are generally pretty informal and carefree, this project had a fairly elaborate recruitment process. First, a student would contact us expressing interest in the project; then we'd schedule an interview with them; then over the course of a few days, the team would discuss the candidate and compare them to other candidates; and finally, after a week or two, we'd notify the applicant about whether they've been approved or rejected. The whole system made people feel as though they were applying for a job, and some even decided to dress rather formally for the interview.

    We decided that Tyler was the best person to send out the rejection emails because he was skilled at giving people bad news without being too blunt about it. Meanwhile, I was the one who typically sent out the approval emails, which usually started with this large image embedded into the message:


    The high barrier to entry and the dramatic approval email, encouraged new team members to really value their positions on the team, which made it far more likely that they would stay loyal to the team throughout the entire project.

    As we added more team members, we were worried that newcomers might start feeling like they were outsiders to the group and that there was a "core team" within the team that made all the real decisions. We wanted every team member to feel as though this was their project, as if they were part of the "core team", so we decided to include every team member in the recruitment discussions and interviews as much as possible. This meant that once you were approved onto the team, your first task was to help the rest of us decide who to approve or reject next. New members suddenly found themselves on the other side of the interview table, asking questions to the new applicants, and thinking seriously about who would make a valuable new addition to the team.

    This approach was perhaps one of the best decisions that we made during the recruitment process, because it really did help a lot of members feel as though they were part of the "core team." It was also a great way to instill a sense of trust into our new team members, because these were very important responsibilities that we were entrusting them with.

    We spent over a month recruiting team members. We considered 26 different people, and we ended up with a team size of nine people. Part of what took us so long was the fact that we had to schedule interviews with almost every one of them, and we also had a lot of difficulty spreading the word about our project to the university's art and music departments.

    Unfortunately, Our Team was Too Big

    We were well aware of how risky it can be to have too many people on the team, because we've seen other student projects collapse as a result of this problem. However, knowing this still didn't stop us from ending up with nine team members, which is pretty huge for a student project. I think we had a few assumptions that made us rather careless during the recruitment process:

    First, we were comforted by the idea that we had a dedicated producer on the team. We figured that any risk that came with having a few extra teammates might be mitigated by having someone whose entire job it was to coordinate the various team members and to make sure tasks got done. And while it was true that the project would have probably caved in on itself without Tyler holding everyone together, having a team that was larger than what we needed still drastically slowed us down. Coordinating nine people together brought so much overhead that it made our preproduction phase move at a crippling pace, even during our most productive moments. The slow pace of progress was significantly hurting the team experience for most of us. There were long stretches of time when half the team didn't even have anything to do, which was a real shame especially after we had managed to get them all fired up at the beginning of the project.

    Too much overhead was ruining the adventure.

    Second, we became too ambitious, so we started adding people not because we actually needed them but because we thought that they would help take the project in a really interesting direction. This is mainly what happened when we added Valerie as the team's writer. And while it was true that she did indeed take the project in an interesting and exciting direction, it definitely didn't help with the team's crippling overhead.

    Third, due to the fact that we were recruiting without knowing what type of game we were going to make, there was a risk that we would find ourselves in need of a skill that we failed to recruit for, and the way that we responded to that risk was by adding more people to the team. For instance, since we weren't sure what platform we would develop for, we ended up with three programmers. Likewise, since we couldn't find any animators, we hired two artists.

    In other words, we were more afraid of not having enough people than we were afraid of having too many people. Unfortunately, our priorities should have been reversed. As we eventually learned later in the project, it's much easier to deal with a shortage of talent than it is to deal with a surplus. When you don't have enough people on a team, you can usually improvise and work around the problem. However, when you have too many people on the team, they just drag the team down while hurting everyone's experience.

    Availability and Communication Problems

    The overhead of a large team wasn't the only thing that slowed us down. After we had finished recruiting, we only had less than a month left before the spring semester ended. During the summer, we no longer had the luxury of having in-person meetings because we were all going to be at different parts of the world. We were so spread out that we had to worry about time zones every time we set up a virtual meeting. Some of the places that we were telecommuting from included: China, Alaska, Oregon, California, Arizona, Virginia, Rhode Island, and Italy.

    This had the obvious effect of drastically decreasing the amount of communication between team members. We at least did a pretty admirable job of keeping our limited communication channels open: we used mailing lists, Facebook groups, Skype calls, Google Hangouts, Gmail chats, text messages, Word and Excel documents synced through Dropbox, and even good, old-fashioned phone calls.

    Our team's private facebook group.

    Unfortunately, it could never be enough. You just can't replace the amount of information that tends to get exchanged when people have casual conversations with each other. Furthermore, trying to communicate with someone who wasn't currently online was very time consuming, because you would usually have to wait several hours for a response.

    On top of those problems, there was also the fact that many of us simply weren't as available during the summer as we had hoped. Some of us had internships to worry about, while others were frequently travelling outside of an Internet connection.

    I was especially unavailable during that summer, as I already had two family trips planned, and a teaching assistant position at the SISTA Game Design Workshop. Even though I tried my best to keep up with this project, I felt like I was always a little behind on the current state of the project. My commitments would interfere with my availability every few days, so I had a habit of starting something, getting interrupted by an event in my life, and then coming back a few days later to find my work outdated and obsolete. It was a really demotivating cycle that seriously hurt our team's performance.

    I think most of us vastly overestimated how much time we would have over the summer. We saw summer vacation as this mystically large expanse of time in between semesters, rather than the 15 short weeks that it really was.


comments powered by Disqus