f13.net

Put diminishing returns on Power Word: Shield. You only need one shield to kill someone dead anyway don't you?

This conversation is retarded. No SNARE in the game has diminishing returns, only TOTAL movement stoppers do. Comparing Frost Shock to fear/polymorph/etc is ridiculous -- those things take you out of the fight entirely, Frost Shock means that you move at half rate unless you're intelligent enough to drink a potion, in which case all it did was really mana inefficient damage.

As a Mage, I can keep you slowed forever while doing damage, and I can cast it twice every five seconds instead of once, meaning I do 1000 damage where Frost Shock did 500, and you still have absolutely no chance of escaping it. Everyone complains about how Shaman crush Warriors and Rogues due to Frost Shock... well Mages crush Warriors and Rogues even more thoroughly, often without getting hit as well. Yet the complaints are about Shaman, because of something called "The Snowball of Nerf-Hate Effect" as I like to call it.

We have a subset of posters on these forums that are "nerf posters." People are mistaken as to why they do it though, I think. They don't come here necessarily because they suck, or they got owned, or anything else (though all those things can lead to one becoming a "nerf poster".) No, they want to feel like they have some sort of control over the game's evolution, to feel "good" about themselves -- these people often have very little real power over their actual lives, often being teenagers.

So they arrive at the forum and need to think of something to #@%$! about in hopes of getting changed, and thus feeling powerful. Some try to go it alone, #@%$! about some isolated topic and get smacked down -- these folks have little chance of success in their goal, and thus you don't hear a lot from them.

Others, however, realize that by attaching themselves to slightly more popular nerf complaints, they can weasle in and get others actually agreeing with them. For some reason, these people feel that if a LOT of posters #@%$! about something, it WILL get changed, and thus THEIR complaint got changed, surely because THEY complained. Thus, no matter why it might have actually gotten changed if it did, they felt powerful and intelligent (Oh, I SAW the imbalance, and campaigned for it).

Because of this second type of nerf poster, certain complaints snowball into much larger matters than they logically should be. Paladins was an example, and a good one. People whined and whined about healing + shield making Paladins too powerful. They complained pages upon pages. Then, a bug got fixed that was TOTALLY unrelated to the vast majority of the complaints... but then the complaints about healing + shielding virtually stopped. Why? Because these delusional posters felt they had "won by association," got their illusionary power trip, and went to something else. It doesn't matter that none of their complaints were actually addressed, the bug fix fell into the general topic of them enough to FEEL like they had caused it.

Frost Shock is just another of these snowball whines, same with Purge to a lesser extent (which is why it's usually Purge being whined about instead of Dispel, which is better in every way). It doesn't matter that these things aren't imbalanced, or that other instances of the "logical problem" people cite pertaining to them exist in the game. All they care about is snowballing their complaints in hopes that SOMETHING will get changed, regardless of why. When that happens, they'll feel special again and move on to another whine.

They could post tomorrow that Shaman's Lightning Shield was deemed overpowerful and thus removed, and 80% of the nerf complaints would stop. It's not about Frost Shock in actuality, it's about these people feeling good about their pathetic selves. Any change would appease them. So take heart, I'm sure sooner or later a bug that is in some remote way beneficial to Shaman will be discovered in the Shaman class, fixed, and then the #@%$!ing will end for a while as these losers turn their attentions to Priests, Rogues, or whoever else they think they can get away with.

Until then, don't let it fool you into thinking your class actually IS problematic; it's finely polished and just fine as it is in every respect. You don't need to make "concession posts" in which you say things like the above; it's not necessary, and doesn't fix balance issues, as they don't exist. Frost Shock being changed from 8 seconds to 4 seconds wouldn't substantially alter any of your fighting styles, Purge costing a bit more mana and removing less effects would lead to it being spammed a little bit more to clear all the effects, nothing else. These aren't imbalances, they aren't issues, and don't let yourself be fooled into thinking they are.

That was a lot longer than I intended. I was just planning on rebutting the dumb Priest, but the general class of people pathetic creatures like her belong to coing to mind forced me into a righteous frenzy. Don't blame me, blame the vermin for being so detestable.

We all hated cr runs (especially at the raid level) in EQ, and all the death penalties that have been used by various games over the years, but one of the things that Raph (again, if it was he) pointed out is that there is a long term downside to minimal/nonexistent death penalties: when there is no perceived risk, players will do anything and everything. A perfect example (of this example) is the complaints about territorial control on PvP servers I've read here in WoW: it really doesn't matter what you do, if a player wants to keep coming back after they die, they can, and do. "Griefers", PvP defenders (in the case of territorial/spawn control), and pretty much anyone else can simply keep on coming back regardless of what happens, making the end of the conflict simply whomever gives up first, or runs out of time.

This cascades over the entire lifecycle of the game-with no meaningful risk associated with dying, and the fact that you can respawn very near where you died (graveyards, etc.) makes any conflict in the game that involves someone dying meaningless--and for any game where conflict between players of any sort (not just combat), when there is no downside involved with the conflict, the players will eventually stop using the game mechanic because it has no actual net effect.

It's a damned game, it's meant to be fun.  Any game that is determined to punish its players is very wrong-minded. 

 If players decline to engage in PvP, it is because it no longer entertains them, which is more likely to happen if they spend most of their time and money recovering from dying.

EDIT: It's possible it was Richard Bartle that wrote the article I'm talking about--but I haven't been able to confirm one way or the other yet...

Also, it was the Roman poet Juvenal  (http://www.bartleby.com/61/39/B0463950.html) who coined bread and circuses.  Though I'm sure Heinlein used it to great effect.

Please realize I am not advocating "broken glass bottle shoved into the rectum" (great phrase by the way!) style death penalties--but I do think that the WoW version of the concept is a pendulum swing too far in the wrong direction (and to relate back to the original post, a swing caused by the general MMOG player base).

I certainly don't look forward to PvP death, but I don't hate it as AcidCat suggests I should.

You made good points earlier of how the lack of death penalties is exploited in WoW, but I submitted changes they can make regarding PvP deaths without introducing penalties (several of which will be included in the Battlegrounds system).  Hell, even the broadcasting the Jedi Academy-style "So-and-so has been thrown to their doom by what's-his-smell" would be sufficient  to encourage players to try not to die, without sticking a metaphorical fork in their eye.

What do you think should happen to players when they die in WoW?  How would you "swing the pendulum" back to where you believe it should be?

I don't play WoW

 :-o

Have I been tricked by the title of this forum?

We all hated cr runs (especially at the raid level) in EQ, and all the death penalties that have been used by various games over the years, but one of the things that Raph (again, if it was he) pointed out is that there is a long term downside to minimal/nonexistent death penalties: when there is no perceived risk, players will do anything and everything. A perfect example (of this example) is the complaints about territorial control on PvP servers I've read here in WoW: it really doesn't matter what you do, if a player wants to keep coming back after they die, they can, and do. "Griefers", PvP defenders (in the case of territorial/spawn control), and pretty much anyone else can simply keep on coming back regardless of what happens, making the end of the conflict simply whomever gives up first, or runs out of time.

That isn't an issue of death penalties, that's an issue of not thinking through the PVP system. One minor change would have made this problem go away, or be significantly less of a problem. In a contensted zone, deaths take you out of the contested zone to the nearest friendly graveyard. Why this wasn't considered I can only blame on the addition of PVP too late in beta to change things. The penalty for death hasn't changed, but it has made the return to a conflict more difficult. DAOC had this system in place at release, but they went to far to the other side, really punishing the player by sending him a long distance from the battle. They later added mechanics that eased up on that.

Valid point, but based on the dynamics of other posts dealing with WoW's "death penalty", some people do consider the time to "recover" from a death and getting back to what you were doing as part of the overall "penalty".

For my money these days, if you aren't INSTANCING sieges, with hard caps on the number of times someone can die while taking part in them, you aren't doing sieges correctly.

One of the things that players cannot see, but developers can, is the "long term view".

That isn't an issue of death penalties, that's an issue of not thinking through the PVP system. One minor change would have made this problem go away, or be significantly less of a problem. In a contensted zone, deaths take you out of the contested zone to the nearest friendly graveyard. Why this wasn't considered I can only blame on the addition of PVP too late in beta to change things.

Beta testers are to load the game to expose bugs you'd otherwise miss. Godot help you if you do design by consensus based on feedback from the bleating of tens of thousand of sheep. I remember the Shadowbane beta.

However, the swarming mass of uberguild ganktards had a louder voice than those who appreciated their initial game mechanics.

Either the company can balance the game themselves and stick to their vision or they can't and it will suck.

Would you fully define "instancing" in this circumstance please? If you mean reserved/dedicated cpu and network resources for the fight and the surrounding area, then certainly.

If you mean "level balancing", forcing equal numbers, set duration, "no one else can join", non-persistent world effects once the siege is "complete", or anything along those lines, then I most definately disagree completely.

Go ahead and disagree. Now go back and play Shadowbane. If you do not start implementing some forms of non-persistent world effects on sieges, THEY WILL FUCKING SUCK. They will be lagfests full of retardation, buggy pieces of shit, not to mention that in early release, all your hardcore catass wastes of flesh will rule the world, get bored with ruling, and quit, reducing your player base to half what it was simply by removing any effective leadership from most of the popular guilds.

Persistent world effects just means the winners always win, the losers have no recourse and is a repeat of all the failures of the past.

Basically beta testing is stupid.

If I ran a game, I wouldn't even have public forums, there would be one board, that was meant for bug reports only.  No fucking suggestions, no ideas, no complaints nothing but "this is a bug, blahblah".

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.

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.

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.

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.

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.

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 (http://www.f13.net/index2.php?subaction=showfull&id=1108575685&archive=&start_from=&ucat=1&). Massive means shit. Massive is what lazy developers have used as a justification for charging subscriptions for really shitty single-player game mechanics.

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 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.

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.

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.

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?

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.

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.

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

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'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.

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.

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 (http://www.f13.net/index2.php?subaction=showfull&id=1102699515&archive=&start_from=&ucat=1&).

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

[/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.

/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.

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.

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.

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

Ack!Mud 4.3 is Copyright (C)1998 by Stephen Zepp

I really don't have a position in this thread, but I feel compelled to point out that the above is almost meaningless.  It doesn't matter what it's like with 100 vs. 100 npc troops; it matters what it's like when you're updating 100 vs. 100 pc characters, each connected to the server via the Internet.  And you're not simulating that.  Actually drawing the graphics isn't the big issue; it's processing the latency-ridden client-server and server-client updates.

Bruce

I don't think the problem is entirely graphical.  I think much of the issue is the communications between multiple clients with each other and the server.  While I lack the computer acumen to diagnose the problem, I do know that I have seen the same problem in every MMOG I've played.  That isn't to say that you are not the exception or the breakthrough, but I heard the guy who designed the hardware and networking for SB explain why he did it the way he did, and that sounded like it should have worked too... but it didn't.

Ack, SirBruce beat me to the point.  That is why I hate these long replies.  And he was more concise, which is why I hate being a pendant.

Actually, the real effectiveness of ninja sieges wasn't in the physical damage done, it was in the morale damage.  Attack groups raiding your tree and killing everyone in town leads directly to people not logging on, followed by cancelled subscriptions.  If I can kill one AFK player at 3am, I will be effective, given that I do it often enough.  And if I can't kill one AFK player at 3am, what is the point?

There were a number of siege scenarios in SB beta.  'Rolling Trebs' (siege weapons then were very slow pets, and in fact they still are pets, AFAIK) was the mechanic up through Beta 3.0.  The problem with the mechanic (aside from the bugs and crashes) was that you basically had to completely overwhelm the defenders, and then stand around for hours while you damaged the buildings.  Whether you won or lost, the battle was a very short term thing, while the players had to invest vast quantities of time building the cities, moving the siege weapons, and then using them, all for a relatively brief battle.

The mechanic in Beta 4 and live is to render the weapons immobile, and build them on the spot.  Unfortunately, the problem is only lessened.  Cities are still slow to build, slow to damage, and sieges are still relatively short battles, although the current implementation no longer requires hours of pre-battle preparation.

Now the mechanic you seem to be proposing for the game you are working on is a movement of NPC surrogates over time.  The question I have is how this process extends the player's action/entertainment time, since clicking menus and giving commands to NPCs isn't likely to be the sort of thing most players enjoy.

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

Ack!Mud 4.3 is Copyright (C)1998 by Stephen Zepp

He mentioned specifically rendering issues with 200 game entities. As I've mentioned elsewhere in the thread, if your game design allows for 200 directly client controlled and fully update needed player objects in a close-in situation, then it's the game design that should be adjusted. While it is possible for 200 player avatars to be in the same geographical space as 200 npc troops, it's not a necessary part of game play, and good design makes it an extremely rare occurence. Of course, players could do it intentionally, but they can do a hell of a lot of other things to bring a server to it's knees as well. You plan for them, plan to make them not a necessary game mechanic (stacking for instance), and cover your bases the best you can.

He mentioned specifically rendering issues with 200 game entities. As I've mentioned elsewhere in the thread, if your game design allows for 200 directly client controlled and fully update needed player objects in a close-in situation, then it's the game design that should be adjusted. While it is possible for 200 player avatars to be in the same geographical space as 200 npc troops, it's not a necessary part of game play, and good design makes it an extremely rare occurence. Of course, players could do it intentionally, but they can do a hell of a lot of other things to bring a server to it's knees as well. You plan for them, plan to make them not a necessary game mechanic (stacking for instance), and cover your bases the best you can.

I really don't have a position in this thread, but I feel compelled to point out that the above is almost meaningless.  It doesn't matter what it's like with 100 vs. 100 npc troops; it matters what it's like when you're updating 100 vs. 100 pc characters, each connected to the server via the Internet.  And you're not simulating that.  Actually drawing the graphics isn't the big issue; it's processing the latency-ridden client-server and server-client updates.

Bruce

To agree with Bruce here, internal testing means shit. Shadowbane's original siege engine tested great... internally. When it hit the beta test server, it wasn't even a good slideshow.  I don't care what anyone will tell you, if you and a majority of your testers are not at a remote location, you have NO FUCKING IDEA what kind of latency issues will crop up.

Also, the optimism of some in this thread is cute. I eat it with a side of Chianti. The MMOG industry lives off of your optimism.

All of our testing is fully remote. In fact, only 2 of our team members even live in the same state!

The problem with his scenario, as I apparently failed to get across, was not only client-side rendering, but also the amount of server to client interactions that have to take place. Both create the huge bottlenecks seen in sieges to this day.

Shadowbane DID use quite extensively level-of-detail scenarios for rendering. Whether or not theirs sucked rocks or not doesn't change the fact that they did use these rendering techniques. The theory is sound, as with everything, it's the implentation of said LOD effects that determine lag or smooth frame rate.

Now, you are saying that you are running 200 NPC battles, with exactly how many PC's involved? Yes, you may get smooth frame rate on that, as well as no latency issues. But if every player in the battle has NPC's, and you get 100 players on each side, you are still going to have rendering issues. Total War is a good start, but God Forbid TW ever had to render all those troops PLUS a playable character for each unit's commander on the field. Or are you saying that the only people who control NPC's retinues are the RTS style players? So let's say there are only 200 NPC's, and then another 100 PC's without retinues who are fighting on each side. You still have 200 PC's, all needing server to client updates on the other characters in their view, PLUS server to client updates on the position of NPC's, the state of the city's defenses, any deformable terrain effects, any ranged weapon effects, and the server has to process all that and send it out, on top of NPC AI, pathfinding and collision detection for all NPC units and PC's.

Oh yes, and you still need that server (or cluster) to send out information to the players on the other side of the world who may or may not have anything to do with the whole dealie.

Yeah, I'm thinking you will need some negative ping code. Because that's the kind of thing I'm talking about. If (big if) you get the player's client to not shit itself with that much stuff on the screen, your netcode will have to be better than anything and everything currently on the market.

Good luck with that. Frankly, it sounds like a good idea that isn't possible with current tech. And if it is possible, I don't see it coming in at under $30 million, no matter how much of this (http://www.pcgameworld.com/story.php/id/4560/) you reuse.

My concern is slightly different from Haemish's, and mostly the same.  I'm willing to believe that you can code a better client update system than we've seen so far.  While I haven't seen the code, I've seen the results, and there has to be a better way.  But I still don't trust your confidence in large event scenarios this side of some actual beta.  To steal somebody's rephrasing of a classic quote, "no game design survives contact with the players".  I think this has been a hidden truth of gaming that MMOs have uncerimoniously dragged into the light of day.

On the other hand, I was equally confident about WoW have massive security problems, and so far that hasn't happened, Thottbot aside.

If your design is not going to factor in the fact that there WILL BE an assload more units than you want into it, you have failed at the design stage. I'm not talking about every player on the server being there. But unless you put an artificial limit on the size of a guild or alliance, you better be able to count on there being a lot more players at the action focii than you it sounds like you are counting on. Again, if it goes to 11, MMOG players will not be satisified with 10.

How exactly does your design intend to keep every single member of a guild out of a siege? It sounds to me like you are trying to make Total War, except that 5 or 6 players can all play unit commanders. What happens when a 200-player guild wants to siege. Sure, it may only take 5 guys online at any time to move the NPC's into the fight, but when the fight happens, you can count on at least half of any half-assed organized guild to be at the siege. What exactly at the design stage are you going to do to cut out that eventuallity?

Strangely enough, that's one of the reasons instancing has become so popular, because you can't design expecting that players will do what you want them to do. If there's a bigass fight going on, people who may not even be remotely involved will want to be there. And again, numbers matter. The first rule of military strategy is get there the firstest with the mostest. It doesn't matter if you only need 5 guys, if an organization can move 500 with efficiency, they will whether your design encourages that or not.

Also, the updates you would have to send to the rest of the players on the server cluster have nothing to do with the siege updates, I'm talking about just the regular updates EVERY client has to get from the server in order to function. Those transactions pile up, putting strain on the server cluster. Combine those with the ultra-intense transactions in a large siege, and you have server lag.

Wait, how exactly is what you just now described NOT instancing? Because it pretty much sounded like the exact same technical implementation I was on about, only you give one set of people one set of content, and another set of people different content.

How is that not instancing?

I'm going to add some non techno babble in here...

I think you can force players to not gather too much in one spot.  You make it a bad tactical choice, sure people will bring the max amount of forces you let them bring.  But if you put enough things into a game that do heavy AoE damage, or jump from target to target, or plagues that spread from npc to all nearby npc's ect ect ect.

Make it tactically completely fucking unsound to not maintain a good spread between forces.

Make a siege practically require you to surround the fortress/town/village/castle, and make them take up allot of geographical space, thereby spreading out forces to several battle points.

Make flanking, and attacking from the rear effective against npc troops to encourage/force players to have skirmishers/vangaurds to protect against such attacks.  Further spreading forces out on the battlefield.

I believe one can through gameplay prevent just sticking as much firepower in one place the most effective tactic.  We've all agreed (its seems) that you wont prevent having more forces from being more effective so it seems logical the solution is to make spreading those forces out by far and away more effective then getting them all packed in one point.

Good luck getting that load balancing thing working. You are aware that the exact same mechanic you describe is currently in ever MMOG in one form or another?

If the primary siege event(s) and the "rest of the world" all share the same server resource set, absolutely. That's the purpose of the dynamic load balancing. For example, in SB, what happened on the War server didn't have any (well, much anyway) "lag effect" for the players on Corruption (except for the common tie points we can assume: databases and total network hardware). In EQ, it was very rare for 3 huge raids in ToV to affect players fighting gnolls in other zones.

Interesting to hear, because from a black box perspective, SB was one of the ones that (appeared, obviously) to not use load balancing within a server...the fact that you could lag standing completely alone in a city while a very large siege was happening on the other side of the world. Guess they tried it, but had network backbone issues--only thing I can think of to cause the cross-over lag if they were on different resource sets.

As far as I know, SB servers were NOT run on multiple machines like every other MMO, but were on single monolithic machines.  Several references to 'big iron', etc.  IMO, this would be the cause of most of the server-side lag in that game.  They didn't seem to have any load balancing at all, tho I recall them claiming they would.  I don't think it ever happened.

As far as EQ, they did have static load balancing, as each game server was multiple machines, each machine ran a handfull of zones.  Occasionally you could feel it when your current zone was on the same box as ToV during raid time, or other major zones.  But only occasionally...  You also tended to feel it when they managed to crash that zone, as it frequently took down the whole machine, or forced them to reboot it, or some such... which would affect a couple other zones as well as the problem zone.  Early on, this kinda stuff was noticable with zones sharing boxes with East Commonlands or Greater Faydark, both being heavy player-congregation zones pre-Luclin.

I think dynamic load balancing is almost a 'holy grail' of MMO Gaming.  Having a setup that allowed a machine to scale the amount of territory that it had to manage by the number of players within that territory, so that as more people arrived, the machine had less space to manage, is ideal.  Getting it to work well...  is apparently not easy.

Alkiera

So you plan to literally almost physically transfer all the characters, terrain information, NPC's, etc. to an entirely other piece of macchinery when there get to be too many people there, and you plan on doing this without them noticing, as the entire server architecture starts tossing around hundreds of concurrent connections and do it all seamlessly, transparently to the user?

So you plan to literally almost physically transfer all the characters, terrain information, NPC's, etc. to an entirely other piece of macchinery when there get to be too many people there, and you plan on doing this without them noticing, as the entire server architecture starts tossing around hundreds of concurrent connections and do it all seamlessly, transparently to the user?

Yeah, good luck with that negative ping code too.

I do not see why you are bothering trying to do something like that. With that kind of idea, you are going 3/4 of the way to instancing the siege anyway. If it works, you could potentially sell that tech to anyone for asstons of dollars. But if it doesn't, and I'm inclined to believe that without MAJOR financial backing and more patience than any VC/Publisher has shown in MMOG history ever, you're going to have a long cluster fuck of a beta ending up like Wish in a cancelled game.

Instancing is a better technical solution because it takes into account the limitations of today's hardware and Internet infastructure. Add in the fact that with instancing, you can more easily adjust things like balance, numbers, terrain placement, and additional siege-specific scripting features to make the experience much more dynamic than anything that's been seen on the PVP front. And you're only real argument against instancing is it "removes the virtual worldness." Which it doesn't, because you still have a world, that can be changed, and there are still thousands of others in the world, they just aren't all banging up against the siege's front door.

This does sound too ambitious to me, but without ambition there would be no innovation. What I keep wondering is why not use distributed processing with dynamical recourse allocation instead of copying process information around? You can much easier transfer calculation_a to another machine/processor than a process requiring calculation_a performed.

If your design is not going to factor in the fact that there WILL BE an assload more units than you want into it, you have failed at the design stage. ...

Again, if it goes to 11, MMOG players will not be satisified with 10. ...

How exactly does your design intend to keep every single member of a guild out of a siege?  ...

As I've mentioned elsewhere in the thread, if your game design allows for 200 directly client controlled and fully update needed player objects in a close-in situation, then it's the game design that should be adjusted.

While it is possible for 200 player avatars to be in the same geographical space as 200 npc ... and good design makes it an extremely rare occurence. Of course, players could do it intentionally ...

Haemish was using an implementation mechanism (and not a particularly good one, you wouldn't "move" everything all at once, nor would you initialize a new resource set only as it becomes needed, that is way too much delay) to invalidate a design. Two completely different things.

This is a fundamentally unsolvable problem because of the emphasis on combat.  Emphasis, or perhaps even total focus to the exlusion of anything else.  Combat by its very nature tends to make players want to cluster together, especially in an RTS-like game.  I think you have to try something else.

The only reliable way I see to encourage players along different lines is to give them non-combat ways to interact with the world that are every bit as compelling as combat.  As long as the only or most compelling option players have is combat, then that's all they'll do, increasing the risk of breaking the overly-elaborate system described above.  Give players crafting systems that aren't file download bars with a sound at the end.  Give players rewards for exploring.  Give players intricate missions that are more than just kill-this-foozle-and-bring-back-an-item.  Give players things that make them want to spread out over the game world because it has direct benefit to do so.    Do those things, and a smaller percentage of your concurrent players will be involved in combat at any given time.  This reduces the risk of player clustering and, in turn, the need for so much developer time spent on solving what amount to glorified network problems instead of putting in compelling game content.

No they aren't two completely different things.  They may not be identical, but they very much related.

I hear this all the time in the industry, glorified visions of whatever is a common buzzword of the moment.  If you cannot come up with a concrete implementation of a design that works, then the design is flawed or untenable.  You can and should do this prior to the start of the major coding effort.

Using one or more implementations to prove or disprove a design is the only acceptable way to engineer any system, be it software or other.  Design in the real world, or doom your software to Shadowbane-esque glory.

I agree--this discussion has been focusing specifically on the infrastructure architecture, but there are dozens of other, higher level, game design mechanisms to avoid "everyone on the server is here" combats as well.

Once again, AC/AC2 already does this. They have a main action locii of the entire game world, and then break off additional locii as needed, and re-merge them as required.

Yay for them? AC2 sucked ass, and both had lag bubbles issues for a long while after release.

EDIT: And just because you instance a siege, that does not preclude having actions like scout battles, attacking supply lines, etc. I believe using instancing, you could actually make them MORE involving than they are in games where you have this stuff without instancing. Making instances little boutique type areas allows you an assload more server resources to do things like deformable terrain, terrain effects, hand-crafted design of zones, etc.

Kind of an aside, but that's twice now you've brought up deformable terrain, and I'm kind of curious why...it's quite a coincidence that networked terrain deformation is exactly the implementation I'm finishing up this weekend--been on and off it for a couple of months now.

He brings it up because it kicks ass. Think of the possibilities: for instance, instead of having to force your way through a gatehouse chokepoint for a castle, you might be able to bust a wall down on way or another. People hiding in a forest? Burn the damn thing down, and now they have no cover/camoflouge. Terrain deformation would be even more useful with modern weaponry. Group holed up in a house? Bust it down. Guy sniping from behind a rock formation? Can't shoot Through it? Blow it the fuck up. Group assaulting from a cave? Make them retreat a bit, then cave the entrance in and trap the bastards inside to suffocate.

Terrain Deformation For Teh Win, etc etc.

I agree--this discussion has been focusing specifically on the infrastructure architecture, but there are dozens of other, higher level, game design mechanisms to avoid "everyone on the server is here" combats as well. The primary one for our particular project is the removal of the "god control" layer over npc troops. Instead of directly forcing their movement, actions, attacks, etc., you issue orders, and the npcs evaluate those orders based on loyalty, casus belli (reasons for war), discipline, etc. Just because a guild consisting of a chaos-earth faction wants to go 3/4 of the way across the game world to jump in on a siege between an order-spirit faction and a order-death faction doesn't mean that their forces can be mobilized to actually contribute in any way to that particular siege, nor does it mean the troops will fight who you want them to fight once you get there. And yes, what I am implying here is mechanics enforced "lore".

How many more MMORPGs need to die before this community understands this simple principle...?