Wall Gates - how should they work

[luziferius]

Hi there,

I‘ve searched a bit(Forum, Trac), but didn‘t find much about how the wall gates should work(high level).

only found the ticket #1385

Since there doesn’t seem to be any implementation currently, I think it is the right time to think about how those gates should work on a high-level base.

There are many possibilities how they could work/what features should be there(UI buttons to control behavior and such things)

I‘ve collected some points(the list below), that might be considered when implementing the gates.

Maybe the devs could rule out some of them that are impossible/very hard to implement,

for the others I would like to initiate some sort of discussion to get the best out of this planned feature.

1. should open gates magically block enemy units?
   

   The open gate could just operate like the farms do where allied and enemy units could just walk right through. This seems more sensible to me then AoE/M's way of having an open gate still block out enemies as if they were vampires or something.

2. UI controls: force close/force open
   
3. should your gates auto-open/close when own units are near? maybe only when those are following a path through it
   afaik in TA:Kingdoms you needed to open/close the gates by yourself, when you forgot to close them the enemy could easily invade...
   
4. only operational when a unit is garrisoned in it?(I wouldn’t like that, someone might find it to be more realistic)
   
5. what should happen when your and enemy units are near? should the gate let your units out to fight the enemy or should it keep closed to not let the enemy in?
   maybe 2 "stances":
   permissive: it opens when your units are near even when enemy units could pass the gate, maybe default
   strict: stay closed when enemy is in LOS,don‘t allow your fighting units to retreat into your territory, maybe overwrites force-open
   
6. UI controls: fine-tune what can pass the gate, "diplomacy stances"(that would include point 2):
   block nothing:let everything through(basically as if the gate doesn‘t exist, force-open)
   block enemy:(well, you know...)
   block neutral:blocks enemy and neutral units like animals and neutral players when diplomacy is designed to allow neutral players, maybe default stance
   block allies:only let your units through(prevent the allied AI from raiding your resources if you want to do such things)
   block everything: force-close
   
7. how long should it take to open/close the gate
   those gates from around 0ad aren’t instant-on/off-energy-shields… they need some time to open or close, but maybe not 30minutes(definitely not)
   
8. a global button/menu, apply the settings of the currently selected one on all gates
   
9. when(if) pathfinding based on LOS is implemented, should enemy gates be treated as closed even when they were open the last time seen(since they wouldn’t open for you normally)
   
10. to be continued…
    

Edited June 20, 2012 by luziferius

[quantumstate]

This was mainly discussed on irc. You can take a look at http://irclogs.wildfiregames.com/2012-02-04-QuakeNet-#0ad-dev.log . That is the main discussion I found with a quick search but there are quite a lot of other mentions.

[vts]

Indeed, I believe they were discussed on IRC, but I think they should definitely be moved somewhere more prominently visible/available. Helps ensure that everyone has the same understanding of what needs to be done. For the walls implementation, this was a thread in the staff forums, so perhaps we could create a similar public one for the wall gates with any decisions made on how the team envisions for them to work.

[Pureon]

I'll finish off the models and create the animations if some are needed, but first I need to clarify how gates function. Specifically, when the gate is opening the doors are going to swing out into the open - if something is in the way do the doors just go straight through the object, or do you need to move the object out of the way first.

I believe we may have opted for the doors to become passable (units can walk through the door models) as soon as the doors begin to open. This will help with pathfinding (units won't get stuck behind open doors when trying to walk through the gate) and make gates quicker to implement. Other more complicated functionality can be added afterwards if needed.

[Pureon]

Larger siege weapons will not be able to fit through the gates. Eventually most non-mobile siege weapons will pack into carts that will fit through.

As long as most of the door is within the gate structure, it won't look too bad.

[MishFTW]

Will Carthage get there special gate structure, the homah?

[feneur]

Will Carthage get there special gate structure, the homah?

Not directly. Later the Carthaginian walls were decided to be a civ bonus instead, see http://trac.wildfiregames.com/wiki/Civ%3A_Carthaginians#CIVBONUSES

[Pureon]

right i forget the packet mobile siege units XD

Hopefully someone will decide to take a look at implementing that sometime

[Pureon]

There's pathing and obstruction obstacles to overcome first, so there's more to it than just making the model animate.

[vts]

I'll finish off the models and create the animations if some are needed, but first I need to clarify how gates function. Specifically, when the gate is opening the doors are going to swing out into the open - if something is in the way do the doors just go straight through the object, or do you need to move the object out of the way first.

I believe we may have opted for the doors to become passable (units can walk through the door models) as soon as the doors begin to open. This will help with pathfinding (units won't get stuck behind open doors when trying to walk through the gate) and make gates quicker to implement. Other more complicated functionality can be added afterwards if needed.

I'm not aware whether any consensus has already been reached about this, but it seems to me like the way you propose is the better alternative, for one because making units move out of the way first creates pathfinding hazards/nightmares. I also don't think players would particularly mind to have the occasional unit walk "through" a wall gate that's swinging open, but they might mind the opposite: e.g. if at some point they need to retreat quickly but can't open their gates because they have 200 units in the way queueing up in front of the gate.

[luziferius]

This was mainly discussed on irc. You can take a look at http://irclogs.wildf...et-#0ad-dev.log . That is the main discussion I found with a quick search but there are quite a lot of other mentions.

thanks for pointing to the irc log

your link seems to be broken for me, i‘ve digged a bit, the working one (for me) is here: http://irclogs.wildf...-%230ad-dev.log

for anyone interested: i’ve searched through that log and here’s some sort of summary:

21:02 < Mythos> For gates, do we want them to act like AOK or AOM?

21:03 < quantumstate> I would say AoM

21:03 < Mythos> Okay, maybe we should be more specific.

21:03 < quantumstate> since then you remove the concept5 of opening and closing gates except for graphical purposes

21:04 < quantumstate> in AoM gates are permanently open for allies and permanently closed for enemies

21:04 < Mythos> Gate construction: (original 0 A.D. concept) Auto-placed when wall is built? or: Select long wall segment, click button, gate is placed? or: Select "gate" from worker UI and place it on the wall segment (AOK)?

21:05 <@Philip`> How would it know where to auto-place a gate?

21:05 <@Brian1> I think gates should be placed like in AoE3, but act like AoK

21:05 < quantumstate> auto placement sounds annoying, trying to get a computer do do the sensible thing is a bad move

21:05 < Mythos> Philip`: I assume it would alternate between 2 long wall segments and the gate segment.

21:06 <@Philip`> That sounds likely to annoy players when it auto-picks a stupid place

21:06 < Mythos> That was the original idea. Of course, we've ignored a lot of the original concepts over the years.

21:06 < quantumstate> Brian1: why do you say AoK style?

21:07 <@Brian1> So you can lock your allies out if they try to steal all your gold.

21:07 < Mythos> Alright, so, select a long wall segment, click the button in the UI to place gate. Does it place a fully-formed gate magically (AOM-AOE3), or does it lay down a gate foundation and we task units to build it (AOK)?

21:08 <@Brian1> Ideally, you'd just click on an acceptably long wall segment rather than the UI panel, but that may be too hard to implement.

21:08 <@Philip`> Selecting a wall segment then clicking an 'upgrade' button sounds to me like it should be easier for players than using the worker UI, since there's fewer steps and fewer opportunities to get confused, and it reduces clutter in the worker UI

21:08 < quantumstate> Brian1: That doesn't sound compelling to me, and AoM style is simpler to implement

21:09 < Mythos> Philip`: Agreed. But does it just swap out the wall segment for a fully-built gate, or does is swap the wall segment with a gate foundation, that then requires construction?

21:10 <@Brian1> Well, AoE3 gates would often left enemies in when my units went out to fight them. Changing the stances on all my units to prevent that is a lot more trouble than just locking the gate.

21:10 < quantumstate> I say directly switch to a gate

21:10 < Mythos> Let's stick to one problem at a time. We're at gate construction now.

21:10 < Pureon> I agree, swap out for a fully built gate

21:10 <@Brian1> Yes, switch directly

21:11 <@Brian1> Maybe for a small cost

21:11 < Mythos> Alright. Long Wall segment gets swapped directly for fully-built gate.

21:11 < Pureon> Small cost is good

21:11 < Mythos> For a cost, definitely.

21:11 < quantumstate> Brian1: AoM isn't like AoE3, enemies can never go through a gate

21:11 < Mythos> Alright, so now, how will a gate work?

21:11 <@Brian1> Well, only part of the long segment, not the entire segment.

21:12 < Pureon> Enemies should be able to walk through a gate if its open

21:12 < Mythos> Brian: A gate segment will be the same length as a Long Wall segment, for ease of swap.

21:12 < Mythos> Right. In AOM enemies can never walk through a gate, even when it's "open." Looked dumb to me.

21:12 <@Brian1> (Although I still prefer AoK style gates, I could probably live with AoM style)

21:13 < Mythos> Plus, I liked in AOK how you could rush your army through the enemy's gate.

21:13 < Pureon> Yeah me too

21:13 <@Brian1> Yeah, or lure them in... then have a trap...

21:13 <@Philip`> For pathfinding simplicity, I think it helps if passability is the same for every player

21:13 < Mythos> Alright, Philip just decided it for us.

21:14 < Mythos> But, a gate should not auto-open for enemy units.

21:14 < quantumstate> because a closed but unlocked gate is passible to the owner but impassible to enemies

21:15 <@Philip`> If you tell a unit to walk from one side of enemy's wall to the other, and there's a closed gate in the middle, what should the unit do?

21:15 < quantumstate> walk round the wall

21:15 < quantumstate> if there is a way round

21:15 < Pureon> It opens automatically for owner, but passability is the same for all

21:16 < quantumstate> Pureon: yes, but for path planning we can't treat it that way, otherwise your units would never walk through a gate since it would be impassible when they started moving

21:16 <@Philip`> quantumstate: If so, that's a bit annoying

21:16 < Mythos> Now you can see why AOM's gates are the way they were.

21:16 < Mythos> Even if they looked dumb

21:16 < quantumstate> Philip`: it is inevitable

21:17 < quantumstate> gates are fundamentally player dependent

21:17 <@Philip`> Mythos: AoM sounds like it has the same difficulty, since passability is still player-dependent

21:17 < quantumstate> Philip`: yes, it is simpler by virtue of not being time dependent

21:18 < Mythos> Philip`: in AOM, the enemy pathfinding treated your gate like any other wall segment.

21:18 < quantumstate> Philip`: so units will take fewer stupid paths

21:18 < Pureon> It's almost the same as a wall piece being destroyed and then rebuilt - how does passability work there?

21:19 < quantumstate> Philip`: How does your pathfinding deal with dynamic changes while walking?

21:23 <@Philip`> quantumstate: It doesn't - the unit will just crash into any new obstruction and then stop and compute a new path

21:23 < quantumstate> Philip`: That sounds reasonable

21:24 < quantumstate> Philip`: since it will be fairly rare

21:24 <@Philip`> Pureon: Changes over time are not a problem - it'll just recompute whatever internal data structures it needs

21:25 <@Philip`> My only concern is that I don't want to have to duplicate all the internal data structures for every player (since passability will be slightly different for every player) and use 8x as much memory, so the pathfinder will need to be made less dumb

21:26 <@Brian1> (So walls with all the necessary features is about a week-long task, or possible double that?)

21:26 < quantumstate> Philip`: you can just change the accessibility of the gate regiosn if that is fast enough

21:27 <@Philip`> quantumstate: That may be possible, depending on how long it takes to do those updates

21:27 < Pureon> I don't think it matters if the attacking force walks up to the gate to find it locked - it either finds another route or begins to attack the gate

21:28 < Pureon> gates will have less hp than walls right?

21:28 < quantumstate> I don't know if it would be possible to group a certain players pathfinding together

21:28 < Mythos> We could make gates one of the few infantry-attackable buildings.

21:28 < Mythos> (since you wouldn't "capture" a gate the same way you capture a house)

21:29 <@Brian1> Hmm, I'd say not, but it's not a big deal, to me either way.

21:29 < quantumstate> Mythos: I would say you would be more likely to try and capture a gate than a house

21:29 < Mythos> quantumstate: Right, but you would need to get *through* the gate first.

21:30 <@Brian1> I kind of think I'd rather force enemies to use battering rams, etc. rather than worry about my gates being captured.

21:30 < quantumstate> yes, in real life people tend to climb and stuff like that

21:30 < Pureon> I wouldn't like walls or gates capturable

21:30 < Mythos> right, I don't think defensive structures should be capturable anyway. They'd need to be destroyed.

21:31 < Mythos> I was just saying, we could allow non-siege units to attack gates. lol

21:31 < quantumstate> yes, that sounds reasonable

21:31 < Mythos> Where with a Barracks or House or something, they would try to capture it instead.

21:31 < Pureon> Yes, that works

21:32 < Mythos> A wall segment or turret? No, you need a siege weapon.

21:32 <@Philip`> Attackability would only help the pathfinding difficulties if enemy units never attempted to walk more than perhaps half a screen width to get around a gate, and always just walked up to the gate and attacked it instead

21:33 <@Brian1> That would preclude automatically generating gates as that would essentially allow enemies to attack any wall segment. Not that I like automatically generating gates anyway.

21:33 <@Brian1> By "enemies," I meant non-siege.

21:34 < quantumstate> Philip`: I think units should walk around where possible

21:35 <@Brian1> (You know what, It might be good to implement walls before finishing the pathfinder. (Hey, I have to try. )

23:13 < historicbruno> (reading the logs) about gates, I like how AoK gates worked, I would say the best (not the easiest) way of handling gate pathfinding, is enemies should walk up to the gate nearest the point inside the enclosed town they want to enter (of course if it's not perfectly enclosed they can just go around)

about the problem with the pathfinder and closed gates blocking own units:

you would need a player-dependant obstruction map for player-dependant pathfinding(I don’t know hard to implement that would be)[multitheading idea: 1 pathfinder per player with it’s own obstruction map]

own gates are always passable for own units(unless gate is locked, so units would walk through gates as the pathfinder finds a path through it) and only passable for enemies when it is in 'open' state(maybe even when in LOS too, but thats LOS dependant pathfinding, probably a bad idea)

Edited June 22, 2012 by luziferius

[FeXoR]

you would need a player-dependant obstruction map for player-dependant pathfinding(I don’t know hard to implement that would be)[multitheading idea: 1 pathfinder per player with it’s own obstruction map]

own gates are always passable for own units(unless gate is locked, so units would walk through gates as the pathfinder finds a path through it) and only passable for enemies when it is in 'open' state(maybe even when in LOS too, but thats LOS dependant pathfinding, probably a bad idea)

What would be the advantage of "opening" gates if your own units can pass them anyway? Pathfinding is already hard to do, so I don't think complicating it further would be wise.

[oddchild]

i agree with the idea that you have to manually close them. I think that would be great, and would make the game more difficult in a good way. Surprise attacks would be more surprising...

Programing wise it wouldn't be hard to implement. When you have a sprite, or a unit of area, you set mapstate or whatnot.

If gate = "closed" then

maparea = 1

else

maparea = 2

endif

If you have to deal with the detecting friends and foes, the coding becomes all the more difficult with pathfinding etc. Keep it simple, let the user close and open the gates.

[FeXoR]

i agree with the idea that you have to manually close them. I think that would be great, and would make the game more difficult in a good way. Surprise attacks would be more surprising...

Programing wise it wouldn't be hard to implement. When you have a sprite, or a unit of area, you set mapstate or whatnot.

If gate = "closed" then

maparea = 1

else

maparea = 2

endif

If you have to deal with the detecting friends and foes, the coding becomes all the more difficult with pathfinding etc. Keep it simple, let the user close and open the gates.

That way you would still need multiple areas to update for the pathfinder. It has to take care of moving/dynamic objects anyway so you could just place a blocking "gate door entity" when the gate is closes and remove it when it's opened. So a gate would be like 3 entities: 2 for the parts that always block (walls at the edges) and one for the center part that only blocks if the door is closed. I don't know if it would be easier to remove the center "gate door entity" or lower it's collision radius to 0 (or remove it's footprint).

Edited June 24, 2012 by FeXoR

[wrod]

I think once the walls are implemented there should be different "stances" for the wall for example

Open:its like open for anyone or anything wanting to go through

Friendlies:only friendlies can go thru

Trade:only friendly trade units can go through

Embargo:friendly units except trade units

Warring:only friendly soldiers and healers and trade units go thru

Full war:only soldier units can leave

[luziferius]

about the problem with the pathfinder and closed gates blocking own units:

you would need a player-dependant obstruction map for player-dependant pathfinding

own gates are always passable for own units(unless gate is locked, so units would walk through gates as the pathfinder finds a path through it) and only passable for enemies when it is in 'open' state(maybe even when in LOS too, but thats LOS dependant pathfinding, probably a bad idea)

What would be the advantage of "opening" gates if your own units can pass them anyway? Pathfinding is already hard to do, so I don't think complicating it further would be wise.

that wasn’t about really opening the gates, but a trick(a hack?) to get the pathfinder working with dynamicaly opening gates:

when the door is closed, it blocks tiles->the pathfinder sees blocked tiles->doesn‘t find a way through the door(since it is closed atm of the pathfinder query); you see the problem!?

so your(as a player) pathfinder should see the gates as always open(until force-close or something is triggered) to allow routing through them.

in reality the gate is opened when the units arrive and closed when they go away, and only in this timeframe the door is really open(so enemies could pass)

but the enemy shouldn’t see your gates that way, because if the enemy pathfinder would, you would almost always stuck your units at enemy gates(and vice-versa)

Edited June 27, 2012 by luziferius

[FeXoR]

that wasn’t about really opening the gates, but a trick(a hack?) to get the pathfinder working with dynamicaly opening gates:

when the door is closed, it blocks tiles->the pathfinder sees blocked tiles->doesn‘t find a way through the door(since it is closed atm of the pathfinder query); you see the problem!?

so your(as a player) pathfinder should see the gates as always open(until force-close or something is triggered) to allow routing through them.

in reality the gate is opened when the units arrive and closed when they go away, and only in this timeframe the door is really open(so enemies could pass)

but the enemy shouldn’t see your gates that way, because if the enemy pathfinder would, you would almost always stuck your units at enemy gates(and vice-versa)

Ah, ok. That still leaves the problem with the player dependent obstruction mapping. But if it can be done...

[Alpha of the Eagles]

Do it simple like Aoe. Opens for friendlies, but during a retreat it can be locked to prevent enemies from entering. Could be convertable, but in that case, not while it's in lockdown.

[luziferius]

I think the simplest way doing it is(programming wise):

• pathfinder always sees gates as open(units would stuck in front of gates) and
  
• not doing any automation; only let the player open/close gates
  

(but that somehow shifts problems into the AIs, since then they must know how to use gates)

[Alpha of the Eagles]

i repeart the problem are around the Programming that. its technical non conceptual.

I think in Aoe2, when the gate is 'closed,' it seems as though it loads a model that blocks the path for the units. I don't think the programming would be hard, relatively speaking, but as I'm incapable of doing it myself, I probably should weigh my words carefully.

[wrod]

here u go alpha *passes him a scale* u can use that to weigh ur words!

[Alpha of the Eagles]

here u go alpha *passes him a scale* u can use that to weigh ur words!

Is it metric? I'm Norwegian.

No, seriously, what I meant was that a 'simple' scenario is entirely different from a users perspective and a programmers. But, I reckon they probably have a solution in mind already.

[Pureon]

But, I reckon they probably have a solution in mind already.

Or even a partly functioning solution

[gudo]

You know... If you check trac, specifically changeset 12081 you'd see that gates are in SVN. Currently, they lack animations and a few may need to be re-modeled. But the important thing is that they are in and they work!

[Pureon]

Currently, they lack animations and a few may need to be re-modeled.

Re-modeled? Two of them are the wrong size, so I'll fix those when i commit the animations.