xUPT

[Calavente]

They have to stop rotting at some point of time or they would turn into skeletons.

but maybe they eat... to replenish their rotting flesh...

 

[PPQ_Purple]

One word: Superglue

 

[El Yahpo]

in the xanth series a zombie has the magic power to never loose mass through decay, it just regenerates... magically

 

[Calavente]

I love this solution !
(And love this series.... but in the end it becomes too much)

 

[PhoenixMuse]

[After reading the first two pages of this thread, I realized that it would be insane to try to read the entire thread. So this post is only after reading the first two pages.]

Option Settings

Will the option allow you to set the exact number of units per tile that are allowed?

Limit # Vote: 7 units per tile

If not, I'm suggesting seven units, because that's the maximum number of dots that are displayed to show the number of units. And, because seven is a good number.

Summons

I agree that summons that are permanent should take up .5 of a 'slot' and that temporary summons should not count.

Forts

I think forts (if we're doing it based on 7-unit-limit) should be +4 units within the tile.

Boats

I think boats need to work a little differently. The max per boat should be six units on the boat (so it's still seven units), and then a maximum of three boats in a tile (regardless of how many units each boat is carrying.)

Impassible Terrain

I love this thought because it makes it so that units that can travel through impassible terrain may actually now have some meaning!

Cities

I think cities should have a limit of of seven units like every other tile until the city reaches beyond size seven. For each population size it should get one more unit slot on the tile up to fourteen units.

Heroes Of Doom

I don't think a stack of seven heroes surrounded by adepts, ranged units and units with good retreating abilities stands a chance. I also don't think a bunch of warriors, no matter how large the stack, stands a chance against seven heroes. In conclusion, I think small-hero stack of doom doesn't change game balance at all.

Time Between Turns

Time between turns is way, way too long as it is. I think that regardless of this implementation some serious work needs to be done on getting AI to spend less time shuffling things pointlessly. If this increases that lag, I think it would be a serious detriment to it's use.

 

[Valkrionn]

[After reading the first two pages of this thread, I realized that it would be insane to try to read the entire thread. So this post is only after reading the first two pages.]

Not a problem.

Option Settings

Will the option allow you to set the exact number of units per tile that are allowed?

Yes, the exact number.

Limit # Vote: 7 units per tile

If not, I'm suggesting seven units, because that's the maximum number of dots that are displayed to show the number of units. And, because seven is a good number.

You can play with however many you wish. I personally will be using 8 or 10, to get a good range of the unitcombats that will be in the game (without allowing all of them).

Summons

I agree that summons that are permanent should take up .5 of a 'slot' and that temporary summons should not count.

Yep. Will likely have a float tag allowing units to take up more or less of a slot. So some may be half.... but others may be double (Here's looking at you, Monstrous Creatures!).

Forts

I think forts (if we're doing it based on 7-unit-limit) should be +4 units within the tile.

Maybe. Easy to add a variable to Plots which allows us to change how many units are allowed on the tile (thus available from Terrains, Features, and Improvements), just not sold on it.

Boats

I think boats need to work a little differently. The max per boat should be six units on the boat (so it's still seven units), and then a maximum of three boats in a tile (regardless of how many units each boat is carrying.)

Would be a per-domain thing. Naval units don't count vs the land limit unless in a city, and land units would not count vs the naval limit.

Impassible Terrain

I love this thought because it makes it so that units that can travel through impassible terrain may actually now have some meaning!

Cities

I think cities should have a limit of of seven units like every other tile until the city reaches beyond size seven. For each population size it should get one more unit slot on the tile up to fourteen units.

City limit modifier will either be configurable separate from the standard limit (so a limit of X + city limit of Y), or hardcoded to 1.5x or 2x.

Heroes Of Doom

I don't think a stack of seven heroes surrounded by adepts, ranged units and units with good retreating abilities stands a chance. I also don't think a bunch of warriors, no matter how large the stack, stands a chance against seven heroes. In conclusion, I think small-hero stack of doom doesn't change game balance at all.

I agree. Would be powerful, but without support would still go down.

Time Between Turns

Time between turns is way, way too long as it is. I think that regardless of this implementation some serious work needs to be done on getting AI to spend less time shuffling things pointlessly. If this increases that lag, I think it would be a serious detriment to it's use.

It shouldn't increase speed much at all, I'd think... Depends on how it's done. That said, we've already increased speed massively from 1.23, and that will likely continue.

 

[Valkrionn]

Necroing my own thread...

The initial version of xUPT is now implemented in RifE, via the Development branch of the SVN (check the Beta subforum of the new forums if you don't know what that is ).

As of yet, there is no tag on units/promotions/improvements/whatever to modify the count; It's a flat X number of units, no modifications. Cities are subject to the same limit, and will bump units out to the nearest valid tile if the city is full; If there is no valid tile, the unit will be left in the city. In the future, we may prevent unit creation in it's entirety if full.

There is a new button on the interface (check the screenshots; It's located in the upper-right corner, under the screen buttons) which displays the current UPT value, and launches a popup allowing you to change the value. It also allows you to Lock the value, preventing you from modifying it again for that game.

Alternatively, you can use a keyboard shortcut added prior to the button, Shift-U, which is also subject to the lock (unless chipotle is enabled in the ini).

Pretty much all I've got for now. It's in, it's working, the interface is done. If you want to play with it, grab the latest SVN revision and give it a whirl.



Now, pictures.

Icons + Popup:


Full Screen:

 

[Morkonan]

...To go with this, I'd probably include his "Surround and Destroy" mod as well, which grants combat bonuses when you surround enemies; Each plot around the enemy that is occupied by your units grants a bonus, up to a max of 60%. This would only be active with the UPT enabled, otherwise it would be too easily exploitable against the AI which would not use it.
...

In regards to Surround and Destroy, I have a better suggestion.. Though, it will take a long time and some diagrams to explain why a simple "+" value for occupying adjacent squares is not a good idea.

In essence, to keep it brief right now, amazingly enough, - While it sounds nifty, there's no expense to be paid for that advantage in bonuses.

That may seem counter-intuitive. After all, if you have the units, you should be able to extend the front, getting a bonus for bringing greater number of troops to bear on the conflict. But, if you do it like that, then there's no reason to have a limit on Unit Stacks since you're just introducing a mechanic that gives bonuses for not stacking units you can't stack anyway... Sort of a "Monty Haul" approach towards engineering combat bonuses.. Every door has good prizes and there's no penalties to be paid.

Put it this way:

You have stack A and B attacking stack X. Sending two stacks off to attack another stack from the SAME direction is no big deal at all. With xUPT you WILL be doing that a lot. Further, those stacks can re-supply each-other. In other words, because they are adjacent, they can switch troops back and forth to protect the most vulnerable stack or take advantage of other opportunities.

That is already a ++ mechanic with the only drawback that certain AOE spells can't be cast. That's no biggie, anyway. Some of those can have a range +1 so you'd never get away with casting them when two of your stacks are attacking the same unit.

Without me getting out a hex sheet and explaining it, here's the simplest way to put my suggestion: (Never mind.. did that below anyway..)

Only give bonuses to stacks that are either attacking from opposite directions (rear attack) or attacking from a tile that is at least one tile away from the other attacking stack (flanking attack). Why? Because, in order to get this rather handy bonus, you must expend additional movement points and time (maneuver), potentially isolate a stack in a precarious situation where its own flank is exposed to a relief/counter attack by enemy units in the area (giving the enemy exactly the same bonuses as you're seeking) or have the terrain and route necessary to maneuver for the attack. In some cases, you will have to expose yourself to additional fire for several rounds, as well as attacks, in order to maneuver for that kind of attack.

This introduces a battlefield "tactical" element into what is normally a strategic game with simplified battlefields. So, in that respect, "Surround and Conquer" is sort of neat. But, it's capable of being "Right" instead of just neat.

Look at it this way:

You are going to assault a fortification. Now, flanking a fortification isn't that big a deal. They're really slow... But, for game-sake, let's say you want to consider that tactic because of the heavy defense values the defenders have. But, simply moving so that you have two stacks attacking from adjacent squares costs you nothing except for the cost and upkeep of additional units.. (Which, is practically nothing unless you force a unit count for all attackers.. which will probably have a bit of processing overhead in the mid/late game.) So, how do you balance this off while introducing a penalty? That's easy - You make it more realistic.

Widening a front thins out defenders. But, for the purposes of RiFE/Civ, that's not a mechanic that is much worried about and with xUPT it's going to happen in almost every meaningful engagement. However, because tiles can get cramped with units, dangers, civ culture borders and impassable tiles, maneuver is a very well used game element. In this scenario, you're going to build on that. So, as the attacker, you must have:

1) You must have the room to maneuver, which may be difficult. Imagine attacking a fortress on a coast with a mountain behind it. That's why fortresses are found on the sides of cliffs in the Real World anyway - You can't attack it from two different directions. Culture borders can work the same way as well as water tiles. Even undesirable tiles where you would get no defensive bonuses (thus, being counted as "exposed") would serve that similar purpose.

2) You must be willing to expose your units to a flanking attack themselves. Their attackers, should they appear, will also get a bonus because it is likely they will appear from the direction you have been advancing towards to begin with. In order to flank/rear attack another stack, one stack will likely be facing the direction it was advancing from when you initiate your attack.. which is likely facing away from the enemy's main source of troops and supplies.

Dangit.. I guess I got to draw something.. Here, this graphic incorporates most of what I'm talking about:




Stacks A+B are assaulting a fortification. If they got a bonus just for being next to each other, that would require nothing extra on their part. Further, they'd likely be assaulting in that manner anyway. It requires no extra movement or time to do so. If they got a bonus for THAT, they'd be getting freebies..

However, in order to get this version of an additional battlefield tactics bonus, one of the stacks must maneuver. We decide to let stack B do that. So, we send B south, along the coast to engage the enemy position from the rear. The only way stack B can do that is by exposing itself to harassing fire from X for at least one turn. But, B does it and is now in position. Yet, B is also "exposed" in that its own rear is exposed to possible enemies coming to reinforce the position. Whatever attack plan we have had best be quick. Otherwise, stack B is going to get caught between two stacks of enemies and its attackers will get the same bonuses we're looking to capitalize on now and we have no way to easily "relieve" stack B in case it is attacked!

If you gave bonuses for simply being adjacent, it would be a bad use of this sort of idea. With xUPT, you'll have many, many combats that involve the use of multiple stacks and there's very little reason for an attacker to worry about whether or not they can take advantage of such a formation. However, if you introduce flanking and/or rear attacks to the battlefield, then the attacker must take terrain and the position of other units into account as well as movement points and their own ability to keep their flanking units safe from counterattack.

Another point - Envelopment is rare. It's rare because of two reasons:

1) Usually, nobody is dumb enough to become enveloped.

2) Enveloping units (surrounding them) introduces a "Fight To The Death." Nobody wants that possibility. You can not surrender individual battles in Civ. So, every single battle is a "Fight to the Death" unless one of the two chooses to retreat to live and fight another day. If you surround an enemy in this situation, they have no lines of retreat. (ALWAYS give your enemy a line of retreat that you can control.) If they have no lines of retreat and are surrounded, giving the attackers an attack bonus because of that is a bit silly. That's like giving a winning lottery ticket to Bill Gates. What's he going to do with that? No. Instead, what you really should do is give a defense bonus to the defender! They are fighting for their lives with no hope of surrender.

Picture Bastogne. A commander is surrounded and he refuses to surrender. The enemy is more powerful and already outnumbers him. Only through sheer force of will can the commander hold out. And, as luck would have it, he does.

Stalingrad - The city is over-run. There is no possibility of retreat (due to orders and the lines of supply not being able to support a massive retreat). The defenders fight for their lives in starvation conditions. They're not just soldiers carrying guns able to turn and run away. Either they face the guns of the enemy or the guns of their own countrymen.

3) Enveloping units costs troops, usually a significantly greater number than the forces you are enveloping. Thus, the only reason to envelope units is to avoid having to assault what are usually fortified positions. Otherwise, you'd just expend the troops necessary to kill the unit and move on. Envelopment is costly so one had better have a very good reason (heavy static defenses) to try it and one had best be sure all the enveloping units can withstand a concerted attack by the defenders, else they will break out and threaten the flanks of the attackers. In this last case, envelopment is only used to force a surrender or attrit defenders due to cutting off lines of supply. Neither option is available in Civ...


Envelopment should not get any combat bonuses in this particular game, IMO. If you're going to use the mechanic, use it for the benefit of the game. If it can't be coded like I explained above, don't use it at all, no matter how "neat" it is.

 

[Kylun Creed]

I'd personally rarely, if ever, use it.

But that's the way I like to play. I've made marathon even slower, I removed the national limits on units (which is really fun when someone summons the Mercurians or Frozen, though I allow them sparingly.), and I throw in excessive amounts of civs so that I tend to be at war with 10-20 (or more) people so that I can see lots of big stacks of big units.