"The Snowball of Nerf-Hate Effect"

[HaemishM]

Consider for a moment a completely different design, where the primary offensive strength of a siege lies not in the mass number of players involved on a particular side, but the ability to manage logistics to get the minimum effective number of npc troops (who, by the way, cannot recall or be summoned) to a siege location. Then, consider that the npc troops lost in the attack are now no longer available to respond to an counter-attack, and therefore have to be committed very carefully in offense.

Sounds good, except that NPC troops are horrible at defense. Your AI will have to be absolutely top-notch to generate a modicum of not sucking at defense. Pathing issues, training issues, kiting issues, all will need to be dealt with on the AI side, unless you expect every movement of theirs to be controlled by players. Oh and all that AI? It's going to eat up server cycles and bring that machine to a crawl.

You also add an entire new dimension that SB's summons chains (and indirectly their entirely player populated armies) destroyed: the concept of defense in depth. In SB, it was a matter of an hour tops to pretty much centralize the entire server's combat capability at a single location (more if your summons chain organization sucked, or you had a ton of non-nation guilds), and this location could be anywhere in the game world. One summons spy alt in an enemy guild and you could mobilize across the entire map at any time. Take away this instant mobilization and you have a much more strategic level to the siege game that requires good logisitics skills, as well as force management. Taking and holding territory actually means something.

Summon chains did cause problems in SB. However, they solved one huge problem... defending a base that isn't being attacked is more boring than the PVE in Shadowbane. Without the ability to get to the defense quickly, defending becomes tedium or frustration. With instancing, instead of worrying about "oops, I died, another hour run to the battle" (read: Not fun, something DAoC discovered), you instead have the layer of "My side can only die X number of times (maybe 2 per person involved) before being shut out of the battle." Add in a factor of only the two main participants in the instance being allowed to invite allies, you keep scavenger griefers out of the battle.

So what that it isn't "virtual world?" It's a fucking game, not a science project.

Also the fact (as I mentioned above) that there was no interaction with the npcs in the game world except as sources of revenue (exp or gold) gave the player base free reign do whatever they wanted. When the npc population becomes a signifigant "player" in the military and political spheres of a game, persistent effects of sieging starts to become not only viable, but required.

In order for NPC's to be a significant player, they will need to be controlled at some points by actual hired players.

[Train Wreck]

NPCs by themselves would possibly suck (though if that were the case than uber-instances would be a peice of cake).  But NPCs fighting along side players can prove to be a valueable distraction.  I guess we'll find out for sure when the Alterac Battleground is released, as all the points of contention (mines, graveyards, bases, etc) are defended by some kind of faction-based NPC boss character (captains, generals, etc).

[sinij]

Sounds good, except that NPC troops are horrible at defense. Your AI will have to be absolutely top-notch to generate a modicum of not sucking at defense.

Giving basic controls over NPCs to players would solve inadequate AI problems. Still I don’t think that beefing up NPCs in any way will make fights any more fun – it will just turn sieges it into huge PvE feast with AOEing druids. Most people play SB to PvP, I just don’t see how turning sieges into PvE will fly with what player base left there.

With instancing, instead of worrying about "oops, I died, another hour run to the battle" (read: Not fun, something DAoC discovered), you instead have the layer of "My side can only die X number of times (maybe 2 per person involved) before being shut out of the battle." Add in a factor of only the two main participants in the instance being allowed to invite allies, you keep scavenger griefers out of the battle.

My main gripe with instancing in mmorpgs is that instancing in as anti-massive as it gets. It is a crutch that should not be used in a well-designed game – if your game calls for instancing you done something fundamentally wrong, be it not enough content or not enough restrictions on how players can interact depending on type of game you are trying to design.

Now to your example as applied to SB – what would “add in a factor of only the two main participants in the instance being allowed to invite allies” achieve? You still would have zerg on zerg battles where everyone who would participate in non-instanced battle would get invited to participate. Introducing “limited lives” can be done without instancing by resurrection timers applied specifically to any death in area-of-effect of siege. About the only thing that can be done by instancing is controlling number of players allowed to participate – still how would that be of any use and who would have a control over it? How two groups of best players dominating all sieges by putting two group restriction is any different by two groups of best players dominating all sieges by brining allies and killing a lot of players? By instancing you just remove any reason for ‘elite’ players not to be reckless and give them ability to disregard politics.


I'm not convinced that instancing PvP will do any good to SB. Instancing PvP in WoW might be the only way to introduce any PvP there, but it is simply because there is no good way to do it in otherwise purely PvE game with a static conflict sides.

[HaemishM]

I'm not talking about Shadowbane, but about the mythical game Zepp is talking about.

I also give not a fuck what elite players do or don't do in an instance. They are never the majority in a game. Instancing in the sieges I'm speaking of is meant to control a number of things, including balance, the zerg, the 3 A.M. raid, etc. By two groups, I don't mean the typical 6-man groups of MMOG's, but two actual groups of combatants, whether they be 20 guys, 2 guilds, or what have you.

Also, the "massive" in MMOG's is a goddamn myth. I've talked about this before. Massive means shit. Massive is what lazy developers have used as a justification for charging subscriptions for really shitty single-player game mechanics.

[Stephen Zepp]

I'm not talking about Shadowbane, but about the mythical game Zepp is talking about.

I also give not a fuck what elite players do or don't do in an instance. They are never the majority in a game. Instancing in the sieges I'm speaking of is meant to control a number of things, including balance, the zerg, the 3 A.M. raid, etc. By two groups, I don't mean the typical 6-man groups of MMOG's, but two actual groups of combatants, whether they be 20 guys, 2 guilds, or what have you.

Also, the "massive" in MMOG's is a goddamn myth. I've talked about this before. Massive means shit. Massive is what lazy developers have used as a justification for charging subscriptions for really shitty single-player game mechanics.

I pretty much agree with everything Haemish says here, except for the fact that instancing is the way to solve the issues. I think that better game design at all levels is the better approach, and multiple levels of "balancing" when taken together would handle the various issues that he wants to encapsulate within an instance. I'm not saying his way won't work (it absolutely would), but I am saying that it can be done better.

Regarding the "NPC sieges becomes massive PvE"--the base ratio I'm looking at here is roughly 9 to 1 in participation, and roughly 5 to 1 in "power balance"--1 PC would control roughly 15 NPC's in a major siege (a basic "squad", plus the overhead players that don't actively control NPC's but instead handle things like communication, tactical coordination, etc.), and the basic ratio of 1 player being able to handle 5 or so NPC's dependent on their builds, tactics, etc.

The comment about NPC's not being able to defend ("horrible at defense") is valid when taken out of context, but when you factor in the fact that the NPC's on the attacking side are roughly equivalent in AI capability, it's a restriction on both sides, and not as unbalancing. Yes, an "army" of 30 players with no NPC's would be able to take out 150 or so NPC's from the other side based on the ratios above, but then again, the defending side is going to have those 150-ish NPCs (or more), in addition to their players.

From a different perspective, in shadowbane, the players are everything--logisitics, command, tactics, primary strike force,  and cannon fodder. When you add in the NPC element on both sides, the nature of the siege changes, in some ways dramatically--instead of being the cannon fodder for the entire siege, the players can focus on the special tactics, command/organization, as well as directly fighting.

[sinij]

I'm not talking about Shadowbane, but about the mythical game Zepp is talking about.

Sorry my bad, I read about sieges and assumed you are talking about SB.

I also give not a fuck what elite players do or don't do in an instance. They are never the majority in a game.

That is 100% true for PvE game. In PvP game this minority is what dictates how game played by majority. In UO minority of skilled players terrorized majority by PKing, dictated prices on rares and held control of nightmare spawns, in SB minority of players manipulate masses to do whatever they want and are always was that key group that can turn battle around for you. There is nothing more this minority would like to “even up the odds” to ensure complete and absolute domination and you are handing it to them.

[HaemishM]

If you want to put it that way, the minority leads the nose of the majority in PVE games too. As you get higher in level, your guild leaders/raid leaders tell you what items to go after, what big raids to take down, etc. Assholes like FOH would like to think they are the tail that wags the dog by making the non-catasses covet what they have. I only buy that argument so far. Having been a guild leader in PVE, and a guild officer in PVP, these people only have power because of really shitty game design.

If you allow sieges to go off at any time, they will go off when you least want them to. Substitute "relic raids" for sieges and you have the same problem in DAoC. This lets the ubers wag the dog, because they are the only ones sick enough or with enough time to wait until it's 3 a.m. on a worknight and no defenders are on to defend against an attack.

Long ass spawn times on big raid mobs do the same thing, because the uber catasses will have the patience to time the spawn down to the minute.

Instancing CAN solve those problems; trying to claim that instancing suddenly makes the game less massive is retarded. You still have massive amounts of players in the world, they just aren't all stepping on each other's toes at the same time. Standing in the lunch line for a dragon... that is the result of MASSIVE being more important than game. Believe it or not, most fantasy adventures do not involve a world that feels as crowded as Grand Central at 5 p.m.

Sieges taking place on instanced servers, as opposed to the "big iron" philosophy that Shadowbane took would have meant sieges with less lag, provided they could have actually made the instancing work right. If you are in a siege with 200 other players and there isn't any lag, how is that any less massive than being in a siege with the same number of people that runs like a slideshow?

[Ironwood]

Instancing CAN solve those problems; trying to claim that instancing suddenly makes the game less massive is retarded. You still have massive amounts of players in the world, they just aren't all stepping on each other's toes at the same time. Standing in the lunch line for a dragon... that is the result of MASSIVE being more important than game. Believe it or not, most fantasy adventures do not involve a world that feels as crowded as Grand Central at 5 p.m.

Why, why, why aren't you taking one of those Blizzard positions ?  Give us some hope for the future.

[Train Wreck]

My only question regarding instanced seiges is, how would it fit into the over all game world?  If a city is captured in one instance but defended in another, how does that translate into the main world?  I see instances as being an ideal solution to dungeons, but it runs into problems outside of that.

[HaemishM]

It's still a part of the world. One city is only instanced one time, though there are ways you could do the siege with multiple instances, where an aggregate of results makes the main result. If you are a member of the guild/faction/whatever that owns the city, you are allowed into the instance, and if you are a member of the attacking faction/guild/whatever, you are allowed in, up until the balance number is reached. The siege is scheduled, something like Shadowbane's TOL sieges were scheduled, except with less jiggle room; you'd more than likely have to make the siege timer analyze the peak play times of the defender's to make sure the attacker doesn't set it for a time when none of the defenders are ever on. Battle time comes, everyone gathers in the instance. If you are in another part of the world when battle time comes, you are given the chance to teleport back, if you decline, you have to make it back there on your own if you wish to join later.

Defenders and attackers can invite allies into the battle; but they count against the total balance number. Let's say 200 people is the most people you could reasonably assume your game could support in an instance without gameplay turning to absolute shit. That's your total number of combatants, split evenly, or through some forumla based on level or class. If you have a level game, sidekick everyone up to the highest level in the instance (much like COH does... you don't get new skills, but you do perform as if you were the higher level with current skillsets). Each side is given a maximum number of deaths. Let's say you have a total of 30 players on your side... your side can die a total of 60 times. To keep griefer spies from suiciding to attrite one side, one player can only die say 3-5 times. Once your side exhausts their death limit, or an individual dies more than 3-5 times, that's it. You are shot out of the instance and not allowed to respawn. You may respawn in an observer mode only, but you can only observe as if you were in the body of another player on your side, and can chat only with those other dead in the instance.

If the defender loses all its respawns, the attacker is given free reign in the instance to loot the city, burn it down, or just loot it and leave it standing.

Yes, you could have NPC guards in this, much like Zepp's idea of each player being given control over a phalanx of guards. What you wouldn't have is scavenger/griefers, or assholes that just like to run in and ruin the fun. Are there holes in it? Yep, I can guarantee you there are. But think about it like this... in a world where the siege was the equivalent of the nuclear weapon, you wouldn't have every Tom, Dick and Harry coming around it. They'd stay far away from it for fear of getting caught in the crossfire. There were also many "rules" of etiquette that gamers WILL NEVER FOLLOW WILLINGLY.

[Train Wreck]

Those are good ideas, and I have yet to hear a better way to run seiges.  By "instancing", I had it in my mind that it was running several copies of the same thing, but only having one instance makes a lot of sense.  I wonder if that's the way WoW is doing battlegrounds?  The way you enter the battlefield is through a red portal, and it is limited to 100 or 200 -- I don't remember which figure is correct -- players on each side.

I don't think it's on a timer, though, and I have no idea how they are going to decide when a player is done and it's time to let in the next person in the queue.  Ideally, anybody would be able to play as long as they want, and have a minimum of waiting time to join in.

[Stephen Zepp]

Haemish:

Two things that you mention that really would bother me with "instanced" sieges in how you've fleshed the idea out:

1) The concept of "balance". On the one hand, you mention that the instance's number of participants should be limited due to game constraints--lag, etc. My point here still remains that the problems with siege lag is do to the innate design flaws of allowing so many update receipients (players) in such a small geographical location--due to no collision of players. You don't need instancing to fix this--what you need is to fix the fact that players run through each other. The added overhead from an (optimized) collision mechanism, as well as the pathfinding algorithm needed is not nearly as bad as the sheer mass of updates that have to be broadcast when so many clients are in the same localized area. You also reduce the huge client rendering load of all those particle effects, high poly models, spells, combat events, and even just the number of total objects in your execution loops when you limit the number of "clients close by". Additionally, a dynamic resource load balancing mechanism (recognize that there is a large amount of players/troops in a geographic region, swap handling to a different game "server/platform/cpu") is critical as well.

On the other hand, you talk about "power balancing"--and this one really bothers me. How do you set the metrics for what is "balanced" and what isn't? Sheer numbers? Total levels? Some calculated "siege offensive/defensive power" rating? By the nature of a siege (with a good siege mechanic of course), the attackers have to have a power advantage--anywhere from 3:1 to 10:1 depending on the defensive terrain, city configuration, etc) to even have a chance of success (note: SB is again a very poor example here, city walls and such were detriments to defense, not bonuses as they should be). You also have to factor in the relative merits of a player's levels, abilities, and character templates--does an aoe druid have a "siege offensive force multiplier" against a warrior for example?

Even assuming that you have algorithms that can handle all of the "balancing" to give you roughly balanced forces on each side--what's the limiting factor? Do you say, "the defenders are a new city, so they only have a maxSiegeDefenseRating of 75, so the attackers can only have the same? What if the "defenders" are a grief city placed right in the middle of the most powerful guild on the server's "home territory", and only have a maxSiegeDefenseRating of 2--does that mean the "attacking" guild can only send a maxSiegeOffensiveRating of 2 as well?

2) Trying to "schedule" sieges: Again, I think the fundamental "need" to force scheduled sieges to avoid ninja-raids, etc. is a game design flaw--currently, it's too "easy" to perform a ninja siege: a small group of players (in the two games mentioned) can decide on a whim to go ninja-raid, and be effective simply because there are no defenders logged on. And the problem with that is, they can accomplish a HUGE amount of offensive damage with even a very small force, with extremely low planning/logisitics.

Instead, if you were to remove the two design flaws (immediate mobilization, and completely out of control offensive capability with a very small force), you'd limit the effectiveness of unscheduled raids. If it takes time to not only move an offensive force to the attack point, as well as control the offensive force's capabilities with small strike teams, you remove a large portion of the concerns.

Yes, the attackers could still set things up logistically for the main fight to happen when the defenders have the least amount of players logged in, but, the defenders now have the opportunity to discover, locate, and attack the mobilizing forces before they would arrive at the siege location itself. Of course, this is dependent on the fact that in my design, the large majority of the "offensive power" resides in the number and quality of the NPC forces--we don't want to make players spend 3 days of active, online time moving each and every squad of troops to the attack point. You can however make this task largely automated if the attackers wish, and that would take only a few "babysitters" to manage the rally and mobilization until the attack kicks off. To sum it up: yes, the attackers could coordinate the mobilization to intend a "ninja siege", but the defenders could also "counter-ninja attack" during the mobilization to at least reduce the attack force, if not negate the ability for the attackers to ninja-siege with any real offensive power.

Request to Mods: This is turning into an excellent thread, but it's a huge hijack. Any chance of splitting off the appropriate siege messages into their own topic in the Game Design forum? :)

[sinij]

Instancing CAN solve those problems; trying to claim that instancing suddenly makes the game less massive is retarded. You still have massive amounts of players in the world, they just aren't all stepping on each other's toes at the same time. Standing in the lunch line for a dragon... that is the result of MASSIVE being more important than game. Believe it or not, most fantasy adventures do not involve a world that feels as crowded as Grand Central at 5 p.m.

We must agree to disagree in this case. I still strongly believe instancing can and should be avoided in PvP games. Every time you mention why would you use instance I can point significant design flaw that lead to behavior you trying to eliminate with instancing. If you don’t want players to do something during off-hours simply prevent it. As applied to sieges example, if you don’t like 3am sieges create window of opportunity for all sieges that you think is reasonable.

Instancing limits maximum potential of any experience in a game only to raise minimal expectations that you can improve by improving your design. For example during instanced sieges you won’t have 3am raids or attackers taking over by shear numbers but you also won’t have unexpected reinforcements and counter attacks.

To me Instancing is a strive for mediocrity.

[MrHat]

Instancing CAN solve those problems; trying to claim that instancing suddenly makes the game less massive is retarded. You still have massive amounts of players in the world, they just aren't all stepping on each other's toes at the same time. Standing in the lunch line for a dragon... that is the result of MASSIVE being more important than game. Believe it or not, most fantasy adventures do not involve a world that feels as crowded as Grand Central at 5 p.m.

We must agree to disagree in this case. I still strongly believe instancing can and should be avoided in PvP games. Every time you mention why would you use instance I can point significant design flaw that lead to behavior you trying to eliminate with instancing. If you don’t want players to do something during off-hours simply prevent it. As applied to sieges example, if you don’t like 3am sieges create window of opportunity for all sieges that you think is reasonable.

Instancing limits maximum potential of any experience in a game only to raise minimal expectations that you can improve by improving your design. For example during instanced sieges you won’t have 3am raids or attackers taking over by shear numbers but you also won’t have unexpected reinforcements and counter attacks.

To me Instancing is a strive for mediocrity.

I'm with you Sinij on this.  I wish there weren't any instances at all. 

However, I understand that they are the evolution of the industry.  Demands on hardware have not met up with the innovation on that side.  By instancing, it still allows us to have games that lots of people can play at once, but with out the crippling hardware problems.

[Stephen Zepp]

I'm with you Sinij on this.  I wish there weren't any instances at all. 

However, I understand that they are the evolution of the industry.  Demands on hardware have not met up with the innovation on that side.  By instancing, it still allows us to have games that lots of people can play at once, but with out the crippling hardware problems.

In my opinion, you need to carefully define what you mean by instances when making broad statements like this (not a flame, just an observation!). There are lots of alternate solutions that fix the hardware performance issues that could be loosely defined as "instancing", but do not have many of the connotations of the term "instancing" that are starting to become the norm definition.

For example, what you are really talking about in this specific quote is load balancing. It is very possible (Asheron's Call, or maybe AC2) to do dynamic load balancing of action locii (made up on the fly term for "world areas that have lots of things going on at once in a small-ish area") without any of the "only certain numbers of players can be in this zone/encounter at once", "forces within this zone that are pvp are "balanced", "this is multiple copies of the same exact content replicated" type connotations that "instancing" gives.

Sorry to be pedantic, but a lot of ideas are being grouped under the term "instancing" that are really unrelated.

[MrHat]

If by load balancing you mean:

1) The concept of "balance". On the one hand, you mention that the instance's number of participants should be limited due to game constraints--lag, etc. My point here still remains that the problems with siege lag is do to the innate design flaws of allowing so many update receipients (players) in such a small geographical location--due to no collision of players. You don't need instancing to fix this--what you need is to fix the fact that players run through each other. The added overhead from an (optimized) collision mechanism, as well as the pathfinding algorithm needed is not nearly as bad as the sheer mass of updates that have to be broadcast when so many clients are in the same localized area. You also reduce the huge client rendering load of all those particle effects, high poly models, spells, combat events, and even just the number of total objects in your execution loops when you limit the number of "clients close by". Additionally, a dynamic resource load balancing mechanism (recognize that there is a large amount of players/troops in a geographic region, swap handling to a different game "server/platform/cpu") is critical as well.

I love that idea. I really do.  But it makes me wonder why devs start 'instances' which limit the amount of people in a certain geographical location over several shards or instances (I'm thinking CoH when I say this).  I have a feeling that they use the instance method because it's easier to code and takes less money to implement.  This is the reason we'll continue to see that method.  Until a brave dev house comes along and properly (not fuck up) your method, it will never happen.

[Stephen Zepp]

Honestly, I think it's due to the fact that "most games do it this way, so the customers must not mind", combined with the fact that there really isn't any way to do everything that needs to be done without resorting to tried and true technology.

Building dynamic load balancing and server farm resource allocation isn't a trivial task at all. "Ethereal" players does handle some other issues as well (grief blocking, etc), so IMO MMOG dev's are just sticking with it. Optimizing collision, and especially the pathfinding algorithms that are needed when players can no longer be walked through is quite a big issue as well.

Personally, since the largest majority of our NPC's are squad based, we can use fat-path pathfinding combined with flocking algorithms to minimize our performance requirements for pathfinding, but it's still a huge issue.

[HaemishM]

Haemish:

Two things that you mention that really would bother me with "instanced" sieges in how you've fleshed the idea out:

1) The concept of "balance". On the one hand, you mention that the instance's number of participants should be limited due to game constraints--lag, etc. My point here still remains that the problems with siege lag is do to the innate design flaws of allowing so many update receipients (players) in such a small geographical location--due to no collision of players. You don't need instancing to fix this--what you need is to fix the fact that players run through each other. The added overhead from an (optimized) collision mechanism, as well as the pathfinding algorithm needed is not nearly as bad as the sheer mass of updates that have to be broadcast when so many clients are in the same localized area. You also reduce the huge client rendering load of all those particle effects, high poly models, spells, combat events, and even just the number of total objects in your execution loops when you limit the number of "clients close by". Additionally, a dynamic resource load balancing mechanism (recognize that there is a large amount of players/troops in a geographic region, swap handling to a different game "server/platform/cpu") is critical as well.

I'm going to have to call you crazy on this one. At the very least, hopelessly optimistic. Every game released, including EQ and newer, though less system-heavy clients like WoW, have problems drawing 200 people onscreen. That's the client side. Even if you aim for WoW-level graphics (or something less heavy like DAoC's first graphic engine), you still have the problem of clients just not being able to render all that shit effectively. You end up having to do things like lower polys on far away objects (which never works right or very effectively) or you have to limit how many objects/players the individual client can see, like WWII Online. Neither is a very good solution. With the way the industry treats "System Requirements" listings, you can fully expect half or more of your users to be on sub-optimal hardware. And that's just on the client side.

On the server side, even with the growing acceptance of broadband users, server hardware and software really isn't proving itself up to the task. Especially not in cases where the server cluster is trying to handle the whole world AND this gigantic cluster fuck of people in one spot. Collision detection will make that a bazillion times worse. Instancing is about the only way to handle it gracefully with current technology. You can talk about dynamic load balancing and optimized code all you want, but it ain't going to pay the bills. Also, given the crappy state of beta tests, it won't get tested enough to handle release.

On the other hand, you talk about "power balancing"--and this one really bothers me. How do you set the metrics for what is "balanced" and what isn't? Sheer numbers? Total levels? Some calculated "siege offensive/defensive power" rating? By the nature of a siege (with a good siege mechanic of course), the attackers have to have a power advantage--anywhere from 3:1 to 10:1 depending on the defensive terrain, city configuration, etc) to even have a chance of success (note: SB is again a very poor example here, city walls and such were detriments to defense, not bonuses as they should be). You also have to factor in the relative merits of a player's levels, abilities, and character templates--does an aoe druid have a "siege offensive force multiplier" against a warrior for example?

You figure out as a designer what your metrics for balance will be and go with it. Tweak as necessary. The sidekicking should help that, if you are dead set on level-based gameplay. The attackers COULD have a numerical advantage, based on the "level" of the city's defenses, etc. A lot of it would be determined by what constitutes a successful city or guild.

2) Trying to "schedule" sieges: Again, I think the fundamental "need" to force scheduled sieges to avoid ninja-raids, etc. is a game design flaw--currently, it's too "easy" to perform a ninja siege: a small group of players (in the two games mentioned) can decide on a whim to go ninja-raid, and be effective simply because there are no defenders logged on. And the problem with that is, they can accomplish a HUGE amount of offensive damage with even a very small force, with extremely low planning/logisitics.

The reason ninja raids are so effective isn't a game design flaw; it's the most effective use of strategy. Strategy dictates that the most effective attack is one in which there is no defense. An organized attacker (i.e. the catass hardcore cocksuckers who have been the target metric for game design in every MMOG), WILL do everything in his power to make sure he can attack when there are the fewest available defenders. If there IS a way for someone to pull off a ninja raid, whether it be through superior use of logistics, THEY WILL. Remember the law of MMOG fucktardery: If it goes to 11, no MMOG player will long be satisfied leaving it at 10. Shadowbane though they had the no-ninja raid thing licked with their siege timers. It didn't work. If all it takes is logistics to pull of a ninja raid, it will be pulled off as often as possible.

Instead, if you were to remove the two design flaws (immediate mobilization, and completely out of control offensive capability with a very small force), you'd limit the effectiveness of unscheduled raids. If it takes time to not only move an offensive force to the attack point, as well as control the offensive force's capabilities with small strike teams, you remove a large portion of the concerns.

Yes, the attackers could still set things up logistically for the main fight to happen when the defenders have the least amount of players logged in, but, the defenders now have the opportunity to discover, locate, and attack the mobilizing forces before they would arrive at the siege location itself. Of course, this is dependent on the fact that in my design, the large majority of the "offensive power" resides in the number and quality of the NPC forces--we don't want to make players spend 3 days of active, online time moving each and every squad of troops to the attack point. You can however make this task largely automated if the attackers wish, and that would take only a few "babysitters" to manage the rally and mobilization until the attack kicks off. To sum it up: yes, the attackers could coordinate the mobilization to intend a "ninja siege", but the defenders could also "counter-ninja attack" during the mobilization to at least reduce the attack force, if not negate the ability for the attackers to ninja-siege with any real offensive power.

Good theory, reminds me of dragging trebuchets 3/4 of the way around the world in Shadowbane for 2 hours only to be killed in 2 minutes. No thanks, I'd rather actually have a fight than spend most of my night just getting to the fight. No need to move this thread, it's got as much to do with WoW and their upcoming PVP battlegrounds as it does with anything else.

Instancing is not a panacea; see EQ2 for an example of it used BADLY. It IS a way to mitigate a lot of the problems with hardware/software performance.

EDIT: I've also talked about this before.

[WayAbvPar]

Good theory, reminds me of dragging trebuchets 3/4 of the way around the world in Shadowbane for 2 hours only to be killed in 2 minutes. No thanks, I'd rather actually have a fight than spend most of my night just getting to the fight.

Haemish (leading the raid)- "ok everyone, listen up"
Haemish's computer- sb.exe
Rest of guild- ".."
Haemish (offline, waiting at log in screen)- "(fill in any 12 vulgarities of your choice)"
Rest of guild- /twiddles thumbs

Yeah, that pretty much sucked a bunch of ass.

[Evangolis]

First reply on Devs and Feedback:

I'm reading an excellent book on game design by Richard Rouse, which I'll review when I finish it sometime next week.  I'm persuaded to his view that devs need to look at player feedback, as well as all the other feedback they get, but they also need to filter it.  That is part of the job, and a vital one.

[Evangolis]

Good theory, reminds me of dragging trebuchets 3/4 of the way around the world in Shadowbane for 2 hours only to be killed in 2 minutes. No thanks, I'd rather actually have a fight than spend most of my night just getting to the fight.

Haemish (leading the raid)- "ok everyone, listen up"
Haemish's computer- sb.exe
Rest of guild- ".."
Haemish (offline, waiting at log in screen)- "(fill in any 12 vulgarities of your choice)"
Rest of guild- /twiddles thumbs

Yeah, that pretty much sucked a bunch of ass.

Pretty accurate, that.  We used to assign two leaders in every attack group so that when one crashed the other could take over until the first could log back in.  Redundant command.

[HaemishM]

I think before I finally quit SB, we had to do that as well. Partly because of the rampant sb.exe problems, and partly because I wasn't going to be leading a raid at 3 a.m. or leading a defense then either.

[Evangolis]

2nd reply on instancing:

The place where instancing is a good solution is in the PvE Dungeon Crawl, because it frees you from the immersion breaking presence of other players.  Even if they do nothing directly obnoxious, the very existance of other players in the deep and mysterious dungeon in the distant shadowy mountians just breaks the feel.  Massive can be good in towns (except that lag sucks, but I digress), on the trails, or in the big battles, but when you are in small group content, the immersion is broken by passers-by.

[Evangolis]

Reply 3 on SB Sieges:  (Sorry about the multi post format, but I'm finding the multiple discussions in this thread a bit confusing)

While I don't gainsay the points made, there have been some changes.  (Yeah, I've been playing SB again.  I touch myself in the bad place, too, sometimes.)  Siege spires can make walls work better.  Resource fights provide an open GvG fight that results in the multi-sided daily GvG action that the game meant to get, although this is in part a gentleman's agreement not to zerg.  And siege scheduling does stop the ninja siege, although the current state of SB subscribership means that you have people from around the world in the same alliance, which means it is always 3AM somewhere.

But there always seems to be another bug, and the best way to beat the opponent is still to make them stop playing.

On the other hand, once EA buys Ubisoft, we won't have SB to kick around anymore.

[MrHat]

On the other hand, once EA buys Ubisoft, we won't have SB to kick around anymore.

Shadowbane The Burbs: ToL Your Neighboor!

[Evangolis]

4th reply on PvP and death penalties:

Increase the rewards for winning, not the penalties for dying.  Never put more negatives into the players' experience.  You can't make people behave, but you might help them have fun.

However, rewards should be transitive, to avoid positive feedback loops, since these are certain doom for your game.

[Evangolis]

5th (and final) reply on sieges and instancing:

I think the problem is not just in the lack of collision detection and such, but also in Haemish's point about client overload.  As a healer in SB fights, I just target myself, and spam group heals when they refresh.  I don't even try to act offensively until the first wave of death clears up the frame rate.  But those aren't the only problems.

The very concept of the mass battle is rather an issue.  It looks great, and the idea seems great, but I think the payoff is not worth the effort.  You work for literally hours to engineer the big fight, and it ends in seconds to minutes.  That isn't a good return on investment.

We look to Shadowbane for examples, because, despite its manifold flaws, SB still came closer to meaningful and entertaining team PvP than anything else in the MMO space so far.  The example I would hold up from SB is what I call The Scout Battle.

The Scout Battle was what preceeded most large battles in beta and early release.  In groups and solo, scouts would go out, probing for hostile concentrations and trying to drive off opposing scouts.  It tended to be a large area, fast moving fight, with more evasion than combat.  And it could run for hours.

I think we need mechanics that develop widespread battles of this sort, rather than the Braveheart lagfests that we all know.  I don't know what mechanic can counter the obvious tactical value of concentration of force without an invasive system like instancing, but I think that this would be the best solution for fun large scale combat.

[Shockeye]

We look to Shadowbane for examples, because, despite its manifold flaws, SB still came closer to meaningful and entertaining team PvP than anything else in the MMO space so far.  The example I would hold up from SB is what I call The Scout Battle.

The Scout Battle was what preceeded most large battles in beta and early release.  In groups and solo, scouts would go out, probing for hostile concentrations and trying to drive off opposing scouts.  It tended to be a large area, fast moving fight, with more evasion than combat.  And it could run for hours.

Which is why I enjoyed playing a Scout. I was able to check the enemy lines and report back what was going on. A few good scouts could ensure proper placement of troops for coming battles. While I enjoyed laying down some smack as a Prelate, my first choice was always to play my Scout.

[WayAbvPar]

I was in the Scout brigade, but as a Thief. Among my most favorite memories of any game was relaying actual useful information back to Haemish and Cevik (where the hell did he get off to, anyway) during manuevers. SB was deeply flawed, but they got a lot of stuff right. Or very damned close to right.

Funniest moment- following a group of ne'er-do'wells near one of our sister cities, and relaying positional info to a squad of folks assembled to chase them off/kill them. The opposing group stopped for a rest just barely within sight of the city walls behind some trees. I took their immobility as an opportunity, and I stealthed in, stole the only siege hammer they had on them, and proceeded to lead them on a merry chase- straight into my companions. They tried to run, but it was just too late. I could hardly fight due to my guffaws.

[HaemishM]

I remember that night. It was freaking hilarious.

[Hoax]

On Instancing:

Haemish believes that mmog's should just stop trying to reinvent the wheel and instead just add one playing card to the spokes of the one they have and call it a day.  I can't be that cynical, yet, I'm getting there but damn it there has to be somebody who can be original and implement their original ideas without them coming out smelling like donkey ass 

I see instancing to be down the same vein, the idea of "massive" is not some hoax.  The world means more when its not instanced.  People who complain that GW is not a mmog, aren't saying that because the grind is too short.  They say that because everything is instanced (thats my take from who I have talked to about it, obviously).

You break the world apart into shiny portals that lead to your own little secret areas that nobody else can disturb and I ask why can't they just release a FF game you can play with 3 friends online and call it a day?  You destroy the world with instances..  If its just a band aid fix while technology on client and server sides catches up I'm ok with that, but acting like its an improvement to trying to keep everyone in the same "world" just doesn't sit well with me.

At its core the idea of Shadowbane's siege-centric gameplay was perfect.

There are several problems w/ the open world sieges:
1) How do you make zerging not the most effective tactic?
2) How do you spread the battlefield out so that you dont just lag to shit and make it stupid
3) How does one prevent "the winners win more and the losers quit" syndrome?

I dont have the answers there right now, or possibly at all.  But just because somebody has not thought of them yet doesn't mean that everyone should stop fucking trying to make a great game and instead just advance mediocrity one more iota.

 

[Evangolis]

I don't agree that instancing always equals mediocrity.  The object of these games is to produce an entertaining experience for the player, and I think that when you are dealing with content aimed at small groups, it is wholly appropriate to restrict that content to small groups.

As to the zerg, I think it was Napolean who observed that God is generally on the side with the big battalions.  Numbers matter, and probably should matter.  I see two offsets for this.  One is to create bottleneckable terrain, where a few can hold off many.  The other is to reduce the signifigance of what you are fighting for.  The reason SB sieges tend toward the zerg and the appearance of two sides (followed by one side and then no sides) is that they matter too much.  Losing your city sucks too badly not to ally with your worst rival and bring the server crashing down to nothingness.  The more something matters, the quicker players will employ degenerate strategies to gain that something.  It is worth noting that resource mine fights, which are much less rewarding events, see much lower levels of alliance and zerging.

As to spreading the battle, one option would be to move the effective range for combat for all classes.  Eliminate melee.  I've heard SWG castigated for non-fun ranged combat, but I know that SB combat with bow scouts could be fun.  Modern military formations try to spread out, to compensate for the power of modern weapons.  There might be lessons from Planetside here, but I don't know.

One prevents the winners gain issue by avoiding positive feedback loops and limiting the impact of PvP long term.  This also means that you have to let people play without forcing them into PvP, or the 'Kill them till they don't logon anymore' strategy will dominate, regardless of the consequences of PvP.  Many advocates of PvP hate the idea, but in a persistant game, PvP has to be a basically optional, recreational and symbolic affair, or it will result in one side taking their ball and going home.  I saw the Lesson of Trammel again in SB a couple of weeks back, as I heard people standing in a safehold deriding 'carebears' in /nation chat.  You could have made a good sword out of irony of that quality.

[Stephen Zepp]

Haemish:

Two things that you mention that really would bother me with "instanced" sieges in how you've fleshed the idea out:

1) The concept of "balance". On the one hand, you mention that the instance's number of participants should be limited due to game constraints--lag, etc. My point here still remains that the problems with siege lag is do to the innate design flaws of allowing so many update receipients (players) in such a small geographical location--due to no collision of players. You don't need instancing to fix this--what you need is to fix the fact that players run through each other. The added overhead from an (optimized) collision mechanism, as well as the pathfinding algorithm needed is not nearly as bad as the sheer mass of updates that have to be broadcast when so many clients are in the same localized area. You also reduce the huge client rendering load of all those particle effects, high poly models, spells, combat events, and even just the number of total objects in your execution loops when you limit the number of "clients close by". Additionally, a dynamic resource load balancing mechanism (recognize that there is a large amount of players/troops in a geographic region, swap handling to a different game "server/platform/cpu") is critical as well.

I'm going to have to call you crazy on this one. At the very least, hopelessly optimistic. Every game released, including EQ and newer, though less system-heavy clients like WoW, have problems drawing 200 people onscreen. That's the client side. Even if you aim for WoW-level graphics (or something less heavy like DAoC's first graphic engine), you still have the problem of clients just not being able to render all that shit effectively. You end up having to do things like lower polys on far away objects (which never works right or very effectively) or you have to limit how many objects/players the individual client can see, like WWII Online. Neither is a very good solution. With the way the industry treats "System Requirements" listings, you can fully expect half or more of your users to be on sub-optimal hardware. And that's just on the client side.

On the server side, even with the growing acceptance of broadband users, server hardware and software really isn't proving itself up to the task. Especially not in cases where the server cluster is trying to handle the whole world AND this gigantic cluster fuck of people in one spot. Collision detection will make that a bazillion times worse. Instancing is about the only way to handle it gracefully with current technology. You can talk about dynamic load balancing and optimized code all you want, but it ain't going to pay the bills. Also, given the crappy state of beta tests, it won't get tested enough to handle release.

/boggle. We regularly have 100 on 100 open field fights with our npc troops, with ai controlled attacking, including basic particle effects with 60+ fps on a good gaming machine. That is with average 800 poly models, NO Level of Detail versions of the models, basic network optimization (this is over the internet against a decently powered desktop acting as a dedicated server, T-1 line only access), plus full terrain rendering. Oh, and that's all without shaders, so no offload of work to the GPU.

At full zoom out of our current camera position, yes, you can overload the client's machine by having 500+ units on screen at once, but again, we have no level of detail models currently, so you are rendering in excess of 400,000 polys all in motion. With the avatar 1st/3rd person camera, the field of view is drastically reduced (down at the fight instead of god view), and with proper distance culling and level of detail assignment, it's not a serious performance issue on computers that can be purchased today.

The latest performance/rendering tests were performed prior to the collision work (that's our current milestone actually), so of course there will be some additional performance loss due to that, but we're not talking masterful collision here either, just simple bounding boxes.

2) Trying to "schedule" sieges: Again, I think the fundamental "need" to force scheduled sieges to avoid ninja-raids, etc. is a game design flaw--currently, it's too "easy" to perform a ninja siege: a small group of players (in the two games mentioned) can decide on a whim to go ninja-raid, and be effective simply because there are no defenders logged on. And the problem with that is, they can accomplish a HUGE amount of offensive damage with even a very small force, with extremely low planning/logisitics.

The reason ninja raids are so effective isn't a game design flaw; it's the most effective use of strategy. Strategy dictates that the most effective attack is one in which there is no defense. An organized attacker (i.e. the catass hardcore cocksuckers who have been the target metric for game design in every MMOG), WILL do everything in his power to make sure he can attack when there are the fewest available defenders. If there IS a way for someone to pull off a ninja raid, whether it be through superior use of logistics, THEY WILL. Remember the law of MMOG fucktardery: If it goes to 11, no MMOG player will long be satisfied leaving it at 10. Shadowbane though they had the no-ninja raid thing licked with their siege timers. It didn't work. If all it takes is logistics to pull of a ninja raid, it will be pulled off as often as possible.

I didn't say use of ninja sieges was a design flaw, I said the effectiveness of ninja sieges was a design flaw. The fact that 10 players can attack a city in the middle of the night with literally 5 minutes prep time, and maybe 15 minutes to run there (and that's only if they don't have a summoner spy in the target guild, or nearby), and then proceed to completely destroy the entire set of city walls in under a few hours is ludicrous.

Instead, if you were to remove the two design flaws (immediate mobilization, and completely out of control offensive capability with a very small force), you'd limit the effectiveness of unscheduled raids. If it takes time to not only move an offensive force to the attack point, as well as control the offensive force's capabilities with small strike teams, you remove a large portion of the concerns.

Yes, the attackers could still set things up logistically for the main fight to happen when the defenders have the least amount of players logged in, but, the defenders now have the opportunity to discover, locate, and attack the mobilizing forces before they would arrive at the siege location itself. Of course, this is dependent on the fact that in my design, the large majority of the "offensive power" resides in the number and quality of the NPC forces--we don't want to make players spend 3 days of active, online time moving each and every squad of troops to the attack point. You can however make this task largely automated if the attackers wish, and that would take only a few "babysitters" to manage the rally and mobilization until the attack kicks off. To sum it up: yes, the attackers could coordinate the mobilization to intend a "ninja siege", but the defenders could also "counter-ninja attack" during the mobilization to at least reduce the attack force, if not negate the ability for the attackers to ninja-siege with any real offensive power.

Good theory, reminds me of dragging trebuchets 3/4 of the way around the world in Shadowbane for 2 hours only to be killed in 2 minutes. No thanks, I'd rather actually have a fight than spend most of my night just getting to the fight. No need to move this thread, it's got as much to do with WoW and their upcoming PVP battlegrounds as it does with anything else.

In pre-release shadowbane, (I didn't participate, so this is from what I've been told) siege weapons were individually controlled, one per player. To move any attacking force, you needed dozens of players, if not more, all actively controlling them constantly. What I said is that if you design the need for mobilization properly, a couple of players tops could manage the mobilization over a long period of time, including swapping off the "babysitting" as appropriate. Instead of setting a bane and then having 2 days+ to wait for anything to happen, you instead begin mobilization of attack forces at that point, converging on the attack site after the mobilization period. All this time, the npc forces are in game and therefore can be attacked prior to centralization, as well as defended. All without the need for 5 groups of players to manually move the attack force for any lengthy period of time.

Instancing is not a panacea; see EQ2 for an example of it used BADLY. It IS a way to mitigate a lot of the problems with hardware/software performance.

I agree with you--it is a way. I happen to disagree however that it is the only way, and especially not the best way.

EDIT: I've also talked about this before.

Yes, you have...I actually read it when I first got here, and replied then--the conversation just never took off!

[WindupAtheist]

Also, Zepp's game has negative ping code.  So there.   

[schild]

Also, Zepp's game has negative ping code.  So there.   

That's entirely unnecessary.