Jump to content
XCOMUFO & Xenocide

Battlescape Design


dteviot

Recommended Posts

Well, it's now time to start working on the battlescape. I had hoped that the fishbowl project would have produced some answers by now, but that seems to have been ineffective.

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.

Terrain

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.

With these, I think it would be fairly easy to lay out a map similar to the "city" maps seen in UFO:Aftermath.

Notes

  • 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.

Possible variations on this:

  • 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?

The more I think about it, the more I like the tiling approach.

 

Combatants

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.
  • Die
  • Obey (to the best of their ability) the orders they have been given. (Possibly this is more an AI feature?)

Other notes

  • 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
Link to comment
Share on other sites

Possible stages for constructing the battlescape:

  1. Define the terrain model.
  2. Build engine to render the terrain, and provide a UI to allow human to move camera to view terrain.
  3. Put combatants on terrain, drawn at correct position, orientation and scale.
  4. Combatants move around the terrain, obeying the restrictions of the terrain. UI provided to allow setting rate time passes at. (Are we going real time or turn based?)
  5. Define combatants' main properties. (e.g. location, orientation, max speed, etc, not to be confused with statistics {the things shown on the soldier stats screen.})
  6. Flying units
  7. End of battlescape conditions (Player quit, all of one force defeated). Calculate salvage and score from mission.
  8. UI to allow human to tell combatants where to go.
  9. Add visibility rules for units. (Initially, just have viewing distance and terrain blocking of view. Do NOT include day/night or smoke obstructions at this point.) 3D engine has cheat mode to allow showing all forces, marking which enemy are visible, and which are not.
  10. Items implemented. Combatants can pick up, drop and move items around in internal inventory.
  11. UI to allow human to order combatant to move items.
  12. Items have actions. Putting item in hand allows combatant to use actions.
  13. UI to allow human to order combatant to manipulate items.
  14. Model weapons. Combatants can be wounded and killed. Weapons have accuracy, range, damage, damage type, and ammo limits. Armor is also modelled.
  15. Allow units to attack each other.
  16. UI to allow human to order combatant to attack another (or move).
  17. Stun damage.
  18. Medkits
  19. Grenades.
  20. Construct battlescape terrain and alien forces (combatants & equipment) from UFO and mission type. (X-Corp forces & equipment are already constructed and in the aircraft/outpost.)
  21. Psi attacks
  22. Smoke
  23. Breakable terrain.
  24. Night missions?
  25. Random terrain generator?

Note, we don't necessarily need to do these stages in exactly this order, I'm pretty sure we can do many of them in parallel. And I've probably missed a

whole bunch as well. Feedback appreciated.

 

Possible prototype battlescape structure:

class Battlescape
{
public Terrain terrain;

// the opposing forces
public class Force
{
	Combatant[] combatants;
	Controller  controller;	  // Human (local/remote maybe?)/AI
}
public Forces[3];  // X-Corp, Aliens, Civilians(?)

// items on the battlescape that are not being carried by combatants
public HashTable<position : Vector3, Item> items;

public class State
{
	DateTime time;  // seconds into battlescape mission
}
}

Link to comment
Share on other sites

David, the list is fairly enough to start it as a sort of Scrum backlog... great jeb there... I suggest attack not more than 2 or 3 of them in parallel (in fact the first couple should be done serially)... I will try to schedule my time to handle the rendering of night/day cycles so you only need to put the time of day and latitude/longitud and we position the lighting accordingly. If anyone do like to learn about how to do it, I have plenty of resources :)

 

Greetings

Red Knight

Link to comment
Share on other sites

David, the list is fairly enough to start it as a sort of Scrum backlog... great jeb there... I suggest attack not more than 2 or 3 of them in parallel (in fact the first couple should be done serially)... I will try to schedule my time to handle the rendering of night/day cycles so you only need to put the time of day and latitude/longitude and we position the lighting accordingly. If anyone do like to learn about how to do it, I have plenty of resources :)

Greetings

Red Knight

With respect, all we need for day/night is to figure out if it is day or night. And I already figured that out for the geoscape. (Now I just need to generalize the code)

For daylight, allowing for the sun's angle adds negligible gameplay.

Night missions are, I think, are going to be a headache. Efficiently doing visibility calcs/rendering when we have 10s of light sources/occlusions could potentially get very nasty. That said, it might not t be that hard, as X-Com 1 managed it with much slower hardware than we have.

 

At any rate, lighting is way down the priority list.

The things we need to work on right now are:

1. Terrain model.

2. Battlescape model.

3. Combatant model.

4. Controller model.

 

And they're at least partially independent. And I'd really like feedback, suggestions.

Link to comment
Share on other sites

I was speaking about the rendering only part of the equation, not gameplay wise ;) ... the good thing is that day/night cycle rendering wise is just a single equation + other light sources... So as long as you can define where the lights are and their lighting volume you are done gameplay wise; the rest is just "shading magic" :) ... and I agree you have to put first all models in. In the end lighting is required for rendering anyways, so better if you can do it generically for any condition ;). Something that luckily can be done far easier than with pre-shaders architectures. :)

 

Greetings

Red Knight

Link to comment
Share on other sites

David, sure find me on IM cause the delay in the communications via forum is too high for the kind of interaction we will need to define something like Terrain. After that we can post the ideas that may arrise.

 

Greetings

Red Knight

Link to comment
Share on other sites

Thanks RK, but I'm not set up for IM. Also using e-mail lets me think about my ideas, and then post them up.

 

Here's my Initial Terrain Model.

I'm going to use the same cell model that I initially built for the fishbowl.

That is, the terrain is composed of a 3D array of cells.

Specifications are:

  • We're using the standard Right Hand Coordinate Axis that XNA uses, so, the Bottom, North West corner of the map will be the origin (0, 0, 0).
  • The positive X axis is going east.
  • The positive Y axis is going up.
  • The positive Z axis is going south.
  • Negative X, Y and X co-ordinates are invalid.
  • The units for the X and Z axis are meters.
  • The units for the Y axis are levels. About 2.5 meters.
  • Maximum size of the array is 128 (X) by 128 (Z) by 8 (Y).
  • We're going to start by modelling an "interior environment". Think, the inside of an X-Corp or Alien base. My thought is that from the "game engine" point of view, this is going to be the most complex environment. A "rural" (entirely outside) or "urban" (mixed inside/outside) environment would use the same cell model; we just generate a different "graphic overlay" over the model. I'll explain this in a bit.
  • Each cell in the terrain is composed of a collection of bit flags that describe the properties of the cell. The bit flags are:
    • bits 0 and 1, Floor height. Values are
      • 0 = No floor. If a non-flying combatant enters this tile, unit is going to fall to next level down. If on level 0, non-flying combatants can't enter the tile. (E.g. it's water.)
      • 1 = Ground level floor.
      • 2 & 3 = Floor at 0.3, and Floor at 0.7. These allow building stairs/ramps/sloping ground between levels. The idea is, any non-flying unit can go from a ground level to a 0.3, from 0.3 to 0.7, and 0.7 to Ground on the next level up. So, by putting a row in order, we can construct stairs etc.

      [*] bit 2. Blocked 0 = combatants can enter cell. 1 = combatants can not enter cell. This means there's something in the cell that prevents a combatant moving into it. E.g. There's a plant filling the location.

      [*] bit 3. View blocking 0 = line of sight is not blocked. 1 = line of sight is blocked. This means there's something in the cell that prevents a combatant moving into it. E.g. There's a plant or other piece of scenery blocking the location.

      [*] bit 4. Up Grav Lift 1 = Combatants can use this to go up a level. (Or come down to this level, from the one above.)

      [*] bit 5. North wall 1 = North face of this cube has a wall, that blocks combatants from moving from this cell to the north neighbour.

      [*] bit 6. North wall opaque 1 = North wall is opaque, blocking sight lines. If 0, wall is transparent. E.g. It might be glass (a window), or mesh, or a low fence/hedge, etc.

      [*] bit 7. West wall 1 = West face of this cube has a wall.

      [*] bit 8. West wall opaque 1 = West Wall is opaque, blocking sight lines.

      [*] bit 9 & 10. Exit

      • 0 = location where X-Corp combatants can start mission
      • 1 = location where X-Corp combatants can end mission. Note, if there are no cells of this value, then 0 can be used as exit points
      • 2 = location where Alien combatants can start mission
      • 3 = location where Alien combatants can end mission.

Some additional notes on the flags.

  • A cell with a value of 0 indicates a completely empty cell, without even a floor. This will probably be the most common cell.
  • A cell with a value of 1 indicates an empty tile with a floor (probably the next most common type.)
  • I'm leaving doors out for the time being.
  • Likewise, terrain is not destructible. At least for the initial terrain model. In later models, bits 5, 6, 7, and 8 will be removed, and replaced with two bytes which index the MCD tile for the north and west faces. (As implemented in X-Com 1.)
  • Some combinations of flags are interesting.. E.g. having no north wall, but blocking the view to the north. (Actually, I guess physically this could be a door or a curtain.)
  • Some combinations of flags are may be invalid. Although I'm not sure which ones they would be.
  • I'm not sure if I should also include south and east walls. (and a Down Grav lift). In theory, this information is already available from the neighbouring cells, so adding it to each cell would be redundant, but might make thinks like pathing/line of sight, either easier to implement, or faster.
  • Loading levels. To start with, I suggest we manually build a number of maps (task for a recruit, build a map builder tool.) A bit later on, we may be able to create a random map generator. Another option, it should not be that hard to parse UFO2000 maps and MCD files and build a cell array.

Graphic overlay

The idea here is that the cells represent the underlying structure of the terrain. We can then draw a 3D model over the cells. For a first cut 3D engine, we just take the faces of each of the cells, create a quad, and texture the quad. E.g. if cell has a floor, then put a quad in the position of the floor, and texture it with the "floor" texture. We can do the same thing for "solid wall", "curtain", "window", "ceiling", and "water".

Later, we could impose a whole 3D model around the cell. E.g. we don't draw the cells at all, but instead draw 3D models at relevant places on the geoscape.

 

So, what do I need to proceed?

  • Input, is this a valid starting point? or is there a better one?
  • That's it I think. I can use some arbitrary textures to start with, and we can add some better looking ones when we find them.
  • Terrain file format. If someone wants to build a terrain editor. I suggest, file is an stream of int16s. first 3 are X, Y, & Z dimensions of the terrain, then the value for each cell, written in order:
    for (int x = 0; x < maxX; ++x)
    {
    for (int z = 0; z < maxZ; ++z)
    {
    	for (int y = 0; y < maxY; ++y)
    	{
    		write(cell[x, y, z]);
    	}
    }
    }


Edited by dteviot
Link to comment
Share on other sites

  • 1 month later...

Some more thoughts, feedback appreciated.

I was really wanting to have real time play on the battlescape (as done in Apoc.) However, I've managed to convince myself that RT is going to be a lot harder to do that turn based. So, the quicker way to get to the final result is build it TB initially, and then when that's working, look at adding RT.

 

So, for turn based, I think the basic Update() loop goes:

  1. Start of turn, set all combatants to full TUs.
  2. Wait for X-Corp player to give order to a combatant.
  3. Have combatant start performing action.
  4. While action being performed, check if action causes a reaction (see below)
  5. If action causes a reaction, active combatant stops action, and opposing force(s) perform reacting action.
  6. Repeat from 2, until X-Corp player indicates he's finished with the turn.
  7. Repeat from 2, with Alien player giving orders to alien combatants.

Actions that can cause a reaction:

  • Combatant moves onto into the sight line of an opposing combatant. (Note, if a combatant is moving, as SOON as combatant moves into sight of enemy, movement ends, even if orders were to move further than tile combatant was sighted on.)
  • A combatant is hit by enemy fire. Test for reaction occurs at end of the "shoot" action.

Reactions:

  • Turn to face direction of enemy fire.
  • Fire at enemy

Link to comment
Share on other sites

OK, here's my initial design for how the Battlescape's Update() loop looks. As always, your feedback is appreciated.

Note that it's going to be a while before I get around to implementing the psi attack and reaction states.

Oh, and I probably have to add a "post action" stage to evaluate if anything happened that might count as "training" for skill improvement. And I need to fit in grenade detonation.

Actually, that raises another question. Does anyone ever set a grenade to explode at any time other than "at the end of this turn". If so, why? I'm considering having grenades detonate when they land after being thrown. Makes programming simpler.

Battlescape_Update_loop_state_machine.png

Link to comment
Share on other sites

Some comments (sorry for the late response, I though that in vacations would have some time but looks like the unplug was complete), in fact a minor comment on cells. Do not use integers for it, create a class or an struct so you can add more information (that you will need).

 

The turn actions looks very good.

 

Greetings

Red Knight

Link to comment
Share on other sites

Guest Azrael Strife
OK, here's my initial design for how the Battlescape's Update() loop looks. As always, your feedback is appreciated.

Note that it's going to be a while before I get around to implementing the psi attack and reaction states.

Oh, and I probably have to add a "post action" stage to evaluate if anything happened that might count as "training" for skill improvement. And I need to fit in grenade detonation.

Actually, that raises another question. Does anyone ever set a grenade to explode at any time other than "at the end of this turn". If so, why? I'm considering having grenades detonate when they land after being thrown. Makes programming simpler.

post-7505-1201718997_thumb.png

Looks good, the only thing I'd say it's missing is Civillian movement (this applies only for Terror Missions of course) that should occur before player/alien actions :)

Link to comment
Share on other sites

Some comments (sorry for the late response, I though that in vacations would have some time but looks like the unplug was complete), in fact a minor comment on cells. Do not use integers for it, create a class or an struct so you can add more information (that you will need).

 

The turn actions looks very good.

 

Greetings

Red Knight

Huh? Cells is a struct.

Link to comment
Share on other sites

  • 2 weeks later...

That is what I wanted to say. Using Flags to specify that information do not gives you enough room for changing as the flags are intrusive in the code; you have to be very careful when deciding to use flags instead of a class with some extra code that would perform the calculation you want (like ray intersection or decide whether you can get in or out of there). When using flags the computation get moved into the caller instead of the callee; leaking details into the upper layers causing manteinability issues (like very high coupling between components).

 

Greetings

Red Knight

Link to comment
Share on other sites

  • 1 year later...

Greeting Team,

My apologies for my abscence. It was meant to be a break of only a month. (After about 2.5 years of working on Xenocide every spare moment, I was kind of burnt out.) Then I thought I'd try doing some writing, and after six months realised that I really didn't enjoy doing it. Writing is hard work, and it's never as good as it originally sounds in your head.

 

Anyway, at the point I left, I believe the the only major (and it's a really major) problem to solve was destructable 3D terrain for the battlescape. This wasn't helped by the fact that there was no art department to help with building the terrain models. At any rate, I've been thinking about the problem and I think I've got a potential solution. Namely, stealing the Cube 2 Sauerbraten engine.

The advantages are:

1. It's a deformable 3D terrain that can be changed on the fly.

2. There's a good number of levels (battlescapes) aready for it.

3. It comes to tools that make it easy for people to build their own battlescapes. (So there's no need for a dedicated art department.)

 

What do you think?

Link to comment
Share on other sites

First of all, welcome back david! It's good to see your name around these parts ^_^

 

Was at least the writing experience worth it? :P

IIRC you were also working on a space game, right? What happened with that?

 

Concerning the cube 2 engine, you mean you'd like to make an engine switch, or just use/port the code part that would fit your needs? Judging from the advantages you mention, I guess you mean the first one.

 

That's very good news because the advantages you mention are really worth it, and in addition it will once again add Xenocide in the FOSS universe (and will also bring it closer to the open source community).

 

vote++ from me to free software :)

Link to comment
Share on other sites

It is an interesting idea, and I was always vote pro Open Source - but... and now comes the big BUT: Is it really wise to again switch development platforms? I mean, we can be glad that one ore two developers are interested in helping out, is it wise to scare them off? Then the really important question arises: how much work will it be to port the source? Can you do it on your own?

It will definitely improve our stand if users will be able to easily generate content/maps. However, as I see it, Cube 2 is an engine mostly aimed on First person shooters - can it really develop the same quality the XNA engine is creating right now?

Link to comment
Share on other sites

Was at least the writing experience worth it? :P
Shrug, it was an interesting learning exercise. I still have the urge to write more. But every time I do I just go lie down until the urge passes. If you're interested, I can send you a link to some of my work. :)

 

IIRC you were also working on a space game, right? What happened with that?
Didn't really work out, the other team was serously disorganised.

 

Concerning the cube 2 engine, you mean you'd like to make an engine switch, or just use/port the code part that would fit your needs? Judging from the advantages you mention, I guess you mean the first one.
Nope, I mean the second, port the engine to XNA, for use in the battlescape. Although I'm not sure how much work that would require. (Was kind of hoping other people here would have some idea, probably a better question to post to the Cube2 people.) Edit, I was also hoping you guys had some experience playing with the Cube 2 engine, so could give me your opinions if you thought it was up to the job. Edited by dteviot
Link to comment
Share on other sites

Nope, I mean the second, port the engine to XNA, for use in the battlescape. Although I'm not sure how much work that would require. (Was kind of hoping other people here would have some idea, probably a better question to post to the Cube2 people.) Edit, I was also hoping you guys had some experience playing with the Cube 2 engine, so could give me your opinions if you thought it was up to the job.

But if we convert an engine, that would be just to have the world editor? So why don't we use a world editor for xna? There are many engines you have to pay for which come with world editors (e.g. leadwerks - there is a Demo abialable for the leadwerk 3D World Studio. It is very easy to use in comparison to the following tools, but less powerful), but there are also some commercial products with free versions like the Autodesk Softimage Mod Tool (it is specifically designed for XNA games, requires registration, but is free (as in free beer)) or the Vue 7 (although I'm not sure how to export to XNA with this one, maybe only works with the pay options).

Edited by Mad
Link to comment
Share on other sites

I think ModTool was used in the C++ branch (probably to export the models).

 

Concerning Sauerbraten, it is a high quality engine. It is even used to develop an RPG game, Eisenstern. Thing is, it has static lighting and thus doesn't use destructible elements. Maybe by "deformable" you mean something different, so my bad.

 

I've been looking in the matter for the last hour and half, and I have two questions: Could you "emulate" destructible terrain/buildings by using heightmaps? Even "worse", what about voxelizing everything and then applying the needed effects on the voxels?

 

I also had another thought: Is DT such a progress blocker? Maybe the project would benefit more from a near-completed game. Once it is ready, we could look into DT again and see what can be done.

 

Btw, I always enjoy a good read, so share what you may dteviot, thanks :)

Edited by kafros
Link to comment
Share on other sites

Concerning Sauerbraten, it is a high quality engine. It is even used to develop an RPG game, Eisenstern.

Yes, I've seen those screenshots. That's why I asked if the quality would be the same as we could gain by using the XNA engine...

 

Edit: But I can

, why you would be interested in using Cube 2 - this really looks pretty easy... Maybe even I could do it... ;)

Then again, I have seen people without any GFX Background handling tools like the ModTool without any problems. But the experience level needed is definetly pretty low for Cube 2. But they are using the Sauerbraten libs. If you want to create new stuff, you have to use blender again.

 

Edit2: Another inconvenience just occurred to me: if we have two engines (XNA for Geoscape/Xnet/Baseview, Cube2 for Battlescape) we would also have to have all models in duplicate, right? Is there an easy way to convert them (ok, should be possible since our artists use(d) Blender, and so do the Cube 2 artists)?

But please don't get me wrong: I just want(ed) to provide some perspective and show some potential problems, if you, dteviot, still say "Cube2 is nevertheless the way to go" let's go Cube2. Guns blazing.

 

Edit3: Last question, and then I'll keep my mouth shut: Will Cube 2 allow us to have some randomness in the maps? Let me explain what I mean by that: UFO maps always were more or less random generated. It is obvious, that we won't be able to hold this up with a (nice) 3D terrain, although I've seen that David introduced a random map generator. But what we should and maybe could have is a random placement of the UFO - so that we have several maps and can place any UFO we want anywhere on the map. Alien starting points would be inside the UFO, thus depending on its type. There's the next problem: Can the "monsters" be randomized? As it looked in the Cube 2 tutorial you just make a fixated starting point for one monster (alien in our case). But we'll need different types of aliens depending on the UFO crew, plus different amount of aliens, depending on the difficulty level, plus different stats of the aliens (health/stamina) depending on the outcome of the crash.

Edited by Mad
Link to comment
Share on other sites

From what I understood, dteviot thought about PORTING any useful Cube2 source to XNA, so that our game could use it, specifically the terrain/world representation so that it would be easier to manipulate (and provide DT functionality).

 

It also seems he's more or less thinking about it himself, and unfortunately I can't provide much useful insight/advice...

 

Unless I understood something wrong.

Edited by kafros
Link to comment
Share on other sites

But if we convert an engine, that would be just to have the world editor? So why don't we use a world editor for xna?

Because we still need an engine to handle the battlescape terrain. True, we do have one in Xenocide already, but it's pretty minimal. (It was really just a bare bones effort, and it shows.)

Where Cube 2 comes in is I think it gives us a terrain engine and a map editor all in one.

 

Thing is, it has static lighting and thus doesn't use destructible elements. Maybe by "deformable" you mean something different, so my bad.
OK, maybe I was wrong, but as the map editor is also the game engine, it's possible to add/remove walls/floors/scenery and such at run time. To my mind, that's destructable.

 

I've been looking in the matter for the last hour and half, and I have two questions: Could you "emulate" destructible terrain/buildings by using heightmaps?
I don't think so, at least, not if we want to have maps with multi story buildings.

 

Even "worse", what about voxelizing everything and then applying the needed effects on the voxels?
I was under the impression that Cube2 was an octree based voxel engine.

 

I also had another thought: Is DT such a progress blocker? Maybe the project would benefit more from a near-completed game. Once it is ready, we could look into DT again and see what can be done.
Well, it's having a good terrain engine that's the progress blocker. I think all the other features are really pretty easy to do.

 

Btw, I always enjoy a good read, so share what you may dteviot, thanks :)
http://www.fictionpress.com/s/2709960/1/Ho..._Evil_Overlords

 

Edit: But I can
, why you would be interested in using Cube 2 - this really looks pretty easy... Maybe even I could do it... ;)

Then again, I have seen people without any GFX Background handling tools like the ModTool without any problems. But the experience level needed is definetly pretty low for Cube 2. But they are using the Sauerbraten libs. If you want to create new stuff, you have to use blender again.

Well, IIRC, you use blender to build creatures and props, The maps are built as done in the demo. (And I was thinking of something like X-Com2, where people could build little 20x20 modules, and then they randomly get joined up to make a map.

 

 

Edit2: Another inconvenience just occurred to me: if we have two engines (XNA for Geoscape/Xnet/Baseview, Cube2 for Battlescape) we would also have to have all models in duplicate, right? Is there an easy way to convert them (ok, should be possible since our artists use(d) Blender, and so do the Cube 2 artists)?

But please don't get me wrong: I just want(ed) to provide some perspective and show some potential problems, if you, dteviot, still say "Cube2 is nevertheless the way to go" let's go Cube2. Guns blazing.

Also, the code would still be XNA/C#, its just that I'd port the Cube2 octree engine to XNA/C# to handle rendering the battlescape terrain.

That is, I wouldn't be using all of the Cube2 engine. As regards models, duplicates would not be needed. It's just a matter of coverting the models at load time into XNA.

(That said, as none of the existing Xenocide models have animated sequences, using the Cube2's MD3 importer means we could use any MD3 (or MD2) models we can get our hands on. (And there's lots of them)

 

Anyway, I'm short of time at the moment, (Work's really busy) and I wanted to get other people's opinions:

E.g.

1. If you just grabbed Cube2, how easy is it for someone to mock up a map that looks like one of the existing base facility modules? Eg. The Baracks or the Lab?

2. Does the Cube2 engine support multi-level maps? (can we create multi story buildng maps?)

3. How big a map will the engine support before it gets slow? Can we have a 120 x 120 x 4 map, like an X-Com map?

 

From what I understood, dteviot thought about PORTING any useful Cube2 source to XNA, so that our game could use it, specifically the terrain/world representation so that it would be easier to manipulate (and provide DT functionality).
That's exactly what I was thinking.
Link to comment
Share on other sites

Thanks for the clarifications. I must say, if you really would be able to port Cube2 to XNA - in a reasonable amount of time (and I think that is now the key element, because otherwise you (and your team - if you can mobilize some people) will just get frustrated over the task), Cube 2 sounds more and more like a good idea.

 

Anyway, I'm short of time at the moment, (Work's really busy) and I wanted to get other people's opinions:

E.g.

1. If you just grabbed Cube2, how easy is it for someone to mock up a map that looks like one of the existing base facility modules? Eg. The Baracks or the Lab?

2. Does the Cube2 engine support multi-level maps? (can we create multi story buildng maps?)

3. How big a map will the engine support before it gets slow? Can we have a 120 x 120 x 4 map, like an X-Com map?

1) I guess it should take someone with dedication about 4-5 hours, maybe less - depending on the detail. But we do have the models already, couldn't we import them? Otherwise it would be a shame.

2) Multi Story buildings should not be a problem.

3) I didn't do a thorough check, but judging from the sheer size of the default map, the possibilities to extend maps to unbelievable sizes (using mapenlarge), the speed of the engine on said (but admittedly empty) maps, and the screenshots on http://eisenstern.com/ I wouldn't say size is/will be our foremost problem. Maximum Mapsize seems to be 512x512(x512?) (however, this is what I took from the edit mode information. The wiki says "Creates a new map of size^2 cubes (on the smallest grid size). 10 is a small map, 15 is a large map but it goes up to 20." - This would be only 400 cubes, so there is something wrong here...

Edited by Mad
Link to comment
Share on other sites

I was under the impression that Cube2 was an octree based voxel engine.

Hmmm...

 

http://cubeengine.com/forum.php4?action=di...&start=1551

 

Look from post "#1564: sparse voxel octree" to the end of the thread. Specifically:

 

  An octree in sauer is composed by vertexes making triangles, with textures.

You can see in this picture that the upper-left cube division has 3 different textures on each side.

 

An octree just divides a cubic volume of geometry in 8 smaller cubes. It doesn't really matter if it's voxels or triangles, right?

 

1. If you just grabbed Cube2, how easy is it for someone to mock up a map that looks like one of the existing base facility modules? Eg. The Barracks or the Lab?

Map editing seems to be really simple, and it is done in-game.

 

2. Does the Cube2 engine support multi-level maps? (can we create multi story buildng maps?)

Multi-level? You mean a map transition to another map?

Because if you just mean having stairs to upper floors,

.

 

3. How big a map will the engine support before it gets slow? Can we have a 120 x 120 x 4 map, like an X-Com map?

http://www.youtube.com/watch?v=YGu_wrgFj58

 

I guess it could easily handle even bigger maps.

 

-=-=-=-=-=-=-=-=-=-=-=-

 

At first I thought we would have issues with in-game objects, but I guess we could create custom entities. Thus, model objects (e.g. microscope) could be converted to an entity and added to a map.

 

Does UFO:AI have randomly generated maps? I played the July build during the summer, and I think it just used pre-determined maps. They still haven't added alien/x-corps base missions.

 

So, what will WE do with base missions? Cube 2 maps are in a sauerbraten-specific format. So, facilities/modules will be small cube2 maps which will be integrated together in bigger maps during battles?

 

Conclusion: Won't it be a whole lot of work? Maybe, instead of sticking to sauerbraten maps, just use the code ideas that fit your needs and find other means of integrating our current assets?

 

-=-=-=-=-=-=-=-=-=-=-=-

 

If the current facilities form such a lot of problems, maybe we should think of "scraping" them for now. I mean, it would be better to find a means of easily creating battlescapes. If, in said battlescapes, open source models (md*) can be added and test facilities can be assembled, then we can salvage any facility objects we can and find a way to add them to the battlescape.

 

Just a wild thought......

Link to comment
Share on other sites

If the current facilities form such a lot of problems, maybe we should think of "scraping" them for now. I mean, it would be better to find a means of easily creating battlescapes. If, in said battlescapes, open source models (md*) can be added and test facilities can be assembled, then we can salvage any facility objects we can and find a way to add them to the battlescape.

 

Just a wild thought......

A little too wild for me. There has been a lot of work invested in these models (an I mean really a lot of work). What we could do is really re-build the facilities in Cube 2 - but that would be a shame, and a lot of work - and still use the high-res models for Xnet and Baseview, until we have found a way to integrate our 3D models into Cube 2...

Link to comment
Share on other sites

An octree just divides a cubic volume of geometry in 8 smaller cubes. It doesn't really matter if it's voxels or triangles, right?
Correct.

 

Map editing seems to be really simple, and it is done in-game.
Exactly, which is why I thought the terrain can be destructable. (Just use the edit features to remove the walls/floors that are destroyed.)

 

Multi-level? You mean a map transition to another map?

Because if you just mean having stairs to upper floors,

.
Actually, I meant, are the maps truely 3D (e.g. Quake) or do they just seem 3D (i.e. They're really 2D, with a hight map, e.g. Doom)

 

Does UFO:AI have randomly generated maps?
I don't know.

 

So, what will WE do with base missions? Cube 2 maps are in a sauerbraten-specific format. So, facilities/modules will be small cube2 maps which will be integrated together in bigger maps during battles?
That was my thought. And we do something similar for any other battlescapes.

 

Conclusion: Won't it be a whole lot of work? Maybe, instead of sticking to sauerbraten maps, just use the code ideas that fit your needs and find other means of integrating our current assets?
The problem is our existing facility model assets don't work very well for the battlescape.

  • There's only a handful of facilities. (I think 6)
  • They're not laid out on a uniform grid, so trying to add a movement grid underneath the model is hard.
  • They're not uniform in size between models, so you can't join them together to make a bigger base, the entrances and exits (not to mention the sizes) don't line up.
  • They're not destructable.

One last question: can you make it so that it will / will it be possible to / does Cube 2 support fog of war / line of sight / visibility? Otherwise we could have some gameplay issues at our hands.
I'm pretty sure I can do it for the visibility of aliens. Having it for the terrain itself may be more difficult. (I've got to download the code and get my head around it.)
Link to comment
Share on other sites

Actually, I meant, are the maps truely 3D (e.g. Quake) or do they just seem 3D (i.e. They're really 2D, with a hight map, e.g. Doom)

So I guess I can answer that with enough confidence: they are real 3D maps.

Link to comment
Share on other sites

  • 3 weeks later...
Glad to see some progress has been happening again. Has there been any more discusion this these posts about the battlescape engine?

Have a look over here, and, not really concerning the battlescape, but might also be interesting for you here.

Link to comment
Share on other sites

Conclusion: Won't it be a whole lot of work? Maybe, instead of sticking to sauerbraten maps, just use the code ideas that fit your needs and find other means of integrating our current assets?
The problem is our existing facility model assets don't work very well for the battlescape.

  • There's only a handful of facilities. (I think 6)
  • They're not laid out on a uniform grid, so trying to add a movement grid underneath the model is hard.
  • They're not uniform in size between models, so you can't join them together to make a bigger base, the entrances and exits (not to mention the sizes) don't line up.
  • They're not destructable.

 

Sorry fot he late reply to this part of your post, but the answers just occurred to me.

  • (Un?)fortunately we have much more, at least according to the AWD progress sheet. It seems almost all models are done, we would "just" need textures for them.
  • This is probably the most difficult point. I don't know how this works, but couldn't we just use a universal grid "floor" which we put under every map, and it will apply to anything above it? Would it be a problem if the models don't fit 100%? I mean, do we really need to have e.g. a door at the border of two tiles?
  • I just was wondering, would it be a big sacrifice to the original idea of the game to introduce corridors? That at least would remove the need for a line-up of exits. Of course this doesn't change the validity of your points. As for the size, wouldn't correcting this be a pretty small task for a 3D artist?
  • bummer. That's bad. :(

 

Don't get me wrong, I think cube2 is a good idea, I just think it would be great if we could keep the maximum amount of assets we already have. So optimally, it would be possible to "just" import the facilities as models into a cube2 map. Then I guess it would be relatively easy to take an existing base design and automatically port it to cube2 map - if we use corridors, this should be doable with relative ease. But of course the bases wouldn't be destructible.

Edited by Mad
Link to comment
Share on other sites

[*]This is probably the most difficult point. I don't know how this works, but couldn't we just use a universal grid "floor" which we put under every map, and it will apply to anything above it? Would it be a problem if the models don't fit 100%? I mean, do we really need to have e.g. a door at the border of two tiles?
I assume you mean build an invisible movement grid under the 3D model, and have the game use the grid. That's what I attempted to do for the barracks model. (seel post http://www.xcomufo.com/forums/index.php?sh...&p=175128.) The problem is, when the 3D model isn't laid out on a meter square gird, there are places where the model and grid don't match. So you wind up with places where the soldiers and aliens can't go (but it looks like they should be able to), and other places where they can go, but shouldn't (because they're in a wall.

 

I just was wondering, would it be a big sacrifice to the original idea of the game to introduce corridors? That at least would remove the need for a line-up of exits.
I assume you mean corridors between the facility models. That's probably doable.

 

As for the size, wouldn't correcting this be a pretty small task for a 3D artist?
I don't know. We'd need to ask the artist (which we don't have.) Edited by dteviot
minor correction
Link to comment
Share on other sites

[*]This is probably the most difficult point. I don't know how this works, but couldn't we just use a universal grid "floor" which we put under every map, and it will apply to anything above it? Would it be a problem if the models don't fit 100%? I mean, do we really need to have e.g. a door at the border of two tiles?
I assume you mean build an invisible movement grid under the 3D model, and have the game use the grid. That's what I attempted to do for the barracks model. (seel post http://www.xcomufo.com/forums/index.php?sh...&p=175128.) The problem is, when the 3D model isn't laid out on a meter square gird, there are places where the model and grid don't match. So you wind up with places where the soldiers and aliens can't go (but it looks like they should be able to), and other places where they can go, but shouldn't (because they're in a wall.

Yes, that's what I meant. I see the problem. I thought clipping would be independent from the grid and dependent on the model, but apparently it is not. Sorry for that.

Edit: Stupid question: wouldn't it be a possible solution to create a movement grid with a very small grid size? (basically as a variation of your first post in this thread: "Alternate thought, could we use quadtrees to hold the tiles, and have variable sized tiles?") In this case a unit would move 5 or 10 (or 100) squares from the view of the engine, but that movement would be interpreted for the player/TU-wise as just one step (or we completely remove a player-visible grid and the cursor is "freely" placeable within the confinements of the underlying fine grid). If we choose to keep the visible grid and the result of a movement is not divisible by the "grid factor" we have several options: either use only a fraction of the TU, or, round up or down to the next fully divisible square number. Of course this introduces some inaccuracy in the TU management, but I wonder if this would really be a big problem - especially if we use option no.1.

If you have a very small grid, you still have areas where you can't go or areas where you shouldn't be able to go, but they are so small, that the player won't realize it.

I just was wondering, would it be a big sacrifice to the original idea of the game to introduce corridors? That at least would remove the need for a line-up of exits.
I assume you mean corridors between the facility models. That's probably doable.

Yes, I meant between the models. But if problem no.1 is not solvable, well, no much use in having corridors I guess.

As for the size, wouldn't correcting this be a pretty small task for a 3D artist?
I don't know. We'd need to ask the artist (which we don't have.)

Well, we do have Darkhomb lurking around. Maybe he knows something? Darkhomb?

Edited by Mad
Stupid question included :)
Link to comment
Share on other sites

Yes, that's what I meant. I see the problem. I thought clipping would be independent from the grid and dependent on the model, but apparently it is not. Sorry for that.

Edit: Stupid question: wouldn't it be a possible solution to create a movement grid with a very small grid size? (basically as a variation of your first post in this thread: "Alternate thought, could we use quadtrees to hold the tiles, and have variable sized tiles?")

Maybe. Really, what you want to do is generate the "movement grid" that describes the space for the gameplay engine from the 3D model. In an ideal world, it's done automatically (or better yet, the 3D model is used directly.) The other option is take the gamespace model, and generate the 3D view from it. Note that the Cube2 engine (Octree) is a way of efficiently storing a variable gird size. The next step along the path is a BSP tree (Quake), but they have problems with changing the terrain dynamically.
Link to comment
Share on other sites

Well, we do have Darkhomb lurking around. Maybe he knows something? Darkhomb?

 

Lucky, I have just installed a fresh copy of Photoshop CS4 and 3D Studio Max 2010. Resizing I should be able to do. I am more of a tweaker so don't expect me to rebuild these buildings as much as I would want to be able to.

Link to comment
Share on other sites

Don't know if anybody read about this: http://www.udk.com/ and http://developer.nvidia.com/object/udk.html

 

The Unreal 3 Engine is now freely available - the SDK includes a

Terrain building tool for placing and customizing vegetation, structures and countless in-game points of interest.

More features can be found here: http://www.udk.com/features.html

Edited by Mad
Link to comment
Share on other sites

The Unreal 3 Engine is now freely available - the SDK includes a
Terrain building tool for placing and customizing vegetation, structures and countless in-game points of interest.

I didn't know the Unreal 3 engine was available. But I did know the Quake 2 and Quake 3 engines were. (Along with considerable high quality documentation.) The issue is both Quake and Unreal are BSP tree based engines, so they don't support on the fly terrain changes.
Link to comment
Share on other sites

The Unreal 3 Engine is now freely available - the SDK includes a
Terrain building tool for placing and customizing vegetation, structures and countless in-game points of interest.

I didn't know the Unreal 3 engine was available. But I did know the Quake 2 and Quake 3 engines were. (Along with considerable high quality documentation.) The issue is both Quake and Unreal are BSP tree based engines, so they don't support on the fly terrain changes.

Yes, I know that, that's the beauty of U3 Engine - if I got that correct, it should support on-the fly terrain changes.

Link to comment
Share on other sites

Yes, I know that, that's the beauty of U3 Engine - if I got that correct, it should support on-the fly terrain changes.
I must have miss read it, but my take on http://www.udk.com/features-terrain.html was:

1. They're talking about the editing tool allowing the terrain height to be modified, not during the game itself,

2. This is essentially a 2D terrain, where the height of any position is settable. (e.g. Doom 1, or RTS type "terrain".

 

Feel free to point out where I am mistaken.

Link to comment
Share on other sites

I got the same feeling. You just have a lot of features while building the terrain in the editor. After that, you can't change it in-game.

 

Btw, I did some more more google-ing, and I've found these:

 

Delta3D open source engine

Dynamic Level of Detail Terrain Rendering with B?zier Patches

Terrain Morphing

Terrain creation basics

 

Maybe Delta3D's source code is probably worth a look. Does any of those links help? :unsure:

Edited by kafros
Link to comment
Share on other sites

I know UE3 supports quite a bit in terms of destructible environments (http://www.udk.com/features-destructible.html), but it all depends on what we need it for. Are we looking for destructible buildings and structures (which I believe it should do) or deformable terrain (cratering, which I'm unsure of)?

 

While I love the idea of working with XNA some more, and switching engines again could be a difficult move, I have to wonder if more developers could be attracted to this project by using UE3. I would imagine plenty of people interested in the games industry might be more willing to participate if they knew their experience with the project could directly translate into useful skills (as UE3 is the most popular engine used these days). That's not to say that the skills developed by working on the existing incarnation are worthless, but rather that UE3 might be a more worthwhile investment for those seeking a game development position.

Edited by rversaw
Link to comment
Share on other sites

×
×
  • Create New...