I've been thinking about a bunch of different things over the past few days and I ended up with two questions to ask about how to code multiplayer (online) games:

1.) When coding a multiplayer game should you create a server.jar that would have all of the important classes that do the damage calculations, movement of players, collision detection etc... and then just have a client.jar that would send information to the server and then get back the damage, where the player can move, etc... or is there a better way to do it? (I'm just thinking about how this would work, I'm not actually making anything like this atm.)

2.) Say, for example, you had a game with multiple different players with different characters that have different stats and say each player is looking at a menu that displays all of their stats. Would having the client (player) sending a request to the server for the stat information to display be an acceptable way to get the information or would it be better for the stat information to be located in an encrypted file on the client's computer where it would be updated by the server if the stats change or is there a better way to do this?

I dont have much knowledge in the area of networking, but I think i can help a little!

1. You should definitely use a seperate server and client. That way the client cant access the information on the server and hack it. The player could alter his stats or anything he wants to do really. The only real problem with seperate servers and clients is the response time, or the ping. Obviously, the farther away you are from the server, the more 'laggy' it will feel. So you should minimize the data transfered between them.

2. It depends if you want to allow the player to play offline. If you save a copy of the stats to the players computer, he can play singleplayer. However, he may be able to hack into it and change his stats. So it really depends, do you want security or the ability to play while not connected to a server?

I figured that problem would come up in number one, I'll assume it would be safe to have the majority of the non-calculation related code on the client side to minimize the data transferred but that probably wouldn't save too much data. As for number two lets just assume the game would be online only.

Cheating would definitely be the main thing I'd want to prevent. Would there be a way to encrypt certain packets of information being sent from client to server as to prevent packet editing by the player and would this be more of a pain to use or would it be useful?

I don't really think you actually need to encrypt data. Doing so would ruin own gameplay. But like I said, there's always a way around cheating.

For example, when sending position to the server, you don't actually send the position itself. If you do that, you can do teleport hacks. A way around this is sending what keypresses the client sends. The server handles that, and sends keypresses/positions out. Then in the client, you interpolate between current and last received position. You achieved smooth/anti-cheat movement.

And of course, if there is anything "fishy" about the data you received from a client, you can tell that there's some sort of hacking going on.

I don't really think you actually need to encrypt data. Doing so would ruin own gameplay. But like I said, there's always a way around cheating.

For example, when sending position to the server, you don't actually send the position itself. If you do that, you can do teleport hacks. A way around this is sending what keypresses the client sends. The server handles that, and sends keypresses/positions out. Then in the client, you interpolate between current and last received position. You achieved smooth/anti-cheat movement.

And of course, if there is anything "fishy" about the data you received from a client, you can tell that there's some sort of hacking going on.

This is how I would do it. The only problem is again, the ping. It really depends on who your player base is. If its just a couple friends, I wouldn't do all that anti-cheating stuff because I don't think my friends would cheat. However, if you're planning on releasing the game to market, you will definitely need to do it.

I don't really think you actually need to encrypt data. Doing so would ruin own gameplay. But like I said, there's always a way around cheating.

For example, when sending position to the server, you don't actually send the position itself. If you do that, you can do teleport hacks. A way around this is sending what keypresses the client sends. The server handles that, and sends keypresses/positions out. Then in the client, you interpolate between current and last received position. You achieved smooth/anti-cheat movement.

And of course, if there is anything "fishy" about the data you received from a client, you can tell that there's some sort of hacking going on.

O.o I would have never thought of that, thanks! The original reason why I suggested the encryption would be from this scenario:

User cooks food in the game, this causes the client to send a notification to the server that the player just gained X amount of XP.

The user edits the packet being sent and makes the server think that he/she just cooked 100 of the item instead of just 1.

The server adds the xp for 100 items to the cooking skill of the player instead of just 1.

I just thought of a possible work-around for an scenario like this while typing. The client could just send a packet containing the item that was cooked and the amount cooked instead of the actual xp values, but I guess you could still edit the packet and say that more than one item was cooked.. =/

For these situations just assume that the game is online only and the players are, say within 500 miles of the server host.

Yeah, this server thing is a huge logic thing, and requires a lot of thinking. For the cooking thing, you would only send that you cooked something, and what it was that you cooked. On the server side, you would check that the player had the raw "whatever" in the first place, and maybe have some sort of limit on how fast you can cook. On server side at least.

Yeah, this server thing is a huge logic thing, and requires a lot of thinking. For the cooking thing, you would only send that you cooked something, and what it was that you cooked. On the server side, you would check that the player had the raw "whatever" in the first place, and maybe have some sort of limit on how fast you can cook. On server side at least.

That would probably work if the character data was kept server-side, guess this isn't as impossibly tough as I was making it out to be in my head.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org