Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm making a game which will be completely centered around PVP battlegrounds and arenas. Think something like WoW, but with the RPG part removed. There will just be a lobby, where you can join a battleground and fight. I plan to use WebGL with the Three.js abstraction.

So, making a game where people can just hit each other isn't my problem - I'd like to have physics play a big role. I simply don't understand how is that possible with open source clients (open source, because it's a website)!

Also, by physics I mean things like burning logs rolling over from a hill, spells that send everything flying around, possibility of dying when hit by a high-velocity object, and so on.

I seem to have only two options:

A, do the calculations on the server

B, do the calculations on the client side

With A, the problem is that I plan to use some plugins for collision detection, and I need to have all the meshes and bounding boxes to test, which I only have access to on the client side! Also, physics might be just a bit too much for my servers to handle.

The obvious problem with B is that you can never trust the client. If I depend on the client telling me that the player got hit really hard and that he did, in fact, throw the player somewhere, that's an obvious security hole. The user can make a simple script that blocks any messages with a "he got hit" header or something, and become invincible.

But, while I was writing this, I came up with a third option, which is to let the client care about others, not just about itself. This falls under the reality checking category, I believe, because if the majority says that someone got hit, and he says he didn't, I'd trust the majority... This option's flaw is that it might be a really big strain on the clients, because this will be a browser game, and my resources are limited.

share|improve this question
1  
On 3rd: imagine a bunch of script-kiddos connecting as a team, and all are saying, that they didn't get hit. Bunch of invincibles, damn. –  joltmode May 21 '12 at 8:21
    
Then I simply don't care about them! Let them have fun, if they're the majority, and they're in their own instanced battleground, they aren't really hurting anyone. In order to get money/XP/items you need to kill other players, and if they want to remove the best way of killing each other, let them have it... –  akled May 21 '12 at 8:26
2  
What he's saying is there can be a team of 5 players all stacked on a team, with a single sixth player on the enemy team (probably a bot or afk) all claiming that their buddies never get hit and that their enemies always get hit. –  SomeGuy May 21 '12 at 9:30
1  
Basically with the third your battleground will be a place where the hackers win. Have you heard of a popular game that is rife with hacking, or one that became that way and stayed popular? No? Me neither. –  Jonathan Hobbs May 21 '12 at 9:54
add comment

2 Answers

up vote 4 down vote accepted

When you do AOE, you can use player-sized cylinders for AOE detection. I think Quake does it this way.

Now for the physics question.
There are several solutions I can think of:
1) Do it all server-side, use simplified meshes and bounding boxes, optimize everything.
2) Split into ranked and unranked battlegrounds (instances), and give players the ability to host their own server. Of course, ranked matches would have to be server-side.
3) Somehow authenticate the client (hard to do in JS)

share|improve this answer
1  
Definitely a good idea to use the simplest shapes possible. MMO's could probably get away with square/cylindrical hitboxes. –  SomeGuy May 21 '12 at 10:17
    
Yeah, as I said in the comment above, I'm thinking of making a simple sphere around every moving object (not a sphere, but something analogues to an eclipse, just in 3D)... –  akled May 21 '12 at 10:18
1  
@Bane: In case you stick with that, I think the technical term is spheroid. –  SomeGuy May 22 '12 at 1:42
    
Nah, we decided to go with cylinders, they make much more sense and are easier to do calculations with. But thanks! –  akled May 22 '12 at 6:24
add comment

You never want to do physics simulation or game play calculations on the client if at all possible, because the client is assumed to be cheating at every opportunity. Calculations should be done on the server and handed down to the client from on high, and the client should have to accept the word of the server.

That isn't to say you can't simulate physics or do calculations for the sake of smoothing out the client's view of the world, but the final say should always lie with the server.

Frankly, I would first worry about getting the game up and running in a (moderately) playable state, and then worry about the load you place on the server. If the calculations turn out to be too complex and the game starts to lag a lot, that's when I would do optimizations.

share|improve this answer
    
Well, it isn't even a problem with the server load, I just don't know if I'll be able to do it! As I said, I planned to have some pre-made libraries for collision detection and physics, which are obviously out of question on the server side... I might just make all the bodies have a sort of sphere around them, that would ease up the calculations, maybe. I'm looking for a more "practical" answer, if possible. –  akled May 21 '12 at 9:44
    
Well the question is pretty general :P. All I can really recommend is that you start small. Square hitboxes will do, as will spells that simply knock back in a straight line X units, etc. As long as you do simple things first and work your way up, there's not much that you cannot do with enough time and energy. –  SomeGuy May 21 '12 at 9:49
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.