Work still to be done:
- 2x2 Units.
- Correctly size them, (Actually correctly scaling all units is probably needed, add a scale and size elements to combatant.xml)
- draw at correct position on battlescape. (Because they cover 4 cells.)
- Line of sight/fire. Actually, these two might not be such a problem. For rule engine purposes, assume combatant is at center of north west cell on terrain. Then add a displacement vector of (+0.5, 0, +0.5) to draw centre of combatant at intersection of cells.
- X-Caps/tanks on battlescape
- Civilians on battlescape terror missions. (Also when aliens attack an X-Corp outpost?)
- Better (or more fun) AI logic for alien forces on battlescape.
- Experience for X-Corp soldiers
- Bleeding out of wounded soldiers.
- Medkit healing
- Recovery of stun damage
- Rest of actions that items are capable of.
- Psi attacks
- Psi probe
- Waypoint (for BB launcher)
- Fire on battlescape
- Smoke on battlescape
- Line of sight effects
- Stun damage
- Ability for combatants to drop and pick up items on battlescape.
- Draw dropped items on the battlescape.
- Proximity mines
- Night missions.
- Rules engine: determine visibility
- Graphics engine: how to render?
- Cydona mission
- Allow X-Corp player to select troops that will defend an X-Corp outpost from alien attack.
- Generating battlescape terrain (esp. for different types of missions.)
- Destructible terrain
- Just being able to destroy walls and floors.
- Major property damage when structural elements are destroyed. E.g. no "floating" building levels after the ground floor is destroyed.
- Improved line-of-sight calculations, to allow for posture, combatant height, and terrain obstacles in way?
- Re-equip soldiers after battlescape mission/before starting new mission. Note logic is already there in CombatantInventory.RestoreLoadout() and SnapshotLoadout(), just need to hook up and deal with case of insufficient supplies in outpost.
- Aesthetically pleasing UI.
- Aesthetically pleasing rendering of battlescape terrain
- Related (maybe) only render part of scene that's in viewing fustrum
- Animate the combatants on the battlescape.
- Draw items in hands of combatants on battlescape.
- Fog of war: No information to player on terrain that hasn't been seen yet
- The ToDo list: (http://svn.projectxe...s/ToDoList.html)
Of these items, the ones with highest priority, because I think they're going to have the most impact on the other features, are:
- Destructible terrain. Impacts on how terrain is modelled, which impacts almost everything.
- Civilian combatants on battlescape (has AI implications)
- Reactions (has AI implications)
- 2x2 units
The more I think about it, the more I feel that Destructible terrain, Fog of war (player being ignorant of unexplored territory), and night missions (player can't see unlit territory) are all related. They require being able to control the terrain shown to the player at a high level of detail. For this reason, I think the solid terrain meshes (e.g. the 3D facility models we have) are not going to be viable.
How to do this?
- Method used in X-Com 1 and 2. Divide space up into cubes, draw a texture for each face. Computationally, this works. It's possible to build a single mesh for the terrain (assuming the viewing frustum is no more than 20 x 20 cells in the x and z dimensions) and render it each frame. (In a single draw call.) Unfortunately, it's really ugly. See http://www.xcomufo.c...h...st&p=174260 Also, it has issues with the combatants interpenetrating the walls.
- Next option, replace the quads (for each wall and floor tile) with a 3D model.
This should look good, or at least better, but this requires more complex rendering logic. Specifically, if each face is a model, then there are potentially 20 x 20 x 3 = 1200 models per level per frame. And each model will require at least one Draw() call to render. However, there is a limit of 100 to 200 Draw() calls per frame. I can see a number of potential solutions to this.
- One is use model instancing, where a single Draw() call will draw multiple copies of the same model. Assuming most of the floor tiles are the same, and we only have a few different wall models, then this certainly seems viable. Note, I think this requires the models have small poly counts, probably less than 256 polys. But for ground and wall tiles, (and tables, chairs, bunks etc, this probably isn't a major issue.)
- Second possibility is given in Game Programming Gems 3 chapter 4.11 "3D tricks for Isometric Engines" which shows how to convert a 3D model into a 3D texture. Which could be used to convert 3D models into the quads used to render the faces each cell.
- Third possibility is given in Game Programming Gems 2 chapter 5.7 "Impostors: adding clutter" Similar to GPG c4.11, converts a complex 3D model into a much simpler 3D model.
- A variation of using 3D models for each face of the cube would be to use a single model for each cube. e.g. instead of drawing a wall across the west face of the cube, there is a model of a wall running north/south down the middle third of the cube.
I can see a couple of advantages to this
- Reduced number of models to render.
- Probably simplifies Path finding and line of sight. Don't need to worry about the north and west faces of each cell, can just regard cell as a single block.
- Probably reduces interpenetration of combatant models. By offsetting the walls to a distance inside the faces of the cube, combatant's arms (and equipment) are less likely to interpenetrate the terrain.
- A problem with breaking up the terrain models into cube or face sized pieces is that having large pieces of terrain is difficult. E.g. A wide screen display on a wall that's more than a meter wide. Or a table or bunk that's several meters long. These would need to be make of several models, but breaking one piece would probably look weird. E.g. destroy half a wide screen monitor, and have half the display still working. Or half a table, and have the remaining half table remain upright. A possible solution might be to have larger models, made up of a set of cell sized polygons. E.g. have a single wall object that's 4 or 5 meters long. If part is broken, then replace the model. (However, this then gets back to issues of keeping the rules and graphics engines in sync.)
My thought on the e-mail to the Silent Storm people was something along the lines of:
(and then attach the above notes on Destructible terrain)
Hi, I'm working on an attempt to recreate an open source 3D version of X-Com, and I'm currently trying to figure out how to have nice looking, fully destructible 3D terrain. As you've already done this for Silent Storm, I'm hoping you would be willing to give me a few hints or suggestions.
Specifically, below are my thoughts on how it might be possible to do this. If possible, could you tell me which approach you think is most likely to work? (So that I don't spend time and effort on the less feasible approaches.) Of course, if you can suggest a better method, or can give me any other information it would be greatly appreciated.
Edited by dteviot, 25 March 2008 - 01:21 PM.