Plan for Paul Dana

Long Strange Trip, Part 2: The Prototype

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 and then later Flash Bios.

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


How the Game Looks Today

Remember, you can Play Flash Flash Bios RIGHT NOW! The open beta has started, so if you want to see where we are today, just Sign Up and help us playtest!

The Plan

The general advice I had received up to this point was to focus on prototyping the gameplay in small iterative steps. After playtesting 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 fyling. 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 audiance 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 adressing 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 actaully was. We had a confused sort of notion that our audiance was "people who played classic arcade games" but that this was a broad audiance 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.