So what does a battlescape need?
- Terrain: this is the "ground" that limits how the combatants can move, so includes walls, floors, ceilings, doors, lifts, stairs, and "inert" objects that block movement, e.g. chairs, tables, plants, fences, etc.
- Sides: The two sides that are fighting. (Computer and Human player.) If someone can give a better name, I'd appreciate it.
- Combatants: the things that fight on the battlescape.
- Items: stuff that is carried by combatants, and can be picked up/dropped.
- UI. This has several parts:
- Interface used by player to give orders to combatants
- Representation of the battlefield.
A question to resolve, how are we going to handle this?
First thing to note, we need to distinguish between how the terrain is modelled by the game engine, and how it is rendered on the display to the player. E.g. in X-Com, the terrain is shown to the user as a set of 2D sprites with a fixed viewpoint, but the internal representation is a set of 3D "cubes".
It occurs to me that a quick way to get terrain working would be to load X-Com style maps. I note that DaiShiva's MapView is written in C#, so if we can get a copy of his code, loading maps should be a fairly simple exercise.
The main problem with this approach is that if we want to draw the battlescape as 3D which can be viewed from any angle, there isn't enough information to do that.
A next step along would be to try and generate a 3D model from the map files. E.g. If the Map file indicates a wall, set up a quad in 3D space at the wall's position, and then paint it with the texture from the pck file. Which gives problem one, the quad needs to be textured on both faces, and we don't know what to put on the side that a X-COM player doesn't see. Obstacles (chairs, plants, etc.) are an even bigger problem to render.
An alternate simple way of getting a working terrain is use a very simple "tile" system to map out an area. Tiles could be:
- X-Corp forces start point.
- passable terrain. e.g. Road
- Impassable terrain that blocks line of sight. e.g. Car/rubble/trees?.
- impassable terrain that doesn't block line of sight. e.g. Water
- Set of 9 tiles that make up a building. E.g. south west corner, South wall, SouthEast corner, Center, etc.
- Actually, might want 6 more tiles, to build one tile sized parts of buildings. E.g. a north, east and south wall tile, to give a room that juts out from the east side of a building. Or a north and south wall tile, to build a corridor connecting two buildings.
- the 3D render engine reads the tiles and then uses them to construct a mesh.
- As with Aftermath, the soldiers would not be able to enter buildings. Although I suppose we could allow parts of buildings to be blown up.
- Height information could be added to the tiles, to produce a non-urban maps.
- For battle inside a building, divide floor into 1 meter tiles, and use bitfield to indicate if tile has north/south/east/west wall. Hmm. If use 16 bits per tile, then have 16 different textures we can apply to each wall. (note, one will be the "no wall" texture, and one might be a door.)
- Heh. I think the ultimate extension of this is something like X-Com's MCD structure.
- We could use different scales. For indoor environments tiles are 1 meter, for outdoors, tiles are 5, or maybe even 10 meters.
- Alternate thought, could we use quadtrees to hold the tiles, and have variable sized tiles?
What do combatants do?
- Note, I'm distinguishing between combatants and the AI that drives them.
- Have a position and orientation in the battlescape, and can move.
- Observe parts of the battlescape.
- Pick up and drop items
- Use items
- Attack other combatants. (Note, this is possibly a specialization of "use items")
- Be injured.
- Obey (to the best of their ability) the orders they have been given. (Possibly this is more an AI feature?)
- I'm not quite sure where to put grenades in the scheme. They sort of count as actors (things that change state in response to events.) At least the proximity grenades react to combatants getting near, and the other grenades are on a timer. However, other than combatants, I don't think there's anything else with that sort of behaviour, so I'm thinking easiest solution is going to be special case code for grenades, rather than trying to come up with a general solution. (We can do that when we have something else with "actor" behaviour.
Edited by dteviot, 26 December 2007 - 02:59 PM.