Increased Pod Size

[Amineri]

I've managed to successfully build a prototype mod that lets up to 5 aliens be placed per pod. To get around the limit of 3 I had to take over the "AltWeapon" fields of the TAlienPod structure (which is what passes the pod composition informtion from the strategy game to the tactical).

 

I've modded the two functions in the tactical game necessary to accomodate the larger pod sizes.

 

On the strategy side I'll I've done is hard-code the starter mission pod selection function to generate one pod of 5 and one pod of 3 sectoids.

 

To test it I used the Developer Console to turn off FoW and made all actors visible.

 

See the results below.

 

First up is the Pod of 5 lurking in the parking lot

 

http://wiki.tesnexus.com/images/2/2e/Screenshot_Pod_of_5.jpg

 

 

As a control check, I also included a pod of 3. There are in the back of the office section.

 

http://wiki.tesnexus.com/images/5/5b/Screenshot_Pod_of_3.jpg

 

There are a limited number of spawn points per map, but each pod only consumes a single spawn point. Within each pod, each alien's position is randomized around the spawn point selected for that pod.

 

In theory this would allow up to 60% more aliens to be jammed into a map. However, my hope is that people will use this to place fewer but larger spawns to improve the tactical game, since there will be less chance of bumping into another pod while trying to maneuver.

 

Additionally, in the later game when XCOM squadsize is at 6, having pod sizes of 5 is a bit more "fair" to the aliens ^_^

 

This is just prototyping so far, so I'm not releasing any hex code quite yet. But I figured I'd tease you all with the possibilities :smile:

 

---------------------------------------------------------------

 

Oh, I thought I should mention that I came across this kind of by accident when trying to figure out how to pass an alien rank from the strategy game to the tactical.

 

I also figured that out, so eventually we'll be able to make mods where the leader of each pod can be assigned a rank when creating the pod in the strategy game. You haven't seen anything til you've faced a Colonel-equivalent Ethereal with 4 Muton Elite Bodyguards.

Edited May 13, 2013 by Amineri

[kara42]

If this works as intended this will be really awesome, so looking forward for the hex code to be released.

 

 

I just see a potential problem with mechanical units if you keep the alien count the same and just organize them into fewer groups.

 

An ethereal with 4 elite mutons works nicely but a sectopod with 4 pesky little drones escorts instead of only two kinda lowers the difficulty as it probably means somewhere else you get 2 Mutons less. It would work

if a mechanical pod of 5 would always have 2 main units (cyberdiscs or sectopod) and 3 drones i guess, question is, can the pod composition be determined in that way?

[Amineri]

Technically speaking, each pod can be made up of any possible mix of aliens.

 

To test this out I made a Pod consisting of 2 cyberdiscs, 1 sectopod and 2 drones. I started to run into some glitches in this situation, as the two cyberdiscs were placed in an overlapping state, and had to use WarpTo (teleport) in order to be able to move. The drones failed to display a mesh at all.

 

So... still some significant debugging needs to happen.

 

---------------------

 

The pod contents are determined in the strategy game in XGStrategyAI. The general rule is that an array of possible alien "pod types" is computed based on month. Each possible type has a % chance to appear. Sectoids in late game have a very low chance, for example. The game uses a weighted random roll to pick each pod type.

 

The pod leader is always of the "pod type". The Support slots of the pod are then filled with a simple lookup call to GetSupportingAlien.

 

But technically the pod structure that carries the information can have as many different type of aliens as is desired... just have to figure out how to code it appropriately in XGStrategyAI.

 

I'm not sure what the glitch was with the crazy mix of Cyberdiscs, Sectopod and Drones, but here is an example with 2 cyberdiscs + 3 drones in a single pod:

 

http://wiki.tesnexus.com/images/3/34/Pod_with_2_cyberdiscs_and_3_drones.jpg

 

 

[anUser]

I like the idea of more aliens per pod and less pods. Whats the default behaviour if you dont mod it? Low level aliens seem to come in pack, but sectopods, cyberdisks and ethereal have scouts... drones or muton elite. Could it be made so every pod contains any randomly choosen alien type from those already available due to date? And is that 5 number some sort of limit or can it be increased to face 9 aliens pod?

[Amineri]

The TAlienPod structure is used to pass each pod's information from the strategy game to the tactical game.

struct native TAlienPod
{

var XGGameData.EAlienPodType eType;

var XGGameData.ECharacter eMain;

var XGGameData.ECharacter eSupport1;

var XGGameData.ECharacter eSupport2;

var XGGameData.EItemType eMainAltWeapon;

var XGGameData.EItemType eSupport1AltWeapon;

var XGGameData.EItemType eSupport2AltWeapon;

}

As you can see, there are only seven values defined.

The pod-type is either Commander, Soldier, Secondary or Roaming. This affects which spawnpoints on the map the pod can use (this is how Commanders are restricted to appear on the bridge of crashed/landed UFO). Soldiers are what appear on Abduction Missions, and Secondaries are what appear on Terror Missions. Each UFO, the alien base, and the special missions each have their own mix of pod-types.

In order to allow more than 3 aliens per pod, I re-purposed the 3 AltWeapon fields to be able to store additional information. The first two I have storing more aliens in the pod. The third I plan to use to store the rank of the Main alien in the pod, so that it can be improved.

Additionally, I began to run into space issues when trying to unpack the structure. This is done in two places. The first reads the alien types and creates the Alien Loadouts, which defines which alien mesh and weapon to use. The second transfers the structure data into a dynamic array and the spawns the XGUnits. Transferring from a struct to array takes space -- you can't loop because each struct call requires it's own code. I'm not sure that I could fit more than 6 calls even if there were space in the struct.

Finally, when a pod is placed each alien's is placed a random distance from the defined spawn point (the spawn point for each pod is randomly chosen from the array of spawn points available to that pod type). The default random distance is 2 tiles, which places them in a fairly tight clump. Some units are quite large and can end up overlapping. I seemed to be having that problem when trying to spawn the pod with 2 Cyberdiscs and a Sectopod. I had one case where the two Cyberdisc pawns were overlapping, forcing the game to Warp them to get them free.

The only way I see to increase the pod size beyond 6 would be to deploy multiple aliens per struct field.

The code could deploy:

1 alien unit of type in first field

2 alien unit of type in second field

1 alien unit of type in third field

2 alien units of type in fourth field

4 alien units of type in fifth field

This would allow up to 10 units per pod. I'm using binary encoding to store the number of main and support types. The first two fields would hold the number of main alien types (e.g. Cyberdiscs, Sectopods, Sectoid Commanders, Ethereals). This would allow from 0 to 3 primary types. The 3rd through 5th fields would typically hold identical support alien types (e.g drones, Muton Elites, or whatever), so I've used a binary encoding to hold the total number. Any number of supporting aliens from 0 to 7 could be specified.

If the primary type and support types are identical (e.g. a pack of 10 sectoids), then all fields would hold the same eCharacter type.

To define 1 primary alien, fill out field 1
To define 2 primary aliens, fill out field 2
To define 3 primary aliens, fill out both fields 1 and 2

---------------------------------

While writing the above, I thought of a completely different approach.

Field 1 stores main alien type
Field 2 stores number of main aliens
Field 3 stores support alien type
Field 4 stores number of support aliens
Field 5 can be reserved for something else

This would limit each pod to containing no more than 2 types of aliens, but the only restriction on the number of aliens in a pod would be how many you could crowd into the deployment area. This is also a lot easier to unpack into the dynamic arrays on the tactical side, as simple loops become possible.

The values are chars (single bytes), not full integers, which means that each would be limited to no more than 255. So I guess you could try and build a pod of 510 aliens. Before you reached that point you'd run into the limit on squad-size per player, which is hard-coded as 128. That's not per-pod, that is the limit defined in XGSquadNativeBase:

 

 

var protected repnotify XGUnit m_arrUnits[128];

-------------------------------------

I'd definitely have to increase the deploy radius higher than 2 to try and keep the aliens from overlapping. Perhaps I could make the deploy radius scale with the number of aliens in the pod...

------------------------------------

Thoughts on the various options?

Edited May 13, 2013 by Amineri

[XMarksTheSpot]

This would limit each pod to containing no more than 2 types of aliens, but the only restriction on the number of aliens in a pod would be how many you could crowd into the deployment area. This is also a lot easier to unpack into the dynamic arrays on the tactical side, as simple loops become possible.

 

The values are chars (single bytes), not full integers, which means that each would be limited to no more than 255. So I guess you could try and build a pod of 510 aliens. Before you reached that point you'd run into the limit on squad-size per player, which is hard-coded as 128. That's not per-pod, that is the limit defined in XGSquadNativeBase: ...

Instead of using every other struct member's value to store the number of aliens wouldn't it be possible to combine both alien type and deployment count into a single byte value?

 

As you have 8 bits available you could, for example, reserve the first 5 bits for specifying the alien type and the other 3 bits for defining the number of aliens.

This would allow for up to 2^5 = 32 different alien types (17[?] in the base game + any that may be added in future expansions [fingers crossed] :wink:) and up to 2^3 = 8 aliens per type (I'd assume a minimum of 1 alien per type, therefore the 3 bits would encode for a range of 1-8 instead of the usual 0-7).

 

Code could look somewhat like this:

// using bitwise operators
(char) ((type << 3) | count)
// or alternatively using arithmetic operators
(char) ((type * 8) + count)

/* with type and count being ints,
   type: 0 - none
         1 - sectoid
         2 - thin man 
   and so forth... */

// Encoding example, '4 thin men leaders with 2 sectoid minions'
eMain = (char) ((2 << 3) | 4);     // 2 = [00010], 4 = [100], together [00010100] = 20
eSupport1 = (char) ((1 << 3) | 2); // 1 = [00001], 2 = [010], together [00001010] = 10
// Decoding example, eMain = 20
mainType = eMain >> 3;   // [00010100] >> 3 = [00000010]
mainCount = eMain & 7;   // [00010100] & [00000111] = [00000100]

(I hope this isn't too confusing :confused:)

 

Up to 8 aliens per up to 3 (or possibly 5, when repurposing the other members, too) different type groups makes for more reasonable and varied pod composition options than your 255*2 proposoal, in my opinion :smile:

 

Final note:

If you'd exclude certain aliens from inclusion in pods (e.g. zombies, uber ethereals) you could cram the type specifier into only 4 bytes leaving the other 4 bits for defining up to 2^4 = 16 aliens per type, but this might be stretching it a bit as this would lead into unreasonable alien count terrain again :wink:

[Amineri]

Right on. I could bit pack the entries. I've had to do a lot of bit-operations, particular with the actionscript part of the code, since many of it's operations are not byte aligned. (Most of the ability icons are packed into 14-bit signed integer values)

 

I do have to leave the UberEthereal in, since it is required for the final mission. The eCharZombie falls right in the middle of the alien enum description, so excluding it be require a little tricky footwork.

 

There are currently exactly 16 alien types:

 

 

 

 

eChar_Sectoid,

eChar_Floater,

eChar_Thinman,

eChar_Muton,

eChar_Cyberdisc,

eChar_SectoidCommander,

eChar_FloaterHeavy,

eChar_MutonElite,

eChar_Ethereal,

eChar_Chryssalid,

eChar_Zombie,

eChar_MutonBerserker,

eChar_Sectopod,

eChar_Drone,

eChar_Outsider,

eChar_EtherealUber,

But I agree that leaving it that close leaves no room for any other alien types that may get added in future DLCs. Having up to 8 aliens of each type should be plenty. Having four different aliens in a single pod is probably overkill in most any circumstances that I can think of, but could leave that in.

The issue that quickly arises is now less of the transporting and more of the defining of the aliens pod compositions.

It's the Strategy AI that determines how pods are composed. The current decision logic for how to assemble pods is rather thin. This unfortunately means that there's not a lot of bytes to play with in order to define additional logic.

The GetSupportingAlien function is currently a single large case statement -- it only has 140 bytes to play with to define how a support alien is selected.

The BuildPod function isn't any improvement -- it has 272 bytes.

With a much larger range of possible pod configurations, the possible difficulty of a mission can vary much more widely if an overly randomized approach to selecting the alien team is taken. This in turn could lead to situations where the player ends up facing impossibly difficult scenarios through straight-up bad luck. If the dropship evac zone worked consistently, I'd be a little less concerned, as tactical retreats are a part of good tactics ^_^

----------------------------------------

I've been trying to think of good synergies between the aliens -- a reason to place different aliens together within a single pod. Drones + other robots work because Drones can repair the primary robots. Really the only thing I can think of is having both tough aliens and agile flanking aliens together in one pod so that when it is activated the player has to deal with a wider variety of alien abilities.

This would be particularly important if there are fewer, larger pods -- since the player is less likely to activate an additional pod, you'd want a reasonably diverse ability mix within the single pod. This assumes that the current AI can deal reasonably with a larger pod.

The AI does have pod-level tactics built into it. A single enemy can be designated at the pod level, and all aliens in the pod will prioritize that enemy, for example. The AI can also execute a pod-level flanking maneuver, which allows it to force particular units within the pod to attempt to flank even if it is not the optimal move at the individual unit level.

I'm not sure how this will all work with fewer, larger pods. So far all I've really tested is whether I can get the information over and the pod built. I suppose I should release some "alpha-level" code to some people so that they can test the AI behavior with the larger pod sizes.

Once I've settled on how I'm going to transfer the data over, that is .... :)

[dubiousintent]

Well, however you implement this, I hope you also tie the size of the pods to the number of squad slots available to the player rather than just the date.

 

-Dubious-

[Amineri]

Well, however you implement this, I hope you also tie the size of the pods to the number of squad slots available to the player rather than just the date.

 

-Dubious-

 

 

Don't look at me! I'll just make larger pods available. It's up to johnnylump, Yzaxtol (and BlackAlpha if he is incorporating any of my mods) plus any other newcomers to decide how to balance things.

 

However, with this drastic increase in the number of possible aliens, I've been thinking about eventually resurrecting the attempt to increase the squad select UI to allow more than six XCOM soldier on a mission.

 

So far I've been unable to create a pod with more than three different alien pawn types. (not that I've run a bunch of tests or anything). My attempt to create a pod with 2 cyberdiscs, 1 sectopod and 2 drones left the drones invisible. Still more investigation required.

 

I don't know that more soldiers + more aliens necessarily makes for a better gameplay experience, but it might in some circumstances!

[dubiousintent]

I was thinking more along the lines of reminding of the need to limit the max size of the pods until each OTS gain increases the squad size to maintain some balance. But as you say: that is an implementation decision.

 

As for increasing the number of soldiers on a mission, I'm of the opinion that if you don't have enough excitement with six soldiers, more are only going to dilute the experience. However, I'm all for having options.

 

Keep up the flow of great ideas and capabilities!

 

-Dubious-