New Siege Implementation: Siege Claims

[rye130]

Any chance you can comment on my understanding of how to abuse the new system? The diagrams not that ugly

[loftar]

No, not really. Core design should be fairly abstract to accommodate flexibility in concrete implementation, but still concrete enough to avoid feature creep. It's kinda hard with complex projects like MMOs but I don't believe it's impossible.

I don't really see the point. I would argue that the problem we're having is not so much with the objectives, but with finding a concrete implementation that fulfills them. I don't think it would be unreasonable to say that our design principles with the siege system are, quite simply: Reasonably aesthetically pleasing, feels reasonably fair to both the winner and the loser, and accounts for the fact that people don't play 24/7. Those has been fairly consistent throughout all the iterations of the siege system; the problem is making something concrete that fulfills them.

Also:

Once you complete the core design (and it's still incomplete going by the about page), you should have a stable, balanced and fully functional game, and only then should you thing about making v2 of the game with expanded core.

I would argue that we had a stable and somewhat functional siege system in World 10, implemented as its core design prescribed. Now we're making v2 of it. I'm sure you're not saying we should throw out all the rest of the game just to make the next version of one part of it, because that seems rather unnecessary and wasteful.

Anyway, please read at least the first chapter of Code Complete. It's free, it's well written and it's insightful. Come on, what do you have to lose ;)

It seems like a book about software design rather than game design, so I have to say I don't really see the relevance.

[loftar]

Any chance you can comment on my understanding of how to abuse the new system? The diagrams not that ugly :cry:

I'm not really sure it constituted "abuse", quite simply. The point about encircled claims would have been just as true for the siege system last world, where it wasn't exactly a huge problem. The part about wall layers 100+ tiles apart assumes partly that there's no siegeable objects whatsoever in between them to extend the siege bubble, but even if there aren't, I don't necessarily think the ability of some level of compartmentalization is an altogether bad thing.

[loftar]

Thats why the +damage stacks. You can move it and keep attacking the next wall with a bit more damage.

The feasibility of that solution depends on the range you can move the siege engines without their efficacy dropping too much. If you make that range too large, an attacker will simply "charge" his siege engines outside the claim of the defender and avoid the time limit, and if you make it too short, multiple wall layers are there. I'm not confident there is a Goldilocks zone between those extremes.

To add to that, the survival of the siege engines seems critical for the same reason, and depends on the attackers being constantly online, which is the exact same problem that we're currently trying to deal with.

[Potjeh]

WTF? Since when are games not software? The principles apply to all forms of software and beyond, heck I'd say most design principles are transferable across all forms of engineering.

As for those principles for siege system they seem solid, but I don't really see much effort to follow them in the concrete design. Specifically, I don't see how can binary siege with hard outer shell and soft innards mesh with the second objective, and every iteration of siege thus far has used the shell design.

[irongete]

Thats why the +damage stacks. You can move it and keep attacking the next wall with a bit more damage.

The feasibility of that solution depends on the range you can move the siege engines without their efficacy dropping too much. If you make that range too large, an attacker will simply "charge" his siege engines outside the claim of the defender and avoid the time limit, and if you make it too short, multiple wall layers are there. I'm not confident there is a Goldilocks zone between those extremes.

To add to that, the survival of the siege engines seems critical for the same reason, and depends on the attackers being constantly online, which is the exact same problem that we're currently trying to deal with.

Siege engines should not charge if attacking unclaimed walls.
About the attackers being constantly online, thats what a siege means. You want to siege your enemy so you need to cut supplies from the city therefore you must be there.
Maybe a different aproach: you can only attack the siege weapon when your enemies are inside this "virtual zone" (battlefield). But give some good hitpoints to the siege engine. So attackers need to keep defending themselves, repairing the siege engine and attacking the wall.

[loftar]

WTF? Since when are games not software?

Of course, but the problems we're having is not with the codification and implementation of the features, which is what this book seems aimed at: programming per se rather than finding the goals to begin with.

As for those principles for siege system they seem solid, but I don't really see much effort to follow them in the concrete design. Specifically, I don't see how can binary siege with hard outer shell and soft innards mesh with the second objective, and every iteration of siege thus far has used the shell design.

Simply because we haven't found a better concrete system for it that better fulfills the same second objective.

[loftar]

Siege engines should not charge if attacking unclaimed walls.

The attacker will just claim the walls themselves in order to charge it up, though.

About the attackers being constantly online, thats what a siege means. You want to siege your enemy so you need to cut supplies from the city therefore you must be there.

I think you'll find the current players who might consider siegeing someone will disagree with you.

Maybe a different aproach: you can only attack the siege weapon when your enemies are inside this "virtual zone" (battlefield). But give some good hitpoints to the siege engine. So attackers need to keep defending themselves, repairing the siege engine and attacking the wall.

That's a somewhat interesting idea, though. Will ponder what it would mean. Mind you, it doesn't solve the problem of multiple wall layers in itself, but it's somewhat interesting.

[ricky]

So i'm going to walk through what (i think) happens when a village is sieged. correct me if/where i'm wrong

1) the attackers build a siege engine
--- it has Xhour cooldown

2) after the cooldown, it can be used to attack a village tile (a wall in this case)
--- the attacked tile creates an YxZ (you're saying 100x100) 'siege claim' which generates 'siege authority'
----- the attacked tile checks how many claims are underneath it, and those claims are subject to the siege.
-------defender's walls not within the siege claim, but still on the defender's claim are still invulnerable.
--- siege authority is generated by only siege engines, with an upper limit of authority generated per unit of time.

3) after X number of consecutive attacks (on the same tile? within the same siege claim?) with a siege engine, an authority threshold is reached which allows the player to attack and break the walls(with siege weapons, not by hand?).
--- palisades have a lower threshold than brick walls
--- the siege engines dont actually damage the walls until the threshold is reached

4) the attackers break the walls, and are free to loot/destroy however they please, as they have breached the wall, thus avoiding any visitor debuffs.

some questions:
siege claims are only generated if the siege is a crime. if a siege isnt a crime, is it essentially "unclaimed" and walls can be broken immediately?

how exactly does the siege claim 'shift' work? an attacker builds a new siege engine on:
A) the same siege claim, attacking a different tile. will this shift/expand the size of the siege claim?
B) outside the original siege claim, but close enough to where both claims touch. is the original claim still there? what happens on the intersection of these two claims?

in what way does a vclaim or pclaim's authority work into this system? claims with 0 authority can be sieged immediately as if it were unclaimed?

as a defender, what options do I have to expedite the removal of a siege claim?

[Potjeh]

Actually the first chapter isn't about programming at all. It's about defining project requirements and stuff like that which applies to all sorts of engineering. Seriously, do you not like reading about this stuff?

As for shell design, have you honestly made an effort to come up with something different? It's obviously not working, yet you keep tweaking it over and over. Is there a point at which you'll decide it's a dead end and switch to a different paradigm to try and refine? Even Salem's system seems more promising, but it hasn't been iterated on very much.