Sending weapon data over the network

Networking & Multiplayer
#1

I am at the point in my game where I can send weapon data over the network. For example, the tank can either shoot the 100 mm gun or the 7.62 mm machine gun. Each can be modified based on officer abilities. For example, the officer can increase the damage of the 100 mm gun by 10% and the 7.62 mm machine gun by 30%.

So I have two options:

1.) Have the client calculate the damage based upon the weapon type and bonuses. Sends it over the network.
2.) Have the client just send an ID number for the weapon with any bonuses (For example, if the officer was present, it would send 1-1 [ID for weapon and ID for modifier]. Then have the server do a lookup and the math and execute the results (Check to see if it’s dead, etc).

Which way is better? How much should I trust the client? I want to store everything in a DB on server side and that would be very very difficult to do if I go with option 1. But, if I go with 2, the server will be spending more time calculating out these things rather then handling other requests.

Any thoughts? Ideas?

Thank you!

#2

Never trust the client.

And … your server will have more processing power than you will manage to use up, most likely. Don’t worry about it until it actually becomes a problem (unlikely). Remember it doesnt have to do any graphics rendering, which saves a lot of CPU, and that the average CPU is approximately 10,000 times as fast as the average net connection.

#3

I don’t agree 100% with bla. I’d formulate more like that:

‘If you have to avoid cheating, never trust the client.’

If cheating is not an issue, trusting the client opens a wide range of options to simplify logic and protocols and save a lot of bandwidth. It often allows for better feedback.

In FlyingGuns, the shooting client analyzes wether there is a hit and calculates the damage. Then it transmits the damage to the targets client. On the targets client, the damage is evaluated and e.g. makes the target smoke or explode.

This way, no networking handshake is necessary, just a store-forward. Second, the experience is believable, bc. a perceived hit on the shooters side in any case is a hit. So no network artifacts show up.

Of course, a cheating client will always win.

Saying that, concerning your specific questions, I wouldn’t transmit the officers state with every bullet bc. that is completely redundant and a waste of bandwidth. I’d share the officers state separately or calculate the damage on the shooting side (if thats possible).

#4

And I agree with blah^3 :slight_smile:
Everything vital for game should be on server. Your client then simply says “I’m shooting with 7.62mm weapon in X direction” and server would calculate all bonuses (in this example it would see that player has an officer and it would add 30% to damage).

@Herkules
Calculating on client may be good for small games like most of people on this forum are making now, but I don’t want to make them forever. Once I would like to be a part of a team that is on the top of game industry :slight_smile: … and that requires learning how to do everything the best way, in this case doing everything on server.

#5

@Kova - The “best” way can be different for each game, most top engineers realise that analysis of the problem/scenaio is the important part - not over generalisations like “everything must be done on the server every time”. Rash assumptions like everyone is working on small scale games arn’t a great move either - especially of recent times.

Blah’s absolutely right on processing power tho, unless your calculations are massively complicated I wouldn’t worry too much about processing power on the server.

There’s also another couple of options:

a) If all the clients know the weapons and bonuses each player has (most of the time this holds) then use a predicatble random generator on all clients and let them all caculate the damage without sending anything but the fact that one fired (this appears to be how Neverwinter Nights Works in most cases)

b) Have the client do all the caculations but have the server check the clients results every now and again - if a cheat is detected then flag the client out of the game. Counter strike did this sort of thing.

Kev

#6

I also don’t thinks it’s a matter of game size or complexity.

Military simulations e.g. are highly complex and don’t do everything on ‘the server’, which doesn’t have to exist at all. Interesting enough that mil. simulations don’t care for cheating :).

In contrast I think the more complex and the more exact things have to be, the more you have to rely on the client.

Imagine sitting in a fighter plane giving a single shot at an opponents plane aileron from close distance, being sure that is must hit the target. You also need visual/audio feedback much sooner than a network roundtrip would allow. In this case, only your client can determine the hit. The server cannot do that for it only has a vague impression of what you see on the screen and maybe doesn’t have the detailed mesh of the target for the exact collision bullet/aileron.

All the server can do is saying: ‘well, ok, the player still had ammo and their (estimated) relative positions/orientations make a hit feasable’.

Letting the server decide leads to situations where you hit a target over and over w/o giving any harm to it. Depending on the gameplay this can be very annoying. (note: I said ‘depending on the gameplay’!)

#7

This conversation has gone to wide… you are all right, it all depends on the game. Since we don’t know anything about the game, I can only suggest the “standard client-server approach” used in most of games (I guess, don’t have any statistics) which I have described. Other solutions of our forum gurus are worth considerating.

#8

Military sims are not games, and if you cheat you get a court martial (gross simplifcation, but basically: you would be a complete moron to cheat, you would seriously damage your career).

Well, I’m afraid that Half Life and friends (including Unreal Tournament now, IIRC) starting with HL2 IIRC do what you do, except they do it on the server, so it’s perfectly feasible.

The phrase is not “never calculate on the client”, it is “never trust the client” - a good game will calc on server AND client (as Kev pointed out, this requires full determinism, i.e. shared-seed RNG’s) and display on the client but process logic on the server (server-authoritative).

#9

Yes, the real answer is of course much more complex and takes into account many factors, but the short answer is not to trust the client. Averaged out, there’s rarely a good reason to trust the client, and if you know what you’re doign enough to make that decision, then you wouldn’t be asking whether to do it on a forum like this :). My initial answer was just giving the simple “follow this and you won’t go wrong” answer.

#10

Thank you for your replies. All replies have been very interesting.

I want to ensure that cheating does not occur, which is difficult to do. I am thinking that the safest way is to allow the server to do the calculations. Though, I believe I could allow the client to do some calculations of the damage and then do a quick check when the data hits the server. If something seems funny then we can set some flags and correct it. In the above example, if the damage of a 100 mm gun is (to make things easy) is 100 and with the officier’s bonuse it would be clearly 110. So I can then do a check in the range of 70-150 and if it’s anywhere in there, then do nothing. Then I’d have to do send ID of weapon and damage. Then check against the server’s copy of the weapon and the range based on known %'s for all bonuses.

I will experiment doing it both ways and see how things work out. You know what works best by trial and error (well, when you have little experience such as myself). This is my first time doing any networking for a game and it has been a most interesting journey. I am always second guessing if I am doing the right thing because I have no experience. I am worried that the game will not be able to handle large amounts of players, but, we shall see. We shall see!

Thank you again and reply if you have any thoughts on what I have said just now.

#11

One thing, if you are going to check the client why not check it for exact calculation? If you are only going for a range min-max then cheat could be made for always doing max damage. Complexity of doing this depends on your game and what server knows about clients, but generaly it is easy to do in most cases. Even if server dosen’t have all the data, you could send all data every now and then along with regular messages and then server should be able to check everything. This shouldn’t affect bandwith much since data is mostly bytes (type of weapon for example can be stored in a byte, except if you have more then 256 weapons :slight_smile: ).

#12

I would usually agree, never trust a client. But in fact, when talking about hobby games, hardly anyone will spend effort to crack it. There may be a few buddies that like the game enough to play it in multiplayer. But Hobby Games will hardly ever get used so much, that cheating is an issue. When playing World of Warcraft or Halflife 2 or such games, cheating is an issue.

But when I have the choice of easy programming or cheat protection, I choose easys programming. I wonder if even 100 people ever play multiplayer in a Hobby Game. The game sure has to be quite good. These players will play with devotion, they probably wont cheat even if they could.

In short words, I do not expect the people which like my game that much that they play it together to cheat.

-JAW

#13

Well said! Just my thought.

I’d by so lucky if anybody tried to cheat FlyingGuns!

#14

I’ve seen many, many games with 100 or so players that have been cracked. Usually by faking high-score data onto an internet scoreboard (since that’s usually so easy).

You don’t learn much by making deliberately insecure games, and usually it takes very little effort to make a game reasonably secure, so IMHO there’s not much point in making a game knowingly insecure.

#15

OMG! :slight_smile: I agree with Blah^3. Just because you don’t think your game isn’t going to be big news, doesn’t mean that you should just ignore appropriate analysis and design - unless of course you just don’t care :slight_smile:

That doesn’t mean you can’t trust your client - it means you should spend some time considering whether you can.

The only decision I can think of that you can make based on whether you think anyone is going to play the game - is whether to write it at all :slight_smile:

Kev

EDIT: Coo, smiley overload.