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
  • Student Postmortem: Full Sail's Smashout

    - Grant Shonkwiler
  •  Smashout is a 3D breakout style game developed at Full Sail University last spring. It was the final project for a group of five students in the undergraduate game development program. (All students must complete a five-month game project with a team of five to seven people.) I was the project lead for the Smashout team, White Board Logic.

    At the start of the project, we were given one week to come up with two separate game ideas, spec them out, and prepare a pitch for the final project staff. We came up with two completely different game ideas and were genuinely excited about both of them, so when our casual arcade style game, Smashout, was picked, we were elated.

    In Smashout, the player rotates paddles to deflect a ball and break bricks. Although this may sound fairly simple, we added a few things to make the game more interesting. For one, we created three main types of bricks: red, green, and blue. In addition to each color brick having a different hit-point value and points value, the color is also used to calculate the multiplier. All three of the main objects in the game -- bricks, paddles and the ball -- use these three colors to calculate the multiplier. The ball is the only object in the game that changes color; any paddle that it hits will become that paddle's color too. For example, if the player hits a blue paddle, the ball turns blue; now if the player breaks a brick of the same color (blue ball breaks blue brick), the multiplier increases. If the ball happens to break a brick that is not the same color (blue ball breaks red brick) the multiplier resets.

    The player is also able to select where the ball will launch from. There is a set of launch points in each level to choose from, and this allows the player to create a strategy for each level. We also used effect bricks in the game, which either help or hinder the player depending on what she or he is trying to do at the time. Finally, for balancing issues we added the ability to slow down all the elements in the game, except for input, using Granny Style, which is limited.

    Throughout Smashout's development, we really wanted to make a game that would be fun and easy to play. Thanks to the level editor we used, we were able to try out many different level schemes (and allow other people to break them), but we feel like the final ones used in the game are the most polished and the most engaging. By including just a few objectives in the completed game and a small number of levels, we were really able to focus on polishing the final product and making the gameplay fun and engaging.

    What Went Right
    1. Design and technology scoping. One of the biggest problems student projects have is over scoping. Students do not have an unlimited budget (neither do professional developers for that matter). Students also don't have a full programming, art, and design team, nor do most of them have much time. There's not much use in trying to make the next Oblivion or World of Warcraft. It's not going to happen.

    When coming up with our original ideas, we had a set of criteria for what we wanted to accomplish. For instance, it was a priority for us to make a playable demo that could be enjoyed in less than three minutes. The criteria we established forced us to limit the number of levels we would have to design and the amount of features the game would need.

    Another reason having a narrow scope helped us was it eliminated the need for advanced technology. I asked Naveen Nattam, our technology lead, what he thought about this. "When we set out to make Smashout," he said, "we knew that we did not want to pursue advanced tech, specifically graphically. While our rendering lead was interested, he was also very wary of how much time could be sunk into visual effects that would leave the game suffering overall. With the team focused on an overall complete experience, we skimped where we could on technology that would require heavy research and development. By being able to avoid this, we had more time to fix existing tech bugs that would appear, rather than constantly putting in new tech by the end."

    Over scoping can be one of the biggest downfalls of a student project. My team's advice to other student developers is to make sure to design and plan something that is feasible with your existing resources, time, and skills.


comments powered by Disqus