Plan for Paul Dana
by Paul Dana · 08/17/2005 (5:54 pm) · 10 comments
Long Strange Trip, Part 2: The Prototype
This is part 2 in a series of blogs that documents the wonderous journey of Jason Sharp, Paul Dana, and Kirk Alberts as we learned the hard way how not to make games. Part One is here
We started two and a half years ago with a prototype called Droids, a 3D clone of an old 2D arcade style game called Oids. The gameplay and the name changed. It became first Bit Shifter, then later Flash Bios, and finally back to Bit Shifter.
We are going to highlight the spots along this journey where we went wrong, how we failed to understand or to believe the advice we got, and why we think we failed to 'get' the process of making a game until our second year.
Oids
Original 2D game Oids
First you need to know about the original 2D arcade style game, called Oids. Part One has a description of Oids and a playable download.
Droids
Fugly UFO Donut headed for the Mother Ship
Next you need to know about the Droids. You can download this prototype right now and play it yourself if you like.
The first prototype of Droids worked like this: in an effort to translate the 2D asteroids style flight control of the original game I made a custom vehicle type affectionately dubbed the UFO Donut Tank. The idea was to have a flight model 'like spectator mode in an FPS game but with momentum' using the traditional WASD keys for moving and mouse for turning.
For the Ship and the Mother Ship and all other game objects I learned how to use the Milkshape modeling program, made incredibly ugly stand-in art, and moved on. For the Droids I used the Blue Torque Guy model that came with Torque. To show 'flat areas' where it was OK to land I painted the terrain with grass texture and used brown desert color everywhere else.
For baddies I chose four things from Oids to implement:
The Open Beta
[ NOTE: wasn't I cute thinking that version of the game was in beta! In fact the 'open beta' version shown above is equivalent to the version you can download in Long Strange Trip Part 6
The Plan
The general advice I had received up to this point was to focus on prototyping the gameplay in small iterative steps. After play testing each version, decide what needs work, and let that influence what is worked on next.
I looked upon myself as a newbie at making games, so I focused on the question: How do I know what needs work? How do I know what to 'do from here'.
I asked Joe Maruschak to play the prototype and give me his impressions as well as advice on 'what to do from here'.
Joe Plays the game
The version of the game I sent to joe had the movement keys bound to ESDF instead of WASD by mistake. I had W bound to 'down' and spacebar bound to 'up'.
Joe sits down to play the game and presses W to go forward. The ship immediately plummets to the ground and goes boom (remember, touch anything other than a landing area and it's instant death).
Joe spawns again and is now very cautious. He figures out where the keybinds are and tries flying around, touches the side of a hill and promptly goes boom.
He is very tense while flying for the rest of the testing, but is able to find the prisons, shoot them to release the 'droids', land and save them, and bring them back to mother ship.
Shooting Droids Prisons from First Person View
What Joe Said
First he warned me up front that my flight model was too difficult. It allows five degrees of freedom. You can move along all three axes X, Y, Z and you can rotate around two Pitch, Yaw. He strongly advised that I work on the flight model first before any other game feature.
Second Joe related how having 'instant kill' on any contact made him very tense while flying. He asked if I intended flying to be 'tense' in this game. I said no. This lead to discussions of how little up front 'reading' most players do before just jumping in and trying a game and how most of their impressions of the game will come from their first few minutes playing it. He related how not many games are 'insta kill' like old school arcade games and the reason for this is that having 'damage' teaches you what hurts without killing you.
This lead to complaint three. Too many keys to press. I was explaining how, yes, it was instant death if you touched the ground or any enemy shot hit you, but there was a shield that protected you from all harm and made you bounce off the ground. The fun was flying around bouncing and timing the shields. He pointed out how that as may be, it was still a lot to need six keys and a mouse to fly around with and then also need a key for shields. I countered that there was no gravity, so really you could fly with just the forward key and the mouse giving the direction to fly in. Joe pointed out that while this was true, it was not an obvious or intuitive flight model.
Complaint four was about how it felt to land the ship. In the original game you had to come in with a certain minimum speed or you exploded on landing. I implemented this same system but it was very 'fussy' about rebounding off the ground and taking a long time till you lost enough momentum that the game would call that 'stopped'. To fix this I added some code to say OK if you are going slow enough just stop, don't bounce a few times before stopping. This had the effect of making the landing areas feel 'magnetic'...they would 'grab' you to a stop. Joe complained that this felt awkward but also he questioned having to land in the first place...why not just fly by?
Finally he gave me a general piece of advice when trying to sort out 'what to do next'. He said that a mission statement is more important than a game design at this phase. Identify who your audience is. Is this a game for hard core gamers? Is this a game for someone who used to play online games but does not have the time anymore? Is this a casual game meant for someone who is looking for a new distraction during lunch breaks? He advised us to get a strong mental image of who is playing the game and why this game would fill their needs.
He gave me more impressions than this but there isn't space to go into them all, these four were his strongest observations at this point.
I asked him what I should do from here and he said he had already answered that. I was overwhelmed with all the feedback and advice so it was clear to me what he meant. He said 'work on the flight model'. I said 'what if I like the flight model and want to keep it...what then'. Being very patient with me he says 'still work on the flight model'.
What We Thought
At this point Jason Sharp and Kirk Alberts had just become inspired by the prototype to join the project. Just as I had been promised. If I made it they will come.
They were anxious to help out. Jason would make 3D models and animate them. Kirk would make textures for the model and GUI elements and textures for the terrains and skyboxes. He also knew Hammer and would make some interiors.
I was also excited to have them start on this work and I was interested in addressing all the issues that Joe brought. Except the flight model. I loved the flight model and was sure that it could be made to work.
What We Did
What we did not do was hunker down and address the flight model. What we did do was go crazy putting content into the game. You can judge for yourself in the next blog in this series how much we followed Joe's advice (or not).
We talked about a mission statement and who are game was for, but we did not really connect this back with how the game actually was. We had a confused sort of notion that our audience was 'people who played classic arcade games' but that this was a broad audience with wide appeal. We knew our flight model was complicated but we felt that, since you only really needed the forward key and the mouse to fly, it was not overly complicated.
The Big Mistake
Our biggest mistake, and one that we would repeat several times, was to mis-identify where the project was along a continuum from start to finish. I was such a newbie that Joe and I were still talking at cross purposes at this point. If he had known exactly how un-ready I was to even grasp his advice, nevermind follow it, I think he would have said 'Look Paul. Your game is here on the continuum [points to 3%], because you still have basic issues with your control scheme (flight model) which is one of the very first issues you have to sort out. But you are acting like you are here on the continuum [points to 17%] because now you want to add 3D art, and here [points at 79%] because you want to add GUI elements.'.
I am making up the particulars of course, but this is the thrust of it. We would do something, know it was not really 'done', but move on anyway as if issues could all be sorted out at some later date.
As Joe was to make more clear to me in later discussions, this just serves to muddy the water. Not surprisingly the issues that I largely dealt with after this point had to do with muddy water.
The Bad Assumptions
The root source of the Big Mistake and all our major problems is a set of bad assumptions we made, mostly without thinking conciously about it:
None of these assumptions was true and they all cost us. Many many hours were wasted because of these assumptions and many months of time went by without actually making much progress toward shipping a game.
If there is any point to take away from this long winded discussion of our first prototype, it is this: try to avoid costly assumptions like the ones we made. There really is a right and a wrong way to make games.
But that is a disussion for another day.
That's all for this episode of The Long Strang Trip. You can read more in my next blog, Part Three : Boys Go Wild.
Please follow us on Twitter, Facebook, and YouTube:
Twitter: twitter.com/PlasticGamesLLC
Facebook: www.facebook.com/BitshifterGame
YouTube: www.youtube.com/user/PlasticGamesLLC
This is part 2 in a series of blogs that documents the wonderous journey of Jason Sharp, Paul Dana, and Kirk Alberts as we learned the hard way how not to make games. Part One is here
We started two and a half years ago with a prototype called Droids, a 3D clone of an old 2D arcade style game called Oids. The gameplay and the name changed. It became first Bit Shifter, then later Flash Bios, and finally back to Bit Shifter.
We are going to highlight the spots along this journey where we went wrong, how we failed to understand or to believe the advice we got, and why we think we failed to 'get' the process of making a game until our second year.
Oids
Original 2D game Oids
First you need to know about the original 2D arcade style game, called Oids. Part One has a description of Oids and a playable download.
Droids
Fugly UFO Donut headed for the Mother Ship
Next you need to know about the Droids. You can download this prototype right now and play it yourself if you like.
The first prototype of Droids worked like this: in an effort to translate the 2D asteroids style flight control of the original game I made a custom vehicle type affectionately dubbed the UFO Donut Tank. The idea was to have a flight model 'like spectator mode in an FPS game but with momentum' using the traditional WASD keys for moving and mouse for turning.
For the Ship and the Mother Ship and all other game objects I learned how to use the Milkshape modeling program, made incredibly ugly stand-in art, and moved on. For the Droids I used the Blue Torque Guy model that came with Torque. To show 'flat areas' where it was OK to land I painted the terrain with grass texture and used brown desert color everywhere else.
For baddies I chose four things from Oids to implement:
1. Guns that shoot you 2. Anti Grav towers that push you 3. Magnetic towers that pull you 4. Teleporters
The Open Beta
[ NOTE: wasn't I cute thinking that version of the game was in beta! In fact the 'open beta' version shown above is equivalent to the version you can download in Long Strange Trip Part 6
The Plan
The general advice I had received up to this point was to focus on prototyping the gameplay in small iterative steps. After play testing each version, decide what needs work, and let that influence what is worked on next.
I looked upon myself as a newbie at making games, so I focused on the question: How do I know what needs work? How do I know what to 'do from here'.
I asked Joe Maruschak to play the prototype and give me his impressions as well as advice on 'what to do from here'.
Joe Plays the game
The version of the game I sent to joe had the movement keys bound to ESDF instead of WASD by mistake. I had W bound to 'down' and spacebar bound to 'up'.
Joe sits down to play the game and presses W to go forward. The ship immediately plummets to the ground and goes boom (remember, touch anything other than a landing area and it's instant death).
Joe spawns again and is now very cautious. He figures out where the keybinds are and tries flying around, touches the side of a hill and promptly goes boom.
He is very tense while flying for the rest of the testing, but is able to find the prisons, shoot them to release the 'droids', land and save them, and bring them back to mother ship.
Shooting Droids Prisons from First Person ViewWhat Joe Said
First he warned me up front that my flight model was too difficult. It allows five degrees of freedom. You can move along all three axes X, Y, Z and you can rotate around two Pitch, Yaw. He strongly advised that I work on the flight model first before any other game feature.
Second Joe related how having 'instant kill' on any contact made him very tense while flying. He asked if I intended flying to be 'tense' in this game. I said no. This lead to discussions of how little up front 'reading' most players do before just jumping in and trying a game and how most of their impressions of the game will come from their first few minutes playing it. He related how not many games are 'insta kill' like old school arcade games and the reason for this is that having 'damage' teaches you what hurts without killing you.
This lead to complaint three. Too many keys to press. I was explaining how, yes, it was instant death if you touched the ground or any enemy shot hit you, but there was a shield that protected you from all harm and made you bounce off the ground. The fun was flying around bouncing and timing the shields. He pointed out how that as may be, it was still a lot to need six keys and a mouse to fly around with and then also need a key for shields. I countered that there was no gravity, so really you could fly with just the forward key and the mouse giving the direction to fly in. Joe pointed out that while this was true, it was not an obvious or intuitive flight model.
Complaint four was about how it felt to land the ship. In the original game you had to come in with a certain minimum speed or you exploded on landing. I implemented this same system but it was very 'fussy' about rebounding off the ground and taking a long time till you lost enough momentum that the game would call that 'stopped'. To fix this I added some code to say OK if you are going slow enough just stop, don't bounce a few times before stopping. This had the effect of making the landing areas feel 'magnetic'...they would 'grab' you to a stop. Joe complained that this felt awkward but also he questioned having to land in the first place...why not just fly by?
Finally he gave me a general piece of advice when trying to sort out 'what to do next'. He said that a mission statement is more important than a game design at this phase. Identify who your audience is. Is this a game for hard core gamers? Is this a game for someone who used to play online games but does not have the time anymore? Is this a casual game meant for someone who is looking for a new distraction during lunch breaks? He advised us to get a strong mental image of who is playing the game and why this game would fill their needs.
He gave me more impressions than this but there isn't space to go into them all, these four were his strongest observations at this point.
I asked him what I should do from here and he said he had already answered that. I was overwhelmed with all the feedback and advice so it was clear to me what he meant. He said 'work on the flight model'. I said 'what if I like the flight model and want to keep it...what then'. Being very patient with me he says 'still work on the flight model'.
What We Thought
At this point Jason Sharp and Kirk Alberts had just become inspired by the prototype to join the project. Just as I had been promised. If I made it they will come.
They were anxious to help out. Jason would make 3D models and animate them. Kirk would make textures for the model and GUI elements and textures for the terrains and skyboxes. He also knew Hammer and would make some interiors.
I was also excited to have them start on this work and I was interested in addressing all the issues that Joe brought. Except the flight model. I loved the flight model and was sure that it could be made to work.
What We Did
What we did not do was hunker down and address the flight model. What we did do was go crazy putting content into the game. You can judge for yourself in the next blog in this series how much we followed Joe's advice (or not).
We talked about a mission statement and who are game was for, but we did not really connect this back with how the game actually was. We had a confused sort of notion that our audience was 'people who played classic arcade games' but that this was a broad audience with wide appeal. We knew our flight model was complicated but we felt that, since you only really needed the forward key and the mouse to fly, it was not overly complicated.
The Big Mistake
Our biggest mistake, and one that we would repeat several times, was to mis-identify where the project was along a continuum from start to finish. I was such a newbie that Joe and I were still talking at cross purposes at this point. If he had known exactly how un-ready I was to even grasp his advice, nevermind follow it, I think he would have said 'Look Paul. Your game is here on the continuum [points to 3%], because you still have basic issues with your control scheme (flight model) which is one of the very first issues you have to sort out. But you are acting like you are here on the continuum [points to 17%] because now you want to add 3D art, and here [points at 79%] because you want to add GUI elements.'.
I am making up the particulars of course, but this is the thrust of it. We would do something, know it was not really 'done', but move on anyway as if issues could all be sorted out at some later date.
As Joe was to make more clear to me in later discussions, this just serves to muddy the water. Not surprisingly the issues that I largely dealt with after this point had to do with muddy water.
The Bad Assumptions
The root source of the Big Mistake and all our major problems is a set of bad assumptions we made, mostly without thinking conciously about it:
1. Adding more to the game will make it easier to see what is fun
and what is not fun.
2. Moving a 2D game mechanic to 3D would be simple and workable
with the right set of changes.
3. It would be possible to design the higher level aspects of the game
without refining the lower level interactive elementsNone of these assumptions was true and they all cost us. Many many hours were wasted because of these assumptions and many months of time went by without actually making much progress toward shipping a game.
If there is any point to take away from this long winded discussion of our first prototype, it is this: try to avoid costly assumptions like the ones we made. There really is a right and a wrong way to make games.
But that is a disussion for another day.
That's all for this episode of The Long Strang Trip. You can read more in my next blog, Part Three : Boys Go Wild.
Please follow us on Twitter, Facebook, and YouTube:
Twitter: twitter.com/PlasticGamesLLC
Facebook: www.facebook.com/BitshifterGame
YouTube: www.youtube.com/user/PlasticGamesLLC
#2
The amount of reviews I have seen for the finished games, that mentioned stuff like "The interface feels quirky" or "the levels seemed sparse". I would think to myself if only you knew the half of it.
I have been honored to see the industry slowly growing up. More and more I see actual project plans on walls and actual milestones being met. This sadly is still an area that can be vastly improved and an area that indies often neglect. I've seen more projects fail for want of a nail (a plan or design document) as it were than any other reason.
You never see a film shoot without a shooting schedule, yet you often see an indie project without a design document or a project plan (even a basic one will do in most cases).
08/17/2005 (6:10 pm)
For my first few porjects (and when I was starting out in the contracting side) I saw a lot of the "leave it half finished" errors. I would see programmers start a gui. Get a few buttons working (usually start and options) and then call it as good as and move on. The plan was always to re-visit at the end. Usually what happened was that it was tidies a bit at the end and left. The amount of reviews I have seen for the finished games, that mentioned stuff like "The interface feels quirky" or "the levels seemed sparse". I would think to myself if only you knew the half of it.
I have been honored to see the industry slowly growing up. More and more I see actual project plans on walls and actual milestones being met. This sadly is still an area that can be vastly improved and an area that indies often neglect. I've seen more projects fail for want of a nail (a plan or design document) as it were than any other reason.
You never see a film shoot without a shooting schedule, yet you often see an indie project without a design document or a project plan (even a basic one will do in most cases).
#4
I really like the way Flash Bios is looking too.
08/17/2005 (9:52 pm)
Thanks for these entries Paul. I really appreciate the time your taking to explain some of hte pain you've gone through. I like to think we are working in the right direction. Our team seems to have most ofyour advice sorted out. Now we have to see if we can follow through on the execution....I really like the way Flash Bios is looking too.
#5
My opinion is that there really are 2 or more levels to game interfaces/controls that need to be present in any game. The first level always needs to be a simple, out of the box, intuitive, get them in the game control system. You can have deeper, less obvious controls that users can learn to use over time but initially it's best to have a basic control system with no manual reading necessary.
The first minutes count alot and it's best to ease players into more advanced play mechanics.
Just my 2 cents or less. :)
08/17/2005 (10:03 pm)
Congo rats on getting your game to this point!My opinion is that there really are 2 or more levels to game interfaces/controls that need to be present in any game. The first level always needs to be a simple, out of the box, intuitive, get them in the game control system. You can have deeper, less obvious controls that users can learn to use over time but initially it's best to have a basic control system with no manual reading necessary.
The first minutes count alot and it's best to ease players into more advanced play mechanics.
Just my 2 cents or less. :)
#6
Tried both Firefox and Explorer.
Nick
08/18/2005 (12:24 am)
Well said Paul. I tried to sign up for the Flash Bios open beta and I got a "HTTP Status 500" "error:The server encountered an internal error () that prevented it from fulfilling this request."Tried both Firefox and Explorer.
Nick
#7
Nick - im sorry that is happening...perhaps the server went down. It appers to be up now. The link given to FBOB is www.plasticgames.com/dev/fbob...but that really is a redirect to here: http://66.212.209.145:8080/fbob/ perhaps It will work if you hit that link directly?
08/18/2005 (6:49 am)
Everyone - thanks for the kind wordsNick - im sorry that is happening...perhaps the server went down. It appers to be up now. The link given to FBOB is www.plasticgames.com/dev/fbob...but that really is a redirect to here: http://66.212.209.145:8080/fbob/ perhaps It will work if you hit that link directly?
#8
08/18/2005 (6:58 am)
No prob Paul. I used the original link again and worked perfectly. Downloading now...
#9
- Brett
08/18/2005 (9:46 am)
I have to say, Paul and I hang around in a certain channel, with some other dev guys, and we see eachother's projects blossom (and also crash and burn at times). I have enjoyed watching Bit Shifter transform into what is Flash Bios. I played it last year at IGC and it was fun.. A little complicated without the trainer mission -- but fun. And that's what counts. I'd suggest getting involved in the Open Beta if you can. I would, but I have some serious benchmarking to do.- Brett
#10
This post should be required reading for buying the Torque license.
I'm glad you found your mistakes and have begun to takes steps as a professional game developer.
Independent != Unprofessional
08/18/2005 (10:07 am)
This is one of the most useful posts I've ever read. So much so that I decided to actually make my first post here! It is often very hard to admit one's mistakes and certainly more so to do it publicly. I have to guess that with Torque's incredible power and low price that too many fall into the trap of trying to add bells and whistles before they add the ability to ring or blow =)This post should be required reading for buying the Torque license.
I'm glad you found your mistakes and have begun to takes steps as a professional game developer.
Independent != Unprofessional
Associate Anthony Rosenbaum