New Siege Implementation: Siege Claims

[Potjeh]

I'm not the game's designer, all I can do is throw random shit at the wall. Actual design should be done by the game's actual designer who has the grand vision. But yes, it doesn't feel very systematic, in fact the entire development of the game (at least in the last ten years) feels very much ad hoc. Feel free to prove me wrong by posting your design document But yeah, iterative design has it's place, but it's for figuring out how rather than what. The iterations of the siege system don't really feel like they have a common thread in what they're trying to accomplish, and frankly I still have no clue at all what your actual design goals are.

[loftar]

But yes, it doesn't feel very systematic, in fact the entire development of the game (at least in the last ten years) feels very much ad hoc.

I'm not sure how you imagine that a development that "feels systematic" would actually look like, but I can't help but wonder if you don't mean one where every step is successful, quite simply. To the extent that we differ from that, that may be because of our lacking abilities, but if that is so, it kinda is what it is.

[trinh]

Please at least make full backup before implementing this I feel in bones that this will end up badly.
Alpha is alpha but I love my carrots

I see lots about attacking, how about defending?
Big ass boi comes with buffed stats and you have only certain time (<24h ) to pack things and move away?

[loftar]

I see lots about attacking, how about defending?
Big ass boi comes with buffed stats and you have only certain time (<24h ) to pack things and move away?

I don't really see any of it being much different in that regard from how it was last world.

[irongete]

What about something more realistic?
Attackers will have a way to protect his weapon, and to maintain the siege they will be required to be there for some hours (Isn't this what a siege means?) constantly attacking.
Defenders can go out and kill the attackers and destroy the weapon at any time or call for help because they have some hours even if enemies are attacking the wall.

(Math used is just to make the point, numbers may be not correctly calculated.)

Palisade has 1500 hitpoints, Brickwall 3000 hitpoints.
Wrecking Ball should be able to break a undefended wall in ~24 hours, Battlering Ram in ~12 hours.
Battlering Ram no loger breaks and can be moved freely by owners.

Walls can be repaired for 150 health every 6 hour.
Battlering Ram and Wrecking Ball mechanics:
- No need to dry or anything: build, move and start attacking.
- Has 50x50 virtual zone around it (battlefield).
- Only "owners" can use it.
- "Owner" is the person who built it or any village/party member, or players in party with a village member.
- Unatackable if any "owner" is online, alive and inside this virtual zone.
- Can only do one attack every 60 minutes.

Weapons damage:
- Battlering Ram hits for 100 damage.
- Wrecking Ball hits for 50 damage.
- Each time a siege weapon attacks: builds up a stacking +5 attack damage.
- If you move the Battlering Ram you will lose 5 attack damabe for each tile you moved. Wrecking Ball will lose all damage if dissasembled.

More thoughts:
- As someone suggested the siege weapon can be set on fire and will take damage over time so attackers should also need to pay attention to the weapon health and constantly be ready to repair it.

[Potjeh]

But yes, it doesn't feel very systematic, in fact the entire development of the game (at least in the last ten years) feels very much ad hoc.

I'm not sure how you imagine that a development that "feels systematic" would actually look like, but I can't help but wonder if you don't mean one where every step is successful, quite simply. To the extent that we differ from that, that may be because of our lacking abilities, but if that is so, it kinda is what it is.

I mean how there's nothing at all about PvP on the about page. I take it you wrote that blurb when you started making the game. The game's summary should explain all the major aspects of the game. Systematic design would be defining the core design and design priorities, and not adding anything to the core once you get into implementation because that's feature creep which is a bad thing. 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.

[loftar]

What about something more realistic?
[...]
- Has 50x50 virtual zone around it (battlefield).
- Only "owners" can use it.
- "Owner" is the person who built it or any village/party member, or players in party with a village member.
- Unatackable if any "owner" is online, alive and inside this virtual zone.

Forgive me for saying so, but that does not seem particularly "realistic" to me. I also don't see how this paradigm handles multiple wall layers.

I mean how there's nothing at all about PvP on the about page. I take it you wrote that blurb when you started making the game. The game's summary should explain all the major aspects of the game. Systematic design would be defining the core design and design priorities, and not adding anything to the core once you get into implementation because that's feature creep which is a bad thing.

To be honest, it sounds like the only real consequence of that would be that we'd have to update the design priorities every other patch to match new insights made in the process. Unless you want it to say "we want to make a game that's fun".

[loftar]

Yeah, games like go have zero replay value :roll:

Just a by the way, by the way, I'll add that the scoring rules in Go aren't exactly the epitome of obviousness and intuitiveness.

[Potjeh]

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. Still, I think every game developer would greatly benefit from developing at least one classic pre-internet era game, that is one with clear requirements and a deadline at which it needs to be a fully playable, fun and balanced game.

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

As an example here's the summary from my own design document for a project I stared recently, after reading that book. It's my first time designing a game so it's far from perfect, but you've got a lot more experience than me so you should be able to do a lot better.

1. Short Description

Guiding Spirit is a single player god game where you take care of a prehistoric tribe as it's supernatural protector. The tribespeople require food, water and protection
from elements to survive. They take care of these needs autonomously, in accordance to available resources and technology. However, as they exploit resources, the tribe
angers local spirits. Angry spirits can cause harm to the tribe via diseases, animal attacks, natural disasters etc. Hostile spirits can be evaded by moving the tribe,
appeased with sacrifices or fought. The player has indirect control over tribespeople and can instruct them via visions to move camp, perform sacrifices etc. Fighting is
done in the spirit world by manifesting a player avatar and engaging the hostile spirits with spells. Both visions and combat spells expend mana, which is
passively generated by each person in the tribe at a rate dependant on their morale. In addition to giving instructions to tribe and combat spells, mana can be expended
on buffs for the tribe and inspiring tribespeople to create new technology. The player starts with a limited selection of these abilities, and unlocks new ones by
defeating various spirits. Player skill is tested in picking a good migration path that provides plentiful resources to the tribe, avoids dangerous spirits and unlocks
useful technologies. The game is won when the tribe unlocks agriculture and no longer needs to migrate, and the game is lost if the tribe dies out.

[irongete]

I also don't see how this paradigm handles multiple wall layers.

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