Planetscape Planning.xls

[[dteviot]]

If you want you can start with the XCOM style aircraft to aircraft combat. For tasks to do, take a look at the planetscape planification at the SVN. If you like to write, you can write the scope of the tasks in the planification and send it to me and Rincewind for corrections.

 

Greetings

Red Knight

We'll, I'm really not sure what do to for all the features in Planetscape Planning.xls. However, I'll have a go at "Research System", and possibly other people can contribute for other features.

 

Executive Summary:

Replicating the Research System (technology tree) in X-COM.

 

Summary:

1. Provide a technology tree.

2. Provide a way for user to create/maintain research projects from the technology tree.

3. Reward user with results of successful research projects.

 

Details:

From a conceptual viewpoint, a Research Project needs to:

1) Determine which projects can be initiated.

2) Determine which resources can be assigned to a project. (Resources could be any combination of people, facilities and bases.)

3) Allow player to assign resources to a project.

4) Allow for start-up costs for a project. (e.g. Money for construction, item for research.)

5) Track the resources being used by a project.

6) Display the resources being used by a project to player.

7) Allow player to add/remove resources from a project.

8) Allow player to cancel project.

9) Track progress of project, and display to user.

10) Calculate incremental progress on project, based on resources allocated and time elapsed.

11) "Reward" player on completion of project.

12) Release resources on completion of project.

[red knight]

Excelent there. Any taker for the others? Come on CTD Guys I know that you have what it takes to do this too (Ive seen you in action, or you dont dare to? ).

 

Greetings

Red Knight

[Guest Azrael]

Excelent there. Any taker for the others? Come on CTD Guys I know that you have what it takes to do this too (Ive seen you in action, or you dont dare to? ).

 

Greetings

Red Knight

<{POST_SNAPBACK}>

Aaargh, you know I can't resist a dare

I'll use David's layout...

 

Let's see

 

"Soldier Equipment System"

 

Executive Summary:

Replication of the Soldier Equipment System in X-Com with improvements.

 

Summary:

1. Allow for soldier equipment customisation.

2. Allow for saving of equipment configuration on soldiers.

 

Details:

The Soldier Equipment System needs to:

1) Determine which equipment slots are free and which ones are occupied by items. Free item slots can be used to house items, occupied, cannot.

2) Determine whether a specific item can fit in a given (free) item slot or not(For example, the system needs to realise that a Heavy Plasma cannot fit in the shoulder compartment, this specific part was buggy in X-Com, where soldiers could be found with plasma rifles in their pockets at times).

3) Automatically assign the correspondant clip item to a weapon assigned to the soldier by Player, if said clip is unavailable, it should display a warning message.

4) Check total items' weight and cross reference it with the strength of the soldier, display a message informing Player of the soldier's encumberance (Player should be aware that the soldier won't be able to move at all with the equipment he just gave him, note that this message should not be a window, but a message in the equipment screen itself).

5) Allow for Armor equipment (note that Armor is not a carryable item, so it cannot fit in an item slot).

6) Update Soldier Armor Values whenever Player assigns him an armor and display.

7) Allow for "manual" (by Player) unloading of loaded weapons and placement of unloaded clips into Base Stores ("Ground" on Battleview)

8) Allow for "manual" loading of weapons, verify that the clip corresponds to the weapon being loaded.

9) Display Soldiers' stats, such as rank, kills, etc.

10) Save information, a given soldier's equipment configuration should remain thorough missions unless it's changed by Player.

11) When soldier is in a base, solider can’t be equipped with items that have not been researched.

12) When soldier is in the battlescape, items can be exchanged between soldiers.

13) When soldier is in the battlescape, soldier can exchange items with the battlescape.

14) When soldier is in a base, soldier can exchange items with the base's inventory.

 

edit: added David's extra points.

Edited January 26, 2006 by Azrael

[red knight]

Well, I must say that was fast

 

Greetings

Red Knight

[Guest Azrael]

Added new section in the wiki, these features (those approved) will be posted here.

[Guest Azrael]

And here's my take on UFO Movement, hope it's good...

 

UFO Movement

 

Executive Summary:

Creation of UFO movement.

 

Summary:

1. Determine target destination.

2. Move to target destination.

 

Details:

1) Determine UFO mission type.

2) Determine destination (dependant on mission type, i.e. if it's a Terror Mission, the destination will be a city/town).

3) Spawn UFO at a pre-determined minimal distance from target destination (minimal distance should be dependant on game difficulty and mission type)

4) Set UFO Speed.

5) Proceed to target destination at set speed.

6) UFO starts mission at arriving at target destination, at this point the UFO is replaced with the correspondant mission pointer (Terror Site or Landed UFO).

7) When Mission is completed, respawn UFO at mission site.

8) Determine target "exit" point (this is to give Player the chance to intercept the UFO when it's leaving, ingame explanation would be that it's proceeding to leave the atmosphere), Exit Point should be at a preset minimal distance from Mission site (to give Player a chance to intercept).

9) Set UFO speed.

10) Proceed to Exit Point.

11) Remove UFO pointer when it arrives at Exit Point.

Edited January 21, 2006 by Azrael

[[dteviot]]

Excelent there. Any taker for the others? Come on CTD Guys I know that you have what it takes to do this too (Ive seen you in action, or you dont dare to? ).

 

Greetings

Red Knight

Aaargh, you know I can't resist a dare <_>

I'll use David's layout...

 

Let's see

 

"Soldier Equipment System"

 

Executive Summary:

Replication of the Soldier Equipment System in X-Com with improvements.

 

Summary:

1. Allow for soldier equipment customisation.

2. Allow for saving of equipment configuration on soldiers.

 

Details:

The Soldier Equipment System needs to:

1) Determine which equipment slots are free and which ones are occupied by items. Free item slots can be used to house items, occupied, cannot.

2) Determine whether a specific item can fit in a given (free) item slot or not(For example, the system needs to realise that a Heavy Plasma cannot fit in the shoulder compartment, this specific part was buggy in X-Com, where soldiers could be found with plasma rifles in their pockets at times).

3) Automatically assign the correspondant clip item to a weapon assigned to the soldier by Player, if said clip is unavailable, it should display a warning message.

4) Check total items' weight and cross reference it with the strength of the soldier, display a message informing Player of the soldier's encumberance (Player should be aware that the soldier won't be able to move at all with the equipment he just gave him, note that this message should not be a window, but a message in the equipment screen itself).

5) Allow for Armor equipment (note that Armor is not a carryable item, so it cannot fit in an item slot).

6) Update Soldier Armor Values whenever Player assigns him an armor and display.

7) Allow for "manual" (by Player) unloading of loaded weapons and placement of unloaded clips into Base Stores ("Ground" on Battleview)

8) Allow for "manual" loading of weapons, verify that the clip corresponds to the weapon being loaded.

9) Display Soldiers' stats, such as rank, kills, etc.

10) Save information, a given soldier's equipment configuration should remain thorough missions unless it's changed by Player.

Additional points:

11) When soldier is in a base, solider can’t be equipped with items that have not been researched.

12) When soldier is in the battlescape, items can be exchanged between soldiers.

13) When soldier is in the battlescape, soldier can exchange items with the battlescape.

14) When soldier is in a base, soldier can exchange items with the base's inventory.

[[dteviot]]

Manufacturing System

 

Executive Summary:

The bit in X-COM where you tell your Engineers to build items in the Workshops.

 

Summary:

1. Provide a list of items that can be built, and the costs of building them.

2. Provide a way for user to create/maintain manufacturing projects from the technology tree.

3. Give user items from successful manufacturing projects.

 

Details:

The Manufacturing System needs to:

1) Know the cost of building each item type, in terms of money, man-hours, and materials (usually xenium and composites, but might be others as well.)

2) Determine which items can currently be built, based on the technologies that have been researched. (post v1.0 may also depend on facilities available in a base.)

3) Determine which resources can be assigned to a project. (Resources could be any combination of people, facilities and bases.)

4) Allow player to assign resources to a project.

5) Allow for start-up costs for a project.

6) Track the resources being used by a project.

7) Display the resources being used by a project to user.

8) Allow user to add/remove resources from a project.

9) Allow user to cancel project.

10) Track progress of project, and display to user.

11) Calculate incremental progress on project, based on resources allocated and time elapsed.

12) "Reward" user on completion of project with the item.

13) Release resources on completion of project.

[amessier]

And here's my take on UFO Movement, hope it's good...

 

UFO Movement

 

Executive Summary:

Creation of UFO movement.

 

Summary:

1. Determine target destination.

2. Move to target destination.

 

Details:

1) Determine UFO mission type.

2) Determine destination (dependant on mission type, i.e. if it's a Terror Mission, the destination will be a city/town).

3) Spawn UFO at a pre-determined minimal distance from target destination (minimal distance should be dependant on game difficulty and mission type)

4) Set UFO Speed.

5) Proceed to target destination at set speed.

6) UFO starts mission at arriving at target destination, at this point the UFO is replaced with the correspondant mission pointer (Terror Site or Landed UFO).

7) When Mission is completed, respawn UFO at mission site.

8) Determine target "exit" point (this is to give Player the chance to intercept the UFO when it's leaving, ingame explanation would be that it's proceeding to leave the atmosphere), Exit Point should be at a preset minimal distance from Mission site (to give Player a chance to intercept).

9) Set UFO speed.

10) Proceed to Exit Point.

11) Remove UFO pointer when it arrives at Exit Point.

<{POST_SNAPBACK}>

 

 

Also after the UFO exits there should be a check by the player when they use the intercept patrol area to find the UFO... otherwise the intercepters patrol is going to be worthless. Unless its only purpose is to find alien bases

Edited January 22, 2006 by amessier

[Guest Azrael]

And here's my take on UFO Movement, hope it's good...

 

UFO Movement

 

Executive Summary:

Creation of UFO movement.

 

Summary:

1. Determine target destination.

2. Move to target destination.

 

Details:

1) Determine UFO mission type.

2) Determine destination (dependant on mission type, i.e. if it's a Terror Mission, the destination will be a city/town).

3) Spawn UFO at a pre-determined minimal distance from target destination (minimal distance should be dependant on game difficulty and mission type)

4) Set UFO Speed.

5) Proceed to target destination at set speed.

6) UFO starts mission at arriving at target destination, at this point the UFO is replaced with the correspondant mission pointer (Terror Site or Landed UFO).

7) When Mission is completed, respawn UFO at mission site.

8) Determine target "exit" point (this is to give Player the chance to intercept the UFO when it's leaving, ingame explanation would be that it's proceeding to leave the atmosphere), Exit Point should be at a preset minimal distance from Mission site (to give Player a chance to intercept).

9) Set UFO speed.

10) Proceed to Exit Point.

11) Remove UFO pointer when it arrives at Exit Point.

<{POST_SNAPBACK}>

 

 

Also after the UFO exits there should be a check by the player when they use the intercept patrol area to find the UFO... otherwise the intercepters patrol is going to be worthless. Unless its only purpose is to find alien bases

<{POST_SNAPBACK}>

It is, when mission is completed and the UFO reaches it's "exit point", the UFO is gone, can't be found through patrol (it's not in the game anymore).

And yes, patrol is only useful for finding Alien bases, though our patrol could be made more useful and allow setting of waypoints.

[[dteviot]]

Stupid questions time.

What's the difference between these three?

Items/Stores System

Hiring/Purchasing System

Transferring/Purchasing/Selling

 

From the notes, I assume that Hiring System should be seperated from Purchasing, so we this should be read as:

 

Items/Stores System

Purchasing System

Transferring/Purchasing/Selling

 

With Hiring as a separate feature?

[red knight]

Even though they can be implemented as different system, regarding the feature we plan to implement them in the same planification step. So it is completly probable that will end up as different systems, but planning tasks would show them as grouped.

 

Greetings

Red Knight

[[dteviot]]

Even though they can be implemented as different system, regarding the feature we plan to implement them in the same planification step. So it is completly probable that will end up as different systems, but planning tasks would show them as grouped.

 

Greetings

Red Knight

I'm sorry, I don't understand. Could you please clarify how they differ. E.g. what goes in "Purchasing System" that doesn't go in "Transferring/Purchasing/Selling"?

[red knight]

The Purchasing for Hiring was a mistake I realized after reading your last post.

 

Items/Stores System: Stock Items and playable properties of Items and Generic Stores (Soldier Inventory is just one of them).

Hiring System: The system that we use to hire soldiers/scientists/engineers (in V1 this is simple but it may not be so in the future, so we plan accordingly).

Transferring/Purchasing/Selling: The system used to purchase, transfer and sell items.

 

Hope that clears the mess up.

 

Greetings

Red Knight

Edited January 23, 2006 by red knight

[Guest Azrael]

Ok, here's more, please comment

 

"UFOs"

 

Executive Summary:

Creation of UFO units.

 

Summary:

1. UFO must follow the behaviour in UFO Movements.

2. UFO must follow the behaviour in UFO Interception.

3. UFO must follow the behaviour in UFO Attacks.

4. UFO must follow the behaviour in UFO Missions.

 

Details:

1) UFO is able to move following the UFO Movements behaviour.

2) UFO can be intercepted by Player craft, when intercepted, it must follow UFO Interception behaviour.

3) UFO can launch interception against Player craft, when it does, it must follow UFO Attacks behaviour.

4) UFO can launch Alien Missions (Terror, Abductions, etc), when it does, it must follow UFO missions behaviour.

 

-----------

"UFO Interception"

 

Executive Summary:

Interception of UFO units by Player craft.

 

Summary:

1. Determine UFO tactics (Aggressive, Normal, Evasive).

2. Conduct battle using determined UFO tactics.

Details:

1) Aggressive tactics means the UFO engages Player craft at short range. Normal tactics means UFO engages Player craft at medium range. Evasive tactics means the UFO tries to outrun the Player craft.

2) UFO can change tactics mid-battle.

3) When UFO tries to outrun Player craft, compare both craft's maximum speed, if the UFO's max speed is superior to Player Craft, UFO can outrun Player craft (Player's speed minus UFO max speed = outrun speed).

 

-----------

"UFO Missions"

 

Executive Summary:

Alien Missions conducted by UFOs.

 

Summary:

1. Determine UFO Mission type.

2. Move to Mission target location.

Details:

1) When Mission is selected, an appropiate location must be determined (a town for Alien Abductions, a city for Alien Terror, countryside for Alien Harvest, isolated place for Alien Base, Alien Bases for Alien Supply, Funding Countries' capitals for Alien Infiltration).

2) UFO must move to Mission site.

3) Determine whether Mission is detected or not by Player.

4) Terror Missions are always detected by Player.

5) When UFO arrives at Mission site, start Mission.

6) Depending on game difficulty, there is pre-determined time until Mission is considered to be accomplished.

7) If Player attends to Mission site, and fails to kill all Alien units, Mission ends prematurely, UFO is respawned and leaves.

8) If Player attends to Mission site, and kills all Alien units, Mission ends prematurely, UFO is not respawned.

9) All missions's success, except Alien Infiltration, depend on UFO staying on Mission site for a predetermined time without Player attending to site.

10) If successful, Alien Base missions create a new Alien Base.

11) If successful, Terror Missions greatly raise fear in the country attacked, raising porcentage of Alien Infiltration success.

12) If successful, Alien Harvest Missions slightly raise fear in the Country attacked.

13) If successful, Alien Abductions Missions moderately raise fear in the country attacked.

14) Alien Infiltration Mission's success depends on target country's overall fear (Alien Terror % + Alien Harvest % + Alien Abductions % + standard value = Fear or chance of Alien Infiltration Success).

15) If successful, Alien Infiltration Missions cause target country to cease funding.

16) If successful, Alien Supply Missions extend target Alien Base's useful life for a certain amount.

17) If an Alien Base is not supplied for a determined time, remove Alien Base.

Edited January 26, 2006 by Azrael

[Darkhomb]

1) Aggressive tactics means the UFO engages Player craft at short range. Normal tactics means UFO engages Player craft at medium range. Evasive tactics means the UFO tries to outrun the Player craft.

 

 

I thought the player determines the range? You could choose aggresive, standard or cautious. As aggresive brings you in close. standard brings you to where both weapons can fire. cautious brings you to where only your farthest range can hit. The only thing the ufo can do is flee or fight (at the range you choose)

[Guest Azrael]

1) Aggressive tactics means the UFO engages Player craft at short range. Normal tactics means UFO engages Player craft at medium range. Evasive tactics means the UFO tries to outrun the Player craft.

 

<{POST_SNAPBACK}>

 

I thought the player determines the range? You could choose aggresive, standard or cautious. As aggresive brings you in close. standard brings you to where both weapons can fire. cautious brings you to where only your farthest range can hit. The only thing the ufo can do is flee or fight (at the range you choose)

<{POST_SNAPBACK}>

Good point, then it's either Aggressive (or standard), which means UFO will fight back, and Evasive which means the UFO will try to flee

[kafros]

Sometimes, the UFO would just reach maximum distance away from you, but not flee (and end the interception). I think the same happened when your ship took too much damage in one UFO shot (i.e. 70% damage due to a battleship's attack).

 

Azrael, do you write these according to existing PRG Dep's decisions, or you write ideas that should be implemented?

[Guest Azrael]

Sometimes, the UFO would just reach maximum distance away from you, but not flee (and end the interception). I think the same happened when your ship took too much damage in one UFO shot (i.e. 70% damage due to a battleship's attack).

 

Azrael, do you write these according to existing PRG Dep's decisions, or you write ideas that should be implemented?

<{POST_SNAPBACK}>

According to the way it was in X-Com with minor improvements (i.e. saving equipment configuration to prevent having to rearm each freaking soldier every single time).

Nothing that would be considered V1+

[red knight]

Azrael, if there is no more discussion, promote all the executive summaries and update the planning spreedsheet with a link to the wiki site where all this information is stored.

 

Greetings

Red Knight

[Guest Azrael]

What about the ones David and I posted? I'm still waiting for someone's approval before doing more (now I don't have a lot of time, but I could keep writing them once I do)

[red knight]

I meant all the ones that are already here yours and david ones. Go on writting them when you have time. Other volunteers?

 

Greetings

Red Knight

[[dteviot]]

I meant all the ones that are already here yours and david ones. Go on writting them when you have time. Other volunteers?

 

Greetings

Red Knight

I believe I know why on the Xenocide team the left hand doesn't know what the right is doing. Based on the limited response to these docs, I'm forced to conclude it's becuase in most cases the right hand doesn't know what its doing.

 

Seriously people, this sort of documentation is the VERY FIRST thing that should be written, before the code gets touched. If you know what you're going to do, it should not take very long to write one of these docs up (about an hour.) And if you can't write one up, then you shouldn't be touching the code, because you don't know what you're trying to achieve.

[red knight]

Indeed that is why I impulse this definitions and discuss the design before starting to code. I cannot do all this stuff myself (even if I would like because I cannot be anywhere and current work is killing me but at least I am able to get resources from my employeers ), that is why I ask for volunteers; furthermore the important thing here is that this type of documents are made from several sources to uncover general implicit thinking from the ones that write them.

 

On the other hand, we didnt wrote them before because we where sticking completly to XCom 1, however recent changes in gameplay (small but changes anyway) has forced us to uncover all that implicit design once and for all.

 

BTW I had updated the other day the ones that where posted in here.

 

Greetings

Red Knight

Edited February 7, 2006 by red knight

[M4st3r]

Craft Inventory :

 

Main goal : Recreate craft inventory

 

Steps :

 

- Make sure equipement weight and it's size isn't too big.

- Think of HWPs as items

- Store craft weapons, with their ammo quanitites

- All weapons are unloaded when transporting

- Store fuel

- When returning from mission also store captives and corpses

Edited February 16, 2006 by M4st3r

[red knight]

"Items/Stores System"

 

Executive Summary:

The inventory systems do stock control, assignment of items to their respective stores. An story can be the inventory of the warehouses, the inventory of a character or an equipped aircraft.

 

Summary:

1. Being able to define an store independently of who will have it (warehouse, individual, or aircraft).

2. Being able to manipulate those stores (put and take out items).

 

Details:

 

1) An storage can have size boundaries or not, it may be composed of multiple storages with specific inclusion criteria.

2) Some items may be composed of multiple items (Weapon and Ammo example)

3) Fuel can be an storable???

4) When returning from mission also store captives and corpses.

5) HWPs are items.

6) All composed items are disassembled when transporting, except craft weapons.

7) Some storages may have an position for their items.

Edited February 16, 2006 by red knight

[[dteviot]]

"Items/Stores System"

 

Executive Summary:

The inventory systems do stock control, assignment of items to their respective stores. A store can be the inventory of the warehouses, the inventory of a character or an equipped aircraft.

I think a battlescape is also a store

 

 

6) All composed items are disassembled when transporting, except craft weapons.

Can you clarify what you mean by transporting? I think you mean transfering between bases.

[red knight]

Or between missions.

 

Greetings

Red Knight

[[dteviot]]

Craft Inventory :

 

Main goal : Recreate craft inventory

 

Steps :

 

- Make sure equipement weight and it's size isn't too big.

- Think of HWPs as items

- Store craft weapons, with their ammo quanitites

- All weapons are unloaded when transporting

- Store fuel

- When returning from mission also store captives and corpses

I don't believe there's a weight limit for items in a craft. There's just a limit in the number of "slots" that craft weapons can be mounted on.

Likewise, there's a limit on the number of troops per craft, but I don't think that's part of the inventory. And on a craft HWPs count as troops, not items. It's only in a base that they count as items. For purposes of storage, construction, transfer, etc. Once assigned to a craft, they're no longer in the base's storage.

[M4st3r]

I think there should be a weight limit for crafts, or even we can say more : there should be only a weight limit. You don't think that flying with 20 rifle clips is same effect when you're flying with 20 dead, made of iron sectopods, do you ? It can affect craft speed IMO. HWP are both items and soldiers.

 

In base items are also no-loaded, so when transferring, you transfer without clips, same about flying to\returning from a mission.

 

Small Conclusion : Items can be loaded ONLY in battlescape.

 

And I agree as battlescape is a big store, which can hold items, I only see thing that we can make container of laying items and their positions.

[[dteviot]]

I think there should be a weight limit for crafts, or even we can say more : there should be only a weight limit. You don't think that flying with 20 rifle clips is same effect when you're flying with 20 dead, made of iron sectopods, do you ? It can affect craft speed IMO. HWP are both items and soldiers.

 

In base items are also no-loaded, so when transferring, you transfer without clips, same about flying to\returning from a mission.

 

Small Conclusion : Items can be loaded ONLY in battlescape.

 

And I agree as battlescape is a big store, which can hold items, I only see thing that we can make container of laying items and their positions.

Actually, items can also be loaded when in a soldier's inventory.

But I think I see what you're talking about here. You're referring to the craft carrying the items recovered from a mission. Now think about the implications of putting a weight limit on a craft. This means that after a mission, a player may not be able to recover all the items (including captives) from a mission. You're going to be lynched if you try doing that.

[M4st3r]

IMO it's not so bad, and it enforces some management of your space.

For example :

 

We take 8 Hplasmas and 16 clips for it, 1 HWP,8 soldiers. (Let's assume it's 20% space).

Then we go on the mission, win it, get 10 floaters dead and 5 reapers dead, and their weapons. It'd take 70% capacity, and it's OK. And MAX CAPACITY (which would stop craft for flying) is 150%. So you can actually have 149% recovery, and your ship will return (with speed 2%, but will).

 

Items can be loaded ONLY in battleVIEW.

-> it's the way how it should look like.

 

Limits :

 

BASE - store capacity (AFAIK 50 items per store)

CRAFT - weight of items

TROOPS - weight and slot limit

Edited February 17, 2006 by M4st3r

[Garo]

Items can be loaded ONLY in battleVIEW.

-> it's the way how it should look like.

 

I disagree with this. We should at least plan that in the future, the layouts of individual soldiers can be preselected at base, or to have different basic user customisable layouts which can be then assigned easily at the beginning of the mission etc.

 

- Garo

[M4st3r]

Clips ARE assigned to weapons in base, but they are NOT loaded, so you can't fit 50 clips + 50 weapons in 50 items.

[[dteviot]]

Or between missions.

 

Greetings

Red Knight

I think I figured out why this was confusing me. You’re referring to the items used to equip the soldiers when they hit the mission site. Is this necessary? One of the things I really HATED about X-COM 1 & 2 was that you needed to re-equip the soldiers at the start of every mission. I’d propose that for a craft going on a mission, the equipment is carried by the soldiers themselves, not by the craft. That is, you equip the soldiers in base, and they keep those items (reloading when they return to base.)

 

Thus, the only items in a craft’s inventory are the craft’s weapon pods. I know, with the newer aircraft, weapons are stored in internal bays, to reduce radar signature. However, for game purposes we’re probably going to want to put the weapons in external pods, so there’s a visible difference.

[[dteviot]]

Hiring System

 

(Question, how does this differ from personnel, item 2 on Planetscape Planning.xls?)

 

Executive Summary:

The bit in X-COM where you Hire, Fire & Transfer Personnel.

 

Summary:

1. There are at least 3 types of personnel. Soldiers, Scientists and Engineers.

2. The hiring system only deals with hiring, firing, housing in bases, and transferring between bases. It does not include: assigning Scientists and Engineers to projects, nor equipping, training, or assigning to craft of soldiers.

 

Details:

1. Player can hire soldiers, scientists and engineers.

2. At time of hire, player assigns personnel to bases.

3. Player may not assign (or hire) personnel for bases that do not have accommodation for them.

4. Player must have sufficient funds to hire personnel.

5. Hiring a person costs a month’s wages. Payable the instant the person is hired.

6. There is a limit on the number of people available for hire. Each day a number (configurable) of candidates for hiring will be created. These people will remain available for hiring for a (configurable) period of time (probably a week or so.) After this time, they will disappear.

7. v1.0 all engineers and scientists have equal skill at time of recruitment.

8. v1.0 soldiers do NOT have equal skill at time of recruitment.

9. post v1.0, the bias factors for randomly creating the available candidates may change as game progresses. (e.g. elite SAS or Spetsnaz troops may become available/unavailable for recruitment depending on current relationship with various countries.)

10. Personnel are paid their wages in advance. On the first day of the month, for the month. Thus, wages can never get into arrears. If there are insufficient funds at the start of the month to pay the wages for the month, what happens? (Suggestion, staff go on strike until they’re paid.)

11. Personnel will never quit?

12. When a base is overrun, all personnel present at the base are killed. (What to do with personnel on craft not in the base? Are potential issues with having no space in other bases for the survivors?)

13. When hot-bunking occurs in a base (more than 25 people per barracks) productivity drops (soldiers don’t train or heal as well) and monthly wages increase by 50%.

14. v1.0, all people of a specific type (engineer, scientist, soldier) are paid the same wage, based on their type.

[[dteviot]]

BASE - store capacity (AFAIK 50 items per store)

With XCOM, each storeroom had a capacity of 50 UNITS (not items), with the smallest item (a pistol clip) having a size of 0.1 unit. Because I prefer to avoid floats where possible, the storeroom now has a capacity of 500 units, and a pistol clip a size of 1 unit.

[reist]

The inventory and item system (NULL level definition of "WHAT it is supposed to do?")

 

Abstract:

The inventory and item system will allow items to be created and stored in inventories as well as manipulate those items.

 

 

Item

 

Abstract

An item is an object that can be transported.

 

Requirements:

- An item can only exist inside a inventory.

- An item can be produced.

- An item can be consumed.

 

 

Inventory:

 

Abstract:

An inventory is a location that can store items.

 

Requirements

- An inventory can store items.

- An inventory can add produced items. (if inventory criteria have been met)

- An inventory can lookup an item.

- An inventory can consume an item.

- Inventories can transport items between each other. (if inventory criteria have been met)

 

 

Inventory Criteria

 

Abstract:

Inventory criteria are condition(s) to be met to allow an item to be stored in an inventory.

[[dteviot]]

Craft Management

 

(Chunks of this have been stolen without permission from Rincewind and M4st3r)

 

Executive Summary

Craft management involves the arming of the aircraft, information required by the simulation tasks like fuel, armour, etc.

 

Summary

1. Allow player to specify and change craft “payload”. (Fuel, Craft weapons, ammo for craft weapons, and soldiers.)

2. Track consumption of fuel and munitions during a mission.

3. It does NOT include sending craft on missions, but does include tracking the “repair state” of a craft.

4. Craft management does NOT include items carried by solders. (For v1.0, we’re NOT going or re-arm soldiers when the craft carrying the soldiers arrives at a mission site. I.e. the soldiers carry their own equipment in the craft.)

5. Craft management does NOT include transport of recovered items back to a base after a mission. (We’re going to assume these items are sent by FedEx.)

 

Details

1. Need XML file that describes the payload capability of each craft type.

2. The ammo used by a craft weapon is carried in the weapon. Craft do not have magazines to carry additional ammo for their weapons.

3. Craft are automatically refuelled when they return to their home base, provided fuel is available. (Hydrogen fuel is always available, provided there is a landing pad in the base.) It takes 30 minutes to completely refuel a craft with empty tanks. Player can dispatch a craft on a mission before refuelling is complete.

4. Craft weapons are automatically reloaded when they return to their home base, provided ammo is available. For v1.0, reloading is instantaneous.

5. Repair of damaged craft begins automatically when they return to their base. Player can dispatch a craft on a mission before repair is complete. Repair time is based on damage %, and craft construction time. A 50% damaged craft will take time equal to construction time to repair.

6. Player can assign (and remove) soldiers to a craft, up to the craft’s limit. Changes occur instantaneously. Soldiers must be present in same base as craft. Changing the soldiers assigned to a craft can only occur when a craft is "parked" in its base. Viewing the soldiers assigned to a craft can be done at any time.

7. Player can add (and remove) craft weapons from a craft. Subject to limits of number (and types?) of weapons craft is able to carry. Hard points CAN be empty. For v1.0, re-equipping is instantaneous. Changing a craft's equipment can only occur when a craft is "parked" in its base. Viewing a craft's equipment, fuel remaining, and damage levels can occur at any time.

8. Player can name and rename craft. Names must be unique. (This is to allow the player to easily distinguish between craft.)

9. A base can only have 1 craft per landing pad.

10. Transferring craft between bases is covered under transfer. (A craft must always be assigned to a base.)

11. Initially, a craft is assigned to the base selected when it was purchased.

12. A craft OWNS the weapons it is equipped with. They don’t count as part of the base.

13. It’s NOT possible to remove fuel from a craft. (e.g. You can’t strip it of Xenium prior to sale.)

14. A purchased (or constructed) craft is delivered with no weapons and empty fuel tanks.

 

 

Misc Details

Craft management properties:

1. Soldier capacity. (Number of troops) HWPs count as 4 troops.

2. Number (type? location?) of hard points/bays/pods for mounting weapons on craft. Questions: What term are we going to settle on for describing these? Are the hard points going to differ in what they can hold? E.g. only wing hard points can carry missiles? How do we describe WHERE a hard point is? How do we show the weapons mounted on a craft? (Artwork)

3. Fuel type, maximum fuel capacity, current fuel capacity, fuel consumption rate.

4. Max “hit points” and current “hit points”

 

Questions

1. What happens to a craft if the base it is assigned to is destroyed by aliens? Ideally we fly it to another base, but that’s tricky. What if it has insufficient fuel, or there ARE no other bases with spare landing pads?

 

Edit 2006-03-07: Added Bases with landing pads always have hydrogen fuel.

Edit 2006-03-10: Changing craft loadout only possible when craft "parked" in its homebase

Edited March 9, 2006 by dteviot

[[dteviot]]

Craft Movement

 

Executive Summary

Craft movement involves the ability to render and give orders to any human craft.

 

Summary

1. Allow player to send craft on missions.

2. Display craft on missions in the planetscape.

3. Display craft mission data in the planetscape

 

Details

1. Player can assign a craft to a mission at any time. (Craft may be in a base, or already on a mission.

2. Globe displays icon giving approximate location of each craft not in a base.

3. Player can request a graphical display of any craft’s operational range on the globe.

4. Player can request a display of any human or UFOs craft’s predicted course on the globe.

5. Any mission will automatically be “postponed” when a craft runs low on fuel. (Low on fuel meaning the craft only has sufficient fuel to reach the nearest XCORP base with a landing pad.) The craft will head for the nearest base, refuel, then resume current mission. The base does not require a landing pad to be empty for this to work.

 

Mission Types

1. Intercept UFO. Player selects a UFO. Engine attempts to predict the UFO’s course and calculates a minimum time intercept course. (prediction is updated every 10 minutes.) Mission ends when: craft reaches predicted destination. Will automatically change to Attack UFO or land soldiers if get close enough to UFO. (Question. Can craft attack a landed UFO?)

2. Follow UFO. Craft always flies towards UFOs current location. Will try to maintain distance of 100km from UFO. Mission ends if loose track of UFO.

3. Fly patrol. Player establishes a patrol path (by giving a series of locations on the globe.) Craft will fly between the points, returning to base when fuel is sufficiently low. (Setting patrol paths is independent of craft.) e.g. Player can create several patrol paths, then assign multiple craft to each path.

4. Attack UFO. Can only be used if craft is sufficiently close to a UFO.

5. Return to Base.

6. Land soldiers at terror site/crashed UFO/landed UFO.

[centurion]

1. How do we handle hydrogen fuel stored in a base?  It’s not practicable to regard it as another item in a base’s storeroom, unlike xenium.  How is this done in X-COM 1?

2. What happens to a craft if the base it is assigned to is destroyed by aliens? Ideally we fly it to another base, but that’s tricky.  What if it has insufficient fuel, or there ARE no other bases with spare landing pads?

1. In X-COM1, fuel was created from thin air and never observed. If we don't want to use this method of handling it, then it should be a regular item.

 

2. I was told that in X-COM1, the craft returned normally and you got to replay the assault again I guess we should destroy the craft if it doesn't have enough fuel to reach the closest base; if there aren't any free hangars within range, then the simple solution is to destroy the craft, and the fair solution is to let it be redirected and prompt the player to arrange for an empty hangar themselves (or just indicate that without micromanagement the craft will be lost). Allowing refuels without being assigned to a hangar like in

5. Any mission will automatically be “postponed” when a craft runs low on fuel. (Low on fuel meaning the craft only has sufficient fuel to reach the nearest XCORP base with a landing pad.) The craft will head for the nearest base, refuel, then resume current mission. The base does not require a landing pad to be empty for this to work

is going to cause problems there, essentially forcing the V1.0+ handling of crafts and hangars.

[[Mad]]

This is a try to define "player". I have no idea if this is enough or way to much, so please comment.

 

Player

 

Executive summary:

The player is the general abstraction of the user, his profile, save games, special options, in game information, etc.

 

Summary:

1) Allow saving (and loading) of game options like gfx, snd settings and key bindings

2) Allow saving (and loading) of gamestate

3) Provide autosave

4) Provide player exclusive savegame slots

 

 

Details:

1) Allow saving (and loading) of game options like gfx, snd settings and key bindings

2) Allow saving (and loading) of gamestate distinguishing between

I) Geoscape savegame including

a) time

position of globe rotation

c) position of bases and vehicles (i.e. crafts) on the globe (human as well as alien)

d) state of bases

e) inventory/items/stores state

f) hired (active and inactive) personel and their assignment to bases, squads, vehicles, laboratorys etc.

g) status of vehicles

h) score (monthly and total)

i) status of ufopaedia

j) status of production and research

k) funds and funding

l) statistiscs of alien and X-Corps activity

 

II) Battlescape (aeroscape) including

a) round

map

c) position of camera on map

d) position of buildings and their type on map

e) position of crafts and their type on map

f) position of units (and their type) on the map

g) stats of units including spent TUs

h) inventory of units, including number of shots left in clips etc.

i) selected player unit

 

3) Provide autosave in different slots (so that one autosave doesn't override the previous) every 10 minutes or before every mission (whatever occurs first).

4) Provide infinite saving slots, bound to the player (so another player gets an empty "savegames list")

Edited March 4, 2006 by Mad

[[dteviot]]

This is a try to define "player". I have no idea if this is enough or way to much, so please comment.

 

Player

 

Executive summary:

The player is the general abstraction of the user, his profile, save games, special options, in game information, etc.

 

Summary:

1) Allow saving (and loading) of game options like gfx, snd settings and key bindings

2) Allow saving (and loading) of gamestate

3) Provide autosave

4) Provide player exclusive savegame slots

 

 

Details:

1) Allow saving (and loading) of game options like gfx, snd settings and key bindings

2) Allow saving (and loading) of gamestate distinguishing between

  I) Geoscape savegame including

      a) time

      position of globe rotation

      c) position of bases and vehicles (i.e. crafts) on the globe (human as well as alien)

      d) state of bases

      e) inventory/items/stores state

      f) hired (active and inactive) personel and their assignment to bases, squads, vehicles, laboratorys etc.

      g) status of vehicles

      h) score (monthly and total)

      i) status of ufopaedia

      j) status of production and research

      k) funds and funding

      l) statistiscs of alien and X-Corps activity

 

  II) Battlescape (aeroscape) including

      a) round

      map

      c) position of camera on map

      d) position of buildings and their type on map

      e) position of crafts and their type on map

      f) position of units (and their type) on the map

      g) stats of units including spent TUs

      h) inventory of units, including number of shots left in clips etc.

      i) selected player unit

 

3) Provide autosave in different slots (so that one autosave doesn't override the previous) every 10 minutes or before every mission (whatever occurs first).

4) Provide infinite saving slots, bound to the player (so another player gets an empty "savegames list")

 

I'll add the following from one of Garo's old posts:

 

Here are the things Coffee.gif which are unique for a single player entity.

- List of bases -> entry point to every base which the player has

- Research system: What technology the player already has and what's on the progress

- List of personnel. this includes soldiers, engineers, scientists etc

- Money

- Monthly incomings from all countries

- PDL (Player Detection Layer), what the player currently sees in the planetscape

 

I'm thinking that the Player class in the main entrypoint to all items in that list.

I know that overplanning is a sin, but I think we should try to keep the Player class behave not like a Singleton, so that we reserve the possibility that we could have multiple player class instances in the future. And I'm not talking about alien instances.

 

After all, mainly only "List of bases" and PDL are the only common thing to a Human player (a Player class instance) and to the Overmind AI. Every else is relevant only to a human player: The aliens dont have money, they don't get money from goverments and they have infinite resource of new alien soldiers but not engineers or scientists. Also the aliens develop new tech by some sort of triggers and not by researching (member, the humans are researching alien tech and not the opposite way)

 

So, the Player class:

- Utilities to iterate over all bases.

- Entry point to the research subsystem, which has methods to query currently available tech etc.

- Entry point to the Personnel class, which contains all personels which the player owns.

- Simple long POD (Plain Old Data) which holds the current money

- Entry point to a class/subsystem which holds the amounts what each country gives each month.

- Entry point to the PDL, which holds the view to the Globe (what player can see)

[red knight]

Saving is just an orthogonal feature named as Save Game State, I am more interesting in things like:

 

- Research Tree

- Bases

- Monthly Score, Total Score

 

etc.

 

I would unify this two:

i) status of ufopaedia

j) status of production and research

Into:

 

- Research and Production Tree Handling

 

Greetings

Red Knight

[[dteviot]]

Countries/Score/Funding

 

As I see it, while these have been given three separate entries, they are sufficiently tightly coupled that they can be considered as one entry. (If people disagree, they are welcome to expand and separate this summary.)

 

Executive Summary

Tracking how well the player is doing, and adjusting funding accordingly

 

Summary

1. Provide a way of subdividing the globe into “regions”.

2. Provide a way of tracking player’s “progress” in each region.

3. Provide a way of funding player, based on player’s progress.

 

 

Details

1. XML file needs to designate geographical “regions” on the globe.

2. XML file indicates mappings between “regions” and “countries” (for v1.0, mapping is 1 to 1. i.e. Each region represents a country.)

3. XML specifies the base funding that XCORP will receive from each country.

4. The planetscape graphics engine can display the regions on the globe (when player requests.)

5. Over each month of “game time”, the simulation engine keeps a running total of xcorp and alien activity for each region. (I assume mission types are .)

6. At the end of each month, calculate player’s score for each region, based on alien activity. Probably simplest way is just have XML file that says “for each alien mission type, the player gets X points if mission is success, and loses Y points if it’s a failure.” At this information to the monthly statistics engine for storage.

7. At end of month, adjust player’s standing for each region, based on the player’s score for each region. At this information to the monthly statistics engine for storage.

8. At the end of each month, calculate the funds that XCORP should be paid from each region (based on player’s standing and the base funding.) Adds this to the player’s available funds. At this information to the monthly statistics engine for storage.

9. Display dialog summarising; alien activity, player’s standing in the regions, and monthly funding.

 

 

From Red Knight:

Countries

Involves the definition of the countries and their area of influence such that the simulation engine know how to work out the scoring details, the country representation so it can rendered, etc.

Score

The score system is the heart of the scoring system, it will integrate the UFO moving patterns and XCorps activities to calculate the score value that will give the final funding change every month

 

Funding

The funding system integrates the scores given by the simulation engine and performs the required adaptations at the end of the month about how much the countries will pay you.

[[Mad]]

Saving is just an orthogonal feature named as Save Game State, I am more interesting in things like:

 

- Research Tree

- Bases

- Monthly Score, Total Score

You will find all of those under the save feature... The question is, are they needed somewhere else? Or to start from the other side: is "player" just needed for save operation, because "in game" everything runs on a "deeper" level, or is "player" the abstraction Layer for everything visible to the Player in the game?

I don't see a reason for the second definition, because this would be a definition of all input/output modules of the game, wouldn't it?

 

---Edit---

After all, I'm no programmer, so it's highly likely I got sth. wrong. So if I get you correct RK, you would suggest all the points I summed up under "Save..." to be independent points of their own, and saving only left as "referer" to Save Game State?

 

Countries/Score/Funding

 

As I see it, while these have been given three separate entries, they are sufficiently tightly coupled that they can be considered as one entry.  (If people disagree, they are welcome to expand and separate this summary.)

Well, as I see it, they are closely related, but shouldn't go in one entry, because, your funding does not only work on a monthly basis, like the score does, but it is some kind of "summary" of all previous months.

Edited March 5, 2006 by Mad

[red knight]

dteviot, it is ok to sum them up in the same task.

 

Mad: You are right, those are 2 posibilities, I focused on player from the programmatic interface but it can be from the "Player" as the ability of the player to be recognized and interact with the "Game". Things like Save, Load, Profile, etc.

 

Lets do the following, stick to the second definition and then if we need the more programmatic way we add a new task for it.

 

Greetings

Red Knight

[[dteviot]]

Countries/Score/Funding

 

As I see it, while these have been given three separate entries, they are sufficiently tightly coupled that they can be considered as one entry.  (If people disagree, they are welcome to expand and separate this summary.)

Well, as I see it, they are closely related, but shouldn't go in one entry, because, your funding does not only work on a monthly basis, like the score does, but it is some kind of "summary" of all previous months.

Mad,

I think possibly you're mixing the concept of "player's available funds which can be spent at any time", with "money given to player at end of month, as reward for progress". You're thinking of the first, while I'm thinking of the second.

[[Mad]]

I think possibly you're mixing the concept of "player's available funds which can be spent at any time", with "money given to player at end of month, as reward for progress".  You're thinking of the first, while I'm thinking of the second.

True. Messed it up. Sorry

 

RedKnight: Ok, so do I get you right if I just leave everything as it is and just polish it up? I need to go to University now, will be back in aprox. eight hours. I will then work on and post a new version.

 

Edit: messed up with my own brain, posted strange answer to dteviot. Clearified now.

Edited March 6, 2006 by Mad

[[Mad]]

I tried to include everyones thoughts, please have a look.

 

Player

Executive summary:
The player is the general abstraction of the user, his profile, save games, special  options, in game information, etc.

Summary:
1) Allow saving (and loading) of game options like gfx, snd settings and key bindings
2) Allow saving (and loading) of gamestate
3) Provide autosave
4) Provide player exclusive savegame slots
5) Provide profile


Details:
1) Allow saving (and loading) of game options like gfx, snd settings and key bindings
2) Allow saving (and loading) of gamestate distinguishing between
   I) Geoscape savegame including
      a) time
      b) position of globe rotation
      c) List of bases -> entry point to every base which the player has   
      d) Player detection level (position of bases and vehicles (i.e. crafts) on the globe (human as well as alien))
      e) state of bases
      f) inventory/items/stores state
      g) List of personel: hired (active and inactive) personel and their assignment to bases, squads, vehicles, laboratorys etc.
      h) status of vehicles
      i) score (monthly and total) and resulting from the score the
      j) funding
      k) Research System: Research and Production Tree Handling
      l) funds
      m) statistiscs of alien and X-Corps activity

   II) Battlescape (aeroscape) including
      a) round
      b) map
      c) Player detection level (of Battlescape, if there is an equivalent): position of camera on map, including fog of war if implemented
      d) position of buildings and their type on map
      e) position of crafts and their type on map
      f) position of units (and their type) on the map resulting in possibility to calculate line of sight, thus making the saving of "what units is the player able to see" of the Player detection level unnecessary.
      g) stats of units including spent TUs
      h) inventory of units, including number of shots left in clips etc.
      i) selected player unit

3) Provide autosave in different slots (so that one autosave doesn't override the previous) every 10 minutes or before every mission (whatever occurs first).
4) Provide infinite saving slots, bound to the player (so another player gets an empty "savegames list")
5) Provide profile, as aggregation of the above mentioned features individually for each Player.

 

Edit: looks nicer when in "code" mode

Edit2: We could run into a problem using my definition of "profile" as soon as we want to implement multiplayer, because until now, it does not really include distinguishing between different Players on the Geo- or Battlescape level.

Edited March 6, 2006 by Mad