Hot answers tagged client-server
32
Keep all your game data and logics on the server. Part of the game which is on the client side can be copied using appropriate tools anyway (even if it's in Flash or Java), so just accept it and don't care too much about it.
To keep your javascript less copyable, because of bad readability, you can minify it. That's a good practice anyway as it makes the ...
18
You should prefer to keep your rendering code separate from your game logic, as they are separate concerns.
If you separate your rendering code from your client/server code, you get a couple of advantages:
Creating a dedicated server will be easier, as any code that renders will be in one place.
You can separate your update phase from your render phase, ...
16
Don't trust the client.
It's as simple as that. Any safeguard you can put in place can be broken; and truly safe methods are impossible within the scope of JavaScript.
The best approach is to only trust the client with drawing what you send it and retrieving user input. Giving it anything more is just asking for trouble.
Any information you send to your ...
13
If it's not a "real time" game in the sense that players don't need to see the immediate result of another player's actions on a game scene then you should be fine with HTTP requests. But Keep in mind the overhead of HTTP.
That said using HTTP will not save you from designing your communication protocol with care. But if you are in charge of both the server ...
12
Since you use a central server, the server will keep track of game events and clients will sync their state with the server state. When a message is received by the server at 12:02, the message should show up at the client as being sent at 12:02. However, when dealing with different timezones, you want the client to display local times. This is more ...
12
You only need about 30 updates (or even less maybe 10 or 20) per second. interpolate the positions of moving objectts client sided.
In general you should only send data when it's REALLY needed.
In WoW you might receive more updates from the players you are in a group with than from the players that are in the same location.
Also, if another player is far ...
12
I once found a very neat quote on the net that's very, very true for any online game:
The client is in the hands of the enemy.
As such, you can't really avoid people doing nasty things to your game client.
Due to this, don't trust the client at all, i.e. everything important should at least be verified server side (better: calculated there). If this is ...
10
I'll rather delve into the problem you are having with network latency: it's unavoidable. Network programming is a fine art and much more psychologically involved than tricking the eye (as you do with graphics programming); people are very sensitive to their perception of time.
What you essentially need to do is do prediction on the client. For example, in ...
10
There is nothing on the client side which can not be faked, everything somebody has physical access to can be manipulated.
The IP contains routing information and thus hints on the location. But the player just needs a proxy and whoops... the IP hints at a completely different location than the player actually is.
Trust your players, don't give them a ...
10
You can use an IP geolocation service to obtain an approximate location from where the user is connecting. Compare this with the GPS data received and you can weed out some extreme cases (players connecting though proxy, etc). You can even calculate distances between user logins and if they are too high (say, the location moved 1000 kms between two login ...
9
how you could prevent someone from simply copying the JavaScript from the web server and either making their own game with it (not my biggest concern)
This is where the law helps. In practice this doesn't seem to happen very often.
or substituting their own JavaScript functions and dashing any hope for reliable clients in the wild if the game was to ...
9
You will probably need to micro-manage the 3G modem to ensure that you don't have delays while it switches power modes. Your simple answer is make sure you send at least one packet larger than 128 bytes every 6-8 seconds. If you can guarantee that all your packets are smaller than 128 bytes make sure you send something once every 6-8 seconds. Avoid, at all ...
8
Unity's built-in networking is RakNet. As far as I know, inside Unity it's only really for peer to peer games (i.e. you can't really run a standalone server).
Most web games I know of that use Unity and have multiplayer use Exit Games' Photon. Paradise Paintball uses it. So does Atmosphir. You write server code in .NET that gets compiled to a DLL and ...
8
I recently made a asteroids/geometry wars crossover with Node.js / JavaScript:
http://github.com/BonsaiDen/NodeGame-Shooter
It has a fat Server which processes the game and thin clients which are basically just views.
The client does some interpolation and things to make it look smooth.
You may want to look at these two files, which contain the underlying ...
8
My suggestion is to have your game communicate to a web service that you created that itself deals with querying the database. At that point, it's very simple to try different kinds of databases by "switching" web service implementations (your web service interface always stays the same so your game doesn't break) and decide which one is right for you.
...
8
Strategy games usually send input, while shooters usually send gamedata. However there are exceptions. For example Halo : Reach runs in lockstep in some online game modes, sending only input.
There are multiple reasons for this:
Shooters have a lot less game data than strategy games
It's easier to keep the game in sync
It reduces lag as long as the game ...
8
For a real-time game, you want to minimize latency. Here's two tips for achieving it, with notes about PHP and Node:
Use WebSockets. They allow fast two-way communication between the server and the client. Using node.js here has the advantage that you can use the same JavaScript API on both ends of the pipe. There's also the wonderful socket.io module for ...
7
I'd suggest to keep things apart.
In Stendhal which is a 2D MORPG written in Java, we did the following things and it works out pretty fine:
The client uses a fast loop for drawing. It does smooth animation and some predictions to minimize lag.
The server uses a loop to process all the game logic. In our case it can be a lot slower than the drawing loop. ...
7
Unfortunately, I'm not aware of any (good) online resources or books on this topic. And I don't know Java. However, seeing that there are no answers yet, I'll share a few tips from personal experience.
First off, you need a fast and reliable RPC, or at least message queue, mechanism. This is what shall be used for both client-server and server-server ...
7
I think what you'll find is that the UDK networking protocol which runs on top of UDP and TCP, is tied up with their proprietary client and server code. So no, if you wish to use the actual UDK networking client, you very likely wouldn't be able to write your own socket or webserver, even if you knew what the packet structure was (and wanted to try to ...
6
Just as everyone else has recommended; keep as much code as possible server-side.
A method I have used to deal with code copying is a bit odd, but it has worked well so far.
Server-side, generate unique id and store it for later.
Server-side, add unique id in script element during html rendering.
Client-side, create a WebSocket connection and pass the ...
6
You have jitter, because you lag is changing constantly. This means, that while server sends updates exactly every timeBetweenTicks ticks, the client receives them after some variable time. That time is probably close to timeBetweenTicks on a good connection, but not exactly equal (And besides, you may have server lag and different clock speeds on server and ...
6
I have solved this problem before with some success with an approach I call "network shadows". I don't know if this is something other people do, but it's always worked for me.
Each entity which is being synchronised across the network has an invisible network shadow entity. When an update comes in from the network, you teleport the shadow directly to the ...
6
Yes there are many tools that allow dumping of the full swf, and/or all of the actionscript. http://www.buraks.com/asv/index.html being one of the many out there.
No, its not worth the CPU power as it will be easy to crack and design a fake program using your "hidden" key. If someone is going through the trouble of hacking your game, a "hidden" key and data ...
6
I don't mean to start a holy war here, but most of the internet services (flickr, twitter, facebook and such) have been dropping SOAP in favor of RESTful webservices and JSON as the serialized format. Although essentially the same, REST services rely on the url and http method to define what should be done, for example
GET /articles - list all articles
POST ...
6
There is no best architecture without knowing a lot more about your requirements, eg. the sort of interactions between characters, how much data is going to be persistent, and so on.
If you can cope with 1 second of latency, you can probably host 1000 players on a single server without problems - but that actually conflicts with the idea of an FPS as they ...
6
I assume since you're students, you are building this as a class project. Please let me first suggest that you scale back your ambitions. Making games is hard, making good games is harder still. I HIGHLY recommend that you and your team
Greatly reduce your design. If you have a short timeframe and have to learn everything as you go, you will run into ...
6
I suppose you could have the server send a hash of it's executable to an authentication server, to ensure it hasn't been modified been modified, but that's about it.
I wouldn't worry too much about it, if you're going to let players have their own servers let them do whatever they want with the game, they purchased it. You can make it difficult to cheat, ...
5
about knowing other players' data:
The only real way to prevent the client from knowing something, is not telling it to him.
*ANY* other kind of doing it will be breakable with a variable amount of effort, depending on how strong your system is.
about user's own data:
Anything you need to store, you need to store it on the server: anything that comes ...
5
Your server should not send the state of all players to all players at every tick. Instead it should send a specially crafted message to each client say every 500 ms saying "these x players in your view port should be at these coordinates in 500 ms."
Most of the time this will work fine, but if the server realizes it has given wrong information it just sends ...
Only top voted, non community-wiki answers of a minimum length are eligible
