Clear & Definitive solution(s) to 1upT -- if needed...

Zyxpsilon

Zyxpsilon

Running Spider
Joined
Oct 29, 2009
Messages
3,250
Location
On Earth
Introduction;

Some referencing for later use only -- Replies;
Spoiler :
#1
As i said earlier in other threads the only (probable, IMHO) solution to the 1upT controversy is a transitional movements principle that uses all 12 directions from the hex instead of the limiting default 6 **during** tactical deployment for pre-battle & optimal path seeking by any sizeable groups of Units -- this can also be done without having to extensively modify any in-code routines & functions.

Indirectly, this idea is a bit like what we see for built Wonders around our Cities; culps & corners are being used to locate items on a map.

ZoC ruleset can also account for clug restrictions when units move towards longer distances since they'd then have a corresponding range capacity. No more (what i dubbed) snaky curving waves path for cavalry for example by moving straight on edge lines between two hexes.
Heck, even Units could stand on such lines & corners; overlap might not look nice but cows & horses do it -- why not Units... if only for efficient (as in MUCH LESS cumbersome) deployment.
Click to expand...

Spoiler :
#2
The main issue is the ZoC and how range & immediate movements are somehow limited when Units are grouped tightly together.
Stacking is a mess of micman and doesn't really provide tactical edges besides pooled elements towards eventual combat phases. Don't get me wrong, it *IS* important to have battle support and progressive strategy aimed at specific targets.

Although, i also almost clicked on 6 -- Tactical layer for a very simple reason; it'd make or add some alternative combat gameplay elements. The danger being cumbersome while automation might be required in certain cases.

Secondly... 1upT isn't really the whole problem when one digs deeper into AI's algorithmic path or even, how slow proper deployment can get.

While you may think flanking is pointless, it sure is supposed to be an effective modifier **unless** a clog occurs barely outside the ring of the nearest 12 hex-tiles. That's where my transitional capacity above would solve many issues. By having free-will deployment (within 12 directions & appropriate distances) BEFORE combat begins, you'd actually use the 1upT to your advantage (or to the AI, btw) while keeping track - not of stacks - but of some available resources within reach.

It may seem complex at first, but the ZoC ruleset is highly adaptable once the principle of pre-battle conditions is clearly defined & given much less restrictions to movement functionality.
Click to expand...

Spoiler :
#3
About that controversial (and sometimes adversarial) 1upT concept.
There is a solution i've been thinking over ever since being caught in a loop of stuck movements in the games.
The clugs seem to be caused by ZoC rules based on the default available six hexes directions.

-- The only way, IMHO, is to allow for transitional steps towards the second outside ring of tiles... for a total of immediate 12 directions unless (as it happens) ZoC prevents some "escaping" tactics.
-- In a sense, the path calculations must consider a 1.5 ratio of accessible distances from the tile you're in and trying to get away from.
-- While this may feel like a scape goat for indirect ways to unclug a steady pace of deployment, you also should be aware that the targeted lines of sight or range values have some meaning. Right now neither can help if you're stopped within a Zoc.
-- The ruleset would need a total rework (specially for AIs) for things such as any army in tight groups.

Frankly, the 1upT has a knack for stalling progress. If the ZoC is altered... the lag effects would possibly feel much less awkward.
Click to expand...

I (must have added *WE* are) am working on such an indirect solution via modding some key components.
You have better ideas (excluding any variations of Stacking processes, btw), share them below... or tough luck.
 
I'm quite unclear as to how you get 12 directions from a hex. In any case, from your citation of cows and horses, you seem to be describing how the graphics are rendered, which is merely a cosmetic issue.

However, assuming that you are describing a genuine change in the topology of the map, how can you mod the pathfinding algorithm to use this? And - even if you could - how can you mod the AI (it's already pitiful when moving units as a result of 1upt) to take advantage of this new topology?
 
Doctor Phibes said:
I'm quite unclear as to how you get 12 directions from a hex.
Click to expand...
Inner ring is 6 tiles, middle ring is 12. OP is essentially suggesting that outside of instances where Zone of Control limits you to one movement, pathing should calculate based on the larger middle ring.
 
Nares said:
Inner ring is 6 tiles, middle ring is 12. OP is essentially suggesting that outside of instances where Zone of Control limits you to one movement, pathing should calculate based on the larger middle ring.
Click to expand...

Ah. Well that actually sounds like a fair idea. I don't see that it solves the deeper problems with 1upt, but it would help some. Trouble is, can that be achieved by modding, it sounds like a deep code change? I confess I've only flicked through the modding docs, but if something like this can be done then I might take more interest.
 
With a number of these "Events" (Example; SerialEventUnitMoveToHexes) ... and runtime access to DLL functionality.
The AIs already have progressive path finding assets and by tricking them into valid calls within a modified ZoC, we might (and i say this with a knife between my teeth!) wrapup a distance_range ratio balanced enough to freeup 6 additional directions around the current default six sides of an Hexagon.
Where's that image -- never mind -- i think you certainly got the angular reasoning that there are 12 hexes (6 of those on cusps and straightly lined with the internal hex corners) outside the immediate 6 surrounding a location tile.

PS;Gee - i type sooooo slow!
 
Zyxpsilon said:
With a number of these "Events"... and runtime access to DLL functionality.
The AIs already have progressive patch finding assets and by tricking them into valid calls within a modified ZoC, we might (and i say this with a knife between my teeth!) wrapup a distance_range ratio balanced enough to freeup 6 additional directions around the current default six sides of an Hexagon.
Where's that image -- never mind -- i think you certainly got the angular reasoning that there are 12 hexes (6 of those on cusps and straightly lined with the internal hex corners) outside the immediate 6 surrounding a location tile.
Click to expand...

Oh, I understand the geometry. But are you talking about privileging 6 of the 12 outer hexes that are 'on cusps' (needs diagram)? That doesn't seem quite right to me, it's a bit like returning to the diagonal distance problem with square grids - i.e. you throw away the whole reason for using hexes in the first place, that all directions are equally privileged.
 
I'm curious as to just how much this would improve functionality. I suspect the AI would still encounter problems with clogging, even with wider options for directional movement.
 
Sure... any ruleset limitations are open-ended in such principle.

If green-hex is where you Unit stands & blues are the only current possible movements. And Black-Z's are enemy owned.
Then, the un_zocced yellow tile South-East would be within immediate range & distance capacity to (white arrow) move.

Thus, un-clugging and tactical "escapes" from the situations at hand.
Much easier deployment before combat... TBS remember?

Now just imagine that YOUR green_unit is surrounded by 6_blues(5,4,3,2,1 or none) of your own & there's no ZoC limitation, in this case.
That's what this system does.
 

Attachments

  • Zocced_Off_w12_directions.png
    Zocced_Off_w12_directions.png
    21.8 KB · Views: 225
Zyxpsilon said:
Sure... any ruleset limitations are open-ended in such principle.

If green-hex is where you Unit stands & blues are the only current possible movements. And Black-Z's are enemy owned.
Then, the un_zocced yellow tile South-East would be within immediate range & distance capacity to (white arrow) move.

Thus, un-clugging and tactical "escapes" from the situations at hand.
Much easier deployment before combat... TBS remember?

Now just imagine that YOUR green_unit is surrounded by 6_blues(5,4,3,2,1 or none) of your own & there's no ZoC limitation, in this case.
That's what this system does.
Click to expand...

Ah, I see. You're simply suggesting it in the context of ZoC clogging. OK, it's a major kludge, but maybe it could help some. I share Nares' skepticism, though, about whether the AI could use it. It might get it even more confused.

Sorry, I shouldn't be discouraging. If you know how to do it (cos I don't, so kudos) why not give it a go? Things like this are always a source of new ideas even when they don't work perfectly.
 
Okay, but i'm also very skeptic (as much weird as it may sound to anyone!) about this whole "idea" for a simple reason; ruleset applications and how algorithms would react to it.
In a sense, the sneaky waves of Units moving towards looooonnnggg paths are a waste of precious move points *IF* a silly clug is a predictable or inevitable consequence.

It simply needs an optimal 12 directions to escape 50% (Incl. +/- Zoc limitations) of the current obstacles, be they opportunistic or tactically fair to all.

I'll come back with illustrated concepts once i have the debug phase done on some small but tricky file changes... i don't want to spoil the assumption -- so to speak.
 
wouldn't it just be easier to use triangles? 12 sides and a lot easier to draw / calculate / visualise / programme etc. Three triangles slotting together side by side would also give the hexagonal edge to make the game look as natural as it does now.
 
Zyxpsilon said:
Okay, but i'm also very skeptic (as much weird as it may sound to anyone!) about this whole "idea" for a simple reason; ruleset applications and how algorithms would react to it.
In a sense, the sneaky waves of Units moving towards looooonnnggg paths are a waste of precious move points *IF* a silly clug is a predictable or inevitable consequence.

It simply needs an optimal 12 directions to escape 50% (Incl. +/- Zoc limitations) of the current obstacles, be they opportunistic or tactically fair to all.

I'll come back with illustrated concepts once i have the debug phase done on some small but tricky file changes... i don't want to spoil the assumption -- so to speak.
Click to expand...

Looking forward to it, an intereresting exercise at the very least.
 
civnoob13 said:
wouldn't it just be easier to use triangles?
Click to expand...
Not in our case... for some core re-coding reasons.
But you might enjoy staring at this pre-dev concept template we had over at a GalCivIII brainstorming "reunion" a few years ago! Original thread here for reference.



Mind you, this was swiftly dispatched by the guys in a riot for being too complex and too hard to implement.
But - as they say - images are worth a 1,000 wordy triangles! ;)
 
Zyxpsilon said:
Sure... any ruleset limitations are open-ended in such principle.

If green-hex is where you Unit stands & blues are the only current possible movements. And Black-Z's are enemy owned.
Then, the un_zocced yellow tile South-East would be within immediate range & distance capacity to (white arrow) move.

Thus, un-clugging and tactical "escapes" from the situations at hand.
Much easier deployment before combat... TBS remember?

Now just imagine that YOUR green_unit is surrounded by 6_blues(5,4,3,2,1 or none) of your own & there's no ZoC limitation, in this case.
That's what this system does.
Click to expand...

If I understand this correctly, you are aiming at
a) breaking existing zones of control by just passing through
b) reaching the target hex (SE) in one turn where under current rules you would need two turns

To a)
What's the point of a ZoC, if you are implementing a system to bypass it?
To b)
You are re-inventing the problem of diagonals from the squares. Why not going back to squares then? (Not that I would propose that, but that's the logical consequence from your idea)
 
lschnarch said:
If I understand this correctly, you are aiming at
a) breaking existing zones of control by just passing through
b) reaching the target hex (SE) in one turn where under current rules you would need two turns

To a)
What's the point of a ZoC, if you are implementing a system to bypass it?
To b)
You are re-inventing the problem of diagonals from the squares. Why not going back to squares then? (Not that I would propose that, but that's the logical consequence from your idea)
Click to expand...
Some precisions...

First section;

a) Not really, the immediate ZoCs from enemy control remain valid *IF* a unit path collides with necessary linear trajectory. Thus, why the in-between supplemental 6 directions towards the external ring of hexes must be allocated in the ruleset for ZoC.
b) More like 1.5 (or less) -- in fact.

Second section;

a) Again, YOUR Zocs are altered (and indirectly of the AIs) during your TBS-Turn... not those of the enemy -- well not all of the enemy's as shown by the (white arrow) move from green to yellow by using the commonly shared line between Hexes.

b) I certainly do. And in some even greater scope. 12 ways to move from tile is a huge capacity. It's not having such a choice that causes clug and a number of obstacles to group deployment. If one can go by, so does what follows. It's a concept of flow rather than restrictions. All distances & Range being equal, even if we could add more move_points to a Unit - it would still be stopped by the enemy Zocs (think of a Mountain here for a split second, or even another of your units idled on such a tile) ahead or nearby. The logic is in the details.

Seriously -- it should be called Flanking Hell against Cities & Units, i might add.
 
What would this do to crossing mountain ranges?

If it makes them passable, then I don't know that the project is worth it at all.

Hopefully they can remain impassable.
 
The map_tiles ruleset doesn't need to be altered - so yes, Mountains certainly remain impassable.

The only difference being is that if two Mountains stand (blues) right between the green to yellow tiles path... the Unit could now be able to move straight on the white-arrow instead of having to make a huge sidetracking attempt to reach that specific tile. But, still wouldn't if an enemy Unit or another Mountain *IS* on that yellow target for moving. For combat though -- well, it's obvious that attacking hasn't changed except for the movement phase & its 1.5 capacity.
 
You must log in or register to reply here.

Similar threads

ggalindo001
Civ VII ideas from Old World
Replies
17
Views
2K
dagriggstar
D
Recursive
  • Locked
New Version - 4.2.7 (October 30, 2023)
16 17 18
Replies
350
Views
57K
andersw
A
Blake00
Heroes of Might and Magic 2 Scenario Mod (& HoMM1 Addon) - Release Thread
Replies
6
Views
2K
CurtSibling
CurtSibling
Recursive
  • Locked
New Version - 3.0.4 (November 29, 2022)
15 16 17
Replies
327
Views
42K
Recursive
Recursive
Recursive
  • Sticky
Vox Populi Congress Guide
3 4 5
Replies
85
Views
14K
Rekk
Rekk
Top Bottom