Archives
With this game development entry I want to describe a bit of my decision process for the gameplay of Bank Shot (AKA OddBall). As described in this post, Bank Shot is an iPhone physics-based puzzle game where your goal for each level is to score 3 different balls in a basket by firing them out of a cannon. Each of the 3 balls is handled by the physics a bit differently (one ball is bouncy and gets more bounce off walls, another is a sponge ball that is lighter and floats more, and the third ball is a heavy metal ball). The "puzzle" part of each level involves the player figuring out how to get the balls around obstacles by using powerups, skilled shots and strategy. My problem as the game designer is to figure out how to keep this gameplay fun, but also challenging without becoming too frustrating.
My first gameplay iteration had the player using one ball at a time. You needed to pick a ball to use and score it in the basket before moving on to the next ball. But this seemed to fragment the idea of having 3 different ball types: you couldn't interact the different balls with each other or create interesting strategies that combined ball behaviours and powerups. It also made the idea of scoring 3 balls in the same basket a bit more monotonous as you would likely just use the same strategy all 3 times for most levels. So this eventually evolved into the ability to have all 3 balls in play at once. The user still controls one active ball at a time, but you can leave a ball in play doing "something" to help clear the way for the next ball. For instance, the basket might only be easily reachable with the bouncy ball because it needs to bank off a wall and around obstacles nicely into the basket but the other balls can't bounce enough to reach. So perhaps the bouncy ball could first depress a button to open another way to the basket. Once the other balls have scored with this other way the bouncy ball could stop depressing the button and be fired from the cannon again and bounce off the wall to score and complete the level. This idea of the balls "helping" each other and playing off each other opens up a lot more possibilities for both the level design and for how a player might solve each level.
My next gameplay iteration involved the interaction of ball powerups. I've designed 4 powerups that can be applied to each ball by the player. These powerups transform the ball in some form to allow it to interact with the environment differently. For instance, one powerup gives the ball spikes so it can stick to surfaces, and another gives the ball a parachute so that it floats and can be affected by environmental effects such as fans/vents more. But how can I restrict these powerups in a way that doesn't just let the player abuse the powerups to easily complete each level and also so it isn't too restrictive and frustrating for the player? This is even more important when you consider one of the powerups allows the player to pause the active ball and boost it in any direction. If the player could continuously use this ability they could simply boost the balls around all the obstacles without much thought and ruin the puzzles.
At first I had the idea that each level would apply a restricted number of uses to each powerup (for instance I could set the boost powerup to be used only 2 times for a certain level). But this had many problems. Firstly, it would mean that I would have to determine, as the level designer, a good number of uses for each powerup for each specific level. This means I need to think of how I personally want each puzzle to be solved, which not only adds a lot of work to the creation process but also restricts the player by imposing my restrictions on their possible puzzle solutions. It also means that players of different skill levels are forced to solve the puzzle with the skill level I have determined. I want puzzles to have many different solutions and I want to allow the players to feel open to solve each level in their own way. So rather than applying arbitrary restrictions on the use of powerups, I started to think about rewarding the player for using them less instead.
With this method, I decided on using the player's score to manage powerup usage. Every time a powerup is used, it reduces the player's score by a set amount. A player receives a score for each level based on how well they completed that level. So when players complete a level/puzzle by scoring all 3 balls they receive a sense of achievement, but if they complete it with a higher score that sense of achievement should feel greater. With a global leaderboard that I plan to implement, the more hardcore players will want to complete each level with the best score possible in order to compete on the leaderboard. Players that simply want to blast through all the levels easily can use the powerups more freely but will receive lower scores. This will help in restricting the powerups for the more skilled players, but something more still has to be done in order to prevent the more casual players (the ones that don't care much about their score and who only want to beat the level) from just using the powerups non-stop. Again, this should be inherent as part of using the player's score to manage powerups.
By using the simple restriction that a player's score can't go below zero, a player can only use powerups if they have earned some points to spend. Each powerup will require a certain amount of points to use (this will have to be carefully playtested in order to determine which powerups are more powerful and should cost more). So when a player earns points by scoring a basket with another ball, or by reaching a token in a hard to reach part of the level, or by doing something else to raise their score, the player will be able to use powerups more often for that level if they want. Those players concerned about a high score will try to complete the levels with as few powerup uses as possible. More casual players can use the powerups more freely at the cost of a lower ending score for each level, but still within a restricted number of uses. I may also start the player with a certain score on each level in order to allow the use of powerups right away at the start of a level.
So with this score management method I think I have covered all the bases I was concerned about:
- Casual players don't have to think about it too hard and they can use powerups more freely at the cost of lower scores
- More hardcore players will have the added strategy of preserving powerup usage for higher scores
- While there aren't hard set restrictions on the number of powerup uses per level, there is still an inherent way in the system to prevent players from using powerups too much
- I don't have to impose my own solutions on the players for each puzzle, they are more free to solve them however they like
- Players have the added choices of which powerups they want to use and when, for instance they could use 1 boost powerup to score a ball at a certain cost, or perhaps they could use 2 cheaper powerups instead and score for the same or less cost of points
However, even with this solution I realize that gameplay designs can sound good "on paper" but don't always work well when implemented. While I'm optimistic this solution will work well once I have created some more levels to test with, I am still prepared to go back and rethink this design decision if need be. So, if you've suffered through reading this whole entry, what are your thoughts on this design decision? How might you approach the problem differently? Feedback is welcome in the comments below!
This entry posted by Graham
in OddBalls
Tags: Game Development
I'm impressed! I love reading other peoples' approach to game design, the problems that crop up, and the solutions to them. I like that your solutions don't punish the player with unnecessary restrictions, they just empower more score-hungry players.
If it was a single player game, then costing points to use the powerups might be too easy but with global leader boards it should lead to some really interesting solutions to some levels.
Well you are right. It could become too easy if I don't also ensure players can't get too many points on any level. Remember that each level has it's own score (not one score for the whole game). Also you have to first do something like score 1 of 3 balls to get points on a level, so you can't just start using a bunch of powerups without first planning out a strategy to ensure you can score all 3 balls. But yes, as the level designer I will still have to account for levels not being too easy for scoring an unreasonable number of points.
Is this the alex jordan and graham davis who developed a map for the HL mod Firearms called obj_bocage? If it is, I am looking to convert that map to Day of defeat:classic (1.3) Do you have the .rmf file? Please email me. Thanks.
Oops, my email is pruitt99@yahoo.com
Graham, you sent me an email and I deleted it as spam before I realized it was about Firearms. Please email me again but this time send it to hellskitchen_dod@yahoo.com and in the subject line just put Firearms map. Thanks.
Graham, I was hoping you had the .rmf file for a map you made for Firearms called obj_bocage. We would like to convert it to Day of defeat 1.3. If you have it would you send it to either pruitt99@yahoo.com or hellskitchen_dod@yahoo.com Thank-you very much for your consideration.
I know it has been several years, but I am still looking to find out if this is the same Jordan and Davis who developed a Firearms map called obj_bocage and whether you still have the .rmf file. I would like to convert that map to day of defeat 1.3. Any help here would be appreciated. Thanks.