GarageGames: Associates Blogs

Michael Perry : What do you think about Documentation?

Michael Perry — 2008-05-15T14:10:25+00:00

***Greetings all!***

Let me get it out of the way right now:

This is a NO frills .plan. I wish I had some pretty pictures or wicked exciting news, but this blog exists purely for informative reasons. I'm tired, I just got back from an hour long dentist appointment, and I can't have my morning coffee because it keeps spilling out of my completely numb mouth. So, please forgive me if I can't scour the internet for LOLCat pics to post here =)

DOCUMENTATION
A dreaded word....Everyone WANTS it, a lot of people hate writing it, and the writing process will NEVER be finished since new versions of the engines are being released all the time. Thankfully, there is a group of people who still want to do the work, and even one insane person who actually LOVES writing documentation...ahem...

TGEA Started It All
During the TGEA 1.7 beta, I created a thread in the private forums: TGE 1.7 Documentation Feedback. The purpose of the thread was to provide a central location for TGEA users to post their feedback, criticisms, and suggestions for the new docs. The response was overwhelmingly positive, constructive, and key to getting new docs and fixes to the user for the release.

So, it's time to show the same attention to the users of the other awesome Torque engines. Stephen Zepp has created a thread in the TGB area, and every other engine has its own as well. Going a step further, the new threads are posted in the PUBLIC area, just to show some love to the people who have yet to purchase a SDK. Every opinion counts, and your feedback will help out in more ways than one. =)

TGEA Documentation Feedback
TGE Documentation Feedback
TGB Documentation Feedback
TorqueX (TX) Documentation Feedback
TorqueX Builder (TXB) Documentation Feedback

In each thread, there is an explanation, purpose, and suggestions on what we are looking for. Each thread will be monitored carefully, so let's get this rock rollin'

Edits: OK, I had to sneak in images. The plan was just too boring =)

Matt Vitelli : Day and Night System

Matt Vitelli — 2008-05-15T01:17:42+00:00

For the past few months, I've been actively pursuing terrain and skybox code to allow dynamic day and night cycles. Day and night cycles are important, especially in sandbox games. Currently, I've been getting some impressive results that are fairly inexpensive. Currently the code requires the use of a specific art pipeline. In time I plan on making the system completely automatic so developers are able to drop levels in and automatically generate the necessary media for the level. In the future, I also plan on having a per-surface detail mapping system allowing users to add as much detail as necessary to the scene. It would also be spiffy to implement a layers system similar to Id's tech 5.

Adam Beer has been extremely helpful in his testing, feedback, ideas, and thoughts. Below is a video he created using the new terrain and sky updates:

www.box.net/shared/xa4pvflcsc

Here is a YouTube video demonstrating the skybox system.

Here is a YouTube video demonstrating the terrain shadowing updates.

Chris Calef : Fun with BVH Files, in Torque.

Chris Calef — 2008-05-14T07:05:33+00:00

WARNING: this blog is rather long and technical, and very heavy on animated gifs! Feel free to cruise through it and just look at the pictures. Or if you just want the code, skip to (HERE). I am including gratuitous explanations in the pages below, in the hopes that it might assist some artists or programmers to have a better understanding of how shapes, skeletons, and sequences work in Torque. Take from it what you will.

This resource is not guaranteed to work, and the user should download it at his own risk. Chris Calef is in no way responsible for anything that might happen as a result of downloading this resource.

----------------------------------------------------------------------------------------

So, anyway, a few weeks ago, an acquaintance dropped a three-letter acronym on me that momentarily changed my life and transformed me into a single-minded, obsessed, fanatically driven introvert. (Okay, so it wasn't that big of a change. My friends didn't really notice.) He said:

"Hey, do you know anything about bvh format?"

I'd had experience with motion capture before and knew there was a lot of data out there -- but I've been busy doing other things for the past couple of years. I have been interested in the engine side of character animation for a long time, though, and wanted to hone my skills a bit in that department anyway.

But as an indie developer, I also just want an easy, cheap or preferably free way to make use of the huge variety of bvh files that are out there on the internet, without buying or even having to learn to use any major art applications.

Call me lazy, I guess, but I'm a coder. I hate using GUIs.

I do also have the impression, though, that even with all the latest tools and techniques, it isn't always easy for artists to convert an animation that was made on one skeleton into a sequence that works with their particular model. The results of failure sometimes aren't pretty.

Well, I'm happy to report, mission accomplished! Some time later, I emerged from my lair with a couple of big shiny new ShapeBase functions that do everything I asked for. Now all I have to do is download a bvh, load up a player, type "$myPlayer.importBVH(coolNewAnimation);" at the console, and voila!

Well, okay, I'm exaggerating just a little. There are a couple of other steps you have to take. But once you get it set up, it's just about that easy.

Just so we're all on the same page, here's what a typical BVH file looks like:

It's a really simple, plain text format that is quite easy to parse. The skeleton is defined at the front of the file, and then the rest of the file is filled with all the frames data. Each line of frames data represents one frame, and all the rotations and translations for all the bodyparts (there can't be any left out) are stuffed into that one line, separated by spaces. Like this:

As you can see, it makes for pretty long lines.

One complication that became immediately evident was the fact that not all the files agreed on whether nodes should have six channels or three. The most efficient and logical method would be to include translation information for the base node, and then only rotations for everything else, since each node has already defined its offset with regard to its parent, and that's all you really need to know.

However, many sources of motion capture data seem to be less than perfectly efficient and logical, and include all six channels for every bodypart. I even found one bvh file that had NINE, adding scale to the end. (It was always "1 1 1", but it was good to know it was there, just in case.)

Also, many files had a lot of float garbage in them (numbers that should have been zero coming out like "-8.88178e-016"). This may not be terminal, depending on how you're scanning the data, but it's just ugly and I wanted it gone before I even started thinking about making these things work with my character.

So, I added another little ShapeBase function: "$myPlayer.cleanupBVH(coolNewAnimation);". What it does is loads up the entire bvh file (in this case "coolNewAnimation.bvh"), changes float garbage to zero, changes channels to three, deletes all the node translation data except for the top node, and then writes it all back out to "coolNewAnimation.new.bvh". It also cuts everything back to a reasonable number of decimal places, like "4.356" instead of "4.3564786755". These files are plain ascii text, and are pretty darn big anyway; I found that just by chopping off that unnecessary resolution, I could drop the file size by a lot.

So, cleaned up, shrunken down and reasonably efficient motion files in hand, the next step to make this work was to get it into a Torque character. For this, I started with a handy character from BrokeAss Games, who was rigged with globally aligned local bodypart orientations and hence was a convenient testing ground. (If you have no idea what that last sentence meant... stick with me, all will soon be made clear.)

This is where the rubber really hits the road, because the main problem people have with using other people's animations (and this is true whether we're talking about dsq files or bvh files or anything else) is the fact that all models do not share the same skeleton. Even though all normal humans may have two arms, two legs and a head, there is no protocol in place to define whether the right upper leg is called RThigh or RUpLeg or right_femur or what. It's entirely up to the artist, and this is the first of our problems. Often this problem alone keeps people from being able to share animations.

It gets much worse than lack of naming conventions, however. Even if we had two skeletons with exactly the same bodyparts, with the same names, defined in exactly the same order, the real stickler is going to come when we look at how the geometry itself is aligned with the world. When an artist is making a character, they might decide that the right upper leg could be represented by a cylinder, which they will then modify and attach to the rest of the body. This cylinder will be created by their modeling application on some initial axis (like, horizontally on the X axis), and they will then rotate it around to the position they want that leg to be in, and attach it to the body.

This is all well and good, but this means that when we want to rotate this bodypart, we have to be aware that it has local axes that differ from the world. For the right upper leg, the direction that the world calls "down", or negative Z in Torque, might actually be positive X.

This problem right here is why you can't just past rotations from one model into another without them looking really stupid. Working around it can be kind of a brain twister. I had to solve this problem once before for the ragdoll pack, though, so I wasn't intimidated this time.

The solution I came up with was to address all of the above problems in one little plain text config file. Often one config file for a model will work with a whole set of related bvh files, but I set it up so you can make one config file per model per animation, to cover all possibilities. You simply name your cfg file after a particular motion (if you have a "frontkick.bvh" to import, then name the config file "frontkick.cfg") and keep it in the same directory as your bvh files for this model. If the system doesn't find a cfg file named after this motion, it then looks for one named "default.cfg" in the same directory.

Default.cfg for Kork came out looking like this:

The first column of numbers is the index of the bones in the bvh skeleton, mapped to the second column which are the corresponding nodes in the dts model. All the rest of the numbers are Euler vectors that represent rotations.

Along the way here I also added a few handy console methods, just to get a better look at my models and sequences. One of them, "$myPlayer.showNodes();" prints out the list of all the nodes in this shape, with their IDs. It makes the mapping part a little easier.

In this case, I had the following skeletons to match up:

KORK

BVH

The reason I started with the BrokeAss model instead of Kork is because when you look at him in ShowTool, you find that in his default position, standing straight up with his arms held straight out, all of his bodyparts have local axes that exactly match the global axes. With Kork, as with most other character models, this is most definitely not the case.

This is only our first problem, however. When it comes to node rotations, there are really two separate issues to deal with. Besides our local node transforms, we also have to take into account the fact that our models may not be starting in the same position, either! My BVH character is defined with his arms down at his sides, but even my friend the BrokeAss Guy starts his life with his arms straight out. This means that even though a Y axis rotation might mean the same thing to both characters, a ninety degree rotation for the BVH guy lifts his arm from down to straight out, while the same rotation on the game character raises his arm from straight out to straight up over his head!

When we get to Kork, he's even worse -- he defaults to "standing holding a weapon" where none of his limbs are aligned with any axis at all.

So, let's take a look at that cfg file for Kork again:

0;0;(-0.0674,-86.4207,-0.0969);(0.0,90.0,0.0);(0.0,-90.0,0.0);(0.0,0.0,0.0);
1;18;(11.7373,-168.9883,-27.6818);(0.0,180.0,0.0);(0.0,90.0,0.0);(0.0,0.0,0.0);
2;19;(0.0,0.0,-44.9645);(0.0,0.0,0.0);(0.0,90.0,0.0);(0.0,0.0,0.0);

After the node mapping, there are four sets of Euler vectors (rotations about X,Y,Z). The first two are for putting the body physically into the position of the bvh character (arms down), and the second two are for dealing with the local rotations of the nodes once we get into this position.

That file's pretty ugly, though, so let's go back to the easier one. Recall that our BrokeAss human has his arms out, and all I need to do is to move his arms down in order to match my bvh position:

10;30;(0.0,90.0,0.0);(0.0,0.0,0.0);(0.0,-90.0,0.0);(0.0,0.0,0.0);
11;31;(0.0,0.0,0.0);(0.0,0.0,0.0);(0.0,-90.0,0.0);(0.0,0.0,0.0);
12;32;(0.0,0.0,0.0);(0.0,0.0,0.0);(0.0,-90.0,0.0);(0.0,0.0,0.0);

How about that? What we're looking at right there is the left shoulder, elbow, and wrist. Since the local axes are all global, and our character has Z up and Y forward, then all I have to do is rotate his shoulder 90 degrees on the Y and it will make his arm point down to the ground instead of out to his left.

This is all good, but what happens to our local axes when we do that? Suddenly our left shoulder, forearm and hand, which used to be pointing toward toward negative X, are now pointing toward negative Z! Oh no! What do we do?

That's where the last two numbers come in. No matter where we end up, it is always going to be possible to rotate our frame of reference back to the global, in two if not in one set of X,Y,Z rotations. (It's possible in one, but for humans it's sometimes much easier to use two, so I included that option. It turned out to be a very good idea, as we'll see shortly when we get back to Kork.) For our BrokeAss human's arms, then, we simply take the reverse of the ninety degree Y rotation we did at the shoulder, and lo and behold, everything works!

For those who are interested, the actual transform process looked like this:

m.identity();              //Start with an identity matrix.
m.mul(matBvhPose); //move this bodypart from its default pose to match the bvh pose.
m.mul(matAxesFix);  //then temporarily move it back to get the local axes matching global.
m.mul(matY);            //then do the bvh rotations
m.mul(matX);           // ...
m.mul(matZ);          // ...
m.mul(matAxesUnfix); //and then rotate by the _inverse_ of that temporary transform,
                              //to take it back out. Voila!

This wasn't too hard with the BrokeAss guy, since all I had to do was rotate his arms, but what about Kork? What are we supposed to do with a guy who not only has a huge mess of local transforms, but then he's standing there holding a crossbow instead of politely keeping his arms out?

Well, this could be nasty, but it turned out it wasn't all that horribly difficult, either. All you need to know is that Torque has a lot of useful quaternion and matrix functions, and my current favorite is called MatrixF::toEuler(). What it means is if you have a matrix representing your current position, and you take its inverse (which brings you back to the global frame of reference), and then you call toEuler() on that inverse, what you end up with is three magic numbers that you can plug right into my config file. Weird starting position, gone!

In code, it gets slightly complicated by the fact that we have to go from Quat16 to QuatF to MatrixF in order to make it work, but that's not so hard:

q16 = kShape->defaultRotations[2];
q16.getQuatF(&myQuat);
myQuat.inverse();
myQuat.setMatrix(&myMatrix);
myEuler = myMatrix.toEuler();

Unfortunately, if you have no starting position at all, what you get is this:

And that's why I'm glad I gave myself two Eulers per operation instead of only one. Now that I'm back to null, it's pretty easy to rotate Kork's bodyparts around with 90s and 180s until he's standing up with his arms down:

0;0;(-0.0674,-86.4207,-0.0969);(0.0,90.0,0.0);(0.0,-90.0,0.0);(0.0,0.0,0.0);
1;18;(11.7373,-168.9883,-27.6818);(0.0,180.0,0.0);(0.0,90.0,0.0);(0.0,0.0,0.0);
2;19;(0.0,0.0,-44.9645);(0.0,0.0,0.0);(0.0,90.0,0.0);(0.0,0.0,0.0);

When trying to visualize all these rotations, it can help to draw yourself a picture (see below, sorry for the sloppy artwork.) This is Kork with his back to us (so we're all facing the same direction), if he was standing with his arms out. Globally the X axis (red) goes to our right, Z (blue) is up, and Y (green) should go into the page.

And that's really the process, in a nutshell. Once all the frames are loaded and suitably processed, my importBVH function simply adds a sequence to our TSShape, sets it up with whatever flags it needs, and adds all of our new rotations and node[0] translations to the shape's nodeTranslations and nodeRotations lists. (If you have a Torque license and want to see the actual code, go (HERE)).

And with that, I believe I will draw this lengthy and perhaps overly detailed blog to a well-deserved conclusion. In the tradition of free motion capture files on the internet and many years of great advice and free stuff for Torque, I'm just going to throw this little project out there gratis as a "thank you" to everybody who's ever helped me figure something out. Have fun, and make awesome games!!

<shameless plug>
I am available for contract work, however, so feel free to get in touch with me if you need help!
chris (dot) calef (at) gmail (dot) com
<end plug>

Paul Dana : 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.

John Kanalakis : Torque X Book Completed

John Kanalakis — 2008-05-04T03:48:46+00:00

It's finally finished. After several months of work, the The Complete Guide to Torque X is finally completed and on its way through the rest of the book publishing process. I'm not sure about the final page count (since it still needs to go through copy-editing and layout). But it should be really comprehensive. Here's a sneak preview of the topics covered in the book. (Not the final book cover)

Introduction to Torque X

The first chapter provides an introduction and overview of XNA and Torque X. It covers some of the history behind XNA and its roots in Managed Direct X. It goes on to explain the benefits Torque X adds on top of XNA to quickly prototype and create new games.

Part One: Torque X Game Design Tools

Chapter 2 dives right into game development by describing the Torque X Builder 2D game design tool. It starts by creating a new game project in XNA Game Studio and then use Torque X Builder 2D to pull game art assets together and organize them into game levels. The chapter ends by building a simple game using only the stock Torque X components applied to different scene objects.

Chapter 3 works with two more important Torque X Builder 2D editors, the Tilemap Editor and the Particle Editor. Both are important tools to understand when building games with Torque X.

Chapter 4 introduces the Torque X Builder 3D game design tool and shows how to create material definitions, position game objects within a scene, assign components, and then save the resulting 3D scenes.

Part Two: Programming with Torque X

Chapter 5 begins shifting game development work from the designer to code. This chapter presents an introductory overview to the C# programming language. In outlines the fundamental aspects of the C# language that will be used most throughout the remainder of the book. Concepts, such as classes, object, interfaces, and delegates will all be spelled out.

Chapter 6 introduces to the key classes that make up the powerful Torque X Framework. Understanding these classes will be key to successfully creating games. This is also where components will become familiar with examples of how to use them.

Part Three: 2D Game Programming

Chapter 7 begins working with the Torque X Framework code by manipulating tilemaps and uses them to build a completely Tilemap-based puzzle game.

Chapter 8 focuses on the 2D representation of a player and its related responsibilities, such as responding to player input positioning the player on screen, animating the character, and interacting with other game elements. This chapter presents the inner workings of components and best practices for creating them.

Chapter 9 adds more common 2D game functionality using components. In doing so, it uncovers more useful Torque X Framework classes and reveals best practices for designing and creating your own game components.

Chapter 10 continues to create additional components that enhance gameplay features. It creates three new components that implement some basic artificial intelligence for game enemies. In addition to adding some interesting game functionality, these components demonstrate some important lessons.

Part Four: 3D Game Programming

Chapter 11 exposes the fundamentals of 3D game programming. This chapter discusses the concepts of 3D coordinates, vectors, scene graphs, models, and animations.

Chapter 12 applies the new knowledge of the Torque X 3D Framework to create a series of player-centric objects. This chapter applies the same techniques of modular design to create re-usable game components that will move and animate a 3D player.

Chapter 13 shows how to create additional 3D game objects. These useful game objects will work together to help implement a basic first-person shooter game.

Chapter 14 revisits some of the AI concepts discussed earlier and translates them into 3D space. This chapter shows how AI components that were easy in 2D quickly get complicated when it applies to 3D space.

Part Five: Finishing the Game

Chapter 15 explores the audio tools available for creating sounds with XNA. Adding audio to a game using XNA is much more restrictive than for a PC game since the game must run within a managed code environment. There are restrictions on audio formats and compression that need to be met.

Chapter 16 explains the fundamentals of GUI building with Torque X and then applies those fundamentals to create some game setup screens and HUD controls.

Chapter 17 explains materials and shaders and how shaders effects can significantly enhance the visual appeal of a game by adding more to the screen rendering process. This chapter dives into the Framework code, tools, and effect files that put shaders to work.

Chapter 18 will focus on what's involved with moving a game over to the Xbox 360 game console. This starts with design considerations for games that target the console and television. Then, this chapter covers specific steps involved in moving a game onto the Xbox 360, using the project converter, XNA Game Studio, and a Creator's Club membership.

That's about it. It took about seven months to pull all of this together. The biggest challenge was probably trying work on the book in middle of some big changes to Torque X. I will also be managing a new website dedicated to the book, where I can post book updates, downloadable code, and a forum dedicated to answering questions about the book. The site is going to be located at: TorqueXBook.com and should be available in a few days. But now that the book is finally finished, I can get back into the Torque X forums more often ;)

John K.

Edward F. Maurina III : Psssss... Hot!

Edward F. Maurina III — 2008-04-25T22:33:46+00:00

Sure it may be a bit self-serving to call my own work hot, but hey, what good is a blog if I can't beat my own chest every once in a while?

It isn't just a pride thing either. I'm happy about completing MGEC for all of the following reasons:

1. MGEC is the pinnacle of a long personal journey. (See below to learn more.)

2. MGEC provides a seamless follow-on (harder than it sounds) to my first book GPGT. i.e. If you liked my first book I think this one will also serve you well.

3. MGEC acts as a gateway-guide for experienced Torque users who want to jump from script-only mods to C++ engine changes. Users can learn to mold TGE(A) to their game's own unique requirements. In short, you no longer need to be afraid to modify the engine. With this guide you can do it!

4. Lastly, now that I have finished the books, I can start to re-focus my energies on other projects. It would be fair to say that I've been tempted on more than one occasion to work on side-projects, but I've had to reign myself in, in order to get the work done. No more. I can now set the whirlwind loose.

I realize that some folks may be sitting on the fence still, trying to decide if this guide will be useful to them. If you're one of these people, please check out these links to get more information on my second book:

Table of contents
The Introduction
Chapter 01 - Exercise #1 - Using The Kit
Chapter 10 - Exercise #1 - Compiling Torque In Windows
Chapter 10 - Exercise #2 - Compiling Torque In OS X
Another blog I wrote about it.

If you have decided you want a copy, it can be found at Amazon, as well as Barnes and Noble.

More about the journey
Finally, as noted above, this has been a very long journey for me. Some time after finishing my last book, and before finishing this one, I wrote up a post-mortem on the topic. If you're interested and never got the chance to read them, you can read them here (on the GG site):

GPGT Postmortem - Part 1 of 3 (History)
GPGT Postmortem - Part 2 of 3 (Project Analysis)
GPGT Postmortem - Part 3 of 3 (Lessons Learned)

, or you can download a PDf version here: .

Note: I did learn from the lessons listed in part 3 of the post-mortem and I think you'll agree that I applied those learnings well to my second book.

Thanks for reading!

Hall Of Worlds - For Gamers (soon to be The Roaming Gamer)
EdM|GPGT || MGEC

Ian Omroth Hardingham : Divorcing from TGB in search of nicer TATs

Ian Omroth Hardingham — 2008-04-23T20:51:27+00:00

This is taken wholesale and lazilly from the Mode 7 blog but I thought it might interest a few people here. I should state that I was using TGB 1.1 (I don't believe in porting unneccesserily. Or spelling it) and that I'm currently very impressed with TSE 1.7

The original Frozen Synapse prototype was written on Torque Game Builder. After a lot of talking we've decided that we're going to make it more PC-centric than previously thought and to use the shaderific Torque Game Engine Advanced (previously TSE and the hilarious TAT) to do some interesting new stuff with dynamics-led art.

I was putting off the port for some more gameplay dev, but finally last week I found a crash in the TGB FS prototype. It was one of TGB's internal systems barfing at the unusual strain FS was putting on it. In other words, time to separate egg from incubator.

Luckily I had always wanted the core "simulation" aspect of FS to be separate from rendering of any kind (making it more portable), so this wasn't as hard as it could have been. However, writing my own 2D collision engine in three hours and porting FS to it still makes me quite happy. I also got it debug-rendering just using GL calls but consdering it's all rotated bitmaps that's not really the hardest thing in the world.

Frozen Synapse is now ready to move to TGEA. I'm very excited about the process of getting it to look good.

John Kanalakis : Torque X Builder 3D Progress: The Axis Gizmo

John Kanalakis — 2008-04-22T02:14:55+00:00

Torque X Builder 3D is coming along very nicely. I have received a lot of great community encouragement and feedback. And as a part of that community, I'm doing my best to factor in all the feedback. I'm also limiting how much I "perfect" the tool in order to get it finished as quickly as possible. Today's focus is on the Axis Gizmo. Since the main goal of TXB 3D is to make Torque X 3D scene creation easier, the Axis Gizmo is a really big part of hitting that goal.

The problem is that creating an Axis Gizmo is not as easy as it sounds. I spent a lot of time researching differnt methods of creating an Axis Gizmo and the one thing I found is that there really is not much information out there about it (or I'm really bad at online researching ;) ). This becomes even more complicated when you need to work within the limitations of the XNA Framework, where simple rendering primitives, such as line and circle drawing, simply don't exist. So, what does one do? I broke the problem out into two smaller problems: rendering the gizmo and processing the user input. I naturally started with the easier problem.

Processing Input
Processing input is pretty straight forward in Torque X, since it just involves creating an InputMap and processing Move structures, just like any other Torque X game does. It took a little more to work to figure out the dragging functionality, and was implemented by tracking the mouse button states. The scene object movement is accomplished by setting the T3DSceneComponent position position by scaling the mouse input. The harder part to figure out was how to select objects in the first place. In short, you need to get the position of the camera, take the mouse's X and Y screen coordinate, scale the position to the view frustrum (accounting for FOV and Aspect Ratio), and then cast a ray forward into the scene and test which 3D shape's bounding box is hit. So, now that shapes are being selected and dragged around the screen, I needed to have some sort of visual representation for the Gizmo.

Rendering the Gizmo
I started out by creating one by hand. The following lame gizmo (shown in the last blog) was created by dynamically generating 3 tall and thin boxes. It was functional, but the Gizmo looked pretty bad as you can see here:

The biggest lesson learned was that the "implementing the Gizmo as a mesh" solution was working. Great! Now, it's a matter of getting it to look good. I received a lot of great community feedback to work with (Thanks James B. and Chris K.). So, I popped open my favorite 3D Modeling program and produced 3 models to represent the Gizmo in the three different functional states (move, rotate, and scale). I exported the models into the .FBX format (native to XNA) and used the T3DXNARenderComponent to render them on screen. The models are simple enough to scale them up and down to match the size of the object selected. Here's how they look in each mode:

Translation Gizmo Arrows

Rotation Gizmo Rings

Scaling Gizmo Blocks

The Gizmo meshes can probably be improved, but most likely won't for a while. Since they are working out well enough, I'm moving off to the next challenge. Again, I'm taking every possible shortcut to get this out as quickly as possible. I just wanted to take a few minutes and write about creating the Gizmo, because everything involved used stock Torque X code. This is just a testament to the power of Torque X that's already built-in... Great Job GG!

John K.

Jeff Faust : AFX 1.1.2 for TGEA 1.7.0 Open Beta

Jeff Faust — 2008-04-17T16:45:14+00:00

Recently GarageGames officially released TGEA 1.7.0, a rather vast update to the TGEA engine. For several months we have been tracking the evolution of this release and in parallel, have been porting AFX for TGEA to it. Since the open beta releases for TGEA 1.7 went so well we are doing the same for AFX.

Right now, if you have a license to AFX for TGEA (ComboPack or CoreTech), you can download a copy of the AFX 1.1.2 for TGEA 1.7.0 Beta from the AFX for TGEA download page on your account page.

Please refer to this thread in the AFX private forums for more details regarding the open beta:
www.garagegames.com/mg/forums/result.thread.php?qt=74306

There were so many changes to the TGEA engine between version 1.0.3 and 1.7.0 that we decided to keep the AFX update for 1.7.0 as simple as possible. As such, this AFX upgrade adds little in the way of new AFX capabilities and focuses on making existing capabilities compatible with TGEA 1.7.0. However, we have been prototyping many exciting new AFX features in our development branch and look forward to releasing much of this tech in a future release. Also, we are just beginning to work with some of the excellent new assets available in TGEA 1.7.0, many of which would look great in some sci-fi oriented demos.

Finally, I just want to extend a big thanks to GarageGames for granting us early access to the TGEA 1.7.0 project. Without this we could never have released a compatible version of AFX so soon after the TGEA 1.7.0 release.

Enjoy the AFX 1.1.2 for TGEA 1.7.0 Beta!

Joseph Greenawalt : Blender DTS Exporter 0.96 Released

Joseph Greenawalt — 2008-04-10T01:52:43+00:00

A new 0.96 version of the Blender DTS Exporter for Torque has now been released.
The new version requires Blender 2.44 or higher, and should be compatible with the upcoming Blender 2.46 release as well.

You can download the new exporter release on the exporter project site.

(edit - the project site release system is now miraculously fixed :-)

Be sure to check the Readme.html file included with the exporter if you are a new user, or if you run into problems.

What's New for version 0.96

* New: Added support for IFL (Image File List) animations.
* New: Improved support for mesh visibility animations. Visibility animations are no longer tied to materials, and can now be set up through the exporter GUI on a per mesh basis. Multiple meshes can be included in a single visibility animation, each having their own separate visibility track. IPO curves from objects or materials can be selected through the exporter GUI to drive each visibility track in the animation.
* New: Users can now set a start and end frame for actions (optional). This means that actions can now be set up using non-overlapping frame ranges, which allows for the use of objects as constraint targets for multiple animations. This feature is entirely optional, and must be enabled by turning off the "Auto Start/End Frames" button on the actions panel (can be set per-sequence).
* New: Sequence frames per second OR duration can now be set through the exporter GUI on a per sequence basis. If the FPS for a sequence is changed, the duration is automatically adjusted and vice-versa. Either of these settings can be "locked" such that when frames are added or removed from the animation, the locked setting (either duration or FPS) remains constant.
* New: Complete rework of the Sequences tab of the exporter. It now contains 4 sub-tabs:
....* Common/All - Contains settings that are common to all types of animations. Also contains a bar graph showing the length of each animation contained within a sequence (Actions, IFL, Visibility, etc.). The bar graph is designed to show, at a glance, whether the lengths of the animations contained in a sequence are the same.
....* Action - The Action panel contains settings that are specific to action animations
....* IFL - This panel is used to create Image File List animations.
....* Visibility - This panel is used to create Visibility animations.
* New: The exporter will now prompt the user if no shape marker is found. If the user chooses, a shape hierarchy will be automatically created and set up with a default detail level (size 1). The exporter guesses which meshes are collision meshes and los meshes by examining the first three letters of the mesh names (looking for "col" and "los"); everything else is placed under Detail1. This should make things a little easier for people who are using blender as a stepping stone to export purchased content or content imported from another modeling app. It might also save experienced users a few seconds creating and parenting empties.
* The effects of mesh modifiers are now applied to meshes in the exported dts file. The Blender modifiers themselves are not applied to your Blender objects. Unfortunately, due to a limitation in Blender's Python API, modifiers will be ignored for skinned meshes (you can still apply them by hand, however).
* Rearranged and relabeled controls on the "Materials" panel. The two most problematic settings (Reflectance Map and Bump Map) are now hidden behind a "Show Advanced Settings" button. Added a new "IFL Material" button used to mark a material for use in an IFL animation.
* Changed all occurrences of "TSE" to "TGEA" (I guess this name is the one that's going to stick :)
* Fixed triggers not firing when no ground frames were being exported for a given sequence.
* Scaling and rotating the marker empties is now supported.
* Numerous bug fixes, etc.

Many thanks go out to everybody who helped with this release; and special thanks to James Urquhart for writing the exporter in the first place. Contributors and Testers are listed below:

Adam Wilson
Philippe C
Dave Young
Bernard Hugueville
Owyn Murtason
Ziba Scott

And thanks to anyone else who I missed.