Thursday, 15 November 2012


When this game was originally planned, with the assumption of tiles, I had hoped to do everything on the CPU to avoid all the troublesome library linking and constraints on end-user hardware that come with using the GPU. Obviously with 3D graphics that's not a position I can maintain, so I've started reminding myself how OpenGL works. I's a lot different to 3.5 years ago when I was taught it!

It looks as if I should be able to leverage the GPU for a little or a lot of the simulation requirements of the game, provided I can keep the graphics processing to a minimum. There are a lot of things the computer will need to do:
  • track locations of N actors on a heightmap
  • keep grouped actors marching together, preferably via local interactions similar to boids, and preferably with variable "discipline" governing regularity of formation (discipline 1.0 => perfectly aligned rectangles and (sometimes, when surrounded) circles, discipline 0.0 => random jumble)
  • render heghtmap shadowed by visibility from PC, and preferably by sun's angle too.
  • render actors visible to PC: different skin textures (corresponding to armour types), different weapons, different animations at different stages (or, even better, simple ragdoll)
  • render actors reported by scouts, either in observed location or in assumed new position
  • track locations and actors visible to scouts (and estimate sizes, directions of groups seen by scouts)
  • track actor-actor visibility, with occlusion from heightmap, actors, and vegetation/buildings
  • avoid actor-actor collisions
  • simulate actor-actor combat (geometrically rather than numerically)
  • simulate movement diffculty caused by and to large groups of pike wielders (particularly in forest)
  • track orders for each actor or group
  • propagate orders through shouting
  • interpret orders and make independent decisions
  • track skill use and increase speed and effectiveness of the relevant actions accordingly (latter part optional - can be done between battles)
  • flexible actor size to accommodate horses, elephants, etc.
  • find paths, considering difficulty moving uphill, potential difficulty moving through vegetation or water, positions of dense groups, enemy groups and groups in combat. In last scenario (and preferably others), walls will become relevant
  • attempt to surround or flank enemies when possible
  • change facing appropriately when [potentially] surrounded or flanked
  • use sensible strategies for enemies - simulate a general if possible
  • allow pausing, slowing down, speeding up.
  • generate a variety of large, realistic heightmaps with vegetation and water, and render these efficiently enough to allow the largest possible number of actors on screen.
Some of  these will be more suited to one or the other of the CPU and GPU. Using CUDA would make a lot of these tasks much easier, but I don't want to restrict players to those with nvidia cards and I haven't actually succeeded in compiling anything that uses CUDA. OpenGL 4 seems to have enough features to make at least some of these tasks doable on the GPU.

Anyway, the current state of the program is a heightmap render gutted and Frankensteined from, (which seems to be abandoned), and... I think that's it so far. Most of the surgery I had to apply comes from removing all references to the GLTools library (substituting GLM), and removing all references to freeglut (substituting SFML).

To continue, I think the next few steps will be:
  1. Get terrain LoD with tessellation shaders working.
  2. Get instanced actor drawing (with LoD) working.
  3. Figure out how to get a variety of textures and individual weapons and ragdolls (or at least animations) working on instanced actors.
  4. If I get bored during one of those stages, figure out how to do triplanar texture mapping on a tessellated heightmap (and hence kill the unpleasant texture stretching artefacts that are so common in RTSs)
  5. If I get really really frustrated trying to draw tens of thousands of instanced actors without killing framerate, figure out how to do those triplanar textures with Wang tiling (which is really cool)
GPU Gems and pyalot's WebGL projects pop up a lot in my googlings, and I'll probably end up using a lot of code from there. I'm going to allow myself one rewrite, so that I can experiment freely with the techniques I'll need to try without worrying about sensible coding practices. Once I'm confident that I've done enough research I'll figure out what to title this thing and start the rewrite, doing things properly with header files and OOP and things. At that point I guess I'll be approximately where I was when I dropped the discrete-space version, but with a lot more processor power to harness and a much more sensible space in which to do the mechanics of actor-actor interactions.

As for titles, I still haven't got any better ideas than "Rogue City".