Goblin Squad Member
|
Right but what I'm saying is it becomes automatic by definition. You can't not notice the door opening, because the client has to be informed of the door opening, consequently a player (or any program a player is running) is instantly informed. a player isn't just going to casually walk over and pretend to look around, a player is going to lob fireballs, spin a whirlwind or whatever at his arsenal will damage without needing to target like crazy. It shouldn't be automatic, but in reality it is. Any mundane change client side that has no real cause, would automatically alert any 3rd party program, and instantly allow the defender automatic detection.No, I am all for AoEs causing damage and stealthed characters having to do some sort of concentration or just a straight penalty to their stealth based upon the amount and type of damage. Massive amounts of damage probably will cause me to perform my stealth so poorly that I will be seen...but then again, my potential observer might be hit by the same effect and miss their opportunity.
As for doors, I think being very near a stealthed character should give bonuses to perception, you see a door open and close by itself, you walk over and check it out...this increases the chance you will see a hidden character...but it does not make it automatic.
I admit I was not thinking about combat situations. In a dungeon when all of your party is present, sure if a door opens and closes by itself that is your option to start throwing fireballs...I don't see a problem with this and actually think is is what would happen. This is a risk you run by trying to sneak up on people, you might spook them and find yourself injured even if you did not intend them harm. I also do not see how system information or a 3rd party program registering a door opening and closing allows you to pinpoint a stealthed character automatically... you can start lobbing fireballs all around the room you are in and you might hit the stealthed character and you might not...he/she might be already be immediately behind you...as you do that.
I'm not 100% sure on the damage side as to whether a client has to know if something has been damaged or effected by any attack for that side of things, logically IMO it shouldn't, but the implications of the devs seem to imply that it does. To me logically you are right the server can note the attack, and the server can know who was in the area, the client dosn't necessarally need that information, but it isn't really a guarantee.
A bigger issue I can imagine though, is the friend/foe determination for some of it. IE 2 parties meet, one wants to send it's rogue into stealth to find out what's ahead... since party 2 is in the same area, is rogue 1 unable to stealth unless party 1 leaves...
I am not 100% sure I understand what you are saying here, but I think AoEs should do friendly fire and if your perception is not high enough you should not see any stealthed character, friend or foe (sorry, not sure again if I addressed your concern).
|
Goblin Squad Member
|
I admit I was not thinking about combat situations. In a dungeon when all of your party is present, sure if a door opens and closes by itself that is your option to start throwing fireballs...I don't see a problem with this and actually think is is what would happen. This is a risk you run by trying to sneak up on people, you might spook them and find yourself injured even if you did not intend them harm. I also do not see how system information or a 3rd party program registering a door opening and closing allows you to pinpoint a stealthed character automatically...
You know it automatically because you know where they are at the second you are informed, someone can't move 20' in the time it takes to blast a fireball at the 20' that the door is in, and a 3rd party program would alert to the door the second it begins to open, as that is when the client becomes aware of it, even if the door isn't in the players line of sight.
I am not 100% sure I understand what you are saying here, but I think AoEs should do friendly fire and if your perception is not high enough you should not see any stealthed character, friend or foe (sorry, not sure again if I addressed your concern).
I'm not talking about the damage friendly fire, I'm meaning based on the problem with hivemind/mindlinked mods where if one knows everyone knows. The only solution for that issue is for the game to fully break you from stealth if anyone notices you. Meaning if you have an ally who isn't in your party near by you won't be able to go into stealth because you are being observed, same issue with your ally's having pets that can detect you even if you do that after the fact etc...
If one detects you everyone detects you is the only way to prevent cheaters, that also means that if an ally see's you everyone sees you. In PVP groups larger then party size will likely need to work together, but the game can't truely determine which groups are together and which ones are opposed, so it will have to treat every group that isn't yours, as an enemy, and assume that enemy is mindlinked to every other enemy in the area.
|
Goblin Squad Member
|
Ah, interesting point about the hivemind thing. Concerning the door...if I were trying to sneak up on a party and had to pass through a door to do it, I would open it from the other side and hide behind the wall...let them blast arrows and/or magic into the area (safely hidden from any non-AoE)...once a bit of time had passed, then I would move through the still open door...which I would leave open. But, this is all silly anyways since there won't be buildings we can enter.
|
Goblin Squad Member
|
Stealth is always a difficult one to rationalise. How can someone be hidden in the middle of an open courtyard, for example? I've played numerous stealth classes in a number of MMOs in the past and I think that Ryan makes a good point. Any online game will always have to contend with those players who want to have every edge possible, even when it's one that contravenes the game's T's & C's.
I think that I'd be in favour of any method which actively works to negate a hacker's advantage.
|
Goblin Squad Member
|
| 1 person marked this as a favorite. |
The problem I have with stealth as implimented in most MMO's is that it functions pretty much as PERFECT INVISABILTY until the stealther reaches a distance of 5ft from the target at which point the target has an opportunity to spot them. Quite frankly, thats a lousy mechanic...in my book worse then not implemting stealth at all.
I understand the reason for it, doing a check for every possible observer against every "stealthed" character that is withing line of sight on every time pulse (something that would more closely simulate real life) throughout the game world would be insanely resource prohibitive for the server (and it would have to be done on the server) so the engines cut down on that to a managable level by only doing such checks for objects that are right on top of each other.... but it makes for an absolutely crappy game-play mechanic.
I'd much rather have a system where you know where the "stealthed" players are but can't "spot" them to act upon them directly unless you've made a request and passed a skill check. This allows "stealth" to be a skill contest between the observer and the "stealther"... adding a new dynamic of game-play.... and when you do that sort of active check ability you can start to take other conditions into effect such as range to target, ambient light level, visability, whether the stealther is in "cover", whether someone else has "spotted" the stealther recently....just as you do with any other sort of active "attack/debuff". It makes the whole "stealth" game much more nuianced and tactical in terms of gameplay.
|
Goblin Squad Member
|
You know it automatically because you know where they are at the second you are informed, someone can't move 20' in the time it takes to blast a fireball at the 20' that the door is in, and a 3rd party program would alert to the door the second it begins to open, as that is when the client becomes aware of it, even if the door isn't in the players line of sight.
I admit I was not thinking about combat situations. In a dungeon when all of your party is present, sure if a door opens and closes by itself that is your option to start throwing fireballs...I don't see a problem with this and actually think is is what would happen. This is a risk you run by trying to sneak up on people, you might spook them and find yourself injured even if you did not intend them harm. I also do not see how system information or a 3rd party program registering a door opening and closing allows you to pinpoint a stealthed character automatically...
Actualy that would make for a very interesting use for something like a "Prestadigitation" spell. Open a door from 30 ft around a corner.... BAM there goes the oppositions Fireball spell! ;)
|
Goblin Squad Member
|
...stuff...Yes, such a system would be great if the engine they choose could handle it. But I think tracking lines of sight of all characters is even more loading on the server. And it still wouldn't solve the problem of third-party "mind link" programs, though it would keep hiding characters farther from potential enemies most of the time.
I think you've missed my point. I'll attempt to rephrase; If the system doesn't toggle visibility, ie everyone is always visible, then stealth could still be an option if the environment is capable of providing the relevant amount of cover. I don't mean stealth in any tricky partial visibility sense, i mean it quite literally in the terms of hiding from players by being camouflaged, out of line of sight, or otherwise go unnoticed. Then the Intent of stealth is sufficed rather than providing a mechanic for stealth. Basically, the onus is on the player to be stealthy rather than relying on some technical aspect to the game.
This "manual" stealth might also require an few tweaks to the PvE model, perhaps as NPCs Perception stat linked directly to a facing capacity, so that one might actually be able to sneak up directly behind an NPC or monster. More simulation oriented approach to the methods the table top game uses, and clearly technically achievable as this capacity has been displayed in innumerable games to date.
Now, this still doesn't prevent the PvP "radar" like issue with extra-client hacks, or packet sniffing, but that sort of thing i believe to be a technical consideration outside of the capacity for the forums to discuss. Unless one of us is currently employed by a MMO as a security expert ...
Now, this still doesn't prevent the PvP "radar" like issue with extra-client hacks, or packet sniffing, but that sort of thing i believe to be a technical consideration outside of the capacity for the forums to discuss. Unless one of us is currently employed by a MMO as a security expert ...
The problem is, the devs' replies clearly imply that no matter how hard you try to secure your packages, they can and will be intercepted and deciphered. So you better design mechanics with that in mind.
|
Goblin Squad Member
|
To my mind the problem with stealth in MMO's is actually one of over-simplifying the mechanics. As several people have suggested they are all or nothing affairs, with either 'invisible' or 'detected' states when in fact most rpg's deal with stealth on multiple levels. Lets look at those now..
Hidden. The player is either physically hidden due to LOS mechanics existing in game, or through some other mechanic. (Ambushing from hide-outs already kind of encapsulates this but could be done on a local scale as a player prepares a hidey-hole that conceals them).
Camouflaged. The players model takes on colours and textures around him. This is a visual disguise that makes a player difficult to discern from surrounding terrain.
Darkness and Low Light. A combination of Hidden and Camouflaged, game lighting itself can be used to make players difficult to spot.
Disguised and Illusionist Effects. The player either appears entirely as something he is not (a different player, a tree, an animal) or is disguised by illusion (appears as multiple players, appears further away or much bigger etc)
True Invisibility. A very powerful ability, this is what most MMO's today pass off as stealth.
Perception Impairing. Rather than hiding, the rogue impacts on the perceptions of his opponent, blinding, confusing, mesmerizing etc. All these can be used as means to cause damage or cover an escape.
All of these are doable in today's games and I think Paizo could pull them off extremely well. I would also add my vote to the 'please don't punish the player-base on what cheaters can do' camp. I will wear death and disadvantage because rogue/thief/assassin game-play can be some of the most challenging and rewarding game-play there is in modern MMO's. Every single aaspect of an MMO can and will be exploited by people if they think they can and removing stuff because it could be exploitable seems counter-productive.
Now though here is the crux of the issue. Most of these styles of disguise are not currently used by modern MMO's because of one seeming standard and widespread game-play mechanic. TAB Targetting. For those unfamiliar, most MMO's allow (usually TAB) as a means to cycle quickly through 'available targets'. If the game knows you're hidden in the area it will include you. If you remove TAB Targetting as a mechanic it means a) stealth players really can stealth, b) everyone else may have issues targetting a desired enemy quickly in high volume combat. Personally I think it rewards skillful play and makes the game more complex, something that should be done at every opportunity. Certainly complex mechanics can be problematic on the mass-market appeal, but the approach Paizo appears to be taking does not seem to be aiming for mass-market or lowest common denominator. I wholeheartedly applaud them for this and if they pull it off they will have my custom for years.
So up with stealth, down with TAB Targetting, boo to cheaters and huzzah for the shopkeep (and Paizo)
|
Goblin Squad Member
|
All of these are doable in today's games and I think Paizo could pull them off extremely well. I would also add my vote to the 'please don't punish the player-base on what cheaters can do' camp. I will wear death and disadvantage because rogue/thief/assassin game-play can be some of the most challenging and rewarding game-play there is in modern MMO's. Every single aaspect of an MMO can and will be exploited by people if they think they can and removing stuff because it could be exploitable seems counter-productive.
The big thing, undetectable and unstoppable cheating is the issue. Item duplication etc... everything on the server side is detectable is bannable, which is why most everything goes through the server, thus most everything isn't exploitable.
When cheating isn't detectable, it does become a majority. Take ryan's showEQ example, it wasn't a small group of players using showEQ, it was more along the lines of at least 1/4th of the players were either using it, probably over half were working with and reaping the benefits of someone else using it. Off of official auditable forums most guilds required or encoraged the usage of the program.
Take WoW, because Blizzard knew the arms race would accomplish nothing, they allowed people to use programs without bothering to make it an underground. And thus came the invention of the raid plugins, that litterally told players what attacks the boss was using, what they needed to do, sent automated whispers to players when they needed to do or not do something etc... It wasn't a small percentage of the game that used such tools, it was more or less a requirement any guild that raided, required players to install before attending their first raid.
It isn't a boo hoo a handful of people will cheat, it is pretty much undeniable that a very large percentage will cheat, considering the PVP nature of the game, I would probably estimate it at 50% or more, and the 50% that don't... well they will likely be the weak and the new players, who are regularly picked off easilly by the other 50%.
You say everything is likely to be exploited, but I challange you, asside from vision, name one other type of hack that is undetectable and unprovable in modern MMO's. Botting, leads to a generally predictable movement path, and can instantly be proven by a GM messaging the player and the bot being unable to respond. Pretty much any other exploits, involve tricking or fooling the server... which would leave tracable server logs.
Of the ones you listed, only 2 of them are not easilly exploitable, Disguise and true invisibility. Both because they permit an all or nothing form. Camoflage, dark/lowlight etc... as long as there is some moderate visual indicator, it isn't just a small percentage, it is a controling percentage of people that will hack, and the people who can will simply make life miserable for those who can't.
Removal of tabbed targetting won't help the issue, it will simply allow the writers of aimbots for fps's to move to the RPG market, only with 3x the value due to a characters longterm persistance being years instead of a 30 minute match.
|
Goblin Squad Member
|
The big thing, undetectable and unstoppable cheating is the issue.
Nothing is undetectable or unstoppable. If it was, and cheating was as rampant as you suggest it is among players, then no-one would ever win a first person shooter round cleanly anywhere on earth.
But they do, because systems like Punkbuster help stop it.
WoW has not had half the issues EQ had because of 2 things. One you correctly identify in sanctioning raid content. But this is paired with the Warden system that looks for bots and scripts.
Sure its an arms race, and its tough, but given Paizo is starting from a very small customer base its actually something they should have no trouble keeping an eye on early in the piece. As the game grows it gets harder, but so correspondingly does their experience in combatting it.
EQ's scenario was unique because it was a first. MMO's were new, game mechanics forced some pretty crazy levels of competetiveness. Paizo can learn from the design decisions that forced that, and Sony's choice and decisions in combatting it.
Saying it's 'too hard' at this juncture, when you're talking about systems that are the absolute bread and butter of one of the big four primary fantasy archetypes, the Rogue/Thief/Assassin/Ranger, suggests you're pretty much gutting those archetypes. I would very much like to know what they would plan surrounding those archetypes if stealth was not a major driver of their abilities.
What is the advantage of a rogue who cannot disguise himself? A thief who cannot steal? An assassin who cannot attack from the shadows? And what kind of a fantasy MMO does not have them at all? Maybe there are answers here Im not sure of that they're planning. Would love to hear more on this.
|
Goblin Squad Member
|
The big thing, undetectable and unstoppable cheating is the issue.
Nothing is undetectable or unstoppable. If it was, and cheating was as rampant as you suggest it is among players, then no-one would ever win a first person shooter round cleanly anywhere on earth.
But they do, because systems like Punkbuster help stop it.
WoW has not had half the issues EQ had because of 2 things. One you correctly identify in sanctioning raid content. But this is paired with the Warden system that looks for bots and scripts.
Systems like warden and punkbuster are bypassed all the time, also EQ's scenerio was because specifically it was designed where it sent information to the client before gamers should know about it. Which was the mistake that developers managed to stop repeating immidiately afterwards, and why every game has always done stealth as true invisibility, because if any information is going to the client, there is absolutely nothing that would stop a packet sniffer. Warden, punkbuster, gamegaurd... all of which are worthless in those conditions
1. If the game is running in a VM and cheat program outside of the VM
2. The cheat program running on an alternate machine on the network before you state that only a handful of people possibly will have 2 PCs in that room, estimate how many have smart phones.
That is why games do not do stealth as making the person hard to see.
As I said I think true invisibility and disguise are technically possible, although difficult to implement. Primarily because none of the clients can be sent that information. That is why those functions work.
Warden IMO has nothing to do with the relatively low portion of cheaters in WoW, the success in that field pretty much comes from the fact that very little can be gained by hacking what the client knows, the client dosn't know what treasure is out there before the person opens/loots, Anything that can be known is legal to get knowledge from via the legal ad-ins. The only thing off limits is bots, to which WoW's very large GM budget is very good at taking out rapidly because they very rapidly respond to reports and in general terminate the accounts of bots more or less as soon as they do the first visible offense. I know for one I still did see bots on occasion, and get random whispers etc... from them. It was less frequent then most games, but that was due to the GMs, because when it comes to technical abilities when one cheater/spammer/botter gets past, they all do instantaniously, only 1 has to be smart enough to bypass, the rest just have to be smart enough to double click a script.
What Onishi said.
Also, if anything, TAB targeting can help implement stealth in a way. Particularly the pseudo-stealth offered by GrumpyMel. It is easy to prevent players from targeting those who are not supposed to be targeted. And no targeting means no interaction most of the times.
|
Goblin Squad Member
|
I've got to agree with Onishi in this regard. If PFO were primarly PVE focused... I'd say we're caring too much about cheaters do since they are primarly cheating themselves, doesn't effect the rest of us playing fair as long as Dev's stand a firm line of not adjusting the difficulty of encounters to take cheaters into account. Let them run in "God Mode" if they like and get bored with how easy it makes things and quit after 30 seconds.... heck in a completely PVE game, I'd probably purposefully make an easly hackable "I WIN" button for the express purpose of making the game so boringly easy for anyone who wants to cheat...that they just wouldn't bother playing it.
PvP is another story though. In those situations you are putting honest players DIRECTLY in competition with the cheaters...(i.e. the players are each others content).... so completely different dynamic. You really do have to worry about cheating in PvP focused game.
Things like Punkbuster do help catch some hacking, especialy the less determined/saavy folks but the main reason why it's not quite as critical an issue for most FPS games is called "Password protected servers", that along with /kick means that you are basicaly getting to choose who you play the game with.... so if someone is so unbeatable that people think they are cheating... they just aren't going to be allowed into the same servers anymore. That along with lack of persistance....means there is not that much real gain from cheating anyway.
If GW had a huge budget to devote to the project and were building their engines from the ground up... I might try to push for them to take a chance and try to impliment some of the visibility stuff.... there are a few things that you CAN do...like SALTING the data sent to the client with false positives...so the hackers don't know which ones are real or not...or stronger packet encryption techniques along with detection software....or just keeping more of the processing on the server.... but that all would translate into alot more resources sunk into it...that GW probably really needs to expend on actualy making the game.
I do NOT, however, think it has to be true invisability or nothing. If you surrender the idea that the prime function of stealth is concealing objects from the player and move it instead to concealing objects from the players CHARACTER... then there are alot of things you should be able to do without a crazy investment in resources. The system has no way of controling what information is revealed to an individual Player through out-of-band methods....but it absolutely can determine what an individual character in the game world is SUPPOSED to know...and what actions that character is eligable to undertake based upon that information.
|
Goblin Squad Member
|
I think GrumpyMel has this exactly right.
It's pretty much impossible to stop the human being in control of the client machine from hacking any information stored on the client machine.
However, it should be relatively easy to stop the character from using the client to interact with another character that is stealthed or invisible.
It seems like a lot of people have taken Ryan's statements to imply that they won't be implementing stealth or invisibility in the game. Perhaps he was instead simply making sure we were aware of the limitations in controlling what the player knows.
|
Goblin Squad Member
|
That's an excellent point, Decius. I wish I'd said that :)
Using player skill as a proxy for character abilities is actually one of my major pet peeves, and it's the reason why I keep hoping that someday there will be a game that will actually let my Fighter or Monk character engage in melee combat as effectively as that character should, without relying on me for anything other than decision-making. I keep saying I want a severely physically handicapped player to be able to play effectively. And while we're at it, I hope that it is ultimately possible for someone who is mentally handicapped to be able to play a wizard where their character is good at solving riddles, etc.
If GW had a huge budget to devote to the project and were building their engines from the ground up... I might try to push for them to take a chance and try to impliment some of the visibility stuff.... there are a few things that you CAN do...like SALTING the data sent to the client with false positives...so the hackers don't know which ones are real or not...or stronger packet encryption techniques along with detection software....or just keeping more of the processing on the server.... but that all would translate into alot more resources...
Oh yes, false positives... This reminds me of the time I first played Thief: The Dark Project. I was also playing UO back then and read about a first person 3D MMORPG that some company planned to release. It was like 2000 or 2001, so the game was never released of course. But I remember thinking about how could stealth be implemented in a thief-like manner. A came up with the idea of false signals (but fed to the player, not client), like footsteps or 3d-models or special effects appearing out of nowhere and simulating sneaking characters ). These signals would be partially negated by a couple of skills like Spot/Listen, of course, but one would need to invest into them to get a noticeable effect.
Oh well, it doesn't matter since it's really complicated and absolutely cannot be achieved with the use of existing middleware (using which is actually a great idea on the part of Paizo). You just reminded me of my childhood lol.|
Goblin Squad Member
|
In order to use False Positives, the client has to have some way of determining which are real and which are false. If the client has access to that data, the human being sitting at the console for that client can hack it.
The client only needs to know which ones are real/false at the time which the end user needs to interact with them. It addresses the hacks that involve the client getting information before it is revealed to the player. Which is what alot of the information disclosure rendering hacks are based on.... the need to pre-populate the client with information so performance doesn't suffer by it having to wait to get that information from the server when it's needed. If the clients could be given information only as they needed it....one whole category of hacks would go away.
What it doesn't address is the category of HACKS where user A has some information (i.e. see's some portion of the map) that user B doesn't have yet...and user A shares that information with user B before it's supposed to be know to user B.
THAT is a really tough type of hack to address because the real answer is to prevent user A from communicating with user B....which you really can't do unless you PHYSICALY control the locations which A & B are operating from.
About the only way you could approach something like that is to not actualy have the players USE clients. Make them play over a Citrix session and turn thier PC's (as far as the game was concerned) into dumb terminals which were just exchanging keystrokes and graphic images with the real "clients" (which would be sitting on infrastructure you controled). Hackers could still share each others screens.... but to get any more functionality then that, they would actualy have to reverse engineer the actual client with no access to the source code or the data packets.... just the info the player had with thier own eyes (i.e. graphics and keystrokes).
Of course, I'm not sure who the heck of a Developer would actualy do that for a game... but if you wanted something that was really resistant to those sort of hacks...that'd probably be the way to go about it.
Yeah... InfoSec is part of my job description....can't help thinking along those lines ;)
|
Goblin Squad Member
|
If the clients could be given information only as they needed it....one whole category of hacks would go away.
Isn't this just another way of having the server determine whether or not the one character detects the other? If that determination is being made on the server, what's the point of sending the false positives at all?
|
Goblin Squad Member
|
I love gamers :D
I make a suggestion that the topic should shy away from the InfoSec portion pending actual hard choices by GW, and immediately it becomes the topic of choice. Its like trying to tell someone "Don't think of an Elephant."
Rather than view this from the purely theoretical realm of what can be done to accomodate hacks on an as of yet to be designed system, perhaps we can analyze the value from a gameplay perspective, and wether some of the proposals presented here actually advance the "fun" factor or if they are systems for the sake of being complicated.
With this in mind, there's two assumptions, visibility is a toggled feature, or not. I attempted to front ideas for not, with little or no traction, so lets examine the playability of non-manual stealth.
We can all agree (i hope) that it's a powerful aspect to game play that should have some layers of limitation. Having a multi-tiered pile of visibility seems to be an over-complication of what is at its base all about yes/no the Player can detect the Opposing Player. If they can, they can ameliorate that advantage without nullifying it, and if they can't the Stealthy player has the fun of determining the Initiative order, so to speak. Its also a base assumption that the stealthy player not only has the advantage of initiation (a strongly undervalued advantage imo) but also tends to have a limited term damage buff.
These are all pretty limited base assumptions of gameplay. Do we feel it necessary to discuss other gameplay options for the context of Player vs Stealthy Player?
I love gamers :D
I make a suggestion that the topic should shy away from the InfoSec portion pending actual hard choices by GW, and immediately it becomes the topic of choice. Its like trying to tell someone "Don't think of an Elephant."
Not really, it has been discussed since like post 20 or so.
Rather than view this from the purely theoretical realm of what can be done to accomodate hacks on an as of yet to be designed system, perhaps we can analyze the value from a gameplay perspective, and wether some of the proposals presented here actually advance the "fun" factor or if they are systems for the sake of being complicated.
We just assume it is not fun to be constantly defeated by cheaters and thus encouraged to use cheat programs. Especially if you level your stealth only for it to be rendered useless by hackers (and there will be a lot of hackers in any persistent world PvP game not designed to counter hacks). If there's no skill for this, it's better, but only a little.
Of course, in small encounters with casual gamers just about any sensible system will work fine. But eventually the stakes will become too high and some guild will hack, causing a chain reaction.
Then some guy who defended his PC king's lands yesterday will go to help his real life friend gather daisies in a nearby forest. And here you are, hiding in the bushes, waiting for a good moment to strike them. Except you are not actually in hiding, as that one guy who started using hacks yesterday can see you perfectly fine.
Now, other people can see you no matter how hard you try, but you still can't see other people who hid well. Isn't it unfair? Can you see the end of this story?
|
Goblin Squad Member
|
I can see how this evolves, and I completely agree it should be of concern. I was merely attempting to redirect the context of the thread towards a topic we can discuss that doesn't rely on purely theoretical ideas. We have zero idea of what middleware is on the table, so whatever InfoSec Mastermind has been (or will be) hired by GW still dreaming of the ideal system. I would heartily enjoy the technical aspects of client vs server security, perhaps in a thread dedicated to it, since its a broader concept that requires fairly deep knowledge to approach. I wouldn't feel like I could contribute to such a thread from an educated, technical position, but I would read it nonetheless.
We can most assuredly assume that hackers and cheats will diminish any fun. I was hoping we could make some assumptions of security for the sake of discussion. Also for the sake of discussion, I was hoping we could move back into the aspects of stealth that I haven't read about in this thread (maybe i missed something pre-post 20). Its all theorycrafting at this point. As such, and in lieu of having literally no access to the technical side of security, I was suggesting the conversation be more in line with the game design aspects of the thread title.
If that's not where the discussion goes, so be it. But I think it limits the discussion about stealth to a purely technical realm.
|
Goblin Squad Member
|
@Gruffling, I think the problem you're running into is the fact that Ryan's statement spoke directly to the hacking, so that's what people are trying to process.
Again, I think its a valid discussion, as I think all these discussions are, but one likely worthy of its own thread. my 2 cents.
Is there even really a debate about how stealth should work if hacks weren't possible?
I'd say there are a few things to discuss/debate about how stealth should work. Example: In other MMOs stealth has such power that its limited to a few classes and special abilities. In the tabletop this isn't a limitation, and in PFO's nebulous skills system, would this fit into the former or the latter? Do rogues/assassins/etc benefit more from stealth (seems reasonable), but what sort of abilities could others benefit from, and how does this impact multi-classing?
Those few are just off the top of my head. And its not like we don't have the time to discuss all manner of things before the development actually starts with opening the Box with the Code in it.
|
Goblin Squad Member
|
@Gruffling, I think the problem you're running into is the fact that Ryan's statement spoke directly to the hacking, so that's what people are trying to process.
Again, I think its a valid discussion, as I think all these discussions are, but one likely worthy of its own thread. my 2 cents.
Just seems odd that you're trying to get people to stop discussing something in this thread when Ryan brought it up in this thread and people naturally want to process it...
|
Goblin Squad Member
|
Do rogues/assassins/etc benefit more from stealth (seems reasonable), but what sort of abilities could others benefit from, and how does this impact multi-classing?
Thinking about how to represent stealth without making characters invisible.
I think the rogue's stealth attacks can represents the ability to gain an early advantage in melee combat, especially in close quarters (urban, underground).
I think a ranger could have a similar ability to gain an early advantage in ranged combat in appropriate terrain.
For both classes, the character's party/group should have to initiate the combat to gain their combat advantage. If the other side attacks first, then your stealth characters aren't in position; you don't get the bonus.
For other classes... I think that fighters should get some bonus in longer combats, to represent their training for long melee battles. They might also get bonuses when they outnumber the other side's melee force by a significant number, to represent training in tactical maneuvers like flanking and enveloping. With lag concerns, I think determining facings and actual flanking would be difficult.
|
Goblin Squad Member
|
I keep hoping that someday there will be a game that will actually let my Fighter or Monk character engage in melee combat as effectively as that character should, without relying on me for anything other than decision-making. I keep saying I want a severely physically handicapped player to be able to play effectively. And while we're at it, I hope that it is ultimately possible for someone who is mentally handicapped to be able to play a wizard where their character is good at solving riddles, etc.
Some might term this "coddling". Others might call it a "developer sanctioned bot". What's the point in playing a game that plays itself for you?
Some people view the player as part of the character. when you roll your dice to determine the stats, one of the random variables added to that end character is the player behind it. If that's not important, then your character doesn't really need you to stick around.
Goblinworks Executive Founder
|
In order to use False Positives, the client has to have some way of determining which are real and which are false. If the client has access to that data, the human being sitting at the console for that client can hack it.
The point is that the client doesn't know which ones are real and which ones are fake. When the character detects a sneaking enemy, the server tells the client "this one is real, it is at x,y,z heading h animation a frame f" and the client can respond more rapidly because it has the textures and models already in cache.
|
Goblin Squad Member
|
In order to use False Positives, the client has to have some way of determining which are real and which are false. If the client has access to that data, the human being sitting at the console for that client can hack it.The point is that the client doesn't know which ones are real and which ones are fake. When the character detects a sneaking enemy, the server tells the client "this one is real, it is at x,y,z heading h animation a frame f" and the client can respond more rapidly because it has the textures and models already in cache.
That works well for true invisibility, which also can be solved by no-one knowing anything, negating the need for false positives. The ideas of partial invisibility/camaflauge darkness etc... this dosn't solve the issue, nor does it permit 1 person to possibly be able to see it, and not guarantee everyone can see it. IE a tactic a guild could use is have one person with super high spot/detection, as soon as his client sees the truth, all other clients get a notification of what is the truely invisible person etc...
The idea of an all or nothing system does work to an extent, IE when a person is invisible, he remains perfectly invisible until it is broken, if one person creature or anything detects him, the invisibility/stealth is immidiately negated. That is the one system that is not a huge free bulseye for cheaters.
By the way, the idea of true invisibility stealth can be viable as long as its duration is extremely short. Like swift invisibility or that ninja ability, if you know what I mean. Or several maneuvers using such invisibility. Of course such tricks are almost exclusively combat-oriented, but they could still add variety to the game.
|
Goblin Squad Member
|
Leaving aside the details of technical implimentation for the moment. Functionaly stealth plays a number of important roles.
- Protection .... If you don't know I'm there or where I am at, you can't effectively attack me.
- Information Gathering .... if you aren't aware of my presence, you might reveal things about yourself that you otherwise would not.
- Information Denial..... if you aren't aware of my presence you won't be able to learn things about me. i.e. "I wasn't aware the Knights of Knee were ferrying supplies and reinforcments along this path."
- Combat Advantage..... If you aren't aware of me, I can manuver into the most opportune position to attack you from.
Employed properly stealth can be an incredibly powerfull tool/combat advantage. Especialy for the type of game that PFO is aiming at. So much so that I think the "perfect invisability outside of 5ft" mechanic that most MMO's choose to impliment it as really becomes problematic.
Remember:
If your client knows where my character is, even if your client is told not to show you, enough people will cheat that being hidden is meaningless - and in fact the non-cheaters then play at a significant disadvantage.
Reasons your client might need to know where my character is:
* I have magical effects on me that affect you.
* You have magical effects on you that affect me.
* You run in to me and collide (or vice-versa).
* A pet you control can sense me (blindsight, scent, tremorsense, etc.)Even stranger case: If there is a 3rd party involved who can see me, then that information can be passed to you and you will be able to know where I am as well. So being "hidden" needs to apply to every potential observer in the space, not just a subset.
You would have to know when I opened a door or triggered a trap, or attacked or was attacked by a PvE entity; all of which reveal my location.
In general, being "hidden" is an all-or-nothing proposition, where the server does not communicate any information about my position to your client, period. And when my "hidden" state ends, every client can access that information. Thus, as a game mechanic, its less than ideal and doesn't work the way people wish it would.
I apologize for the necro but this puzzles me from a programming standpoint. Why does your client need to know where I am if I'm "hidding?" Your client should just know that you have x, y and z effects on you. When I move out of range and take effect y with me, all your client should know is that now your character only has effects x and z. Any animations that need to be triggered can be handled by code via event handlers whenever an effect is added or removed and it can know which animation to run via the effect's type.
This is true also with collisions. Your client doesn't need to know my coordinates but simply needs to play an animation, most likely, and maybe move a little.
Also, if there's a 3rd party who has a bead on my location and they announce it then why should this be bad? It just means that either I didn't hide well enough or they're more organized than I look. If it's someone I though was a friendly then that's a pretty tough learning experience but one I won't forget and actually lends to a fantastic roleplay opportunity.
The only valid reason I can see out of your examples, technically speaking, is if you have a pet. In order for my pet to effectively navigate to you, if attacking or whatever, you would need the beginning and end data to path correctly. However, I only see this as an issue if pets NEVER do anything pet-like such as digging the ground, or sniffing in an area for whatever reason. If pets have no ticks and are simply attack companions then I would see why this behavior would be very predictable and possibly a bad thing. If my pet jets off to another location I can "twitch think" and blast the area with fireballs or whatever else I have.
|
Goblin Squad Member
|
@Buri
I know it's been said quite a few times here. Yes, a system can be done where the client doesn't know anything. BUT such a system would require tremendous hardware requirements, this is why you never see it in any game. Technology has not advanced far enough to make such a system cost effective, so the game simply sends out all information, and your client decides what you can see.
A fundamental underpinning to MMOs is that the game dictates to the client instead of the other way around. Otherwise, people would just write scripts that "attack" people anywhere in the current instance.
The game already needs to handle these calculations, otherwise you have the above where the client is dictating to the game and anyone with a "super client" effectively "auto wins." The game already works to know how quickly you move, when you shoot if/what you hit, how much damage is done, what you see, what happens when you click on something, what's in your inventory, how much money you have, etc, etc, etc. The game client does none of this and simply a pretty viewport into the game. At best all the game client should do is report your actions to the game but the game takes over from there already. This is the standard way to implement an MMO platform and shouldn't be different just because PFO is a sandbox rather than a themepark. Otherwise, the guys at Goblinworks are going to be relying on each individual client to do the legwork of things such as physics and AI which will be a client cluster in terms of synchronization especially in heavily populated areas.
Also, the idea that it takes more resources to send less data to the client is plain odd. This should be more efficient, not less, as it exposes less data open to be exploited, helps ensure quick and reliable data transmission and helps ensure adherence to time tested programming principals such as DRY (Don't Repeat Yourself) which, in this case, says that everyone knowing something is useless and only those who *should* know something should know.
|
Goblin Squad Member
|
When the client is handling stealth, the server broadcasts player locations, actions, and a 'hit' or 'miss'
When the server is handling stealth, the server has to take every player, and make a list of every player that that player could possible see, and update it frequently(multiple times a second), at the same time constantly checking the relative 'stealth' and 'detection' levels between every character and determine who can see who, the determine any broadcasted locations via abilities that would reveal stealthed targets.
If 50 people are standing in proximity of eachother, and stealth is magically 4 calculations, that is roughly 10,000 calculations per refresh.
Then the issue is one of calculation mitigation, which is also a fundamental aspect of game development. In that case ability usage should be instanced (i.e. sampled every so often instead of being part of every single game tick). For sake of simplicity let's say there's only one stealth check every 5 seconds. To also keep it simple, let's use Pathfinder style skills, something I think we are familiar with. So, once every 5 seconds the RNG kicks off, rolls and stores that result plus my stealth mod. Anything else that comes along makes a passive perception check similarly only does so once every 5 seconds, rolls the RNG, adds perception and stores that result. So, you don't need to roll new checks every single refresh. That would be ridiculous.
To make such a system even better, you could actually store these results until an event happens where calculation should be redone such as collision with an object, casting a spell, making an attack, using a pair of binoculars, etc. So, I stealth, my stealth score is evaluated, and while I stay stealthed I just keep using the same result and the same is true with everyone around me. Until something happens where things *should* be evaluated, the stored numbers are compared rather than these checks being calculated each and every time.
Also, keep in mind anything remotely close to a 3D modern game uses occlusion culling (http://en.wikipedia.org/wiki/Hidden_surface_determination) to make things much much easier and performant. In your 50 man example, that only makes sense if everyone is standing in a circle in an open field and everyone is within the visibility threshold. Any other configuration, or one with trees, buildings and other objects (i.e. the actual game) will further occlude objects from every being processed in the scene graph.
At best you'll likely only have a handful of people to calculate values for. Futhermore, you should only be running these checks for characters actually employing stealth. Normal characters should simply utilize a range/occlusion check. For anyone being stealthy in an area they bump up a bit but it's far from an n2 operation unless everyone is stealthing and then the system I described above should be used instead of making fresh samplings each and every frame.
If by "the game" you mean "the server", then I think this is not accurate.
How not? What should the client be reporting to the game server other than "player pressed forward button," or "the player pressed in the inventory key," or "the player attacked," or "the player cast fireball in direction x,y,z?" The responses to these inputs should be such as "your position is now x,y,z," or "these are the items in your inventory," or "you hit/missed/did x number of damage," or "you hit actor x (which doesn't have to be a character, it can be a tree, for example)," respectively.
Anything else is unnecessary bloat and opens your game to exploitation as packet intercept hacks can easily make it so you can do almost anything and then the server actually has to do more work to ensure what you want is even possible regardless of context (e.g. a game having to check to make sure you legitimately cast a spell during a loading screen is inefficient at best).
I know I'm sounding argumentative but really, in this case, a =/= b in the case of stealth and all clients *must* know where you are. The game industry has been around long enough to have addressed issues like like coming up with techniques on when to perform fine-grained calculations and when to use sampling instead. I can't see a situation where an MMO *has* to broadcast *all* actors within a certain radius unless you're trying to do something mechanically with the code that you, as a game developer, always want that data available. It honestly sounds like code that escaped a debug release that never got removed later on rather than a planned, intended feature.
|
Goblin Squad Member
|
At best all the game client should do is report your actions to the game but the game takes over from there already. This is the standard way to implement an MMO platform...If by "the game" you mean "the server", then I think this is not accurate.
How not? What should the client be reporting to the game server other than "player pressed forward button," or "the player pressed in the inventory key," or "the player attacked," or "the player cast fireball in direction x,y,z?" The responses to these inputs should be such as "your position is now x,y,z," or "these are the items in your inventory," or "you hit/missed/did x number of damage," or "you hit actor x (which doesn't have to be a character, it can be a tree, for example)," respectively.
Anything else is unnecessary bloat and opens your game to exploitation as packet intercept hacks can easily make it so you can do almost anything and then the server actually has to do more work to ensure what you want is even possible regardless of context (e.g. a game having to check to make sure you legitimately cast a spell during a loading screen is inefficient at best).
You weren't talking about how things "should be" when I quoted you. You were describing the current "standard way to implement an MMO platform".
To my understanding, the "current standard" actually involved the Client doing quite a few calculations: range checks, stealth-detection checks, effect timers, cooldowns, etc.
You'll get no argument from me when you say it could work a different way and get a different result. But, as I said in my first reply in this thread, that would require a lot more processing to be performed on the server, which I believe would be a significant departure from the "standard way to implement an MMO platform".
|
Goblinworks Executive Founder
|
The current model has the client do a lot of data interpretation, but the server validates everything. The client tracks the cooldowns as a service to the player, who wants to know when the cooldown is over. The server also tracks the cooldown, and rejects any attempt to use that ability again until the cooldown expires. The client doesn't generate any random numbers, such as skill checks or damage values.
The client also does all the UI stuff and rendering and non-vital physics. Also, the current paradigm is for the client to handle all of it's own movement, with regular position updates that are validated by the server. That's been standard since the start of remote multiplayer gaming, and I saw exploits enabled by the server NOT validating the new location as far back as the late 90's.
|
Goblin Squad Member
|
@Buri - 100% agree, you better expressed exactly what I have been arguing. Since security is such an issue that that the world needs to be designed around those who might cheat (for instance, no darkness because someone will cheat), the client should handle all the art assets and UI only. This is the logical extension of previous rationales.
|
Goblin Squad Member
|
I know I'm sounding argumentative but really, in this case, a =/= b in the case of stealth and all clients *must* know where you are. The game industry has been around long enough to have addressed issues like like coming up with techniques on when to perform fine-grained calculations and when to use sampling instead. I can't see a situation where an MMO *has* to broadcast *all* actors within a certain radius unless you're trying to do something mechanically with the code that you, as a game developer, always want that data available. It honestly sounds like code that escaped a debug release that never got removed later on rather than a planned, intended feature.
Yeah, I agree with you. I didn't understand the logic behind that statement from Ryan either. He did make another valid point earlier though... which is if one player does detect where a stealthed player is at (i.e. made his "spot" role).... then that player could transmit that info out of band to other players on his team via a hack. The other players wouldn't neccesarly be able to ACT on that info by targeting the stealthed player, etc... because the server would still know that target is not SUPPOSED to be visable to those other characters.... but in terms of pure information disclosure, it would work.
That's the part of the stealth being "all or nothing" that made sense to me.
|
Goblin Squad Member
|
The current model has the client do a lot of data interpretation, but the server validates everything. The client tracks the cooldowns as a service to the player, who wants to know when the cooldown is over. The server also tracks the cooldown, and rejects any attempt to use that ability again until the cooldown expires. The client doesn't generate any random numbers, such as skill checks or damage values.
The client also does all the UI stuff and rendering and non-vital physics. Also, the current paradigm is for the client to handle all of it's own movement, with regular position updates that are validated by the server. That's been standard since the start of remote multiplayer gaming, and I saw exploits enabled by the server NOT validating the new location as far back as the late 90's.
I'm guessing the rationale behind that has to do with client responsiveness and latency? Otherwise that design doesn't make much sense from a resource efficiency perspective. Anything important that the server has to validate you'd be processing TWICE....once on the client and once on the server... so that model wouldn't really save anything in terms of server resources...it has to do all that processing anyway. It's possible it might even be more resource intensive on the server...since the server would have to calculate not just what the client DID do (i.e. user pressed W key for 1.5 seconds) but what the client COULD do (i.e. move from X,Y to X-2,Y-3).
The only reason I can imagine it might make sense to do that on the client side first then validate on the server would be you wouldn't need to wait for a server reponse to update the UI with the new info, thus it feels more responsive to the user...and if the server invalidates an input then the client adjusts (i.e. plays catch up) when it gets that response back...rather then waiting for the response in order to update.
The server and client do have to run asynchronously with the client treating the server as an authoritative source even over itself. This is why you can be running along and you "snap" back to an earlier spot because your client lagged and the server sent a "no, you're really here" message to the client. So, while the client is playing the animation of the game, the server does need to spot check things and send corrective information to the client so everything stays in sync.
So, some things will always be doubly calculated but concerning actor visibility, that is something that is sent to the client anyway with new players popping in and out of the game around and, in the case of a stealthed character that is more stealthy than you are perceptive, the server simply negates to inform your client that character is there.
Several games already do this as there are invisible "gm only" characters so that devs can interact with the client and the game world but often these aren't visible to everyone else. To implement stealth, basically, instead of doing an IsGM check you simply do IsVisible and have that function evaluate if one character can see another.
I was thinking last night about the 10k calculations number that Valkenr mentioned and why that really didn't phase me. Here's why.
On a single-core, 1 GHz CPU that only represents 0.00001 of the processors time. Given that most modern CPUs are in the 2 - 3 GHz range, that comes to 0.000004 (there's an extra zero in there in case you don't see it). Also, considering this is most likely done with stat checks (stealth vs perception) which is just boolean based greater than comparisons, this can be split into an asynchronous job. If it is, let's assume it's spread out against just 4 cores, because really, if you're running an MMO and running anything less then you're just not doing it right. I can almost guarantee you that an average WoW server is a dual socket, 10-core a piece Xeon behemoth.
That comes to 0.000001 second. 6 cores: 0.0000007. 8 cores: 0.0000005 quadrillionths of a single second. These are minuscule fractions of a second. On a single server. For 50 people. The speed of the human nervous system is much, much slower than this only reaching speeds of milliseconds. To scale it out, the time it takes your finger to tell your brain you're touching something, we could do these calculations about ten thousand times.
|
Goblin Squad Member
|
Just like it's silly to try to psychoanalyze a celebrity based on seeing them on TV a few times, it's silly to try to analyze the server load on PFO to determine the impact of moving client-based processing back to the server. There is far too much relevant data we don't have access to.
But just for the heck of it, how do your calculations work out when you've got 40,000 active connections, and 20+ different battle areas each with 100+ players involved, and 100+ different battle areas with 20+ players involved.