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

  • PART FOUR: Prototyping until the Bitter End

    Our Creative Process during Production

    Once we decided to pursue Magnet Ball for our IGF entry, the next challenge was to figure out how to turn this little prototype into a full game in just a single month. When we assessed how much work had to be done on the game, we framed every task as a design question. We then prioritized those tasks based on the urgency of those design problems, and we proceeded to work on the game by making prototypes that would attempt to answer those design questions.

    For instance, rather than simply setting a task called "Make more stages," we asked the question: "What are some stage designs that would make interesting new scenarios?" Whereas the first problem statement simply emphasizes the need for the final result, the second problem statement encouraged us to see it as a design problem that required experimentation and playtesting to fully answer. With the rapidly approaching deadline, it would have been easy to just build the first ideas that came us and then just move onto the next thing. But these problem statements reminded us of the need to create a high-quality experience, and so we made time to iterate on our stage designs.

    Framing every task as a design question also encouraged us to do a lot more experimenting than we otherwise would have, and we very quickly developed a deep understanding of our game's design. Our creative process during this stage of the project was just amazing, especially considering how broken our creative process was before the reboot. We were definitely able to stay in that design "zone" throughout most of the production phase, because our problem statements were inherently asking us to keep our eyes on the experience that the game was actually producing, rather than simply on what features the game needed next.

    And that's basically what you need in order to have a healthy design workflow for video game projects. You need to find a way to stay focused on the experience that players are actually having, and then everything else that you do must in some way tie back to the goal of improving that experience. In our case, framing all of the work that we did in the context of design questions really helped us to maintain that focus. Because of this focus, we started seeing our programming tasks as just a means to an end for the sake of our design experiments, and this helped us to stay grounded when making certain implementation decisions.


    We were proud of many of the solutions that we came up with for some of our design problems. For instance, during playtesting we noticed that players would often end up in a state that we called "deadlock", which is when a tug of war would break out over a block with neither player wanting to let go. We experimented with a couple solutions, including one that featured a stamina bar, but the final solution that we came up with was to simply have the contested blocks explode (as the image above shows). Not only was this an exciting way to solve the problem, but it also added quite a bit of randomness to the match, which helped to keep matches from getting stale.

    We also spent a lot of time thinking about the different skills that players could learn while playing the game. We had a mental catalog of moves that players could perform, such as: the slingshot, the block hop, the meteor smash (reference to Super Smash Bros.), the kamikaze, the hover goalie, plowing, and much more. We really wanted to make these moves an explicit part of the game, but there just wasn't enough time. We also really wanted to create a better first-time experience for players who just want to figure out how things work, and we wanted to add features that would create a better interest curve for each match. Despite being really optimistic with respect to how much time we had left, we simply weren't able to bring the game to the level of polish that it deserved.

    Our Development Process during Production

    Our programming process typically had three steps. First, we would try to implement the feature as quickly as we could get away with, just so that we can see the feature running and be able to assess its quality. We'd then iterate on that feature's design, which would often require more-often sloppy-programming work. We would finally decide either to abandon the idea or to commit to it, but we wouldn't actually clean up our messy implementation of the feature until the mess started getting in our way. This meant that we only cleaned messy code if it was actually a problem, rather than cleaning it for the sake of cleanliness.

    The original prototype of the game was built using Stencyl 2.0, because it's a great tool for rapid prototyping, and the fact that it publishes your project to a Flash game made it portable and easy to playtest on other people's devices. However, Stencyl wasn't necessarily a good tool for building larger games that would eventually ship. We knew that it was a risk to keep developing the game on Stencyl, but at the time, we decided to take that risk because it allowed us to build off of the existing prototype, rather than having to figure out how to reimplement everything on a different platform.

    Unfortunately, we ran into a few very serious problems with Stencyl. First, the game's performance started slowing down drastically as we added more features to the game. Second, we realized from playtesting that playing the game with anything other than two gamepads was intolerable for many players, and getting gamepads to work with a Flash game was not easy. Fortunately, I have a lot of experience with developing for Flash, and Stencyl allows you to write ActionScript 3.0 code directly into the Flash project so that you could bypass Stencyl's internal programming language. The solutions that we came up with for both the performance problem and the gamepad problem were pretty impressive. We were doing things with this tool that probably no one had ever done before. 


    It was those kinds of difficult programming problems that also showed just how dedicated we were to creating a better experience for the player. Whenever we considered giving up and just leaving those problems in the game, we found our motivation by simply thinking about what the player experience would be like if we didn't solve the issue. We found that we had a pretty strong sense of advocacy for our players, and there were many cases when we simply refused to allow our players to have a bad experience just because we couldn't solve an important problem. We would eventually become very proud of our solutions, partly because they were difficult to arrive at, but mainly because we were simply proud of how much we were willing to fight for the sake of our players.

    Stencyl 2.0 didn't have any collaboration features, so we frequently found ourselves having to manually merge our work together. However, this wasn't such a bad thing, since this forced us to basically do a code review before every merge. For version control, we basically maintained a Dropbox folder with a copy of every single prototype that we had made:


    Having a copy of every single prototype was extremely useful, not just for our development and debugging process, but also for our design process. It was great to be able to go back to older versions of the game and compare current prototypes to past ones. For instance, while tinkering with the physics of the game, the only way to assess those design decisions was to just play different versions of the game at the same time and compare how they felt.


    Even though the submission deadline was on October 31st, we continued to work on the game well into January, which is when the IGF announced who the nominees were. Because we submitted our game as a webpage link, we were free to modify the game even after the submission deadline, and so our hope was to fix some of the more serious problems before the judges got a chance to look at the game. The team, however, mostly disbanded when the deadline had passed, because that was the official "end" of the project, and it would've just been disrespectful to expect them to keep contributing past that point.

    Thoughts on the Prototype-Centered Process

    The interesting part of the Magnet Ball project was that the game was essentially in a perpetual state of rapid prototyping, from the original inception of the idea to the final "release" of the game. The obvious benefit of this approach is that it's tailor-made for projects that require a lot of design work, such as games with particularly creative mechanics. The entire development process revolves around the designers' workflow and their need to iterate on the game. Tasks are prioritized based on their impact to the user's experience, and progress can be measured by how many iterations have been completed, rather than how many features have been implemented. This tends to encourage more creativity to emerge throughout the entire development process, rather than keeping most of the creative work contained towards the start of the project.

    However, this process comes with a few costs. First, it asks that the designers have a lot of skills. I personally see the concept of "rapid prototyping" as a skill set that needs to be mastered, rather than a development methodology that can be easily applied. This process also works best when the designers are also decently experienced programmers. It's hard to get in the "zone" of rapidly iterating on a design if you are not the one who is actively putting the product together. A good amount of programming experience allows the designer to be comfortable enough with the materials that they're working with so that they can stay focused on rapidly iterating on the design.

    The second major problem with this process is that it's not immediately scalable to large teams. While it's likely that a prototype-centered approach can work in large teams, it's just hard to iterate rapidly on something due to the overhead of a large team. However, this process is a great fit for small, independent studios, who often rely on innovative design work in order to make their game stand out in the market.

    Things I Would Do Differently

    As with any good project, I still have many regrets for things that I could have done better. So if I ever got the chance to do this project again, here are a few major things that I would do differently:

    1. Make sure you have enough time to work on the project. This means saying "NO" to as many other commitments as you can. When you're a student, you often have to fight for the time to work on your own projects, and sometimes it helps if you can pass your project off as research so that you can get credit for working on it.
    2. Figure out what you're making before assembling the team. Rapid prototyping is best done with a very small team, so there's no point in wasting people's time by not having any work for them to do. When you do start recruitment, you'll also have a much clearer idea of what skills you'll need, and you can use your prototype as a way of attracting teammates.
    3. Make sure everyone on the team has enough work to do and are able to do it. A big part of keeping your team engaged is about making sure they're able to do good work. If they simply don't know what they need to do, or if there are things that are getting in the way of their ability to work, then you're at a high risk of losing that teammate's interest.
    4. Do not work remotely. Avoid this at all costs. There is absolutely no good side to working remotely, especially when it comes to highly collaborative projects like this one. The ideal scenario would be to have everyone stay in the same town so that you can meet with each other regularly in face-to-face meetings.
    5. Schedule dedicated "working hours" where everyone works on the game together in the same room. This is something that we never even considered doing until after the project was over. The benefits of this approach are almost too many to list in this paragraph: you get increased communication, it's easier to collaborate with team members, you can ask someone a question and they're respond instantly, you get that sense of camaraderie that makes you feel like you're on a team, and you get the time management benefits of having dedicated "work hours" that are separate from all other hours.
    6. Don't forget to market your game! Because we were making our game exclusively for the IGF, we didn't have any plans for Magnet Ball outside of the competition. This meant that we never planned for a "release", and we never marketed, which means that basically no one ever played our game.

    In Conclusion

    And now it's finally time to end this monster of a paper.

    This project completely changed our understanding of how to manage and run game projects. This project went through a lot of ups and downs, but if there was one thing that really helped us, it was our ability to learn from our mistakes quickly and adapt on the fly. Postmortems for game projects usually talk about the mistakes that couldn't be fixed or avoided, or the mistakes that no one realized until after the project was over. But with this project we simply refused to let our mistakes control the fate of our game, and this is what motivated us to keep improving our process throughout the entire project.


comments powered by Disqus