Tag Info

Hot answers tagged

35

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 ...


27

This could be considered an animation problem. If a position correction comes back from the server due to an attempt to move into an invisible object, send back not only the correction but a flag indicating why the correction was needed. Instead of a player popping backwards, he may do a "woah" kind of reeling backwards animation, making it more believably ...


20

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, ...


17

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 ...


14

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 ...


14

Simple answer: cheat or don't be that accurate! If you've played some shooter online, you'll most likely have experienced the so called "rubber banding" if your connection to the server is bad. This is caused by your client correcting your position from time to time. Basically, what happens on the two sides: The server will track your movement and send ...


13

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 ...


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 ...


13

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 ...


12

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 ...


12

Your goal of synchronizing 50 events per second in real-time sounds to me like it is not realistic. This is why the lock-step approach talked about in the 1500 archers article is, well, talked about! In one sentence: The only way to synchronize too many items in too short time over a too slow network is to NOT synchronize too many items in too short time ...


11

You can host a simple matchmaking service on Google App Engine for free. It should be able to service many users. If it starts being really really popular, you can start paying for the service with what you earn.


11

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

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 ...


10

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 ...


10

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 ...


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

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 ...


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

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 ...


8

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. ...


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

Don't optimize prematurely. Keep it simple. Using TCP in this case is OK, and I don't see any problems with your current scheme. UDP is usually used for performance critical scenarios such as in an online action game, because it allows explicit control over individual packets as opposed to working on top of a layer abstraction of streams like TCP. However, ...


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 ...


8

You should send redundant data, which here means send the position and the velocity. Even if you are out of sync, the fact that you have the position and the velocity allows you to correct the trajectory using an interpolation function. Then using some tricks like delayed animations, accelerations, etc. allows to hide the latency. Edit: I assume that the ...


7

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 ...


7

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 ...


7

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 ...


7

I'm not sure what it is exactly that you want to achieve. But, there's one pattern that is used constantly in game servers, and may help you. Use message queues. To be more specific: when clients send messages to server, do not process them immediately. Rather, parse them and put into a queue for this specific client. Then, in some main loop (maybe even on ...



Only top voted, non community-wiki answers of a minimum length are eligible