"The Snowball of Nerf-Hate Effect"

[MaceVanHoffen]

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.

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.

[Stephen Zepp]

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.

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

[Stephen Zepp]

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.

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.

The purist in me would argue otherwise, but your point is well taken. It doesn't matter what you design if you can't implement it.

[sinij]

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.

This is where IMO "instancing"* falls short. You have to put artificial rules and constrain that break immersion and limit ways players can interact. In non-instancing siege you can give number of alternative activities, like counter-attacking, scouting, attacking supply lines and such, that would entice players from participating at 'the main fight'.


* Lets stick to non-technical definition of instancing that everyone understands and uses. Instancing is creating non-interacting copies of the same content for individual & small group of players. It is non-interacting aspect that defines instancing.

[Hoax]

Ok so I'm not smart enough to know exactly what your saying but it sounds like the problem is this in layman terms:

A small battle starts, both sides call for reinforcements from nearby areas who converge upon the area.  When those reinforcements arrive you want the system to allocate more resources to the battle area so that everyone doesn't just lag to hell.  The concern is how do you move all that world information onto new server resources w/out their being big framerate/lag hiccups when those new forces arrive?

If that is the gist of it I have a thought on the matter but I can't be sure I'm understanding correctly.

*Edit*  Actually, I dont like my idea much I was thinking of how there was a brief pause when new troops entered an area in Dynasty Warriors and thinking that you might be better off having there be a designed pause w/ some message saying: "new forces have arrived" so that you dont have to worry as much about some people being slower to recieve the new locii information or worse crashing when new troops arrive.  But thats something that works well in single player games and I'm not sure I like it in a mmog so nevermind.

[HaemishM]

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.

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.

[Stephen Zepp]

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.

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.

Regarding the main discussion, I think that implementation wise both of the designs have strengths and weaknesses, and obviously our current design is a lot less in use currently for MMOGs. I also don't think that either of us have come up with any convincing arguments to change the other's mind, so unless others contribute, I'd think it's time for us to agree to disagree! I do like the direction the thread has almost head a couple of times (game design decisions at a higher level than just the siege itself)!

[Strazos]

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.

[Stephen Zepp]

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.

Oh, you don't have to convince me how cool it is, I was just wondering if it was a coincidence that he was bringing it up in this thread, or if it was the fact that it's what I'm working on.

For discussion purposes by the way, you actually brought up two different topics: object destruction/deformation, and terrain deformation. Subtle difference honestly, but implementation wise they are two totally different things. Examples in shadowbane: destroying a city wall was object destruction, how the city grid flattened out when you placed a ToL was terrain deformation.

[HaemishM]

I bring it up because in previous MMOG's it has either been impossible to do real-time (thus requiring large patches to change the world) or has been a cluster fuck of clipping issues, or boring randomized terrain. Taking the siege or other instance resources out of the server cluster infastructure and dropping them into their own dedicated area should allow you more control over things like terrain deformation, object destruction and specialized creature/enemy AI options. All of these things can be done without junking up server resources for the people not even involved in the action.

It's pure co-winky-dink that I brought it up while you were working on it.

[sarius]

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.

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

A specific player (type) that SWG cultivated well has been thrown the sewage pit by their developers, IMO.  Crafting, in the infamous CURB, has been completely capped to where the player can always reach the pinnacle of max stats with the most minor effort.  The Smuggler revamp has lowered the limits of slicing to ridiculously nominal inclusion, and it basically took most of the community threatening a walkout before the devs decided to not invalidate ALL resources collected for Armor and Weaponsmithing professions for the past two years.

SOE devs have a two year history of outright lies to their player base on these professions.  They flew people to Austiin and lied to their faces.  It would be just a funny if they only drove their players away from the game in the thousands once a year, but they've adopted the Capt. Nimo school of customer relations to the point where everyone uses SOE as the poster child for what not to do.

I seriously doubt that most SWG developers know crap about the long term effects of their decisions on their player base.  If they did, they'd be able to actually describe interaction in the crafting professions of SWG with coherent sentences and SOE wouldn't be playing hot potato with their subscriptions numbers for the upcoming quarterlies.

The first game that comes out with a complex crafting system tied to a complex economy beyond SWG's will be the end of SWG's foundational veteran players, and the game itself, IMO.  Sadly, there's been no rise to the occasion I've seen.

Finally, in communications software development I've not once seen where taking something away from a product, in any light, has produced more customers.  How many more MMORPGs need to die before this community understands this simple principle...?

[HaemishM]

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

Lots. Lots and lots of lots. I can count on one hand the number of dead MMOG's, and that number is eclipsed by the still-going yet shitty ones.

[WindupAtheist]

I'm a Star Wars fanboy, and an Ultima Online diehard, and even *I* think SWG looks like ass.  What else need I say?