Tag Info

Hot answers tagged

29

Try to keep this as simple as possible and interfaces well defined and documented. Maintaining and debugging a complex system in production easily turns into hell. So if there is a simple and a complex approach, think twice before you go with the complex one. Defining Services I think the first step is to identify services and their dependencies: Static ...


13

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


11

The way I typically do that is set up animation events that are hooked up to each frame that would require a footstep sound. So in the walk animation there will typically be two steps, so at those frames I tell whatever sound system I'm using to play a random step sound. (In your case, I think it's just a regular fmod event.) Another way I've seen it done ...


11

This is really hard to pull off, because real concurrent editing (on the same files) can be rather tricky. I'd focus on some source code versioning system like SVN, Mercurial, or Git. If you're using Visual Studio, the best option would be using their Team Foundation Server or - with the addon being in beta right now - Git. Setting up a Git repository ...


11

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


10

Generally the world is divided up into a number of smaller regions. Each of these regions is usually an independent server process (WoW's world servers or Eve's Sol nodes) and can run on any of a number of machines. In some games there are explicit doors between maps (Eve, STO, Guild Wars) while others try to mask this more (WAR, Free Realms). Those that opt ...


10

Problem analysis Real-time communication over a high-latency connection is obviously impossible. You can of course attempt an illusion (as you're doing by making the remote player appear to have passed an obstacle when it's not yet known). When that illusion fails (as yours does when the remote player didn't actually pass the obstacle, but died instead) ...


9

The algorithm posted was correct, but in your example you are forgetting about the time it takes for the server packet to get to the client, so: Server time: 1 Client time: 0 Client sends 0 to server ... 150ms to get to server (ping is 300! not 150ms in this case. Ping is round-trip) Server time: 1.15 Client time: 0.15 Server receives packet and sends ...


8

I believe it's a common requirement of MMOs that processing for a single shard or realm can be done over several servers to ease the load. I'm curious as to how this can be done whilst maintaining a unified consistent world where all the players, and all the NPCs can interact. It's probably not as common as you think; at least, not if ...


7

There are two approaches to this. Lock Step In Lock Step all clients send there data for frame 1 to the server and then wait. The server collects the frame 1 data from all clients and only processes them once all are received. It then sends the result back to all clients and gives the clients the go-ahead to start working on frame two. Note that with frame ...


6

The quick answer is: there is no best approach. Games all contain different architecture; every game will choose different sets of data to send in order to synchronize itself with other machines, which will affect the choices that you can make when choosing how to deal with lag. What you specify in option #2 -- that clients send messages to be acted on at ...


6

You probably won't be able to use NTP directly -- for one, you need to have a server that is guaranteed to be available to all of your clients. Second, it's really overkill for what you need. What you want to really do is come up with some sort of common time stamp that all of the clients can agree on. Based on the method from ...


6

You have identified the key problems. Your "bounding box" solution to what-to-update seems fine. You may want to make the update box a little wider than the view box, so that actors outside the view are already available if your player starts walking. The usual solutions to jumping are: Some assumptions, e.g. other players keep moving in the same ...


6

Dead reckoning may not be the best idea in this case; you should do entity interpolation (effectively rendering the other players in the past, which always gives you real, valid positions). I've written about this with much more detail here. Whether or not seeing players slightly in the past is acceptable or not depends on the details of what you're trying ...


6

every action the player takes is deterministic, however, there are events that happen on scheduled intervals I think there's your problem; your game should only have one timeline (for gameplay-affecting things). You say that certain things grow at a rate of X per second; find out how many game steps are in a second and convert that to a rate of X per Y ...


5

For example, let's say it's tick 1000 and player 1 sends a message saying that he is going to start attacking player 2 at tick 1002. That's not how it works. What is sent is what player 1's controls do. Click on location, drag to here, pressed key X, whatever. You don't send specific game state like "is attacking". The idea being that, as long as ...


5

Few questions first. Are the 'rockets or something else' intelligent or dumb? If they're dumb all you need is the timestamp of fire, the origin, and the vector to simulate their path. If they're intelligent how intelligent are they? Can you compute at the time of fire that they're going to hit or miss? If so you can simulate the entire path on the ...


5

Here are two approaches: First: Switch to deterministic physics, send player commands, ai actions, objects coming into view and whatever can't be determined client-side to clients. This must include non-commands, a confirmation that up to a certain point in time nothing but the commands that has been sent and received apply. The client must run two or ...


5

In a multiplayer game, every gameplay-relevant decision should be made by only one system. When multiple systems make a decision, like in your case the trajectory of the ball, and they disagree due to timing issues, the game gets out of sync. When each client calculates the angle only after its own collisions and sends the new trajectory of the ball to the ...


5

There is a great number of text editors which allow several users to simultaneously edit the text. "Simultaneously" in this case means that when you open a document and someone else is/are editing it, you see those someone else's cursors, and what changes they make -- in real time. Obviously, you can make your own changes too, and they will be broadcast to ...


5

You're looking for a source control solution. These are a common part of the industry. Large Open Source projects often have dozens (and in a few cases hundreds or thousands) of individual developers spread over the entire world. Solutions like GitHub, BitBucket, CodePlex, SourceForge, and more offer these services for free (often only if you make your ...


4

It's not clear why this should be a problem. If the delta is the time between updates, then it doesn't matter if it's called 1ms late providing it's consistently called 1ms late, which would appear to be the case. It's also not clear how you are observing that this is a problem given that presumably there is no visual output until the whole lot has returned. ...


4

You didn't mention if a single server was an authority or not, but have a single time that every client syncs off of. In my experience with City of Heroes, latency can be streaky, so a running average (root mean square is easy) is a good way to approximate. We also timestamp all roundtrips as part of the packet header. Truth be told, since the cases that ...


4

I'd say 2: as you state, solution 1 would generate too much traffic. There's a chance it works in the beginnings, but then when you'll add other things to send you might have to reduce the input updates frequency and thus you game reactivity. As a rule of thumb, sending deltas instead of complete states is most of the time The Right Thing to do. You're ...


4

Ok I don't know about World of Warcraft or their implementation. Taking average network jitter and delays into account you don't get a very accurate reading about time from the server. (That is why NTP is difficult.) If all you want to display is the server time, you just need to send the server's time and add the current round trip time to get a rough but ...


4

The normal answer to work on different files rather than trying to edit the same one. Anything big enough to involve multiple people will also involve multiple files.


4

It's simple arithmetic and requires no loops or periodic DB updates. The player has a rate of resource gain. This is fixed until some external stimulus happens like the player buying an item to change speed. You need only know the current speed and resource counts for this to work. Take the current time. Take the last time the resource counts were ...


4

To complement Anko's answer, you can change a bit your game design by adding the consequence of the failed obstacle after the failure, for instance, a failed jump results in landing in a puddle of mud which disqualifies the player. This way the other player notices the failure by seeing the other fall in the mud, while the player who fails sees it right ...


4

First, to solve the problem with scheduled events, don't broadcast the events when they happen, but when they're initially scheduled. That is, instead of sending an "increment the energy of tile (x,y)" message every second, just send a single message saying "increment the energy of tile (x,y) once per second until it is full, or until interrupted". Each ...


3

Send only the state changes, and at relatively longer intervals send a complete status, so that even if a packet got lost after a while you would reset to a correct value. Furthermore, you can number the udp packets, so that you would know if you are losing too many of them.



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