Archives by Month - January 2012
Much of the work I've been doing on OddBall lately has to do with the in-game console. I should first describe a bit about my design of this game world in order to explain the purpose of the in-game console. You see, OddBall is primarily a casual puzzle game, but I have also built a bit of a story and world around the premise of the game. As a game designer, one of the things I endeavour to do is create compelling worlds and environments for players to interact with. Rather than solely having a set of sterile game mechanics and rules to follow (which can be fun on their own), I still want the player to be immersed in the game world. So having even a small amount of back story and "reason" that describes what the player's presence means in the context of the game world is important to me. The player can still choose to ignore this, but at the very least having a story provides me, as the designer, with direction for the game.
As a player in OddBall, you are a recruit assigned to test OddBalls in the OddBall facility. Through your iPhone touch screen, which is designed to feel somewhat like an interface for remotely controlling OddBalls, you fire OddBalls through test levels. By puzzling your way through these test levels with the OddBalls, you are in fact testing the OddBalls and their capabilities. Now, this isn't the most inspired or deep premise for starting a story, but it's something that gives some context when you start playing the game. Of course as you play and progress in the game, more of the story becomes revealed and you begin to unravel possibly more sinister reasons for being recruited. But, I won't spoil that. The point is, as minimal as this premise is, there is at least a bit of story that explains your place in OddBall.
As you play and progress through the OddBall facility levels you are given tips, instructions, sarcastic encouragement, and sometimes criticism from your trainer. In this way, you learn how to play and use new abilities, you are provided with feedback, and ultimately you are rewarded and learn more of the story. My goal in designing this part of the game has been to ensure it doesn't interrupt the player's regular flow of just playing the game. This is a casual mobile game after all, and I want players to be able to easily and quickly play levels without much hassle. But as I've described above, I also want to convey a bit more depth for the game world. Balance is key here. So, because audio is often muted by game players on iPhones, and because having lots of audio in a mobile game would make the game/app much larger in file size to download, I've opted to convey this information through a text console in the interface (rather than having the trainer talk with audio).
So far so good, but now we are dealing with conveying a modest amount of typed text within the game interface on a very small iPhone screen. Obviously I can't type much information in that space before it begins to block out the regular game view for the player. Again, balance is key here so I've designed the system around the regular flow of the game. At the start of every level (when there is a natural pause from playing to load the next level), the text console grows to cover most of the screen. In this enlarged console a series of short but succinct messages are provided to the player from the trainer. The player can skip these easily if desired with the click of a button. Afterwards, the level begins as usual and the console shrinks down to a single small window within the main game interface. When the text console is in this shrunken state, very short one line messages can still be transmitted to the player as he/she plays. This system allows me to provide a bit of story and feedback to the player from another character in the game between and during levels without being intrusive to the main gameplay.
This feature has been built into my game for a while now, but I've been continuously tweaking it and making improvements. For instance, in order to make the typed text feel more like it is coming from another person in the game (rather than just appearing on the screen like a pre-rehearsed script), I've developed a system to allow the text to appear one character at a time as if it were being typed out in real time by someone. And when that still seemed robotic, I designed a way to input brief pauses in the typing for even more of a realistic feel. But as always, balancing this is important because of the inevitable desire of players to just play and the possibility of it typing too slow. The text needs to appear fast enough that players aren't waiting to read it. They can always skip it, but for those that want to read the messages and don't want to feel punished for doing so, I need to make sure the text appears quickly enough that it's not frustrating. Balance.
So, at this point I have one character being typed every 0.03 seconds, with strategic pauses in between, and it flows quite nicely. However, this week a new problem crept up. At the end of every level I present the player with a scoreboard to show how well they did. This scoreboard is displayed in the expanded text console and styled in a way that looks typed out by the trainer. But I need this to type faster than usual because it is not text that flows like a proper sentence. It has padding, dashes, and other formatting in order to frame the score values nicely - nobody wants to read that typed out one character at a time unless it's really fast. And simply displaying it all at once is too sterile and robotic. So, having it typed at a faster speed makes sense, and making my system do this was simple because I've designed it to allow for dynamic speed changes. This is where I ran into an unforeseen problem.
You see, when I run and test the OddBall game on my MacBook it runs blistering fast at 1600 FPS. The iPhone is different of course. The lower hardware specifications and other restrictions on that device mean my game runs at only 30 FPS. Which is actually perfect. Anything less than 30 FPS would be a problem because it would feel stuttery and unresponsive, but once you get up to 40-60 FPS on the iPhone it consumes more battery power and it becomes a drain on the device. So 30 FPS is a good place to be. However, the keen observer will have noticed that I mentioned typing my usual text at one character every 0.03 seconds. But at 30 FPS, I'm only getting 1 frame every 0.033 seconds. So I can't physically make it type faster than that on the iPhone with the way I've designed my typing system. It works fine on my MacBook, but once I tested it on the iPhone - whoops!
So, this problem is what I've been addressing in my code this week. I've been working on adding support to my typing system so that it can type chunks of text every X seconds instead of just typing one character at a time. With this new addition, I can tell the scoreboard text to type chunks of 6 characters at a time, instead of just one. And it's almost working. It still needs a few tweeks before it is done. And I can hear it calling me now to complete it, so it's time to return to the code!
As a player in OddBall, you are a recruit assigned to test OddBalls in the OddBall facility. Through your iPhone touch screen, which is designed to feel somewhat like an interface for remotely controlling OddBalls, you fire OddBalls through test levels. By puzzling your way through these test levels with the OddBalls, you are in fact testing the OddBalls and their capabilities. Now, this isn't the most inspired or deep premise for starting a story, but it's something that gives some context when you start playing the game. Of course as you play and progress in the game, more of the story becomes revealed and you begin to unravel possibly more sinister reasons for being recruited. But, I won't spoil that. The point is, as minimal as this premise is, there is at least a bit of story that explains your place in OddBall.
As you play and progress through the OddBall facility levels you are given tips, instructions, sarcastic encouragement, and sometimes criticism from your trainer. In this way, you learn how to play and use new abilities, you are provided with feedback, and ultimately you are rewarded and learn more of the story. My goal in designing this part of the game has been to ensure it doesn't interrupt the player's regular flow of just playing the game. This is a casual mobile game after all, and I want players to be able to easily and quickly play levels without much hassle. But as I've described above, I also want to convey a bit more depth for the game world. Balance is key here. So, because audio is often muted by game players on iPhones, and because having lots of audio in a mobile game would make the game/app much larger in file size to download, I've opted to convey this information through a text console in the interface (rather than having the trainer talk with audio).
So far so good, but now we are dealing with conveying a modest amount of typed text within the game interface on a very small iPhone screen. Obviously I can't type much information in that space before it begins to block out the regular game view for the player. Again, balance is key here so I've designed the system around the regular flow of the game. At the start of every level (when there is a natural pause from playing to load the next level), the text console grows to cover most of the screen. In this enlarged console a series of short but succinct messages are provided to the player from the trainer. The player can skip these easily if desired with the click of a button. Afterwards, the level begins as usual and the console shrinks down to a single small window within the main game interface. When the text console is in this shrunken state, very short one line messages can still be transmitted to the player as he/she plays. This system allows me to provide a bit of story and feedback to the player from another character in the game between and during levels without being intrusive to the main gameplay.
This feature has been built into my game for a while now, but I've been continuously tweaking it and making improvements. For instance, in order to make the typed text feel more like it is coming from another person in the game (rather than just appearing on the screen like a pre-rehearsed script), I've developed a system to allow the text to appear one character at a time as if it were being typed out in real time by someone. And when that still seemed robotic, I designed a way to input brief pauses in the typing for even more of a realistic feel. But as always, balancing this is important because of the inevitable desire of players to just play and the possibility of it typing too slow. The text needs to appear fast enough that players aren't waiting to read it. They can always skip it, but for those that want to read the messages and don't want to feel punished for doing so, I need to make sure the text appears quickly enough that it's not frustrating. Balance.
So, at this point I have one character being typed every 0.03 seconds, with strategic pauses in between, and it flows quite nicely. However, this week a new problem crept up. At the end of every level I present the player with a scoreboard to show how well they did. This scoreboard is displayed in the expanded text console and styled in a way that looks typed out by the trainer. But I need this to type faster than usual because it is not text that flows like a proper sentence. It has padding, dashes, and other formatting in order to frame the score values nicely - nobody wants to read that typed out one character at a time unless it's really fast. And simply displaying it all at once is too sterile and robotic. So, having it typed at a faster speed makes sense, and making my system do this was simple because I've designed it to allow for dynamic speed changes. This is where I ran into an unforeseen problem.
You see, when I run and test the OddBall game on my MacBook it runs blistering fast at 1600 FPS. The iPhone is different of course. The lower hardware specifications and other restrictions on that device mean my game runs at only 30 FPS. Which is actually perfect. Anything less than 30 FPS would be a problem because it would feel stuttery and unresponsive, but once you get up to 40-60 FPS on the iPhone it consumes more battery power and it becomes a drain on the device. So 30 FPS is a good place to be. However, the keen observer will have noticed that I mentioned typing my usual text at one character every 0.03 seconds. But at 30 FPS, I'm only getting 1 frame every 0.033 seconds. So I can't physically make it type faster than that on the iPhone with the way I've designed my typing system. It works fine on my MacBook, but once I tested it on the iPhone - whoops!
So, this problem is what I've been addressing in my code this week. I've been working on adding support to my typing system so that it can type chunks of text every X seconds instead of just typing one character at a time. With this new addition, I can tell the scoreboard text to type chunks of 6 characters at a time, instead of just one. And it's almost working. It still needs a few tweeks before it is done. And I can hear it calling me now to complete it, so it's time to return to the code!
This entry posted by Graham
in Velvety Couch Games
| Comments (1)
Tags: Game Development, OddBalls, Unity3D
