f13.net

Longtime lurker, first time poster :)

In virtually all MMOGs in completed or in development that have territorial warfare (Eve, Shadowbane, Lineage, AoC and PotBS) there's a timer system involved that forces the attackers to give the defender notice about when they're going to attack. It is fairly annoying to show up with an army and have to say "ha ha, we have crushed all of your opposition so we will now go away and wait for an arbitrary timer to run out!" and it results in massive lag fest as both sides know exactly when to log in for a big battle.

The only alternative to this produced so far that I can think of is DAoC's system in which objectives can be captured by players at any time (I believe that something similar exists in Planetside and WoW). I remember being in a DAoC zerg that wandered around taking a handful of keeps, then going to bed and waking up to find out that all of the keeps we'd taken had been retaken while I was asleep. It made the whole thing feel rather pointless.

So the question is how to make a territorial warfare system without timers while making it much easier to hold territory than in DAoC and making 4 AM raids not be able to destroy any objective at will.

Well in the real world the reason that, say, Hitler didn't launch a 4 AM raid on New York is that armies are fairly slow and in most cases (with exceptions like Pearl Harbor) you can see an army coming. Of course you could make the world really really big and players really slow, but I don't think that people would must enjoy having their character on auto-run for 24 hours in order to be able to siege an enemy objective.

But how about this: let players zip around as normal but have the only things that are able to knock down/capture enemy-held objectives (siege engines, units of NPC soldiers, capital starships, dinosaurs, whatever) be only able to move incredibly slowly and only capable of being logged off at capturable/destroyable forts/castles/star bases/whatever. By really slow, I mean taking days to roll/fly/walk/whatever the damn things from one end of the map to the other.

That way if you want to go and knock down/capture enemy buildings/whatever you'd log on and take some siege engines out of one of your forts and start wheeling it towards one of your enemy's forts and once it got there it would start lobbing rocks at it until it was destroyed. The siege engines themselves would be fairly vulnerable, quite expensive and easy to destroy if unguarded, but the forts would take a good bit of bombardment to knock down/capture and have NPC-operated defenses of various sorts.

Pretty simple basic idea but here's what I think the tactical/strategic implications of it would be:

-People would tend to not base their siege engines in their capitol/heartland, instead they would base them in forts near the edges of their territory so that they'd able to get their siege engines into enemy territory quickly without having to lug them all the way from their own capitol to the border (thereby giving the enemy more notice that an attack is coming).

-If the siege engines were slow enough, people would tend not to attack the enemy heartland until they have a staging area inside the enemy's (former) borders. After all, if it takes a long time (exactly how slow the siege engines should be would have to be established after testing) to wheel your siege engines from your border to the enemy's heartland then it'd be almost impossible to protect the siege engines for that along since they enemy would have lots and lots of chances to attack, respawn and attack again while the siege engines are being wheeled towards their heartland. If you first captured a fort where siege engines could be logged out halfway between your (former) borders and the enemy's capitol then it would be much much easier to wheel the siege engines from there to the enemy's capitol while keeping them intact.

-4 AM raids wouldn’t be anywhere near as powerful, since if you started wheeling your siege engines towards the enemies at 4 AM, it wouldn’t be 4 AM anymore by the time they got there.

-It would be much to your advantage to knock down/capture forts that the enemy has along your border to keep the enemy from using them as staging areas for sieges of your own forts.

-It would be very difficult to launch sieges at enemies on the other side of the map since it would take so damn long to get your siege engines in place that a 4 AM raid that would destroy all of your siege engines before they got there would be pretty much inevitable.

-In order to keep your siege engines intact you'd have to defend them all the way over to the objective that you're sending them to destroy and then all the way back again, somewhere along the line they'd often get destroyed, thereby making attacking expensive.

-The defender would have a general strategic advantage.

-More wars would end in stalemates than in current MMOGs with territorial warfare.

-Sieging would become more tactically complex then "set a time and then show up with a big zerg." People would do things like feint with one bunch of siege engines and then attack elsewhere with a bunch of other ones, in order to make it easier to get sufficient siege engines to enemy forts intact, thereby making warfare more tactically complex and interesting.

-It would be harder to project power (because of the difficulty of wheeling siege engines to the other end of the world), which would make politics more local and fragmented.

-A surprise attack first strike would be potentially devastating, thereby making people more afraid of their neighbors backstabbing them and making alliances less stable.

I think that all of those tactical/strategic implications would be good things and would be ways of making a "Shadowbane without the suck" kind of game a lot of fun.

You've pretty much hit on the only major way to accomplish this in a persistent setting and avoid the whole "bane time" thing that Shadowbane had.

I've been thinking about the concept myself for a couple of years, and you're pretty spot on regarding both the good points and the bad ones! The biggest design concern really is making it feasible to have "defense in depth", meaning that you can't zoom to the final target and kill it at a moment's notice.

Whatever implementation strategy you go with, for a game to have both meaningful and "not time zone restricted" persistent territorial capture, it has to have multiple encounter possibilities over a decently long period of time.

NPC armies that are crafted and require supplies to maintain. Their march to the city would be the timer.  The defender can choose the time of the conflict by sending their army to meet them them along the way or except the attackers time keep the army close to defend at the attacker's choice.  Of course all this would imperfect with unit composition, terrain, supplies and morale impacting army movement and both sides can do stuff to slow/weaken the opposing force before the main battles begin.

The answer is really supply logistics but no one wants to tackle that because it is not fun.

If you have to take base A to take base B so that you can protect your supply lines for the attack on base C which is the one you really wanted to attack because it screws up the other guys planned logistics trail for his probable attack on base D you now have to worry about defense in depth and no one can just 'win'.

Good luck implementing it or making it fun to play the first dozen or so times.  You can go look at Gary Grigsby's War in the Pacific from Matrix games if you want to see the concept done well for a two player game.  Of course, games of WitP can take 3 or more real life years to play...

One of the issues I see with this would be the caretaking involved in babysitting a siege engine all the way to the target, and possibly back. Having to actually walk along with a catapult wagon would be just as boring as waiting for a timer, most of the time. Worse, you now have to deal with catassing and setting up round-the-clock watches for the damn thing.

A patch for this might be to have the siege engines be difficult to kill while en-route and then vulnerable while approaching or bombarding the target. This alleviates the need to actually have to babysit the thing - merely having defenders "on call" would work and alleviate the tedium somewhat.

a neat mix, eye-em-oh, of supply logistics and gameplay mechanics is found in Rise of Nations with unit health decay when in opposing territory (if the opposing faction has researched it)

you could apply a similar mechanic (I never liked health decay) to the siege device in lieu of a big movement speed decrease, simultaneously encouraging outpost captures along the path to slow down/pause rate of decay

it'd enable the freedom to ignore supply logistics if you really wanted to, but increase difficulty in proportion with that convenience. taking a siege device from your border all the way to the heart of the enemy would be doable, but likely a huge waste of resources as your bringer of fortressy death would arrive less "Juggernaut of Doom" and more "We Replaced The Wheels With Peasant Corpses, Do You Have A Carpenter Nearby"

Well the other way would be to build up a complete set of strategy game style mechanics, but that would be harder.

I think that the best way of doing that would be to making it as difficult as possible to launch an attack on an objective that's far from your staging areas/borders. That way to get at an enemy capitol you'd need to push back the enemy's borders and establish staging areas near their capitol first, which would make defenses in depth useful.

Right, that would basically be taking my siege engine concept and taking it to the next logical step and would serve the same basic purpose. If you made the NPC armies slow, vulnerable to 4 AM raids while outside their borders (and not too vulnerable to 4 AM raids inside their own borders) and need some kind of logistical support you'd have a great basis for a strategy MMOG, which would be a great thing for a DIKU-infested genre.

But the twist would be that they can change directions, feint and retreat, which simple timers can't. And, like you said, they can be counter-attacked before they reach their target, giving defenders a much-needed advantage.

Right, and fun has got to trump realism. I don't think that it would be too bad if the NPCs did all of the transportation (nobody wants to be a virtual porter) and the PCs raided each other's logistic networks and try to defend their own networks against raiders.

That is a problem. At least in theory the solution would be that people would launch attacks on nearby objectives (enemy border forts etc.) to reduce the amount of baby-sitting going on, hopefully the basic game mechanics would penalize people who do too much boring babysitting by making long periods of babysitting make the expensive siege engines vulernable to raids.

Now that's what I'd be very worried about. Never ever underestimate the persistence of cat-assers. Maybe a potential solution solution to this would be putting in kamikazi mechanics. That way if the cat-assers launch a long-distance attack straight at your capitol from the other side of the map, even if they're cat-assy enough to mount an effective around the clock guard on the siege engines you could have your guild launch constant suicide attacks on the siege engines that would take them down one or two at a time, thereby not leaving enough cat-ass siege weapons left by the time they got to their target. This would encourage short-range operations since if you attack a nearby enemy border fort instead of their capitol there won't be enough time for suicide attacks to take much of a toll before they get there.

That could work, my concern with that would be is that it wouldn't give defenders enough of an advantage, which would lead to massive alliances predominating more than I would like. It would also make it possible to launch an attack directly at the enemy capitol without having to deal with their border defenses, which would make it possible to have your capitol destroyed in the first siege of the war. But maybe if you could give defenders an advantage in a different way like giving capturable objectives shit-loads of powerful NPC guards.

Sometimes similar happens in www.battlemaser.org (interesting free MMOG with a strong strategy element) in which the NPC armies get big morale penalties when outside their borders (including in the territory of allies) that and making it only possible to raise new NPC armies in one's capitol and making NPC armies fairly slow make it very hard to operate large empires/alliances effectively, which makes it pretty much the only multiplayer strategy game I've seen that has lots of localized in-fighting rather than a handful of massive alliances. This makes it a good source of inspiration for strategy MMOGs despite the very simplistic gameplay.

That could work. The only issue if is you have the siege engines be fast enough, even with big health/effectiveness penalties when operating outside one's borders, it wouldn't stop 4 AM raids. It wouldn't matter how weakened the juggernaut of doom is if it arrives at the enemy capitol when all of the enemy are asleep.

Having Bruce flashbacks. Send help.

The following jumps out:

This (babysitting siege weaponry transporting overland) was demonstrably not fun in Shadowbane and violates the notion that folks should be able to log into the game and start having fun with their friends in 10 minutes or less.  I put up with quite a few 3-4am 1 man 8 account siege raids in Shadowbane and even paved 45 buildings in 60 minutes with a crew of siege barbarians wiping out literally months of work for The Other Guy (TM), so had incentive to prevent such shenanigans from continuing or spreading.  Leaving a physical resource vulnerable in the field usually results in a requirement of 24-7 overwatch on that resource because the time-in-transit becomes such a valuable resource in itself.

My observation, was that travel to the point of conflict was too easy when that point was deep within enemy territory.  Summon should work to the border of your territory, advancing into enemy territory should be limited by desire to keep pushing on, but extending your territory waits on checking off control of the border regions.  Being able to summon past the front negated any meaning to territory in Shadowbane aside from the land under your actual city itself.  The 'front' was meaningless so every fight became a desperate fight for your guild's survival.  Eventually the Mine system was implemented which provided a remote thing to fight over that wasn't your entire guild's existence.  That helped a bit, but summoning still meant territory was largely irrelevant.

bbcode is hard, apparently

The supply train progress being devolved to a glorified 'bane' rather than an actual gameplay sink came to my mind as well.

I've been playing Romance of the Three Kingdoms lately again and inevitably considering how an online version of it could work, and the supply train topic immediately made it come to mind. Specifically in reference to Rot3K, consider if the area of 2 enemy cities are split into 3 sectors. City, Field, City. Getting siege to the enemy city requires Siege Production, Siege Transport. When the first starts, the enemy cities gets a warning (let's assume a Scout system of whatever sort is in place). They then have X days to respond (somehow; assume it's fair). Then once done, it prepares to enter Transport Mode in the Field. During that time, the enemy again can respond by entering the Field by starting a Skirmish or something. But if they don't, the Siege transport is a success and it slowly and safely moves to the enemy city (or the war camp near it), serving as that eluded glorified 'bane'.

I describe this carefully since it has a lot of terms which may be perceived as artificially controlling and obviously the topic is about a more realistic and uncontrolled system. But break down some of those terms and consider it basically just as Siege Production and Siege Transport. During each you have a chance to officially respond--Open War, if you will--and that gives you full freedom to decimate either project.

But if you don't, each project receives a safeguard of some sort. Exactly the "glorified bane" that was referred to; a nearly unbeatable supply train crossing the land that doesn't fully need a babysitter. But even though the chance to wage Open War against it has passed, you could still wage... Guerrilla War, let's say for a lack of a more creative term, and do minimal damage do it - important for not only some sake of defense yet, but more importantly that sense of realism which an invincible "glorified bane" moving across the land would certainly hurt.

There's still a lot of systems in place for the sentiment of trying to break down as many of those as possible. It's a form of moderation nonetheless though, which in itself may be the key; not to streamline such warfare to be more realistic for the average gamer, but rather to also moderation its occurrence so slight excessiveness becomes more tolerable. In the very least, it's constructive early A.M. brainstorming all the same.

I think that SB's original design of limited invulnerability that depended on your Base size (TOL rank etc.) and that did NOT include walls (or barracks I would say) was a good one.

The issue really becomes this... Everyone LOVES taking part in a well-timed raid that catches their enemy off-guard.  Heck, it is how those of us who play outside of the Mega-guilds can ever compete.  But, nobody enjoys logging on to find their city has been demolished over night by some random group of whoevers.

I have been part of both groups, and the main things that will help the situation in my mind are:

1) No instant transport of siege equipment.  It does not have to be "slow", just normal speed will be enough really.  As long as you cannot toss a few catapults into your pack and get summoned to the front lines then I am fine with that.

2) Make the "Main City" invulnerable (or at least most of it) until the outer cities are captured.  This is basically the EVE model (as I understand it) in which you have to have a controlling presence in the sector before you can siege the Capital.  If we looked at SB it would mean placing multiple resource Mines in one Territory.  Then the attackers would have to take a majority of those mines (or forts) and hold them for a full 24 hours before they could attack the main city.  After that 24 hours there is no more time buffer... the city is completely open.

The biggest goal, really, is to have targets that are Always vulnerable but are not Too devastating when lost.  I never really minded losing a city in SB... lost tons, killed tons... it was part of the game.  But, it never failed that members would disappear for a week, month, or forever when a city was lost.  I doubt that would have happened over losing a frontier fort.

3) Only allow people able to defend a city 24/7 to own one.  One of the problems I see with many siege-type games is everyone thinks they "deserve" to own a city.  This just is not true... anywhere.  It takes real work and organization to establish something that big, and if you cannot handle it, then you don't deserve to have it.  Basically this would mean Fewer cities with Larger populations.  Inevitable that Larger population will contain people from different schedules/timezones.  This means you have a greater chance of having people online 24/7... putting you in a great place to defend your city at all times.

In SB (Corruption server for those who remember) I got to lead a multinational guild of equal parts USA/Germany/France/Italy/Russia.  It was probably the most fun I had in SB as there were ALWAYS people on.  If you want to play the territory-control game... you need to be able to project your guild power at any time of day.  I suppose Dev's can try to create nifty ways to let people play in that realm who are not willing/able to do what it takes to compete... but really the players have the ability to do that also.

this is the whole timer issue though--you could have large attacking forces wiping out all opposition but the main city and then having to guard the place for a day, taking leisurely walks to the edge of camp to piss on suspension of disbelief

or have defenders stalemate by taking back the stuff when the attackers are doing things like having a life

unless you had huge, rigid factions with a huge main city full of people from different time-zones that could continue to fight after others went to bed or whatever, but outside of chance it'd only be attainable with troops of AI running around (oh man, or a big enforcer demon with a sword the size of several small houses! yes! totally cool!)

forcing players to do things or wait for something dictated by policy out of their hands is old-school, and not in the remember-my-awesome-Contra-score-best-summer-ever way

I dunno!

> 3) Only allow people able to defend a city 24/7 to own one. 
Talk about a niche market.

Tactical surprise is good, but strategic surprise shouldn't have a place in these games.  The problem with 4am raids, beside being antithetical to any sort of causal gaming, is it is players playing around each other.  It's really not PvP if guilds are just attacking each other's empty cities.

Seige SHOULD be a pain in the ass. It's hard. Seige equipment is build for a specific assault, and if anybody is planning a seige on your faction's city you get some onscreen warning to that effect. This plan and buildup takes a mandatory 12 hours, say, but nobody actually needs to be online or do anything during that period. Nothing can disrupt it. When those 12 hours end, the seige equipment begins moving from your base to the enemy city and everybody had better be there to protect it. It can move relatively fast and is immortal so long as anybody of its faction is "near" it. Once it reaches the enemy city its immortality goes away and seige begins.

The buildup period requires the seige engine materiels and expenses, and can only be executed by high ranking members of a faction. Those materiels are gone whether anybody shows up to babysit the engine or not. Only one seige per faction. Choose wisely.

Like surprise attacks? I recommend Raiding! It doesn't require a declaration (other than that your factions must not be friendly) or any special cash investment.

Cities cost a lot to create, but once created they make resources and cash rather than requiring them. If raiders can form a big enough group to handle attacks by the guards, they can go in and steal money and resources. Diminishing returns over time that have nothing to do with the amount of money and resources available. Back off and let the city respawn resources before you try again. Set those returns such that it's impossible to completely drain a city of resources in less than 24 hours. Even a drained city isn't destroyed, it just isn't making money for the folks who control it.

I also like permanent, capturable, developer-placed forts and ruins. Give them special abilities too... temporary buffs, maybe, a healer or a shop.There should be an array of them throughout the land. If you control any the forts within the "territory" of your city, your guards are tougher, buildings and walls are hardier against seige, and raiding rewards are lower.

I also agree that territory ought to prevent non-friendly teleportation within it.

I think one aspect of this will work against territorial combat - the buffs for controlling more terrain features (forts, mines, etc).  As one side gets beaten down they have to defend less land and should therefore be harder to continue to beat down, until such time as the aggressor has gotten so big they have trouble continuing to advance or hold their now larger borders.  By making the stronger parties continue to get stronger the bigger they get, you make it unlikely for late adopters or new powers to arise in a game in progress.

I imagined terrain features that were relatively easy to capture and hard to hold. They're just there to provide options. Also the buffs are given by something at the feature.. praying at a shrine or talking to an NPC or, I dunno, stepping in a pond. Area-wide buffs would only alter the defensive strength of cities, players have to actually visit the site on a regular basis for personal buffs. Realistically those buffs could be available no matter who "controls" the site, assuming you can get close enough to activate them... in which case cities would be placed near as many forts as possible, but controlling them would only be a hedge against losing the power they bestow. It would be handy to be near towers with spiffy buffs, but that's just one more place you have to care about defending if the city comes under attack.

More generally, "the rich get richer" is a problem with any of these large-scale conflict games... and probably an important topic for its own thread.

The thing is... history of games where the Defender gets to decide when combat happens shows that people STILL play around each other.  The biggest example is when you have East vs West (a rather usual setup in SB).  Each side will set the defense to their Prime Time... which is obviously not a prime time for the other side.

The same thing will happen if the Attackers sets off some "set-time" attack.

One of the things that used to be very fun in SB was going to a person's town... any time... and just tearing stuff down.  Generally you would not even get through 1 wall before the guild started recalling to their town and calling in reinforcements to kill you.  The point of sieging was to Force PvP... not avoid it.  As long as cities are invulnerable then the players just go out and about and don't care if you are sitting there waiting to kill them.  But, you start tearing down some of their stuff and they all run back and fight.

Now, I would be fine if you could steal resources... say there are regularly spawning merchants/harvesters or some such... or that each Guard Respawn costs the defending guild resources... then your attack is actually Hurting them in some way besides just random inconvenience.

As a person who comes from a smaller guild (30-50 people), I like games that still allow Guerilla style warfare.  If we have to we can get together 100 people at 4 am to go bash town a city... but that is not fun or realistic on a daily basis.  But, I would still like to be able to take my 5-man team and go cause some Real damage to the other side.

Moving the conflict Away from city-sieges is probably a good way to go.  That makes them more rare, more epic in scope (because of the logistics involved).  If we keep the conflict around resources and trade then we are basically "destroying" future earning rather than past development.  It is still significant but it does not hurt so much for the Defender.

Yes.

The idea of a small team of raiders roping over the walls of a city, killing guards and stealing gold in the off hours sounds an awful lot like player-created content. Better yet if raiding shows up as cosmetic damage... busted windows, broken furniture, and burned thatch roofs. Show up in the morning and check the city: "Aw damn, raiders." Maybe the guards know what faction they were (...and better still if there's a chance that sort of information can be faked by the raiders).

The goal isn't to destroy what people love and care about, it's to initiate conflict in which the players have a stake. If the cities require resources to upgrade, then raiding them for loot slows their growth and pisses their guardians off. It doesn't require heavy planning and it still has rewards for the raider. Even landless guilds could enjoy it.

If siege is expensive, but knocks out upgrades before it destroys things, then a partially successful siege would feel positive to both sides. The attacks would still feel productive because it would knock back the city's progress, and the defenders would feel productive because they'd know that had successfully protected their city and couldn't be attacked by that faction again without some delay (plus they spent a mint on that siege and WE'RE STILL HERE!). Even if the siege only knocks their walls down three upgrades and drops a tower... hey, three upgrades and a tower! Woot.

If the damage took more than 24 hours to repair then a siege could theoretically take place in multiple waves over multiple days and start to feel like a real siege... exhausting and demoralizing to both sides. Kinda like a raid endgame. Hmm.

If only one siege at a time is allowed per city, large factions will form mini factions specifically designed to harmlessly siege them over and over. If multiple sieges are available then decoy sieges might be set up, with the faction just concentrating on whichever city was looking most promising. Siege should be absolutely be a BIG THING... but multiple siege engine setups should probably have pretty steep diminishing returns or, again, mini-factions will ally with large factions specifically to crush opposition with piles of siege engines. More fun for all involved if they can only donate troops.

Blahblahblah. We've had a better Everquest, now I want a better DAoC dammit.

[Edit: Spelling, grammar, He-Goal and the Masters of the Universe]

Man, I still need to write that essay on "Positive vs Negative" conflict.

Pxib (and others) are correct--the siege mechanic was designed to give positive value to PvP--instead of ganking vs being ganked, it was "attack their homes" vs "defend our homes".

The problem was, they made it too invested--basically one loss and you were done.

I got a lot of shit for my time on the Fear server as a nation leader--forcing conflicts, declaring territories (and defending them), forcing people to sub to my nation, etc...but for every "you're an ass dude" tell I got, I'd get people that understood that my goal was to generate positive conflict, and force the gankers/griefers to at least meet in a middle ground of why we fought--and it was a PvP game after all, so if you didn't want to fight, go away.

Or have about 10-15 NPC guards escort the wagon.  That way, it would at least be somewhat protected from small group player attacks.  Maybe the players for that team has a wagon location indicator on a map so they can keep track of where it is along with an ETA.  This would allow players that are on to check-up on the wagon from time to time to help make sure it gets to where it's going.

Same could apply with Supply movements between forts or whatever...

Going to try to briefly explain the (half baked) idea I've been playing around with since I read the first post.  There are keeps and villages (which the keeps "keep").  The keep is on a hill, nearby to the village.  You can think of them as a combined entity.

Villages have villagers which provide; revenue, defenders, a scouting network, a marketplace and other stuff (half baked!).  Villagers have faction.  Killing villagers to take keeps will negatively impact your faction.  Villages will be less beneficial to an invading force which hasn't done anything to offset this penalty - either proactively or retroactively.  Examples include tricking someone else into killing the villagers, spreading plague to the villagers, infiltrating and subverting the villagers, etc.

Keeps are expensive.  You need a healthy village to offset the expense drain the the keep represents.  Creating a healthy village requires some interaction with the village (selling ill-gotten loot there, often at prices not so favorable to the hero/guild/realm)

I'm going on too long.  The idea is that having a village change hands too frequently is good for no one because then that faction/that village becomes worth less and less to the taker.  Riding into the heart of another country and sacking a village is possible, but if you do it too often you get 100% KOS turnout whenever you ride into that faction's area (in general I'd think that villagers would put forth about a 33% of the population defense response - which should be a significant obstacle to overcome).

Therefore - attackers don't attack unless they think they can secure the village/area because paying to upkeep the keep without the assistance of the village is a significant drain on their guild's economy (and not upkeeping the keep + sacking the village = really pissed off villagers).

I know we all see "faction" and think, fuck no! not another faction grind!  I'd really like to see things that build faction be things that player want to do anyway (i.e. loot dungeons, sell stuff to someone - the choice of who you sell to involves who you get the best rates from + who's faction you need to be boosted).  I'd also like to see religion played up a bit more in villages (e.g. building a church in a village gives access to healing, and really pleases the villagers).

Why I'm pushing this idea is because it seems like it could finally add a way for these games to have/support a spy/intelligence network (subverting the villagers, killing off the runners leaving one village to spread news of an advancing army, etc).

I agree it does seem fairly complicated.

I am a fan of having this kind of MMO/RTS merger... I have just never seen it happen.  I guess it might be worth my time to test out Dreamlords or whatever game tried to do the RTS/MMO thing, but the reviews made me shy away from it.  I don't know if it was their particular design or the nature of the beast that makes the player base so small.

I bring up the RTS thing because every idea here seems to involve intelligent, controllable NPC units that are owned/created by the players and continue to work in the world when the players log off.

Is there a game out right now that has such a thing?  I remember hoping years ago that WoW would be just that... a MMO version of the RTS in which I got to send off my human woodcutter and go kill horde peons all in an Epic battle of moving territory control lines.  But, for those who missed it... that is not how the game turned out.

What is it about the combination of RTS (NPC units that actually DO something in game) and MMO that is so difficult?

Time of Defiance, Darkspace, and Savage are three MMO/RTS style hybrids.

Time of Defiance is a little like VGA Planets except you build RTS style on floating islands. The games reset every X time (or maybe when someone owns everything). The problem is that one person usually streamrolls everyone else in the game.

Darkspace is another space RTS style game. You can build up planets and then fly your space ship around and battle it out with other factions. The problem is the MMO part of it is all locked up. Everyone already has so much shit you can't break into it. You're stuck fighting it out in 64 player arena's that regularly reset.

Savage is an RTS/FPS hybrid. One person is the RTS commander who builds things and tells people what to do. Everyone else runs around and fights off opposing faction. You can also mine and help your buildings build faster. You gain levels which have minimal benefits but the levels are lost after the game ends. Savage 2 is suppost to have persistent levels and items between RTS games.


That is dynamic content. Developers are afraid of dynamic content. This leads to the main issue which is someone ganking your shit while you're offline.

The thing is... dynamic content does not have to mean PvP.  Though I generally have only looked at PvP games since EQ, I was very interested in a game I want to call "Myth" or some such that was being tested a couple years ago.  It basically sounded like a huge PvE epic where the players were battling against a RTS style enemy that would conquer/build/siege the lands unless the PC players fought against them and took over the land.

Granted, it seems TR is trying to do this now... will be interesting to me if they can pull off truly dynamic content or if they will merely give the illusion of it while pushing their own storyline.

Sounds like something Horizons was suppose to have. See this thread (http://forums.f13.net/index.php?topic=5394.0).

(Historical note: for those that may remember, when I joined this forum it was as a game designer, not a GG employee, at the time working on exactly this type of hybrid game)

One of the biggest technical challenges I found actually was the sheer overhead of the AI for having those units do things when the player wasn't online. Pulling guards in shadowbane, the whole concept of pulling in general taught us that if you rely on "off line defense" that is performed by NPC's, they need to be able to process well, and that AI takes a lot of server CPU processing power.

If you allow every single user to control NPC's, then you are basically talking about an AI process for each of those players--or an incredibly well integrated external AI package, which is very very expensive.

The other factor is simply making the hybridization of vastly different genres work well--from economy time scales (RTS games make thousands of "gold" an hour--what does that do to your FPS/RPG item economy, etc) to play time scales (RTS games are over in 3-60 mins, RPG games expect much longer play periods, and endless ones), to all sorts of other issues.

It's not impossible, and I honestly wish I had the time to get back to working on my prototype, but unfortunately that's not gonna happen in the near future :(

This is the part I can't figure out. MMOGs are already full of NPCs. How does making them do something different take more CPU? I can see if maybe they all have to run A* vs. cheating by just moving towards the player that could be CPU intensive. However, Unreal, Quake, and Battlefront all seem to run fine with say 64 FPS bots. You can have X number of AI machines connect to the server just like a normal player client would connect (without the graphics obviously) to offload the AI onto as many additional machines as you need.

Most of those NPCs operate on the, Am I Mad At X? form of AI, where X is determined to be the last guy who hurt me (by entering aggro range or reaching the top of aggro gain).  Pretty simple stuff that doesn't do well to defend a city at 4am as the guards happily chase players around the desert instead of protecting their home city.  That AI is dumb for defense, it doesn't represent coordinated action, and doesn't provide much obstacle to a player who wants to exploit it.  Do FPS bots have to worry about coordinated attacks?  Do they have decide against attacking into massed blaster fire?  Do they stun the healers and target the dps next?  Do they protect their property or do they just die and respawn and go again?

Maybe we shouldn't count on our NPC defenders to defend in the usual way...  Instead of trying to kill transgressors, maybe they should just try to hide from transgressors and so long as they exist their protected assets are immune?  It is pretty much the same problem (same boundary and FOF identification issues) but instead of trying to directly play into the aggressors attack they are attempting to avoid it.  If the players initiated the assault there is a good chance the NPC rushing out to meet it is a bad idea, denying the decisive confrontation may be a better road to buying time, which is all NPC defenders can be expected to provide anyway.

My Shadowbane capital had ~200 NPC guards and it was still impossible to defend when the tower archers weren't forcing the other side to sb.exe ad naseum.  There were a few hundred cities per server.  The NPC load, even with poor AI, begins to weigh on the hardware.  There will always be more (NPCs, Players, objects as the world ages) we need a solution that scales resource demands reasonably.  Better AI over an arbitrary number of NPCs isn't something that scales.

AI is a red herring.

For whatever reasons, even if it's just numbers and respawn rate, the NPC defense will either be effective or ineffective. Players and game designers lose either way. If the NPCs are effective against a coordinated raid all by themselves, then once players join the defense they'll be nigh impossible to beat. If the NPCs are ineffective against a coordinated raid, then the city can get stomped as soon as the players leave. Even if the NPCs are tuned such that they can reliably hold off a coordinated raid for six hours before they fall, then the attackers will be pissed because they've got to invest six hours of constant attacking or the defenders will be pissed because their player defense force can only take six hour breaks.

Somebody's unhappy either way. Worse than unhappy: They feel cheated.

A six hour seige isn't fun... it's work. Rather than figuring out how to produce the perfect six hour seige somebody needs to figure out how to break up a war into five exciting (but individually optional) hour-long skirmishes over the course of a week with an epic two hour battle scheduled on the weekend... which is, itself, only one step in the larger war AT THE END OF WHICH there's a chance somebody's city gets destroyed, or more terrifying still, captured! NPCs may play roles in that action, but they cannot be important ones. Defenders must feel their skill is critical in the defense, and attacks must feel their success depends on the same.

Man am I glad I found this forum. RPGCodexers loathe debating MMOs. Anyway, this is exactly what Ive been designing myself. The game being post-apocalyptic, RTS style resources would be gathered by guilds who have SB cities, each with buildings conferring different benefits as well as uses. Not only would the cities themselves be seiged, but the resource gathering could be attacked and the resources stolen. As was said before, this means you dont lose your entire city and have a focus for small to medium-group battles on a regular basis.

Savage was a great game with the way Commander mode (not surprised Battlefield2 stole the idea) let you garner your troops to a point and give them a task. I'd love to give that ability to a group leader (but imagine groups are larger like 15 people or so) to earmark destinations with waypoints and flanking maneuvers.

Furthermore, for every task you followed, you'd get guild points which might decide who got promoted or whether you got cool weapons from the guild armory.

NPC guards should have skill levels comparable to regular players which could be upgraded along with weapons and armor. Of course done in different styles (wasteland rough, corporate military etc.).

Speaking of NPCs...why not have randomly found NPC towns that you could sub, ally, or conquer, upgrading their weapons and armor and having them join in the fight on your side?

Great thread.

Be pedantic there pxib--you're talking about combat AI--in a persistent RTS or RTS/Hybrid, you still have "orders" that have to be processed, as simple as they may (or may not) be. And therefore, you need AI to process them.

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 ;)

I't doable--in fact, I have the design pretty much all laid out with prototypes for some of the stuff working, but it's not trivial by any means.

It is interesting how quickly a talk about AI and Dynamic worlds degenerates into "will the guards be able to protect me while I am gone?"

I am much more interested in a group of goblins that sieges my city than I am at how well my NPC guards defend it.  The Goblins give me something to do while I AM online... the guards just try to help me out while I am not.

It seems that the basic RTS "mindset" for the AI is as follows:

1) Game created: You are on Team A.

2) You have resources X, Y, Z... build A, B, C in that order.  Build unit 1, 2, 3 in that order.  Send out scouts.  Locate the enemy.  Send Groups 1a-2c to attack... yada yada build your base while attacking theirs.

The way you make the AI "harder" CAN be to make them smarter (see Galactic Civ 2... nice AI there), or just to give them unfair amounts of resources.  I am cool with the unfair resources if that is all we can do, but we SHOULD be able to do it.

The economy/time thing seems to be just a matter of playing with the spreadsheets.  There will be a point where the NPC units that "gather" are not worth the Resources it takes to produce them either because they a) gather too slowly or b) die too easily... or some mix of the two.  So, you find that point, let them gather just slightly More, and test it out again.

In that type of game I would find a quest that says, "Go and kill 10 Orc Peon Woodchoppers and return" instead of "Go kill 10 wild bears and return".  And, the woodchoppers that die would eventually lead to other things happening in the "enemy" camp... say walls falling down due to disrepair, or even entire buildings falling down.  Put in the WoW world that would mean the Horde no longer has access to certain vendors or quests until they protect their woodchoppers or go chop wood themselves.  This causes other problems... but most of those come from the level/class/equipment-design of the game (IE one level 70 character could solo-siege Tarren Mill), not with dynamic content.

....and despite all that complexity and hard work, I still believe it's a waste. Even if players could individually alter each NPC's AI to the point that fruit merchants fight like bots in an FPS, those bots either win or lose. They do so when players are not around, and either the attacker or the defender feels cheated out of a fair fight. Coming online to find your city destroyed sucks... and it probably sucks even more if you put a lot of effort into programming a defense. Discovering that an offline defense is impregnible sucks, too. It's like running into an unwinnable PvE quest... except in this case it may be literally unwinnable, because the defending player doesn't care whether or not you love the game, only whether or not her city is standing tomorrow morning.

Could commandable units add a lot to a MMOG? Absolutely. I also like base-dependent "power armor" and "gun turrets" (substitute whatever genre-appropriate nouns you like). They are not the solution to the "Territorial Warfare Without Timers" problem. Honestly, the attacker hasn't got as much to worry about... an unbreachable defense will be seen as a game-breaking bug. What's the point of PvP if you can't win? With a breachable defense, tjem. city seige becomes no more than a higher stakes version of the "you killed me while I was afk" or "you shot me while I was lagged" or, more fundamentally, that elementary schoolyard favorite: "I wasn't ready!"

The higher the stakes the more likely the losing player gives up and quits, and he feels cheated no matter how capably his assets defended themselves while he wasn't in direct control. Economic reality, gritty nethers or no.
I agree that eliminating PvP would be a great solution to this problem. The PvE goblin AI could be designed to manage the odds in the player's favor. An empire might lose a few important cities, but will defend its capitol. A faction with a single fort might just lose a few walls and important buildings. Good AI, from Checkers to Hearts to Half Life 2, is just a puzzle to be solved. It puts up a good fight and then loses so the player can feel the thrill of victory and continue to love the game. Although player factions should want the same thing -- the game won't be any fun if they scare away all their opponents -- basic game theory (http://en.wikipedia.org/wiki/Prisoner's_dilemma) predicts that they won't think that through.

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.  In NWN if you create a module and want all the NPC Guards to take out torches at night and put them away at dawn an easy way is to put it in the heartbeat script for that NPC.  This won't scale and leads to unpredictable behavior as soon as you have a few NPCs reaching for their torches.  A better solution was to put a single timing object in the world for the day/night cycle and have it run through a callback list whenever this single object identifies a state (day/night) change.  Then each NPC only runs code/script when told to by the central timing object, instead of all the time checking to see if it should be doing anything different.  Of course, if the callback list, or the activated script gets a bit long your game can stutter at the update.  I think you could see this vendor stutter in Shadowbane if you were in a big automated production city where all the vendors were completing at the same time (i.e. the ring/jewelry production facility of a particularly large merchant city).  Staggering the callback execution only works so much to spread the load, as would creating a seperate timing object for each class of NPC actor (which is again just another way of staggering the loads). 

So at the end of the day you really want to avoid putting anything on the individual NPC instance that doesn't absolutely need to be there.  e.g. the crafting interface just connects this particular crafter's inventory record to the global craft queue and at the appropriate time the global entity will fire the callback, but instead of asking the NPC to actually produce now it will tell the NPC what it produced (by calling the producer itself).  The callback producer builds a queue of inventory addresses with production parameters to generate the actual items asynchronously.

If you are willing to break the instant feedback of independent timers by NPC (independant NPC timers were visible in SB) then you don't need a controller per Player (or per NPC) but one per class of NPC.  "Oh, you want a Hammer of +4 Lolz?  Well I'm not starting it until I finish my lunch."  The NPC drops that work into the queue for the next timed callback and the player gets to micromanage only to within ProductionTime+1 timing segment for that NPC type.

Funny, how a thread on territorial warfare without timers has turned towards putting timers on AI. 


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.

The Monster Play in LOTRO has a lot of what we're talking about. It basically has DAOC battlegrounds where you have a zone with a bunch of different keeps in it. The keeps can be captured by the freeps (players) or the creeps (players as monsters). The keeps are mostly defended by NPCs. The freeps and creeps come in and beef up the NPC defenders. If an attacking side kills the keep captain they take over the keep. I assume a freep attack on a creep keep is a lot like a Raid.

There are also camps of freep NPCs, creep NPCs, and neutral NPCs around the map so if there is no other players to fight you can still kill things. The NPCs (I assume on both sides) give you quests like collect elf ears and legs (in the case of the monsters). Plus other quests like 'collect a bunch of logs for our destroy the forest sawmill' which you can walk around and find on the forest floor. I don't know if completing the quests beefs up the NPCs on your side or not. Might be cool if completing the quests upped the level of your side's NPCs.

I don't know if you gain control of the whole zone if you 'win' the zone and the battle moves on to another zone or not (battle front line).

As a monster you get points for completing quests and ganking people which you can put towards beefing up your stats. There is no custom armor or weapons for monsters though. I also don't know what a freep gets if you kill a creep. A creep might drop money he's collected but I'm not sure.

Really nothing dynamic there. I think I'd rather play something like Battlefront if that's all it is going to have to offer though.


The building buildings in the middle of a running battle in Savage worked pretty well. You have people defending the builders and additional people helping the builders to make it build faster.

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.

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.


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.

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.

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.

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.

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.

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.

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.

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

[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]

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)

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.

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.

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)

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.

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.

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.

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

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.

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?

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.

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.

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.

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.

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.

Why?

All you need to ACTUALLY collide is your player and the objects immediately surrounding it that it could feasibly collide with; so that movement is restricted as to give the illusion that the player is colliding with something.  Collision should be handled locally.  Projectiles don't have to actually collide (use physics) they mearly have to have the illusion of colliding and that comes in the form of "touch" messages.  An object doesn't have to collide with another object to know that it's passed through (or "touched") a surface being drawn in the scene.  You also don't have to calculate the physics of other players.  That's just crazy.  Why would you calculate physics on other players when all you need locally is their position and animation ("pose")?  That's just extra processing work.  There's your "layers" of optimization.  Forget the binning nonsense...

Wouldn't you need to calculate physics on players if you wanted them to be able to "push" or "knock back" other players?  And, what if you use physics (how fast the character is moving) to determine damage as well?

Only your collision physics with them, otherwise you'd just update their position and sync the animation.  You wouldn't need to calculate the physics they are acting onto something else, locally on your system.  They are calculating that on their system, so why make the server and client do double work?  The position of the other player is already being updated every so many ms anyways.  Let that players client calculate the physics and send back the updated position based off the results to the other client systems across the network (like it already does).

On your second question, you wouldn't need to calculate collision physics to add the movement value to a damage calculation.  Something like:

getPlayerVelocity()  Local  // where PlayerVelocity is a varible that tracks the local players movement speed.

getPlayerDamageOutput () Local // calls the PlayerDamageOutput variable
PlayerDamageOutput = getPlayerStatDamage() + (PlayerVelocity/10) // calculates an increase of damage based on the players stat damage and 10% of the players movement speed at the time of attack

There's no collision physics calculation involved.

The bottom line is, if the local player isn't touching it (or about too due to proximity), then the collision boundaries don't need to be calculated.  A lot of engines do needlessly calculate this stuff.  I've always forced collision to be disabled based on what I've said and the result is the same with lower overhead.

Dude....you have a hidden assumption here that your simulation has a way of determining locality, without implementing that locality.

The binning system (or a similar optimization layer) is how you "Collision should be handled locally [sic]". Inside your memory space, objects are just a linked list (or set, or whatever ADT you happen to be using), and if you don't implement a locality mechanism, any check at all has to be applied against every object in the scene.

Long story short: if you don't have a system that allows you to relate and track how "close" objects are to each other, than for every "locality" check you want to do, you have to iterate over every object possible and say "are you within XXX distance of me? yes--you're local. no? move on".


That's totally dependent on genre, and desired game play.

In addition, as I've been cross-editing my two posts above, it sunk in--you are combining two separate game dev concepts (collision detection/response, and physics)...collision does not require a physics response, and while a collision event is most commonly a result of the physics system updating individual object's physics states, it's not the only way to generate collisions.

Consider the situation where a player enters a trigger area (a trigger being defined as a region a level editor places in his mission to detect when a player enters it). While it's not the only way to implement it, triggers are commonly implemented as objects that have collision detection, but not a physics collision response. When the player enters (or stays) within a trigger region, the collision detection systems report that as a collision event, and the level designer/scripter commonly handles that event callback to do whatever the trigger region is supposed to do.

To me that's a clear separation of "physics" and "collision"--sure, the player can only enter the trigger region by the physics system moving him there, but the trigger collision itself does not affect the physics of either object in any way--it simply generates a collision event for further processing.

That's broken on many fundamental levels.

First and foremost: You should never allow a client to be authoritative in any multi-player client/server simulation where cheating is a possibility--and that's any game you produce (that has multi-player). As soon as you let client executables determine authoritative physics responses, you open up multitudes of cheating techniques, from dissembling the executable and re-wiring physics, to simply intercepting packets before they are delivered to the server and re-writing them.

Secondly, this doesn't take into account the fact that by definition, all clients (and the server for that matter) are in different time slices at any given real time slice, and due to the time required to send updates to the server, then propagate to all other clients, those clients are going to disagree. It's extremely rare to have a setup where you can have what could be called "multi-simulation authoritative updates"--EA did this for their very controlled and limited design requirements for NASCAR, but it's an extremely rare, and extremely difficult functionality.

How do you handle desychnronized simulations if any client can say "my current state is authoritative"--what if that client (intentionally or unintentionally) doesn't have the full game state? They could have lost packets, or simply be too far behind the "average game state" of the rest of the simulations to have the right information.



You are being very loose with your definitions, and I think this is why there is disagreement here. By definition, PlayerVelocity is a physics state, and therefore you are performing a physics calculation. It's an approximation (and a very basic one), but again by definition every single physics calculation in a game engine is.

I will concede that in your specific example there is no direct modification to the target's physics state based on a result of the collision, but it's also pretty common to have the (false) assumption that collision implies a game state physics reaction. As you've demonstrated, you can (and in many cases should) detect collision but respond without physics, or at least decouple the collision response and the physics response. That doesn't mean that the collision detection doesn't occur--it has to for you to know that the two objects are touching.


Back to what I said in the post above--you are assuming here that your simulation stores a way to determine locality, without allowing (in a theoretical sense, not your implementation example) that system to exist. Some form of binning, or other locality information storage system, is required to determine is a player "isn't [sic] touching it (or about too due to proximity"...and as it turns out, a binning system provides both that functionality you just used, in addition to acting as an optimization level for collision checking.

Accidental double post.

The "Local" identifier means that that code will only be run on the client's computer.

Locality referees to "Client Side" and not x,y,z location.  All object templates are preloaded into memory when the client launches.  Then the objects (actual art assets such as 3D models and Textures) are rendered to the screen based off of the proximity to the player.  This is all done locally on the client side and are swapped out of memory as needed.  Generally speaking, assets would be preloaded regionally.  Then, the only art assets that have to be done on the fly are player models, equipment/weapon models, and textures (but, these days, only if more complex then WoW's characters...such as SWG or CoH characters...otherwise the combinations would be preloaded when the client launched).  I've never heard of 'regional binning' which seems to be what you are suggesting other then in Sector based games (otherwise known as "Portal Engines") such as Crystalspace3D and many many many of the early 3D games (such as DooM, Duke Nukem 3D, Tomb Raider, The Sith Engine (Lucas Arts engine used in a number of their early 3D games), etc).  But these were used before the days of culling and RVTCS (Ranged Vector Thing Creation Systems).  In newer engines like Crystalspace3D, you could avoid Sector Binning by implementing these newer systems and just having one large Sector Bin for each major region.

Cheating, the other primary concern, is avoided by the server verifying that an action is occurring within a certain tolerance (min and max value range).  If it isn't, then it cancels the action.

An efficient server system, IMO, is designed so that the majority of the events it handles are boolean returned values.

I did a bit of quick research on your term "RVTCS", and came across a couple of your posts from a few years ago, and wanted to highlight something:


That loop indicates that you are looping over every object in your simulation (client side, server side, whichever), and doing a vector distance check (twice) for a max and min range. In other words, you are doing a straight iteration over every object in your sim, and if I read the context of the post you made correctly, you are doing that for rendering optimization (occlusion is mentioned in the thread), which means you are doing this for every frame render (hopefully at least 30 times a second[/url].

There is absolutely no way any client machine is going to be able to handle this type of occlusion, or this type of big O search for any reasonable value of Used in a game where Territorial Warfare is going to make sense--in other words, an MMO style game. It is easy to expect values of Used (which is your total number of objects in a simulation as far as I can tell) in any reasonable map size in an MMO environment. Hell, even if you limit your number of users per "mission/area" to 1k, you will barely be able to run that kind of search every frame for just player's rendering, and that doesn't even begin to cover collision detection or physics.

And food for thought: the occlusion benefit of doing  a view frustrum occlusion test is most probably much less than the performance hit necessary to do the math of the test itself--you may want to look at not bothering to render objects not in your view frustrum.

The RVTCS cog (used for the Sector based Sith engine) was a work around piece of code that ran client side.  The Sith engine (like many sector based (or Portal based, if you prefer)) was plagued with issues when it came to creating large open areas.  You could divide a large area into multiple sectors, but if the origin of objects near the edge of the rendered scene was not within the Field of View (the rendered scene) then the entire object would not render at all (even though it should).  This only occurred when the object was in a separate sector from the player.  The other issue with portal engines is that they render everything that it thinks should be on the screen regardless of distance.  It is important to note that this particular code had nothing to do with character player models or any other non-static object.  The code used for that particular game actually served two purposes.

1.  It allowed you to tell the engine to stop rendering an object if it was beyond a certain distance from the player.
2.  It allowed for you to have it stop rendering that specific object at a particular minimum distance to switch to a higher resolution model.

So, it there were two great optimizations that were made that finally allowed for the creation of large open areas to be created using that engine which were previously not possible.  That also looks like and older version of the code.  New versions were object template specific and thus not limited to 10 objects.  But this is all besides the point because this is specifically about work arounds for old portal based engines, and not what I was discussing...

On an interesting side note, i later designed a piece of code that allowed for virtual sectors to be created within one single sector.  It essentially a "trigger zone" that would allow you to trigger events when a player entered a certain x,y,z perimeter without having to deal with the issues relating to using multiple sectors.

I don't mean to be redundant, but what you describe in your side note is built in to a binning system...

I'm also not dogging the optimizations you guys made--I simply was pointing out that given the problem state in the general thread, higher levels of optimizations are pretty much mandatory.

Yes, but the point was that the "binning system" was causing objects to not render simply because their origin (center point position for the object) was outside the same sector (bin) and out of view.  That was the optimization "working as intended" and for small objects, that wasn't an issue.  For larger objects that spanned two more sectors (bins) it became an issue.  So, again, it was a work around for that issue.  To elaborate; the pieces of code i designed for the Sith engine were designed such that they canceled the "binning" optimization by having your entire level be in one sector (or bin, if you prefer).  Since eliminating this optimization causes the frame rate to take a huge hit, a supplemental optimization (the RVTCS) was used to limit how many objects were rendered on the screen at one time (it also bypassed a hardcoded limit of ~350 object to the entire environment).


I don't think it was a question of higher level optimizations being needed, but more precisely, what those optimizations were...which will very between engines.  My preference, is to do as much client side as possible and validate limits (prevent cheating) server side.  In the MMO I'm designing now, health bars will only be client side (most things will be killed in a few hits), no "fly text", etc.  I'm taking a page for online fps games such as BF1942 when it comes to combat.  I haven't decided what to do about chating.  Right now chat is implemented with chat bubbles, etc.  But I'm considering taking it out and using a separate VOIP program that communicates with the client and server...

Cheers!