You Shall Not Pass!

Users who are viewing this thread

You Shall Not Pass is an attempt to give fortresses overlooking mountain paths the ability to prevent enemies from passing, forcing enemy units to take the long way round, while any allied neutral troop can pass right through.

Alpha 1 preview:

Download
Alpha 1 module system: http://1drv.ms/1DxWkbE
Ready to play on native: http://1drv.ms/1Fy1h66

As it stands, holding fortresses in strategic positions to control access to certain areas of land, roads, etc. is non existent, since any troop can pass by an enemy fortress.

This proof-of-concept will be for Maras Castle.

To have a mountain fortress control who passes nearby, I've placed a small stripe of mountain under Maras Castle, which will prevent any unit from passing and then created a script based path by using portals. There are two parties "Maras Castlewalls", one on each side of the castle. These will serve as portals (they are shown for testing purposes, in game they would be hidden):
288tjjk.jpg

I've edited every trigger, script & event, which gives parties an order to move somewhere and added a script, which will run distance checks to decide, whether the unit should travel directly to it's target, or travel through the portal and then to the target. If it's shorter for a unit to travel through the portal, it's original destination will be stored in a slot and the destination set to the closest portal entry. When the unit reaches the portal entry, it will get spawned at the other portal and original destination will be restored. If the party's faction is at war with the faction holding Maras Castle, this portal will be ignored and the party has to travel the long way around.

Since I have no idea how the path gets selected for the player, the player needs to visit Maras Castle and then can chose to travel to either side. This option will be hidden, if the player has negative relation with faction that holds Maras Castle.

fnh4qc.jpg

1ttyqv.jpg

By creating a script based portal across a mountain fortress, capturing and holding fortresses in strategic locations will become a vital part of the overall game strategy.

It's working decently so far.

However, there are a couple of bugs:
-some hole in the map under Maras Castle, since I don't know how to use blender properly
-Any party that wants to visit Maras Castle will use the portals, then walk a loop around the mountain. Instead of traveling to it directly.
-Sometimes it's not possible to access Maras Castle from both sides. Gotta experiment with the map a bit more to fix this.
-Haven't included the relation check, yet.

Probably gonna release as OSP, once it's working properly.
 
Good idea. I once did something like this too, to seperate every location of a town or castle into different icons. So there would be no town menu or anything, you would just go to shop in world map. I am glad you put something like this in Forge now. Again, good idea.
 
Well, made some progress. The relation check is in place and works for both ai and the player. Min relation to pass is 0 or greater. Bandits never pass, since no honorable lord would let them through.

In a test, I went to war with Rhodoks and conquered Maras Castle. Rhodok villagers, caravans and lords stopped using the portal, while swadian lords kept using the portal to harass Rhodok villages :wink:

About the castle icons, I'm gonna look into that, once the code works properly. Because atm. the ai can only cope with one portal.

About making the ai use the portal; It's a bit more complicated than I hoped it would be, but it works pretty well.

Initially, the game checks, whether the portals x&y coordinates lie between the party and it's target destinations coordinates (plus some 10-15m in all directions, roughly half a mountain width). If the portal is inside that rectangle, the game will calculate the distance from the party to it's destination. I'm using a multiplier to estimate the actual travel distance. The closer either the party or the target is to the portal, the higher the multiplier. Because if the party is close to a portal, and we know the portal is near mountains, it's actual travel distance around the mountain would be quite long. This will make it more likely for a party to travel through the portal, the closer it is to the portal, while parties, where both the party and their target destination are far away from a portal will not go far out of their way in order to use a portal.

I'm still trying to figure out the best way to prioritize portals, if multiple portals lie within the x&y coordinate.
 
Amazing work, I don't know how you managed to think of it, but well done!
 
Great idea. I will keep a close eye on this...

I have a simpler idea though. Maybe castles could have an 'attack', based on the number of ranged troops in their garrisons. A projectile would shoot out and hit armies within a small radius of the castle on the map. A script would calculate random casualties to an enemy party that drifted too close. This principal could be applied to besiegers, as well, with constructable siege engines that could implement the same effect on besieged centers.

It would not require parties on pathfinding work.
 
Strictly speaking, that would be simpler. With more impassable castles the scripts would get exponentially more complicated and could lag up the map. Although the ai would just ignore the damage it's taking and you'd still get slightly weakened armies milling about in your land. There'd also need to be some sort of check that prevents this from happening to besieging armies - perhaps an army only suffers damage one it enters the radius, and sets a party slot that prevents them from being attacked any further.
 
jacobhinds said:
Strictly speaking, that would be simpler. With more impassable castles the scripts would get exponentially more complicated and could lag up the map. Although the ai would just ignore the damage it's taking and you'd still get slightly weakened armies milling about in your land. There'd also need to be some sort of check that prevents this from happening to besieging armies - perhaps an army only suffers damage one it enters the radius, and sets a party slot that prevents them from being attacked any further.

It would definitely benefit from some changes to the AI. I understand what you are saying with the check, but I think the army should be "attackable" while it is besieging, at least when building siege equipment. It has always bugged me how parties take no casualties setting up ladders...
 
Those extra casualties would just be an unavoidable minor annoyance to a player who loses 10 huskarls when building a ladder. Considering how punishing and un-fun (native) sieges are, an extra few unpreventable deaths probably wouldn't go down well in most mods.

Anyway i always assumed the ladders were being carried by your men onscreen, but the game just shows the ladder in its final position because of engine limitations. It'd be silly, even for warband, if your men set up the ladder on the walls and just returned to camp, leaving the thing to be kicked down or broken by the defenders. :razz:

You could always use a few hints from history. The whole point of those pass castles wasn't to provide a physical block, but to provide a raiding base so that a passing army would be constantly harrased by the garrison, and so wouldn't be able to bring supplies through the pass without remaining close by. The ai doesn't seem to eat anything so implementing a supply system wouldnt really work, but enemy armies that passed without first capturing the castle could suffer a morale penalty - which has a range of effects.
 
jacobhinds said:
Those extra casualties would just be an unavoidable minor annoyance to a player who loses 10 huskarls when building a ladder. Considering how punishing and un-fun (nativ :wink:e) sieges are, an extra few unpreventable deaths probably wouldn't go down well in most mods.

Skilled troops would be less likely to fall. Also, different tactics would be available to the player to counteract the garrison.

Anyway i always assumed the ladders were being carried by your men onscreen, but the game just shows the ladder in its final position because of engine limitations. It'd be silly, even for warband, if your men set up the ladder on the walls and just returned to camp, leaving the thing to be kicked down or broken by the defenders. :razz:

True  :???:

You could always use a few hints from history. The whole point of those pass castles wasn't to provide a physical block, but to provide a raiding base so that a passing army would be constantly harrased by the garrison, and so wouldn't be able to bring supplies through the pass without remaining close by. The ai doesn't seem to eat anything so implementing a supply system wouldn't really work, but enemy armies that passed without first capturing the castle could suffer a morale penalty - which has a range of effects.

Great Idea!
 
jacobhinds said:
Strictly speaking, that would be simpler. With more impassable castles the scripts would get exponentially more complicated and could lag up the map.

For the time being, adding more portals will make the script more complicated linearly, not exponentially. I am currently testing with 6 portals on the map
The logic is as follows:
->Get xy coordinates of party, target_center and portal.
->Is Portal a in the party and target_center xy range? If yes, (assign, portal_a_in_range, 1),
->Is Portal b in the party and target_center xy range? If yes, (assign, portal_b_in_range, 1),
->(eq, portal_a_in_range, 1), if true, calculate, whether party would use portal a. If yes, (party_set_slot, portal_a, party_would_use_portal, party_no),
->(eq, portal_b_in_range, 1), if true, calculate, whether party would use portal b. If yes, (party_set_slot, portal_b, party_would_use_portal, party_no),
->Find closest portal, among those, which the party would use and assign it as ai_object to make the party travel there. If there is no such portal, assign target_center as ai_object.

But there is no calculation to find out, whether the party should use multiple portals. Currently a party will use a maximum of one portal.
 
Fire_and_Blood said:
But there is no calculation to find out, whether the party should use multiple portals. Currently a party will use a maximum of one portal.

Thanks for clearing that up - i guess it would be linear if you're only using one portal per journey. Since the ai tends to make short journeys within its own territory anyway i guess the pathing would work pretty well.
How about campaigning armies? If the marshall goes through a portal first, the others might get confused and go all the way round the mountain if the script doesn't fire often.
 
Actually, I'm not entirely sure, what would happen, if a campaigning army goes through a portal. If the lords have a specific goal, i.e. raid village x as a group, all lords will use the portal, but if they are just roaming, it might not work. If it doesn't work, I could add a check at the portal exit, that if "party_no", the portaled unit, is marshall, it would rerun the portal checking script for all lords of that faction.

Edit:
Also, it's probably much easier, to just rerun the script, whenever a unit has used a portal to figure out, whether it should use another one, instead of calculating beforehand, that using portal a->d->b is the shortest path to the destination.
 
You Shall Not Pass alpha 1 is released!

6 castles (Maras, Etrosq, Culmarr, Almarre, Sungetche and Negal) control which parties can travel through the path they are guarding. Only parties that have a relation of 0 or above with the faction holding the castle can pass. This is true for ai and the player.
For the player to pass, he needs to first visit the castle and then select the option "cross fortress".

Download: http://1drv.ms/1Fy1h66

Installation: Copy the .txt into Native module and start a new game.

For now, these are only the files to play. I still gotta go through the ms and make the code understandable.
 
Back
Top Bottom