Blog for Paul Dana at GarageGames.com

372 Free Textures - what a gem!

Paul Dana — 2008-06-23T18:06:44+00:00

The Plastic Games effort to release one useful thing per work day to the community, Gem-A-Day, continues. We have been at it for two weeks, delivering and explaining these useful little development nuggets in the form of C++ and script classes and a few useful 3D shapes as well.

Kirk Albert's has decided to shame us all by releasing 372 free textures, plus some examples of use, to the community. He wanted all this stuff to be a single gem but I wouldn't let him and made him stretch it out. All the textures can be grabbed from the first of his gems so check out Gem #11 from Kirk.

I have no idea how long we can keep this up. We are finishing up some contract jobs and looking for more. We are also hoping to release a code pack / content pack for sale on Garage Games.

I better get back to work. Have fun with the gems folks.

Zombies and Gem A Day

Paul Dana — 2008-06-05T02:27:15+00:00

Zombies!!!!!

I realize I forgot to put the word Zombie into the title of my previous blog about our Zombie COOP game. Even though this blog is about our Gem A Day project, I figured I would put the word Zombie into the title of this blog and provide as many redundant links and gratuitous images as I figure you could stomach:

That's gotta hurt.

Gem A Day

Plastic Games is a small independent games development company. We make a living generally doing contract work and generally using Torque. We have been doing this for several years now and we have a policy of code re-use that we call making "gems". A gem is a self contained bit of code and/or art, often along with some useful conventions, that solves a particular problem in a way that makes it easy to use this solution again in the future. The name comes from the famous Graphics Gems and Game Programming Gems series.

Over the years we have made quite a few useful Torque Gems, and it has saved us a lot of time and effort. The more we use our gems the more we realize it was worth making them. In an effort to give back to the community, over the next few weeks we intend on releasing a Gem A Day.

Anthony Rosenbaum and I will begin posting one resource each work day, starting Monday, June 9th. Each resource is one of our Plastic Gems.

Plastic Gem #1: Placeable shapes will explain how to use Torque to create your own custom shapes with their own animated behavior using the StaticShape class. It provides a cool .dts shape of a grandfather clock that is used in the first three gems.

Plastic Gem #2: Animation Threads provides a heap of useful improvements to the animation support and builds upon what the grandfather clock can do.

We hope you find these resources useful as it has sure been a pain preparing them. We have the first few ready and will be busily working on more so that we can keep up the Gem A Day effort for at least two weeks.

The gems are going up. For a list of gems, visit the Gem A Day page.

Next we make it look good...

Paul Dana — 2008-05-09T14:47:57+00:00

Next we make it look good...

Plastic Games has been working on a co-op Zombie game prototype.

You can play the prototype. Download the zip here. Get your friends to download and play together!

You can watch a video of game play here.

Keep in mind this is a gray block prototype. It is like a rough draft of one chapter of a book. It shows enough game play to see if people would want more. It does not represent the game play of a complete game. The question it asks is: is it fun to kill zombies like this with your friends?

1. Make it Play Good...

Clearly I have failed at my resolution to blog more often, as a result this blog is somewhat lengthy. As I mentioned in my last blog, Plastic Games has been spending time between contract jobs prototyping a co-op Zombie killing game. We realize this is not an original premise. We find our prototype to be fun and we think you might too. We encourage you to checkout the game play in the video link above and if it looks fun download and play it. It is the most fun in co-op mode and we have a server running. Tell some friends about it and play it together.

When I last blogged I mentioned that we had just "found the fun" in the game and were excited to show it to people. Prior to this we were discouraged because the game wasn't very compelling in single-player or co-op. We had improved the performance a bit and had fixed some bugs and the single-player experience got a bit better and so we decided to try to play it on co-op mode and see how it was. It was fun! Granted there were still issues but the fun had at last been found. Turns out we were pretty close to the fun already but performance issues and bugs were hiding it.

The problem remained that the performance was still crap. We had improved it enough to see the game better but it was still crap, even in single-player without any networking issues. In co-op it was even worse. The only reason we were having fun playing co-op is we knew how all the effects were *supposed* to look (from single-player) even if more than half of it was not showing up in a co-op game. Animations would be skipped or come late, zombies would just slide or warp at you with no animations, blood particles would not show up, the frame rate was terrible especially with lots of zombies on screen.

The solution was to just focus on performance until the feedback we already had in place could be seen more clearly. Later we could work on improving the feedback as well.

2. Make it Run Good...

The art assets we used for the prototype either came from content packs or were interiors that we already had from previous projects or had developed as part of our own testing. Much of it was not optimized in any way. Similarly much of the code we put together for the prototype was script code that got the job done quickly but wasn't very fast code.

So clearly we had some ideas where to start in improving things but, as always with optimization, the place to start is with measurement. Naturally we need to be able to quantify where the performance was suffering before we would know which parts of the code need improving or even to know if any one code change actually helps.

Gemming

We did a series of tests with test maps to determine what affected frame rates the most. At Plastic Games we have a philosophy of "Gemming" problems. This means that when we go to solve a problem we try make some part of the solution reusable; a little "gem" of code or whatever that will help us in the future. In this case this meant making script code for *duplicating* objects in a mission file in a regular grid of 3x3 or 5x5 or 7x7. We used this as a way of constructing our test maps procedurally from simple inputs. It also meant creating some code for hiding or showing certain classes of objects so we could do FPS tests without having to actually laboriously go through and hide or show large number of objects. We also made a handy method of temporarily moving the visibility distance way out. It is reset back to what it was automatically before you either SAVE or LIGHT the scene. This helps in the editor to just see what your editing without accidentally changing your visibility settings.

Debug Render Modes

Now that we had confirmed where performance needing improving we prepared for that work. We knew we would need to create some more custom INTERIOR assets for this prototype with proper LOD and such and we decided to use that as an opportunity to create some proper grey-blocking art assets. As part of the need for measurement we took advantage of the Interior Debug Render modes Torque has always had. There is a resource out there for accessing these modes with a dialog so we merged that resource in.

The Show Detail Level render mode is a great help. It color codes the different Interior LODs as: White, Blue, Green, Red, Yellow...with white being the closest, etc. The colors changing in game as you walk around tell you the LODs are changing.

LOD Profile

Another opportunity for Gemming came up when we considered how much of pain it was to update the values that controlled the LOD. We would have to go back to the .map file and update and create a new .dif file, etc. To ease this pain I created the LODProfile:

datablock PlasticLODProfile(GB_LGTEST_LODPROFILE)
{
   geometryFile = "~/data/interiors/greyblock/gb_lgtest.dif";
   detailValue0 = "400";
   detailValue1 = "128";
   detailValue2 = "60";
   detailValue3 = "12";
};

datablock PlasticLODProfile(TEMP_LRG01_LODPROFILE)
{
   geometryFile = "~/data/interiors/greyblock/temp_lrg01.dif";
   detailValue0 = "400";
   detailValue1 = "150";
   detailValue2 = "60";
   detailValue3 = "12";
};

// etc...

An LODProfile is used to override the LOD values stored in the .dif file. To tweak the values that control LOD changes we only have to update this datablock, not re-create the .dif file.

Tweaker

Speaking of tweaking...previous Gemification here at Plastic Games had already given us the Tweaking system. Explaining the origins of this tool we created would take too long so I will just describe what it does. It is a tool to help in the tweaking of game parameters. It helps the programmer expose whatever parts of the script he wants the game designers and testers to be able to tweak. The game designers and testers can user the Tweaker GUI to make and test changes the result is written back out to the scripts. This is very handy.

The way it works for the programmer is also very simple: it uses commands embedded in scripts to indicate which things should be tweakable. For example the above datablocks actually look like this so they can expose some values to the Tweaker system:

datablock PlasticLODProfile(GB_LGTEST_LODPROFILE)
{
   geometryFile = "~/data/interiors/greyblock/gb_lgtest.dif";
   //P[ GrayblockLODProfiles
   //-----------
   detailValue0 = "400";
   detailValue1 = "128";
   detailValue2 = "60";
   detailValue3 = "12";
   //P]
};

datablock PlasticLODProfile(TEMP_LRG01_LODPROFILE)
{
   geometryFile = "~/data/interiors/greyblock/temp_lrg01.dif";
   //P[ GrayblockLODProfiles
   //-----------
   detailValue0 = "400";
   detailValue1 = "150";
   detailValue2 = "60";
   detailValue3 = "12";
   //P]
};

// etc...

At runtime, when the game designer or game tester calls up the tweak panel the game scripts are parsed and then a panel like this is displayed:

Now I can play around with the LOD numbers to get the result I want. Here is an example that shows the use of the Torque Show Detail Level Interior render mode and the tweak system. Remember that WHITE means the LOD zero the most high detailed, then BLUE, then GREEN. In this example there are only three levels of detail. Notice how the scene changes as we tweak the LOD numbers:

TEMP_LRG01_LODPROFILE.detailValue1 = 150

TEMP_LRG01_LODPROFILE.detailValue1 = 200

TEMP_LRG01_LODPROFILE.detailValue1 = 290

DTS LOD Render Mode

DTS Shape objects (like the player and trees and fences) also have LOD settings.

They are not such a pain to setup as Interiors are and there is ShowTool Pro to view the settings. However it can still sometimes be hard to relate distances as you see them in ShowTool and in-game so I created a debug render mode for DTS shapes that is similar to the Interior Show Detail Level render mode and using the same color code: White, Blue, Green, Red, Yellow, etc:

Using these tools and our test maps we were able to determine appropriate budgets for shapes and interiors and appropriate distances for LOD changes.

Networking

So the improvements to the frame rate helped but were not enough as the networking needed improvements as well. You can see the above image from my last blog post. That screenshot was taken in co-op mode and you can't even see any blood at all from that bat impact. Not good.

The problem is how the blood particles are implemented. We had updated the Projectile class to allow a different explosion when a projectile hits a player. This explosion we setup to be a blood particle explosion. This is how the projectile blood was handled. For the bat and zombie scratch we created a blood explosion and set it going.

Ok you ask...so what's wrong with that implementation? Well the biggest problem is that it ends up sending information from the server to the client that, as such, the client should already know. The projectile or a bat swing hit the player on the server. The server sends a damage update to the client. But then also the projectile explodes (or the bat scripts create a blood explosion) and that info is sent to the client. By the time that info is received enough time has gone by that the explosion is actually over with and you never see it.

We can do better

What I did was extend the damage code to include information needed to have the client create all the damage FX itself when the damage was received. Turns out there is already a "damage vector" showing what direction damage is coming from (that is not hooked up anywhere in the scripts that I could see) I added a damage "position" and a 32 bits to control the "type" of blood. I added a new datablock type, DamageBloodData to control things like how many particles should spawn for how much damage, etc. Here is an example of how that looks:

datablock DamageBloodData(bloodSpray)
{
   // Bit 8 is blood spray in direction of damage...
   bloodType = 8;            // if any of these bits match the incoming damageFXType then this effect applies

   particleEmitter = "bloodSprayEmitter"; // particle emitter to use for this blood effect...
   normalFromDamageDir = 1;  // if true then blood FX normal set from damageDir and following flags apply, otherwise blood FX normal set to (0,0,1)
   normalCrossZ = 0;         // if true then normal is crossed with (0,0,1) before inversion or tilting up (only used if normalFromDamageDir=1)
   normalInverse = 0;        // if true then normal is negated after crossing but before any tilting (only used if normalFromDamageDir=1)

   //P[ bloodSpray
   //-----------------
   normalTiltUp = "1";         // if true then normal is tilted UP by approx 45 degrees from horizontal after any crossing or negating (only used if normalFromDamageDir=1)
   //-----------------
   deathMinDamage = "100.0";  // min damage of a deathly blow for purposes of damage FX
   //-----------------
   minDamage = "1.0";           // damage below this does not cause this effect
   maxDamage = "100.0";           // damage above this causes max particles
   minParticles = "15";          // particles at min damage & above
   maxParticles = "50";          // 0=get count from emitter lifetime, else particles at max damage...
   minParticleVariance = "2";    // random variance at min damage
   maxParticleVariance = "10";   // random variance at max damage
   //-----------------
   posZOffset = "0.0";         // 0 = no change, larger values raise blood emitter UP
   startRadius = "0.01";      // radius for random start position of blood particles...
   //P]
};

You will notice the tweak codes again. Note that any comments that are provided near tweakable parameters are used to implement tool tips for that parameter:

This system allows us to define different particle effects for different parts of damage and then specify in the projectile class (or any damage scripts) what sort of damage each projectile does.

In the game we added five types of blood emitters: Fountain, Rebound, Swipe, Spray and Stream. Each type has its own DamageBloodData datablock. The one above is for Spray. As you can see this datablock references its own ParticleEmitterData (which references its own ParticleData). Spray is the blood that shoots out the back of a zombie when you shoot it. Fountain is the fountain of blood you always see. Swipe is to-the-side splash of blood used only for the bat.

This system worked well and now blood particles were showing up every time, even in a co-op game. We were able to get rid of the explosions completely which also reduced network traffic.

This helped a lot with the feedback. We also did a similar thing for the HUD elements. They were originally implemented in script and were not very efficient. We implemented C++ code to transmit the information that used to be in scripts such as the type and amount of ammo. This made the HUD more responsive and reduced networking even further.

Where's the Mess?

In fact the blood was working so well it made another problem. The ground looked too clean for such a blood fest! We added blood DECALS to solve this. We were concerned about performance adding ray casts to each particle that were not there before, so we made only some particles actually check for collision and leave a decal behind. We ended with one out of five particles leaving a decal.

3. Make it Look Good...

OK so that concludes the story of how we got from there to here. In fact, I have left out an amazing number of things I did not have the patience to get into, from changing game goal to a series of checkpoints, to the optimizations we tried that didn't help, and the subtle features we added to particles to make them show up better at far distances. Those things and a better description of the Tweaker system will have to wait for another blog.

The question for this zombie game, of course, is...what next? Well...next we make it look better!

This is, after all, just a proof of concept with stand-in art and animations. None of the experience is as rich or as deep as we would like and the quality of the art is nowhere near where we want it. We have ported this code base to TGEA technology and we are exploring making this thing look better. I will try to blog more often and keep everyone up to date. (Don't hold your breath). In the meanwhile go download the game and play. The link is at the top of this blog.

That's all?

You may ask...wait a second. Where is the back story? What about putting this fighting in a larger context with more long term rewards? All these are good questions but we feel the heart of a good fighting game is good fighting. We have a hundred bajillion back story ideas and some really great ideas for how to build the larger game around the fighting. But who cares about our ideas. We want to hear your ideas. Go play the game and tell us what you want out of a zombie killing game.

Also if we don't make it look good then nobody will bother giving it a second glance.

OK, that's all I have for now. I am starting up a small contract now so I am not sure when I will blog on the zombie prototype again. My next blog will probably be about Gemming and the Plastic Gems we have built.

Now go play the game. Preferably with your friends.

Long Time Coming...

Paul Dana — 2008-03-09T01:10:28+00:00

OK, clearly my resolution to blog more in 2007 was a bust.

I looked back and I blogged exactly once: Mar 12 2007...almost a year ago. Whoops.

The year of 2007 flew by like a movie about someone else's life. When I think back to summarize what the boys from Plastic Games and I have been up to it seems all exciting and fun, and I suppose it was. At the time it seemed like a lot of work.

At the beginning of last year we were just installing our first attraction at a major theme park in Orlando, FLA and we have now installed our second. Both projects went very well. The client was very happy with the results (we made their "preferred vendor" list). Nothing could have been more satisfying that playing those very games with my children during February vacation and watching hundreds of people flow through the room and play our games and just have a great time with their families too. Both projects also show the incredible power of the Torque game engine and technologies from Garage Games in particular. I am continually amazed at what a skilled team can do with Torque.

In between those two game contracts we also worked quite a bit with Eric Preisz of C2C Simulations and have done some other game contract work as well to keep busy and keep bread on the table.

I attended IGC 2007 which was awesome and got to hear a lot about Instant Action from Garage Games before they announced it to the wider world. That was a great trip. I should have stayed longer and I should have blogged. I did not talk much business with anyone because I am quite frankly a dunder head, but I did catch up with a bunch of people and got to check out what GG was up to, and got to play some amateur rock and roll bass at the Indie-Jam. Booya! :-)

When we have downtime from contracts we have been prototyping game ideas. If the prototype seems to have promise we "finish" it enough that we can get some feedback on it from anyone we can encourage to help us play test. We are calling the result a "proof of concept" as it lets us see if a wider audience views the prototype the same way we do and to just collect more opinions on it.

Anthony Rosenbaum and I are the programmers for Plastic Games. He recently blogged on the first proof of concept we have ready for people to give opinions on. It is a kids games prototype called "Bixby and the Isle of Charms". It is about a kid named Bixby who finds treasures and adventure digging in the sand at the beach. If you want to check that out you can follow this link here: www.plasticgames.com/~anthony/bixbyioc_poc_01.zip

We are working on another proof of concept for a Coop Zombie Killling game. While the final game would have more rewarding gameplay objectives, this first version is simply "Kill this many zombies in 20 minutes". The reason is that, at heart, it's a game about killing zombies and so our focus for a while will be just making killing zombies with your friends more fun. We are not quite ready with it yet so I can't give a link, instead you will have to be satisfied with just another image.

Look here for the link to the Zombie Killing Game in a week or so.

Giving Presentation to Middle School Math Club

Paul Dana — 2007-03-12T17:53:39+00:00

I am giving a presentation today to the Math Counts club at my daughter's middle school. The subject is how I use math in my job as a game developer. I am posting this blog to make an easy location for the students to get to some web pages I wish to show them.

PhET Physics Education Technology

Motion

Robert Penner's Easing Demo

Bit Shifter

Paul Dana — 2006-10-26T03:05:03+00:00

BIT SHIFTER

Bit Shifter is a 3D Arcade Strategy game where you must save Bit World from infection by an Evil Virus. You play Flash Bios, pilot of the S.S. Scandisc, delivering virus cleaning robots called Bits to infected ares of bitworld. You must fight off nasty creatures that spawn from the virus, protecting the Bits, but watch out! If the virus reaches the Data Stream it's all over!

Plastic Games was formed when programmer Paul Dana met the art team of Jason Sharp and Kirk Alberts. Prior to meeting we had already become proficient in Torque engine technology and we wanted to put that skill to use and form a game development studio.

Bit Shifter (later renamed to Flash Bios after the main character) is the first project Plastic Games worked on. We worked on it from April of 2003 until October of 2005. During this time we received an increasing number of offers for contract work and eventually stopped work on the game to do contract work fulltime.

Play the Game Yourself!

To checkout the game download this zip file . To see the depth of this game you need only play the tutorial and the first level.

What We Learned

We learned a lot about how to make games during the two plus years we worked on Bit Shifter and even more about how not to make games.

We learned that the first and most important thing about a game is the feel of the control object. If the control object does not feel just fabulous to interact with then the game right off is no fun. Our control object is a spaceship as you see above and we made and re-made the flight model for Bit Shifter endlessly. We must have gone through six revisions and one of the last things we were working on when we stopped was the flight model.

We learned how many different details affect the feel of the control object beyond just the physics, from camera lag and camera tilt to supporting details like thrusters that rotate in the direction of thrust and impact rotations when the object is hit.

Above you see how the ship rotates to show impacts when hit with enemy fire. The image does not do this justice, you need to play the game really appreciate the detail that went into making just flying this ship around fun.

Above you can see that, in addition to rotating under an impact the ship would start to spew smoke and the cool neon blinking areas on the ship would go from blue to red as it took more and more damage.
This kind of detail extends to the rest of the world as well. The nasty creatures that spawned from the virus would bob up and down slowly but that would increase and they would start to spew smoke and fire when hurt. When you hit them they would rotate from the impact: infact you could get them spinning like crazy it was a blast.

The very terrain was a character in the game. The Data Stream represented the circuits flowing through Bit World. Each level would represent a part of those circuits with the Data Stream flowing in one side of the level and out the other. All the elements in the game from Bit Makers to Health Generators were "powered" by the Data Stream. We wrote custom rendering code to show the flow of power through the Data Stream and up the "Zor Paths" that brought power to the game ekements.

As areas of the terrain in Bit World got infected they would turn an animated turbulent red to show the presence of Virus using more custom rendering code. When the Zor Paths got infected they would turn red as well and the Virus would spread quickly down the Zor Paths. If the Virus reaches the Data Stream then the level is over!

A Team Was Born

After two plus years of effort we did not have a complete game. What we did have was a vast appreciation for the effort it takes to make a quality game experience and the skills to acheive it. Best of all we had become a team.

Since that time we have been further honing our skills working on contract projects. For details on our availability please contact Paul Dana paul@plasticgames.com or Jason Sharp jason@plasticgames.com.

What The...

Paul Dana — 2006-10-26T02:44:20+00:00

What the heck has Plastic Games been doing for the past year?

Good question.

The short answer is that we have put down work on Bit Shifter (aka Flash Bios) to pursue contract work.

The long answer will be forthcoming in future blogs, including the one immediately following this one. Don't fear, I still plan to finish my series of blogs, The Long Strange Trip. This blog and the next one are just quick updates to let everyone know what is going on.

You won't have long to wait as the next blog goes up in about an hour. It explains all about the game Bit Shifter and what we learned making it and includes a link to the game itself for people curious to try it out. I created this page so people could learn more about Plastic Games and how we learned to be an effective game development team.

Saturday Sep 24 5:15

Paul Dana — 2005-09-24T05:15:14+00:00

The Long Strange Trip, Part 3: Boys Go Wild

Long Strange Trip, Part 3: Boys Go Wild

This is part 3 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 last left you, dear reader, at the end of Part Two. I had finished a prototype of my game and had Joe Maruschak play it and gave me feedback. Also at this time Jason Sharp and Kirk Alberts were inspired by my Droids prototype to join me. Plastic Games was born!

Our Logo

We had Joe's feedback, which was:

1. Instant Death is nerve racking and somewhat hard to understand experience...why did I just die?...might want to add health.
2. 5 degree of freedom flight model is very difficult. Consder abandoning it. At the very least the flight model should be your focus until you get it right.
3. Landing the ship feels awkward...how about just flying by to grab Droids?
4. Write a mission statement...Identify your target audience and make decisions on what is right for your game by always going back to that mission statement. He cited his mission statement for Think Tanks: A cartoony tank game for former fraggers who don't have very much time in their life anymore but who would enjoy a simple online fighting game where it's quick to get into the game and quick to finish a map.

Jason would do modeling and animation, Kirk would gui/hud/concept/texture/terrains, and I would do coding. Jason and Kirk already knew how to get art into the Torque Game Engine. We were all set! We were ready to continue our prototyping. One month later we had a new version. You can
download this 8-May-2003 prototype of Droids right now and try it yourself.

By this point we had decided that this remake of Oids would happen inside a computer. Instead of "robots" you would be saving "Bits" (they would still look like robots)...the more you save the less data loss, right? Get it? We called the ship the S. S. Scandisc and we envisioned saving Bits being like saving data inside a computer. When we told Joe of this theme he suggested the name Bit Shifter.

Our First Brilliant Move

A Spiffy new ship model and a "chip" model for Bit Prison

Our first priority should have been addressing the flight model...so instead we made the ship look much cooler. How could we resist? I had this fugly flying UFO donut. We needed a ship that looked like it could fly the way the UFO dounut could fly.

Well...no we really didn't. What we really needed was to work on the flight model and improve it, possibly abandon it altogether. After that was done we could make a ship to match the flight model. Sure...but...but isn't that ship much cooler?

While we were making new models heck we would make a new model for the Bit prisons. Computer chips are found inside computers...let's use that!

Our Second Brilliant Move

A Giant Magnet that pulled you to your death!

Instead of address basic issues we instead had an orgy of putting content into the game. We were "cloning" Oids, a 2D arcade game, and so I suppose we figured that if we just put in enough content the game would be fun. Instead of playing the game we had and fixing and adressing the game we had...we constantly thought instead about the game we were about to build. We continued with the plan that the gameplay is already decided...it's Oids in 3D. Therefore we simply needed to translate the elements of the 2D game into our game and, presto! Fun! Right?

Not so much.

We reasoned: The original game had Grav Pods that pulled you in and Repulsors that pushed you away. We translated that to our in-a-computer theme and said, OK: Our game will have Magnets to pull you and Case Fans to push you.

A Giant Case fan that tracked you and pushed you

Now this was cool!

The Brilliant Moves Just Keep Coming

Only one month elapsed from when Jason and Kirk joined me to the version of the prototyp you can d/l and play yourself and that produced the screenshots your looking at. We had never worked as a team before and none of us had all that
much experience with the Torque art pipeline. And yet we were able to get all the game elements into the game that you see here in that time. And this is not just static models. Each of these models has animations and sounds:

The case fan would track you and push you away

This was quite an accomplishment. I had already created the Turret Resource that I am generally known for and there were AI Turrets in the game when Jason and Kirk joined me. That took an entire new C++ class to make work, but this Fan is animated in script only! I made a few small changes to the script animation functions, mostly just exposing to script animation thread code normally only callable from C++. Beyond that the rest was done in script.

And the turn around time was insane! In this same month not only did we make the new ship model, the chip prison, the magnet and the fan. The original game Oids also had "fuel pods". You would land next to them. A little "gas hose" sort of deal stuck out and refuled your ship. Kirk made an awesome piece of concept art that lead to this game model:

The Zapper that refueled you

How f***ing cool is that?
Again this is a fully animated model that works in game, also done almost entirely in script. Notice the cool lightning effect across those electro rods. Once you land on the pad needing fuel, the arm comes down and your ship gets hit with lighting. As the lightning fires your ships fuel goes up. The needle indicators on the zapper slowly drain. Once your ship is full the arm retracts. If the zapper has been drained of its energy then the cool lightning effect across the rods would stop and of course the needles would read zero.

The Zapper had some bitchin detail

We Were Gods

We were drunk with power by this point. We were astounded by our own brilliance; and it was quite a technical achievement. We were so astounded, in fact, that it blinded us to the reality that we were not actually making progress. It sure felt like progress. After all...look at the number of features that we got into the game in such a short time! But...consider this: The Magnet, the Bit Prisons, The Fan, and the Zapper do not appear in the current version of the game!

And we were not even done putting stuff into the game! Just like Oids, we added a Missle Dome that would crack open when you got near and emit a Seeking Missle that would come and getcha!

Watch out for the seeking missle!

Conclusion

We added a lot of contant. We went wild. We assumed adding content would magically make the game fun. It didn't. It just muddied the waters more and more. As time went by I started to realize that fighting the muddy waters is a major challenge when designing games.

Deciding what to put in the game is hard. Deciding what to take out is hard. Dealing with a muddy game design that already has too much in there is even harder still.

This is one of the main reasons whey there is a certain order to do things in: start with the control scheme of the "main character", in our case a space ship. Build only enough of the game to test the control scheme. Make sure it is tight.

Next move onto the camera...as many things about the camera heavily influence the players perception of the "main character" being controlled.

You continue with this process, iteratively improving the game in such away that it muddies the waters less and less, rather than more and more.

These are lessons I learned the hard way.

Well...that is all for now. Be sure to tune in next time for Part 4 in the series: Burnt Down, Fell Over, And Then Sank In The Swamp.

Thursday Aug 18 0:54

Paul Dana — 2005-08-18T00:54:09+00:00

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:

1. Guns that shoot you 
2. Anti Grav towers that push you 
3. Magnetic towers that pull you 
4. Teleporters

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:

   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 elements

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.

Friday Aug 5 3:46

Paul Dana — 2005-08-05T03:46:48+00:00

What a long strange trip...

Long Strange Trip, Part 1: The Idea

What a long strange trip it's been...

How stupidly we went about most of it.

I started in March of 2003, a lone coder with a mission: make a game prototype first. Before making a webpage, before forming a team, before making a design document.

It is now Aug of 2005. I have a team, and we have a product: Flash Bios, a 3D Arcade Strategy game. We are in beta and we will ship sometime this year.

In my wildest dreams I did not think it would take us over two years to finish this game. After all...I thought really hard for months and months before I chose a game idea to go with. I sought (and thought I was following) the advice of experienced professionals. I spent a year learning the Torque Engine before trying to make a game with it; doing things like creating the Turrets resource and learning about the art path, etc. I took the humble path. Even though I had over 13 years of professional 3D graphics coding under my belt I still though of myself as a newbie. I would seek advice. I would follow it.

Your asking...then what in God's name happened?

I will tell you. We learned what not to do. The hard way. Blundering our way through this, Jason and I have finally learned how to follow the advice we were receving from the start.

My friend and mentor, Joe Maruschak, has advised me from the very start. He has convinced me to take time I don't really have to write this series of blogs, and tell people the story of our long strange trip.

We are going to highlight the places where we went wrong, how we failed to understand it or to belive the advice we got, and our own views on where we failed to "get it".

Oids

Fugly UFO Donut headed for the Mother Ship

First you need to know about the original 2D arcade style game, called Oids. You can download Oids right now and play it yourself if you like. Be warned this is an ancient game that ran on the Atari ST and the original black and white Macintosh. The download contains an Atari ST emulator as well as the game.

Oids worked like this: your job was to save all the Oids on a Planet before you moved onto the next Planet in the System. Oids were these little robots held in prisons. The Mother Ship would spit you out and you would have to go find the Oids prisons and destroy them to free the Oids, being careful not to shoot the Oids! You would have to destroy any defenses guarding the Oids and then land on flat areas near the Oids. They would hop on board after you landed. Once your ship was holding the max (8) you would have to bring them back to the Mother Ship. Once you freed all the Oids in this way you would move onto the next Planet.

Your ship, the Oids, and all defenses were one-shot-one-kill. If your ship touched anything (other than a flat area during landing) it would blow up. To protect yourself you had a shield that would slowly run down as you used it. Your ship expended fuel when you thrust. You had to eventually find a refueling station and land near it, or bring 8 Oids back to Mother Ship and she would refuel you.

Next Blog...

Read My Next Blog to find out how the original prototype played out.

You will hear how the prototype inspired a team to materialize in front of my eyes, what joe had to say about the prototype, and how we followed some of his advice, but mostly failed to "get it".

Eventually you will find out how, despite being a bunch of utter noobs, we ended up with this:

Flash's stylish ship, the Scandisc and an antiviral bit

Finally, speaking of long strange trips. Some of you may recall that my last April Fools .plan was about going to work for a guy who discovered Atlantis. As I told you then, although it was a joke and I never worked for Robert Samarst, but he really did discover Atlantis.

No kidding.

Also he finally released images he obtained on his expedition last summer. I have been waiting along time to see them. It represents a higher resolution scan of the "wall" he found, confirming what was seen in the lower resolution scan. Ie...that its a wall that travels in a straight line, keeps a consistent width, takes a perfect right angle bend, and keeps on going.

How awesome is this?

Now after your done gaping at that, Read My Next Blog.