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

    [08.12.14]
    - Livio De La Cruz

  • PART THREE: Pre-Production Done Right

    Fixing our Creative Process

    Given how much time we had left, we might have been tempted to just rush through the pre-production phase so that we could have had a concrete idea to work on again. But considering that the biggest mistakes of the Senses Project happened during pre-production, we were very careful to make sure we did things right this time.

    When planning our new pre-production phase, we knew that we had to center the process on the creation of prototypes, and we knew that we had to figure out how to work as quickly and as efficiently as possible. In other words, we were thinking about rapid prototyping, and our final plan ended up being based around the popular 2005 paper "How to Prototype a Game in Under 7 Days"by the Experimental Gameplay Project.


    To the rescue!

    First, we decided to create a "core prototyping team", which consisted of only two people: myself and Zuoming Shi. The plan was for each of us to create a fully playable prototype of a completely new game idea every week for four weeks (so eight prototypes in total, four per person). At the end of this phase, the entire team would help us select the most fun prototype, and we would then spend the remaining six weeks turning that prototype into a full game for the competition.

    The small size of the core prototyping team was in part due to the fact that Zuoming and I were the only ones with the skills to be on such a team, because we were both game designers who could program. However, the small team size was also a conscious decision to increase our pace by decreasing the number of people working on the same thing. Having one person do all the work for a single prototype, from brainstorming to programming, was the only way that we could have made so many prototypes in such a short amount of time.

    Of course, we were concerned that the team experience would be hurt by the fact that the vast majority of the team would have nothing to do during pre-production. It was a very real risk that team members might start to drift away from the project if we didn't have anything for them to do for such a large amount of time. We at least tried to collect ideas from the rest of the team during the team meeting every week, but it was hard for most members to feel like they were contributing meaningfully, especially since it was entirely up to the core prototyping team to decide which ideas to prototype next.

    The extremely short time limit for each prototype not only kept us moving at a fast pace but it also discouraged us from overthinking our ideas too much. One of the things that went wrong during our first attempt at pre-production was the fact that we would try to think very hard about whether an idea was "good" or not, when the only real way to answer that question was to make a prototype and play it. Following this new rapid-prototyping process taught us to not be so critical of our own ideas before trying them out, which in turn led to more creative ideas being prototyped.

    One would think that the pressure from the quickly-approaching project deadline would have hurt our creative freedom by discouraging us from pursuing risky ideas. However, the fact that we had planned to build so many prototypes actually made us feel more secure about pursuing such ideas, because we felt like there was a good chance that at least one of our prototypes would be good enough for the IGF.

    Rapid Prototyping and the Creative Process

    Even though rapid prototyping was a very challenging and demanding process to follow, I personally found it to be extremely thrilling. The main reason for this is because it was the first time that I had ever found myself absorbed in the design process for a video game.

    To understand what I mean, it's important to know that I have a lot of experience designing things in other media, and the design process that I follow for every media usually feels the same. Whether I'm working on a website, a poster, a video, or even a paper, there is a distinct "zone" that I tend to get into as I iterate on my work over and over again. I've never been able to get into that zone with video game design, mostly because how much time and focus it takes to implement certain ideas into code. However, during the rapid-prototyping phase of this project, I was finally able to enter that zone, and I felt like I had done my best game design work yet as a result.

    Rapid prototyping was more than just a challenge to implement something into code quickly. For me, it was a process by which I could explore and change the idea as I was building it. The goal of each prototype wasn't just to be fully playable in the mechanical sense, but to also offer a fleshed-out vision for what the game could potentially be like. In other words, rather than creating crude versions of some larger idea, the goal of a rapid prototype is to capture the full essence of an idea, which often involves the need to mold your idea into a smaller, more coherent vision that can potentially stand alone as its own small game experience.

    Basically, what kept me in the zone was the fact that everything was now framed in terms of the following design problem: "How can we quickly build this idea so that it delivers a good experience?" Ironically, that problem statement ended up defining the rest of the project, not just our prototyping phase.

    The Fruits of Pre-Production

    Our plan to build eight prototypes in four weeks didn't go as smoothly as we hoped. We were only able to build five prototypes, and it took us five (not four) weeks to do it. Rather than making one prototype per week, we instead found ourselves making one prototype every other week. Making these prototypes in a single week took up so much of our free time that we found ourselves burnt out for the following week as we struggled to catch up with some of our other classes.

    The pre-production phase was still a great success, however. We were able to come up with some really interesting game ideas, and we learned a lot of useful design skills. The following sections are a list of all of the prototypes that we've made, in the order that we made them. You can see that the earliest prototypes had quite a lot of energy put into them, but then that energy seemed to decrease with the later prototypes as we became more burnt out and busier with school.

    Prototype 1: Fighting Blind

      
    Play this prototype at: http://interguild.org/livio/prototypes/FightingBlind.html

    I started prototyping the day after we made the decision to reboot and before we really made the final decision on how exactly we were going to handle pre-production. I spent the first few days of the week brainstorming while using strategies that I learned from John Cleese's Lecture on Creativity, and by Wednesday I had come up with a cool idea that I wanted to try out: a game about ninjas fighting in the dark.

    This prototype turned out to be a pretty good boost of motivation for the team, because it proved that our crazy plan for pre-production was not only feasible, but that it could also lead to some really interesting results. This prototype has a certain level of "coolness" to it, but it also had a lot of major design risks that made us want to find a better idea to pursue.

    While playtesting this prototype, we found that the blindness mechanic wasn't as confusing to figure out as I feared. In fact, the prototype usually left a great first impression with people, but the crudeness of the fighting mechanics and the lack of a win condition quickly made the prototype feel pretty cheap. A big risk about this prototype was the fact that we probably didn't have enough time to make a fighting game that was deep enough to satisfy players. Although, it would have been nice make follow-up prototypes in order to experiment with different fighting mechanics.

    I was also hoping that the gameplay would be slower paced, where players would have to think carefully about giving away their positions, but we found that many players preferred to frantically move around because it was very easy for them to lose track of themselves once they stopped moving. Perhaps this idea would have worked better as an online multiplayer game or a single-player experience, so that we wouldn't have had to hide the player's own avatar from them.

    Prototype 2: Detonator

      
    Download this prototype at: http://bit.ly/DetonatorPrototype

    This next prototype was made by Zuoming, and the basic idea was to make a puzzle game based around solving large and flashy chain reactions. This prototype featured several levels with different ideas on puzzles that could be made with this mechanic. Although, during playtesting we found that some of the levels had some very baffling designs that could only be solved through trial and error.

    Unfortunately, this didn't turn out to be one of those ideas that immediately grabbed one's attention. The gameplay didn't seem like something that could stand alone as its own game, because I've seen it before as a smaller part of larger games. However, it was pretty funny to see that some players thought the playable character was a refrigerator, and that premise alone could have turned into a pretty interesting game.

    Prototype 3: Particle Racer

      
    Play this prototype at: http://interguild.org/livio/prototypes/ParticleRacer.html

    For the third week, I tried to tackle my favorite genre: racing games. The idea was to have a racing game where traffic vehicles behaved more like a fluid particle system, so that rather than clumsily crashing into every obstacle they encountered, traffic vehicles would instead gracefully dodge things as smoothly as possible. I didn't really know if this would turn into a fun game, but I figured it would at least be a fun system to play around with-and it'd probably just look cool visually.

    Unfortunately, this was my first attempt at programming a racing game, and figuring out how to get the controls to feel smooth was not trivial. I didn't even get collision detection working properly before I decided to cancel this prototype. We decided that if the scope of the idea was too big to prototype in a single week, then it was probably too big to make into a full game in time for the submission deadline. We also figured that writing the AI to get the behavior that I was looking for would probably take longer than expected, so cancelling this prototype and working on another idea was simply the smartest thing to do.

    Prototype 4: Runner

      
    Download this prototype at: http://bit.ly/RunnerPrototype (Windows Only)

    Zuoming's last prototype was like a cross between CANABALT and Super Crate Box. The idea was to challenge the player to reach the end of the level as fast as possible while giving them a variety of weapons to use along the way. Unfortunately, the prototype failed to create the sense of urgency that he was going for because there wasn't any real penalty for being too slow. It also didn't help that the pace of running and shooting enemies was pretty slow, which made the game feel more like a generic run-and-gun platformer, rather than a fast-paced running game.

    Prototype 5: Magnet Man

    I probably wouldn't have cancelled my Particle Racer prototype so easily if I hadn't already come up with another idea that I wanted to prototype. The idea was to have a single-player platformer game where the player controlled a ball-shaped man with the ability to attract and repel objects.

      

    In order to avoid any confusion with Mega Man 3‘s Magnet Man, I eventually renamed the character to "Maget Sam." This was a conscious reference to Samus from the Metroid Prime games, since some of my ideas on how to use the magnetic powers reminded me a lot of the series's morph ball puzzles (I don't think Magnetic By Nature existed back then).


     

    Unlike my previous prototypes, which were programmed strictly in ActionScript 3.0 for Flash, I decided to use the educational software called Stencyl for this prototype because it had a built-in physics engine. After I got the basic mechanics working, I found myself playing in the debugging level for quite a long time. I spent a lot of that time thinking about how much fun the mechanics turned out to be, but I was also thinking about why the game just didn't feel like it was going in the right direction for some reason.

    The physics just seemed a little too random and imprecise for puzzles, and I also just couldn't shake the feeling that having the player navigate a level probably wouldn't be the most interesting way to use these mechanics. When I imagined the player running to the right and using these magnet mechanics to move things around in order to solve problems, it just didn't feel right in my head.

    Later that night, when my brother saw me playing with the prototype, he noticed that I was using the magnetic powers to slingshot blocks around me and throw them around at really high speeds. He pointed out that it looked like I was trying to shoot the blocks into some kind of goal. When I heard that comment, I immediately thought of some kind of soccer field, and I knew instantly that I just had to try that idea out. I was so eager to change the direction of the prototype that I forgot to save a copy of the single-player version of the game.

    Prototype 5, v2: Magnet Ball

      
    Play this prototype at: http://interguild.org/livio/prototypes/MagnetBall.html

    If you were to play this prototype, you might notice the completely baffling control scheme. The main reason was because this prototype was designed to be played with gamepads rather than a keyboard. Back when we were playtesting the Fighting Blind prototype, we learned that players were usually uncomfortable when crowding around a small keyboard together, and I just didn't want that issue to ruin someone's experience again. Since the only gamepads that I owned were two PlayStation 3 controllers, I downloaded a program that would allow me to map the button presses on the controllers into simulated keyboard presses that Flash could understand.

    It's ironic that the idea for Magnet Ball didn't appear until our very last night of pre-production. We had already extended our pre-production phase by a week, and we were going to hold a team meeting during the following morning to decide which game idea we were going to pursue until the IGF deadline. Basically, after five weeks of prototyping, we ended up choosing an idea that was only a few hours old. That decision wasn't much of a gamble, however, because Magnet Ball was clearly the most fun prototype that we had.

Comments

comments powered by Disqus