Jump to content
XCOMUFO & Xenocide

Programming Requirements


dteviot

Recommended Posts

Hey we're the art dep, we are supposed to bug you Prog guys :P

And often its the other way around... ^_^

I suspect that's because there's not enough up front communication about what each team is trying to achieve, and what it need it needs from the other team to be able to do it.

All the is different is the texture, so no need changing the model...

From a programming view, there's negligible difference in the work required either way.

 

Not meaning to be nasty or anything, but supporting multiple models for X-Corp soldiers is WAY down my priority list.

So far, in fact, that it isn't even on the list.

This statement isn't correct.

There is currently provision for supporting 4 models for X-Corp soldiers. "no armor", "combat armor", "powered combat armor" and "flying armor". The information on the image to use (for all but the no armor case) are held in item.xml. But there is no provision for variants of each of the four types. e.g. Sex, camo, etc.

 

Note, I'm not saying that I can't or won't support multiple models, just that I wasn't aware of the need to do this. And that if I do, then it needs to be prioritized along with everything else.

 

So, if we're going to have multiple X-Corp soldier models/textures then someone needs to tell me now what the plan is, so that I can prepare for it.

Also, does this mean we may have different alien models/textures as well? Note, there is provision for each rank of an alien species to get a different model, but assumes there is only one model for each combination of rank and species.

Edited by dteviot
Link to comment
Share on other sites

Well, I guess then the ART dep will have to read the XNA updates and churn out accompanying art. I have a general idea of what needs to be done (Like all of those base facilities) but I bet that is not really "Needed" by the prog department at the moment. Possobly things like interface and menus, buttons, widgets and stuff along those lines is what the prog dep needs at the moment, I am not sure, please clarify...

 

Work still to be done:

 

2x2 Units. -Complete a 2x2 Alien for use?

 

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?) -Get some CIV models done?

Better (or more fun) AI logic for alien forces on battlescape.

Experience for X-Corp soldiers -Approperiet menus?

Reactions

Bleeding out of wounded soldiers. -Art related Symbols for sodlier status?

Medkit healing - Medkit "Healing Interface"?

Recovery of stun damage

Explosions - Explosion sprites?

Grenades

Rest of actions that items are capable of.

 

Psi attacks

Psi probe

Scan

Hit

Waypoint (for BB launcher) - Waypoint "Marker"?

Fire on battlescape

Smoke on battlescape - Smoke sprites?

 

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 - How do you draw it? Do you take "status" or "type" of each tile and then give it a certain color, and the mini map just scans the tiles and draws the itself (During the loading screen persumably saving the "Complete" minimap into a temp file for that mission)? If so then little Art dep involvement is needed..

Edited by Shinzon
Link to comment
Share on other sites

Have the X-Caps and Silabrate already, so no urgent need for 2x2 models. (Other than in the form of models for all aliens)

Civilian models. I've already got an idea for that. Use existing .md2 models.

Should not need an interface for med kit, it's going to work just like a weapon. At least until post v1.0.

 

Really, the big bit is terrain models, and until destructible is solved, I don't see much point in working on them, as it may require redoing them.

 

In the mean time, alien and equipment models is probably the way to go.

That said, it may pay to discuss standards for the alien models, so that the programming team can handle them.

e.g. Scale of models, Location of origin and initial orientation.

Standard animation sequences.

Maximum number of bones per model.

How to attach items to the model's hands.

There's probably a whole bunch more stuff, that I don't even know about.

Link to comment
Share on other sites

I belive the bones matter is going to be slightly complicated; as it is not simple as every alien sharing a humanoid set up... So the rigging of diffrent aliens is going to be really diffrent from one another... Unless I'm thinking of a compleatly other thing... :P Edited by Shinzon
Link to comment
Share on other sites

I believe the bones matter is going to be slightly complicated; as it is not simple as every alien sharing a humanoid set up... So the rigging of different aliens is going to be really different from one another... Unless I'm thinking of a completely other thing... :P

I just said "number of bones", not position or rigging.

The issue is, and I may be a bit wrong here, but assuming we're using skinned (or stitched) models, then Shader 1.0 means we can render a model with up to 20 bones in one pass. (IIRC, in theory it's up to 27 bones, but that leaves no registers for other things, like lighting.) If we go to Shader 2.0, then up to 96 bones is possible assuming we don't need to scale the models. If scaling is required, it drops to 64. Again, practical limit is less than that.

 

And as Darkhomb said, we need a set of common animations, regardless of how the character moves: e.g.

walk, turn, fire weapon, hit?, use item, die, etc.

We need to figure out how prg can use common code to play the animation on all characters.

Also, how to put items in character's hands. Standard method is put a bone with a known name at the attachment point.

Link to comment
Share on other sites

Since not every model is the same, some will require more animation to look smooth for certain parts. we either have a set range that every model should mimic IE the viper which is fully animated, so whatever frames it uses it what all models use.

 

or we do some type of xml that states frame ranges for what movement for each model.

Link to comment
Share on other sites

before we get too far into the discussion of animation, we need to know what the engine supports. Are we do simple animation stored only in vertex keyframes al la quake, or more complex skeletal based animation? Also will the engine support multiple rigs or do we need to limit things to a single humanoid rig?

An excellent question. The answer is; at the moment it doesn't support either.

As regards supporting either.

  • Quake is easy to do. I know of 2 libraries (including source) that can draw animated .md2 files in XNA, and one that does .md3. Unfortunately, they're not copyright compatible with Xenocide. But from what I've seen of the .md2 spec, it wouldn't be hard to write my own. (Especially with the other libraries as a guide for any ambiguities in the spec.)
  • I'm not so familiar with skeletal animation. Truth is, I'm just learning it myself. That said, from what I've seen, that should not be too difficult, assuming Shader 2.0 is minimum spec. (And as I've posted before, I think I'd like to make shader 3.0 as minimum, as that may make destructible terrain a lot easier.)

So, long story short, I'm willing to do either. In fact, I suspect we could do both. But that would add development time.

Link to comment
Share on other sites

I'd prefer to go with skeletal animation since I think it'll be easier to work with in the long run and provide better results. Edited by dteviot
Link to comment
Share on other sites

before we get too far into the discussion of animation, we need to know what the engine supports. Are we do simple animation stored only in vertex keyframes al la quake, or more complex skeletal based animation? Also will the engine support multiple rigs or do we need to limit things to a single humanoid rig?

I should add an additional comment, and display my appalling ignorance of animated modeling.

My understanding is that if we're just going to play animations, then from the view of the game's rendering engine, the rigs are irrelevant. Provided the engine can be told the bone hierarchy and the bone values, it just walks the hierarchy, applies the bone matrix to the mesh, and renders. It's only if we want to have the game engine programmatically manipulate the model (e.g. IK or rag doll physics) that different rigs become an issue.

Note, this says nothing about issues the ART department may have with trying to animate models with different, non-humanoid rigs.

Link to comment
Share on other sites

Bones and Riggins aside for now; is there anything that the prog dep absolutley needs done? If not I will continue to work on the base facilities and dig through the Database; seeing if I can texture or re-model something
Link to comment
Share on other sites

Bones and Riggins aside for now; is there anything that the prog dep absolutley needs done? If not I will continue to work on the base facilities and dig through the Database; seeing if I can texture or re-model something

There's nothing that needs to be done urgently.

I think the most useful thing at the moment would be magazines for the human weapons, so the equip soldier screen can have some nice graphics.

I'd also refrain from doing base facilities for a little longer, until destructible terrain is resolved.

Link to comment
Share on other sites

Understood...

 

I forgot weapons need ammo to shoot ^_^

 

What is the poly target per ammo clip?

Edited by Shinzon
Link to comment
Share on other sites

Eamon is working on clips for the rifle already. Think we need a pistol clip modeled, and rocket launcher texture. I will update the art assets excel this week.

Right now there isn't really a limit, the only time the model will be used is the x-net. rendered front side will be used for equip screen.

Edited by Darkhomb
Link to comment
Share on other sites

Right now there isn't really a limit, the only time the model will be used is the x-net. rendered front side will be used for equip screen.

That's not exactly true. The models will probably be used if the items are ever dropped on the battlescape, or held in someone's hand (which means they might also appear in a reload animation, if we can figure out how to do it for all combatants.) That said, poly count isn't a big issue. Keep it below 1000 and I don't think it will be a problem.

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

OK, we will proceed with the big models for terrain.

Additional point, as we're going to use big models (with the cell framework underneath for the rules engine to move the combatants) we're going to need to agree on the size of the "cells", so that the rules engine doesn't try moving combatants through walls, or putting them above/below the floor.

At the current time the cells are 1meter x 1meter by 2.5 meters high. And the floor can be 2.5 x 0.3333 m or 2.5 x 0.6666 m, or 0 meters high.

Note, from the game engine's view using a different scale for the cells is trivial, but we need to know what it is. (Because it's going to make building the models easier.)

Also, do we need to add some other rules about building the terrain models, Such as all ramps, doors etc must be 2 cells wide, so that 2x2 units can navigate the models?

Link to comment
Share on other sites

One minor correction:

 

In my post it sais:

Using BSP though is counterproductive as the entire terrain because a polygon soup model (in the extreme case).

Should have been read: Using BSP though is counterproductive as the entire terrain BECOMES a polygon soup model (in the extreme case).

However, it shouldnt change the interpretation of not using BSPs.

 

For the Cell you can create the Cells rule engine from the geometry pretty easily without human intervention (As long as you agree on the scale of the models). You load the terrain + objects and then for each valid cell position to check to see if there is a blocking polygon in it. Blocking polygons are those that have a certain angle non parallel to the floor or above a certain threadhold on cell covering (to be able to have hills and stairs). Probably it would be important to be able to use smaller cells (than the reference that the soldier/unit uses to be able to handle the stairs as a common case instead of an special case).

 

Greetings

Red Knight

Link to comment
Share on other sites

Sorry for the abrupt end of updates; but I entered my final month and the proffesors sure like to pile stuff up... I will be tied up for roughly a month... =p
Link to comment
Share on other sites

Sorry for the abrupt end of updates; but I entered my final month and the proffesors sure like to pile stuff up... I will be tied up for roughly a month... =p

That's fine. I decided to celebrate the release of 0.4 by taking a week off Xenocide development, and instead play UFO:Afterlight. Which has been sitting unopened on my shelf for more than a year.

Link to comment
Share on other sites

×
×
  • Create New...