Archives by Month - November 2009
"Cold Sundays" tracklisting:
1. Abstract Soul - Inamorata (So Deep) (Original Mix)
2. Dubsativa - Nexus 6 (Original Mix)
3. Stan Kolev - Across Bengal (Original Mix)
4. Paul Hardy, Moodymanc - Sizzler (Original Mix)
5. FreezerRoom - Weapon Of Choice (Fish Go Deep Vocal)
6. Sebastian Davidson - Sunday Morning (Original Mix)
7. Evren Ulusoy - The Night Is Young (Original Mix)
8. Orion & Mango & J Shore - Raining In Osaka (Bale & Voltaire Remix)
9. Ross Couch - Changing Seasons (Original Mix)
10. The Craftsmen - Estrella (Earnshaw's Deep String Remix)
11. Ross Couch - Pure (Original Mix)
12. Shane D feat. Kerry Wood - Silence (McHale & Peddie Mix)
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!
I've also been spending a fair bit of time on my Bank Shot (AKA OddBall) iPhone game. I have about 90% of the basic gameplay code complete, and I'm just wrapping up a good chunk of the HUD and menu system code now. Tweaking the HUD and GUI has been a bit finicky and time consuming, but soon I will be able to focus more of my time on the actual graphics and level design. Up until now most of the work has been on central code systems to ensure the basic gameplay works and that everything can communicate with each other. My next phase of development includes learning a new 3D modeling program, creating 3D models, skins and animations, designing out some levels and a flow for the game progression, and updating all the little graphical nuances that need attention. So there is still a fair bit of work and a lot of polish to complete before the game is ready to play. But things are moving fairly smoothly now.
I also recognize that I haven't posted a single development video of the game yet. I'm now looking into recording some of the basic systems I have working and posting it here as part of my development diary. Most of the graphics are placeholders so far, but it will be good to share how the game will work and possibly get some feedback. Going too long without any outside feedback can lead to tunnel vision and result in a less balanced game experience. Also, my goal is to start morphing this blog more towards a development diary, at least in part, and so I should really start posting more frequent updates about the specific development I am doing. So you can expect some short videos here soon.