- It needs to be possible to remove a player from any location, and thus it needs to be possible to force fundamental conflict.
- Sieges should be visually appealing. They should look like sieges, and not depend on ugly, non-visual states.
- War and siege should be a collection of informal, localized states, rather than formal and global. Formal states create distinct interfaces between states that are prone to manipulations, workarounds and exploits. The game devolves to a game about those states, rather than a game about siege warfare.
- That players actually make progress in a siege is not too important. What is important is the ongoing threat of being able to do so if not prevented or counteracted, and the ability to always/often act toward furthering this goal. As long as both sides have to/are able to continously take meaningful action on account of the siege, it does not matter whether either side actually breaks the other, but in fact a protracted siege is highly desirable. This in itself creates activity and a sense of action and purpose.
- Sieges should not seek to force players into being online simultaneously, but should rather seek to create points of overlap in time and space with opportunities for encounters.
- Sieges should, ideally, have several possible vectors of attack
- Losing should ideally be fun. If the process of losing is drawn out over a longer period of time, it can potentially be fun.
- Sieges should be subject to a great deal of inertia.
The insight I arrived at, thus, was that, quite simply, a lot of the game states are too volatile. Sieges, historically, have not been fun, largely because you loose everything in an instant, without much ability to counteract it.
What we want to do, thus, is simply to insert many more time gates into the process than presently exist. As it stands there is a 24hr waiting period for the ram, and that is it. We'd like there to be lots more, and probably a lot more fine-grained. For example.
- Place a ram. Four hours later you can move and use it.
- Ram a wall segment. You can knock the wall down two steps (arbitrary scale) every, say, six hours.
- Repair a wall segment. You can repair the wall one step every four hours.
- Place a catapult. Eight hours later the catapult can be loaded.
- Load a catapul. One hour later the catapult can be fired.
- Fire a catapult. A shower of stones scatter with some randomness over an area, damaging constructions and players in it if they hit. Four hours later the catapult can be re-loaded.
- Strike a cow. The cow falls prone. 6 hours later the cow can be struck again. Three strikes and the cow dies.
- Smash a siege engine. Three hours later it can be smashed again.
- Smash a locked door. Four hours later you gain entry to the house.
- Smash a locked chest. Two hours later you gain entry to the chest.
&c&c&c. Ideally there'd be a million little time-gated states like these that theoretically allow you to raze a settlement entirely if you so desire, but which require you to put up consistent effort over several days in order to actually do so. Note that the numbers and ideas here are pulled out of my ass, and express principle rather than actual considered implementation.
I want to imagine that the inertia of a system like that -- you have time to call allies, potentially lay counter-sieges, encounter perpetrators while they are actually online, &c&c -- could potentially create a system that is, indeed, actually dynamic and fun.
Various aspects of this has been suggested before. There are a million little details for the devil to hide in.
Share your thoughts if you have them.