In this interview with developers Kurt Waldowski and Mike Padilla, they discuss how they used their mom to make sure their design had universally understandable instructions, the importance of planning out overall designs, and other challenges they faced while making a fun physics based indie title, Kinetics.
What was your process for coming up with the original concept for Kinetics?
Well, to start, this was the first big game Mike and I have made. Coming in we didn’t have any sort of a game plan. The concept for Kinetics arose when I was experimenting with physics in Game Maker. My initial thoughts were to make a ball drop and modify its trajectory. Even with the little crappy engine I made, I was quite entertained just bouncing the ball around. I instantly loved the idea of flexible puzzles that allowed for creativity, instead of a linear solution that the player must stumble upon. So, I guess you can say our initial motive for transforming a little physics engine into a full blown game revolved around this idea: We were interested to see how different people think.
What was your design production cycle like?
Well, initially we lacked a solid design document at all. But we will address that next; for now we’ll reference the design process after the reincarnation of the project.
We sketched up our plans, cranked out an engine, and made a prototype with a few levels. Because I have an independent study class in which I worked on my games, it was easy to get feedback. I pulled kids in and had them test the game. As many flaws were pointed out, this frequent input forced me to constantly redesign elements of the game. Through this process, we continued to polish the core engine to hell before we even started designing levels. However, when we did get to designing levels, the process was quite interesting. With graph paper to scale the screen size, one of us would design a level on paper while the other put his latest design into action within the game. We would flip flop, and test each other’s levels. Having “virgin eyes” viewing each other’s levels right off the bat helped make sure the designs worked, and were fun. The process was also very efficient.
However, the most interesting thing we did to aid our design helped simplify the game, and make it more accessible. We got Mike’s mom to test the game; and she claimed to have never played a videogame … Ever! Her lack of problem solving when it came to videogames truly exposed how poorly we communicated the directions of the game, and how flawed some of the controls were. Maybe people with “common videogame knowledge” would figure it out. However, we wanted to target everyone, not just core gamers. This forced us to overhaul multiple elements of the game,which was quite a pain, but extremely important. [Editor: This is a great example of designing for your audience. How your game works and what it conveys is different depending on the backgrounds of who is playing.]
Did you face any difficult design challenges in building the game?
Unfortunately, the whole first round of creating Kinetics was a challenge. Due to our lack of experience, and the spontaneous nature of the project, we didn’t have an initial plan or design layout. After playing around with the little engine we made, we knew we wanted an open-ended physics game where you bounced and maneuvered a ball to the end of the level. But that’s about it. We created a lot of trouble for ourselves by not being too methodical about the programming and not planning out our goals, ideas, or anything really. Hence, we ended up with a lot of bits and pieces of a game that didn’t quite fit together. Maybe a half year into the process our motivation dropped off and we more or less stopped working on it for a long time. I can’t quite remember why we decided to start working on it again, but I’m glad we did.
When we came back from the break, we both saw how unorganized and fragmented the game was and decided to start from scratch. This opened our eyes to how necessary it is to pre-plan.. From there, the game took off and our motivation rebounded higher than ever.
What big design successes did you have for the game?
Although the initial level designs aren’t all that crazy (we wanted to get the player used to the base mechanics before solving puzzles) we were very happy with our later level designs. We put a lot of thought and extensive testing into them. The variability in how each level can be solved while keeping the difficulty at a reasonable level (not too hard or too easy) was quite challenging. Each level allows for an array of different methods to succeed; many that we didn’t intend. As I watched others play test the early stages of our game, I was intrigued watching players argue with each other that their way was better, easier, more efficient, etc. The freedom the game gives you when it comes to solving a puzzle is a key ingredient. But what’s remarkable is exactly how each individual overcomes a given level without direct guidance; a solution I would never think of is someone’s natural instinct to succeed.
I was also happy with the amount of polish Mike pushed us to implement. He was quite OCD about how things were done, and helped make sure the graphics, physics, and other elements were polished to their highest potential. I think that had a huge part in turning this simple idea into a good game.
What design lessons did you learn from this game that you think might be applicable to other games you work on in the future?
Oh God; we learned sooo much. Having to start over from scratch revealed to us the heavy importance on early in-depth design. Additionally, the flaws in the game pointed out through feedback taught us some big design lessons. After seeing where our game excelled and where it lacked, I concluded that every good game needs five core elements: Concept, 10 seconds of fun, Incentive, Replay, and Polish. The two elements our game excelled in were 10 seconds of fun, and polish. To explain, 10 seconds of fun refers to the core mechanic of your game; as soon as someone picks up the game, within ten seconds, they should be having fun. If the core mechanic the player will be dealing with throughout the whole game isn’t fun, then the game won’t last. In Kinetics, just experimenting with the trajectory of the ball is fun within itself. In addition, we polished the hell out of the game. We made sure that everything ran smoothly and the presentation was nice. However, we lacked in Incentive, Replay, and Concept.
Incentive: Why should you play Kinetics? The current reason is to progress to the next level, or get high scores. However, because scores cannot be shared and they do not unlock anything, they hold no weight. No one knows what a “good score” even is, so that incentive is quite weak. Although the 10 seconds of fun might be present, over time interest will be lost as there is no real motivation to continue.
Replay: Once you’ve beaten the game, there should be a motivation to come back. Because my game lacks incentive, players may not even get to this element. I learned replay is essential for a good game; high scores could have aided in the replay value, but as I said before, a high score currently has no weight or meaning in Kinetics. Maybe an online exchange of score would have solved this problem.
Concept: Concepts make games feel new and interesting; bits and pieces from the other four elements make up the concept. Super Crate Box, for example, is new and innovative because of a twist in the concept: don’t kill enemies, collect crates. Kinetics was such a simple idea that the concept was lacking from the start.
Going forward, I know to cover all of these elements within my games. I feel they are essential to a game’s success, and had I designed Kinetics to include these, it would have been a bit more successful.
You can find Kurt’s blog here.
