Plan for Paul Dana
by Paul Dana · 09/06/2004 (9:05 pm) · 13 comments
The Best Laid Plans of Bits and Men...
Figure 1 Concept Art of Bits Fighting the Virus - by Kirk Alberts
Good things are happening with Bit Shifter. Last Plan I announced the start of the Bit Shifter Open Alpha where versions of our game were integrated with a web-based Questionnaire system for automatically gathering feedback on game play. We felt that our Arcade Strategy game in development, Bit Shifter, was done from the 10,000 foot view and from the 1,000 foot view. We decided to take this Alpha version to the public and seek help with details at the 100 foot view. The idea was to involve a wider audience while our plans were still flexible, before going into Beta.
That plan worked good. Really Good. In fact, too good. We got such great feedback we realized we were not as "done" as we thought we were. About 600 people participated in The Bit Shifter Open Alpha (BOA). We learned:
The flight model was the hardest criticism for me to hear because I had worked and worked on that sucker for so long. So much tweaking and revising...it was exasperating to hear people were still continually bump into the ground without meaning to. But that is what play testing is for. The improvement was a paradoxical way to get people to not bump into the ground...we added gravity. There were other improvements as well but adding gravity allowed the other changes in a way that combined to make a satisfying control scheme that everyone was happy with.
How it was...
To discuss what the game play lacked, let me review how the game worked back in May.
Figure 2 Fighting the Virus Back in May's Alpha
In the game Bit Shifter, you play the part of Flash Bios. You pilot the S. S. Scandisc through Bit World, which is a landscape that represents some circuits inside a computer. You pickup "Bits" which are like robots and take them to areas of the landscape that are infected by big glowing patches of red Virus. The Bits clean up the virus. You protect them and form them into Squads to help them protect themselves while you fly off to save other parts of the landscape from infection. You lose a level if all your Bits die, or if the Data Stream gets infected. The Data Stream appears as a river that passes through every level.
Figure 3 The Data Stream and Connecting Circuits
Figure 2 shows the Flash throwing Bits on a patch of red Virus. A Shell Turret has spawned from the Virus that Flash has shot and now it's burning. Figure 2 shows the Data Stream and the Circuits that connect to it. The Virus travels faster along the Circuits. This section of Circuit has become infected so Flash is throwing Bits down to clean that up before it reaches the Data Stream.
The action depicted in these two images was from the third map titled A2D. We used the first two maps to try to "train" the player in how to play the game, and they worked. But the game was sort of dull till this third map and so we needed a way to have the first map feature all the action and fun of this third map, but still "train" the player.
Two other problems we had were not problems with what we had finished but with what we had planned to do next. One was that this game play, while clearly awesome, was not going to be quite enough to make the planned 15 maps for the game. The problem was that Bits are quite vulnerable on their own. They can clean the Virus but need you to protect them. This makes for some great game play but it limits possible map game play scenarios because you cannot leave Bits on their own too long or the virus will kill eventually kill them.
The other problem was in how the player would obtain new Bits. At the end of the Circuit were Bit Zappers. As long as the Circuit was not infected and had power, the Zapper would slowly charge up. If a fully charged Zapper had a Binary Crystal on it...then the Zapper would fire, draining its energy, and turn the Binary Crystal into a Bit.
Figure 4 Bit Zapper making a Bit from a Binary Crystal
A second large NPC, called a Data Miner, would emerge from a cave periodically and bring a Binary Crystal to the Bit Zappers. This NPC was never made. The reason for this plan was to explain why there is a limit to how many Bits a given level can have...even if there are plenty of powered up Binary Zappers. Simple right?
No...not at all. Everyone thought it was an overly complicated "story" that did not make a whole lot of sense. Even the object, though pretty darn cool, does not scream out "Bit Maker" when you see it. We were also advised that the fact that you can make only so many Bits was not a detail that actually needed explaining...certainly going to all that trouble and confusing just to explain it was not worth it.
What we changed...
Solving the Bits-need-your-constant-protection also turned out solved the issue that the game play was too weak to go all 15 maps (and potentially expansion packs beyond that). We needed a solution that required no new key presses, and no job beyond the existing four of flying, shooting, picking up Bits, and throwing Bits. We tried having the bits assume one of three roles:
The Bits would just spontaneously assume these roles based on proximity to each other. This worked really well. It solved the issue of leaving Bits alone and simultaneously opened up enough game play opportunities for us to go 15 maps, 24 maps, and more. However this first implementation had two flaws. One was that now the old game play of using all your Bits for cleaning (even though they needed you) was gone. The other problem was that sometimes a bit you placed to clean up a critical area decided for itself to turn into a Fighter and wander off to fight, not cleaning the area you threw it on. So it took away control from the player.
The solution was to allow the player to organize the bits into Squads, which are arbitrarily labeled with letters A, B, etc...
Figure 5 Bits organized into Squads
The idea is that Bits will not take on Fighter or Medic roles unless you form a Squad. This allows us to retain the old game play while still getting the new game play while giving control back to the player we had inadvertently taken away. To form squads is very simple and requires no new key binds: you simply throw Bits close together and they form a Squad. Figure 5 shows Bits formed into Squads. It also shows the new game element, the pump, that draws power from the Data Stream to power the Circuits. The old game element looked like a paddlewheel.
The solution to the Bit Zappers was easy (in retrospect). We simply discarded the Binary Crystals and the Data Miners, and turned the Zappers into "Bit Makers" instead. Like before they slowly gain power when connected to a circuit, but it's more obvious that it's making a Bit now. If there is already a maximum of Bits on the map when fully powered, then they simply don't spawn another until an existing Bit dies:
Figure 6 Close up of new Bit Maker and a Shield Maker in the distance
How it Worked Out...
It is really working out great, especially now that we have Anthony Rosenbaum helping us out with some awesome Level Design. Anthony was our biggest fan when we showed the prototype last year at IGC 2003. He loved the combination of simple Arcade and simple Strategy. In fact his suggestions on improving the game came to mind when we were thinking up the Squad idea to solve our game play problems, so he was an obvious choice as a "map maker" in the sense of designing the Strategy game play for our maps.
Figure 7 The Squads in Action!
Once a map is fully play tested and we have squeezed the most fun out of Anthony's designs we will go back and add more items like trees and such so the world does not look so open and empty all the time, but right now we are following the fun where it leads us. That method has served us well up to now.
The final suggestion for change came from Jay Moore, which is to make the automated questionnaire system ask these four questions when a new tester signs up:
The idea is to be able to know which sort of person has this opinion of your game as well as what the opinion is, and to be able to filter out answers from players not in your target market, etc...
What is next...
Next is...you get to play this game! We are starting up the Bit Shifter Open Alpha again and this time it won't go away. The idea was to have a new version for testing every three or four days. We thought we were "done enough" to be ready for that back in May when we first tried to start the Open Alpha, but it turns out we were wrong. Now that we've addressed the issues the first Open Alpha taught us, we really are ready for this. Anthony has built us a rough draft of each of the 15 maps, even though the final baddy and weapons scripts are not complete. We will be ready to crank out a new map to test (or a revision of an earlier map based on alpha testing) once every three or four days from now until IGC 2004.
Nearly everything is ready but we need a period of testing before we "go live". The links to the Bit Shifter Open Alpha are real. If you want to help us work out the kinks feel free to signup and play. Once we know all problems with downloading and isntalling and answering the automated questionnaire system, I will submit a Developer Snapshot here on Garage Games to announce that B.O.A lives again!
Another thing to bear in mind is the COMIC of Flash Bios that everyone loved at IGC last year that you saw when the levels loaded. Not only have we not dropped that idea, we have elaborated on it and a six or seven page BACK STORY comic will precede the game itself both as a marketing tool and to help the user learn the game elements before he actually plays. Kirk Alberts has revised the characters and Jason Sharp has written an excellent Script...
But the best news of all is that Nauris Krauze has agreed to do the final ink and painting for the comics under Kirk's art direction! Naruis also has helped us with some concept art (Bit Maker). Check out this awesome "rough" of the comic:
Figure 8 "Rough" of comic by Nauris Krauze showing improved Flash emotions and use of color and style
Does Nauris just rock or what?
There is so much great stuff coming it will take me pages and pages to describe it. I am not sure we have time, though because there seems to be some sort of Virus attacking my position. Uh oh! I think I'm going to lose my connec
Figure 9 Paul Dana was disconnected from the system: Error 126: .Plan file too long...
Figure 1 Concept Art of Bits Fighting the Virus - by Kirk AlbertsGood things are happening with Bit Shifter. Last Plan I announced the start of the Bit Shifter Open Alpha where versions of our game were integrated with a web-based Questionnaire system for automatically gathering feedback on game play. We felt that our Arcade Strategy game in development, Bit Shifter, was done from the 10,000 foot view and from the 1,000 foot view. We decided to take this Alpha version to the public and seek help with details at the 100 foot view. The idea was to involve a wider audience while our plans were still flexible, before going into Beta.
That plan worked good. Really Good. In fact, too good. We got such great feedback we realized we were not as "done" as we thought we were. About 600 people participated in The Bit Shifter Open Alpha (BOA). We learned:
1. Our flight model was still not intuitive enough 2. The first maps were not challenging enough 3. Our plans for the "Bit Maker" was obscure to grasp and overly complex to build 4. There was not quite enough game play elements to stretch to 15 unique maps 5. The BOA system itself needed a small improvement
The flight model was the hardest criticism for me to hear because I had worked and worked on that sucker for so long. So much tweaking and revising...it was exasperating to hear people were still continually bump into the ground without meaning to. But that is what play testing is for. The improvement was a paradoxical way to get people to not bump into the ground...we added gravity. There were other improvements as well but adding gravity allowed the other changes in a way that combined to make a satisfying control scheme that everyone was happy with.
How it was...
To discuss what the game play lacked, let me review how the game worked back in May.
Figure 2 Fighting the Virus Back in May's AlphaIn the game Bit Shifter, you play the part of Flash Bios. You pilot the S. S. Scandisc through Bit World, which is a landscape that represents some circuits inside a computer. You pickup "Bits" which are like robots and take them to areas of the landscape that are infected by big glowing patches of red Virus. The Bits clean up the virus. You protect them and form them into Squads to help them protect themselves while you fly off to save other parts of the landscape from infection. You lose a level if all your Bits die, or if the Data Stream gets infected. The Data Stream appears as a river that passes through every level.
Figure 3 The Data Stream and Connecting CircuitsFigure 2 shows the Flash throwing Bits on a patch of red Virus. A Shell Turret has spawned from the Virus that Flash has shot and now it's burning. Figure 2 shows the Data Stream and the Circuits that connect to it. The Virus travels faster along the Circuits. This section of Circuit has become infected so Flash is throwing Bits down to clean that up before it reaches the Data Stream.
The action depicted in these two images was from the third map titled A2D. We used the first two maps to try to "train" the player in how to play the game, and they worked. But the game was sort of dull till this third map and so we needed a way to have the first map feature all the action and fun of this third map, but still "train" the player.
Two other problems we had were not problems with what we had finished but with what we had planned to do next. One was that this game play, while clearly awesome, was not going to be quite enough to make the planned 15 maps for the game. The problem was that Bits are quite vulnerable on their own. They can clean the Virus but need you to protect them. This makes for some great game play but it limits possible map game play scenarios because you cannot leave Bits on their own too long or the virus will kill eventually kill them.
The other problem was in how the player would obtain new Bits. At the end of the Circuit were Bit Zappers. As long as the Circuit was not infected and had power, the Zapper would slowly charge up. If a fully charged Zapper had a Binary Crystal on it...then the Zapper would fire, draining its energy, and turn the Binary Crystal into a Bit.
Figure 4 Bit Zapper making a Bit from a Binary CrystalA second large NPC, called a Data Miner, would emerge from a cave periodically and bring a Binary Crystal to the Bit Zappers. This NPC was never made. The reason for this plan was to explain why there is a limit to how many Bits a given level can have...even if there are plenty of powered up Binary Zappers. Simple right?
No...not at all. Everyone thought it was an overly complicated "story" that did not make a whole lot of sense. Even the object, though pretty darn cool, does not scream out "Bit Maker" when you see it. We were also advised that the fact that you can make only so many Bits was not a detail that actually needed explaining...certainly going to all that trouble and confusing just to explain it was not worth it.
What we changed...
Solving the Bits-need-your-constant-protection also turned out solved the issue that the game play was too weak to go all 15 maps (and potentially expansion packs beyond that). We needed a solution that required no new key presses, and no job beyond the existing four of flying, shooting, picking up Bits, and throwing Bits. We tried having the bits assume one of three roles:
1. Cleaner Bit which cleans Virus as normal 2. Fighter Bit to protect the Bits by fighting the virus 3. Medic Bit to heal damage done to Bits
The Bits would just spontaneously assume these roles based on proximity to each other. This worked really well. It solved the issue of leaving Bits alone and simultaneously opened up enough game play opportunities for us to go 15 maps, 24 maps, and more. However this first implementation had two flaws. One was that now the old game play of using all your Bits for cleaning (even though they needed you) was gone. The other problem was that sometimes a bit you placed to clean up a critical area decided for itself to turn into a Fighter and wander off to fight, not cleaning the area you threw it on. So it took away control from the player.
The solution was to allow the player to organize the bits into Squads, which are arbitrarily labeled with letters A, B, etc...
Figure 5 Bits organized into SquadsThe idea is that Bits will not take on Fighter or Medic roles unless you form a Squad. This allows us to retain the old game play while still getting the new game play while giving control back to the player we had inadvertently taken away. To form squads is very simple and requires no new key binds: you simply throw Bits close together and they form a Squad. Figure 5 shows Bits formed into Squads. It also shows the new game element, the pump, that draws power from the Data Stream to power the Circuits. The old game element looked like a paddlewheel.
The solution to the Bit Zappers was easy (in retrospect). We simply discarded the Binary Crystals and the Data Miners, and turned the Zappers into "Bit Makers" instead. Like before they slowly gain power when connected to a circuit, but it's more obvious that it's making a Bit now. If there is already a maximum of Bits on the map when fully powered, then they simply don't spawn another until an existing Bit dies:
Figure 6 Close up of new Bit Maker and a Shield Maker in the distanceHow it Worked Out...
It is really working out great, especially now that we have Anthony Rosenbaum helping us out with some awesome Level Design. Anthony was our biggest fan when we showed the prototype last year at IGC 2003. He loved the combination of simple Arcade and simple Strategy. In fact his suggestions on improving the game came to mind when we were thinking up the Squad idea to solve our game play problems, so he was an obvious choice as a "map maker" in the sense of designing the Strategy game play for our maps.
Figure 7 The Squads in Action!Once a map is fully play tested and we have squeezed the most fun out of Anthony's designs we will go back and add more items like trees and such so the world does not look so open and empty all the time, but right now we are following the fun where it leads us. That method has served us well up to now.
The final suggestion for change came from Jay Moore, which is to make the automated questionnaire system ask these four questions when a new tester signs up:
1. Age 2. Male/Female 3. Name of favorite game 4. Number of PC games tried in a year
The idea is to be able to know which sort of person has this opinion of your game as well as what the opinion is, and to be able to filter out answers from players not in your target market, etc...
What is next...
Next is...you get to play this game! We are starting up the Bit Shifter Open Alpha again and this time it won't go away. The idea was to have a new version for testing every three or four days. We thought we were "done enough" to be ready for that back in May when we first tried to start the Open Alpha, but it turns out we were wrong. Now that we've addressed the issues the first Open Alpha taught us, we really are ready for this. Anthony has built us a rough draft of each of the 15 maps, even though the final baddy and weapons scripts are not complete. We will be ready to crank out a new map to test (or a revision of an earlier map based on alpha testing) once every three or four days from now until IGC 2004.
Nearly everything is ready but we need a period of testing before we "go live". The links to the Bit Shifter Open Alpha are real. If you want to help us work out the kinks feel free to signup and play. Once we know all problems with downloading and isntalling and answering the automated questionnaire system, I will submit a Developer Snapshot here on Garage Games to announce that B.O.A lives again!
Another thing to bear in mind is the COMIC of Flash Bios that everyone loved at IGC last year that you saw when the levels loaded. Not only have we not dropped that idea, we have elaborated on it and a six or seven page BACK STORY comic will precede the game itself both as a marketing tool and to help the user learn the game elements before he actually plays. Kirk Alberts has revised the characters and Jason Sharp has written an excellent Script...
But the best news of all is that Nauris Krauze has agreed to do the final ink and painting for the comics under Kirk's art direction! Naruis also has helped us with some concept art (Bit Maker). Check out this awesome "rough" of the comic:
Figure 8 "Rough" of comic by Nauris Krauze showing improved Flash emotions and use of color and styleDoes Nauris just rock or what?
There is so much great stuff coming it will take me pages and pages to describe it. I am not sure we have time, though because there seems to be some sort of Virus attacking my position. Uh oh! I think I'm going to lose my connec
Figure 9 Paul Dana was disconnected from the system: Error 126: .Plan file too long...
#3
Gameplay looks very simple but also very fun. Excellent work.
09/06/2004 (10:18 pm)
Brilliant plan. Its great to see how a game evolves based on user feedback.Gameplay looks very simple but also very fun. Excellent work.
#4
09/06/2004 (10:26 pm)
wow :-)
#5
09/06/2004 (10:30 pm)
Great read and great artwork. Nice job! 
#6
These kind of development histories are very interesting to read. Glad to hear about the gameplay changes, and that the comic is still go. Joe and I were talking on Friday about how far Bit Shifter has come in the past couple months. You guys have done a great job, keep it up!
09/06/2004 (11:24 pm)
Woot!! I know how my morning's going to be spent tomorrow. ;) These kind of development histories are very interesting to read. Glad to hear about the gameplay changes, and that the comic is still go. Joe and I were talking on Friday about how far Bit Shifter has come in the past couple months. You guys have done a great job, keep it up!
#7
09/06/2004 (11:30 pm)
Yes, an excellent plan ... very descriptive.
#8
09/07/2004 (2:58 am)
Good stuff Paul, excellent to hear your dev story.. I hope we can all share a few at IGC too! 
#9
09/07/2004 (3:29 am)
I'm glad they let me on this bandwagon!!!
#10
09/07/2004 (9:05 am)
Paul - This is a great backgrounder for your session at IGC on Finding the Fun Factor. Finding not just a fun game mechanic, but one that has depth and wide appeal takes a passion for finding the sweetspot. 
#11
09/07/2004 (11:09 am)
Remarkable stuff guys. Very original and inspiring. Keep it up. :)
#12
Find the fun, find the fun...our mantra...find the fun... and finish the %#*@ing game...
09/07/2004 (4:39 pm)
Holy crap....Paul just now told me that he'd done a new .plan....and what a .plan it is. I personally would like to thank Nauris and Anthony publicly for coming on board and agreeing to help us out. Anthony cranked out so many good map designs that I haven't been able to check them all out yet, and Nauris....not enough good things can be said about Nauris's work.Find the fun, find the fun...our mantra...find the fun... and finish the %#*@ing game...
#13
09/21/2004 (2:29 pm)
In one word an excellent .plan! Thanks for sharing this information :)
Torque Owner Joshua Dallman
Default Studio Name
kudos on simplifying gameplay elements, I was getting lost just reading about the old design... and kudos on integrating the feedback questionaire with the alpha, that was an awesome thing to do and obviously provided invaluable feedback.
I know you must have heard this before, but have you ever played "herzog zwei" for sega genesis? this game has its roots there. I'd love to see a multiplayer version where you can infect opponents datastreams!