Xna Stage 0.3

[[dteviot]]

OK, I've posted about this before, but I'll do it again.

There are a number of tasks that need to be done in this area, and that can start now without interfering with the work I'm doing. (Namely, Transfer of materials, Research and then Manufacturing.)

My initial list of tasks, hopefully in order of increasing difficulty is:

• Generate Names for Personnel. (small, but we will want it done.)
  
• Assign Soldiers to Aircraft.
  
  
• Assign Soldiers to Psi Training.
  
  
• And the big one, get Soldiers to carry equipment.
  

Generating names requirements.

• names should be unique
  
• Initially just name soldiers, but may want to name scientists and engineers later
  
• Probably want name to have numeric tag indicating skill/attribute levels
  
• Player may want to be able to change soldier names
  

Assigning Soldiers to aircraft, rules/requirements:

• Soldier and aircraft must be based in same outpost.
  
• When an aircraft is sold or transfered, remove the soldiers and X-Caps that are assigned to it.
  
• A soldier can be assigned to at most one craft.
  
• Soldiers assigned to aircraft can't be transferred (or fired)
  
• Need to be able to specify the "order" solders soldiers are in on an aircraft.
  
• Note, item.xml specifies the maximum number of soldiers and X-Caps a craft can carry, but it doesn't specify the layout of the cargo area. eg. 2 x 5, 4 x 6, 2 x 8 etc. We may need to do something about that.
  
• Screen (or dialog, but probably screen) to assign and remove soldiers from aircraft.
  
• Injured soldiers can't be assigned to aircraft (do we want to change this?)
  
• If a soldier is injured, until they heal they can't be assigned to an aircraft.
  
• Over time, injured soldiers heal. (Zombie, what's the rate for healing, please?)
  

Assigning Soldiers to Psi Training, rules/requirements:

• Assignment is done at start of month.
  
• Can't assign more soldiers to training than have space for.
  
• Can assign injured soldiers to Psi training.
  
• Check for progress at end of each month.
  
• Zombie, can you please tell us the rules for gain in psi skill/strength/whatever.
  

Soldiers carry equipment: No longer available, I'm working on this - signed dteviot

• Screen to equip soldiers. Is used in outpost, and on battlefield to pick up items.
  
• When soldier is equipped in an outpost, soldier will retain those items, when returns to an outpost, best efforts will be made to restore soldier to state when left. Expended ammo replaced, missing equipment replaced. Additional items removed. Etc.
  
• This means that aircraft do not carry a set of equipment used to arm soldiers with on arrival at a battlescape.
  
• Soldiers can't be equipped (when in an outpost) with items that haven't been researched. Nor with items that they can't carry onto a battlefield, e.g. alien corpses.
  

Obviously, there's more requirements that need to be added, and as I can't do everything, your contributions would be appreciated.

Edited October 23, 2007 by dteviot

[SupSuper]

For reference, here's an archived version (the real one seems to have vanished) of the Soldier Names Database.

[Zombie]

Generating names requirements.

• names should be unique
  
• Initially just name soldiers, but may want to name scientists and engineers later
  
• Probably want name to have numeric tag indicating skill/attribute levels
  
• Player may want to be able to change soldier names
  

Are scientists/engineers going to be considered as items (not individuals) for v1.0? If so, it wouldn't make much sense to give them names if they are going to be treated as a group. If you do want to have a feature where the game adds tags to soldier names, fine. Just make sure it's an option the user can change when playing. (Some of us don't like to use tags).

 

Assigning Soldiers to aircraft, rules/requirements:

• Soldier and aircraft must be based in same outpost.
  
• You can't transfer a craft between outposts if it has crew assigned to it.
  
• A soldier can be assigned to at most one craft.
  
• Soldiers assigned to aircraft can't be transferred (or fired)
  
• Need to be able to specify the "order" solders soldiers are in on an aircraft.
  
• Note, item.xml specifies the maximum number of soldiers and X-Caps a craft can carry, but it doesn't specify the layout of the cargo area. eg. 2 x 5, 4 x 6, 2 x 8 etc. We may need to do something about that.
  
• Screen (or dialog, but probably screen) to assign and remove soldiers from aircraft.
  
• Injured soldiers can't be assigned to aircraft (do we want to change this?)
  
• If a soldier is injured, until they heal they can't be assigned to an aircraft.
  
• Over time, injured soldiers heal. (Zombie, what's the rate for healing, please?)
  

In the original game, you could transfer a craft even if personnel were assigned to it. The game would just automatically dump them back into the base. For the transport ship, I would suggest a drag 'n drop screen for assigning soldiers. That way, a player has complete control over the order of the troops/tanks coming off the ship. Does artwork have models of the inner layout of the transport ships yet? (I'd like to take a look at them). If not, it's hard to define a layout if the craft innards aren't defined yet. Soldiers which are injured on the battlefield recover in a random number of days depending on the following equations:

 

MinDays = INT(HealthLost / 2)

MaxDays = INT(HealthLost * 3 / 2)

 

So a soldier with 10 points of health loss will stay in the infirmary between 5 to 15 days randomly distributed.

 

Assigning Soldiers to Psi Training, rules/requirements:

• Assignment is done at start of month.
  
• Can't assign more soldiers to training than have space for.
  
• Can't assign injured soldiers to Psi training.
  
• If injured, any soldier who is being trained is removed.
  
• Check for progress at end of each month.
  
• Soldiers receiving Psi Training can't be fired or transferred.
  
• Should we make it, soliders on Psi Training can't go on missions either?
  
• Zombie, can you please tell us the rules for gain in psi skill/strength/whatever.
  

At least in the original game, you could assign soldiers to psi training if they were injured. Soldiers in psionic training could be transferred or fired, they were just removed from training for you by the game. IMHO, soldiers in psi-training should be allowed on away missions. They can continue training when they return to base. (Perhaps this is more of a post v1.0 thing, but we could lower the amount of psionic skill points awarded to soldier who were away from base for extended periods of time).

 

The rules for psionic gains are quite simple. See this page in the X-COM wiki for the particulars.

 

- Zombie

[[dteviot]]

Are scientists/engineers going to be considered as items (not individuals) for v1.0? If so, it wouldn't make much sense to give them names if they are going to be treated as a group.

At the moment, in sell (and soon in transfer) they are individuals.

 

If you do want to have a feature where the game adds tags to soldier names, fine. Just make sure it's an option the user can change when playing. (Some of us don't like to use tags).

Agreed

 

In the original game, you could transfer a craft even if personnel were assigned to it. The game would just automatically dump them back into the base.

Not in the version of X-Com 1 I have. If there's free living quarters in destination, troops move with the craft, otherwise, you can't move the craft.

I'm just trying to make things simple.

 

For the transport ship, I would suggest a drag 'n drop screen for assigning soldiers. That way, a player has complete control over the order of the troops/tanks coming off the ship.

Ideally, yes. Implementing may take some time.

 

Does artwork have models of the inner layout of the transport ships yet?

I don't know.

 

At least in the original game, you could assign soldiers to psi training if they were injured. Soldiers in psionic training could be transferred or fired, they were just removed from training for you by the game. IMHO, soldiers in psi-training should be allowed on away missions. They can continue training when they return to base.

Agreed, that should be even simpler to implement.

[SaintD]

If you do want to have a feature where the game adds tags to soldier names, fine. Just make sure it's an option the user can change when playing. (Some of us don't like to use tags).

 

If it's possible to see a soldiers stats anytime you deal with them, we wouldn't need tags. For example, I find tags most usefull on the soldier equip screen pre-battle. So I can know who can carry heavy weapons, or has the highest accuracy.

 

It would be nice if the soldier picture would show the stats when you hover.

 

Also, do we have "paper doll" art for equipping soldiers yet? If not I would like to suggest we make the "pajamas" a goverment agent suit instead. (Men In Black anyone?)

[Zombie]

If it's possible to see a soldiers stats anytime you deal with them, we wouldn't need tags. For example, I find tags most usefull on the soldier equip screen pre-battle. So I can know who can carry heavy weapons, or has the highest accuracy.

Total agreement by me. One of my pet peeves is the inability to view soldier attributes in the equip screen. (Another is the small graph which only has a few stats in the battlescape. If a user could customize what is shown, you could better manage your troops. Yes, you can click on the soldier area and view everything about him/her, but it requires you to manage through a separate screen which is a pain).

 

- Zombie

[[dteviot]]

In the original game, you could transfer a craft even if personnel were assigned to it. The game would just automatically dump them back into the base.

Not in the version of X-Com 1 I have. If there's free living quarters in destination, troops move with the craft, otherwise, you can't move the craft.

I'm just trying to make things simple.

 

On reflection, you're correct, simplest solution when an aircraft is sold or transfered is to remove the soldiers and X-Caps that are assigned to it.

[SaintD]

If it's possible to see a soldiers stats anytime you deal with them, we wouldn't need tags. For example, I find tags most usefull on the soldier equip screen pre-battle. So I can know who can carry heavy weapons, or has the highest accuracy.

Total agreement by me. One of my pet peeves is the inability to view soldier attributes in the equip screen. (Another is the small graph which only has a few stats in the battlescape. If a user could customize what is shown, you could better manage your troops. Yes, you can click on the soldier area and view everything about him/her, but it requires you to manage through a separate screen which is a pain).

 

- Zombie

 

Somewhat off topic, but another peeve of mine is on the battlescape. Someone can be bleeding to death and there is no way to know who has fatal wounds without looking at everyones full stat page. And if someone is unconsious, you have no way of knowing if they are bleeding. If you see someone shot, you need to check on them. But there are times people get caught in a blast and you don't realize they have a fatal wound.

 

Reminder to us for battlescape: Hurt soldiers need an icon. Maybe a red (!).

[red knight]

Reminder to us for battlescape: Hurt soldiers need an icon. Maybe a red (!).

Probably with a numeric indication of how much hurt

 

Greetings

Red Knight

[[dteviot]]

Possible change in plan. While I suggested being able to control the position of soldiers and X-Caps on aircraft, on reflection we may not want to do this. Thought is, while in X-COM one, troops debark from aircraft, in Apoc, the troops are to be transported close to the site, and then proceed the last bit on foot. If we adopt that model (at least initially) it saves us at least 2 pieces of work.

• Providing aircraft models on the battlescape to debark from.
  
• Writing the code needed to store soldiers in order on craft.
  

It also allows us to have multiple "exit points" on the battlescape.

Note, even if we don't debark troops from craft initially, there's nothing stopping us adding that ability at a later point in time.

[Zombie]

I kinda like the safety provided by the transport ship on mission deployment. Also it allows a player to decide immediately if they want to abort due to a hot landing zone. Of course, if we are going to use Apoc's way initially and then switch at a later time, I'm fine with that. But the problem still remains on where to place soldiers on a map. I'd think it would be easier to have them collected in one spot rather than spread out across the map in pseudo-random spawn locations. If we don't have a craft model for the battlescape yet, just dump the soldiers/tanks on the ground where the craft would go.

 

- Zombie

[red knight]

Follow the XCOM way, do not order them at all

 

Greetings

Red Knight

[[dteviot]]

Follow the XCOM way, do not order them at all

 

Greetings

Red Knight

Well, I suspect being able to order the troops on a craft is trivial effort, compared to the work required to get a craft into the battlescape in the first place. So, to get something playable as quickly as possible, I propose deferring the "craft deployment" until much later in the project (like, battlescape finishing touches) And putting troops in order on an aircraft serves no purpose until that time.

[red knight]

Exactly, even though it is a "simple" thing there are subtle things that you have to take in account, so lots of tweaking will be needed that wont add much value till the end of the project.

 

Greetings

Red Knight

[Zombie]

What do you want to know about soldier inventory, dteviot? I'm not sure I understand the question so please elaborate.

 

- Zombie

[SaintD]

Exactly, even though it is a "simple" thing there are subtle things that you have to take in account, so lots of tweaking will be needed that wont add much value till the end of the project.

 

Greetings

Red Knight

 

 

We could build in unit positions on the transport craft in the geoscape. Then simply ignore it on the battlescape until we are ready to tackle it.

 

Possible ideas for later:

I always wanted to be able to attach the tanks to the outside of my transport craft in XCOM. It would also be sweet if the landing craft had a few turrets to help clear up hot landing zones!

[[dteviot]]

What do you want to know about soldier inventory, dteviot? I'm not sure I understand the question so please elaborate.

 

- Zombie

• Screen shot of soldier inventory.
  
• List of locations and their properties. e.g.
  • Left hand
    • size 2 x 4
      
    • time to put an item into hand
      
    • time to remove an item from hand
      
    • special limitation: can only hold one item
      

    [*]Left Shoulder

    • size 1 x 2
      
    • time needed to add an item
      
    • time needed to remove an item
      

    [*]Armour

    • size 1 x 1
      
    • special limitation: can only add/remove item when soldier is in outpost
      
    • special limitation: can only hold amour items
      

Are there any other properties, e.g. weight limit for area?

 

One other thing comes to mind, need to track two sets of properties.

1. "Standard loadout", which is what soldier should be equipped with at start of mission. and

2. "Current state" which is what solider is actually carrying at point X in time.

[Zombie]

Ah, ok. Well, let's see. Here is a shot of soldier inventory I made for the X-COM wiki's OBPOS.DAT page.

 

http://www.ufopaedia.org/images/f/fe/Slots.png

 

	  Slot(s)		 Area			   Sizes
   0, 1		Hand Slots			1x1, 1x2, 1x3, 2x1, 2x2, 2x3, 3x1, 3x2
 2-3, 4-5	  Leg Slots			 1x1, 1x2
 6-7, 8-9	  Shoulder Slots		1x1, 1x2
   10-18	   Back Pack Slots	   1x1, 1x2, 1x3, 2x1, 2x2, 2x3, 3x1, 3x2, 3x3
   19-24	   Belt Slots			1x1, 1x2, 1x3, 1x4, 2x1

   Size		 Items
	1x1		 Most ammo, grenades, Elerium
	1x2		 Cannon ammo, HE pack
	1x3		 None
	1x4		 None
	2x1		 Pistols, Blaster Bombs
	2x2		 Mind Probe, Small Launcher
	2x3		 None
	3x1		 Rockets, Rifles, Stun Rod
	3x2		 All types of Heavy Weapons, corpses
	3x3		 None

For the Time Unit costs for shifting items between areas, see the Inventory TU Table at the X-COM Wiki. There isn't a weight restriction for any of the areas: if the item fits, you can place it there. Excessive weight will bog a soldier down (aka encumbrance) and he/she may incur a TU penalty if total carried weight is above the strength rating. The only "special" area is the hand slots which can only carry one item at a time as you mentioned.

 

The initial loadout for soldiers is a little bit strange in X-COM. Usually, the game picks items from the top of the list and gives one to as many soldiers as it can. The primary slot is the belt as the game will try to place items there first. If the item doesn't fit or the area is filled, the game tries the legs, the shoulders and finally the backpack. Stun Rods, Electro-flares, Blaster Launcher/Blaster bombs, and the Mind Probe are never equipped. Neither is "orphaned" ammunition (ammo loaded on a craft without a suitable weapon present). Things which are always equipped include the grenades, Motion Scanner, Medi-Kit and Psi-Amp. The Psi-Amp is a special case: if a soldier doesn't have this skill yet, he doesn't get this device. Each soldier with Psi-Skill >1 will get one of these items placed in his backpack depending on the number of soldiers present. If there are fewer than or the same amount of psi-soldiers than amps, each soldier gets one with the remainder placed on the ground in the item "pile" on the ground in the craft. The normal weapons will try to be placed in a hand slot (loaded). After these weapons are placed, excess ammo is divvied up between the soldiers and is usually dumped in the left leg slot.

 

I don't know, is this what you were looking for?

 

- Zombie

[[dteviot]]

I don't know, is this what you were looking for?

It's exactly what I was after. Thanks

 

The initial loadout for soldiers is a little bit strange in X-COM. Usually, the game picks items from the top of the list and gives one to as many soldiers as it can. The primary slot is the belt as the game will try to place items there first. If the item doesn't fit or the area is filled, the game tries the legs, the shoulders and finally the backpack. Stun Rods, Electro-flares, Blaster Launcher/Blaster bombs, and the Mind Probe are never equipped. Neither is "orphaned" ammunition (ammo loaded on a craft without a suitable weapon present). Things which are always equipped include the grenades, Motion Scanner, Medi-Kit and Psi-Amp. The Psi-Amp is a special case: if a soldier doesn't have this skill yet, he doesn't get this device. Each soldier with Psi-Skill >1 will get one of these items placed in his backpack depending on the number of soldiers present. If there are fewer than or the same amount of psi-soldiers than amps, each soldier gets one with the remainder placed on the ground in the item "pile" on the ground in the craft. The normal weapons will try to be placed in a hand slot (loaded). After these weapons are placed, excess ammo is divvied up between the soldiers and is usually dumped in the left leg slot.

- Zombie

Hmm. Not really relevant, as we're going to Apoc style equipping. That is, set the soldiers standard loadout in base, and soldier will maintain that until changed.

 

Oh, and I took the liberty of moving the posts to the 0.3 thread (obviously) because this is really a 0.3 topic.

[SaintD]

One other thing comes to mind, need to track two sets of properties.

1. "Standard loadout", which is what soldier should be equipped with at start of mission. and

2. "Current state" which is what solider is actually carrying at point X in time.

 

Why #1 at all? Why not just store the soldiers in the base loaded with thier equipment. I suspect the reason XCOM works like it does is for memory reasons. We don't have near the same constraints.

 

Make the men equipable in the base at any time before a mission. Then when they get to the battlescape they just have thier gear. That way the transport doesn't need to come into play. The transport can have a weapon and ammo locker for extra ammo and whatnot we don't want on the guys. But I never liked the "spend 15 minutes getting the gear back where it was last time we went out" at the start of each mission.

 

I like the idea of templates that we could apply to soldiers to make the proccess faster in base.

 

-D

[Zombie]

Um, that's just what dteviot mentioned in his last post. Soldiers being equipped at base in the style of Apoc.

 

I agree though, pre-equipping soldiers before battle is much better. I'd much rather spend the time figuring out what each soldier should carry back at base one time rather than doing it before each mission.

 

- Zombie

Edited October 10, 2007 by Zombie

[[dteviot]]

Um, that's just what dteviot mentioned in his last post. Soldiers being equipped at base in the style of Apoc.

 

I agree though, pre-equipping soldiers before battle is much better. I'd much rather spend the time figuring out what each soldier should carry back at base one time rather than doing it before each mission.

 

- Zombie

Yes. The confusion is what I meant by "solders standard loadout". What I meant was, like in Apoc, setting the individual loadouts for each soldier. Which the system tries to maintain when soldiers return to base.

[SaintD]

Um, that's just what dteviot mentioned in his last post. Soldiers being equipped at base in the style of Apoc.

 

I agree though, pre-equipping soldiers before battle is much better. I'd much rather spend the time figuring out what each soldier should carry back at base one time rather than doing it before each mission.

 

- Zombie

Yes. The confusion is what I meant by "solders standard loadout". What I meant was, like in Apoc, setting the individual loadouts for each soldier. Which the system tries to maintain when soldiers return to base.

 

 

Sounds good. It would also be great if you never saw the message "couldn't re-equip squad." I want a dang list of things I should buy.

On a related note I would like to set a "buy below" level for consumables. So I could set smoke grenades to 20, and anytime I had less than 20 my clerk would buy more. Maybe asking for my approval.

[[dteviot]]

Um, that's just what dteviot mentioned in his last post. Soldiers being equipped at base in the style of Apoc.

 

I agree though, pre-equipping soldiers before battle is much better. I'd much rather spend the time figuring out what each soldier should carry back at base one time rather than doing it before each mission.

 

- Zombie

Yes. The confusion is what I meant by "solders standard loadout". What I meant was, like in Apoc, setting the individual loadouts for each soldier. Which the system tries to maintain when soldiers return to base.

 

 

Sounds good. It would also be great if you never saw the message "couldn't re-equip squad." I want a dang list of things I should buy.

On a related note I would like to set a "buy below" level for consumables. So I could set smoke grenades to 20, and anytime I had less than 20 my clerk would buy more. Maybe asking for my approval.

My thought was keep track of materials used during a battlescape, then at add put in a "purchase order" to replace the expended materials. (That player can approve/update.) But it's either post v1.0, or for someone else to do. I just don't have time to do everything.

[[dteviot]]

progress:

• Azrael's patch: BaseInfoScreen shows defense strength
  
• renamed "name" attribute in item.xml, facility.xml and research.xml to "id", and added "name" attribute to hold name to show to player.
  

Notes:

• Red Knight, can you please fix the remaining FxCop warning in GlobeVertex, I'm not sure of the best way to deal with it.
  

[red knight]

I assume that you are refering to this one:

CriticalWarning, Certainty 90, for ArrayFieldsShouldNotBeReadOnly

{

Target: #VertexElements (IntrospectionTargetMember)

Resolution: "Either replace 'GlobeVertex.VertexElements' with a strongly typed collection that cannot be changed, or replace the public field with a method that returns a clone of a private array."

...

}

Well even if it is true, there is a performance issue in doing what it asks you. Because in that case you have to recreate something that is not supposed to be changed anyway (as it is a declaration) every frame. What it is a very big burden over the GC. That is my biggest gripe agains FxCop, it can helps you a lot but you dont have to go religious about it use, because you end up writting lots of code just to "hide" those errors making the code plain awful. I is ok to use it for screening purposes though once in a while; for instance, I detected a couple of problems regarding IDisposable with GeoMarker and Skybox (nothing big though that I am going to address).

 

EDIT: BTW FxCop is designed for guidelines enforcing not for perfomance programming so the ruleset changes. This link can be helpful: http://blogs.msdn.com/fxcop/archive/2007/0...internally.aspx

 

If you want I can create an FxCop project with the really useful rules and add it to Xenocide source.

 

Greetings

Red Knight

[[dteviot]]

I assume that you are refering to this one:

CriticalWarning, Certainty 90, for ArrayFieldsShouldNotBeReadOnly

{

Target: #VertexElements (IntrospectionTargetMember)

Resolution: "Either replace 'GlobeVertex.VertexElements' with a strongly typed collection that cannot be changed, or replace the public field with a method that returns a clone of a private array."

...

}

Well even if it is true, there is a performance issue in doing what it asks you. Because in that case you have to recreate something that is not supposed to be changed anyway (as it is a declaration) every frame. What it is a very big burden over the GC. That is my biggest gripe agains FxCop, it can helps you a lot but you dont have to go religious about it use, because you end up writting lots of code just to "hide" those errors making the code plain awful. I is ok to use it for screening purposes though once in a while; for instance, I detected a couple of problems regarding IDisposable with GeoMarker and Skybox (nothing big though that I am going to address).

 

EDIT: BTW FxCop is designed for guidelines enforcing not for perfomance programming so the ruleset changes. This link can be helpful: http://blogs.msdn.com/fxcop/archive/2007/0...internally.aspx

 

If you want I can create an FxCop project with the really useful rules and add it to Xenocide source.

 

Greetings

Red Knight

OK, so in this case we just tell FxCop to shut up about that warning. Fine with me. (I do it all over the place anyway.)

I just wasn't sure if I was missing something.

[[dteviot]]

Progress:

• StaffSargeant patch: Monthly costs include items in transit, and Added Monthly Costs Screen
  

[[dteviot]]

Hi dteviot,

 

I got latest from SVN and noticed that the new MonthlyCostsScreen.cs file is not present in the repository for some reason.

 

I am also starting to look at the Stores screen (and comparing it to the sell and transfer screens) and have a couple of questions:

• Should the Stores screen only display non person items?
  
• In the sell and transfer screens the engineers and scientists are displayed individually. This is different from XCom where only soldiers do and seems to be the result of how ListContents is implemented in OupostInventory. Should this be changed to be the same as in XCom?
  
• In the same screens, where an individual is listed, is also states how many are in the base, so these should only ever have 1, but they display how many of their type (Scientist, Engineers or Soldiers) exist in the base - this is surely a bug, but I am not sure as how to go about fixing it. Any ideas?
  

Cheers,

StaffSargeant

• Missing MonthlyCostsScreen.cs. Reason is, I got sloppy. I'll add it tonight.
  
• What should stores show? I'd suggest showing everything, just like the sell and transfer screens. For that matter, rather than implement a new stores screen, I'd consider adding a flag to the sell screen that tells it to run in a "stores" mode. (Although it might be easier/cleaner to factor the common code into a base class, and derive "Stores" and "Sell", I haven't looked into this in any detail.)
  
• Displaying individual scientists and engineers. Actually, I think it only shows IDLE scientists and engineers. And the reason for showing them individually is because the plan was to make them individual.
  Personally, I'm happy to have the appear individually, but others may have a different opinion. (Along the lines of: a single entry is less work for the player.) If you want to roll them into one entry, be my guest.
  
• Displaying count. It's not a bug, it's so person knows how may soldiers/engineers/scientists there are. Trying to count the number of rows in the screen is a bit awkward, so the count was provided. The same thing is done for craft. (If can tell if an item is unique from Item's IsUnique property)
  

Anybody else want to add their opinion/comments?

[[dteviot]]

progress:

• StaffSargeant patch: Added StoresScreen
  
• Added MonthlyCostsScreen.cs (which I forgot to check in yesterday)
  
• Removed "Transactions" button from Geoscape screen
  

[[dteviot]]

(8:16:31 AM) StaffSargeant: Hi dteviot

(8:17:02 AM) StaffSargeant: Good morning

(8:17:19 AM) dteviot: good evening

(8:18:21 AM) StaffSargeant: Do we have a UI design for the assign soldiers to crafts screen?

(8:18:36 AM) dteviot: no

(8:18:59 AM) StaffSargeant: OK. Will probably plunder the soldier list screen in that case.

(8:19:18 AM) dteviot: my thoughts were probably pick craft, get list of places on craft and free soldiers

(8:19:45 AM) dteviot: then have buttons to move soldier to/from craft, and position of soldier in list

(8:19:50 AM) StaffSargeant: I didn't think item.xml had craft layouts

(8:20:18 AM) dteviot: it doesn't, just treat it as a list, and we assign places in layout based on position in list.

(8:20:51 AM) dteviot: ie. we fill craft starting at "top left" corner, and fill in left to right, top to bottom.

(8:21:22 AM) StaffSargeant: OK. I'll figure out how to lay it out on the screen.

(8:21:25 AM) dteviot: closest match for GUI is probably the "equip craft with weapons" GUI.

(8:21:43 AM) StaffSargeant: What are we doing with XCaps?

(8:21:48 AM) dteviot: Actaully, thinking some more,

(8:22:04 AM) dteviot: it's probably very similar to the X-Com 1 assign soldiers to craft GUI

(8:22:23 AM) dteviot: except we provide up/down buttons to move soldiers position in the list.

(8:22:49 AM) dteviot: I've been thinking about X-Caps, but haven't had a good idea.

(8:22:57 AM) dteviot: I can see two obvious options.

(8:23:08 AM) dteviot: 1. Keep two lists, one of soldiers, other of X-Caps.

(8:23:14 AM) dteviot: Advantage, it's simple.

(8:23:18 AM) StaffSargeant: In X-com1 they were part of the equipment.

(8:23:21 AM) dteviot: Disadvantage, duplicated work.

(8:23:43 AM) dteviot: Ah.

(8:24:12 AM) dteviot: Option 2. X-Cap and Soldiers are both "combatants", and craft carries combatants.

(8:24:20 AM) dteviot: Unified model, but more complicated.

(8:24:32 AM) StaffSargeant: Preferences?

(8:24:41 AM) dteviot: Put this way, probably easiest to have 2 lists.

(8:25:01 AM) dteviot: Gives the advantage, we could put additional gear on aircraft if we wanted

(8:25:21 AM) dteviot: e.g. Special mission equipment (flares, sun rods etc.) that soldiers wouldn't always need

(8:25:46 AM) StaffSargeant: In addition to the "auto equip"

(8:26:00 AM) dteviot: yes.

(8:26:09 AM) StaffSargeant: Makes sense

(8:31:43 AM) StaffSargeant: Bye for now

(8:31:50 AM) dteviot: goodnight

[[dteviot]]

progress:

• Created AmmoInfo and added to Item
  
• Now possible to handle Combatant carried items holding ammo.
  

[[dteviot]]

Progress:

• Added BattlescapeInfo to item.xml/.xsd
  

As part of the "equip solider" screen, I've modified item.xml

The change is adding a battlescapeInfo element, which holds information relevant to item when its on a battelscape.

The main attributes I needed were spriteTop and spriteLeft, which specify the cell holding the top left corner of the item's sprite to show on the soldier inventory screen.

That is, I need a sprite sheet (a .png file) that is divided into a set of cells that are 32 x 32 pixels in size (or possibly 64 x 64.)

The spriteTop and spriteLeft values give the co-ordinates of the cell holding the top left corner of the item's sprite,

and the carryInfo gives the number of cells making up the image (in x and y) directions.

 

The sprite sheet needs to go like:

 

+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| Xen |	 |	 |   RC-H	|		   |	 |		   |
+-----+ P   +	 |-----+-----+		   +	 +		   +
| P-C |	 |  R  |   RC-A	|	RC	 | LR  |	HLR	|
+-----+-----+	 +-----+-----+		   +	 +		   +
| R-C |PP-C |	 |   RC-I	|		   |	 |		   |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|   HC-H	|		   |	GD-C   |		   |PR-C |	 |
|-----+-----+		   +-----+-----+		   +-----+	 +
|   HC-A	|	HC	 |	 |	 |	GDL	|HP-C | PR  |
+-----+-----+		   + LP  + PP  +		   +-----+	 +
|   HC-I	|		   |	 |	 |		   |SB-C |	 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
|		   |	 |	 |	 |		   |	 |		   |
+		   +	 +	 |	 +		   +	 +	SBL	+
|	HP	 |SR-C |LR-C |IR-C |	RL	 |  S  |		   |
+		   +	 +	 +	 +		   +	 +-----+-----+
|		   |	 |	 |	 |		   |	 | MS  |	 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+ MK  +
|  FP +  G  +	 + GS  +		   +		   +	 +	 +
+-----+-----+	 +-----+		   +		   +-----+-----+
|		   +Ps-A + GP  +   Body	+   Stun	+	 +	 +
+	Ps-P   +	 +-----+		   +		   +-----+  SC +
|		   +	 + GA  +		   +		   +	 +	 +
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+

 

Where

Xen = Xenium

P = Pistol

P-C = Pistol Clip

R-C = Assult Rifle Clip

R = Assult Rifle

RC-A = Repeater Cannon AP ammo clip

RC-H = Repeater Cannon HE ammo clip

RC-I = Repeater Cannon IN ammo clip

RC = Repeater Cannon

HC-A = Heavy Cannon AP ammo clip

HC-H = Heavy Cannon HE ammo clip

HC-I = Heavy Cannon IN ammo clip

HC = Heavy Cannon

 

GC-D = Gravity Distortion Drone

GCL = Gravity Distortion Drone Launcher

LP = Laser Pistol

LR = Laser Rifle

HLR = Heavy Laser Rifle

 

PP-C = Plasma Pistol Clip

PP = Plasma Pistol

PR-C = Plasma Rifle Clip

PR = Plasma Rifle

HP-C = Heavy Plasma Rifle Clip

HP = Heavy Plasma

 

SR-C = Small Rocket

LR-C = Large Rocket

IR-C = Incendiary Rocket

RL = Rocket Launcher

 

S = Stun baton

SB-C = Stun Bomb

SBL = Stun Bomb Luncher

 

MS = Motion Sensor

MK = Med Kit

FP = Flashpod

 

G = Grenade

GS = Smoke Grenade

GP = Proximity Grenade

GA = Alien Grenade

SC = Satchel Charge

 

Ps-P = Psi Probe

Ps-A = Psi Amp

Body = Dead Body (cheating, initially use one sprite for all corpse types)

Stun = Unconscious Body (cheat, initially use one sprite for all unconscious bodies)

 

where each "box" in the diagram is either 32 or 64 pixels high and wide.

e.g. Xenium is from pixels 0, 0 to 31, 31, and the Pistol is from 32, 0 to 63, 63

 

I also need need a background "equip soldier" image for the screen. Until then, I don't think I can proceed with the equip soldier screen.

 

Finally, I while creating the BattlescapeInfo element, I added a couple of additional fields that I think we're going to need, that someone might like to fill in.

Specifically, the "armor" attribute, that specifies the item's resistance to damage. Attacks less than or equal to this won't effect the item, over this level will destroy it

[[dteviot]]

progress:

• Fixed IGeoBitmapProperty.Size not being correctly recalculated when saved game is reloaded.
  
• Aircraft are stripped of weapons when they are sold
  
• Check for "X-Corp loosing game" conditions at start of each month
  

[Darkhomb]

might want to think about doubling the numbers, 32x32 is kinda small. might be better to have 64x64 blocks

 

but here the grid you made scaled to 32x32 for testing then ill start putting weapons we have full models of in there.

Edited November 13, 2007 by Darkhomb

[Darkhomb]

This isnt a finished version,but it is better then the one i showed you earlier.

[[dteviot]]

progress:

• StaffSargeant's AssignToCraftScreen patch
  

Notes:

I've not given it a through inspection, but I see the following issues.

• Crashes if you try changing the ranking of a soldier who is not assigned to an aircraft.
  
• Crashes if you select a solder, but do not select a craft, and then click the "assign" or "unassign" buttons.
  
• When you "unassign a soldier from a craft", you probably should not need to have a craft selected.
  
• When you "unassign a XCAP from a craft", you probably should not need to have a XCAP selected.
  
• XCap in a base are not shown until a craft is selected
  

Also note, I've done a bit of refactoring, to tidy up the code somewhat, so what I've checked in isn't exactly what StaffSargeant submitted.

[StaffSargeant]

progress:

• StaffSargeant's AssignToCraftScreen patch
  

Notes:

I've not given it a through inspection, but I see the following issues.

• Crashes if you try changing the ranking of a soldier who is not assigned to an aircraft. - FIXED
  
• Crashes if you select a solder, but do not select a craft, and then click the "assign" or "unassign" buttons. - FIXED
  
• When you "unassign a soldier from a craft", you probably should not need to have a craft selected. - FIXED
  
• When you "unassign a XCAP from a craft", you probably should not need to have a XCAP selected. - By design. The list is not of individual xcaps, but of xcap _types_, so have to know what craft to use.
  
• XCap in a base are not shown until a craft is selected. - FIXED
  

Also note, I've done a bit of refactoring, to tidy up the code somewhat, so what I've checked in isn't exactly what StaffSargeant submitted.

AssignToCraftScreenFix.zip

[[dteviot]]

Progress:

Stubbed in EquipSoldierScreen

[[dteviot]]

Progress:

• Merged in StaffSargeant's patch, better exception reporting dialog
  
• Merged in StaffSargeant's patch, fixed some bugs in AssignToCraftScreen
  
• Some more work on EquipSoldierScreen. (Correctly draw sprites of items soldier is carrying)
  

[Darkhomb]

Sorry know you wanted to work on that this weekend, i'll work on the background more, had alot more going on then planned.

[[dteviot]]

Sorry know you wanted to work on that this weekend, i'll work on the background more, had alot more going on then planned.

Not a problem, what you did was perfectly sufficient for the time being. Thanks for your efforts.

That said, now that I've got the screen partially working, I've think I've got a better idea of what is required. (There's no hurry to do any of this, but I think it will result in a nicer looking screen.

• All the "boxes" on the screen must be exactly the same size. (This is because many items cover several boxes, and if the boxes are not the same size, things look weird.)
  
• On the "ground" area, there are 20 boxes across the width of the screen. And as the screen is 800 pixels wide, then each box, including it's border, needs to be 40 pixels wide.
  
• Therefore each box should be 40 pixels high, and each item sprite needs to be a multiple of 40 pixels. e.g. Grenade sprite is 40 x 40 pixels. Pistol is 40 x 80 pixels.
  
• If you give each "box" a boundary one pixel wide around each edge, then there will be a two pixel wide boundary between adjacent boxes. (e.g. The backpack) Suggested fix. 1. Add an extra one pixel wide boundary around the outside of the backpack. This extra pixel won't count as part of the backpack area.
  
• Final comment, putting text onto the background bitmap was a mistake, as it will give translation issues. Suggested fix, remove the text, and draw an arrow linking each set of boxes to their location on the soldier.
  

[[dteviot]]

A couple of additional changes I'm contemplating:

• Rename the "Item" class in Xenocide/Source/Model/StaticData/Items to ItemInfo. Update the names it's derived classes to match.
  
• Rename ItemHandle to Item.
  
• In basic.xsd, we have a number of enumerations that look like RANK_SOLDIER, RANK_LEADER etc. Now where this gets a bit ugly is we will want to turn these enumerations into C# enum values. And the way this is currently done in the code is via a lookup table that indexes the xml string via the C# enum's value. Ugly. It would be less work to use the Enum.Parse() to do the conversion. However, using Parse() requires that the C# enums match the string. And having C# enums like "RANK_SOLDIER", is also ugly. So I propose replacing the enums in the .xsd with C# style enums.
  e.g. Replace "RANK_SOLDIER" with just "Soldier"
  

Anyone have any comments?

[[dteviot]]

progress:

• Equip Soldier screen is now working
  

Notes:

• You can pick up items on the Equip soldier screen by left clicking on them
  
• Left Click on the place where you want the item to go to put the item down
  
• You can change the ammo in weapons in the Equip soldier screen by picking up the ammo and droping it on the weapon.
  
• If you drop an item onto the "ground" area, it will be returned to the outpost's inventory
  
• Screen also displays ammo info for currently selected item.
  
• Right click on an item to remove it's clip (if it has one.)
  

I've been trying to think what do we need for a minimally playable battlescape, and come up with the following list as what I believe is the minimal set of features:

• A minimal terrain: a flat, empty, 2D grid. Think "chessboard" but say 128 cells on each edge.
  
• Combatants: that can move, shoot, get injured and die. (We will ignore being able to pick up items, move inventory, reload weapons, change weapons, med kits, grenades, psi attacks, smoke, etc.) Need to constrain activities by TUs/time.
  
• Interface that allows player to give orders to X-Corp forces/Interact with battlescape.
  • Select non-dead soldier
    
  • Move selected solder to location
    
  • Have selected soldier shoot at enemy.
    
  • Save/Restore game
    
  • End battlescape mission.
    
  • Move viewport.
    

  [*]AI that moves the alien forces.

  [*]Way to end the battle, and calculate the score

  [*]At start of mission, figure out what the Alien troops are and equip them

Questions/comments:

• What have I forgotten?
  
• Can we expand on/clarify these requirements?
  
• How can we go about implementing these requirements?
  
• What would the next stage(s) be?
  
• Giving orders to X-Corp forces. I suspect the "turn based" model (e.g. X-Com 1, where, player gives the order, and, if the soldier has enough TUs, it's done) would be the easiest to implement. However, the sort I'd really like to have is the psudo-real time of Apocalypse. Where player gives each soldier a list of orders, and they start running them simultaneously. And time can be stopped and orders changed. Anyone have any ideas on how we could build a system that works with both?
  

Some final thoughts about the battlescape's terrain.

• I think I finally begin to see what RK has said before about the "internal model" of the terrain. E.g. my proposal was to treat the terrain as an array of "cubes", where each cell represented a volume of the battlescape. The properties of each cube reflected the properties of that volume. E.g. A wall was encoded by one of the cube's faces being impassable, and painted with a wall texture.
  An alternate model of the terrain would be something like a quake/halo level, where the terrain is described by a "sea of polygons" describing the walls, floors and ceilings inside the battlescape.
  
• We should distinguish between the internal representation of the terrain (which is used by the game engine) and how the terrain is drawn on the display for the player. E.g. We could use a quake 2 level to describe the battlescape, but only display it from a fixed isometric perspective (e.g. X-COM 1) The fixed isometric has a big advantage because the player can only ever see one side of a wall, so we don't need to worry about the other side.
  

edit: typos

Edited November 24, 2007 by dteviot

[red knight]

Exactly the only caveat is that you need to process a hand made terrain to create a internal representation or create a terrain based on constrains or create both at the same time

 

My pick would be the creation at the same time, how that can be accomplished? Well we first have to start with a simple terrain (without other objects).. So the creation of a terrain using a "random" Height Map would be more than enough for our purposes of starting to define the internal representation and the process of creation. After that we can move toward adding premade objects like trees and adapt our internal representation to create keep the tree structures in there, then with houses and we will have a complete functional battlescape creation procedure.

 

Greetings

Red Knight

[[dteviot]]

Progress:

• Correctly calculate scaling transform for X-Net models
  
• Strip aircraft of soldiers and X-Caps when transfered or sold.
  
• Strip soldiers of equipment when dismissed.
  
• Can't transfer or dismiss a soldier that is assigned to an aircraft
  
• Can only equip soldiers when they're in an outpost
  
• soldiers are killed when aircraft that carries them is destroyed
  
• Tuned terror missions, only last UFO in set will attack a city
  
• Stopped some FxCop warnings
  

Notes

• X-Net now shows the Barracks and Research Lab models correctly
  
• Yes, I'm aware the Terror mission unit tests are broken. They're next on my ToDo list, but I didn't think I'd have time to fix it tonight.
  

Edited November 25, 2007 by dteviot

[[dteviot]]

• ListSoldiersScreen shows craft soldier is assigned to
  
• Fixed Terror Mission Unit test
  
• Removed "cells" field from CombatantInventory
  
• Can now move between soldiers on EquipSoldierScreen
  
• add unit test to aircraft, to check soldiers are killed when aircraft carrying them is destroyed
  

Notes

• I believe this concludes the 0.3 feature list. (Except for any bugs that need fixing.)
  
• Yes, I'm aware that a condor can now carry 14 soldiers AND 2 x-caps (i.e. 16 combatants). Personally I think it's a feature, not a bug.
  
• Please let me know of any other bugs you find.
  
• Or any other features that we can/need to add that don't involve the battlescape.
  
• Other than that, I'm going to take a break for a couple of weeks. Catch up on my Game design reading, and try to come up with a plan for the battlescape.
  
• Ego stroking comments, like "What a great job you've done", would be nice.
  
• Constructive criticism, saying what I've done wrong and how it can be fixed, would be even more appreciated.
  
• And patches that include the fix would make me ecstatic.
  

Random thought:

Looking at Apocalypse vs X-COM 1, in Apoc, most of the buttons used icons, not text.

This has at least two advantages that I can see.

1. Don't need to worry about translating the text on the buttons.

2. Icons are smaller than text, so buttons can be smaller, giving more space on screen for other elements.

We should seriously consider using icon buttons for the UI.

[SupSuper]

• Ego stroking comments, like "What a great job you've done", would be nice.
  

I'll do you better. What an awesome job you've done.

I'll leave red knight to do the nitpicking.

 

Random thought:

Looking at Apocalypse vs X-COM 1, in Apoc, most of the buttons used icons, not text.

This has at least two advantages that I can see.

1. Don't need to worry about translating the text on the buttons.

2. Icons are smaller than text, so buttons can be smaller, giving more space on screen for other elements.

We should seriously consider using icon buttons for the UI.

Ugh, please don't, I hate icon UIs. They're cryptic, unflexible and unintuitive. And we have enough wasted space as it is.

[Guest Azrael Strife]

Literally and without exaggerating in complete awe of what you've done with PX, David keep it up!

 

I prefer icon based GUIs than text based ones, if made right they can be intuitive enough and I certainly enjoy the GUI of Apocalypse more than the one of X-Com1

Edited November 26, 2007 by Azrael Strife

[[Mad]]

I would agree to Sup. Icon GUIs are pretty cryptic, and it is difficult to make icons intuitively understandable for everyone. I for one hated the apocalypse GUI because it always took some time until you were that used to the pictograms that you didn't have to think three times before clicking anything.

 

Apart from this, I've said it before, but since you asked so nicely I'll say it again: You've done a really great job with the Xenocide code and the PRG team.