Blog for Devon Winter at GarageGames.com

Windstorm Update - Of Avatars and Interfaces

Devon Winter — 2008-09-03T13:20:00+00:00

So it's certainly been awhile since my last post, but it's not because I haven't been busy. In fact - it's just the opposite. I've been insanely busy. Here's what's up with Windstorm.

Windstorm had gotten to the point where a significant number of the core systems were in and working. You could equip and unquip clothing. You could equip weapons and animations switched accordingly. Basic mob AI was in the game, and you could aggro, kite, kill and leash mobs. The ability system was in place, and you could receive innate abilities, and you could tie abilities to items. I had implemented a quest system that already supported two basic types of quests. I had also created a loot system, complete with loot tables for the mobs, and you could get money and ph4t purpz from mobs. Okay maybe not purpz but certainly goodies. And rudimentary vehicle support was in. You couldn't attack from vehicles yet, but you could get on one and ride it around and get back off. So basically everything was in place to create a simple scenario where you talked to some NPCS.. received some gear.. got some quests.. killed some mobs and retrieved a jetbike.. turn in those quests, and was rewarded. I was feeling pretty damn good about how things looked.

Of Avatars
I decided before I went and implemented too many more systems, I wanted to update Windstorm's look a bit. My current avatar, while adorable, didn't look very scifi-ish. And she was going to need a lot more animations. In fact I had pretty much reached the point where I couldn't go forward without the ability to create some truly unique animations. So I figured the time was now to create a new, custom avatar for Windstorm. I would learn to model and animate her, and put myself in a position to continue to create and export whatever my crazy design ideas came up with. So I spent the better part of two months attempting to do just that. I wrestled mightily with Truespace and Gamespace and plugins and in the end, didn't get anywhere near what I wanted. What I did get was a whole heap of frustration.

Along about that time I spotted Pam in the content store. Pam was pretty much exactly what Windstorm needed. She had Windstorm written all over her. But she was going to need a lot more animations, even just to get where I was currently with the Cubix Studio Female. And Pam didn't use the default Kork skeleton setup, so she wasn't remotely compatible with Motion Studio. So I contacted 3DGDA, and asked them about costs for custom animations for Pam. We struck a deal, and I gotta say, those guys were awesome! They were very reasonably priced, they did the work in exactly the amount of time they quoted, they were great about iterating over the animations until I was satisfied with the final product. Very professional, very competent. I have tons more modeling and animation work yet to do, and I have every intention of utilizing them some more when I get the project to the point where it's ready for it. We had a new avatar, and I was exceptionally happy with her.

So with the new avatar in place, it was time to tackle the next big system - vehicular combat. Or so I thought. See, vehicular combat is going to be a huge part of Windstorm, and I wanted to take some time with it - not just hack something in. I spent many morning drives in to work going over in my head the various designs for how vehicles would interact with classes, and abilities, and weapons. I eventually came up with a solution that I really liked. Now my entire design for those systems and how they relate to each other could take several blogs in and of its own right. But for now, suffice it to say I came to realize that in order to implement vehicles in the way that I really wanted to, because they were going to be closely linked with abilities and weapons, well I was first going to have to revamp my current weapon and ability design. Of course, right? So actually the next thing to do was not vehicular combat, but an overhaul of the weapon and ability systems.

Of Interfaces
Not to bore you with too much detail, but in the original system, abilities were the damage-doers, and weapons were modifiers to that damage. So you would have a "Sharp Shooter" ability that did X amount of damage with a certain chance to hit and had a certain range. If you equipped a shotgun, the damage would be increased, but the range lessoned. If you equipped an assault rifle, the range increased, the chance to critical hit increased, but the base damage reduced. That sort of thing. This was pretty clean, and certainly worked, but in the end, I came to realize that people don't want to think of weapons as modifiers - no matter how cleanly it works in your system. So in the new system, weapons are the damage doers, and abilities modify that damage. It's a bit like Star Wars Galaxies worked, but there are quite a number of other significant differences as well. So the main change to the system was reworking how abilities and weapons related to each other, and restructuring all the datablocks to support that new design.

Out of this design was born a number of changes to the UI, including an entirely new UI element - the Weapon Panel. The Weapon Panel is the interface that in one small window is supposed to give the user everything he needs to know about the weapon he has equipped, and the abilities he can use with that weapon. So.. uh huh.. you guessed it. In designing the new interface element, I decided now would be a good time to update the look and feel of the interface as well.
The existing interface is plenty functional. Not hideous by any means, but not exactly eye catching either. It definitely was not what I wanted for the final interface for the prototype. I hate doing things over when I don't have too, and as I was going to be creating new interface elements and revamping many of the old ones, well I might as well update the art too. So another week spent brushing up on my programmer-art photoshopping skills, and then I started tackling all the various pieces of the interface. And dayum, I gotta say I didn't realize how much interface I'd already built in the game.

A Thousand More Words
Okay, enough of teh wordz. Time for some piccies. Let's do some before and after.
Here's how Windstorm looked at the beginning of the summer. You'll recognize Cubix Studio Female, (affectionately called Cindy by yours truly), and probably some other stock art as well. And of course, the old interface.

Here's the new Windstorm. Of course, you'll recognize everyone's favorite scifi girl, Pam. And the new interface. And the Weapon Panel of which I spoke of. What do you think? I went with the glass-bubble look that's all the rage in interfaces these days (just look at CBS Sports if you don't believe me), though in the typical "less is more" paradigm, I could probably tone down the glass effect some - and probably will. I'm pretty happy with it, but comments and criticism are certainly desired and appreciated.

And what's this? Yap.. that's Pam racing along on the BraveTree Jetbike (my one sci-fi vehicle in the game), sporting one of her new custom animations, a custom version of scout-root. I don't know about you, but I think she looks pretty sweet on that bike.

Okay that's all for now. Still got tons more to do, and not nearly enough time to do it.

Devon out.

On Cursors and Code, and Mickey Mouse

Devon Winter — 2008-07-08T12:02:58+00:00

So summer vacation was a blast. If you're planning a family trip to Disney World, I have two recommendations I would absolutely make:

1.) Wait until you're children are at least 5 or older. Seriously. If you're like us, and you try to do four Disney Parks and one Water Park in five days, you do *not* want to be pushing anyone, or carrying anyone by the end of the day. Plus, your children will be old enough to actually enjoy and remember the occasion.

2.) And this is a MUST -- Buy this guide: The Unofficial Guide to Disney World This thing is basically a Jame's Leveling Guide to Walt Disney World. Seriously! Worth it's weight in gold in giving you the the *best* plan for managing each trip to each of the Disney parks. Crowds at Disney are impressive. But if you manage your trip, you can totally still beat them -- even in peak season hours. But if you just walk into the park around 11:00 am all wide-eyed and open mouthed.. well, expect EPIC FAIL.

So upon returning, it was time to integrate Torque 1.7.1 into my project. If you recall, I'd just upgraded from TGE 1.5.2 to TGEA 1.7.0, and lots of things were pretty broken. Before I could finish though. TGEA 1.7.1 was released, so before I spent too much time fixing things, I figured I'd integrate that version as well.

It went.. surprisingly well. The entire project was integrated in less than half a day, which, as those of you that have done integrations before know, is not too shabby. One of the main reasons I think things went as smoothly as they did was that this time, when I set up my project in perforce, I went to special lengths to set things up to facilitate integration later on. And, surprisingly enough, it worked! It worked so well, that I thought it might be useful to share. I've leeched plenty from this community, so I figured it was time to give something back.

So while I know it's not terribly sexy, I've submitted a resource on setting up a Perforce depot to work with TGEA. I have no idea how many people may or may not find it useful. But I do firmly believe two things. One -- You absolutely should be using some form of revision control, and two -- the decisions you make early with how you set things up will greatly affect how easy (or difficult) it will be to integrate changes later.

The resource is still awaiting approval, so once it's approved I'll add a link here pointing you to it.

And here it is: Setting up a Perforce Depot to work with TGEA

Enjoy, and if you find it useful, please rate it/pass the word!

So once the integration was complete, well heh.. all my bugs didn't magically go away. I know, right? Go figure. The first thing I tackled was my software cursor, which had mysteriously disappeared. Big thanks go out to Rene Damm for posting up mods to the engine in this thread for returning the use of software cursors whenever you want them. Thanks Rene!!!

And Dear GG - Please integrate this (or something like it) in a future release. Lots of us are still making games that would like a software cursor. A global flag enabling or disabling such is exactly the kind of things that makes it easy to do. Love, Devon.

That's all I have for today. I fixed lots of other bugs, including porting the texture layering system over to use the new TGEA Material system. I also found and fixed a small bug in TSMaterialList::setMaterial. I'll post up something on this later, but I've expended my blog breath for today.

Cheers!

Devon.

Upgrading to TGEA - Twice

Devon Winter — 2008-06-20T19:19:23+00:00

Where we left off...
So I usually like to blog at the end of things.. so as to kind of recap my experiences along the way. Right now though, I'm smack in the middle. But I'm going on vacaction next week (Griswald Family Vacation to Walleyworld, woohoo!), and I'm piling up on the amount of things I want to write about, so I'm going forward with kicking something out today.

Last we left off, I had wasted -- err.. I mean, been doing research for the last three months digging through Truespace, Gamespace, and the torque art pipeline. I was trying to create an entirely new detailed character model and get her through the entire pipeline -- from sketch to animated model. In the end, I finally had to punt -- gamespace was just too finicky of a beast to accurately get animations out of, and I had to get back to doing real work -- writing systems. So for now, we'll continue to rely on stock assets and content packs. And I have a new appreciation for 3D artists.

SO, it was time to get back to work on Windstorm, my MMO Proof of Concept. And one of the first things I had already decided I wanted to do was to make the leap from TGE to TGEA. It was never for me a question of if I would make the leap, only a matter of when. For you see, I've made some fairly significant modifications to the engine, and everything I'd read was that TGEA was in and of itself a fairly major overhaul -- not to mention the entirely new material system, etc. So I knew the conversion was not going to be a trivial process. And brother? Let me just tell you I was not mistaken.

Rolling up our sleeves..
The first decision was whether to treat this like an upgrade to TGE, and do an integration in perforce, or to treat it as an entirely new project. Well it only took about 5 minutes of looking over the new directory structure to make that call. An entirely new project.

So the first tip I can offer for anyone out there who hasn't made the leap yet is just that -- don't think of it as an upgrade from TGE. Treat it as an entirely new product, that shares some common code with TGE. Yes, it actually is mostly common code, but the code has been moved around and reorganized so much that you'll drive any sort of merge/diff tool bonkers tryin to figure it all out.

The next thing to decide was on directory structure. My project differs slightly from the stock torque projects, but not too signficantly -- you can't differ too much or things just stop working. Too many relative path dependancies in TGE for you to stray too far. But having gone through the pain of previous integrations, I wanted to make sure I set things up in such a way tha future integrations would be as painless as possible. So here's what I did.

At the root sits Windstorm, the project subfolder. Below it, is TGE170_BASE subfolder, which mirrors the stock /Torque/TGEA_1_7_0 folder you get on installation. Now one thing I noticed is that in my ../Products/ subfolder I *didn't* have the template. This made me sad, but as my original project was based on the FPS starter kit, it would have to serve as my game directory baseline. So under /Windstorm/TGEA170_BASE/GameExamples, I removed all the examples save for Stronghold -- the renamed FPS starter kit. I then checked all that into perforce. Of course we're using revision control here bub.. we're professionals after all!

I then *branched* the TGE170_BASE subfolder in perforce, creating a new subfolder called TGE170_WORK at the same level. This is where all my modifications will go. But *now* we should have a baseline that represents the stock default installation of TGE, so that when future versions are released, we should be able to integrate them more easily.

So now my structure looks something like this...

Windstorm
     |
     -- TGE170_Base
               -- Engine
               -- GameExamples
                   -- Stronghold
               -- Products
     |
     -- TGE170_Work
               -- Engine
               -- GameExamples
                   -- Stronghold
               -- Products
                    -- WindstormGame
                        -- My game goes here

One thing I would have done differently is not incorporate the version numbers into the names. Duh. But it's done now, and there's no going back. But this is an important lesson to consider.

Once your structures and files are set up in the version control system of your choice, it becomes a royal pain in the ass to move directories and structures around, and plays hell with revision histories, so spend some time setting it up, and make sure you are happy with it.

So directory structures set up, everything mostly in place in Perforce, it was time to start working on the actual integration.

[-- insert two weeks of work carefully comparing differences to old TGE files and new TGEA files and my changes here, including trying to figure out where the hell everything had been moved to.. -- ]

heheh.. no, I'm not kidding. It's a lot of work, and most of it painfully tedious, and just stuff you have to be careful about. I took some notes as I went along, and found some things that were incredibly useful.

First, the porting notes included in the release are golden. You absolutely must read this document from beginning to end multiple times. Pay attention to it. All the stuff it says is true!!

Additionally, this resource this thread post by James Laker had a ton of great info in it.

And beyond that, I kept some of my own notes, so I'll add them here for posterity.

-- "core/realComp.h" has gone away.

-- "gui/controls/guiBitmapButtonCtrl.h" has moved to "gui/buttons/guiBitmapButtonCtrl.h"
- along with anything else derived from button.

-- "dgl/*" - anything in dgl has gone away. All of the draw utility functions are now in GFXDrawUtil, which you get to by calling GFX->getDrawUtil();

-- GameConnection::getControlObject now returns type GameBase, instead of ShapeBase.

-- The Canvas global has gone away. You'll now need create a local variable, and get the root of your control to get the canvas, the way it's done in editTSCtrl:

GuiCanvas *pCanvas = getRoot();
if (pCanvas)
	pCanvas->setCursor(pDefaultCursor);

-- gameconnectionmoves.cpp has been broken up and split over two classes. The definitions of Move and Movemanager have been moved to moveManager.*. There is now a moveList class, that encapsulates all of the previous old gameConnection::move* functions from before. This kids, is what we call componentization. Though I doubt that's how we spell it.

Not a lot, but maybe they'll help you.

Even after I got all the code converted, I still had a lot of work to do before I could get my avatar spawning in my game world in a satisfactory matter. Most of it had to do with mucking around with the assets and replacing old TGE versions of assets with bright shiny TGEA versions. I have some specific examples, but this blog is already running longish, so I'll save those for a future blog.

The Joke's On Me
The real beauty though, of this whole process, is that about halfway through the upgrade process, Matt Fairface and company released TGEA 1.7.1. :O

Now.. far be it from me to complain about rapid releases of much needed bug fixes and cleanup stuff. But you can imagine, after several weeks of integration work, my somewhat weary sigh as I saw this release. In fact, I decided briefly that I would just put off the TGEA 171 integration for some time to come, cause I really prefer a stable working version of my project before upgrading it.

But after the integration, even after fixing up the assets, lots of stuff in my game was still broken. None of my cursors were displaying anymore. After some investigation, I discovered this this was one of the things fixed int 171. My dedicated server was't working correctly. I was having connection issues. gfx draw utility fucntions were not working correctly... and each thing I found, turned out to be something it looked like was fixed in 171. See where this is going, right?

So, I decided it was pointless to try to spend a lot of time fixing the broken things in my game when clearly a lot of the broken things were broken in TGE170, and some other people had already spent a lot of time fixing them, and I just needed to take advantage of them.

So.. after we get back from Disneyworld, all tan and rested and out of money, I'll be tackling TGEA integration...

again. :)

Hope this was useful, or at least mildly entertaining. Until next time..

Devon out!

Truespace and Torque - Part II

Devon Winter — 2008-06-04T21:19:38+00:00

This is the second part of a 2 part blog detailing my experiences with Truespace and the Torque engine. If you're coming here first, you'll want to catch the exciting introduction here.

Truespace 7.5 - A Beast with Two Heads
So the first thing you should know about Truespace 7.51 is that it's basically two modeling packages jammed into one. See, when they made the shift to 7.0 from 6.6, they wanted to revamp the entire user interface. Introduce new animation techniques, basically create an entirely new modeller. But they wanted to keep their old fanbase as well, as well as to continue to provide compatibility with the plethora of plugins that add so much functionality to the package. So their answer was a package with two modes. The Model mode, and the Workspace Mode. in Model Mode, you're basically in old Truespace 6.6 mode, and you have all the modelling tools and animation stuff that you had in Truespace 6.6. And in Workspace mode, you're in the new modeling package, and you have an entirely new set of tools and animation capabilities on that side.

And then they created this gawd-awful hack they call the bridge to try to keep stuff you do in one mode in sync with the other mode. It's not very elegant, it's only a partial solution at best, and it has some pretty significant ramifications. The first of which is, if you're not familiar with Truespace at all, you basically have to learn two interfaces. The old Gamespace interface, and the new Workspace interface. And much, but not all, of the functionality is duplicated across the modes. So you can't just pick one side and learn it to the exclusion of the other. Well you could pick the model side and ignore the workspace side altogether, but then you're eschewing all the new capabilities of the program, which is the reason you bought the program in the first place. But you can't ignore the old model side and just use the new workspace side, for two very important reasons.

1.) Many things are still only available on the model side. Boolean CSG operations, for example, never got ported to the workspace side. So if you want to boolean add two solids together, you have to switch over to model side, figure out where that operation is, perform the operation, then switch back to Workspace side. Ugly. Nurbs modeling? Only on the Model side. I know, right?

2.) All of the plugins only work on the model side. Let me say that again. All of the plugins only work on the model side. This allows them to say that that they're compatible with all of the old plugins. They are, in a sense. But only in a limited sense.

This is especially true for animation. They built an entirely new animation system on the Workspace side, but they kept the old animation system on the Model side. And the two are not compatible. What does this mean exactly? It means this.

You cannot use Truespace 7.51's advanced animation system to create animations for Torque.

It doesn't mean you can't use Truespace 7.51 for creating animation for torque, it just means you're limited to doing all your animation on the Model side, which is to say you're limited to what Truespace 6.6 could do. Four years ago. Or however many years it was.

What about tomorrow?
So right now I'm using a four year old exporter plugin on the wrong side of the tracks in a package that I bought this year. Caligari has already said they're working on phasing out the Model side of the package altogether. In many ways, this would definitely be the best thing for the package, to get it back to being a single headed beast, and to reduce the mountains of confusion that erupt whenever anyone tries to use it and figure it out. But unless they provide some alternative source of plugin architecture, which they haven't said they are going to do, or build Torque .DTS/.DSQ funtionality directly into their package, which I would be very surprised if they did, when they do so Torque support will be dead in the water.

Which actually, is quite sad, because despite my comments here, I actually likeTruespace. On the Workspace side of things, the interface is pretty damn good. It's got features and capabiliities that compete against packages that cost ten times its price. From a price/performance comparison, it is an ideal package for the independant game developer. And it really does have those awesome animation capabilities to integrate physics forces into keyframed animation.

Collada Anyone?
One thing Truespace does do is export into the Collada format. I've heard rumors that Garage Games is looking at potentially importing the collada format directly into their game. This would be a HUGE boon if they did so. Lots of 3D packages are startin to export collada, and it's emerging (I think) as a true standard. If they did so, Truespace would not only return as a possible content developer for Torque, I believe it would be the ideal one. So PLUS ONE on the vote to read collada format animations and models directly into Torque.

Okay that's all for now. If you're looking at using Truespace for your Torque project, then I hope you found this useful. You *can* use it.. it does work.. sort of.. but not nearly in as nice a way as it should.

Cheers till next time..

Devon

Truespace and Torque - A Study in Four Year Old Technology

Devon Winter — 2008-06-04T20:19:21+00:00

Where have you been?

So it's been quite a while since my last post. (I wonder, offhand, how many blogs start that way, lol. I'd wager quite a few). But contrary to previous absences, I haven't been idling away my time playing this MMO or that one. Quite the contrary, in fact.

No, I've been working my ass off on Windstorm, my code name for the MMO Proof of Concept. See, after I got a working scenario, complete with quests, combat, and abilities, I decided it was time to take it to the next level. But for that, I was going to need some real live honest-to-god content, and most importantly, I needed to be able to generate animations for that content. That is -- I wanted to design and develop a new avatar (as well as townsfolk), and have their rigs in a modeling package, and be able to create new animations for them, if need be. The next level of content was going to require some custom animations, and I knew I wasn't going to be able to find stock stuff out of a content pack for this.

Only one problem. I'm not an artist. Not even a little bit. But no worries, I've never been afraid to tackle new information, and being a one-man show that's doing this in his spare time, I decided I'd learn to model. And texture. And animate. Can't be that hard, right? Yeah.

Why Truespace/Gamespace
So the first decision was which package to use. I spent a lot of time gathering as much information as I possibly could on the various packages -- all with an eye towards making sure they could get my content out in the .DTS/DSQ format. For Torque, once you look over all the options, there's pertty much four choices. First, Max/Maya, which I consider to be *one* choice -- they're both owned by the same company these days, and both fall into the "$3000.00 and up" price range. This places both of them out of the running for me. I just couldn't see spending that kind of money for what is essentially an experiment in one-man MMO shop. At the other end of the spectrum there's Blender, which is free. I downloaded Blender, and tried to use it. Just.. Oh.. mah.. gawd. I'm sure I'll get some hate from the Blender lovers out there but you'd be hard pressed to design a MORE esoteric and obtuse ass-backwards interface than what Blender has. Besides, I've never been a fan of open source technologies. No seriously. Anything put together by everyone means for the most part it's not exactly right for anyone. That old saw about "What's a camel" and all that. ("What's a camel? A camel is a horse put together by a committee..")

That left LightWave XSI and Truespace. XSI is around $800.00, which made it kind of pricey. Do-able, but still on the high end. Gamespace, on the other hand, could be had for less than $200.00. It had an exporter.. the Dark Industries DTS exporter, and there was even a pack that allowed you to create .MAP output, so you could theoretically create your level content in Gamespace as well, and then use MAPTODIF to convert that to .DIF format. So.. I'm thinking.. I *might* be able to only have to learn *one* crazy 3D program interface, and be able to make .DTS files, .DSQ files, *and* .DIF files. Wouldnt' that be sweet! What can I say.. I knew better, but I wanted to believe it would work.

So I bought Gamespace, and started going through tutorials. I installed the .DTS exporter from Dark Industries (which, mind you, was built over four years ago, and the company that built it has long gone the way of the dodo, so you're not going to get anything by way of support, near as I can tell, unless Matt Summers is still lurking around here. ;) ). The exporter is a bit of a beast to figure out, but I struggled through it, and was able to, using a tutorial, model a blaster, texture map it, and wrangle through the settings to get Gamespace to succesfully build the output file, complete with mount points. Here's the prerequisite screenshot for this post, of the gun I modeled in game. Woot!

About that same time, I read that Truespace 7.5 had some rather advanced animation features, including the ability to add physics impulses to an animation and then keyframe them. This would be perfect for things like recoil effects, knockbacks, death animations etc. And everything I could read on the plugins for Gamespace said they would work with Truespace 4.1 and above. Soo.. I could get Truespace 7.5, use their advanced animation feature set, and export them into the Torque game engine! So I upgraded to Truespace 7.5, for another $300.00.

Well some of what I had hoped for was true, but a lot of it wasn't. And that's what I'm here to share with you today. Because this is exactly the kind of information I needed to make my purchase decision six months ago, and if I had had this kind of information, I might have made a different decision. And it's not just about the purchase.. it's about architecture and the pipeline. You're committing a lot more than just money when you decide to go with a particular package. You're committing to months of learning, experimentation, and just large volumes of sheer work as you wrangle with your new tool set and you want to know, beyond any doubt, that at the end of the day you can get what you need out of the package.

So for those of you whom are still considering a modeling package, I'm sharing.

I'm going to put the next part in a second post though, because I don't want to go over the post length, and further more I need to get back to work before finish this beast, lol. Next part coming shortly..

Mission Complete!

Devon Winter — 2008-03-03T20:33:57+00:00

So it's been just over three months since my last post, but contrary to popular belief, and some would perhaps even say hope, I am not dead. And in fact, though most of November and December, and a good bit of January were spent generally goofing off and loafing, about mid january I returned to my mmo POC (proof of concept) in earnest.

Now, as you probably won't recall, I'll remind you that when I left off, I'd just finished getting a salvage/loot system in, and was in the process of tackling a mission (ie., quests) system. And, now.. I just gotta say..

Boy did I underestimate how much work it was going to be!

There's just, an extraordinary amount of work that had to be done!! Everything starting from defining objectives and prerequesites to figuring out how to handle circular datablock dependencies (more on that later!), to setting up the various pieces of data to the incredible amount of UI work that had to be done -- it just seemed like every time I finished one piece it made me realize I had three more pieces to write!

Now, last time I went into excruciating detail on exactly how the loot system worked. This time, I'm going to spare you the boring minutiae for two reasons. One --- it's a big system and to describe it in detail will take more time than I've got to update this blog.. and Two -- in the end, it's not really all that interesting.

What is interesting, is that I ended up with what I feel is a fairly complete WoW-like mission system. Oh sure it doesn't put an arrow on the hud or update the minimap (namely because I haven't implemented a minimap yet), but it does have all of the following functionality --

1.) Accept a misison, and be awarded items to provide assistance for the mission.

2.) Check back with the mission-giver, and get an "in-progress" text dialog.

3.) Full Mission Log, that keeps track of all your current missions, and displays status text on how you're progressing on any individual mission.

4.) Complete missions, and provides for both guaranteed rewards, and optional rewards, where "You may also select from one of the following.."

Additionally, NPC's have text that's updated on a per-client basis that reflects if they have mission for you, if you're currently in progress on a mission for them, and if you're ready to turn a mission into them. These are the equivalent of the ubiquitous exclamation point and question marks that appear over any NPC in any self-respecting MMO these days. In fact I was originally going to do the question marks and exclamation points, (and probably still will, eventually), but didn't want to take time off to model them up, and fiddle with exporting them and getting them attached to bones, when some simple text would suffice for my POC. After all, the hard part here was making sure the right information regarding a client's (player's) relationship to the NPC was replicated down to the client!

I'm also very excited because the completion of this task marks a pretty major milestone for the POC. I now have basically a full slice-of-gameplay from beginning to end. To that effect, I have created a zone and some content that I have imaginately called the "Mini-Mission". The intention was for you to be able to get into the zone.. get some missions.. kill some monsters and loot them.. get some cool gear and weapons and equip them, and complete the missions. And that, my friends, is exactly what you can do.

So, without further ado, here are some fun screenshots from the Mini Mission. I put them in a slideshow over at photobucket, and you can view them at the link below:

Mini-Mission Slideshow

Slideshow Caveats - The stupid slideshow in photobucket is way too fast. But there's no control to slow it down. If you hover over the slideshow it will bring up the play/pause controls, and you can pause it as it runs. Click on any panel to view an individual screenshot, then click "Full Size" if you actually want to read some of the Mission Text in those screenshots.

Next time I want to talk about data. Fun, right? But it's a problem every developer has had to tackle -- how to get your game data into the game. I've implemented a solution, and Torque does a wonderful job of supporting static data concepts through datablock classes, and so I figured I'd talk about my solution. I'm interested to hear from other developers what they're doing, if they want to share, and what they think about the solution I'm using. But that's for NEXT time!

till then, Enjoy!

Fixing the Zombie Shuffle

Devon Winter — 2007-11-15T20:29:45+00:00

So I haven't gotten any real work done in the past few weeks (stupid Hellgate!), and I'm headed out of town for the holidays for another week or so, so I thought I might assuage my guilt by posting up a bug fix I discovered a few months ago. This one cost me a weekend. I looked around the torque forums and resources, but didn't find anyone else that had posted a fix for this, so I thought I'd share. Hope it's useful!

Let's do it all official like.

Bug
At slow speeds, the move animations break for AI characters. That is, below a certain threshold, they no longer play their animations smoothly, and instead start to stutter and slide.

Repro
Starting with a stock TGE 1.5.2 install, load up the starter.fps module. Load Stronghold, and run over to where Kork is racing around his little circuit. Watch his animation. Notice it's playing quite nicely.

Load up example\starter.fps\server\scripts\player.cs, scroll down to the player datablock, and reduce the player's default run speed to 1.24 (approximate walking speed):

   runForce = 48 * 90;
   runEnergyDrain = 0;
   minRunEnergy = 0;
   //maxForwardSpeed = 14;
   //maxBackwardSpeed = 13
   //maxSideSpeed = 13;

   maxForwardSpeed = 1.24;
   maxBackwardSpeed = 1.24;
   maxSideSpeed = 1.24;

Load starter.fps, and "run" over to watch Kork. Now, you'll notice that you are also moving at an ungodly slow pace. But just be patient, move on over to where you can see Kork, and watch him. Notice how his animations are stopping and stuttering, and sliding. This is even more noticeable on a "real" client, but should be plenty visible on the standalone version too. Notice however, that the animations for your player still seem to be fine. They are scaled down to slow (as they should be), but play smoothly throughout their entire cycle. If you add another player to the mix, and observe him, you'll see that his animations play fine too. It's only animations for AI players that are broken.

The Fix
Edit - So thanks to some diligence on behalf of some of the other community members, we got down to what we think is the real culprit here. While my original fix does in fact fix the problem, and doesn't (to my knowledge) break anything, it's not really fixing the bug.

Here's the right fix. Bring up aiPlayer.cc, and find the getAIMove function. At the very bottom, before you return, add the following statement:

   .
   .
   // Add the following statement
   // Clamp the move for network traffic..
   movePtr->clamp();

   return true;
}

The original "fix" I leave here strictly for posterity's sake, but it is not necessary, and in fact if you've made this change I'd recommend rolling it back. I try to muck with the engine no more than absolutely necessary.

No you don't have to wade through my blog to get to the good stuff. Here's what I did to fix it. Load up player.cc, and move down to the processTick function. Find the part where they are about to perform the physics updates. Change the conditional as follows:

PROFILE_START(Player_PhysicsSection);
//if(isServerObject() || (didRenderLastRender() || getControllingClient()))
if(isServerObject() /*|| (didRenderLastRender() */ || getControllingClient())
{
updateWorkingCollisionSet();

updateState();
updateMove(move);
updateLookAnimation();
updateDeathOffsets();
updatePos();
}
PROFILE_END();

Basically, remove "didRenderLastRender" form the conditional. Compile this, run (in slow motion) back over to Kork, and watch him. Hey!! Whatdya know! If everything went well, he should be playing his entire animation sequence, if ever so slow. Enjoy!

What's Going On Here??
Okay so this is where it gets good, imho. Here I get into the down and dirty of what I figured out over almost an entire weekend of debugging. From this point forward, we're getting down into the trenches.

So I stumbled across this bug while implementing walking for my mutants on patrol. I had a walk animation, set up a "mWalking" state on aiPlayer, and get all that working correctly. But I noticed that while walking, the mutants would start stuttering and sliding. Spent way to long just verifying that I hadn't screwed things up in implementing my walking stuff before it occured to me to check for this bug in stock 1.5.2. Live and learn!

Started with watching the animation. Closely. It appeared the sequence was getting reset prematurely, or gettin stuck on a certain frame. Debugging animation problems can be tricky, cause you can't *just* use breakpoints. The bugs occur over time, so you have to use lots of logging, and observe values over time.

player::updateAnimation seemed liked a good place to start. If you put a breakpoint here, you quickly figure out there are four players being updated -- the player on the server, the player on the client, the aiPlayer on the server, and the aiPlayer on the client. Here are their ID's. All things being equal, they are probably the same ID's for you.

1681 - aiPlayer on Server
1811 - Player on server
1812 - Player on client
1816 - aiPlayer on client

I had to do some tom jiggery with making some members of tsThread public so I could access them while logging, but hey it was all in the name of science. I added a log statement in updateAnimation to see how the aiPlayer on the client's animation was progressing. Here's what I saw..

For Unit ID: 1816.. animPos == 0.289882
For Unit ID: 1816.. animPos == 0.398241
For Unit ID: 1816.. animPos == 0.432000
For Unit ID: 1816.. animPos == 0.864000
For Unit ID: 1816.. animPos == 0.239268
For Unit ID: 1816.. animPos == 0.316829
For Unit ID: 1816.. animPos == 0.098171		BOOM! Reset!
For Unit ID: 1816.. animPos == 0.098171
For Unit ID: 1816.. animPos == 0.198194
For Unit ID: 1816.. animPos == 0.296234
For Unit ID: 1816.. animPos == 0.424000

Hot damn! Sure enough, it would progress through the cycle, then periodically just reset back to zero. WTF! So.. more code digging.. more log statements, and I figured out that animations will get reset if you change the current action animation. So I popped up to player::updateActionThread, which is responsible for determining which action animation to use, at any given time. Another log statement where we call pickActionAnimation revealed the following:

for unit 1816, current action animation is: 1
for unit 1816, current action animation is: 1
for unit 1816, current action animation is: 0
for unit 1816, current action animation is: 1
for unit 1816, current action animation is: 0
for unit 1816, current action animation is: 1
keyboard0 input device unacquired.
for unit 1816, current action animation is: 0
for unit 1816, current action animation is: 0
for unit 1816, current action animation is: 1
for unit 1816, current action animation is: 0
for unit 1816, current action animation is: 0
for unit 1816, current action animation is: 1
for unit 1816, current action animation is: 1
for unit 1816, current action animation is: 0
for unit 1816, current action animation is: 1
for unit 1816, current action animation is: 1
for unit 1816, current action animation is: 1
for unit 1816, current action animation is: 1
for unit 1816, current action animation is: 1

Holy crap! My animation's bouncing between root and run all over the place! Was it getting fucked up on the server? I changed the log statement and watched..

for unit 1681, current action animation is: 1
for unit 1681, current action animation is: 1
for unit 1681, current action animation is: 1
for unit 1681, current action animation is: 1
for unit 1681, current action animation is: 1
for unit 1681, current action animation is: 1

Nope! The server was keeping the animation exactly what it was supposed to be, but for some reason it was getting fubared on the client.

So. Who changes the animation? Well, player::pickActionAnimation does, and it does so based on your current world velocity. Now.. our velocity is set in aiPlayer, and is a constant.. so it shouldn't be fluctuating at all in magnitude -- only in direction, and only then when we turn. More logging down in the heart of pickActionAnimation..

for player 1816, translated vel is: (0.054765, 1.212516, -0.110260)
for player 1816, translated vel is: (0.054765, 1.212516, -0.110260)
for player 1816, translated vel is: (0.054765, 1.212516, -0.110260)
for player 1816, translated vel is: (0.000000, 0.000000, 0.000000)
for player 1816, translated vel is: (0.000000, 0.000000, 0.000000)
for player 1816, translated vel is: (0.054765, 1.212516, -0.110260)
for player 1816, translated vel is: (0.054765, 1.212516, -0.110260)

Boggle! See that? Right smack in the middle velocity's gettin zeroed out! So.. moving up the chain now.. we're getting close I can smell it. Turns out, velocity is calculated in player updateMove. updateMove is called in player::processTick. Now.. processTick is called both on the server and the client, and in both cases, for an aiPlayer object, it is called by the following piece of code at the bottom of gameProccess::advanceObjects..

      if (obj->mProcessTick)
         obj->processTick(0);

This means, in all cases, on server and client, aiPlayer's processTick function is called with a null move object. On the server though, this is okay. This is exactly what we want, in fact, as its a marker to tell the aiPlayer to get his move!

   Move aiMove;
   if (!move && isServerObject() && getAIMove(&aiMove))
      move = &aiMove;

So every update the aiPlayer calculates a valid move structure, and that gets used down at the bottom of processTick when we updateMove. But on the client.. ho ho! The client.. our move structure is never updated. Soo.. at the bottom of the processTick, when we updateMove, we do so with an invalid move structure every time! So updateMove with a move of ZERO causes us to degrade our velocity. Mind you.. we dont just stop.. cause our new velocity is zero, but this is applied against our current velocity using acceleration, so we just slow down slightly. Guess what! We slow down enough to cause the pickActionAnimtion function to switch from running anim to root!

But.. every time we get a new update from the server, which is quite often, the server replicates the RIGHT velocity down to us for the aiPlayer, so it gets set back up. So.. the server is blasting us the aiPlayer's velocity.. but in between updates, we're slowing down because we're recalculating our move using an invalid move structure. I know right??

So.. down below, in processTick.. the only reason that the aiPlayer is calling updateMove with an invalid move structure is that we have this check for "didRenderLastRender" in there, which allows all the functionality to be called for aiPlayers, which are really not real clients at all. So I removed that check, and now aiPlayers clientside get their movement only from replication and everything seems to be much happier.

Why doesn't this happen for other player's I see?
Because players on the client side actually have valid move structures calculated for them. So you're not constantly using an invalid structure, which degrades the velocity.

Why doesn't this happen all the time?
Because at higher speeds, the velocity degradation between movement updates isn't enough to cause the animation to switch. The degradation is still going on, but you never reset the animation, and your velocity gets reset every time the server sends an update.

Um.. don't you think that 'didRenderLastRender' check was there for a reason?
Yes. I do. Absolutely. Honestly though, I can't figure out why. This is the only place in the engine this function call is used, and if you look at it, it basically is checking to see if this update is an update we rendered in -- cause obviously render frequency and update frequency are not linked. So.. I'm guessing it was an attempt to make sure we only updated physics on the client immediately after we performed a render, to get tighter coupling between the sim and the display, but honestly that is only speculation. Near as I can tell, there's *no* reason to call those update functions if you're not either the server or the controlling client for this player. I can say I've had this fix in for about 3 months now, running regularely, and I haven't seen anything broken because of it yet. Perhaps a GG programmer might shed some light. But as always with any bug fix -- Caveat Emptor.

Okay.. that's all I got. Hope this helps, and have a safe holiday. See you later after I come down from the triptophan high!

Dev out!

Hellgate crits production for 1300 hp's. Production dies.

Devon Winter — 2007-11-10T02:36:45+00:00

So this past week I was supposed to be starting work on the quest system. Unfortunately, Hellgate:London actually got released on the 31st, and I've pretty much spent every free minute I was supposed to be working on the prototype playing Hellgate.

This is not all that uncommon. I play a LOT of MMO's, and it has been a common pattern throughout the lifetime of this product that I'll get pulled away for a month or so from time to time when the next bright and shiny MMO comes along. Now granted, it's debatable whether or not this game even is an MMO, but it's close enough, and has enough MMO-ish qualities to merit some observance. It's also a helluva lot of fun.

In fact, it's probably the most broken, bug-ridden, poorly designed, and yet incredibly fun game I've played in a long time. And that's what I want to talk about for just a bit.

Hellgate is absolutely terrible for indie developers. The reason it's terrible for Indie developer is that it serves as an incredibly bad example. No seriously. One of the things we constantly fight as low budget but impassioned developers is trying to produce a game that doesn't LOOK like it was built by one guy working in his game room part time. And here comes a product developed by a supposedly reputable developer. Financed by EA. Darling of E3 for three years running, and designed by the guys that built friggen Diablo!

And yet when it launches, their subscription service is MIA. It has massive crashes to desktop, memory leaks, poorly designed UI's, networking issues, graphical glitches, and huge performance problems on a variety of platforms. But they launch it anyway. And it sells. And worse, it's fun!

And as a consumer, I pay for this game, I play it, and I curse all its brokenness while really having fun in the core gameplay. And as a developer, a little voice whispers in the back of my head that THIS developer.. this publisher, well they released this bug-riddled mess but it's still fun, people are still buying it, and well.. maybe.. maybe it's okay if you let some of those little things go and just get it pushed out the door.

Don't listen to that voice. Don't do it.

That's the thing I have to tell myself. That's the thing I hope you say to yourself. Because it's a very easy temptation to listen to. There are so many pieces of polish and systems and pieces of things to fix up that it's easy to say "hey we got the core gameplay working, so what if the chat window lays completely over your user interface, or half the time you enter an instance with your group you can't see your own group members!

But mark my words, ultimately, that kind of shit is the stuff that's going to kill this game. Yeah, it's fun. But it's not solid. And people buy the game and play it and they're assaulted by the bugs and they will leave this game before they ever get to the part that's fun. Make no mistake, I give this game a lifespan of a year at the most.

So as I go forward with my quest system, I'm going to strive to keep Hellgate in the forefront of my mind. And I'll compare it to games like WoW and Guild Wars and games that are incredibly polished, and made damn sure I cross all my t's and dot my i's before I start showing it off.

Of course, I'm still going to finish the game. :P I'm more forgiving than most..

Until next week, Devon out.

Teh Ph4t L3wtz

Devon Winter — 2007-10-30T14:20:26+00:00

So when last we left off, our hero could finally loot the corpses of her hard-earned kills. I figured this week I'd spend some time talking about that system. Like any system, in concept it sounds really simple. In practice of course, the implementation is anything but. So here we go.

What this isn't
Sadly, this is not a turnkey drop-in loot resource, complete with code. The reason for this is not out of any lack of desire to share, but only that my limited time doesn't allow for me to go through and remove all the dependencies this system has on the systems I've already built. With over a year's worth of work already in place in my engine, to make this a stand alone resource I'd have to either stub out or provide all the underlying systems, and I just don't have the time to go through and fix up those dependencies.

What I will do though is go through the entire system at a high level, talk a bit about what I put where and why I put it there, and hopefully if you're doing something similar, you might find some kernel of usefulness buried within. Or perhaps just an entertaining read of a mildly delusional programmer. :P

The Parameters
So what I'm shooting for is a first pass implementaion of WoW's looting system (and LOTRO's.. and EQ2'S.. etc). That is, objects don't drop on the ground ala GW or Diablo. You kill a corpse, and it gets a sparkly saying you should loot it. You loot it, and it gives you some money, and displays a window with the other things on the corpse. You take those things by clicking on them, and for fun I added a "Take All" button, so clicking on that will give you everything in the panel at once. As I don't have the notion of groups yet, then I wasn't going to mess around with any group looting rules. Everything is free for all, and it's first come first serve. In fact, you can even loot something while someone else is looking at the loot panel. Obviously, this isn't final design, but it was enough for my purposes.

Setting up the data
So the thing I realized I needed was a loot table. This determines who has what loot, and the chances of them dropping it. Now I've already built a tool that allows me to take excel spreadsheet data, save it in a comma delimited format, and generate .cs files that contain datablock definitions for the data defined in the spreadsheet. Not the most elegant way of setting up data in the game, but at the time I hadn't bothered to code up an XML parser, so this was more expedient. Turns out it works pretty well. Here's the structure definition for the loot table record:

   struct lootentry
   {
      F32            rate;
      GameBaseData   *item;
   };
   typedef struct lootentry LootEntryType;

   S8                   baseCredit;
   S8                   creditSpread;
   LootEntryType        lootEntries[cMaxLootEntries];

Now my game's set in the future, and as we all know, money in the future looses all demonination and just because credits. baseCredit and creditSpread work together to determine how much money to randomly drop. Basically you'll get baseCredit +/- some random amount between 0 and creditSpread/2. A loot entry defines a drop rate (from 0 to 1), and a pointer to our item definition for the thing to drop. This is a very simple drop system, and I wrote up some notes for a much more complicated system, and then saved it for future reference. Again, K.I.S.S. I created some examples of these for the two mobs I currently have in the game, and the player datablock gets a pointer to one of these records as a the "Loot" member.

I wasn't done with data yet, as I still needed a bit more. We know knew where to go to figure out what loot to put on the player, but the generated loot needs to be stored somewhere. I created two new members to go on the player structure (not the player datablock). The first is a simple bool -- isLootable. Basically, this gets set to true when a mob has died and loot has been generated for him, and is true as long as loot remains on him. The moment all loot is removed from him, this gets set to false. Second, a new record called "generatedLoot" was added. This holds what you think it would, namely being the amount of money generated, and an array of item references. It could hold quantities as well, for each of those items, but I decided that each item in the loot table would only ever generate one of those items. That's the beauty of being both designer and programmer, I can make those kinds of decisions. :) Both of these pieces of data (the isLootable flag and the generatedLoot structure) are tied to a "lootModified" flag on the player, and replicated to the clients by way of the pack/unpack update routines.

The Process
So how does it work? Well something like this. If at any point a player becomes disabled, (ie., dead), we check their loot table pointer to see if it 's non null. If it is, then we call a generateLoot function that looks up the loot table entry, rolls the dice, and stuffs the generated money and items, if present, into the generatedLoot structure. The isLootable flag is set to true, and the "lootModified" flag set so these updates get replicated to the clients.

At this point, I had to go off and create a sparkly particle effect. Ugh. Art. I suck so much at art. Still, after some wrangling I got something that didn't make me want to cringe. SO.. more data added to the player datablock -- a pointer to the sparkly particle effect. I stuffed it in there right between footpuffs and splash effects.

So.. back to process. On the client, in advanceTime, I now update loot particles. If the "isLootable" flag is set (having been replicated to us from the server), and we do not have a particle system up yet, AND we are not playing an animation (cause see.. I don't want the sparkly to show up until I've finished the death anim), then we generate the loot emitter, register it, and start it. If the loot emitter's already generated, we just emit some particles. And if the flag is not set, but the emitter is still running, we schedule it for termination. Wee!

The player sees the loot sparkly, jumps for joy, and runs up to r-click on the corpse. When they do, I send the command up to the server that says "work on this right here" with the mouse coords. I haven't yet made the enhancements suggested in last week's blog, but I almost certainly will. For now though it still sends the work command with the mouse coords. The server says "hey.. corpse here.. lootable?" If so, then it generates a notification message to all interested clients that client Jimmy is looting the mob. It also takes this opportunity to decrease the generated loot by the amount of money on the mob, and increase the player's money (oh yeah, I forgot, each player has a new S32 for their current credit amount) by said amount. Note -- even though I send the amount of money taken along with the notification, the amount is transmitted only for the purpose of displaying the chat message. The client should *not* update it's own money amount, because the server already did that, and the updated money amount will be sent via replication. Finally, I also tell the specific client that requested the loot to play his loot animation.

So on the client, I get the begin_loot notification, and if it was my client, I display the loot panel and chat the "Player jimmy has looted some money" message. If it wasn't my client that's 'begin_looted'ed, I just chat the message, so everyone knows how much money you got off that corpse!

Brief pause here as I go code up the UI panel for displaying loot. See note above about previously generated systems. This wasn't hard because it was almost identical in function and form to the inventory panel I had already created. Back to the action..

So now my loot panel is displayed, and it was informed about which mob it was displaying loot for. Any time the generatedLoot is modified, in unpackUpdate, I refresh any panels that are open. So this means that even if I'm looking at a panel, and someone else takes something from the mob, the panel will reflect that information. Sweet huh? When the user clicks on an item in the panel, the panel generates a command to the server to "Take Item Blah from Mob Blahblah". The server verifies the item still exists, and if so, it removes the item from the mob's generatedLoot structure, and grants the player a single instance of said item. This goes through the player's already written "grantItem" routine, so items are auto-stacked inside their inventory (another previously written system). Again, a notification is sent to all clients of the item taken, purely for chat purposes. The updating of the panel and the player's inventory is left up to the server's replication. If at any time when the server moves the last item out of generatedLoot, and there's no money left, the "isLootable" flag is set to off. Clientside, when I refreh UI panels, if at any time the isLootable flag changes, if it's set to off I close the loot UI panel. So when the last item is taken the panel closes automagically.

Finally, I added a "take all" button, which generates a separate command to the server, and the server just iterates through all the generatedLoot on the mob, sending out notifications for each item taken.

Okay! That's pretty much it. A long read, yes, but that's pretty much top to bottom. I promised some pictures, or something, so here's a poor quality video of the looting in action. Sorry for the poor quality, I didn't realize photobucket would recompress what I had already compressed! I promise future videos to be in better quality.

Simple Loot Demo

Rambling thoughts on InstantAction, Torque 2, and Component Architecture

Devon Winter — 2007-10-25T14:17:50+00:00

So I know I said I was going to talk some about loot, but I just finished spending several hours getting caught up on whats going on with GG these days, and their initiative with InstantAction, as well as some of the other things they're working on. And because it's the internet, and this is a blog, and out here everyone gets an opinion whether they should or not, I thought I'd throw in my two cents worth. I have absolutely zero interest in joining the circus on the forums, though I did find it amusing that a discussion that started about whether GG's current direction is a good one or not has devolved into bickering about whether or not Marble Blast constitutes a casual game.

I also commend Stephen Zepp for moderating with a great amount of civility and restraint a forum at which people who have made a career out of being forum trolls have come to roost. You couldn't pay me enough. So good on ye.

But what about GG? What about InstantAction? What about Torque? Well, a few things there.

First, the casual games market right now is absolutely exploding. Anyone can tell you that. And hand in foot with that are web based games and communities. I mean just look around. Disney recently bought Club Penguin for $350 million dollars. The fastest growing segment of the Xbox Live is the XBLA side of it. Games like Puzzle Quest are redefining how we look at casual games. Now if you had a company that had as its assets a rich collection of tools for enabling people to cater to that market -- wouldn't you? I mean seriously. And if you could form a partnership to create a platform upon which for people to play those games, and at the same time extend the types of games that people could play on that platform, wouldn't you do so? I sure as hell know I would. So yeah GG may have been founded with the idea of using the tribes engine, doctoring it up, and selling it to independant game developers as a leg-up tool, but industries change. Technology changes. And as a company if you don't evolve for your marketplace you won't survive. GG is just doing that.

Here's something else. People are going on and on about what casual games are and are not. What I don't think most people realize is that what defines "casual" has absolutely nothing to do with the kind of game it is. Well I mean it does for some people, but they're missing the point. Casual game are games that can be played casually. That means two things. (1) Short time frame., and (2) No barriers to play. The second is crucial, so I'll say it again. No barriers to play. Look if you want to play a PC game you have to go buy the game and bring it home and install it on your PC. That's a huge amount of work. Even if you want to play a console game, you have decide which console, go buy the console, then buy games for it, and only then do you get to play them. But as far back as ten years ago eight million people a day were playing games like tetris and bejeweled on AoL because it was right there! They didn't have to go anywhere or buy anything the game was just right fucking there and they played for 20 minutes before they had to go pick up the kids from school. That is casual!

The only reason I emphasize this point is because I think it's why GG has a chance.. a *chance* at success with this. If they bring games that us old timer hard core types think of as real games and reduce the barriers to playing those games -- make them easy as hell to play because they're right fucking there in my web browser, then they could be sitting on a gold mine.

But they have to hurry. Cause they're not the only ones that have realized that reducing barriers to play is the next explosion in gaming. Nintendo.. Steam.. XBLA.. everyone is lining up to figure out how to make games more approachable and easier to get to than ever before.

Now for the most part, I personally haven't been all that excited about GG's direction towards the casual gaming market. Because despite what I said up there, I, like everyone else, have a pretty clear concept of the kind of game you're talking about when you say casual game. And when I look at technologies like TGB and Torque X and the XNA initiative, I see those technologies being used to produce one type of game, and quite frankly those are not games I want to make. I know. It's stupid and stubborn. But I don't want to make Marble Blast Ultra or Zumo Extreme or Luxor's Revenge. I want to fucking make WoW. Those are the games I play and for as long as I can remember I've had the dream of creating a world of my own and inviting people to come and play in it. And recent success in that genre have embolded every other mother's son to do the same, so that these days you can't swing a dead cat on the GG forums without hitting an MMO developer. I find none of that deterring.

But you know.. GG has said they want to make a "console platform" for the web. I think that's an awesome way to think of it. The thing is, one of the major failures of the classic xbox was that they launched with no decent RPG's. None. And the same was true for the 360. Now since then games like Fable and Oblivion have come along and helped to address that some, but it wasn't that way at the start. So maybe what IA really needs to succeed is a decent RPG for people to play! Are you listening GG? :P Maybe in a year or two when the "platform" has stabilized a bit and shows some signs of legs, perhaps that will be exactly what they need. Just sayin..

Okay I've ranted a bit, but before I go I want to talk a bit about Torque 2. From what I've read, they're pretty much throwing out TGE(A) and starting over with a whole new engine, taking what they've learned from the last six years of working with the first engine. They're also doing what everyone else in the industry is doing right now and moving away from a heirarchical architecture, and moving towards a more componetized one. I think all this is smart, and it reaffirms my hope that they're not abandoning the "game engine" side of their business. What they haven't said yet, is whether or not the engine will be a general purpose engine, for building PC games as we currently know them, or whether they're working specifically to build an engine that caters to the web-based platform they're also building. You know? I think they haven't said anything about this yet because they're still trying to decide for themselves.

I sincerly hope its the former and not the latter. I've worked with a lot of game engines. When I picked up the Torque engine, I had very low expectations. I was getting something that I could afford to mess around with on the side -- something to build a proof of concept with. I didn't for a minute consider that I could use Torque for the real thing. I'm pleased to say that Torque has exceeded my expectations in just about every way. Yeah it's got kinks and hacks and bugs galore. Guess what. So does every other licensed engine on the market. But it serves as an excellent foundation for building your game, and the more I used it, especially since seeing the graphics and terrain overhaul in TGEA, the more I came to believe that this thing could actually be used for the real thing.

I hope that's what Torque 2 is. I hope they're committed to their statement about building the real thing. I know I would pay ten times what I payed for TGEA if I could get an engine that works to the same level of quality as Torque 1 has, but is capable of producing the kind of visual appearance that a game produced in 2009 or 2010 is going to have to have.

Finally, this is for any of the programmers at GG that might happen to have been bored enough to get to the bottom of this. I absolutely agree that creating a component based architecture is the way to go, and at where I work we recently just did the same thing with our engine. But I would advise caution against componetizing everything. The hierarchy still has it's place in some components. And there is still something to be said about being able to access things when you need it.

If at the end of the day all your physics shit is over in this compoenent and all your health information is over in that component and your damage capabilities are in a different component and you find yourself spending all your time traversing component trees to get to the data you need and wishing for the days when gawddammit it was just all in fucking player.cc ftlog, well then.. you've probably componetized too far. :) Good luck to you guys. Looking forward to seeing the fruits of that labor.

Next time, back to talking about my journeys in making game systems, and teh ph4ts l3wtz.