Jump to content
XCOMUFO & Xenocide

Planetscape Planning.xls


dteviot

Recommended Posts

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 :wacko: 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.

I think we will just assume that each landing pad comes equiped with electrolysis (SP?) gear, and can create hydrogen fuel on demand from the base's water supply. So no need for it to be an item in the stores. I.e. we always have a free, unlimited supply of hydrogen fuel for our craft, just as in XCOM 1.

 

I don't think using bases as "gas stations" is going to be a problem, because we model it as the craft isn'in the base. It's parked on the surface. It's not OWNED by the base during the refueling.

Link to comment
Share on other sites

  • Replies 107
  • Created
  • Last Reply

Top Posters In This Topic

Then it would probably be best to add the ability to land to the crafts, so they will be simply sent to land at the closest base if the owner is out of range.

 

edit: a landed craft would not consume fuel, but will have its detection range reduced (eliminated?) and the personnel onboard will have their training suspended or something, to make stationing them off-base in a troop carrier less attractive.

Edited by centurion
Link to comment
Share on other sites

Then it would probably be best to add the ability to land to the crafts, so they will be simply sent to land at the closest base if the owner is out of range.

 

edit: a landed craft would not consume fuel, but will have its detection range reduced (eliminated?) and the personnel onboard will have their training suspended or something, to make stationing them off-base in a troop carrier less attractive.

This would give use two "landed" states. "landed at a not-home base" and "landed". The distinction being the "landed at a not-home base" means craft is refueled (and re-armed) while "landed" just doesn't consume fuel. But it occurs to me that landed might be useful. Land near a mission site at night, then wait for dawn before engaging.

Does anyone else think it has value?

Link to comment
Share on other sites

This would give use two "landed" states.  "landed at a not-home base" and "landed".  The distinction being the "landed at a not-home base" means craft is refueled (and re-armed) while "landed" just doesn't consume fuel.  But it occurs to me that landed might be useful.  Land near a mission site at night, then wait for dawn before engaging.

Does anyone else think it has value?

Yea really sounds good. Should be limited to crafts with vertical takeoff ability though if we some day choose to include normal planes...

Link to comment
Share on other sites

Personnel

 

I’m really not sure what I’m supposed to say here, so be nice. Red Knight, if I’ve got it wrong, please give me a bigger hint about what sort of things are supposed to be here.

 

Executive Summary

From R.K: “Personnel tasks involves the definition/creation of the Scientists, Engineers and Soldiers cluster to be used in the game.”

Translation, describe Engineers, Scientists and Soldiers, their attributes, and their functions.

 

 

Details

1. There are 3 types of “personnel” - (Not counting the bystanders at a mission sites.)

2. All people have the following attributes: (I’ve taken these from apocalypse, if someone want to change it to X-COM 1 stats, by all means.)

a. Monthly Salary

b. Name

c. Sex

d. Max Health

e. Current Health

f. Accuracy

g. Reactions

h. Speed

i. Stamina

j. Bravery

k. Strength

l. Psi-energy

m. Psi-attack

n. Psi-defense

o. Engineering skill

p. Research skill

3. People may also have an “inventory” of items they are carrying.

4. People may also wear armour.

5. Monthly Salary is described further under “Hiring System”

6. Every person has a unique name.

7. Sex is either “Male” or “Female”. post v1.0, sex may have influence on starting stats, for v1.0, is purely cosmetic.

8. v1.0 The remaining attributes have a value between 0 and 100, inclusive.

9. v1.0 All engineers have an engineering skill of 100. Scientists and Soldiers have 0.

10. In later versions, engineers may have differing engineering skill values. And may even be able to improve their engineering skill.

11. v1.0 All scientists have a research skill of 100. Engineers and Soldiers have 0.

12. In later versions, scientists may have differing research skill values. And may even be able to improve their research skill.

13. All engineers and scientists have the same values for values d to p. An XML file gives the values for these. (Note. For most purposes, we don’t care what these values are, they’re only important if a base is invaded and the Scientists and Engineers have to defend the base.)

14. Soldiers have different values for d to p. Starting values are detailed in “Hiring System”.

15. Over time, a soldier can increase (or possibly decrease) various attributes. This is detailed further under “Training system”

16. Meaning of attributes: d to n are really only of relevance in the battlescape, but are detailed below

 

Health

Max Health indicates the maximum value that “Current Health” can have.

An uninjured person will have a current health that equals their max health.

As a person is more and more injured, their current health will drop.

If current health reaches zero, the person dies.

When injured, a person will recover health points at a rate of X per day. (Where X is determined by probably in an XML file, may be influenced by stamina? A hospital facility in base?)

An injured soldier cannot be trained. An injured scientist or engineer cannot work on projects.

 

Accuracy

Base probability that person will hit a target with an attack? Can someone specify the exact formula?

 

Reactions

Not really sure. Help!

 

Speed

Um. Number of meters person can walk in a turn, if they do nothing else?

 

Stamina

Not really sure. Help!

 

Bravery

I think it’s something about how likely person is to panic?

 

Strength

Indicates how much mass a person can lift, before becoming encumbered.

Can someone specify the exact formula?

Post v1.0, some impact on Hand To Hand combat ability?

 

Psi Strength

I think it’s something about how many Psi attacks a person can do, before they get tired?

Can someone specify the exact formula?

 

Psi Attack

How strong this person is when they make psi attacks?

 

Psi Defense

How resistant person is to psi attacks?

 

Notes

1. More information on personnel can be found under the topics “Transfers”, “Hiring System”

There are 3 types of “personnel” - (Not counting the bystanders at a mission sites.)

 

Edit 2006-03-01: Probably best to have 3 health values. Health, Stun Damage and Physical Damage. (Then we don’t have to change the value of Health as person is injured, we change the Damage attributes.)

Edited by dteviot
Link to comment
Share on other sites

Land Type Detection

 

I’m REALLY not sure what I’m supposed to say here, so be nice. Red Knight, if I’ve got it wrong, please give me a bigger hint about what sort of things are supposed to be here.

 

Executive Summary

From R.K: “Land Type Detection involves the creation of a class cluster that would represent the world in a way such that you can define what type of land (or ocean) you have for a specific point in the world surface. You have to define too the different types of land, encoding, etc.”

 

So, I guess it goes something like this.

 

1. Provide an XML file that defines regions on the globe and gives their “land type”.

2. List the “land types”.

3. List the effects of “land types”

 

Land Types

There’s probably a list somewhere, but I can think of:

Deep Ocean

Beach. – for Bikini Beach terror mission :)

Farm

Mountains

City

Desert

Forest

Arctic

Mars?

 

 

 

Effects of Land Types

Geographical features of battlescape. (e.g. “Tileset”, buildings, plants, “stage dressing”)

Requirements for troops? (e.g. armour of some sort needed for Ocean missions?)

Was suggested somewhere that land type may have effect on base.

 

See also:

http://www.xcomufo.com/forums/index.php?showtopic=8410

 

Garo wrote:

Possible land types include something like forests, jungle, arctic, farmland, desert, rocky terrain. LandTypes like "city" and "mars" should also be in this list, but they are threat a bit differently (see World)

 

I think that the LandType should also contain other parameters, like "how much rocks", "how dense jungle" etc, so that these parameters could also be used to make the world areas more diverse (like that in the middle of antarctica, there's only snow and snow and snow, but in 1/3 from the coast towards the south pole, you could also see some holes in the snow where the cold sea shows it's deep mysteries)

 

Red Knight wrote

I think that for a base implementation for Landtype the polygonal query is good enough, but think about using sort of data structure composed of processed textures Wink.gif (You just draw where stuff is and process it to create the Data Structure with all that data) all the information is composed there and stored in a file and read then by the game. (This gives you a better control over parameters, but it is out of scope of base implementation, let alone null Wink.gif where you only define the responsabilities and interface prototype).

 

Edit: Added url, Garo and RK quotes.

Edited by dteviot
Link to comment
Share on other sites

Globe Rendering

 

Executive Summary

Globe rendering is responsible for showing Earth and location of places of interest.

 

Summary

1. Render Earth lit by Sun according to current time in the game

2. Draw borders of countries/regions on Earth

3. Draw major cities of Earth (where terror missions can be encoutered)

4. Show current Player and Aliens activity on Earth

(5). It's possible for player to filter information displayed on globe easily (proposition)

 

Details

1. Earth has to be lit taking into account time of the day (day/night/grayline) and time of the year (in winter there's more sunlight on southern hemisphere, summer - northen hemisphere)

2. Country borders have to be shown only on lands (no borders on water/oceans)

a. Countries should be named with appropriate text visible on globe

3. Cities should be shown as icons that are easily recognizable from others

a. Cities should have names by their icons

4. Each game object whether it belongs to Player or Aliens, and is visible to Player, should be shown as an easily recognizable icon

a. Player objects are shown as blue, whilist Alien objects are red

b. There are icon types for each object type: Base, Small UFOs, Medium UFOs, Large UFOs, Crash Site, Terror Site, Land Site, Human Crafts (5 icon types).

 

 

PS. My first entry, be polite ;P

Link to comment
Share on other sites

Globe Rendering

 

Executive Summary

Globe rendering is responsible for showing Earth and location of places of interest.

 

Summary

1. Render Earth lit by Sun according to current time in the game

2. Draw borders of countries/regions on Earth

3. Draw major cities of Earth (where terror missions can be encoutered)

4. Show current Player and Aliens activity on Earth

(5). It's possible for player to filter information displayed on globe easily (proposition)

 

Details

1. Earth has to be lit taking into account time of the day (day/night/grayline) and time of the year (in winter there's more sunlight on southern hemisphere, summer - northen hemisphere)

2. Country borders have to be shown only on lands (no borders on water/oceans)

    a. Countries should be named with appropriate text visible on globe

3. Cities should be shown as icons that are easily recognizable from others

    a. Cities should have names by their icons

4. Each game object whether it belongs to Player or Aliens, and is visible to Player, should be shown as an easily recognizable icon

    a. Player objects are shown as blue, whilist Alien objects are red

    b. There are icon types for each object type: Base, Small UFOs, Medium UFOs, Large UFOs, Crash Site, Terror Site, Land Site, Human Crafts (5 icon types).

 

 

PS. My first entry, be polite ;P

 

Nice work Guyver =b

I'd add a couple of "luxury items"

1. Should display mission information for human craft. e.g. Patrol routes, landing points, courses etc. (Player can select if this information is shown or not.)

2. Should display projected courses for detected UFOs.

3. Should be able to do some "statistical displays", e.g. code regions by quantity of alien activity.

4. Option to display globe as flat map. (Sometimes it's a bit annoying to have to rotate the globle to look for stuff, a flat map makes it easy to see at a glance new activity.) E.g. A UFO is detected. Should be easy to FIND the new UFO.

 

Edit: Additional items:

Should also be able to show areas of neudar coverage.

Should also show status of countries. Friendly, Hostile & Borderline.

Edited by dteviot
Link to comment
Share on other sites

Personnel Status

 

Additional notes/thoughts for personnel.

 

1. As well as attributes, personnel should also have statistics. These include

a. Number of days employed.

b. Number of missions (Soldier only)

c. Number of kills. (Soldier only)

 

We probably don’t need a full set of attributes/statistics for every person. From a player perspective, for an engineer, the only attribute the player will be interested in is engineering skill. Therefore, implementation might be that engineer doesn’t have the various “soldier” skills normally. And when a base is invaded, we just create some soldier entries in the battlescape with default attributes for the engineers & scientists.

Link to comment
Share on other sites

Base Management

 

Executive Summary

From R.K: “Base management is the cluster that involves the Baseview system, facilities constructions, destruction, metadata, etc.”

 

Summary

1. Allow player to create and destroy bases.

2. Allow player to create, manage and destroy facilities in a base.

 

Details

1. XML (or something) specifies the maximum number of bases player can have.

2. Player can select a position on the globle and create a base at that position. Restrictions:

a. Player must not have reached maximum allowed number of bases.

b. Location must not belong to a hostile country.

c. Question: what happens to a base in a country that becomes hostile to a player?

3. Player can destroy bases.

4. Player can give bases names (and rename them.)

5. XML file describes facilities.

6. v1.0 Each base has a 6x6 grid of available space.

7. Player can view a 3D representation of a base and its facilities.

8. Player can destroy the facilities in a base.

9. Player can add facilities to a base.

10. Rules:

a. Player can only build facilities that are currently available on their technology tree.

b. Player can only build facilities if player has sufficient funds.

c. At start of build, cost of facility is deducted from player’s funds.

d. Every base must have at least one access lift, and this is the first facility that must be constructed in a base.

e. Each facility that is added to the base must touch another facility. (With the exception of the initial access lift.)

 

11. When player is selecting a facility to add to the base, player needs to be shown: name, size, cost & construction time.

12. Facilities take time to build.

13. A facility is not available for use until fully built.

14. While a facility is being built, player needs to be able to know when building will finish.

15. A base summary report is available, detailing:

a. % of base capacity in use. (For personnel, items, craft and aliens.)

b. Number of personnel in base (of each type.)

c. Number of idle workers.

d. Other?

 

STORAGE_FACILITY

Holds up to 500 units of items. (Guns, ammo, etc.)

 

XENOMORPH_HOLDING_FACILITY

Holds up to 10 units of aliens

 

SHORT_RANGE_NEUDAR

Detects UFOs, range 250, accuracy 0.65. I’m not sure what accuracy means. Can anyone me?

 

LONG_RANGE_NEUDAR

Detects UFOs, range 750, accuracy 0.85

 

TACHYON_EMISSIONS_DETECTOR

Detects UFOs, range 2500, accuracy 0.98

 

FAC_BASE_ACCESS_FACILITY

Gives access to base. 1 required per base

 

FAC_LANDING_PAD

Holds 1 Human craft. (Or one UFO)

 

FAC_RESEARCH_FACILITY

Place for up to 50 scientists to work in.

 

FAC_ENGINEERING_FACILITY

Place for up to 50 engineers to work in.

 

FAC_BARRACKS_FACILITY

Provides living accommodation for up to 50 personnel.

 

FAC_PSIONIC_TRAINING_FACILITY

Place for up to 10 soldiers to increase their psionic abilities. Need to expand on this some more.

 

FAC_MISSILE_DEFENSE_ARRAY

Um. Attacks UFOs when they get close to the base. We need to figure out exactly how this works.

 

LASER_DEFENSE_ARRAY

Ditto.

 

PLASMA_DEFENSE_ARRAY

Ditto.

 

GAIA_DEFENSE_ARRAY

Ditto.

 

GAIA_DEFENSE_ARRAY

Ditto.

 

GRAVITY_SHIELD_FACILITY

Um. According to X-NET, Attacks UFOs when they get close to the base? Its name suggests it helps protect the base from UFO weapons. Go figure. :shrug:

 

FAC_NEURAL_SHIELDING_FACILITY

Helps conceal base from alien detection. More details would be good.

Link to comment
Share on other sites

Ok, I think I should have a try at CTDs "bread and butter"-function. :)

 

X-Net viewer

 

Executive Summary

From R.K: "The XNet viewer will show information regarding specific topics that the user is discovering."

 

Summary:

1) Display already reserched entrys and allow selection of these

2) Display Models

3) Display text for the model

4) Feature stats comparing

 

Details:

1) Feature a list of items and technology available to the player at the time. This list should be grouped by the following categories:

a) Crafts

  I) X-Corps

  II) Alien

b)Armament and craft components

  I) X-Corps

  II) Alien

c) XCAPS

d) Weapons

  I) Human weapons

  II) Alien weapons

e) Equipment

  I) Human equipment (including armour)

  II) Alien equipment

f) Base facilities

  I) human

  II) alien (?)

g) Alien life forms

h) Alien research

i) Technologies

The tree should inflate and deflate on click and leave open all previous opened branches open.

 

2) Models of each item should be displayed in 3D. They should be freely rotationable around all three axis and should allow free zoom in and zoom out as well as holding the zoomfactor. If not touched by the player, the models should rotate slowly around their x- axis.

 

3) The text viewer should - besides showing the CT according to the selected item - feature the possibility to show and hide stats (such as weight, ammo capacity etc.) on demand. the stats themselves should be read form item.xml. In some cases a modificator is necessary (i.e. weight: items.xml value divided by 4).

 

4) The XNet viewer should feature the possibility to compare stats of different items.

 

If an entry is left, and another one is viewed, the last position of the model and the text should be saved for this specific item. If the player chooses to view this item again, he should find everything right as he left it. Nevertheless, on leaving of the XNet viewer all parameters should be reset to default.

 

It would be a nice feature to have a specialized X-Net viewer for different interfaces, like Basescape, Battlescape and the "hangar". e.g. The Basescape viewer should only feature buildings, the battlescape viewer only weapons, equipment, UFOs and aliens, the "hangar" only X-Corps crafts, Armament, weapons, equipment and mission descriptions etc etc.

 

Ok, now I know the categories do not match the ones that are used right now. But what do you think of these? I chose this order because I think this would be the most logical way to go.

Alien research probably is a bad name. In this category I would like to have everything non-technological about the aliens, like missions, goals, culture, backstory etc.

What do you think of the different X-Net viewer modes?

Edited by Mad
Link to comment
Share on other sites

The extra work do not provides great gains. Not for now, remove it from the task description.

By that you mean the last paragraph, I assume?

Ok, so the description would now be:

 

X-Net viewer

 

Executive Summary:

From R.K: "The XNet viewer will show information regarding specific topics that the user is discovering."

 

Summary:

1) Display already reserched entrys and allow selection of these

2) Display Models

3) Display text for the model

4) Feature stats comparing

 

Details:

1) Feature a list of items and technology available to the player at the time. This list should be grouped by the following categories:

a) Crafts

  I) X-Corps

  II) Alien

b)Armament and craft components

  I) X-Corps

  II) Alien

c) XCAPS

d) Weapons

  I) Human weapons

  II) Alien weapons

e) Equipment

  I) Human equipment (including armour)

  II) Alien equipment

f) Base facilities

  I) human

  II) alien (?)

g) Alien life forms

h) Alien research

i) Technologies

The tree should inflate and deflate on click and leave open all previous opened branches open.

Every weapon requireing clips should be the root of another branch where it's clips are listed.

 

2) Models of each item should be displayed in 3D. They should be freely rotationable around all three axis and should allow free zoom in and zoom out as well as holding the zoomfactor. If not touched by the player, the models should rotate slowly around their x- axis.

 

3) The text viewer should - besides showing the CT according to the selected item - feature the possibility to show and hide stats (such as weight, ammo capacity etc.) on demand. the stats themselves should be read form item.xml. In some cases a modificator is necessary (i.e. weight: items.xml value divided by 4).

 

4) The XNet viewer should feature the possibility to compare stats of different items.

 

If an entry is left, and another one is viewed, the last position of the model and the text should be saved for this specific item. If the player chooses to view this item again, he should find everything right as he left it. Nevertheless, on leaving of the XNet viewer all parameters should be reset to default.

Edited by Mad
Link to comment
Share on other sites

Purchasing/Selling/ Transferring

 

Executive Summary

The bit in X-COM where you buy stuff and put it in your bases, sell stuff you don’t want, or move stuff around the globe.

 

Summary

1. Player can purchase items.

2. Player can sell items.

3. GUI for selecting items to be removed from one base and placed in another.

4. Types of items that can be bought and sold are: craft, craft equipment, troop equipment, aliens, and items salvaged from missions (e.g. UFO components.) Personnel are covered under Hiring system.

 

 

Details

1. XML file lists the items that can be purchased, their purchase and selling price, and if they can be purchased.

2. The purchase price is always in $. (It never includes things like Xenium or Composites.)

3. Being purchasable is independent of being buildable. That is, even if an item is purchasable, it may also be buildable.

4. Player is always able to sell items, even if player will get $0 for “selling” them.

5. Player can only sell items that are in a base. (What about items in transit? Salvage from a battlescape when there is insufficient space in base?)

6. When sold, an item is immediately removed from the base.

7. An item can only be purchased if there is sufficient storage space in the selected base for the item, and player has sufficient funds to afford the item.

8. Items can only be purchased if item is currently available on technology tree. i.e. it’s in the list of default items or has been researched. (This constraint is unnecessary for v1.0, as all purchasable items are in the default item list, but this may not always be the case.)

9. If an item is purchasable, then there is an infinite quantity of the items available for purchase. (Alternately, the XML file specifies the maximum number of items available for purchase each week. At the start of the week the maximum number allowed are available, as the week progresses, the number available for purchase will reduce as items are purchased. At the start of the next week, the number goes back to the maximum.)

10. When purchased, the item is immediately placed in the selected base. (If items were to take time to arrive after purchase, then we run into the possibility of there being no room in the base when the items arrive, even though there was room in the base when the items were purchased. There’s also the problem of item ownership. If the items take time to arrive, then they’re not owned by the base during this time. So what is responsible for them?) Of course we run into similar issues if we transfer items between bases and the transfer takes time. And with salvage from a battlescape. An alternate solution to the “insufficient space in base when items arrive” problem is giving player the opportunity to transfer or sell items that are in the base until there is room. Player can also sell the arriving items. Assuming that items will take time to arrive when purchased, then how is this set? Possibilities: 1. Items arrive at midnight, of day of order. 2.XML file gives time taken for item to arrive. (Allows us to tweak arrival times. Small, common items e.g. pistol ammo turn up quickly, large items e.g. craft take hours/days.)

11. If a craft is sold, any equipment (and ammo) on craft is put into base’s store if there is room. If there is insufficient room, player is given opportunity to sell or transfer items in the base (and the items from the craft.) If the craft is xenium powered, the Xenium fuel is removed from craft and stored in the base. (Is this reasonable? If we’re removing the fuel, how is the new owner going to use the craft?)

12. If an item is sold, it’s gone and not available to be bought. (E.g. if we sell an alien or craft we built, it won’t be available for purchase by the player.) This also applies to “standard” purchasable items, when there are weekly quotas on the quantity of items available. Obviously, when there are unlimited quantities of purchasable items, replacements can always be purchased.

13. GUI to allow user to specify items to transfer. GUI won’t let player send items to a base that doesn’t have space to store them. (Question. Should calculation also allow for other items that are also in transit to the destination? Becomes complicated. If space is insufficient in base, how can player sell items that are in transit?)

14. Can’t Transferring craft if staff are assigned to a craft, because of restriction that the personnel assigned to a craft must be long to the same base the craft is assigned to.

15. Questions: When transferring items between bases how long does it take? (We could cheat, and require all bases to have a teleport facility :)) Assuming it takes time, how is this set?

16. When transporting salvage from a mission back to a base, how long does it take?

Link to comment
Share on other sites

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.

 

Additional hiring stuff:

1. When fired, all equipment carried by a soldier is put into a base’s store. If there is insufficient room, player is given the opportunity to move inventory around bases. (Refer transferring.)

2. Soldiers can only be dismissed when they are in a base.

3. Engineers and scientists can only be dismissed when they are in a base. (They can’t be dismissed while moving between bases.)

4. Soldiers can only be transferred when they are NOT assigned to a craft.

5. Personnel can only be transferred to another base if there is space in the barracks to hold them. (Do we allow for other personnel that may be in transit to base?)

6. How long does it take for personnel to be transferred?

Link to comment
Share on other sites

6. How long does it take for personnel to be transferred?

 

What if we implement transfers between bases to be actual craft (but it would not show in the planetscape radar). This would allow the items and soldiers, which are being transferred, to be owned by the craft. As we will have craft handling systems for interceptors, ufos etc, implementing such invisible craft would be an easy task. It would just have infinitive storage space and fixed speed. Just create the craft from a factory, transfer the items and soldiers into the craft, setup target and dispatch it and the craft handling subsystems would take care about the rest =)

 

Later, in post V1.0, we could make these transfer crafts visible so the UFO's could intercept and destroy them, if we wish.

 

- Garo

Edited by Garo
Link to comment
Share on other sites

Sound Support

 

(People, I’m doing my best here, but I think I probably need some assist from someone who understands this area better.)

 

Executive Summary

Support ogg with stereo encoding for 2D and environmental sound. Support ogg encoding for 3D sound. Support volume controls and general sound options.

 

Summary

1. Provide GUI for player to adjust sound settings.

2. Provide background music and background sound effects.

3. Provide event driven sounds from positions in 3D space. (e.g. Weapons fire.)

 

Details

1. Sound GUI must provide:

a. Ability to set music volume.

b. Ability to set sound effects volume.

c.

2. We have a set of “background music” pieces.

3. We have a way to specify when the various pieces should be played. (E.g. music during on the planetscape may not be appropriate for battlescape.) Ideally, users should be able to add new music and indicate when they’d like it played. Might we have mission or event driven music as well? E.g. different music for terror missions, base attacks?

4. Will want background sounds, and when to play them. This would include both battlescape sounds (e.g. distant sirens for terror missions) and planetscape/basescape sounds. (e.g. Hanger noises when in the equipping craft GUI, power tools noises in the manufacturing GUI.) We need to make a list.

5. Need a collection of sound effects. (weapon fire, explosions, speech) Which are played when events occur:

a. Battlescape events. E.g. grenades detonate, troops/aliens hit.

b. Fights between UFOs and craft. (Missile launch, craft hits, etc.)

c. Issuing orders to craft, buying/selling items.

d. Here’s a thought, when a research project finishes, there’s a “Eureka”, followed by splashing, running, and a “Stop that naked man!” :)

e. Anyway, again we need to make a list.

6. We will want a way to specify the sound effect to associate with event. (Ideally, user will be able to add new effects and specify their own mapping of event to sound.

7. Ideally, for sounds on the battlescape, we’d like to play them in 3D space. (However, given that Xenocide isn’t a FPS, this is a luxury. We should investigate how difficult this will be to implement.)

 

 

Background “environmental” sounds

Workshop power tools,

Distant emergency services sirens.

Birdcalls (appropriate to terrain), e.g. Seagulls at beach, raptors in mountains. Parrots in Jungle.)

Clinking of glassware, centrifuge. (Other lab sounds?)

More: ToDo

 

Non-battlescape Event sounds

(“Fox One”, Two, Five?) Missile launch.

Soldier saying “Yes Sir.”

Cash Register (Sale/Purchase of items?)

HAL9000 saying “I’m sorry Dave, I can’t do that.” (Player has asked the impossible :))

Jet engines spinning up. (We’ve just built some sort of craft.)

Air raid siren (UFO detected.)

More: ToDo

 

Battlescape Event sounds

More: ToDo

Link to comment
Share on other sites

Alien/XCORP Detection

 

(This was originally called UFO detection, but I’ve since realized that description is incomplete.)

 

Executive Summary

The ability for Aliens to detect XCORP craft and bases (assets) and XCORP to detect Alien assets.

 

Summary

1. Alien assets have the ability to detect XCORP assets. The ability depends on the alien asset’s detection capability and the XCORP asset’s “visibility”. (And vice versa.)

2. Detection capability has two components, range and “probability.”

3. Visibility has several components.

 

Details

1.The factors influence a XCORP base’s “visibility”:
 a.Number of personnel in base.
 b.Number of psionic training facilities.
 c.Number of soldiers getting psionic training
 d.Number of aliens contained.
 e.Tachyon detector.
 f.craft launch/landing
 g.psi shielding facility
2.The factors that influence an alien base’s visibility:
 a.Craft launch/landing
 b.Other?
3.The factors that influence a XCORP craft’s visibility
 a.Craft type.
 b.Number of personnel aboard.
 c.Number of PSI trained personnel aboard.
 d.craft flying or landed.
4.The factors that influence an alien craft’s visibility:
 a.Craft Type.  (The bigger, the more detectable.)
 b.Mission. (The more overt, the more detectable.)
5.XCORP base’s detection capability:
 a.Is determined by the BEST facility in the base.
6.Alien base’s detection capability:
 a.I don’t know how it’s determined.
7.XCORP craft’s detection capability:
 a.Craft type.
 b.Is craft flying or landed.  (Landing reduces range by 90%)
 c.Craft equipment (e.g. neudar pod)
8.Alien craft’s detection capability:
 a.UFO type
 b.UFO mission
9.Player can specify that the areas of the globe that are in “radar range” of XCORP assets are shown on the globe.
10.(Maybe) Player can specify that the areas of the globe that are in the “radar range” of known alien assets are shown on the globe.  (Problem is, would have to have researched the alien UFOs/bases to know what their ranges are.)  
11.How detection works.
 a.When an alien asset first moves into the “field of view” of an XCORP asset (or in the case of alien bases, an xcorp craft moves sufficiently close to the base), the visibility of the alien and the probability of the xcorp asset are calculated.  These values are then used to determine if the alien has been detected or not.  If not detected, then as long as the alien remains in the xcorp’s field of view, every ten game minutes we retest for detection.
 b.Detection testing is performed by EVERY xcorp asset that has the alien asset in range (until alien is detected)
 c.Once detected, the alien is visible to ALL xcorp assets in range.
 d.Once detected, an alien craft remains visible until it goes outside the range of ALL xcorp assets. (and is shown on the globe.)
 e.Once detected, the location of an alien base remains known (and shown on the globle.)

 

EDIT 2006-03-21 Checking for detection as soon as a UFO enters radar range, and as soon as it leaves may be difficult to do. May be easier to just run the test every 2 or 3 game minutes.

Edited by dteviot
Link to comment
Share on other sites

Training System

 

Again, someone who knows about this area needs to fill out the mechanics.

 

 

Executive Summary

The bit where personnel increase their skills by training or experience.

 

Summary

1. Soldiers can increase psi skills by training in the psionics training facility.

2. Soldiers can increase non-psi skills by training in the gymnasium facility.

3. Soldiers can increase all skills by using them in the battlescape.

4. Scientists increase their skills by completing research projects.

5. Engineers increase their skills by completing manufacturing projects

 

Details

1.A soldier can be assigned to a psionics or gym facility provided:
   a.Facility exists in the base the soldier is assigned to
   b.Facility has spare capacity.
   c.Soldier is uninjured.  (If soldier is injured, he is automatically removed from the facility.)
   d.Soldier is not already assigned to another facility.
2.	A soldier can be assigned to a craft as well as a facility.
3.	The way facility training works is as follows:
4.	Every hour we track if soldier is in facility or not. (If out of the base, soldier isn’t in the facility.)  At end of month, we see if soldier has spent enough time in facility for improvement.  If less than 75% of month spent in facility, no improvement.  If less than 90%, chance of improvement is reduced by 75%.  How improvement is calculated? Up for discussion:  I suggest:
   a.Take weakest skill.  
   b.Calculate odds for improvement: (max value for skill – current skill level)  / max skill level.  (Basically, the better the skill is, the less likely we will see improvement.)
   c.Roll the dice.  If successful, increase = (max value for skill / 10)
5.	Scientists.  For each research project completed by a scientist, research skill increases by 2.  (It doesn’t matter how much time the scientist spent on the project.)  Alternative, for every 100 hours spent on research projects, scientist gets a 50% chance of increasing skill by 2%.
6.	Engineers.  For each manufacturing project completed by an engineer, workshop skill increases by 1. (There’s a limit on the number of research projects.  There isn’t a limit on number of construction projects.)
7.	Soldier experience is evaluated at end of each mission. (Successful or otherwise)
   a.Carrying 3 times weight will increase strength by 1 point.  (Should we provide a “lead brick” object, so that you can load up soldiers for weight training?
   b.Hitting an alien with an attach increases accuracy by 1 point.
   c.Running a sufficient distance, increase speed by 1 point.
   d.Resisting a psi attack, increase psi defence.
   e.Successful psi attack, increase psi attack.
   f.Health.  (Get wounded?)
   g.Bravery (Resist fear?)
   h.Stamina?
   i.Reactions?

Link to comment
Share on other sites

6. How long does it take for personnel to be transferred?

 

What if we implement transfers between bases to be actual craft (but it would not show in the planetscape radar). This would allow the items and soldiers, which are being transferred, to be owned by the craft. As we will have craft handling systems for interceptors, ufos etc, implementing such invisible craft would be an easy task. It would just have infinitive storage space and fixed speed. Just create the craft from a factory, transfer the items and soldiers into the craft, setup target and dispatch it and the craft handling subsystems would take care about the rest =)

 

Later, in post V1.0, we could make these transfer crafts visible so the UFO's could intercept and destroy them, if we wish.

 

- Garo

 

You're not the first person to suggest we use invisible craft to transfer items. :)

 

Also, I’d like to thank all the people who have taken the time to write up features, or provide feedback on the items posted.

Link to comment
Share on other sites

d. Here’s a thought, when a research project finishes, there’s a “Eureka”, followed by splashing, running, and a “Stop that naked man!” :)

:D good one. Although I'm pretty sure it will get on ones nerves after a while. So maybe we just stick to some "*patsching*"... :)

Link to comment
Share on other sites

Sound Support

 

(People, I’m doing my best here, but I think I probably need some assist from someone who understands this area better.)

 

Executive Summary

Support ogg with stereo encoding for 2D and environmental sound. Support ogg encoding for 3D sound.  Support volume controls and general sound options.

 

Summary

1. Provide GUI for player to adjust sound settings.

2. Provide background music and background sound effects.

3. Provide event driven sounds from positions in 3D space. (e.g. Weapons fire.)

 

Details

1. Sound GUI must provide:

a. Ability to set music volume.

b. Ability to set sound effects volume.

c.

2. We have a set of “background music” pieces.

3. We have a way to specify when the various pieces should be played.  (E.g. music during on the planetscape may not be appropriate for battlescape.) Ideally, users should be able to add new music and indicate when they’d like it played.  Might we have mission or event driven music as well?  E.g. different music for terror missions, base attacks?

4. Will want background sounds, and when to play them.  This would include both battlescape sounds (e.g. distant sirens for terror missions) and planetscape/basescape sounds.  (e.g. Hanger noises when in the equipping craft GUI, power tools noises in the manufacturing GUI.)  We need to make a list.

5. Need a collection of sound effects. (weapon fire, explosions, speech) Which are played when events occur:

a. Battlescape events. E.g. grenades detonate, troops/aliens hit.

b. Fights between UFOs and craft.  (Missile launch, craft hits, etc.)

c. Issuing orders to craft, buying/selling items.

d. Here’s a thought, when a research project finishes, there’s a “Eureka”, followed by splashing, running, and a “Stop that naked man!” :)

e. Anyway, again we need to make a list.

6. We will want a way to specify the sound effect to associate with event.  (Ideally, user will be able to add new effects and specify their own mapping of event to sound.

7. Ideally, for sounds on the battlescape, we’d like to play them in 3D space.  (However, given that Xenocide isn’t a FPS, this is a luxury.  We should investigate how difficult this will be to implement.)

 

 

Background “environmental” sounds

Workshop power tools,

Distant emergency services sirens.

Birdcalls (appropriate to terrain), e.g. Seagulls at beach, raptors in mountains.  Parrots in Jungle.)

Clinking of glassware, centrifuge.  (Other lab sounds?)

More: ToDo

 

Non-battlescape Event sounds

(“Fox One”, Two, Five?) Missile launch.

Soldier saying “Yes Sir.”

Cash Register (Sale/Purchase of items?)

HAL9000 saying “I’m sorry Dave, I can’t do that.” (Player has asked the impossible :))

Jet engines spinning up. (We’ve just built some sort of craft.)

Air raid siren (UFO detected.)

More: ToDo

 

Battlescape Event sounds

More: ToDo

I would add:

Details:
Ad. 1.
   c. Ability to chose output device (which sound card to use)
   d. Hardware / software 3D rendering

Ad. 5. Each "enviromental" (played as a result of user input / game event) sound should have alterable pitch and different sfx files, to play them randomly as a result of the same event (makes things sound less artificial)

8. Environment effects (depending on the surroundings; possibly use of a little metalic environment effect while in Baseview)

Link to comment
Share on other sites

UFO Combat

 

This was originally called UFO Attack, but I think Combat is a better term, as I think this item covers the whole bit when an XCORP craft engages a UFO. So it’s also going to include Azreal’s “UFO Interception” – which I think was meant to be the bit where the player sends a craft to intercept a UFO (or the alien sends a UFO to intercept a craft?)

 

That is, I believe the UFO topics work as follows:

 

UFOs

The types of UFOs, and creation of UFOs by Alien.

 

UFO Movement

Alien “deciding” on a mission, creating and assigning UFO(s) to mission. UFO then performs mission.

 

UFO Detection

How player can detect UFOs on missions (and alien bases)

 

UFO Interception

Assigning craft to intercept UFOs.

 

UFO Combat

The actual combat between craft and UFOs.

 

Executive Summary

The bit where XCORP craft “fight” UFOs.

From Red Knight “Involves the Craft to UFO attacks functionality where crafts can take stances, UFOs can outrun the player, etc.”

 

Summary

1. Provide GUI to give player some control over combat between craft and UFOs.

2. Probably also be used when a UFO attacks an XCORP base.

3. There are at least two alternative choices for implementing this.

a. X-COM 1 model, (player sets a couple of options, and the craft and UFO slug it out.)

b. “Aeroscape” (a simplified battlescape. Where player gets to micromanage craft movement, weapons fire etc.) Maybe something like ship combat in Master of Orion.

 

 

X-COM1 model Details

1. Combat is always between a single UFO and either a Base or single XCORP craft.

2. Battle starts when craft and UFO reach 100 km.

3. Player sets craft “tactics”: aggressive, normal, cautious, escape.

4. Alien will pick tactic for UFO.

5. Combat starts. Combat is broken down into turns. During each turn craft will

a. a move relative to each other. (as appropriate)

b. fire weapons (if appropriate)

c. “roll the dice” to see if any hits occur. If there are any hits, assign damage to craft.

d. Report results to player (fire, hit, miss, damage.)

e. Player updates craft’s current tactic. Alien updates UFO’s current tactic.

f. Repeat from step a, until either break off combat (i.e. range between craft increases to 200 km) or one is destroyed. (Or in the case of UFO attacking a base, the UFO reaches the base.)

6. I believe under “aggressive” craft tries to close to short range and then fire. Under “cautious”, craft says at maximum weapons range.

 

Aeroscape Details

1. Combat is between squadrons of alien and XCORP craft.

2. Combat takes place on a simplified battlescape. An empty 3D grid.

3. Play is broken down into turns.

4. At start of each turn, player can give craft a set of simple orders (essentially a reduced set of the orders that could be given to a soldier) e.g. Move to: Shoot missile X at UFO Y.

5. Combat ends when either craft break off combat UFO or craft get to “exit point” on map, or all of one side are destroyed.

 

The idea behind the Aeroscape is that it is a simplified battlescape, so it lets us experiment and learn before we build the “full scale” battlescape.

 

EDIT 2006-03-22.

1. Game time on planetscape stops while UFO combat is occurring. This is mostly to keep other things from happening and overloading the player, while the combat is in progress.

2. Game can't be saved while UFO combat is occuring.

Edited by dteviot
Link to comment
Share on other sites

Edited UFO detection.  May be easier to just poll every couple of game minutes to see if a UFO has been detected, rather than trying to determine exactly when UFO enters/leaves a radar's range.

 

Sounds good. After all, that's how the real radars work in the real life, they poll the surroundings :)

 

- Garo

Link to comment
Share on other sites

Edited UFO detection.  May be easier to just poll every couple of game minutes to see if a UFO has been detected, rather than trying to determine exactly when UFO enters/leaves a radar's range.

Sounds good. After all, that's how the real radars work in the real life, they poll the surroundings :)

But wouldn't be there a danger to miss an UFO? The radars (NEUDARs) have a certain chance to detect an UFO, if the detection algorithm of the game skips an UFO hich should have been detected, the statistics are not right anymore. E.g. the large NEUDAR might normally have a 10% chance of spotting an UFO, and now will only have a 9% chance...

Link to comment
Share on other sites

Edited UFO detection.  May be easier to just poll every couple of game minutes to see if a UFO has been detected, rather than trying to determine exactly when UFO enters/leaves a radar's range.

Sounds good. After all, that's how the real radars work in the real life, they poll the surroundings :)

But wouldn't be there a danger to miss an UFO? The radars (NEUDARs) have a certain chance to detect an UFO, if the detection algorithm of the game skips an UFO hich should have been detected, the statistics are not right anymore. E.g. the large NEUDAR might normally have a 10% chance of spotting an UFO, and now will only have a 9% chance...

OK, I think there's a miscommunication here.

In the original post, I suggested that we check for UFO detection the instant a UFO enters the range of a radar. This raises two issues.

1. Calculating exactly where and when this will occur. (If it's a UFO and craft it becomes messy, especially if they're on courses that turn. e.g. running a search pattern.)

2. Setting up some sort of event to fire in the game engine when the predicted interception time occurs.

 

So, a simpler solution may be we just set up a game event that fires every couple of minutes. When it fires, we run through all the UFOs, check if any not detected ones are in radar range, and if they are "roll the dice" to see if the UFO is detected. So in theory, if a UFO just "clipped" a radar range, going in and out between polls, then, yes, it wouldn't be detected. However, that doesn't alter the % chance. Which is the base chance of detecting a UFO in each poll.

 

Or is the % chance meant to be something else?

Link to comment
Share on other sites

So, a simpler solution may be we just set up a game event that fires every couple of minutes.  When it fires, we run through all the UFOs, check if any not detected ones are in radar range, and if they are "roll the dice" to see if the UFO is detected.  So in theory, if a UFO just "clipped" a radar range, going in and out between polls, then, yes, it wouldn't be detected.  However, that doesn't alter the % chance.  Which is the base chance of detecting a UFO in each poll.

 

Or is the % chance meant to be something else?

No, that's exactly what I meant. And I was thinking - as you already said - of UFOs which enter and leave the zone between two polls. On the other hand, this might not happen all the time, so maybe the problem is only an academic one...

Link to comment
Share on other sites

Statisics Counters

 

Standard disclaimer: I’m not really sure about this area, so feedback on errors and additions is appreciated.

 

Executive Summary

The dialog that shows graphs of how things are going.

From Red Knight “The statistics counters are graphical represesentations of the UFO activity patterns that the score system must keep”

 

Summary

1. Keep historical records of information of potential value to the player.

2. Provide interface(s) to usefully display this information.

 

Details

1. Should keep monthly totals for preceeding month.

2. Should keep daily totals for each day in current month.

3. Provide line graphs of historical data.

a. Alien activity, by country

b. Income, by country

c. XCORP operations, by country.

d. XCORP’s standing, by country.

e. (Maybe) expendure.

f. (Maybe) income from sales.

4. Display historical data by month, week, or day.

5. (Optional) display current data on planetscape’s globe.

a. XCORP’s standing

b. Alien activity

c. XCORP income.

Link to comment
Share on other sites

Base Information

 

Executive Summary

From Red Knight “The base information screen will show the required information about the current base statistics, etc.”

 

Summary

1. Dialog that shows base statistics.

2. (I think this stuff has already been discussed under base management.)

 

Details

1. Show available total, in use, and free capacities in base: Baracks, stores, alien containment, workshop, labs.

2. Show costs for base: wages, base maintenance, craft rental.

3. Warning if getting low on ammo for commonly used weapons?

Link to comment
Share on other sites

Game Cinematics

 

Executive Summary

Showing video clips at appropriate times during the game.

 

Details

1. Have a collection of video clips.

2. Figure out how to show the video clips, on different OSes. (At minimum, Windows & Linux)

3. Define set of events when clips will be shown.

4. Link events to clips.

5. Maybe provide GUI to display clips that have been “unlocked”?

 

List of Clips

1. Intro

2. End Game

3. Other: ToDo

Link to comment
Share on other sites

Additional points for UFO combat. (Added to prior post.)

 

1. Game time on planetscape stops while UFO combat is occurring. This is mostly to keep other things from happening and overloading the player, while the combat is in progress.

2. Game can't be saved while UFO combat is occuring.[/color]

Link to comment
Share on other sites

Because that topic will go in the experimentation with game mechanics class ;) .. For now we will stick to the easiest path for completion. Let say classic style, even though I really like the idea of the Aeroscape (with an autocombat functionality of course)... so basicly we are doing the autocombat first ;)

 

Greetings

Red Knight

Link to comment
Share on other sites

Because that topic will go in the experimentation with game mechanics class ;) .. For now we will stick to the easiest path for completion. Let say classic style, even though I really like the idea of the Aeroscape (with an autocombat functionality of course)... so basicly we are doing the autocombat first ;)

 

Greetings

Red Knight

Thanks.

Link to comment
Share on other sites

I would like to add something to the X-Net viewer.

But I have to ask first if this is possible:

I would like to have seperate CTs for Clips. That way we can easily add different amunition in v1+. These CTs should be sub-texts of their weapons. So that they only show up if you click on the name of the Weapon. Just like the weapons only show up if you click on "weapons". This is what I mean if I write "Every weapon requireing clips should be the root of another branch where it's clips are listed."

What do you think?

Edited by Mad
Link to comment
Share on other sites

I would like to add something to the X-Net viewer.

But I have to ask first if this is possible:

I would like to have seperate CTs for Clips. That way we can easily add different amunition in v1+. These CTs should be sub-texts of their weapons. So that they only show up if you click on the name of the Weapon. Just like the weapons only show up if you click on "weapons". This is what I mean if I write "Every weapon requireing clips should be the root of another branch where it's clips are listed."

What do you think?

I'd say it's certainly doable, and as a gut estimate, would take between 5 and 20 hours to implement.

However, I have concerns about how "natural" and "intuitive" such an interface would be. That is, could a person use the interface without even thinking about it, or is it sufficiently different that that the person needs to think about it every time it's used. Kind of disrupts the "suspension of disbelief".

For that matter, while the Planetscape and Basescape have a similar "look and feel" XNET is different. Which feels kind of "off" to me.

Link to comment
Share on other sites

Terrain Base Modifiers

 

I believe this is based on threads

http://www.xcomufo.com/forums/index.php?showtopic=8193

http://www.xcomufo.com/forums/index.php?showtopic=8138

 

Executive Summary

Base properties are changed, depending on the type of terrain the base is located in.

 

Summary

The type of terrain a base is built on may impact:

a. Monthy maintenance

b. Build time.

c. Build cost.

d. Concealment from UFOs

e. Ability to defend from attack.

 

Details (Copied from JTGibson's post.)

 

Arctic/Antarctic:

- Drawback: Additional $250/mo. per person in the base as monthly maintenance, to reflect higher life support (heating) requirements.

- Advantage: Cold environment enhances base security: deep snow reduces the ability for alien units to trudge into the base, reducing the number of alien invaders that get through the (assumed) base defence perimeter.

 

Desert:

- Drawback: Base is easier to spot by scout UFOs.

- Advantage: Missile defences are more effective and 20% cheaper; radar range is longer; hyperwave decoder is 5% cheaper.

 

Forest:

- Drawback: Base creation (i.e., new base site) is $100,000 more (6.6% more expensive).

- Advantage: Base is considerably more difficult to spot by UFOs.

 

Mountains:

- Drawback: Facility construction cost is increased by 5% and takes 10% longer (rounded down -- e.g., 28 days becomes 30 days; 32 days becomes 35 days).

- Advantage: More difficult to spot, all defences more effective.

 

Plains:

- Drawback: Base is easier to invade or siege.

- Advantage: New base site is $100,000 cheaper.

 

 

The advantages and disadvantages also apply in reverse, with regards to the X-Corps spotting/attacking alien bases.

 

My comments

1. Why are terrain exclusive? There are mountians in antarctica, and some mountains have forests all the way up to the treeline.

2. Oceanic bases are missing from the list. (I'd make them very expensive, but also very hard to detect and attack.)

3. Antarctic bases would also be hard to hide. (Waste heat from base, and not much air traffic.)

4. Why would a desert base be any easier to find?

5. Mountain base would be much harder to defend. Attacker could take advantage of terrain.

6. Incidentally, if I wanted to hide bases from aliens, I'd put them on container ships. Not only would the base be mobile, but to hide it, just send it into a port, and loose it amoung all the other ships.

7. We're also missing hiding XCORP bases in plain sight. Military bases and airports.

Link to comment
Share on other sites

Dynamic Zones

 

I'm don't know what to put here.

 

All I can think of is having different paletes for different seasons. E.g. A forest in winter would have snow on the ground, and bare trees.

You might also have water frozen, so soldiers can walk on it.

But both of these are battlescape properties, so I'm not sure how the planetscape is impacted.

Link to comment
Share on other sites

It is that ;)

 

Details on the specific properties for the terrain modifiers is left for gameplay, just the esential properties of the modifiers are needed. Like "Hide Modifier", "Attack Modifier", Cost, etc.

 

Greetings

Red Knight

Link to comment
Share on other sites

I'd say it's certainly doable, and as a gut estimate, would take between 5 and 20 hours to implement.

However, I have concerns about how "natural" and "intuitive" such an interface would be. That is, could a person use the interface without even thinking about it, or is it sufficiently different that that the person needs to think about it every time it's used.  Kind of disrupts the "suspension of disbelief".

For that matter, while the Planetscape and Basescape have a similar "look and feel" XNET is different.  Which feels kind of "off" to me.

Hm. I don't get this. why is it so much work? We already have sort of a tree structure in the XNet, so why would it be so complex to add one more hirachy?

Second I don't understand why you think this wouldn't be intuitive. A gun needs clips. So I search for the clips where I search for the gun - and voilá - as soon as I open the XNet entry for the gun I get a list of all usable clips with seperate explanaitions for each amunition type.

Link to comment
Share on other sites

I'd say it's certainly doable, and as a gut estimate, would take between 5 and 20 hours to implement.

However, I have concerns about how "natural" and "intuitive" such an interface would be. That is, could a person use the interface without even thinking about it, or is it sufficiently different that that the person needs to think about it every time it's used.  Kind of disrupts the "suspension of disbelief".

For that matter, while the Planetscape and Basescape have a similar "look and feel" XNET is different.  Which feels kind of "off" to me.

Hm. I don't get this. why is it so much work? We already have sort of a tree structure in the XNet, so why would it be so complex to add one more hirachy?

First off, we have different definitions of "so much work". For most programming tasks, this size counts as "small" or even "tiny".

 

However, for time budget:

For starters, the existing xnet.xml file schema uses a 2 level hierachy, so changing it to 3 potentially requires updating all 120 entries. (That's at least an hours' work.)

And, just to make life fun, xnet.xml is auto generated, so that would require updating and testing the generator program as well. Figure in another hour there for code and test. (It sill requires an hour to update the data file that feeds the autogenerator.)

 

Next, code changes to Xenocide. When I last looked at the code (and it's possible my information is no longer correct) it was hard coded to a 2 level hierachy. Going to a 3, or general, level hierachy would require significant changes to the existing code.

I'd guestimate around 100 lines of code, so figure in 4 hours work to write the code.

 

Now we get into the dirty little secret #1 of programming.

Once the code has been written, we need to get it to work. Typically it takes just as much time to debug code as it takes to write, so we're looking at another 4 hours here.

 

Adding it all up, gives a median guestimate of 10 hours.

 

However, as this is a guestimate, there's easily a factor of 2 error in there, giving a spread of 50% to 200% of the initial range.

So, as a gut estimate, between 5 and 20 hours to do the job.

 

 

Second I don't understand why you think this wouldn't be intuitive. A gun needs clips. So I search for the clips where I search for the gun - and voilá - as soon as I open the XNet entry for the gun I get a list of all usable clips with seperate explanaitions for each amunition type.

I have no problem with a hierarchical ordering of xnet items. My issue is that while the “menu” is arranged that way, we’re not providing the usual visual clues to indicate the nested structure of the data. E.g. indentation, icons, etc.

Link to comment
Share on other sites

However, I have concerns about how "natural" and "intuitive" such an interface would be. That is, could a person use the interface without even thinking about it, or is it sufficiently different that that the person needs to think about it every time it's used.  Kind of disrupts the "suspension of disbelief".

For that matter, while the Planetscape and Basescape have a similar "look and feel" XNET is different.  Which feels kind of "off" to me.

 

Slightly offtopic, but I think that the current XNet interface could be much better. The left side is ok, but the right side, where the technology tree is displayed, doesn't feel "intuitive". I'm not a gui designer, so I can't easily come with good ideas how to make it better, but I think that something should be done for it.

 

- Garo

Link to comment
Share on other sites

I have to agree to both of you. I myself find that the "tree" part of the X-Net could do much better. It already would be a great improvment to have a visual representation of the tree structure, maybe with icons like dteviot said, or lines, or mabe just an indention.

SupSuper, could you have a look at this?

dteviot: You will know best of everyone how much work it will take to rewrite RTF2XML and the other xnet related code. I really would apreciate a free level tree structure, because it would give us a lot more liberty in building the X-Net. Also, for v1+ I could imagine, it might be useful, to have something like symbolic links, so that you don't need to add the CT for the AP bullets to every weapon able using this type of amunition, but only links to this CT. This would decrease the memory consumption of xnet.xml.

If we are on this, we really should think about if we want to change the topics of X-Net, like I described in the X-Net viewer spec, or if we want to keep it as it is right now.

 

Nevertheless, I won't be the one to code any of this, so you guys have to decide if you think it's worth the effort or not. I can only propose changes and hope they'll make it to the code.

 

edit: typo

Edited by Mad
Link to comment
Share on other sites


×
×
  • Create New...