Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (711)
Games in Android Showcase (213)
games submitted by our members
Games in WIP (785)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Questions on Network Implementation  (Read 9938 times)
0 Members and 1 Guest are viewing this topic.
Offline Riven

« JGO Overlord »

Medals: 1260
Projects: 4
Exp: 16 years

Hand over your head.

« Reply #30 - Posted 2012-11-18 07:50:39 »

Cas decided to use ints for most logic, and it's more than enough accuracy. We didn't even resort to (cumbersome) fixed point decimals. Just make your base unit small enough (like 1mm or less). For most 2D games, this is enough, and makes your game deterministic across clients/platforms (assuming latency doesn't affect logic).

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline delt0r

JGO Wizard

Medals: 139
Exp: 18 years

Computers can do that?

« Reply #31 - Posted 2012-11-20 15:53:54 »

If your using UDP and don't know what the 2 generals problem is, or what flow control is, or why TCP has the handshaking it does to establish a connection, then i guarantee that as soon as the network is poor enough for you to notice packet loss with TCP. Your UDP solution will collapse.

Sure it works well when everything is peaches and roses. But that is *not* the same as faster/better than TCP. And what did you gain? Even AAA titles are moving to TCP now. And many of these titles have pretty crappy network code. 

Of course there are situations where UDP works well. Fixed rate full state per packet is one of them.

I have no special talents. I am only passionately curious.--Albert Einstein
Offline teletubo
Global Moderator

JGO Wizard

Medals: 71
Projects: 4
Exp: 8 years

« Reply #32 - Posted 2012-11-20 18:47:31 »

You have a server with an authoritative game state from some time in the past Si. At set intervals, for any period of time in which it has inputs from all of its clients, it will simulate the game state to a new authoritative state at time Sf, and then send this to all of its clients.

The clients will then revert their game states to Sf, discard all cached inputs before Sf, and then use the remaining ones to interpolate the game state up to time N, the actual current game time. To simulate the other client players, they will simply guess based on the last input given to them.

Whenever the clients update, they will continue to cache inputs for that period of time, and also send their inputs to the server.

So does that sound about right? Is there anything I can do to improve how a client guesses what the other clients are doing? Or just improve it in general?


I don't think there's an specific answer to your question, until you drill down to what kind of game you want to make. Some strategies might work better for some kind of games, and some for the other.

To be honest I don't believe what you described could be very good, except for turn based games, unless the tick rate of your server is extremely high (which would easily saturate your network).

In a real-time game I would recommend the server to run the game as it were in the client: full logic at N ticks per second, process the player inputs as they come, broadcast it to everybody.

Now here it comes when I said the type of game:
If it is a FPS, let's say Quake, players are likely to keep moving, rotating, dodging,shooting, at a very high rate; so you might want to have a packet being sent very often updating the players position.  

However, if you have an action-rpg, think of Diablo, you don't need such high rate of packages. (now I'll tell you from experience. This is exactly how I implemented my online game Reign of Rebels).
You basically just need a package when an entity moves, or attacks (or performs any significant action).
Let's say you have entity A standing on point  10,23  and the player (or the AI) directs it to move to point (14, 25). The client will send the message that it wants to move, server receives it and broadcasts this. Just 1 package exchange and you'll have the entity performing the exact same move on the client and on server. When the entity hits is target, it will stay there until further orders are given. No need to send a shitload of packages telling that the entity A is standing in position 14,25.  
This strategy might even work in some more fast paced games where your Physics/pathfinding is deterministic.

Of course you would use some interpolation tricks to make things smooth (some of which I discussed here ), but this is definitely a solution for this kind of game.

Maybe if you show us a video of a game similar to yours, we can give better suggestions on how to implement it.

As for TCP/UDP: Just go for TCP. You have already too much to worry in the making of a game, just let TCP handle some of the headache for you.

Pages: 1 [2]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

numerical (239 views)
2017-02-21 07:32:16

numerical (238 views)
2017-02-21 07:31:46

theagentd (350 views)
2017-02-18 13:42:33

theagentd (350 views)
2017-02-18 13:35:16

h.pernpeintner (1514 views)
2017-01-24 22:39:11

h.pernpeintner (1502 views)
2017-01-24 22:38:32

Galdo (2067 views)
2017-01-12 13:44:09

Archive (2085 views)
2017-01-02 05:31:41

0AndrewShepherd0 (2622 views)
2016-12-16 03:58:39

0AndrewShepherd0 (2340 views)
2016-12-15 21:50:57
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 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‑
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!