Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Simple basic question.  (Read 3133 times)
0 Members and 1 Guest are viewing this topic.
Offline marcuiulian13

Senior Member


Medals: 5
Exp: 3 years



« Posted 2012-06-23 12:01:57 »

I am trying to make my RPG game multiplayer, and this is the first time when i meet with servers.

When any of the players move, a thread sends their position to the server, and then the server transmits the position to the other players. Is it ok to do it like this or i should send a message to the server when someone press a key, and then the server computes the position and send position to the others? If i should to the other way, how can i manage to check collision?  Huh

Getting a project done is by far the most hard thing in game development.
Offline Summit

Senior Newbie


Medals: 1



« Reply #1 - Posted 2012-06-23 15:16:54 »

The answer to this question is highly dependent what you desire as far as gameplay. There are pros and cons to both systems.

Are your clients constantly moving around?
Will other connected clients need to see them in their exact positions or can they be fudged a little? (think WoW where everyone sees each other in slightly different positions)

In an fast paced game (think first person shooter), the client should be sending only their inputs to the server. The server receives the inputs, validates them, applies them to its version of the game world, and ultimately sends the client back a snapshot that contains their changes. The client is never trusted to determine its own position (or health, money, etc.). Pros to this system is it's not possible to cheat the server by telling it impossible things. The server will determine the outcome of all actions so they are always correct. Cons are increased communication necessary between client and server and having to implement more client side prediction and recovery code to make inputs appear instantaneous. It simply wouldn't do for clients to wait 150ms round trip before their actions took effect, so you predict what will happen on the client side and make corrections based on what the server tells you later.

If your game is twitch based and your players are taking aim at each other, then it makes sense to implement a snapshot based system so everyone is seeing the same thing. If your game is more target based, like you select someone and then cast a spell but never have to aim the spell, you might be able to get away with sending just positions (and doing some checks for impossibility). This is what many MMOs do because it allows them to lower the amount of traffic to the server for basic movements.

Edit: As far as collision detection goes, this is just another thing that the server can do on its end and inform the clients of. Here's sort of an outline of what a server might do in a FPS:

every 15 millseconds:
1. check network for updates clients have sent me, store the unprocessed input for consumption
2. for each player in the world, apply any unprocessed input gathered in step 1
3. run a simulation step and update the game world based on the time since last update (ex. move any projectiles forward)
4. check all game objects for any collisions, perform appropriate actions (ex. move players back so they aren't colliding, apply damage for any projectile hits)
5. clean up the world, removing dead entities
We have a world that is completely up to date. We could send a snapshot of this world to all players, but it's usually not necessary to do so every tick.
6. if it's time to send a snapshot, create one and send it all connected clients

More information: https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
Offline sproingie

JGO Kernel


Medals: 202



« Reply #2 - Posted 2012-06-23 15:20:16 »

The second: send movement commands to the server, then have the server tell you and the others where you are.  You'll want to do some prediction on the client side, otherwise things will feel really unresponsive.  If the client's prediction is wrong, the player will appear to jump around, which is what happens in most online games.  Ideally you get them to converge on a compromise position that actually gets rendered, but usually it doesn't happen that way, people just live with the stuttering movement.

Collision detection is easier when you compute all positions server-side, since you can use basically the same code as you would for single-player.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline marcuiulian13

Senior Member


Medals: 5
Exp: 3 years



« Reply #3 - Posted 2012-06-23 18:17:47 »

Ok, so my idea isn't good? Until now i used to move the player client-side and send the new coordinates to the server, and then the server send those coordinates to everybody except the user that sent them.

My problem with this is that the movement isn't smooth enought..

Getting a project done is by far the most hard thing in game development.
Offline ra4king

JGO Kernel


Medals: 345
Projects: 3
Exp: 5 years


I'm the King!


« Reply #4 - Posted 2012-06-24 03:10:17 »

That's why you interpolate, aka you make the players smoothly move from one position to the other.

Offline marcuiulian13

Senior Member


Medals: 5
Exp: 3 years



« Reply #5 - Posted 2012-06-24 07:50:27 »

And what is the delta in server transfer? How can i calculate it, and how can i handle it?

I am already interpolating the client's update delta, but how i manage the server one?

Getting a project done is by far the most hard thing in game development.
Offline Summit

Senior Newbie


Medals: 1



« Reply #6 - Posted 2012-06-24 16:06:36 »

You should really read the source multiplayer networking link I posted. You'll probably need to read it over a dozen times to fully get all the concepts but it's all layed out quite nicely in there.

I'm not sure I totally understand what you mean by 'sever delta', but if you go back to the outline I gave above, you'll remember that the server is sending the client snapshots of world data. This is typically done every 50 ms. So imagine you're a client and you've just received a snapshot. It contains two things: world data and a timestamp of the server at the time it was created. You now have a snapshot of the world as it was at the time given in the snapshot.  

For now I would just assume that both client and server are synced on the same clock. This is absolutely untrue but just getting started it won't be helpful trying to also work in clock syncing. And for now since you're developing locally you can put off worrying about ping, since it will be close to 0. These two things you will later need to work into your system as ping and clock deltas obviously do exist, but for the time being assume the server time of your snapshot is also local client time.

1  
2  
3  
4  
5  
public class Snapshot
{
    public long time;
    public WorldData worldData;
}


Just starting out to make sure everything is working you could immediately update your local client version of the world to this snapshot. It will be synced but since you're only receiving updates every 50ms, it'll be very, very choppy. How do we solve this? We need a way to get the snapshot of the future state. This is done by moving the client view of the world back in time. If we did so by say 50ms (we'll call this view lerp) then we'd usually have one snapshot to move forward to (assuming the snapshot packet isn't delayed or dropped on its way to us). So now you have version of the game world as it will be 0-50 ms from now. Every client update loop you can calculate how close you are to that upcoming snapshot and move everything towards their final authoritative positions (this is called interpolation).  

I think that should be enough to get you started, but there is obviously more to it. Most games move their view lerp back 100ms in case a snapshot is dropped, they'll always have another one to move forward to. Again, read that link, it has all these details and much more.

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #7 - Posted 2012-06-24 16:09:34 »


Interesting read, ta.

There's also the Q3 article which is quite elegant: http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline jonjava
« Reply #8 - Posted 2012-06-24 22:44:27 »

... this is the first time when i meet with servers....

Forget what anyone has said in this thread, just get it working over LAN first. Then take suggestions.

Offline Summit

Senior Newbie


Medals: 1



« Reply #9 - Posted 2012-06-24 23:34:56 »

Forget what anyone has said in this thread, just get it working over LAN first. Then take suggestions.

You still have a client-server architecture whether you're connecting via LAN or not, and the same set of challenges as far as how the two should communicate still apply. You have a lot more reliability and less lag over a LAN but since this is more of a discussion about how servers keep clients updated on game state, I don't see how LAN makes any difference.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline JESTERRRRRR

Senior Member


Medals: 7
Exp: 1 year



« Reply #10 - Posted 2012-06-25 02:37:52 »

I made a game with only movement over lan, disasterously laggy... even when the same pc hosts and acts as a client connecting its noticably jittery lmao.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

BurntPizza (19 views)
2014-09-19 03:14:18

Dwinin (34 views)
2014-09-12 09:08:26

Norakomi (62 views)
2014-09-10 13:57:51

TehJavaDev (87 views)
2014-09-10 06:39:09

Tekkerue (42 views)
2014-09-09 02:24:56

mitcheeb (65 views)
2014-09-08 06:06:29

BurntPizza (47 views)
2014-09-07 01:13:42

Longarmx (35 views)
2014-09-07 01:12:14

Longarmx (40 views)
2014-09-07 01:11:22

Longarmx (36 views)
2014-09-07 01:10:19
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!