Blog for Phil Carlisle at GarageGames.com

The importance of good tools for productivity

Phil Carlisle — 2007-12-05T23:26:45+00:00

I was at a presentation a couple of months back about a product one of the thegamecreators.com had been working on. One thing he said was that whenever he starts a project, he immediately thinks of the tools he needs to make it easier.

That got me thinking this last month as I've been scripting missions for Panzer Ace.

The fact is, I think mission "scripting" would be better done in another way. Particularly as the missions we are doing for PA are actually more like a mixture of mission logic and camera/machinema work.

Then I remembered that I was going to write some machinema stuff in 2002 :) so I figure now is actually the time to revisit that idea and turn the absurdly horrid script code (I mean it really is pretty nasty writing a ton of script logic to setup in game cutscenes as it is) into a more manageable set of UI tools.

We already have a lot of the code you'd need (event based systems, triggers, spawners and I've just been doing additional camera control work). So it should be reasonbly easy to get a first-pass system in place to get the core game stuff done.

I'm going to design it over the weekend, but something along the lines of a timeline based system a bit akin to a much-simler version of director's cast/timeline system seems like the way to go. Basically, have multiple timelines which represent a given "take" of action. Each take is either a cutscene or a gameplay section. Add events into the take based on what you want. Add layers to this so that you can have multiple ways of transitioning between takes etc.

I'll draw a diagram over the weekend. But here's a simple example to get us started.

Right now, in one of my test missions, after doing the intro cutscene (driving a tank over a russian plain) you have to fight a few scripted enemies. Now the thing that struck me, is that if I want to actually cut short the cutscene, I post an event to the manager and it goes onto the next "scene". But what I'd prefer to do, is have a sort of timeline, where I could add a layer to it (photoshop style) and right-click "add event->escapetransition" and give it the take to transition to.

Similar with camera cuts. Right now we've got a great big bunch of if(event) changecamera(cameraname) scripts. What I'd rather do, is right-click the camera track and "add->event->cameraswitch" into the timeline at the appropriate points.

Given how much crap I've had to mess around with for a single mission. I feel like getting even a rudimentary version of this together is going to make my life 1000% easier to get my missions done.

So expect some design stuff about this over the weekend. I prefer to use mindomo.com to flesh out my ideas and then usually build some kind of class collab diagram. But I might just mockup something in photoshop this time round :)

Sorry, rambling, but wanted to get this down on paper so I dont forget the frustration of mission scripting :) visual mission design for the win!!!

Using the way back machine.

Phil Carlisle — 2007-11-17T09:13:32+00:00

Here's a fun exercise for those of you who like to blog here on GG.

Go to your account page, then browse the resources you've posted. Most of them will likely be blogs. It's like a very weird sort of way-back machine!

My first post was in March of 2001, here tis:

www.garagegames.com/blogs/1605/668

It's like a personal timeline for me (I'm a bit of a talker as anyone who knows me will attest) because I've kept on blogging here at GG for a while. Throughout that time I've finished my job at Team17 (twice), been to america umpteen times. Been round the world. Started about a dozen projects. Scrapped the same number. Had about half a dozen colds and infections. Been frustrated by artists. Moved house about a dozen times. Published 3 book articles. Written about 100 posts on AI. Whinged, whined and moaned about almost everything. Shipped a couple of commercial games. Lamented the lack of decent artists about 1000 times. Pledged to fix the torque asset pipeline a few times.

Through all of these posts, you know something that struck me. I'm STILL as enthusiastic about games now, as I was then. Isn't that strange?

So in order to not make this a long rambling post, I just want to finish up and say *THANK YOU* to all the people who've been part of this journey with me so far. I've met some really amazing people through GG and it is sometimes difficult to reflect that its often the value of the journey that matters, not the value of the destination.

Hugs.

Juggling cats.

Phil Carlisle — 2007-09-21T17:11:52+00:00

Balls

To me, part time indie development always feels like juggling. Trying to juggle work commitments with your indie life can be a very difficult thing.

Almost like juggling cats.

Anyway, I wanted to post about how things have gone since last year, just so I have some retrospective next year to think about.

Around this time last year, we were working on Air Ace, our multiplayer dogfighting game. It was starting to look good, but we had a big issue with networking the flight physics.

Air Ace Screenshot (large)

To cut a long story short, after some deliberation, we realized that we couldnt ship Air Ace without the physics being fixed and we couldnt find anyone capable of fixing it. I know that many of you would have
probably fudged something together, we did consider that, but truthfully I had a very specific feel in mind for the game and without at least some semblance of the flight model I wanted, I dont think I'd have liked the game. I'm not about to make a game I dont like playing myself.

So, we took the decision to shelve the game until such time as we found someone to work on the physics again.

Our next plan of action, was to take the multiplayer aspects of Air Ace (team based combat, various game modes etc) and move it into a new game. This was to be a NON physics based game (lesson learnt there).
So we chose to use tanks, as they are very combat oriented, have less issues compared to humans when it comes to content and generally we like em!

And thus, Panzer Ace was born!

We did some initial work, getting a few tanks from 3drt, getting them rigged. Adding in all the Air Ace code. One decision we made, was that given we didnt need the vast horizon distance that we did in Air Ace,
we would use TGE instead of TGEA, in order to work with the more stable codebase and reduce our system requirements.

So we set about building Panzer Ace. Here I want to talk you through a few of the interesting problems we've come across in its development.

We started Panzer Ace by taking a load of the code we'd created for Air Ace, backend systems, scripting, plane choice etc. Ported it across to TGE and stuck it in. This saved us many months of work and seemed to go pretty well. However it later caused us some issues, which I'll go into at the end of this post.

Because we had to change to Tanks, our starting point for the new game would be to take the tank pack and essentially replace plane* with tank* in the game. Anywhere you'd have selected a plane, you now
selected a tank. Simple really.

Only, well, there are issues with the tank pack as it is now. Its still a great starting resource, but using it for a scalable multiplayer game is not really a good idea. Let me explain some of the problems we encountered.

* Treadmarks - This was a feature of the tank pack. It produced pretty nice looking treadmarks on the terrain as you drove it around. Unfortunately, the way this was implemented wasnt really suitable for
a multiplayer game, as it constantly emitted new decal objects. Essentially we'd see the object count in the game spiral as we added more players into the game. The result was that we had to ditch the treadmarks, although we do have a solution to implement further down the road (using a ribbon of quads).

* Control system - This wasnt really an issue with the tank pack so much as our own desire to have a system that felt "nice". I know this kind of thing is pretty subjective, but I think a big part of being a
designer/developer is that you have to take responsibility for how things "feel". I didnt like how the tank pack felt to control. The plan was to try out a scheme I knew I liked from playing Call of Duty. In that game, you control tanks using keyboard and mouse, but the mouse is essentially a free look (spun around the turret at its axis) and the turret turns to follow where the mouse cursor lands. After some playing around, I got this system working reasonbly well. It still has a few bugs but I didnt really worry about those once I felt the system worked.

Strangely enough, the control system led me to another issue. That of targetting, or rather, the ease of hitting the target. Its hard to explain this, but somehow the ease of targetting when you are firing fast moving projectiles with no ballistic drop simply doesnt make for an engaging game. It is simply too easy to line up your cross hair on a target and pull the trigger. It felt like there was no skill involved and a multiplayer game MUST be about the relative skill of the players involved. A skilled player must always be able to beat a lesser skilled player over an average number of games. This is a very subjective thing I know, but having played a lot of combat based games, I know that what drives people, is feeling thier skill get better and that somehow the skill involved has a direct effect on the outcome of any given combat.

* Ballistic trajectory - The outcome of this, is that I decided to have a look at the difference between direct trajectory (i.e. fire projectile along a straight line) versus ballistic trajectory (where the projectile drops with gravity). Well, I can tell you, for a tank combat game, introducing ballistic trajectory really helped the feeling of skill! it is a minor change for the code, involving twiddling the projectile datablock, but it sure makes a hell of a difference to the feel of the game. Where as before I could just blam away at targets, now I had to consider the flight time, distance, relative motions etc. I had to lead the target, had to consider the
drop of the shell, in essence it added a much lacking element of skill.

* Optimisation - this will have to wait for another post to go into in more detail, suffice to say that often times, performance can be gained from tweaking the details and considering what really matters to the game. I've done some tweaks recently that have sped up the game immensely and took almost NO time to do the tweak, but took a LOT of time to figure out how and what to tweak. I want to pass on some of
that process, but it'll wait.

Early Panzer Ace screenshot

So back to the history...

Production on the game was going pretty well at the start of summer. Barring technical glitches, we could definitely get a multiplayer tank game working well, so we were looking at the various options of how to
monetize it. Around this time, a few of us got into crunch in our day jobs, production fell off quite a lot. In fact a lot of the early summer was that way. As with any spare-time thing, it can fall off quite quickly when large projects happen at work. Both myself and Thomas had major gigs happening over the last year and at times that has hurt the game development rather more than we'd have liked.

So a few months back, as we both got free from the projects that had been eating away at our time, we had a good long look at the project. It had come some way from the Air Ace changeover, but looking at it as
a commercial venture, we knew that we had a long road ahead. Given our time available, we had to make a big decision about how well we could deliver what is essentially a service based game. Online games must always be thought of as a service in my mind, because they require a longer term commitment to keep the game fresh, add content, make sure servers are up and running etc. Add to this, the problems of building a player base, keeping forums alive, billing etc. It all came pretty clear that we simply didnt have the time to finish the game we wanted it to be. There simply wasnt any way of building up the game with
enough players, managing the community etc. We could technically complete the game, but we simply couldnt find the time to work on the business and marketing side of it post release.

So we decided that rather than push forward with the online game. We'd take what we had from that game and push on with a scaled down offline version of it. Taking what we had produced and scaling the game down in terms of its back end business requirements and essentially produce a more intense single player combat game from it.

Since that decision, we've been working on AI to flesh out the singleplayer game. I'll post another post soon about how that AI has been working and the fun challenges it produces. We've also been working on mission designs and scripting. It turns out that its actually quite fun doing singleplayer mission design. Although actual level design for singleplayer has quite a lot more to it than multiplayer, you can at least isolate the requirements and build mission specific helper code (for an example, I built a message into the AI code recently that allowed me to tell a whole platoon to move or stop moving from the mission script).

So we're pushing on with this COD like singleplayer combat game with gusto, even the early completely unpolished mission scripts feel like they could eventually be quite nice. Hell, even the tutorial scripts Thomas put together showed some promise! So we're pushing this forward and we're aiming for a chrismas release, with as many highly polished levels as we can muster. Push push push.

And then the IA thing came out.

Now there's a spanner in the works. A service that seems to offer the business logic of multiplayer games a shot in the arm. A service that kind of fits in with our old plans for Panzer Ace.

Our goal right now, is to really put our all into getting PA singleplayer completed. After all these years of not having a product completed, it really is do or die. To do otherwise would just be insane. Even if there is a business case for going forward with a multiplayer version again. I think at this point, we dont really care
about the business issues anymore. Its about shipping. No matter what.

Longer term, we will have to wait and see how the IA plans pan out. How that its with what we were working on with Panzer Ace multiplayer (or indeed if Panzer Ace fits in with IA), but it sure would have been
nice to know six months back :)

Anyway, thats where we are. I'm not going to show you more shots as we still need to flesh out the issions and get theme playable and script complete before we hand them over for artwork (the method we're working on right now, is that we script up the mission gameplay, using whatever stand in art we need. Then we'll hand that almost competed version over to the artists in order for them to complete the level design and assets for the missions. But getting the missions to feel right in terms of pacing and action is the main goal right now.

Man, it is an interesting time to be working on this stuff. Singleplayer design is a blast and totally different from the multiplayer stuff.

It would just be nice if juggling those cats were a little bit easier.

End of Summer.

Phil Carlisle — 2007-09-04T23:42:25+00:00

Wow, is it that time again?

Yes, summers almost over, end of this month its back to work for me (bah). So I thought I'd do a quick update.

FBX Importer

Didnt get much time to look at this recently. But I did get the collada stuff from feeling software and had a look at integrating that into the pipeline. Either way, its basically a scene graph based format which has to be munched into TGEA internal format.

Whats weird about these things, is that neither FBX nor Collada seems actually very well documented. I mean, you see people complain about documentation all the time, but both Collada and FBX are supported by huge companies and yet they are still relatively creaky (i.e. undocumented features, formats or methods that work differently than expected). I'm actually kind of surprised how Discreet are saying that Max and Maya are both going to use this format for sharing assets.

Game

We are pretty much desperate to get our game shipped. So huge feature choppage has ensued :) but on the upside, we are stitching together the body parts left over from the great cull reasonbly quickly. Of course this isnt the epic tome we first envisioned. But if we can get a nice polished little game out there, we'll call it even.

Other stuff

Been reading about the amazon web services api. Got some useful stuff in there. Things like the flexible payment system, elastic compute cloud and the S3 file store are pretty damn neat. Of course, there is a downside (always is) and in this case its a pretty nasty one. For the FPS at least, the downside is that you need to have a US registered company!! Now I dont want to scare amazon, but I think someone should tell them that the world does NOT revolve around the USA. I just find it kind of painful that they only thought to innovate the internet for US companies only. Bah!

Why am I interested?

Because the FPS purports to actually support microtransactions. Think about it, microtransaction payments by a well known and trusted online vendor like amazon? Using an easy to program with API? Doesnt that sound like an opportunity? It sure does to me. I've got a product idea in mind for it, but of course its not possible until Amazon decide that the rest of the world isnt just some backwater made to do the cheap grunt work for all the high tech americans. Maybe I'm being a bit cynical there :)

Anyway, a quick update. Next time, pictures of the game!!

Come work with me!!

Phil Carlisle — 2007-08-27T19:00:00+00:00

Ok, its a blatant ad to get us started off. Sorry, should go in the help wanted place, but frankly thats a bit too noisy and I want to find someone :)

http://data.bolton.ac.uk/personnel/hr/personnelmatters/r&s/vacancies/cca037ac-Aug07-Advertisement.htm

Ok, to get past the corporate speak, come work with me on some fun stuff! You'll do some lecturing, but the main bulk of your work will be playing with us lunatics (ok, not true, but not THAT far off).

We're after someone who's a real vet, fancies a change from the usual game dev ratrace but still loves doing thier job.

Anyway.. Now that I've got the obligatories out of the way. I wanted to post about something else.

MMO's. Why do people constantly go over the same turf? I mean, go to www.mmorpg.com and look at the sheer number of MMO's coming out that follow almost exactly the same template? Then think of the number of fun indie games you could produce with that amount of funding!

It just kind of irks me that essentially people can seemingly throw money away at businesses that clearly have no clue of how to differentiate themselves.

Anyway, now that I've got that little rant of my chest. Right now I'm doing some research into how possible it would be to build an MMO architecture on an indie budget. I came across the amazon EC2 stuff a few weeks back and it got me seriously thinking. EC2 for the uninitiated is an amazon "service" which allows you to run linux based servers on thier hardware backend. Basically it virtualizes the whole process, so you can literally install and run servers on the fly via thier webservice API. This isnt really the key to it though (running a server isnt rocket science), what is innovative, is that you pay for CPU hour. You also pay very little. If you combine these things together (easy server launch API, quick server setup and launch) you should be able to see that an on-the-fly scalable server cluster could be built pretty easily. Not only that, but it would only cost you for the servers you NEED. No server sitting there running with nobody on!

So this COULD be used for a truly indie budget server cluster (on a par with the larger MMO's of this world). The only downside is that right now you cant specify a few things you'd need to really build a proper cluster, mainly in terms of the location and distance between servers switch-backbone wise. If they get that sorted, which I believe they intend to, then a cluster scale MMO on an indie budget is very possible. Hell, if the MMOkit would build on linux you could literally build a scale-out cluster using it!

So, thats an option for the future. I'll be keeping an eye out for the new API coming and might even experiment some.

The changing nature of entertainment

Phil Carlisle — 2007-08-14T21:22:34+00:00

I dont know about you, but I've all but stopped watching TV.

Up until recently, the TV was the main form of entertainment in many households. But recently I've noticed that I spend far more of my leisure time not just browsing the internet, but actually being entertained by it. Of course part of the problem is the quality of TV programming having sunk to new depths. Seriously, in the UK the TV has just gone so far down in quality, with huge numbers of "reality" shows that are cheap to produce but in a way you can tell. Combine that with the constant ads for insurance or loans etc and it really turns me off.

Sites like [url]http://www.youtube.com[url] are perhaps the tip of a newly emerging iceberg really.

Recently I've started using sites like TV Links UK to find what is essentially the same programmes I might have chosen to watch on regular TV but in internet form. Using this site completely convinced me that "user selected" internet based streaming TV is going to be the future of TV. Once we get ubiquitous fibre based internet we can actually stream TV at a decent rate. Somehow the process has to get easier, but the main thing that convinces me, is the nature of how you watch the programmes. In essence what convinced me was watching the whole of the series "Heroes" in two long sessions.

The reason I find this so compelling, is that it isnt a passive experience anymore. Basically its gone from push (TV) to pull (me asking for it). The experience is so much better, because you dont have the weeks gap between episodes anymore. You also dont have any ads, which leads onto a few key questions for this new paradigm:

1) Who is going to fund the new internet based programmes?
2) How are they going to recoup that cost from consumers?
3) Who is going to own the "channel" to the consumer?

This is something that I think WILL get worked out to a big extent. Perhaps embedded ads that are non intrusive and more targetted.

Of course there are technology issues, to do with streaming and bandwidth, but I'm entirely convinced that those are within achievable goals right now in at least rudimentary form. Look at something like www.stage6.com which has great streaming and full screen replay with none of the poor quality and capacity problems of youtube.

Why am I talking about this and what does it have to do with games?

Well, consider this. If my leisure time is going to be spent "pulling" from the internet. What is it exactly that I'm looking to pull? Ok, I enjoy passive experiences, so I want to see something interesting that I can sit back and be interested in. What interests me? Well, for me, unique invention, hearing about game developers and development, technologies, hell even watching others play games. So I see a lot of value in a streaming "channel" devoted to production of game development related content. But thinking further than the passive media, there is a whole gamut of experience I could be interested in. Right now we think of MMO's as the world of warcraft model, but frankly that is blinkering people to a whole range of interesting uses of the gaming medium. Orion posted a plan recently about a product that I think exemplifies a new range of boutique products that will slowly gain more and more ground over the passive experience of TV. Think about it, games about all sorts of things, perhaps an MMO that is actually historically based? Or one that has us all immersed in the world of CSI??

My main thrust here, is that in ten years time, I think interactive media is going to be a really big opportunity if we can only see far enough to make the experience less painful. I see that passive media will still have a place in the overall entertainment experience, but that fundamental shifts will happen and I think developers would be wise to think outside of what we currently see and think to what could work for people further down the line. When the vast majority of people seek thier entertainment online what form will that take. How about a channel where you all vote on user created "models" which have been styled by other players and are doing a virtual fashion show? Or virtual theatre performances where real people (virtual or using mocap suits or some such) produce realtime streaming performances direct to millions of people in realtime?

Honestly, there sure is a new wave of entertainment just poking its head up on the horizon, we can see the baby steps with community sites, but the future is going to look soooo different than it does now. It will be far more fragmented but also far more targetted and hopefully it will also be much more personal and valuable to us than the current dross thats being pushed at us in order to sell product.

Someone stole my notes!!

Phil Carlisle — 2007-07-25T16:44:27+00:00

I just got back from the educational day at the Develop conference in Brighton (england, uk). It was a bit of a weird day, but I wanted to post some info that I thought was interesting to GG's community.

There was a talk by Epic's Chris Wells, senior character artists on GOW and UT3. Anyway, I took a whole crapload of notes, unfortunately some bugger whipped the freebie bag I'd put the notes in for safekeeping, so this is going to have to be from memory.

One of the interesting things was to hear what kind of polycounts and texture counts they were using on GOW.

I'm sure you can get a lot of this info online, so feel free to do some digging of your own. But here are the figures as I recall them.

They start off with a reference model, basically a low poly reference figure (male, female), which is only used for proportion reference.

Then they build a scratch model, which is a basic (well, he called it basic, looked bloody fantastic to me) low poly model to start from. They then export this model into mudbox or zbrush to add in detail. Before doing that, he says that they figure out which parts to use which texture on. So he says that they basically they split up the UT models by having "organic" on one texture, "hard shell" on another (armour) and "common" on another. Common being tubes and stuff.

So, they perform the unwrapping and use some tool (which I cant recall) to relax the UV's, whatever the hell that means :) hahahaa. Ehem.

So basic UV layout using Deep UV. Texturing comes from reference on 3DSK etc and is applied using Deep Paint.

He talked a bit about how he adds detail to the armour using double chamfering and whatnot, but that was TOTALLY beyond me, I'm sure its a well known max trick.

So anyhow, once they have the low poly ref in zbrush or mudbox, they add lots of detail etc. He says they usually get up to about 8 million poly's or so. Oh, he said to remember to create your models using quads so that the normal mapping and zbrush stuff works better.

He did mention that some models go higher, up into the 30 million poly mark. Guess it is to taste :)

Once the details are added to the high poly mesh, now is the time to get that back into Max. Nows the fun part. Due to some weird reasoning, they use OBJ format for saving out the high poly model. Unfortunately there is a relatively low limit on the vertex count in an OBJ file, so they have to break down the model in zbrush into model sets. He basically selects an area of the model and saves it out seperately (face, hands, etc etc).

He mentioned a program called poly cruncher, which is a poly reduction tool. I think it runs within max to reduce the high poly cage before its used in the normal mapping process (not entirely sure why, maybe a speedup thing).

So imagine you have the high poly mesh and the low poly mesh underneath it. Then they basically bake a number of textures using max's render to texture (things like diffuse layer, ambient occlusion, normal map, copy of AO used to start off the spec map).

Seems they have something like diffuse, fresnel, specular, normal and one other map. Most of those are at 2048x2048 res.

Interestingly they do fiddle with the baked maps. Its not just a bake and forget thing. Touch ups and highlights etc.

The "final" low poly model, is tweaked from low poly they used to export to zbrush and usually comes in around 13k triangles although he said that they have topped out at 30k triangles for a complex character before.

So, there you go.. normal mapped stupidly good looking character process!

What other unique tidbits did he have?

1) Save time by doing "paintovers" rather than modelling. - This was a nice one, basically, instead of modelling detail, especially if you dont really know what you want from a final model but still dont want to be a slave to your reference or concept art, try doing a paintover on your reference (male female) mesh. A paintover is simply a quick 2d paint sketch over the top of a rendered image rendered from your reference mesh. So for instance, you have your reference female up in max/maya, you render a front shot, then you simply paint detail onto that reference until youre happy with what you have. THEN you model that detail.

2) Study anatomy and life drawing skills. - His background was as an anatomy artist, make sure you do lots of quick sketching (20-30 mins) of figures in different poses. His 30 minute sketches were pretty bloody amazing btw :)

3) Make sure to look at how characters actually pose themselves in different situations. Draw simple figures in quick sketches (like stick figures really) to capture those poses from memory. Try and get a vocabulary going of those poses and see where the anatomy comes in.

I'm sure there was a load more useful info, including book references he highly recommends. Unfortunately I cant tell you, because of the note-stealer!

However, hope is not lost, as they promised to put the slides up online for the talks. So once they do that I'll link here for reference.

The rest of the talks were either inspiring (Matt S from EVO) or annoying (Matt from EA, but for a different reason). Lots of the speakers talked about how they are looking for diversity and want to have developers think more "mainstream". I think theyre problem is mostly that they dont fundamentally believe it :) If they did, they'd not be trying to recruit industry experienced devs all the time right? They'd be talking to girls schools or something. Bah!

Anyway, sorry, lots of rambling drivel, I'm tired and it was a dull 5 hour train journey back. Now I'm off to veg out before heading off for a few days.

I'd post some of those lovely images of the UT3 models (oh man, they had a 30k poly WEAPON) but.. you can go and google em.

Oh, no work on the tools stuff this week. Busy :)

Art pipeline and other things.

Phil Carlisle — 2007-07-16T09:56:21+00:00

Art pipeline update

Greetings.

Ok, so more stuff on the Art pipeline. This week I spent time mulling over how various DCC apps export differently to FBX format. It seems there really isnt a single convention as to how one app saves as compared to another. On the upside though, the main advocate of FBX format also produces most of the main FBX content production tools (max, maya, motionbuilder) so I'm sure they will internally link up at some point and come to an understanding.

FBX format and the SDK is a tad weird though, because it has to support so many DCC tool features.

Originally I had envisioned using the FBX SDK from discreet for supporting Collada format files too (in addition to the obj/3ds formats it also handles). But having reviewed the code, I've decided to go for Feeling Software's FCollada libraries for it. FCollada is actually reasonably sane, if completely undocumented and frankly makes my eyes water less than the collada DOM and other api's I've seen floating around.

Right now I can read FBX format files with >1 UV sets (which is why I originally decided to do this), interestingly I was messing around with multi-sub materials in max trying to figure out how the FBX file would look internally after exporting a number of different setup scenarios (mostly in this case, adding a texture mapped box then trying to add different UV mappings and layers and textures and seeing how they worked). I've now figured out at least one useful workflow that seems to be what artists expect to do, so we're good to go from the FBX format front for at least moving forward.

So, next task is to get the DTSSDKPLUS to export the FBX format data from my internal scenegraph into Torque's DTS mesh format. From there its a matter of then adding the features to the Torque side to handle the various functionality I want (multiple UV sets etc) and then writing out the new features from the DTSSDKPLUS side and handling them in torque.

Once all of that works, I can integrate the Collada loader code into my scenegraph and the export should just work as-is. Same with .x and any other format I choose.

Game related

With a burst of productive energy right now, I'm having fun getting on with our games projects. Right now we're revamping the GUI to look more consistant and we're adding the UI to incorporate our shop-store backend system. I've come to the conclusion that writing custom GUI controls is for the birds and I'm using a compositional model a lot more (where you add controls to a GUIStackCtrl nested within a GUIScrollCtrl). Only downside is the pretty mixed up positioning elements and what appears to be a bug with extents of GUI controls not being updated properly when using the "width" and "height" of the parent control. Not to worry though.

I also started prototyping a simple 2D game during this weeks GID weekend. Although technically I wasnt GID'ing, it certainly kind of went that way. I implemented a simple heirarchy of objects in script, only to realize that I think I prefer to do that in C++ (plus the script was VEEEERY slow).

The basic premise of the game remains a closely guarded secret right now (ok, not closely, but I havent told anyone yet), but it involves a randomly generated heirarchy. The cool thing about using a randomly generated environment is that it allows me to offer unlimited mission possibilities.

Just to explain the random generation thing in a bit more detail. I decided to use a technique we used in the old worms games. When you generate a new game level, you are given an N character string. That string is the parameters to the generation algorithm encoded such that ANYONE can generate the same level based on that string. So sharing a good game level with someone else will be as simple as sharing 16 characters. Not only that but you can also randomly generate different TYPES of level based on different properties of the string (perhaps different bits in random parts of the string).

When players play the game, it is basically a logical puzzle, but it is bounded by time. You will earn a rating for any given level that gives you a "score" so to speak. So we can have people generate levels, have people DESIGN levels based on tweaking parameters, we can have people SHARE levels based on simple strings and we can SCORE players based on thier achievements for a given level. All with minimal effort and almost no data transfer. Sounds good no?

Another great advantage of this game idea, is that it essentially contains only procedurally generated content. Even the graphics will for the most part be procedurally generated (using an external application). In fact, the only thing that wont be generated is the world map. I'm hoping to find a source that will allow me to download the data I need to recreate that map though, so again NO artwork!

I'm happy with my prototype though. It feels like a good thing to do.

Feeling Lazy?

Phil Carlisle — 2007-07-10T18:19:42+00:00

I know, we all do it. We all feel lazy sometimes. I know I do.

I recently thought about how a whole community relies on GG to develop technology for them. I mean, who hasnt sat back and thought "ok, I could do this myself, but I will wait until GG release <product name/version here> with that feature in instead"??

I am sure many of you know what I mean. We kind of sit back and think wether we want to do the work, or we want to sit and let someone else do it, so we choose to sit.

But I've come to realize that sitting isnt progress. What I mean is that inevitably that road leads to a place where you never actually accomplish anything because there is always an excuse to blame someone else. It's bad enough that I let students do that kind of thing, but I'm fully capable of doing whatever thing I'm waiting for. So clearly my own lack of drive its whats causing me to sit.

Now thats off my chest, I'll leave you with this thought. If you've ever wondered why one game gets finished and another doesn't, ask yourself this... "Did they sit back, or did they get on and do?". Thats the crux of it. NEVER wait for someone else to create your technology. Employ the technology you have OR embark on your own. Dont be afraid to cut features if thats what it takes, but fundamentally, never EVER rely on someone else to do something you need. Unless of course you are fully in control of that person (paying) or have a balanced view of the risk.

We recently had a very stark choice to make regarding third party development. Our choice was that we will never rely on third party development for ANYTHING. Not because we have a "not invented here" attitude, but because if we rely on third parties, we simply never drive ourselves forward, there is always someone else to blame, or some other feature to wait for. Basically we never GET IT DONE.

Ok, might sound preachy, but I'm really just being self critical. Right now I'm in a very productive mood, have LOTS more technology I want to look at and I'm just getting on with it. I love it when I feel like this and part of this rejuvenation is the freedom from the self-inflicted shackles of waiting for someone else.

So, more info to come on various things I'm working on. Hopefully some screenshots soon too.

FBX pipeline progress

Phil Carlisle — 2007-07-07T15:14:50+00:00

Oh man, this FBX SDK is cryptic at times. There are a billion ways to get whatever data it is you want and a whole slew of "mapping" and "reference" modes.

I'm slowly sifting through it, essentially recursively visiting each node in the FBX scenegraph and constructing my own much simpler scenegraph nodes. Then I'll simply write an exporter that traverses the internal scene and outputs the format information I want.

So basically a DTSTraversal will output DTS files. A DTXTraversal will output a newer format with multiple UV's etc.

Then I'll take a look at a ShaderTraversal to output shader attributes. Maybe outputting a bunch of shader defs for TGEA to parse for example.

Thankfully, the project is starting to take shape. I can parse the FBX alright now, plus my basic scenegraph is in place (although its not very well tested). Still a ways to go, in that I need to write some unit tests in there and my basic output logging is frankly making me ill :)

Next up really, is to make sure I can handle the various mapping modes in a clean way. That is, producing scene nodes with mesh, uv, texture attributes etc.

One cool thing that will come out of this I hope, is that we can have multi-pass shapes with the various blend options and even vertex colouring etc. Basically all setup from within your DCC tool of choice. So for instance in max, you'd setup a couple of materials, or a single material with a couple of texture passes (one set to blend with the other) etc.

Once the basic mesh import/export pipeline is in place. I'll look at starting some of the other functionality, for instance convex hull generation, bounding box creation etc. But those should be relatively simple in that they take an input node (a mesh node) and create an output node (hull node, bounds node) and then you simply add handling support for that node type in the scene traverser you are using to output with.

I need to also get started on documenting the internals of this. To be honest I'm not really sure WHY I'm doing this (other than I got interested in adding another UV layer to DTS shapes), but it makes me think what the ultimate purpose is. As I go beyond simply adding another UV layer for myself, I've got to think about the overall goal. I guess my own goal is to make art production as simple as it possibly can be.

Anyway, here is the screenshot. Dont get too worked up, its basically visual studio and a window showing the console output of a FBX file! :)

Enjoy!