and the next step after that would be stepping up to skinned meshes vs rigid body animation. but i don't think even dx11 and the latest card could do it: 125 characters onscreen at once without slowdowns at 15fps. that would be 62 characters at once at 30 fps, or 31 skinned mesh characters onscreen at once at 60fps. games can't really do this yet can they? total war draws a lots of characters, but they're not high resolution, like a character in a typical shooter.

In the sports games I've worked on we've usually got ~30 players and referees on the field, plus ~32 low-detail spectators (which are then instanced/impostered to fill up to 100000 stadium seats). That's at 30hz on DX9/2006-era consoles (with about half the frame time being spent on post-processing), and 60Hz on the new DX11/2014-era ones.
Bigger rival companies were doing it at 60Hz in the DX9 era too...

Play any newish Assassin's creed or Hitman game and you'll see crowds of easily 100 animated NPCs, which the player can interact with (interrupt/push/etc).

Going back a ways, any Quake 3 derived shooter (e.g. every Call of Duty game) supports 32 player multiplayer on DX9.

Quake 3 was on the cusp between the CPU doing the skinning, and the GPU's vertex shader taking over that role. These days almost everyone uses GPU-skinning. GPU's can crunch *millions* of pixels per frame with highly complex pixel shaders, so 30 characters * 10k verts is a breeze.

Play any newish Assassin's creed or Hitman game and you'll see crowds of easily 100 animated NPCs, which the player can interact with (interrupt/push/etc).

These days almost everyone uses GPU-skinning. GPU's can crunch *millions* of pixels per frame with highly complex pixel shaders, so 30 characters * 10k verts is a breeze.

so its possible then?

even on a baseline box? (onboard graphics only)

or would a card be required?

in my case, i'm a lone wolf. so the engineer IS the content creator, and therefore can't be eliminated from the content creation loop. being a content creator with full knowledge of and access to the source code and compiler tools, about all data driven does is save me a few re-compiles.

Doesn't really matter. Being a lone developer or a content designer in a team of people, the goal is to rapidly iterate. A data driven system with tools that can preprocess your content to generate appropriate content IDs, validate paths, validate ID validity (you will likely have content referring to other content, which means that needs validation to ensure that content hasn't moved, been deleted, etc.) All of this is stuff that a decent set of content tools can do, all without requiring you to recompile the entire game.

That being said, for small one off projects it can be nice to just have a simple "asset to array + enum" preprocessor that walks a directory tree and produces an array of strings + enumeration with asset names. That's fairly trivial to code up in almost any scripting language you can imagine. This does presuppose though that your assets rarely refer to each other, but that's another problem entirely.

The solution of using asset IDs of some kind (GUIDs, integers, string hashes, string asset Ids, etc.) are quite common in AAA game development, and work. the nice thing is that you should never need to rely on them being in any specific order or that the index will or will not change (such a requirement means your code will easily break, and hence why it shouldn't be done).

That one uses a Radeon HD 6310 according to AMD`s datasheet, which supports DX11 (or OpenGL 4.x), so using these features is no technical issue.

i didn't think it would be. i assumed it was at least dx10 capable.

i haven't made that "big move" yet from dx9 fixed function for a few reasons:

1. except for 100+ skinned meshes at once in Caveman 3.0, dx9 does what i need and i already know the API.

2. unless i can get free shader code to replicate basic dx9 fixed function capabilities (alpha test, alpha blend, 2 stage texture blend), i have to write some number of shaders to simply get back to where i already am.

3. the pipeline API between dx9 fixed function and dx10-11 is sufficiently different that more than just shader code would be required just to get back to where i already am. only at that point could i then move forward and implement things like massive numbers of skinned meshes, true instancing for terrain, etc.

4. the next 3 titles planned after caveman 3.0 are all flight vehicle simulators (starship, airship, and Aroura/X-type space fighter plane), so no need for lots of skinned meshes, complex terrain scenes, etc. I have yet to think of an effect required that dx9 cant do.

5. the idea is to build games, not port unfinished titles to a new version of directx and windows and all the other latest and greatest stuff all the time, especially when the additional features are not required. the tool should be no more complex and powerful than required. otherwise your "using a tank to kill an ant". that comes from generic design sciences. it speaks to the concept of not using a complex system for a trivial task.

note that i have begun to make the move though - i do have the beginnings of a dx11 version of the z game library done, complete with testbed program. but until development needs justify the time required to get full dx11 with shaders going - i can't justify spending development time "sharpening the saw" any more, as its still plenty sharp enough for the tasks at hand. the same way we're always advising folks here to not "use a tank to kill an ant", i'm trying to resist the temptation to step up to the shiny new dx11 model "tank", just because its high tech bleeding edge stuff. maybe if i was a demo developer, but i'm not - i'm a GAME developer. <g> graphics are just a means to an end - the GAME is the thing.

But this is something that will severely limit you anyway. Using DX9 fixed function for something "massive" like you're doing seems crazy (when DX10 and DX11 are readily available on your minimum spec model). Switching to a higher version of DX, or even OpenGL, may be a substantial change, but right now you are not using 75% of your GPU's capabilities, and you are burning 50% of your CPU's time for driver overhead without actually getting anything in return.

It's OK to use DX9 if that is all you have for development and you want to support clients with 10 year old computers. But it's crazy not to use a much faster, much more modern path with features like instancing and array textures that is readily available (your customers have paid for these features, let them use them).

well its kind of a moot point at this point as the games is just about done, and dx9 got the job done (barely). the next major version will be dx11+ based.

This is something that was possible even with software skinning on a somewhat powerful CPU 5-10 years ago (of course with somewhat less detailled models).

then the next version will definitely used skinned meshes.

the goal is to rapidly iterate. A data driven system with tools ... without requiring you to recompile the entire game.

my problem is that when i start, and for the vast majority of the development cycle, the compile times are trivial. only if a design grows very large does compile time become an issue ( Caveman 3.0 is now up to 55 seconds for a link). and that's rare, occurring only at the end of the largest games. and you know how it is, games tend to grow beyond their original scope. so the games are not expected to be "large" when started, so data driven isn't usually considered.

this time around, i'm considering data driven with built in editors from the get-go, but again the next title is not expected to be "large" - not nearly as big as Caveman - so its difficult to justify the extra dev time required for data driven + built-in editors.

but i do realize the advantages of data driven. in fact parts of caveman are data driven with built-in editors. but its only a few variables (animation IDs and such) in the animal types database that are data driven. again it was hard to justify adding load, save, and editing capabilities just to assign one constant value to one entity type one time only and then never use it again. reminds me of the guy who spent 3 years building his world editor for his game, then used it to build his game world in 3 days (or was it weeks?) and then never used it again. true story, i saw his posting online about it once somewhere. i only did it because of the 55 second link times i was up against at that stage.

hat being said, for small one off projects it can be nice to just have a simple "asset to array + enum" preprocessor that walks a directory tree and produces an array of strings + enumeration with asset names. That's fairly trivial to code up in almost any scripting language you can imagine.

clever, use code to generate your source code of enumerated IDs.

i was almost considering adding user defined tokens to my in-house macro processor to do the same sort of thing.

yesterday i finished creating and assigning sound effects to all objects, actions, skills, and entity types, and animations to all objects, actions, and skills. i ended up using hard coded array indexes, and tabbed back and forth between the code and the data driven lists of files to load to look up array indexes for wavs and animations (array indices are assigned in order of loading). i wrote commonly used indexes down on a piece of paper for even faster reference without having to tab back to the load lists. this actually went quite fast given the amount of stuff: 300 objects, 100 types of actions, 50 skills, 50 monster types - and some actions and skills depend on the object (making/repairing) or skill (learing) type - adding another 50 or 300 cases each! only took a couple days. i doubt that a built-in editor would have let me set all those constants much quicker. then again, i'd assign 300 sfx, then recompile once, and so on... so i only recompiled a few times - maybe 6 or 8 times over two days.