Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Question about collision detection?
Gintoh
Member UncommonPosts: 329
I'm not coding i'm just wondering randomly for a reason that would take to long to explain. If you put "collision detection" on a npc (so that you can't walk through it) that's walking around town, and you want a player who stands in front of him to be pushed as he walks so that a player can't block his path. Would putting the collision detection on him be enough to make the player pushed back as he walks or would you have to put in a whole seperate code for the player to be pushed.
Comments
It depends how you handle collisions. Detecting a collision is only one part of the problem. What you do with that collision is another.
I skate to where the puck is going to be, not where it has been -Wayne Gretzky
That depends very strongly on the precise details of how collision detection is implemented in the particular game in question. Collision detection is hard, and making it match the graphics exactly is computationally intractable in most games, so games have to take all sorts of shortcuts that can do weird things.
Also, what Quirhid said.
What do you mean?
Also why is it hard? Couldn't you just put a little circle around the NPC to make it so you can't wlk through the area? What do you mean "match the graphics?"
It just depends on how the game's mechanics and physics are written. Is the game written with a general purpose physics system? For instance, each object has a particular mass, so when two objects are interacting, the physics system uses the mass and velocity of the objects to determine where things move. Or, perhaps the system is written so that NPCs always "win", regardless of mass. In either case, 100% of the interactions are coded into the system, but in one the results are determined somewhat procedurally, and in the other the results are predetermined.
I can not remember winning or losing a single debate on the internet.
Technically collision detection doesn't *do* anything, it just looks to see if there is a collision or not.
Inside the gameloop, every frame you'll have it asking if there's a collision. Usually it will be "false": no collision for the game to worry about.
Collision detection in it's pure form, just tells you "true" or "false". It's when it tells you "true" that you decide what happens:
- Collision with a plasma grenade, it sticks to you
- Collision with a jeep, you get run over and you respawn
- Collision lava, you catch fire
- Collision with a wall, your movement in that direction doesn't happen.
- Collision a bullet's path, you lose hit points.
- Collision with the end of the level, you get an annoying loading screen.
- Etc.
Of course most game engines and physics engines try to expand on that and make their own improvements for coding efficiency, or trying to mimic the real world. That's where concepts like "mass" come in. Every engine will have its own way of doing things.
The thing to remember is that in a MMO the server would have to do a lot more collision detection if they also do it for Players colliding with NPCs/MOBs, instead of just Players colliding with trees for example. MMOs always make collision detection as simple as they can get away, so yes just a square, rectangle, or a box. With 1000s of players it adds up.
Ultimately, it would mean the server could support slightly less people.
(You could try to make the less important collisions be done client side, but you can bet that players will find it, and find a way to abuse it)
Well, I mean pillars have collision detection that prevents people from going through them, wouldn't it just be like having a lot of pillars in the world? Like every mob would be like a pillar?
Also I don't think PC's should have collision detection, bc griefing. I think an npc not walking around a player is still more immersive then it going through the player.
over 20 years of mmorpg's and counting...
Yes, it would be just like pillars.
Collision Detection is between 2 objects, the (box around the) Player and the Pillar, or the Player and another Player.
Whether or not there *should* be collision detection between two objects is a question that's up to you the game designer / programmer.
Pillars doesn't move, while NPC does. With collosion detection, it just going to bring in lots of complication. Group of players can push NPC together to block city gate like a pile of zombies in World War Z just for a laugh and annoy other players.
It's also possible to push NPC to stand all over the shop or quest givers, make it impossible to push through to interact with the main NPC.
If main NPC can be push also, someone would have push such NPC away to make it stuck somewhere hard to find or reach, make the game unplayable.
There are many ways you can ruin the game by just having collision detection in the game with many real people.
No but I mean people couldn't move the NPC's, npc's could move the player if they're walking or something.
My point is how much strain would that put on the game, since as I said, pillars have collision detection and you can't walk through them so it would be like having a lot of pillars in the world. WOuld a lot of pillars put strain on the game? I don't know so that's why i'm asking.
Yes it would. Collision detection with a static object such as terrain, can be handled client-side and is relatively straightforward: The game engine might not allow you to move inside the terrain in the first place. Collision between dynamic objects are traditionally calculated server-side. The orders of magnitude how much this would put more strain on servers is hard to estimate and would vary from game to game.
I skate to where the puck is going to be, not where it has been -Wayne Gretzky
So NPC would be like a tank, I see.
It would certainly take a bit of performance out from the client, and the server, depend on the engine. What would bring the performance down is depend if player would play animation as they being push by NPC or not because animation need to be verified by both client and server, how much force they being push, and how far they will be push out for. Pillar is a static collision detection so it just stop player from moving through that area, not being push.
If you do the collision detection server-side, yes it will put a little bit more strain on the server, everything does, but I doubt it would make a very noticeable difference. It won't be the feature that breaks the camel's back.
NPCs moving around won't make any difference, stuff moving around is what collision detection is for.
If you don't care about players being able to cheat it, (You seem to be aiming for immersion, not cheat-proof blocking of players' movement), then you could probably get away with having the collision detection for this on the client side, block the player's movement command from being sent to the server when moving into the NPC. You could probably make "Pushing" work after some trial-and-error. That would mean no strain on the server at all; but glitches will be a bit more common than the other way, also players could create cheats to move through NPCs. If it's only aesthetic then you might not care about that.
So you agree, doing it server side would be like having lots of moving pillars in place of mobs? And that that wouldn't slow things down too much? correct?
But wouldnt the checking to see if there is a player there to detect the collision for the players movement signal have to be done server side? Or no?
It check on server side just to make sure player position are sync with the rest of the other players, and to make sure that there's no cheating like how some player managed to cheat through collision detection and hide inside terrain while attack other player and other player can not attack back.
Yes.
Normally, yes.
The reason that just about everything is done on the server is that you can't trust the data coming from the client.
If you are using NPCs to strategically stand-their-ground and block a player from leaving a building during a quest; then yes, you'd want to do that on the server.
But if you are just doing it for-looks, (This is a bit of an "El Cheapo" solution) you could get away with doing it on the client-side and 99% of the time it would keep non-hacking clients from going through NPCs. The server would not be looking to make sure the NPCs don't go through Players, but the client could see the NPC comming and move it's Player back when the NPC hits it. You could even have the client display a player in the wrong place if the player is inter-meshed with the NPC due to a glitch or hack.
Yes, that solution is a bit of a hack-job, but possible.
strictly speaking, "collision detection" does none of the moving, or even stop a playing going through a NPC.
All it is ... is to trigger a flag to say "player A is not bumping into NPC B". What happens next, needs additional code. It can be something as simple as:
- NPC B is not moving, and impassable, so all the command to move the player pass B (in that direction) is ignored, or
- There will be a physics simulation of player A colliding into NPC B as an elastic collison, and player will lose control of the movement for 3 seconds
... or anything the designer would like to code.
We had this in Warhammer I believe.
It should be in all mmorpgs. The fact that folks can walk through each other is a sign of old school programming. Perhaps chock this one up to what needs to be part of the evolution of the industry. A shield wall of armored men in front of a gate should mean something.
Here's to adding as much reality as possible to a fantasy game in order to help it feel more immersive. This should ALWAYS be the goal (making one's mmorpg immersive).
IIRC, collision is only with players vs players in Warhammer Online. Players who are created in the same realm and not engaged in combat, the NPC and other mobs still walk right through each other to prevent griefing.
It's not old school programming, but it's a feature to avoid player griefing each other in PvE.
Log into any game, try to run into a wall, and see what happens. Most likely you either get stopped well short of the wall or else you punch into the wall. As the latter tends to look worse than the former, games usually err on the side of stopping you short. I can assure you that this isn't because game designers want to give the impression that actually touching a wall means instant death. It's that stopping you right at a wall graphically is very hard to do.
And that's with one of the objects a simple thing that never moves. If you want a moving object to push a player, it gets a lot more complicated yet. Exactly which direction do you push the player, and how far? Should it depend on which way the player is going? What if the direction that you want to push a player has something else there that's supposed to block him? In some games, this has created exploits where you could abuse it to walk through walls or otherwise get to areas that you shouldn't have been able to.
Now what if a player collides with not one NPC but two? What if one tries to push him into another? What if three NPCs approach the player from different sides and try to compress him?
Some things can be calculated client-side, but as Quirhid notes, collision detection with anything that moves has to be done server-side. Otherwise slight discrepancies in where a character is believed to be could push him one direction on one player's screen and a different direction on another player's screen. Rubber banding from the server having to correct the player's location gets rather annoying, especially if the server takes too long to detect it; Guild Wars 1 has a rather bad case of this.
Furthermore, when collision detection is done client-side, you can do it on a frame-by-frame basis. That is, you can say, exactly 21 milliseconds have passed since the last frame, so where exactly are all characters in this new frame? But the server doesn't know when the client is going to start rendering a new frame, so trying to keep it consistent for all players even as different clients display the game world at different times opens up a bunch of new issues to address.