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.
2. Documentation, pre-production and scheduling. These three words strike fear in the hearts of most students and programmers. But for us, documentation, pre-production, and scheduling went really smoothly.
During the first two months of the project, these three things should be a developer's main focus. The rule of thumb I learned is that during this time, and until the game is fully planned, a developer may prototype, but shouldn't start writing engine code.
Something that worked really well for us was splitting up the work and designating one documentation master to each document (pick people who enjoy this kind of work or they will seriously resent having to do it). We had to create three main documents for our project: a technical document, a production document, and a publishing document. Our technology lead took charge of the technical document, while I handled the publishing and production documents. From there, we both assigned modules of the documentation to each of our teammates, who then completed them and returned them to us to polish and compile.
While we were writing the documentation, we also had to do pre-production work. We approached it as if we were doing research and planning for the project. One part of the pre-production phase that was extremely important and helpful to Smashout's development was doing a walkthrough of the game. Everyone on the team sat down and walked through the entire game (not including all the levels), mapping out everything that could happen, what we wanted the player to feel or see in each situation, and how the game should react. The walkthrough was extremely important to our design process because once we started production, we were able to look back at it whenever we needed to figure out how a menu, level, or feature was supposed to work.
Here is where having only five team members really became useful. If one of us wanted something to go a certain way, we only had to convince four other people that it should be done. We also began researching all our core technology at this time, which enabled us to prototype early (discussed more below).
Scheduling is quite possibly one of the hardest things to do for any project, but for us it went very smoothly because we constantly updated our schedule. We came up with all the main features of the game and tech early so we were able to write our schedule based on those features. Another core feature of our scheduling was to schedule breaks. We only scheduled 40 hours of work per week and took the weekends off. Giving the team time off is something that is hard to do on a five-month project, but I've learned that if developers (even students) don't take time off, they will not get as much done and they will not have happy teammates.
3. Rapid prototyping and getting the games in the hands of the user. One thing that worked really well for us was prototyping our modules very early to see how they would work. The most important one we made was a small gameplay prototype. After extensive whiteboard prototypes, we decided to make an actual working version of our game.
We made the prototype quickly (in about a week), and asked teachers and other students to play it. We came up with about six different control schemes and put these into the prototype and made it so the player had the ability to change the control scheme on the fly. We did this so we could begin gathering information on how the game would play and identifying problems that would occur while building the full game.
After we came up with the prototype, we decided we wanted as many people as we could get to help test it. We set up a blog and an email address and began asking everyone we knew if they would help test our game. We had more than 100 testers, including some members of the GameCareerGuide forum (thank you), and their feedback was invaluable.
Just having the testers was not what made them so invaluable. It was the method we used for getting builds to them and information from them -- Smashout Fridays. Every Friday, we would put out a new build of the game along with a list of questions that we specifically wanted answered by our testers: How are the controls? What do you think of this feedback effect?
A database of all our testers was used to keep track of basic information about them as game players and their answers to the questions asked each Friday. This allowed us to quickly figure out how valuable their feedback was and weigh it. Since we were making a casual game that we wanted to be accessible to non-gamers, we always tried to focus on fixing the things that non-gamers complained about. Thanks to this testing method along with our early prototype, we designed a control scheme that works really well.
4. Data-driven design (DDD) and how the art team used it. One thing that we emphasized early on while developing Smashout is that we wanted to make the game completely data-driven through XML files. For those of you who are not programmers, basically, DDD decreases the amount of time spent compiling the game and allows developers to easily adjust things on the fly.
While working on the game, our policy was "no magic numbers," and, "If you suspect that something might need to be changed, put it in a file." These two rules pushed us to make almost everything in the game able to be changed quickly. Where this system was really powerful was in our effects system. The effects system was what controlled all the feedback effects that are seen in the game: text effect, particle effects, sound effects, and so forth. Within these files, we could define an effect as being a sound, or a sound and particle, or any combination of effects, and we could add time delays and things like that.
The reason this was so powerful is early on we decided that we wanted our game to be very feedback-heavy; and effects are things that take a lot of tweaking, so we decided to implement a system that would allow us to adjust the effects fairly easily.
At Full Sail, student developers are assigned to an art director at the beginning of the project. The art director usually helps the students with the visual and audio design and feel of the game. We were very lucky to get Casey Coffman, who specialized in audio, seeing as Smashout was to be very heavy on audio feedback.
The really great thing that came our of art team, Casey and a 2D artist, was their willingness to learn and help with the game. At the beginning of the project, we asked the art director if he wouldn't mind learning the scripting system for the effects so he could put them into the game, and he gladly took up the challenge. As a result, we were able to send him builds constantly, and he was able to place new art into the game whenever he wanted, speeding up our art integration by days.
5. Stand-up meetings. Throughout the project, we adopted some very basic Scrum methodologies for our meetings. At the beginning of each day of work, we held a quick stand-up meeting, where we stated what we were going to work on for the day and with whom we would need to interact. During these meetings, it was my job to compare what people said with their schedules; we also used this time to address any problems with the schedule.
The daily meetings allowed us to stay on task, flexible, and able to help each other with tasks. At the end of the day we would do a quick recap and see how close people were to finishing their tasks, checking once again to see if anyone was having any specific problems.
One of the best things that came out of the meetings was our ability to cut features and focus our time on the most important things. Before each milestone, we would meet and decide which priorities were highest for completing the milestone. We were able to cut things that were unnecessary and focus on what would make the game polished and fun.
What Went Wrong
1. Lack of testing protocol. While working on integration, we oftentimes had modules that would not even work or would not work at all how we intended them to. Had we set up some sort of module testing protocol, we could have avoided this problem and saved ourselves a lot of time.
In some cases, it was very obvious that the module just hadn't been tested. Sometimes the modules would appear to work until the moment a bug popped up, which we would fix, and then 10 more would appear. Even though having a formalized testing protocol in the process would have saved us time, I'm not sure we would have had time to fully implement it properly.
2. Personal issues. Throughout the project, a few team members faced a number of personal issues and family situations. One of our team members was going through a hard time with his girlfriend and was having some financial problems, which caused him to be stressed, which resulted in him not sleeping well, which affected his work and the way he treated the rest of the team. He would show up late for meetings and not let us know that he was going to be late and would also fall asleep while working. These kinds of issues caused delays, not to mention a little bit of bitterness, from the team.
If we had had more open communication with each other when these issues were affecting someone's work, this would not have been such a big issue. When working on a game development team, each person comes to rely on every other person. If someone's work is slipping because they aren't showing up on time or are falling asleep on the job, but the rest of the team doesn't know that there is a serious personal or emotional problem behind it, the team is likely to interpret the person's actions as them being lazy or not caring about the project -- in other words, "he is letting us down." Then resentment kicks in. On the other hand, when people explain a personal problem that is directly or indirectly affecting their work (or their attitude), then there can be more understanding of their behavior, and thus better efforts by other team members to support not only the individuals, but their work in relation to the project, until they can catch up again.
While this was not something that we could have necessarily "fixed," we could have definitely handled it better.
3. Unwillingness to ask for help. One issue that would plague us every so often was when someone was really stuck on something but would just keep hammering away at it without making any progress. With a few modules, we would see someone slipping on his schedule during the stand-up meetings and we would ask why things were slipping, and instead of saying "I'm stuck" and asking for help, the person would just say, "Things are coming along," or, "I was caught on this, but I'm about to work it out."
For the stand-up meetings to work and for each student to work well on a team, every person needs to know when to ask for help.
4. Uncomfortable work environment is not conducive to work. Unfortunately, Full Sail does not provide a workspace at all times. The school does have open labs for a few hours every day, but the Smashout team needed to find a place where we could work for long stretches. At the beginning of the project, we tried meeting at different team members' apartments until finally settling on mine.
Using my apartment as the workspace worked well enough but was not ideal. There were too many distractions and not enough tables. While we tried to create a more efficient environment in the space available to us, it still pales in comparison to having a real office.
5. Pigeonholing gameplay bugs. Near the end of the project, we began getting a lot of feedback about bugs and a need to polish the game, almost all of which had something to do with the gameplay. By now, our technology lead had switched exclusively to gameplay, meaning he caught the brunt of the work in terms of bug-fixing. Because he was the only programmer trying to deal with the bulk of the workload, he got bogged down. If we had planned it better, we would have had more people helping with the gameplay and therefore would have had more people who were familiar enough with that code to help fix bugs.
Ball Now in Play
Working on Smashout was not only a great learning experience, but also a lot of fun. We were very proud to finish this game and glad we were able to stick so closely to our initial design, as well as get all the features in on time.
We were told that it is rare for a game to come out of Full Sail with so much audio and visual feedback. The real payoff came when we gave a presentation and the audience was really into the game -- even watching it was exciting. Afterward, people were able to play the game on an arcade machine. We had accomplished what our teacher was always hounding us about: "Make it fun and done."
While we didn't make a very long game or one that breaks new ground in any real way, we were able to make a project that we are proud of, looks good in our portfolios, and is fun to play. Since the completion of the project, everyone from the team has been able to show off Smashout proudly, to both friends and future employers.
Grant Shonkwiler graduated from Full Sail University in June 2008 with a bachelor degree in game development. He is now employed in the game industry in Philadelphia. He was the project lead on Smashout.
Release date: June 17, 2008
Platform: PC, Full Sail arcade machine
Total development time: 5 months from concept to finish
Software used: Microsoft Word (documents), Microsoft Project (scheduling), Visual Paradigm (UML), Microsoft Visual Studio 2005 (C++), Adobe Photoshop (2D art), Audacity, Maya (3d Models), AlienBrain (source control)
Total lines of code: 45,842 without comments
Team: Grant Shonkwiler, project lead; Naveen Nattam, technology lead; Franklin Ludgood, render lead; Scott Rodda, interface lead; Charles "CP" Wilkinson, asset lead.
Full Sail Production Team (Teachers): Casey Coffman, art director; Phil Marunowski, 2D art; Jason Hinders, external producer.