Page MenuHomeWildfire Games

[gameplay] give Fortress a territory root
ClosedPublic

Authored by Nescio on Jan 24 2019, 4:50 PM.

Details

Summary

This patch gives fortresses a territory root, which means that if you lose your centre, you won't always lose your all other structures as a consequence. For comparison, centres, wonders, and several special structures already have a territory root.

See https://wildfiregames.com/forum/index.php?/topic/25352-should-fortresses-have-a-territory-root/ for poll and further discussion.

[EDIT] Also lowered the territory radius of the fortress by 20% (i.e. a 36% smaller areas).

Test Plan

Agree :)

Diff Detail

Repository
rP 0 A.D. Public Repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

Nescio created this revision.Jan 24 2019, 4:50 PM
Vulcan added a subscriber: Vulcan.Jan 24 2019, 4:51 PM

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/differential/998/

elexis added a subscriber: elexis.Jan 24 2019, 6:06 PM

Giving root territory to more buildings had not rarely been proposed. D1164, also the proposal to remove territory entirely optionally.
But the more buildings receive root territory, the more it deincentivizes building, defending, destroying capturing, rebuilding the buildings that do have root territory.
As a defender this may be more comfort (but so would be removing the Health component of buildings).
Root territory being only a property of few rare buildings makes the gameplay more distinct from other RTS, gives more choices for defensive and offensive, stratgic or tactical moves and adds to the presentation of a city state. (Civic centers define an area as a small independent citystate. A fortress is a place to defend, but doesn't fulfil the same role as a civic center.)
So: Why? (And why not post the reasons for a diff in the summary or test plan when uploading a patch that isn't trivially correct?)
That some special buildings have root territory might have been an unconscious decision for some buildings (inherited form the parent without consideration), but I didn't research.
I'd rather go the opposite way and remove it from some buildings where it doesn't fit. I don't know whether it makes sense for the theatron gymnaseon or iberian monument. The latter was a unique gimmick so far. Perhaps one could create some relation to the historic realities of the embodied structures (and that historic reasoning could be manifested in the history string description, which would be displayed in the template info dialog from a23).

Thank you for your reply! No, I certainly don't think ordinary structures such as the dock should have a territory root. However, I do think it's appropiate for the fortress, because:

  • it's expensive: 1000 stone (civic centre costs 1500 resources, military colony 600)
  • it takes long to build: 500 (centre 500, colony 300)
  • it's limited to 10 per player
  • it is enabled only in city phase
  • it can only be build in your own territory
  • historical realism: a city was only conquered when all of its fortresses were taken; control of the city centre mattered, but wasn't decisive
  • gameplay: as you wrote yourself, a “fortress is a place to defend”; without a root you can simply ignore them and aim straight for the centre; with a root they will help defending your base, keeping nearby structures under control.

With this patch, the dynamic would be a bit different, yes, however, fortresses would continue to be functionally different from centres: centres allow you to acquire large tracts of territory (can be build in neutral territory, much larger radius), while fortresses allow you to keep it.

That some special buildings have root territory might have been an unconscious decision for some buildings (inherited form the parent without consideration), but I didn't research.

No, it's explicitly defined: do a grep -r "<Root>true</Root>" * and you'll find the following templates set a territory root:
campaigns/campaign_religious_test.xml
campaigns/campaign_city_test.xml
campaigns/campaign_city_minor_test.xml
structures/pers_tacara.xml
structures/maur_pillar_ashoka.xml
structures/cart_super_dock.xml
structures/pers_apadana.xml
structures/pers_ishtar_gate.xml
structures/rome_arch.xml
structures/iber_monument.xml
template_structure_civic_civil_centre.xml
template_structure_wonder.xml

(Actually I think it could be removed from the arch, Ishtar gate, monument, and pillar, but added to the (unbuildable) maur_palace)

ffffffff added a subscriber: ffffffff.
In D1762#70938, @Nescio wrote:
  • historical realism: a city was only conquered when all of its fortresses were taken; control of the city centre mattered, but wasn't decisive

Until all garrisoned fortresses are taken that is?
That would be the case with the current system already.
The question is what should happen to the civic, economic and military buildings if the enemy has taken over the city center, whether it would be good or bad gameplaywise and historically realistically to have the player "pop-blocked" and the economic nearby buildings unusable after losing a CC. The military ones (barracks) probably would still be in effect in history in the situation of a conquered CC I suppose.
(Also, the argument that the city has not been taken over yet until all defenses have been destroyed could be applied to towers and wall towers. But I guess these fortifications logically differ due to the garrison limit and people in the towers had given up if all fortresses were conquered? I can't speak on the history side.)

  • gameplay: as you wrote yourself, a “fortress is a place to defend”; without a root you can simply ignore them and aim straight for the centre; with a root they will help defending your base, keeping nearby structures under control.

Maybe you are right.
Let's consider however what will happen in 1v1s and 4v4s and last man standing games however. In order to defeat a player via root territory removal and pop-blocking, one now has to defeat many more buildings, it will make it easier to defend as you said. Making things easier to defend can prolong games. That might not be a dealbreaker either. But perhaps one could also consult few balancing brains and check whether that the territory radius and strength are proportionate under the diff etc.

Nescio added a comment.EditedFeb 16 2019, 12:05 PM

Some time ago I started a poll on the forums; there appears to be a clear majority in favour (12 to 7), although the number of votes is not overwhelming.

I have no idea what the proper procedure for implementing gameplay-related tweaks is. How to proceed?

Nescio updated this revision to Diff 7869.Apr 26 2019, 6:32 PM

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/differential/1296/display/redirect

Nescio edited the summary of this revision. (Show Details)May 31 2019, 7:17 PM
Nescio added a reviewer: Restricted Owners Package.Jul 6 2019, 5:37 PM
Nescio updated this revision to Diff 10703.Dec 21 2019, 4:02 PM

rebased

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/vs2015-differential/834/display/redirect

Successful build - Chance fights ever on the side of the prudent.

Link to build: https://jenkins.wildfiregames.com/job/docker-differential/1350/display/redirect

Nescio retitled this revision from Give Fortress a territory root to [gameplay] give Fortress a territory root.Dec 23 2019, 4:47 PM
Nescio removed reviewers: Restricted Owners Package, borg-.Aug 15 2020, 9:10 PM

If territory root were to be enabled for the fortress then I think the territory radius should be lowered. That way it will still let players keep the buildings nearby the fortress, but will make it much harder to go on without a new Civic center. I think it will still be frequent that players will not lose hold of a majority of their buildings as the buildings will just chain territory and thus the territory root, but will make it a bit more unlikely.

Nescio updated this revision to Diff 14074.Nov 19 2020, 4:31 PM
Nescio edited the summary of this revision. (Show Details)
Owners added a subscriber: Restricted Owners Package.Nov 19 2020, 4:31 PM

Successful build - Chance fights ever on the side of the prudent.

builderr-debug-macos.txt
../../../source/simulation2/scripting/JSInterface_Simulation.cpp:153:4: warning: suggest braces around initialization of subobject [-Wmissing-braces]
                        CFixedVector2D(-halfSize.X, -halfSize.Y),
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
../../../source/third_party/fmt/format.cpp:145:7: warning: '_POSIX_C_SOURCE' is not defined, evaluates to 0 [-Wundef]
#if ((_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && !_GNU_SOURCE) || (defined(__ANDROID__) && __ANDROID__)
      ^
../../../source/third_party/fmt/format.cpp:145:37: warning: '_XOPEN_SOURCE' is not defined, evaluates to 0 [-Wundef]
#if ((_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && !_GNU_SOURCE) || (defined(__ANDROID__) && __ANDROID__)
                                    ^
2 warnings generated.
In file included from ../../../source/graphics/tests/test_Camera.cpp:17:
/Users/wfg/Jenkins/workspace/macos-differential/source/graphics/tests/test_Camera.h:168:4: warning: suggest braces around initialization of subobject [-Wmissing-braces]
                        CVector3D(-101.0f, -101.0f, 101.0f),
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
In file included from ../../../source/simulation2/tests/test_SerializeTemplates.cpp:17:
/Users/wfg/Jenkins/workspace/macos-differential/source/simulation2/tests/test_SerializeTemplates.h:39:4: warning: suggest braces around initialization of subobject [-Wmissing-braces]
                        3, 0, 1, 4, 1, 5
                        ^~~~~~~~~~~~~~~~
                        {               }
1 warning generated.
builderr-release-macos.txt
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libnetwork.a(precompiled.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libtinygettext.a(precompiled.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libtinygettext.a(tinygettext.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/liblobby.a(precompiled.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libglooxwrapper.a(precompiled.o) has no symbols
../../../source/simulation2/scripting/JSInterface_Simulation.cpp:153:4: warning: suggest braces around initialization of subobject [-Wmissing-braces]
                        CFixedVector2D(-halfSize.X, -halfSize.Y),
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libsimulation2.a(precompiled.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libscriptinterface.a(precompiled.o) has no symbols
../../../source/third_party/fmt/format.cpp:145:7: warning: '_POSIX_C_SOURCE' is not defined, evaluates to 0 [-Wundef]
#if ((_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && !_GNU_SOURCE) || (defined(__ANDROID__) && __ANDROID__)
      ^
../../../source/third_party/fmt/format.cpp:145:37: warning: '_XOPEN_SOURCE' is not defined, evaluates to 0 [-Wundef]
#if ((_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600) && !_GNU_SOURCE) || (defined(__ANDROID__) && __ANDROID__)
                                    ^
2 warnings generated.
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libengine.a(precompiled.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libgraphics.a(precompiled.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libatlas.a(precompiled.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/libgui.a(precompiled.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/liblowlevel.a(dbghelp.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/liblowlevel.a(file_stats.o) has no symbols
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: ../../../binaries/system/liblowlevel.a(vfs_path.o) has no symbols
In file included from ../../../source/graphics/tests/test_Camera.cpp:17:
/Users/wfg/Jenkins/workspace/macos-differential/source/graphics/tests/test_Camera.h:168:4: warning: suggest braces around initialization of subobject [-Wmissing-braces]
                        CVector3D(-101.0f, -101.0f, 101.0f),
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.
In file included from ../../../source/simulation2/tests/test_SerializeTemplates.cpp:17:
/Users/wfg/Jenkins/workspace/macos-differential/source/simulation2/tests/test_SerializeTemplates.h:39:4: warning: suggest braces around initialization of subobject [-Wmissing-braces]
                        3, 0, 1, 4, 1, 5
                        ^~~~~~~~~~~~~~~~
                        {               }
1 warning generated.

Link to build: https://jenkins.wildfiregames.com/job/macos-differential/2018/display/redirect

ValihrAnt accepted this revision as: ValihrAnt.Nov 19 2020, 9:32 PM

It's an interesting change and will be good to see how it plays out in multiplayer.

This revision is now accepted and ready to land.Nov 19 2020, 9:32 PM
borg- accepted this revision as: borg-.Dec 14 2020, 5:34 PM
borg- added a subscriber: borg-.

I agree with @ValihrAnt, the changes are good.

This revision was automatically updated to reflect the committed changes.

Thank you, @Freagarach! It was long overdue.