Territorial Warfare Without Timers

[Vinadil]

Yea... and thought it has been a while since I played SB, I liked the direction they were moving with things like Walls and Mines.... giving them a TON of hitpoints but NO ranks.  That way you don't spend 3 weeks and millions of gold building something that a person knocks down overnight, but you still spend Something and it takes a Good amount of time (even with no defense) to knock down the walls.

The mines are intended to be the daily battle, and I think they could actually have been used MUCH better in SB.  Server population kind of kills that system, and the fact that only a Very few city features require actual resources (like the T8 tree).  Mines would have been much more interesting (to me anyway) if you needed wood/stone/etc. for cities and siege equipment instead of just gold for everything.

One thing that can help the whole Timer thing (trying to get back to the OP) is just to make things take more time while Still giving some incentive to do them.  For example:

In SB it was not out of the ordinary for my guild to run late night raids on player towns, or even All-day affairs on weekends.  Sure some of it was boring, but not entirely because you had the random PvP that occured as people would try to kick you out of an area.  That will be a part of most PvP games, but if you added a nice PvE element to it then it would give people an incentive to stick around sieging a town also.  PvE element I always wanted was NPC merchants who carry items/create wealth for allied guilds (much like Rise of Nations caravans).  Now, the reason you need incentive for people to beat on walls (outside of wanting to kill the other side) is that you are going to make it take 12-24 hours to get through a wall.

Of course that sounds crazy as very few people will actually spend 12-24 straight hours tearing down a wall.  But, say you actually made it take time to REPAIR a wall also?  This is one thing I never got about SB.  It takes 3 hours to beat a wall to almost 0 and then a few seconds and some gold to magically bring it back to 1million HP.  What if the defenders had to repair similar to how the attackers sieged?  Basically it would allow a siege to take place over several RL days or even weeks.  The point of the siege would be to get the Cities resources (Through mines/caravans/players) as well as knock down the wall and capture the city.  The defenders would have time to repair their wall during their PrimeTime if they wanted.

If you make the siege process take longer, but give other short-term goals/achievements to both sides, then you may not need the Timer feature either.

[Stephen Zepp]

To be able to handle that well, and also handle a large variety of other "human offline" tasks, you need to basically disconnect the human directly from controlling his units/buildings, and instead have him give orders to a "controller" of some sort, that then processes those guidelines/orders. And that means a controller for basically every player that ever happens to have the possibility of controlling a unit or two--and while it's not a linear multiplier really (internal vs external bandwidth), having a process for every one of your human account holders (and you can't go with just the online users here, which is what most servers need to optimize for--max online loads) is a really daunting concept, especially for an indie

So you've got resource gatherers or shopkeepers or crafters under your dominion that need to perform their non-combat actions without grinding the server to a halt.  If each NPC performs its duties autonomously then each one is poling timers and checking status.  [snip various technical stuff]

Absolutely--polling loops break down when you start talking massive anything, and it's important to use a variable rate callback algorithm so that regardless of the last time you got a message to update, you can "catch up" and calculate anything that was missed.

An another option for those things that do need to be polled (even if it isn't every 32 milliseconds or whatever) is to look at lowering the frequency of updates based on the "closeness" (in time) of being observed. No one really cares if the guards move from point a to b to c to d if they aren't watching--they just care that if it takes 10 minutes to go through all 4, if they come into observable range 7.5 mins in, the guards should be at point c.

There is a lot you can do with this theory of "load is where the observers are" as well--dynamic predictive scheduling of server loads based on player centric load momentum is a really interesting topic--basically, if a lot of players are converging on an area, predict that you will need hefty resources (hardware/server) and set up a (seamless zoning of course) heavy duty resource set to handle the expected load in a small geographical area (new server box, migrate all the players to it as they get close).

And for all those areas that have nothing in them--put 'em all on one box and let them update as they can, no need to be synchronized and steady if no one is watching, as long as the "sum over histories" works out the same.

Closer to the topic: Without NPCs to drag out combat or hard timers to limit asset destruction over time you are left with a game of capture and hold where if you log off your team loses control of whatever assets they happened to be holding at the time.  That's a pretty hard core model for a persistant world and under such a model I'd expect ~60-300sec construction time for assets - because they'll be gone as soon as you lag out and can't get back through the login server.  It would require human guard duty to establish long lived assets, which is not fun and poses a problem for the small group that can't cover 24-7-365. 

However, the folks who actually got to build the cities in Shadowbane were very few but the folks who got to knock them down were legion.  Much cheaper but less persistant buildings would go a long way to spreading the "builder" play feature across the entire game population.  That alone might make it worth pursuing a two fold approach: the skirmish game has no timers, but the capital game does.  Folks who want to be really serious about their asset construction can build the capitals while the rest can have most of that same fun without the grinding/farming/stress outlay of maintaining a persistant asset in a PvP world.  We lost more buildings to first time build and upkeep mistakes than to enemy attack in SB, the costs were really too high for a nation to be able to let everyone play at city building.

Draw the skirmish buildings from local terrain limits (no trees here == no fast tower building, no stone and no trees == no towers at all), so players don't even have to "farm" to build them.  That might start being fun - Fog of War being dispelled by watch towers, being knocked down by an attacking enemy, etc.

SB got close with the idea of a "city adminstrator" (owner of the ToL), and the ability to have other players run shops and such. The problem here was that the system was so very limited.

In a "perfect world" RTS/RPG hybrid, a city adminstrator would deed out lots, and could even zone them (ala Sim City), and other players could lease the lots and do what they want. Combined with a much more flexible (and complex, I admit) "permissions" system, you could have a player run a set of training barracks, and have other players that were 'trusted' come and hire out troops....and if they return those troops at the end of the "day", get a higher trustworthiness rating for the next time, or whatever type of positive reinforcement you want.

[HRose]

Can I join the discussion?

This is one of the main problems I analyzed since open warfare and conquest-based PvP is what I like the most in a MMO.

On the proposed solution of "slow" siege engines I'd say that it leads to a situation where the battles focus around those. Siege engines would be the vulnerable spot. There cannot be any surprise attack or, the main problem, strategy, because your enemy can see from far away the thing crawling for days.

This means that the battle is fought *between* keeps, not around them. The goal would be neutralizing the siege equipment before it reaches the castle. Which isn't exactly a wonderful scenarios as you likely want the battles to take place in those castles.

I'll explain instead how I was thinking to solve the problem myself.

Beside a bunch of little things and sidetracks the main solution was about the "ruleset" used in the conquest system. Think about zooming in and out of a world, where with each zoom out you get multiple situations condensed into one. The more you zoom in the more you go in-detail, the more you zoom out the more you get abstractions. A war in a region can be made by a bunch of skirmishes. You zoom in and you get the detail, you zoom out and you get the war progression on a general level.

That's the context.

The goal is: the system should work so that the opposite faction cannot conquer the whole world overnight. In DAoC or SB this is possible. Rush and conquer all the keeps, steal the relics during off-peaks. You wake up and discover you lost everything.

War isn't like that. The idea is to segment it. There's the first-person level. Your character fighting. The single battle. The single castle. This level is the level of the skirmish. A region can be made of different castles and "hotspots". Control enough of them and the region is yours. Risk-like your realm can only conquer adjacent regions, so that the conquest progress is easily readable. You see the border of your empire expanding or shrinking.

The idea is that in a (real) day you can annex one or two regions. You have to occupy castles and defend them. Whoever maintains the control also finishes to take over that region. Once that region is yours you can move to the next one.

In order to make this plan work I also made a distinction between conquest and pillage. Conquering a keep means controlling it. Make it your home. Start producing stuff, activating an economy. As I said before this is only possible if you have a direct supply line to that keep. If instead you attack another place that isn't located in the vulnerable regions (those adjacent) you can just create havoc. You won't take over the keep, but you can destroy it and steal enemy's resources, or burn them. This means disrupting their economy and forcing them to rebuild.

So basically you have this Risk-like type of map. With regions, and hotspots within each region. Players can see right away where the battle is because it is focused mainly on the borders of your empire and not spread around a huge world where you have to walk for an hour before finding a fight.

And the result is that while the skirmishes are real-time, the conquest progression is slower, following the rules of a real war.

This means that the system is less vulnerable to a "rush" victory. Thing develop with the time. The war is an overall context. A campaign.

By the way, along those ideas I was also proposing a complete automated system where you programmed NPCs to do all the boring duties. My game concept has complex supply lines and campaign-related resources-gathering and production. People say this is a killer because no one wants to be a farmer. I agree.

My idea is that NPCs are made for that. Not to be quest dispensers or just sit there staring at a wall, but to do in your place all that is boring in a game but still necessary for the game to have some depth. Let them work in your place. Let them walk, farm, craft.

While the players wage war.

About the "rich get richer" I also had in mind various solutions (so that the war isn't predictable and the loser always has fun gameplay available), but that's entirely another topic.

[HRose]

P.S.

I noticed that Zepp wrote how complex NPC activity isn't easily doable due to heavy CPU load, so I'll explain how I imagined my solution. Because I had thought of that as well.

Basically an AI is when a CPU is presented a situation and has to calculate something. In my idea the automated system I described above is completely "free" of AI on the general level.

It's AI when you are dynamically pathing something, for example. But it isn't AI if you tell an NPC to walk to point A to B and then from B to C.

In my idea the "programmable  NPCs" came out of a system where all actions are pre-planned. For example the walking nodes are already there. You just activate and order them. You tell an NPC to walk between points, carry over duties, but all these tasks are precalculated.

This would allow a good number of NPCs working in the background, using the CPU for about the same tasks that involve normal mobs in a game. The AI would just kick-in in a combat situation. While the rest is about automatons moving through instruction trees.

[Stephen Zepp]

My thoughts are a bit of a hybrid of the two concepts: moving siege capability (more importantly to me at least, moving troops, since in this design "players" are squad leaders of NPC troops, but the troops still have to travel to the target) across terrain is important, but what's more important is constructing siege outposts in preparation for attack.

In historical siege warfare, you didn't make siege towers in your home castles and march them to the target--you marched the resources to the target's general area, and then constructed the siege engines there. You did of course march your troops, but I'm selecting the idea here of siege outposts, not the actual mechanics.

This is very similar in effect to HRose's thoughts here--taking territory is a matter of expanding your own territories via outposts, which become bigger and bigger as they survive. Eventually, there will be a territorial overlap/no man's land where much of the field combat happens, but you can still march around insufficiently defended/supported areas to attack at deeper targets.

In addition, given general holes in the enemy's perimeter, you could build up outposts that allow for troop housing/training, siege weapon construction, player respawn, player teleportation to/from, etc....making siege warfare against major cities possible in multiple ways--either as the end of a long campaign, or as a well planned outpost preparation in an insufficiently detended/detected area near an enemy city.

Of course, HRose's mechanisms for complexity being behind the scenes is of course critical--my general thoughts were to make it like what MOO 3's multi-level control was supposed to be like. You have multiple tiers of playstyle, and players can take over whichever they like, but without player control, there would be an AI to manage in a player's absence. Sure, if you have a guy on your "team" that loves the logisitical details, he can play that aspect (and will do much better than an AI most likely), but if you all just want to log in and kill stuff, your AI's will take care of eventually getting troops, siege weaponry, etc. to the places you need to be. You may want to help it some, but you don't have to.

Regarding what is "AI", that's always a sticky definition. Incorrectly of course, the general game dev industry defines things like pathfinding, immediate tactical target selection (basic, kill who's first), and even "move to destination" as AI, when of course it really isn't. You still of course need CPU cycles to accomplish even that stuff (even if it's just polling the troops to move their increment over time each update cycle), but it's not goal setting/accomplishment, sensor analysis, or problem recognition by any means....all of those require even more CPU cycles, and I think ultimately should be off-lined to background threads/machines for a system like this to work.

[HRose]

In my idea I entirely avoided NPC armies because I thought the point was that fighting is fun for the players. While the NPCs would be restricted to the boring duties and timesinks.

If every player builds an army then you have either an RTS or a game so huge that it's hard to manage. The NPC duties of my ideas are on a guild level. You take over the keep, put there your flag and then get access to the economy subsystem. So a whole guild has access to the NPC tasks, but not the single player.

I was thinking to use them not just for resource gathering, but also to haul stuff, patrols, guards and caravans.

The idea is that the layer of the economy is entirely persistent. The resources that are gathered sit in the world and never exit. You cannot safelock them into your bank or log out with them. Moreover the inventory is realistic. So let's say that you go pillage a town deep in enemy territory. You could decide to steal all of their resources there, but how you haul all that stuff back to your own territory? You would have to use a bunch of caravans, and caravans are slow. And they move on roads so they are also vulnerable. While the other faction can set NPC patrols that can spot you.

So the other option of destroying the resources. Or ambush enemy caravans.

So this whole layer is about the support to the war. Then the war is about the single players because that's the kind of expectation in a MMO. I was just thinking of a DAoC like with the conquest layer expanded and made the real pivot. But in the game at the end you play mainly your character, use your skills as always, PvP as always. So not a MMO/RTS. Just a conquest system that from a side borrows an economy-resource system, from the other the region-based conquest typical of wargames that I love so much.

About the passive defense I was thinking something very, very simple. Like DAoC guards in the keep, but persistent. Maybe more of them, but no respawns. It's up to the players to reactivate a keep or a village and manage it. There would be no AI system taking over and starting to react to a strategic game. Fighting NPCs in a PvP usually feels quite crappy.

[Krakrok]

Fighting NPCs in a PvP usually feels quite crappy.

I think it's almost mandatory that you also have NPCs to fight in a RPG style PvP game. 90% of players suck and NPCs allow them to win some of the time which is a requirement for a successful game. It works well in the Battlefront games.

[Lightstalker]

Fighting NPCs in a PvP usually feels quite crappy.

I think it's almost mandatory that you also have NPCs to fight in a RPG style PvP game. 90% of players suck and NPCs allow them to win some of the time which is a requirement for a successful game. It works well in the Battlefront games.

That, and you don't often have to run around the map looking for some NPCs to log in to PvP/E with.

[Krakrok]

That, and you don't often have to run around the map looking for some NPCs to log in to PvP/E with.

Which is a problem in DAOC battlegrounds and LOTRO Monster Play. Nothing worse than logging into LOTRO Monster Play and there being 10-20 monsters in the zone and no freeps to fight. Or if there are any there is no way to really find them. Each monster class gets a 'find X race freep' stone but it's pretty expensive to buy.

WWIIOL had this problem. Planetside has this problem but the 'Instant Action' button eliminates it.


I think if in HRose/Stephen Zepp's system the 'siege camp' worked like how the Base/Tower/AMS system works in Planetside it would probably be pretty good. The main goal being to give both sides a spawn point relatively close to each other where they can fight it out from until one of the spawn points is captured.

[HRose]

I think it's almost mandatory that you also have NPCs to fight in a RPG style PvP game. 90% of players suck and NPCs allow them to win some of the time which is a requirement for a successful game. It works well in the Battlefront games.

Well, in my idea the game has a PvE portion, but it happens elsewhere in the game and not on the PvP world.

I used that other portion as a "gate". Players get comfortable in PvE, learn the game and move to PvP only when they want so. It can be from minute 1 or never.

About the matter of "travel" instead I'll say that I was planning a teleporting system. I was planning a rather big PvP world with big zones. Traveling would take way too long and wouldn't be fun.

So from a side I was planning to compensate the large world by focusing the live war in a few "hotspots" (see above). So that you know where the action is and don't have to wander for hours to join a battle.

From the other I was thinking of a teleport system where you can log in the game and then port right near the battle. The interesting part is that the "economy" and resource game doesn't get teleport abilities. Teleporting works only on you and what you wear. If you want to haul stuff through the map you'll have to set an NPC caravan as I explained. While the players themselves are allowed to quickly port everywhere (that they have under their control with a port active, you cannot port into enemy land or neutral space).

[pxib]

The interesting part is that the "economy" and resource game doesn't get teleport abilities. Teleporting works only on you and what you wear. If you want to haul stuff through the map you'll have to set an NPC caravan as I explained. While the players themselves are allowed to quickly port everywhere (that they have under their control with a port active, you cannot port into enemy land or neutral space).

[derail]
This is one of my favorite parts of Puzzle Pirates. You can teleport onto a moving ship, or from island to island, or wherever you need to go virtually instantaneously. Any money you're carrying is at risk if you lose a battle. You can put your money in a bank, but the banks charge heavy fees to transfer from branch to branch. Crafting and rare goods can only be transferred in ships. Everything localizes automatically, and moving large amounts of cash around is either expensive or risky.

I was, for a time, part of a crew that ran a Western Union-style service. For a smaller fee than the banks charged, they would transfer large amounts of cash for other crews. Every once in a while we'd run inconspicuous ships with extremely large amounts of cash on board around the isles to keep various "money ships" stocked in popular harbors. Profitable and fun!
[/derail]

[Typhon]

I think if in HRose/Stephen Zepp's system the 'siege camp' worked like how the Base/Tower/AMS system works in Planetside it would probably be pretty good. The main goal being to give both sides a spawn point relatively close to each other where they can fight it out from until one of the spawn points is captured.

I dislike the siege camp idea because its slow and lumbering.  I'd rather see multiple defense targets, with the need for the offensive force to feint and cut supply/defense lines with scouts and distributed forces.  The offense must get the defense to commit to a particular front or fronts, and then hit somewhere where the defense isn't.   The answer to the 4am offense is, imo, to have fewer server instances with more people from all around the world (if it really is that problematic, add in the concept of characters having timezones - a character will not be fighting with fatigue during it's "daylight" hours.  Yes, I realize that that idea kind of sucks).  Combine this with defenses that are typically stronger then offense unless the offense brings to bear more expensive siege weaponry that takes a longer period of time to create - which gives the offense two choices, wait a week until they can create another fist of god to bring to bear on an enemy encampment, or try to draw the defending force to a location that isn't the primary target.

I like NPCs because of the reasons state: there's is a common denominator available for "PvP" regardless of whether anyone is on at any one given point in time or not.  I'd also like the concept of the RTS-style commander PC player (or even NPC 'player') because I like the concept of a general giving directions (rather then people having to guess at whether they should be offense or defense, etc)

[HRose]

I dislike the siege camp idea because its slow and lumbering.  I'd rather see multiple defense targets, with the need for the offensive force to feint and cut supply/defense lines with scouts and distributed forces.  The offense must get the defense to commit to a particular front or fronts, and then hit somewhere where the defense isn't.   The answer to the 4am offense is, imo, to have fewer server instances with more people from all around the world (if it really is that problematic, add in the concept of characters having timezones - a character will not be fighting with fatigue during it's "daylight" hours.  Yes, I realize that that idea kind of sucks).  Combine this with defenses that are typically stronger then offense unless the offense brings to bear more expensive siege weaponry that takes a longer period of time to create - which gives the offense two choices, wait a week until they can create another fist of god to bring to bear on an enemy encampment, or try to draw the defending force to a location that isn't the primary target.

I'm not sure what's the siege camp idea or even if it's part of the plan I described, but the rest should work pretty much like that (possibility to cut supply, steal resources, pillage etc..).

That said, in my experience it's not fun to have that mouse and cat gameplay where you go to attack where the enemy isn't. It's probably better instead to encourage a battle, one front against the other. I also don't like the classic DAoC style of attacking the undefended keep. The battles should happen because the fun gameplay at the end is about them.

About the worldwide servers instead it was explained elsewhere that it's often a publisher restriction. So not something you can touch in game design.

[Stephen Zepp]

I dislike the siege camp idea because its slow and lumbering.  I'd rather see multiple defense targets, with the need for the offensive force to feint and cut supply/defense lines with scouts and distributed forces.  The offense must get the defense to commit to a particular front or fronts, and then hit somewhere where the defense isn't.   The answer to the 4am offense is, imo, to have fewer server instances with more people from all around the world (if it really is that problematic, add in the concept of characters having timezones - a character will not be fighting with fatigue during it's "daylight" hours.  Yes, I realize that that idea kind of sucks).  Combine this with defenses that are typically stronger then offense unless the offense brings to bear more expensive siege weaponry that takes a longer period of time to create - which gives the offense two choices, wait a week until they can create another fist of god to bring to bear on an enemy encampment, or try to draw the defending force to a location that isn't the primary target.

I'm not sure what's the siege camp idea or even if it's part of the plan I described, but the rest should work pretty much like that (possibility to cut supply, steal resources, pillage etc..).

That said, in my experience it's not fun to have that mouse and cat gameplay where you go to attack where the enemy isn't. It's probably better instead to encourage a battle, one front against the other. I also don't like the classic DAoC style of attacking the undefended keep. The battles should happen because the fun gameplay at the end is about them.

About the worldwide servers instead it was explained elsewhere that it's often a publisher restriction. So not something you can touch in game design.

I think he was referring to my take on the concept HRose.

Interestingly, the main idea from this stemmed from my brother--he's an unusual MMO player in that he only gets a few hours in the mornings (early) to play, yet wanted to be able to do more than just solo gank (he used to work up unusually capable builds in SB just to mess with folks for an hour--his favorite was a nuker called "Glass Cannon"), and the idea we came up with was that a player like himself could contribute strongly to a guild effort by scouting and placing advance bases, and maintaining them for the main guild attacks.

[Typhon]

I understand the desire to not waste folks time in trying to find eachother for a good trashing.  That is where PvP-as-sport/battlegrounds comes to the rescue.

Then, there is world-RvR.  Creating a seige camp that must move slowly to the target, becoming an obvious target itself, just doesn't float my boat.  I'm right there with you on why you are creating that system, I think it does a decent job of addressing those elements that are undersireable (4am raids, taking undefended keeps, etc), I just don't like it themactically.  It's not clever enough to distract from what it really is - an attack timer.

I'd like to see a system where there are timers for the unimaginitive, and options for those willing to be more creative.  I also like cavalry.  I think speed, formation, geography and fortification should be a part of these (RvR or sport-PvP) games.

[Stephen Zepp]

I understand the desire to not waste folks time in trying to find eachother for a good trashing.  That is where PvP-as-sport/battlegrounds comes to the rescue.

Then, there is world-RvR.  Creating a seige camp that must move slowly to the target, becoming an obvious target itself, just doesn't float my boat.  I'm right there with you on why you are creating that system, I think it does a decent job of addressing those elements that are undersireable (4am raids, taking undefended keeps, etc), I just don't like it themactically.  It's not clever enough to distract from what it really is - an attack timer.

I'd like to see a system where there are timers for the unimaginitive, and options for those willing to be more creative.  I also like cavalry.  I think speed, formation, geography and fortification should be a part of these (RvR or sport-PvP) games.

I'm not quite getting how you think it's (exactly?) the same as "this attack is invulnerable until time XXX, when everyone shows up and the fight starts"--which is my definition of a timer at least.

The whole purpose of attack/respawn outposts in my design is that it's always vulnerable, needs to be placed strategically so it isn't discovered easily and can be developed, yet needs to be placed close enough to be a useful spawn/rally/resupply point for the attack.

Maybe we're talking two different things, but I'm not talking about invulnerable entities that move slowly myself--I'm talking about making small cities close to your enemy, which allow you quicker logisitical trails for an attack.

Even in SB with the true bane timers, this was a very useful tactic--make a small ToL or two near your main bases (or near your main attack points) to serve as respawn spots, and repair spots for an extended encounter--that's all I'm really talking about here, except that I didn't like the whole "some buildings are invulnerable, some aren't" part of ToL's in SB. I don't think anything should be invulnerable, just well entrenched.

[Typhon]

What is lumbering (or isn't) is how long it takes to establish a siege object.  For the moving siege camp 'establish' means 'move close enough to be brought to bear on an enemy encampment' (I guess will call this the siege caravan to differentiate?).  For the static siege camp 'establish' means 'build'.

I recognize that the static camp can be more variable in it's effect (different size camps have different sized effects), which gives a greater degree of options - such as feints (establish a bogus camp in a more easily discoverable location).  The camp seems a better solution.  I guess what I don't like about it is that I've never seen a game engine where there was so much landmass that anything was 'hidden'.  Especially near another encampment where people are going to obviously be more familiar with the terrain.

So in my head I end up struggling with what the timers look like with the siege camp - can a small camp be built quickly enough that it has a reasonable chance of being brought to bear before it's discovered?  Seems like to be a counter to the 4am attack, the answer is no, it can't be built quickly.  That makes it lumbering.  If it's lumbering, and your game world isn't very much larger then I can imagine, the camp will be discovered before it can be brought to bear, which means that the attackers will need to defend it... and we end up with the same 4am problem, except this time it's the attackers that have the problem.

You were right, I wasn't picking on HRose concept is essentially the same as the castle/village thing I was suggesting.  i.e., to extend your empire you need to conquer, then build.  That activity doesn't preclude pillaging, but pillaging doesn't extend your empire.

But I wasn't really picking on your concept either, I was just pointing out that an extreme view might consider it to be another "timer" (especially if the camp building activity is tedious)

[Stephen Zepp]

To give a perspective, I'm coming from the point of view that full on attacks on major cities would happen at the end of a reasonably long and protracted campaign. The defenders would know it was coming, and the attackers would be moving across territory over an extended period of time, with the majority of the fighting in the "no mans land" between the last area the attackers had secured/destroyed, and the next.

Think about warefare prior to WWI, and especially in the prussian era. There wasn't an end run around France to hit Spain while they weren't looking (from Germany I mean)--you would have to secure a decent logistical path through France to be able to get your siege capability to Spain. I can see from the short/tactical perspective this would fit your description of lumbering, but a full out war between two large, established guilds should take months in my opinion, with fighting pretty much every day of the week.

Sometimes it will go fast as the defenders realize they were over-stretched and have to consolidate--sometimes it will go slow as the attackers fail to properly secure/build logisitical lines and get pushed back, but it adds so many additional layers into the game environment that I think it's well worth it.

I can't describe how frustrating it was sometimes in Shadowbane to wake up to 4 banes on cities within the nation, simply because some ass was bored at 4 am and logged in a 6 pack of characters to tear down some walls and drop banes in the ruined sections. And I'm not talking outposts here, I'm talking primary cities within a nation that took months to get productive--and that type of instant 24 hour and your city is gone is what I'm trying to get rid of...

Now, 24 hours to lose a layer of outposts, and have your next layer of towns become vulnerable--that might make more sense if there are several layers of development to go through.

[Vinadil]

I think that there is a very simple solution to the random bane/attack thing.  I would love to see a Shadowbane server that tried it.  The basic idea is to remove the "summon" spell (or make it near usless with a 1 hour recast or something), and remove all the "tree hopping" and teleporting.  Perhaps you could leave runegates... but I am still not big on those unless you are not allowed to bring siege weapons through them (which would be near impossible for them to do since you can carry siege items in your pack.)

The best way that I see to encourage regional warfare is to do it like EVE, where travel from one side of the universe to the other is LONG and Dangerous.  A scout in SB who was able to use the gates could jump around and drop 15 banes in an evening if he wanted to, and setup siege equipment at each one to prep for an attacking force.

In any case, the war over boundary lines is impossible when players are able to just jump around the map at will.  And, if they HAVE to move in a straight line to the enemy, then the enemy has the chance to set up defenses along that line.

[Stephen Zepp]

I think that there is a very simple solution to the random bane/attack thing.  I would love to see a Shadowbane server that tried it.  The basic idea is to remove the "summon" spell (or make it near usless with a 1 hour recast or something), and remove all the "tree hopping" and teleporting.  Perhaps you could leave runegates... but I am still not big on those unless you are not allowed to bring siege weapons through them (which would be near impossible for them to do since you can carry siege items in your pack.)

The best way that I see to encourage regional warfare is to do it like EVE, where travel from one side of the universe to the other is LONG and Dangerous.  A scout in SB who was able to use the gates could jump around and drop 15 banes in an evening if he wanted to, and setup siege equipment at each one to prep for an attacking force.

In any case, the war over boundary lines is impossible when players are able to just jump around the map at will.  And, if they HAVE to move in a straight line to the enemy, then the enemy has the chance to set up defenses along that line.

But then you will have (many) players complain about useless time wasted moving from one place to the other, etc, etc. And in some ways, it is a valid complaint.

An added advantage of the "siege outpost" concept is that once it's developed, you could easily allow for a summoner's portal to be built there, etc. Allowing players to instant travel close to a decent place for combat, but not be summoned directly to the ToL of the enemy's capital as soon as they die.

[Vinadil]

I don't mind player build/player destroyable summon stones.  In fact I think the original concept of SB (where the siege tents were respawn centers) was not a bad one.  In that scenario the players have the ability to build their own transportation systems (many good ideas on this on the Darkfall website back from 2004) AND the players have the ability to cut off the "other sides" network.  My problem is when you can send one guy out to the enemy city (from ANYWHERE on the map) and within 30 minutes summon in a 200-man army.  That makes the whole concept of "territory" meaningless.

The other thing that will keep people from feeling that whole "the world is empty" thing is to... have more people on your server.  Granted, SB could not run more than 1,000 people before lagging to death, but in the early days of some of the servers there was a LOT of regional warfare on a near-constant basis.  The thing that makes the world feel empty is that... well the world is empty.

I don't like fixing low-server-population issues by allowing people to jump all over the map.  Either a) build a smaller world or b) build a quality game and fill your servers.  I think many times people try to use the "the world feels empty" or "I don't want to run for 30 minutes to find a fight" as a Cause.  Those are merely effects, symptoms if you will, of much deeper issues most of the time.

[DarkSign]

/sigh

I remember the first 200 vs. 150 seige on Dread. It was a beautiful thing full of carnage, death and sb.exe's.

[Stephen Zepp]

/sigh

I remember the first 200 vs. 150 seige on Dread. It was a beautiful thing full of carnage, death and sb.exe's.

Morale(s) of the story:

--player collision is a good thing, not bad, m'kay?
--video card drivers are not your friend
--OpenGL is great for cross platform, but can be rough on QA--nothing like having 80 different iterations of video card/hardware/driver combinations, and not covering even 30% of your user base.

[Vinadil]

What is the big issue with Collision Detection?  Does it just require too much processing both on the server and client side?  Or are there other, more technical, issues that keep people from using it?

[Typhon]

What is the big issue with Collision Detection?  Does it just require too much processing both on the server and client side?  Or are there other, more technical, issues that keep people from using it?

It's abuseable.  They had it in EQ, and folks would use it in lower guk to be gigantic douchebags (pull a room, then sit in the doorway at the entrance so that folks would get killed because they'd be unable to zone out).

[Stephen Zepp]

What is the big issue with Collision Detection?  Does it just require too much processing both on the server and client side?  Or are there other, more technical, issues that keep people from using it?

It's abuseable.  They had it in EQ, and folks would use it in lower guk to be gigantic douchebags (pull a room, then sit in the doorway at the entrance so that folks would get killed because they'd be unable to zone out).

Combination of both, but nowadays more on the abuse side.

The problem is, in a game like Shadowbane, the ability to abuse not having collision detection (stacking anyone?), and what that in turn does to your polycount per frame, player action density (nothing like 100 players all in immediate scope with highest priority changing animation states to shut down your networking, not to mention general server load) and just general game play (large armies should be spread out--it's one of the core reasons why focus fire is so powerful in a game like this, when 75 people can unload on one target at the same time).

In my perspective as both a player and a game developer, lack of player collision is a terrible game/engine mechanic second only to authoritative client side hit detection in how badly it screws up your game.

[Vinadil]

Well, everything is abuseable... but if you even made people "sticky" such that if you push against them you collided, but push long enough and you can get through... or just "Push" them once and they move, then you can get around that.  Of course, have a nie PvP game (like the Shadowbane referenced above) and I don't care if you stand in the door, I just kill you then move through.

Beyond the abuse possibilities, are their coding issues that make this less desirable?  From what I hear WAR is going to have a semi-collision system where friendly units are not collidable but enemies are the "sticky" I referred to above.  But, I don't know of many other games that have any sort of collision detection.  Well, EVE does, but it is a very different creature... but now that I mention it I wonder how they handle that, because at some points you CAN move through other ships whereas at other points you merely bounce off them.

[Stephen Zepp]

Well, everything is abuseable... but if you even made people "sticky" such that if you push against them you collided, but push long enough and you can get through... or just "Push" them once and they move, then you can get around that.  Of course, have a nie PvP game (like the Shadowbane referenced above) and I don't care if you stand in the door, I just kill you then move through.

Beyond the abuse possibilities, are their coding issues that make this less desirable?  From what I hear WAR is going to have a semi-collision system where friendly units are not collidable but enemies are the "sticky" I referred to above.  But, I don't know of many other games that have any sort of collision detection.  Well, EVE does, but it is a very different creature... but now that I mention it I wonder how they handle that, because at some points you CAN move through other ships whereas at other points you merely bounce off them.

From a pure engine perspective, yes, collision is expensive. And yes, if you want "perfect collision" (poly to poly for example, as opposed to bounding region vs bounding region) it can overload your servers quickly...but collision optimization is not only a pure technology solution, but it's also a gameplay solution as well. Worried about optimizing 100v100 bounding region collisions per physics tick? Don't design your game to put 100v100 in one bin at a time (a bin is part of most engine's top level collision optimization), and/or accept a less accurate and less expensive collision mechanism such as bounding cylinders.

But it's not rocket science, it's just good game design. Frame your scenes to preclude over-powered video card requirements. Build your mechanics with performance chokepoints in mind from the beginning.

And don't design from the perspective that just because you can put 300 high poly characters on screen at once all interacting directly, you should.

Hell, just think realistically--a 100 person army isn't all going to stand in a gate courtyard at once, so why let them?

[Vinadil]

I know that WAR has some sort of Collision (or at least reported to a while back), and Darkfall is claiming to have Full collision, anyone know if Age of Conan is?  Or, for that matter Pirates of the Burning Sea?  I cannot imagine a world where ships can sail through each other, but who knows these days.

[Typhon]

Just to be clear: I wasn't weighing in on whether I thought there should or shouldn't be collision detection, just saying why I thought game developers didn't bother adding it (although I wasn't very clear in doing that).  So here goes again with me trying to be clear.

From a devs perspective from two years ago - why would I want to go to the substantial effort of adding this to my game when bottom feeders in my game will just abuse it anyway?  I don't need the headache.

Nowadays I think most of the engines have it already baked in, so I don't think it's as much effort to add.  So player abuse is probably the only reason you wouldn't add it, but as Stephen pointed out, there's as much abuse without it as well.

Frankly I'd like to see it added to the game.  I'd also like to see world geometry make a difference in these game (high ground being important, formations being important, etc) and I think collision detection would be  big part of that.  But I'd also like to not get trapped in some doorway by some douchebag, so I'm thinkin that instances for PvE are here to stay.

[Stephen Zepp]

This is a personal pet peeve I completely admit, but I cannot for the life of me think of any "normal" game design where not having collision both makes sense and isn't a lazy man's solution.

I am of course blowing off things like "you are a ghost searching for xxx" style stuff, but EQ, SB, WoW, whatever--to me not having at least some form of all object collision system is like using a band aid on a severed artery...you just aren't thinking about the impact of your decision.

Planetside has a lot of systems that are a PITA, but even if they didn't do it all that well, they have full collision--and it's a fundamental aspect of tactical play. Only so many people you can fit on a set of stairs, and that makes sense. For those that haven't played, they have a relatively undeterminstic push/slide/climb over mechanic that alleviates most block griefing.

[CaptBewil]

Well, everything is abuseable... but if you even made people "sticky" such that if you push against them you collided, but push long enough and you can get through... or just "Push" them once and they move, then you can get around that.  Of course, have a nie PvP game (like the Shadowbane referenced above) and I don't care if you stand in the door, I just kill you then move through.

Beyond the abuse possibilities, are their coding issues that make this less desirable?  From what I hear WAR is going to have a semi-collision system where friendly units are not collidable but enemies are the "sticky" I referred to above.  But, I don't know of many other games that have any sort of collision detection.  Well, EVE does, but it is a very different creature... but now that I mention it I wonder how they handle that, because at some points you CAN move through other ships whereas at other points you merely bounce off them.

From a pure engine perspective, yes, collision is expensive. And yes, if you want "perfect collision" (poly to poly for example, as opposed to bounding region vs bounding region) it can overload your servers quickly...but collision optimization is not only a pure technology solution, but it's also a gameplay solution as well. Worried about optimizing 100v100 bounding region collisions per physics tick? Don't design your game to put 100v100 in one bin at a time (a bin is part of most engine's top level collision optimization), and/or accept a less accurate and less expensive collision mechanism such as bounding cylinders.

But it's not rocket science, it's just good game design. Frame your scenes to preclude over-powered video card requirements. Build your mechanics with performance chokepoints in mind from the beginning.

And don't design from the perspective that just because you can put 300 high poly characters on screen at once all interacting directly, you should.

Hell, just think realistically--a 100 person army isn't all going to stand in a gate courtyard at once, so why let them?

Ussualy collision can be toggled on and off.  It would seem to make more since to only toggle on collison within a certain radius from the player (20m would be sufficient i would think).  This should possible to be done far less expensively then leaving it on for everything in the scene.  I'll add this to my list of things to test...

[Stephen Zepp]

Well, everything is abuseable... but if you even made people "sticky" such that if you push against them you collided, but push long enough and you can get through... or just "Push" them once and they move, then you can get around that.  Of course, have a nie PvP game (like the Shadowbane referenced above) and I don't care if you stand in the door, I just kill you then move through.

Beyond the abuse possibilities, are their coding issues that make this less desirable?  From what I hear WAR is going to have a semi-collision system where friendly units are not collidable but enemies are the "sticky" I referred to above.  But, I don't know of many other games that have any sort of collision detection.  Well, EVE does, but it is a very different creature... but now that I mention it I wonder how they handle that, because at some points you CAN move through other ships whereas at other points you merely bounce off them.

From a pure engine perspective, yes, collision is expensive. And yes, if you want "perfect collision" (poly to poly for example, as opposed to bounding region vs bounding region) it can overload your servers quickly...but collision optimization is not only a pure technology solution, but it's also a gameplay solution as well. Worried about optimizing 100v100 bounding region collisions per physics tick? Don't design your game to put 100v100 in one bin at a time (a bin is part of most engine's top level collision optimization), and/or accept a less accurate and less expensive collision mechanism such as bounding cylinders.

But it's not rocket science, it's just good game design. Frame your scenes to preclude over-powered video card requirements. Build your mechanics with performance chokepoints in mind from the beginning.

And don't design from the perspective that just because you can put 300 high poly characters on screen at once all interacting directly, you should.

Hell, just think realistically--a 100 person army isn't all going to stand in a gate courtyard at once, so why let them?

Ussualy collision can be toggled on and off.  It would seem to make more since to only toggle on collison within a certain radius from the player (20m would be sufficient i would think).  This should possible to be done far less expensively then leaving it on for everything in the scene.  I'll add this to my list of things to test...

Actually do to the way that most collision optimization implementations work, this is already done. To try to briefly explain without going into lecture mode:

Picture your game world as a big old checkerboard. When objects move from place to place, where they move to can be abstracted out to a square on the board.

When it's time to do a collision check (assuming you follow all the standard rules for square assignment, otherwise known as "binning"), all your engine has to do for any particular object is to check the objects within it's own square. There are side cases and corner cases that are already part of the binning system which cover things like "but hey, he's in two bins at once" type stuff.

The problem lies in the fact that the code to control which bin(s) an object should be in has a performance cost, and therefore you can't just arbitrarily make your bins tiny. It's a trade off between iterating over a (sub)set of objects to check collision against, and how much it costs to move an object from bin to bin.

[CaptBewil]

Interesting.  I've never worked with a system that uses "binning".  I've heard of it before, but I'm not familier with any specific examples.  Can you give a couple?  The closest I've ever seen to something like that were Sector Based games.  The way they worked was that object properties were only loaded if the player was in that sector.  I think CrystalSpace3D might still use that type of system...

The system's I'm familier with load everything within the terrain culling distance.  Basically you just have one big sector (or Bin) that your game world is in, and then you establish a radius from that player from which the defferent systems become active (or scaled, as the case may be).  Rethinking my previous assessment, 1m per 1mph (1kph) of the max player speed should be sufficient, giving time for the server to update.  Projectile collision destruction/animation can be handled outside of that with surface "touch" messages...

[Stephen Zepp]

Interesting.  I've never worked with a system that uses "binning".  I've heard of it before, but I'm not familier with any specific examples.  Can you give a couple?  The closest I've ever seen to something like that were Sector Based games.  The way they worked was that object properties were only loaded if the player was in that sector.  I think CrystalSpace3D might still use that type of system...

The system's I'm familier with load everything within the terrain culling distance.  Basically you just have one big sector (or Bin) that your game world is in, and then you establish a radius from that player from which the defferent systems become active (or scaled, as the case may be).  Rethinking my previous assessment, 1m per 1mph (1kph) of the max player speed should be sufficient, giving time for the server to update.  Projectile collision destruction/animation can be handled outside of that with surface "touch" messages...

I'm describing the underlying optimization layers deep within an engine, not a system that a player (or even developer) routinely works with.

For example, you are absolutely correct--a developer would probably query for all objects within a certain distance of a point (in Torque, it's called a containerRadiusSearch, because our binning system is implemented via a Container class), but the root point is that without some form of optimization at this level (where locality can be somehow measured and invalid/un-needed collision checks avoided), you would have to check for collision from every object to every other object in your entire scene, every physics pulse. In Torque, that's 30 times per second--and that's ok when you have maybe 50-100 total objects, but is completely unworkable when you get much higher than that, hence the need for several different levels of optimizations.