Jump to content
XCOMUFO & Xenocide

Xna 0.5


dteviot

Recommended Posts

Time for another brain dump.

 

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

    [*]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

    [*]Reactions

    [*]Bleeding out of wounded soldiers.

    [*]Medkit healing

    [*]Recovery of stun damage

    [*]Explosions

    [*]Grenades

    [*]Rest of actions that items are capable of.

    • Psi attacks
    • Psi probe
    • Scan
    • Hit
    • 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

    [*]Sound

    [*]Minimap

    [*]The ToDo list: (http://svn.projectxenocide.com/xenocide/xna/trunk/docs/ToDoList.html)

I've almost certainly missed items, so please add anything you can think of.

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

Summary of "Destructible Terrain"

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.com/forums/index.php?sh...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.

    Note, I'm not sure if this will complicate or simplify up/down path finding and line of sight.

    [*]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.)

Final note.

My thought on the e-mail to the Silent Storm people was something along the lines of:

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.

(and then attach the above notes on Destructible terrain)

Edited by dteviot
Link to comment
Share on other sites

This is a huge agenda. If this is only for xna 0.5 I am not entirely sure if you should add any more even if you "missed" something.

But I guess this is your agenda until v1.

 

For v0.5 this sounds like a good plan:

 

    * 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

 

However, since you will be working on destructible terrain anyway, it might be worth adding

    *Fog of war: No information to player on terrain that hasn't been seen yet

and maybe even

    *Night missions.

to the list. I don't know how big the effort will be, but, to introduce new features gameplay wise, it might be nice to have explosions and grenades in 0.5 as well.

 

Question: what is with sfx? Is everything for this already implemented and we are just lacking the necessary sounds, or would this require a lot of work? Same goes for Battlescape music.

 

Something which is missing on the main list would be the Aeroscape, although this might go under "Aesthetically pleasing UI".

Link to comment
Share on other sites

Question: what is with sfx? Is everything for this already implemented and we are just lacking the necessary sounds, or would this require a lot of work? Same goes for Battlescape music.

 

Something which is missing on the main list would be the Aeroscape, although this might go under "Aesthetically pleasing UI".

 

Battlescape music is easy, we just need to figure out what songs we want for battlescape and drop them in a directory. Also do we want just music playing randomly do we want to change the music during ai turn etc, do we have different music for terror and base attacks.

 

As for sound effects, we prob need a little more, there are alot of sound effects and there really isnt a list for which is what just 001, 002, (looking at the svn only) will have to browse the sound threads for more of that. But basicly we will need a little procedure that checks what is going on, walking, fireing (firing what weapon) droping down, spotted someone, dieing, injured, what is being used (male, female, alien, tank) and play the exact sound.

Link to comment
Share on other sites

This is a huge agenda. If this is only for xna 0.5 I am not entirely sure if you should add any more even if you "missed" something.

But I guess this is your agenda until v1.

correct

 

For v0.5 this sounds like a good plan:

    * 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

That's probably optimistic if we plan on 0.5 in two months.

I suspect the terrain by itself will take at least that long.

However, other people (if there are any) could work on the civilians and reactions.

 

However, since you will be working on destructible terrain anyway, it might be worth adding

    *Fog of war: No information to player on terrain that hasn't been seen yet

Depending on how terrain is implemented, that might just fall out, with maybe a days extra work.

 

and maybe even

    *Night missions.

That I'm not so sure about, handling 10s of lights is something I've yet to figure out. (My current idea is have a bitmap that indicates the light level at each cell, then do a texture lookup in the vertex shaders to determine the light level.) Unfortunately, I believe this will require Shader 3.0.

 

to the list. I don't know how big the effort will be, but, to introduce new features gameplay wise, it might be nice to have explosions and grenades in 0.5 as well.

Again, these could be done by someone else.

 

Something which is missing on the main list would be the Aeroscape, although this might go under "Aesthetically pleasing UI".

truth. Again, something someone else can do.

 

As for sound effects, we prob need a little more, there are alot of sound effects and there really isnt a list for which is what just 001, 002, (looking at the svn only) will have to browse the sound threads for more of that. But basicly we will need a little procedure that checks what is going on, walking, fireing (firing what weapon) droping down, spotted someone, dieing, injured, what is being used (male, female, alien, tank) and play the exact sound.

Well, for actions, I've added an attribute to each action in item.xml, so that you can put the name of a sound effect there.

We should probably do something similar to combatants. Add a sound element, with the names of the different sounds for different effects. e.g. Getting hit, killed, moving, etc. Given a list of the sounds, I can probably whip up a schema in a few hours. Heck, I can figure out the basics in 15 minutes, then it's just a matter of plugging in a list of all the sound types we want. I'll post it up tomorrow.

Link to comment
Share on other sites

Sounds good, but also there are different effects for each type of alien/person and multiple sound effects for the same thing, dying 3 different ways, soft foot steps, hard footsteps, metal footsteps.

Multiple sound effects isn't a problem. Although I should note that at the current time the rules engine doesn't have any information on type of surface being walked on.

Anyway basic xml would look something like this (per combatant in combatant.xml)

<sounds>
<sound id="PlasmaDeath" filename="content/audio/sound/battlescape/alien/grey/boilingWater.ogg"
<sound id="PlasmaDeath" filename="content/audio/sound/kitchen/popcorn.ogg"
<sound id="LaserDeath"   filename="content/audio/sound/kitchen/fryingbacon.ogg"
</sounds>

So, we just need to define what the set of IDs are (because they're going to need to be defined as an enumeration, to minimize errors.)

If an ID appears multiple times, then we just pick a random sound.

I should also point out that, at current time, the rules engine doesn't track the type of attack that killed anyone. (Although it does note who did the killing.)

Link to comment
Share on other sites

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.

It is true that all of them are related somehow, however there is a bigger relationship between FOW and Night Mission than with those 2 with Destructable terrain. However, it is not true that the facility models approach is not viable; in fact, you will see that it is exactly the way to go. I will try to elaborate further to give an ideo on how that should be implemented.

 

First, why are they related? Because both FOW and Night Mission share the very same root, discovering when to show something and to some degree on how much detail; that means it is a visibility problem. Furthermore, lets suppose that the visibility is taken care, both too have a shading component. Basically deciding how to calculate the surface color (or the pixel color to be true in this case :) ).

 

In the case of FOW you have a very simple formula:

If there is someone arround you fully see entities and terrain/objects (this is a discrete problem solved by the game engine)
else if you have been there already but are outside you have to show only terrain/objects
else you shade in black :)

So think FOW as a mask in the shading process if the pixel gets projected into the mask (a ray from the eye collides with the mask before hitting an object) -- this goes inside a pixel shader btw -- then you shade in black. To make things more interesting the mask threadhold can be shaded differently for "aestetical reasons" if required. But nothing prevents you to know that when shading.

 

On the other hand, the entity visibility is just an drawing level problem, if the entity is inside a specified radius then it is drawn; otherwise it is not. Simple as that. So the only difference is wether you push something to be drawn or not based on a certain rule.

 

Destructable Terrain is more a vertex/object problem that later has to be shaded using those very same techniqs using FOW and Night Missions (BTW Night Vision is just a change in the lighting equation only --- pixel shader again and some extra operations on the vertex)

 

Some information on lighting equations and shaders:

http://www.slideshare.net/mobius.cn/advanc...r-meltdown-2005

A survey on lighting techniqs: (check the latest slides)

http://www.slideshare.net/wuzziwug/renderi...-in-video-games

 

Another way to do rendering (lighting):

http://en.wikipedia.org/wiki/Deferred_shading

http://www.talula.demon.co.uk/DeferredShading.pdf

 

And this is STATE OF THE ART:

http://www.iit.bme.hu/~szirmay/gpugi_link.htm

 

For destruction of models you can take a look at this:

http://creators.xna.com/Headlines/developm...01/Shatter.aspx

 

If you can mark some triangles to use this effect you have instant destruction of elements :)... better effects though are obtained with this on volumes though.

Link to comment
Share on other sites

First, why are they related? Because both FOW and Night Mission share the very same root, discovering when to show something and to some degree on how much detail; that means it is a visibility problem. Furthermore, lets suppose that the visibility is taken care, both too have a shading component. Basically deciding how to calculate the surface color (or the pixel color to be true in this case :) ).

It's the visibility that's the hard part.

Well, not exactly. The rules engine handles the visibility OK, it's transforming the visibility information so that the graphics engine can use it.

In the case of FOW you have a very simple formula:

If there is someone arround you fully see entities and terrain/objects (this is a discrete problem solved by the game engine)
else if you have been there already but are outside you have to show only terrain/objects
else you shade in black :)

Actually, you don't want to shade in black. You clear the screen to black, and then don't draw the polys.

Which I think we can do by setting alpha to 0 and alpha thresholding to 0, so that pixel isn't even rendered. Otherwise you get problems with transparent pixels being rendered to the Z-buffer.

So think FOW as a mask in the shading process if the pixel gets projected into the mask (a ray from the eye collides with the mask before hitting an object) -- this goes inside a pixel shader btw -- then you shade in black. To make things more interesting the mask threadhold can be shaded differently for "aestetical reasons" if required. But nothing prevents you to know that when shading.

 

On the other hand, the entity visibility is just an drawing level problem, if the entity is inside a specified radius then it is drawn; otherwise it is not. Simple as that. So the only difference is if you push something to be drawn or not based on a certain rule.

I'm assuming by entity you mean an alien, civilian, (or eventually) an item dropped on the terrain. Yes, they're not a problem because they're discrete models. And it's not just specified radius to determine visibility, because walls block line of sight.

 

BTW Night Vision is just a change in the lighting equation only --- pixel shader again and some extra operations on the vertex)

Not exactly. lighting calculations also need to take into account the fact that walls can block light.

I did have a bit of an idea how light might be handled earlier in this thread.

 

My current idea is have a bitmap that indicates the light level at each cell, then do a texture lookup in the vertex shaders to determine the light level. Unfortunately, I believe this will require Shader 3.0.

And I suddenly realize it might be possible to do much the same thing for destroyed parts of the model. Maybe.

Basic idea is again, have a bitmap indicating the condition of each cell. Then in vertex shader, it's easy to convert the vertex's co-ordinates into a cell, and from a cell, the relevant textel in the bitmap. And if bit indicates cell is trashed, draw the vertex as transparent. I do see one problem. How to distingush between different parts of the cell being trashed. e.g. A wall being destroyed, but the floor being present, or vice versa.

Edited by dteviot
Link to comment
Share on other sites

Actually, you don't want to shade in black. You clear the screen to black, and then don't draw the polys.

Which I think we can do by setting alpha to 0 and alpha thresholding to 0, so that pixel isn't even rendered. Otherwise you get problems with transparent pixels being rendered to the Z-buffer.

In current hardware believe me that it is better to just draw black than do not draw (doing a discard) :) ... the idea is that the multiple framebuffers do not render the image but attributes (enabled by MRT - Multiple Render Targets) and those are composed at the end. Deferred shading powerpoint I posted show that at the extreme as the extreme case is what deferred shading is. Now, if the visible part is just another attribute you are done, when composing you know what to do ;) ... Thats the reason that I say that in the extreme case rendering visibility is isomorph with the shading process. :)

 

Take a look at this 2 presentations in order:

http://www.gdconf.com/conference/archives/...tchard_matt.ppt

http://www.gdconf.com/conference/archives/...dreich_rich.ppt

 

Both shadowing, visibility and what I am talking about start to make sense ;) ...

 

If you can get GPU Gems 3 take special attention to the following articles:

Chapter 13: Volumetric Light Scattering as a Post-Process

Chapter 19: Deferred Shading in Tabula Rasa

Chapter 28: Practical Post-Process Depth of Field

Chapter 8: Summed-Area Variance Shadow Maps

 

And in particular, this one shows the solution to another nearly isomorph problem:

Chapter 30: Real-Time Simulation and Rendering of 3D Fluids

 

I'm assuming by entity you mean an alien, civilian, (or eventually) an item dropped on the terrain. Yes, they're not a problem because they're discrete models. And it's not just specified radius to determine visibility, because walls block line of sight.
There are better ways to do this in the CPU but I will show you how to convert a discrete visibility problem into a shading one just for the purpose of demostration.

 

Suppose that you have all geometry and draw in Black all static things and in a color based on an Unique ID all entities.

Now if you read back that image and find all distinct pixel you would get something like this: { 0, Id1, Id5, Id8 }

If you discard 0 that is all static geometry, you can now map all the Ids into an entity...

Now do the render with only the entities whose Ids match :) you are done... you have solved visibility

 

This problem is isomorph to shoot 1 ray per pixel in ray tracing ;). There are reasons while it is much faster to do on the CPU, but doesnt means it is not posible the other way arround. For some problems like FOW, shadows, etc it is much faster to do that on the shading process using the GPU than on CPU. That is why I separated a discrete problem with the rest ;)

 

Greetings

Red Knight

Link to comment
Share on other sites

I don't see how this helps.

Possibly because I don't know what isomorph means, I translate it as "single shape".

I grasp deferred shading. Do the geometry caclulations once, to a buffer. Then use the calculated results for lighting and rendering.

The hard part is "How do I pass the visibility information known to the game engine to the graphics engine?"

Link to comment
Share on other sites

Ok lets start with Isomorph (that is the simpliest one :) )...

In problem solving research (an area of Cognitive Psychology) an isomorph is a problem with an identical state space to another problem (e.g., Tower of Hanoi and Chinese Tea Ceremony). It literally means same structure or shape.
Formally that means that:

Given problem P and P' and S a solution to P then P and P' are Isomorph if there is a function F such that F(S) is a solution to P'.

 

In the example: if you have a solution of P (in this case rendering visibility in shading) you have also a mapping that allows you to solve P' (discrete visibility)

 

About Deffered Shading, even though you are correct about the procedural the concept goes far beyond than that. For example, most shadowing algorithms requires you to render from the light source or create extruded geometry from the light source. In deferred shading, your geometry from the eye solves the visibility problem because from that you can know if something is seen or not; now the point is: do the engine must know about it??? is the visibility required for a "shading purpose" or for a game rule?

 

Trying to answer those questions even if vaguely will give you a couple of hints. Like for instance for "visibility" to know if someone is inside the area (discrete problem) where it should be seen is different from the visibility if the alien even if seen is under a smoke curtain. The degree of detail needed for one problem is orders of magnitude smaller than the other. With a bounding box for each element and a simple ray tracing approach you are almost done for the 20 units you care about. (Even though doing it in the CPU is similar at how it could be done on the GPU). On the other side, the other is a shading problem where far more detail is needed (to the pixel level).

 

So in short how would I do it?

Use a gross aproximation for the entities (knowing if an entity should be seen game rule based... radius or ray shooting, more complex are posible but for most purposes that is almost enough). 
Select active entities to render. (everybody seen and inside the FOW)
Create a alpha style texture with the FOW (very simple to do) -> as if you are looking from the top 
Render ( Terrain, Entities ); -> remember to pass the new FOW texture

 

Now on the Shading part:

 

Render using the method prefered (direct or deferred)...
Postprocess the rendered image darkening or desaturating colors where in the dark FOW. (Substractive filter or Desaturate Filter)

 

Done :)

 

Why did I mention deferred rendering? Because the post processing step requires most of the typical information that is generated in a Deferred Shading Renderer so you are doing the work anyways. The idea is that the rendering do not encode colors but properties of the pixel (Depth, Color, even things like FOW :) ). It is sorta complex at first but after some times it makes sense... or at least I am trying to explain it in such a way that it makes sense. Did it makes sense?

 

Greetings

Red Knight

Link to comment
Share on other sites

It is sorta complex at first but after some times it makes sense... or at least I am trying to explain it in such a way that it makes sense. Did it makes sense?

Perhaps. I'll go through it and say what I understood.

  • isomorph means two problems are really the same problem, just described differently
  • discrete visibility Determine which parts of the geometry are visible and which are not. It's not clear if visibility means "drawn on the display" or "according to the rules of the game, is visible to a unit owned by the player."
  • For example, most shadowing algorithms requires you to render from the light source or create extruded geometry from the light source.
    That sounds reasonable sense. Note, I don't know anything about shadowing.

In deferred shading, your geometry from the eye solves the visibility problem because from that you can know if something is seen or not; now the point is: do the engine must know about it??? is the visibility required for a "shading purpose" or for a game rule?

You've completely lost me. What visibility problem? Do you mean Discrete Visibility? In which case, what does this have to do with shadowing? I'm guessing you've shifted topics and are talking about knowing if terrain/objects are visible to the player.

And what I think you've been saying is that "deferred rendering solves the discrete visibility problem by including information on the visibility of each pixel along with the rest of the information (normal, albedo, etc.) that is written for use during the lighting passes."

Create an alpha style texture with the FOW (very simple to do) -> as if you are looking from the top

How does this differ from my previous suggestion?

Construct a bitmap where each pixel corresponds to a cell in the battlescape, and the colour of the pixel corresponds to the state of the cell. E.g.

Red == 0 is cell has not been seen, ever.

0.0

Alpha == 0 cell has been destroyed by weapons fire

Alpha == 1.0 cell is intact

 

(This is equivalent to your FOW alpha texture)

 

Then in vertex shader, figure out which cell the vertex is in, and look up the corresponding light level and destruction values, then pass this onto the pixel shader which uses this when texturing the geometry.

 

(Equivalent to your post process step, which can be rolled into the render step)

 

Note, this assumes that vertices are sufficiently closely spaced that there are no polygons that span more than one cell.

Also, (as I said before) destruction of cells is slightly more difficult, as I'm not sure how to distinguish between destroyed floor and wall vertices.

I guess what this says is, FOW and Night are easy. Destructible terrain is hard. Which is something I also said before. If we can solve destructible, FOW and night are probably trivial modifications of the destructible solution.

So, we need to focus on a solution for destructible.

Link to comment
Share on other sites

How does this differ from my previous suggestion?

Construct a bitmap where each pixel corresponds to a cell in the battlescape, and the colour of the pixel corresponds to the state of the cell. E.g.

Red == 0 is cell has not been seen, ever.

0.0

Alpha == 0 cell has been destroyed by weapons fire

Alpha == 1.0 cell is intact

 

(This is equivalent to your FOW alpha texture)

 

Then in vertex shader, figure out which cell the vertex is in, and look up the corresponding light level and destruction values, then pass this onto the pixel shader which uses this when texturing the geometry.

I think we are mixing stuff so that it got complicated; indeed a FOW texture is an encoding of that information. However you mix cell state for destruction, something that is very geometry oriented, with FOW which is pixel oriented.

 

I guess what this says is, FOW and Night are easy. Destructible terrain is hard. Which is something I also said before. If we can solve destructible, FOW and night are probably trivial modifications of the destructible solution.

So, we need to focus on a solution for destructible.

What I argue here is that "destructible" in fact spawn multiple stages of destructability. Cell destructability is a discrete simplificable problem for things such as Fire, Smoke, Game Rules, etc. While it is not from a shading point of view, for example Fire+Smoke do have a visual representation that requires a volumetric definition and others that do not (SuperParticles/Voxelization/Etc against Impostors). With FOW with the creation of a FOW texture you are decoupling the real world state with the shading version of it (what you require to paint the pixels). You may not need that information per/se in the engine as long as you can generate it from the entities (units) position. Remember as a general rule of thumb, everything that can be calculated/derived from other information source is better to keep it that way; because if you have both states the posibility of inconsistencies is higher, with added complexity+more efficience problems. That is why I always say, create your world in such a way that the domain map as closely as posible to their intend. If you have entities that move in the world, first you need a world, and then the entities to move in it... Entities are discrete units, while the world can be a bunch of polygons or whatever representation you like, as long as you can respond easily and/or efficiently if I can move there or not :).

 

The point is that with Cell based objects you may be choosing (I may be wrong) a too restrictive model that you are going to pay later on. As long as your units know if they can move to a certain place or not that is enough. If you then want to restrict your world representation for the purposes of entity moving, it is up to you, but the domain model or the World is far more richer than that and choosing a path using those assumptions is plagued with unforseen risks at this moment. More if you think how the actual shading is done today. I would say, forget about destructable models now; concentrate in rendering all what you have and have a restricted gameplay where you can use the door to get it, and after that see how to destruct a house correctly cause the underlaying assumption continues being the same, either you can move there or you cannot. :)

 

Hope that makes sense.

 

About the visibility, to fix things up lets call "visibility" the discrete problem where one unit can "see" other unit and "pixel visibility" the shading problem.

 

Greetings

Red Knight

Link to comment
Share on other sites

I think we are mixing stuff so that it got complicated; indeed a FOW texture is an encoding of that information. However you mix cell state for destruction, something that is very geometry oriented, with FOW which is pixel oriented.

As I see it, FOW isn't just pixel orientated, it's rule oriented.

And they're tightly related, they're both properties of the terrain. Although it could be argued that destroyed terrain is terrain that has been changed to a state of "not there". They're differences of scale, but not kind. From the view of the game rules engine. From the render engine they're potentially very different animals.

(Note, I think mostly in terms of the rules engine.)

 

The point is that with Cell based objects you may be choosing (I may be wrong) a too restrictive model that you are going to pay later on. As long as your units know if they can move to a certain place or not that is enough. If you then want to restrict your world representation for the purposes of entity moving, it is up to you, but the domain model or the World is far more richer than that and choosing a path using those assumptions is plagued with unforseen risks at this moment.

If you've got a better alternative, please let me hear it. I've considered BSP trees, but they don't support large scale destructibility. And destructibility is a core requirement for Xenocide. (It will be the major point of differentiation between Xenocide and UFO:AI)

 

 

More if you think how the actual shading is done today. I would say, forget about destructable models now; concentrate in rendering all what you have and have a restricted gameplay where you can use the door to get it, and after that see how to destruct a house correctly cause the underlaying assumption continues being the same, either you can move there or you cannot. :)

My concern is we go down this route, the Art department produce a large number of terrain models (like the facilities) and then we find we can't make them destructible. This would require re-doing the models. If the artwork department is happy with this, then I have no problems with this track. After all, the work from my side is trivial. Although I will need help figuring out what's wrong with my code to calculate AABB for models. (hint.)

Link to comment
Share on other sites

I can finish up what ever currently outstanding facilities I have; but stop there; so we will still have some facilities done in the old way do be used in engine...
Link to comment
Share on other sites

The fracturing and destructability is doing procedurally, at least for big models (that is how it is done today) the artists just hints the engine where to "cut off" the elements. Or what an artist do is chop the model in parts if required (but that is something that you can do procedurally too on a Geometry build pass. That is why I say lets forget about it, and concentrate on that part.

 

Using BSP though is counterproductive as the entire terrain because a polygon soup model (in the extreme case). So it cannot handle properly (without too much work and many restrictions) models that change place.

 

Greetings

Red Knight

Link to comment
Share on other sites

The fracturing and destructability is doing procedurally, at least for big models (that is how it is done today) the artists just hints the engine where to "cut off" the elements. Or what an artist do is chop the model in parts if required (but that is something that you can do procedurally too on a Geometry build pass. That is why I say lets forget about it, and concentrate on that part.

 

Using BSP though is counterproductive as the entire terrain because a polygon soup model (in the extreme case). So it cannot handle properly (without too much work and many restrictions) models that change place.

 

Greetings

Red Knight

See this thread for response

Link to comment
Share on other sites

  • 2 weeks later...
The fracturing and destructability is doing procedurally, at least for big models (that is how it is done today) the artists just hints the engine where to "cut off" the elements. Or what an artist do is chop the model in parts if required (but that is something that you can do procedurally too on a Geometry build pass. That is why I say lets forget about it, and concentrate on that part.

 

Using BSP though is counterproductive as the entire terrain because a polygon soup model (in the extreme case). So it cannot handle properly (without too much work and many restrictions) models that change place.

 

Greetings

Red Knight

See this thread for response

Got GPU Gems 3 (from library) on Friday.

Chapter 1. Generating 3D terrain on the fly in the GPU. Unfortunately it needs shader 4. i.e. Direct X 10. Which I think means:

  • Vista needed.
  • XNA doen't support it.

Arrrhhhhhhhh!

 

Does OpenGL support shader 4? On XP?

Edited by dteviot
Link to comment
Share on other sites

http://en.wikipedia.org/wiki/Shader_model#...ramming_shaders

 

First of all, you just need windows Vista (XP won't fit, tough luck), and second you need a high end (game-oriented and usually expensive) graphics card that supports Shader Model 4.

Actually I just did a quick search, and you can get a SM 4.0 capable GPU for $200. Nevertheless, it will only help on windows Vista, so it's not doing any good

 

In addition, directX 10 and Shader model 4 are getting obsolete already due to DirectX 10.1 and shader model 4.1

 

Not even commercial games demand shader model 4... Hey, even Assasin's Creed and Jericho, which are masterpieces, use Shader Model 3... Crysis needs Shader Model 2 and only uses DirectX 10 IF AVAILABLE...

 

Soooo, in four words : Out of the question!!! Shader Model 4.0/4.1 goes TOO far... Demanding users to have Shader Model 4 is just an extreme overkill

 

 

 

p.s. Now that I re-read my post it seems to offensive/absolute, it was never my intention, sorry!

Edited by kafros
Link to comment
Share on other sites

Yes, OpenGL (edit: 2.0!!) does support SM 4.0, and yes, OpenGL is OS independent, the restriction of DirectX10 to Vista is (more or less) only to sell Vista... Plus, what good will it do? I mean, XNA does not support OpenGL, or am I wrong?

But, I think SM 4.x is really a bit overboard. There has to be another way!

Edited by Mad
Link to comment
Share on other sites

Ok, speaking with a firm step in the technical background I will do a couple of myth debunking just for the sake of it ;) ... you are reading too much slashdot ;)

 

First of all, you just need windows Vista (XP won't fit, tough luck), and second you need a high end (game-oriented and usually expensive) graphics card that supports Shader Model 4. Actually I just did a quick search, and you can get a SM 4.0 capable GPU for $200. Nevertheless, it will only help on windows Vista, so it's not doing any good
There is a really important reason why XP wont support DirectX 10 (SM4 is just how to say it... an unlucky bystander in that commercial war), to the point you have to reimplement the kernel of XP to support the features proposed by the DX10 spec (something that it doesnt make sense from the commercial standpoint). Such things are related to the Device Driver Model of XP that are plainly not posible to be done without a new DDM. SM4, as is, is not a DX10 thing, but they are very enhanced by the rest of the DirectX 10 spec (everything comes in one package). That is why OpenGL can provide that funtionality, because it puts the burden on the developers side instead of on the DX10 API/Driver developer. I can name the changes that make that simply not posible, but it doesnt makes sense, you can read about it from the blog of the DX10 team.

 

In addition, directX 10 and Shader model 4 are getting obsolete already due to DirectX 10.1 and shader model 4.1
Not entirely true... I would say as Tim Sweeny pointed out (something that I agree) that DirectX10 is the last API that will have an impact in the Realtime Graphics world ;) ... http://www.tomshardware.com/2008/03/11/tim..._graphics_api_/ ... Why?? well because with the GPUs being like a General Purpose Stream Processor, you can go an program your own API with a raster engine that fits your needs without ever bother with DirectX itself :) ... You want raytracing?? Go and program in CUDA the ray tracing engine and you are done :) ... The changes done to DX10.1 are not that big to call it "obsolete" either.

 

Not even commercial games demand shader model 4... Hey, even Assasin's Creed and Jericho, which are masterpieces, use Shader Model 3... Crysis needs Shader Model 2 and only uses DirectX 10 IF AVAILABLE...
Because they were not programmed with SM4 in mind and because they hadnt used the specific features of DX10 for compatibility sake. But after time passes DX10 will be used more an more games that really makes use of them, not because the feature set, but because of the flexibility it provides. Shader development today is hard, because of you have to seamlessly switch between multiple ways to do stuff (that will change when CUDA style APIs and that kind of stuff do really start to make a difference as they treat the GPU as an standard parallel processor)... DirectX11 maybe???

 

Soooo, in four words : Out of the question!!! Shader Model 4.0/4.1 goes TOO far... Demanding users to have Shader Model 4 is just an extreme overkill
I do agree for now :), but knowing the timeframes we manage, it is not that much in 2 years ;)... always remember computing is about tradeoffs, in this case easy of development against processor requirement.

 

Greetings

Red Knight

Link to comment
Share on other sites

Got GPU Gems 3 (from library) on Friday.

Chapter 1. Generating 3D terrain on the fly in the GPU. Unfortunately it needs shader 4. i.e. Direct X 10. Which I think means:

  • Vista needed.
  • XNA doen't support it.

Arrrhhhhhhhh!

Does OpenGL support shader 4? On XP?

Yes, big problem indeed. The problem there is that the 3D Terrain is created in the geometry shader something neither XNA or XP support. XNA by design, DirectX on XP by a driver issue. If you are really completely absolutely sure that you want to implement that and you are willing to sacrify the XBox360 support there are ways to implement that on XP (not Vista yet) using CUDA. However, that approach is more of a showoff than a REAL thing. They are showing that they can do Marching Cubes on the GPU ;) ... Until now I still dont understand why you want to generate the 3D Terrains on the fly, or better why not to simplify that using standard Stripping (SM1) on CPU to do the geometry generation (even Geometry Clipmaps would be enough, GPU Gems 2) on a Fractal bitmap. You can then select the place for the big objects using leveled "blueprints" (like putting the same value in the bitmap for a complete house so you get a levelled terrain to put the house in --- Try SimCity 4 to see that approach in action ;) ).

 

If you are willing to use SM2 you can even do the displacement on the GPU, several technics exist like the one for the water in GPU Gems 2. I think geometry clipmaps implement sort of that too.

 

Basically what you do it:

 

On Loading (CPU):

  • Create a fractal terrain.
  • If required by the rendering technic create the terrain geometry
  • Select where you are going to put BIG objects
  • For each BIG Object
    • Level the terrain bitmap using the BIG Object blueprint

On Rendering (CPU+GPU):

  • Render Terrain using any Displacement Technic (realtime or precalculated -- that was done On Generation --)
  • Render BIG Objects

Read my post about OpenGL stuff.

 

Greetings

Red Knight

Link to comment
Share on other sites

Yes, OpenGL (edit: 2.0!!) does support SM 4.0, and yes, OpenGL is OS independent, the restriction of DirectX10 to Vista is (more or less) only to sell Vista... Plus, what good will it do? I mean, XNA does not support OpenGL, or am I wrong?

But, I think SM 4.x is really a bit overboard. There has to be another way!

True, XNA doesn't support OpenGL. But let me digress for a moment.

The XNA branch was originally intended to be something of a Proof of Concept experiment, on how to structure the code. I had a serious disagreement with the other team members on how to do the Geoscape game logic. And I think I've proved I was right, or at least, my solution was viable. er. wandering off topic.

Anyway, I'm thinking that perhaps instead of calling this the XNA branch, it should really be called the C# branch. Reflecting the language used, not the library.

To expand, at the time the branch was started, I realized that XNA would not run on Linux, and that a possible solution would be to do the graphics using a different 3D library. Consequently, the branch's code has been structured into two pieces, Model and Graphics. Roughly corresponding to Model and View. (In case you're wondering where the Controller is, it's rolled into the View, mostly encoded into the state machine that shows the screens, and the logic done when the user interacts with the screens.)

The game logic lives in the model directory, and knows nothing about XNA or graphics. (Well, OK, it knows the XNA Vector2 and Vector3 classes, but those can be easily replaced.)

The 3D code lives in Graphics\Scenes, constitutes only a tiny part of the code, and would, I think, not be difficult to re-write using the C# open GL wrapper.

The UI code lives in Graphics\Screens, and again, if we can find a suitable GUI library, or even get CeGUI# working with OpenGL (it's mostly there).

 

My point, was that the C# branch was originally designed with the though that we might need to swap out the XNA library.

Edited by dteviot
Link to comment
Share on other sites

I knew about that, cause you resisted to use the Component approach that is heavily rooted on XNA, the point is that even though there are millions of way to do the same stuff at this moment there is no One Size Fits All Solution. On the other side, OGL is already showing its age in complexity so I doubt (and I am not saying it isnt possible) that there is any clear advantage to move in that direction. Sure SM4 is cool, but there is nothing that requires you to implement the functionality in it either. As I said, Chapter 1 in GPU Gems 3 is a showoff :) that may be posible to be done straight in XNA when we need it anyways. So I wouldnt bother too much about it either now. Going with a simple solution is the best tradeoff at this moment.

 

Greetings

Red Knight

Link to comment
Share on other sites

  • 3 weeks later...

Progress:

  • Revised Geoscape shader to make day/night transition more obvious.
  • Fixed bug: When placing access lift for new new base, can click outside the area of the base, so base lacks a lift.
  • Fixed bug: Opening sound options dialog no longer resets volume levels

Notes.

  • Hopefully now people won't think southern Europe is in darkness at 12.00 in the afternoon. That said, I'm still not happy with the geoscape shader, as the day/night terminator now looks artifical. What I did try (as suggested by GPU Gems), was instead of using a value of 1 for daylight, use the dot product of earth normal to sunlight to compensate for the bump.
    e.g. daylight = dot(mul(normalFromMap, tangentToWorld), sunAngle) / dot (modelNormal, sunAngle)
    Unfortunately, that didn't work.

Edited by dteviot
Link to comment
Share on other sites

  • 7 months later...

OK, I've had a quick look at XNA 3.0, and think for the moment I'm not going to use it.

Specifically because:

1) It requires .Net 3.5 framework (which is a 250 meg download.)

2) Installing Dev Studio 2008 express is problematic for me. (I don't have a broadband connection.)

Link to comment
Share on other sites

Guest Azrael Strife

I cannot seem to access the wiki, nor SVN via browser, can you provide the information to download the source code?

 

Thanks.

 

edit:

1) It requires .Net 3.5 framework (which is a 250 meg download.)

Actually, I might be mistaken, but you can target .NET 2.0, not limited to 3.5.

Edited by Azrael Strife
Link to comment
Share on other sites

I cannot seem to access the wiki, nor SVN via browser, can you provide the information to download the source code?

1. Download and install a SVN client.

2. Start client, and Download the code from http://svn.projectxenocide.com/xenocide/xna

 

Thanks.

 

edit:
1) It requires .Net 3.5 framework (which is a 250 meg download.)

Actually, I might be mistaken, but you can target .NET 2.0, not limited to 3.5.

You might be right, 3.5 might be needed to get VS 2008 to run, but not the output from VS 2008.

Link to comment
Share on other sites

Guest Azrael Strife
I cannot seem to access the wiki, nor SVN via browser, can you provide the information to download the source code?

1. Download and install a SVN client.

2. Start client, and Download the code from http://svn.projectxenocide.com/xenocide/xna

 

Thanks.

 

edit:
1) It requires .Net 3.5 framework (which is a 250 meg download.)

Actually, I might be mistaken, but you can target .NET 2.0, not limited to 3.5.

You might be right, 3.5 might be needed to get VS 2008 to run, but not the output from VS 2008.

Thank you David :)

Link to comment
Share on other sites

  • 2 weeks later...

So I might be a little late to the discussion, but I can't say I check this too often :(

 

VS2008 can create projects that target .NET 2.0, 3.0, or 3.5. This is because all three versions of the framework actually run on .NET 2.0, each newer version simply adds some new assemblies.

 

This isn't really related, but it could be for future users: If you want to see the quickest way to get the latest version of .NET, take a look here: http://www.hanselman.com/smallestdotnet/

 

Though I still don't have a lot of free time, I would love to see this project move forward to XNA 3.0. When I did spend some time working on this codebase, I was always sad that I had to use VS2005 and couldn't use any of the new C# 3.0 features (and had to keep multiple versions of VS installed). If it came down to it, I would be more than willing to burn a copy of the express edition disc and send it out, just to help this happen! Shipping to New Zealand could be a bit expensive, but if nothing else, I'm sure someone closer may be able to hook you up with a copy.

Edited by rversaw
Link to comment
Share on other sites

  • 2 weeks later...

I'm up for the move to VS2008 since it's pretty much standard in uni (and they give me a full version for free :D) so I have to use it every day now.

 

And Azrael is right, only .NET 2.0 is required to run XNA 3.0 games:

Supported Operating Systems: Windows Vista Service Pack 1; Windows XP Service Pack 3

A graphics card that supports DirectX 9.0c and Shader Model 1.1 is required.

Shader Model 2.0 is recommended and required for some Starter Kits.

.NET Framework 2.0 or higher is required.

Link to comment
Share on other sites

I'm up for the move to VS2008 since it's pretty much standard in uni (and they give me a full version for free :D) so I have to use it every day now.

 

And Azrael is right, only .NET 2.0 is required to run XNA 3.0 games:

Supported Operating Systems: Windows Vista Service Pack 1; Windows XP Service Pack 3

A graphics card that supports DirectX 9.0c and Shader Model 1.1 is required.

Shader Model 2.0 is recommended and required for some Starter Kits.

.NET Framework 2.0 or higher is required.

 

 

That really just depends on the game though. You can use XNA 3.0 with VS2008 to target .NET 2.0, which means you will only need .NET 2.0, but you can also target .NET 3.5 SP1 or .NET 3.0 which would require that they be installed on a client. Though I would love to have Xenocide moved forward to .NET 3.5 SP1, I'll settle for anything that will compile with VS2008 :)

Link to comment
Share on other sites

  • 2 months later...

Trunk now uses XNA 3.0. (Merged in code provided by Loshult)

Minor issues found with patch:

 

CeGui.Renderers.Xna was still using the XNA 1.0 libraries.

FMOD was still using the XNA 1.0 libraries.

Target version for framework was 2.0 (not 3.5, because that's a massive download.)

Removed System.XML.Linq reference from Xenocide. (not using)

 

Also: Imade two compiler warnings go away.

Still need to fix the "The custom tool 'ResXFileCodeGenerator' failed while processing the file 'Resources\Strings.resx'".

Fix is probably something to do with Xenocide\Resources\Strings.Designer.cs (which used to be autogenerated, from Resources\Strings.resx

 

Removed some cases where global replacement of "Resources" with "Strings" was wrong.

 

ToDo: Update instructions on Wiki for building Xenocide.

Link to comment
Share on other sites

The Strings.Designer.resx file should be autogenerated as before. There was some issues with the file when I imported it to VSE 2008 though so I had to manually copy paste some xml-code to a new file to get it working. It could maybe be some issues left with that operation.
Link to comment
Share on other sites

I checked out the latest changes from trunk but I get the following compilation errors now:

 

  • Error 1 The project file 'C:\Documents and Settings\Christian ?kerblom\Mina dokument\Privat\Xenocide\trunk\Xenocide\Content\Content.contentproj' has been moved, renamed, or is not on your computer. The project will be labeled as "unavailable" in Solution Explorer. 0 0
  • Error 2 Metadata file 'C:\Documents and Settings\Christian ?kerblom\Mina dokument\Privat\Xenocide\trunk\Dependancies\CeGui\CeGui\bin\Debug\CeGui.dll' could not be found CeGui.WidgetSets.Taharez
  • Error 3 Metadata file 'C:\Documents and Settings\Christian ?kerblom\Mina dokument\Privat\Xenocide\trunk\Dependancies\CeGui\CeGui\bin\Debug\CeGui.dll' could not be found CeGui.Renderers.Xna
  • Error 4 Unable to copy file "app.config" to "bin\Debug\CeGui.dll.config". Could not find file 'app.config'. CeGui
  • Error 5 Unable to copy file "app.config" to "bin\x86\Debug\FMOD.dll.config". Could not find file 'app.config'. FMOD
  • Error 6 Application Configuration file "app.config" is invalid. Could not find file 'C:\Documents and Settings\Christian ?kerblom\Mina dokument\Privat\Xenocide\trunk\Xenocide\app.config'. C:\Documents and Settings\Christian ?kerblom\Mina dokument\Privat\Xenocide\trunk\Xenocide\app.config Xenocide

 

dteviot Could you commit the files above to the trunk? The first file exist in the xna 3.0 branch. Error 2 and 3 seems to be related to the dependencies or build order but I didn't find anything when I took a look. Error 4-6 is new files.

 

Edit - Progress

I have added fatal wounds. The combatant gets a random number of fatal wounds from damage in the range [0 (int)damageInflicted/10]. If a combatant receives 5 damage points he gets no fatal wounds. 1-19 can result in 0-1 fatal wound and so on.

 

I'm thinking of changing the fatal wound so that the minimum is equal to (int)damageInflicted/20 and maximum is damageInflicted/10. ANy comments?

 

At the end of each turn, the injury level of combatants with fatal wounds is increased by the number of fatal wounds. Fatal wounds are reset at end of mission.

 

I'm working on a unit test for this but I haven't completed it yet so I've not commited the changes yet.

Edited by Loshult
Link to comment
Share on other sites

I have added fatal wounds. The combatant gets a random number of fatal wounds from damage in the range [0 (int)damageInflicted/10]. If a combatant receives 5 damage points he gets no fatal wounds. 1-19 can result in 0-1 fatal wound and so on.

 

I'm thinking of changing the fatal wound so that the minimum is equal to (int)damageInflicted/20 and maximum is damageInflicted/10. ANy comments?

 

I have a feeling that [(int)(damageInflicted/30 + 0.5), (int)(damageInflicted/15 + 0.5)] would work best :) (personal taste)

 

Nice start Loshult, I'll keep an eye on the progess (and even comment if you find it helpful xD)

Edited by kafros
Link to comment
Share on other sites

I have added fatal wounds. The combatant gets a random number of fatal wounds from damage in the range [0 (int)damageInflicted/10]. If a combatant receives 5 damage points he gets no fatal wounds. 1-19 can result in 0-1 fatal wound and so on.

 

I'm thinking of changing the fatal wound so that the minimum is equal to (int)damageInflicted/20 and maximum is damageInflicted/10. ANy comments?

 

I have a feeling that [(int)(damageInflicted/30 + 0.5), (int)(damageInflicted/15 + 0.5)] would work best :) (personal taste)

 

Nice start Loshult, I'll keep an eye on the progess (and even comment if you find it helpful xD)

 

That would give the following fatal wound tables (assuming maximum health is 60):

Damage | Fatal Wounds (30-15)
0-7    | 0
8-14   | 0-1
15-22  | 1
23-37  | 1-2
38-44  | 1-3
45-54  | 2-3
55-60  | 3-4

Damage | Fatal Wounds (20-10)
0-4    | 0
5-9    | 0-1
10-14  | 1
15-24  | 1-2
25-29  | 1-3
30-34  | 2-3
35-44  | 2-4
45-49  | 2-5
50-54  | 3-5
55-60  | 3-6

 

I don't really know which version I like the most. kafros version gives less fatal wounds but has smaller spread. I don't know whats best to have... Any comments?

Link to comment
Share on other sites

I think this is a matter of game balance, so basically somethng we'll just have to try out. As I see it, kafros version would/could be fine for Easy or normal mode, since it does not give that many fatal wounds, Loshults version could fit quite nicely for the more difficult levels, since yes, it does afflict more damage, but is "finer grained" and thus allows for a more "realistic" account of the "real" injury. Or to simplify: In superhuman mode the player will be thankful for a less heavy use of randomness.
Link to comment
Share on other sites

So while we are discussing game balance we might as well start to address some issues regarding that. My first issue is how we could put that kind of game balancing figures into a specific and easily changed place. My suggestion is to make a GameBalancing class that includes properties/functions for stuff that has to do with game balancing. The creation of weapon damage and creation of fatal wounds is probably things that we should put in that class in that case. Specific values should probably be read from a xml-file to make it easy for others to actually tune the game balance without recompiling.

 

I'm not that familiar with how things like that is solved best so I'm open for discussion and want help to find a suitable way of handling it.

Link to comment
Share on other sites

Just to add my 2 cents on the subject of fatal wounds. The way Enemy Unknown and TFTD handle fatals can be found at the X-COM wiki and at StrategyCore. To boil it down, if damage inflicted is greater than 10, the unit will always get a fatal wound (equal chance of 1, 2 or 3). If damage is 10 or less the game just uses a proportionality to determine if the unit will survive unscathed (0 fatals) or get 1-3 fatals (equal chance for them but the probability of getting a fatal increases as you get closer to 11).

 

I see no problems with kafros' approach or yours. However, I'd like to point out that both of these methods produce a lot more fatals than in EU/TFTD. This might unbalance the way Medi-Kits are used. ;) In kafros's approach, you'll be getting less fatals than normal on lower damages, but more fatals with higher damages. The upper end of the spectrum is basically a very rare event so getting more than 3 fatals is almost impossible without getting killed. On the other hand, at low damages, fewer fatals are applied overall and thus the Medi-Kit is not as desirable as in the original game (I'll finish the mission before I need to heal him). :)

 

- Zombie

Edited by Zombie
Spelling.
Link to comment
Share on other sites

Just to add my 2 cents on the subject of fatal wounds. The way Enemy Unknown and TFTD handle fatals can be found at the X-COM wiki and at StrategyCore. To boil it down, if damage inflicted is greater than 10, the unit will always get a fatal wound (equal chance of 1, 2 or 3). If damage is 10 or less the game just uses a proportionality to determine if the unit will survive unscathed (0 fatals) or get 1-3 fatals (equal chance for them but the probability of getting a fatal increases as you get closer to 11).

 

I see no problems with kafros' approach or yours. However, I'd like to point out that both of these methods produce a lot more fatals than in EU/TFTD. This might unbalance the way Medi-Kits are used. ;) In kafros's approach, you'll be getting less fatals than normal on lower damages, but more fatals with higher damages. The upper end of the spectrum is basically a very rare event so getting more than 3 fatals is almost impossible without getting killed. On the other hand, at low damages, fewer fatals are applied overall and thus the Medi-Kit is not as desirable as in the original game (I'll finish the mission before I need to heal him). :)

 

- Zombie

 

Thanks for the good information. I think I'll start with implementing the original fatal wounds instead of inventing a new. I found out though that we should add fatal wounds to different body parts and that they affect different stats on the combatant. See the X-COM wiki link for more information about it.

 

What do you think about having the aliens/civilians also receive fatal wounds? In my point of view that should only reflect reality and I don't think that it will make the game alot easier. Maybe we could give the medics a healing ability without use of medikits instead?

Link to comment
Share on other sites

What do you think about having the aliens/civilians also receive fatal wounds? In my point of view that should only reflect reality and I don't think that it will make the game alot easier. Maybe we could give the medics a healing ability without use of medikits instead?

Sure, that sounds good. I always despised the fact that the alien medics primary role consisted of stunning X-COM soldiers and not healing their own kind. We might have to flag which alien units can be healed though. I don't think the Sectopod/Cyberdisc robotic counterparts in Xenocide should be able to be healed. Not sure if this type of alien should have fatals either. Just my opinion though. ;)

 

- Zombie

Link to comment
Share on other sites

I checked out the latest changes from trunk but I get the following compilation errors now:

 

  • Error 1 The project file 'C:\Documents and Settings\Christian ?kerblom\Mina dokument\Privat\Xenocide\trunk\Xenocide\Content\Content.contentproj' has been moved, renamed, or is not on your computer. The project will be labeled as "unavailable" in Solution Explorer. 0 0
  • Error 2 Metadata file 'C:\Documents and Settings\Christian ?kerblom\Mina dokument\Privat\Xenocide\trunk\Dependancies\CeGui\CeGui\bin\Debug\CeGui.dll' could not be found CeGui.WidgetSets.Taharez
  • Error 3 Metadata file 'C:\Documents and Settings\Christian ?kerblom\Mina dokument\Privat\Xenocide\trunk\Dependancies\CeGui\CeGui\bin\Debug\CeGui.dll' could not be found CeGui.Renderers.Xna
  • Error 4 Unable to copy file "app.config" to "bin\Debug\CeGui.dll.config". Could not find file 'app.config'. CeGui
  • Error 5 Unable to copy file "app.config" to "bin\x86\Debug\FMOD.dll.config". Could not find file 'app.config'. FMOD
  • Error 6 Application Configuration file "app.config" is invalid. Could not find file 'C:\Documents and Settings\Christian ?kerblom\Mina dokument\Privat\Xenocide\trunk\Xenocide\app.config'. C:\Documents and Settings\Christian ?kerblom\Mina dokument\Privat\Xenocide\trunk\Xenocide\app.config Xenocide

1. Added Content.contentproj that got missed from XNA 3.0 merge.

2. Deleted the references to app.config that got added to .csprog files when upgraded to XNA 3.0.

Now compiles OK. Note, crashes during run time. Problem with CEGUI resources. will investigate tomorrow.

 

Notes.

4, 5, and 6 were the editor adding an app.config element to the .csproj files when I altered them. (And I missed it.)

Removing the app.config element from them fixed 4, 5, and 6. Which allowed the DLLs to be created, which fixed 2 & 3.

Missing Content.contentproj added.

Link to comment
Share on other sites

  • 4 weeks later...

Some progress:

 

- Fatal wounds with different body parts have been implemented.

- Fatal wounds works as in UFO: EU/D.

- Fatal wounds causes the soldier to bleed at the end of each turn.

- Fatal wounds can be healed (No med kit have been programmed, it is just that the fatal wounds can be healed which also heals a number of injury damage points)

- Fatal wounds are cleared after completed mission.

 

Things left to do related to fatal wounds:

- Fatal wounds should cause stat decrease (head => less morale, body => less energy, arms => less accuracy, legs => less TU's) I would like comments of references on how this works in the game. I'm not entirely sure on how to implement this. Adding properties in the Combatant class for morale, energy, accuracy and timeunits seems the best way right now.

- Injury damage should generate recovery days. Recovery days should decrease per day basis.

- Med kit healing...

 

I have attached the patch made on the trunk folder.

fatalwoundshealing.zip

Link to comment
Share on other sites

  • 2 weeks later...
Things left to do related to fatal wounds:

- Fatal wounds should cause stat decrease (head => less morale, body => less energy, arms => less accuracy, legs => less TU's) I would like comments of references on how this works in the game. I'm not entirely sure on how to implement this. Adding properties in the Combatant class for morale, energy, accuracy and timeunits seems the best way right now.

- Injury damage should generate recovery days. Recovery days should decrease per day basis.

- Med kit healing...

 

I have completed parts of the things above. Remaining stuff is:

- Fatal wounds generates accuracy penalty.

- Med-kit healing

 

I would like to have some more information about how stamina/morale recovery on each turn should work. As far as I can see, it has not been implemented yet. The Statistic class needs to be updated with three values for most of the statistics, i.e. base time units, time units left, time units increase. Most statistics should probably have base value, current value and increased value.

 

Who will patch up the trunk with the changes when I'm finished with the fatal wounds/healing stuff?

Link to comment
Share on other sites

Nice.

 

I would like to have some more information about how stamina/morale recovery on each turn should work.

http://www.ufopaedia.org/index.php?title=Energy

http://www.ufopaedia.org/index.php?title=Bravery

 

Who will patch up the trunk with the changes when I'm finished with the fatal wounds/healing stuff?
That would be Mad?
Link to comment
Share on other sites

What isn't mentioned on that page is how aliens recover energy. They have an "Energy Recharge" stat which gives that value back to the unit every turn. For all aliens this is a number between 20 & 50. :)

 

The better page would be my personal baby, the Morale page. ;)

 

- Zombie

Link to comment
Share on other sites

Very nice work Loshult!

Who will patch up the trunk with the changes when I'm finished with the fatal wounds/healing stuff?
That would be Mad?

Probably. ;) But I'd prefer if dteviot would - it's his dept. after all.

Link to comment
Share on other sites

  • 5 months later...
Very nice work Loshult!
Who will patch up the trunk with the changes when I'm finished with the fatal wounds/healing stuff?
That would be Mad?

Probably. ;) But I'd prefer if dteviot would - it's his dept. after all.

So, are there any news about this? Or should I just patch it in? Loshult, are you still around?

Link to comment
Share on other sites

×
×
  • Create New...