Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


C# higher level network library


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
15 replies to this topic

#1 FrontBack   Members   -  Reputation: 179

Like
0Likes
Like

Posted 09 July 2014 - 09:32 AM

Hi everybody! smile.png

So, I'm making a multiplayer game and I'm looking for a library that's built for multiplayer games, that easily (or at least without making me write the entire netcode) allows me to make a client-server system that syncs the entities' data, such as position, rotation, scale and so on.

If possible I don't want to rely on cloud-based systems like Photon, APlay and stuff like that.

 

First of all, does it even exist a library like that? If not, what framework is the best to make one? Lidgren or RakNet (now open source)?

 

Thanks to everyone who will help me! happy.png



Sponsor:

#2 ncsu121978   Members   -  Reputation: 509

Like
0Likes
Like

Posted 09 July 2014 - 06:47 PM

lidgren



#3 FrontBack   Members   -  Reputation: 179

Like
0Likes
Like

Posted 10 July 2014 - 02:01 AM

lidgren

 

Well, maybe I explained myself badly: I'm looking for a library that makes me easier to sync my entities, and Lidgren is indeed powerful, but using it I would be forced to write the entire netcode, which I want to avoid for various reasons.



#4 DvDmanDT   GDNet+   -  Reputation: 968

Like
0Likes
Like

Posted 10 July 2014 - 04:24 AM

I don't think you'll find something higher level without using an entire engine. I'm not sure I can see how such a library would even work. How would it know what to synchronize and how would it actually perform the synchronization when it receives data?



#5 hplus0603   Moderators   -  Reputation: 5548

Like
0Likes
Like

Posted 10 July 2014 - 10:32 AM

Netcode is usually intricately tied to the game engine itself.
Thus, if you want the "sync" part, you will typically also want the "entities" part of a game engine.
Most game engines that do this are complete solutions (adding graphics, too) such as Unreal Engine 4, C4 Engine, Torque 3D, etc. (I'd recommend for UE4 or C4, against Torque.)
enum Bool { True, False, FileNotFound };

#6 stupid_programmer   Members   -  Reputation: 1184

Like
0Likes
Like

Posted 10 July 2014 - 07:41 PM

SmartFox sounds more like what you are looking for.  It is a discreet instance running on your own server will handle connecting and sending data back and forth from the client to the server.  But as was mentioned no matter what route you go you will have to write some code yourself.



#7 FrontBack   Members   -  Reputation: 179

Like
0Likes
Like

Posted 11 July 2014 - 09:48 AM

Netcode is usually intricately tied to the game engine itself.
Thus, if you want the "sync" part, you will typically also want the "entities" part of a game engine.
Most game engines that do this are complete solutions (adding graphics, too) such as Unreal Engine 4, C4 Engine, Torque 3D, etc. (I'd recommend for UE4 or C4, against Torque.)

 

Thank you for your response.

Unfortunately, for the game I'm making, there are no engines that have the features that I'm looking for.

This engine is also entity-based, but the netcode is the only part that I can't do. I tried several times, without any success.

I was interested in Janus (http://equis.cs.queensu.ca/wiki/index.php/Janus), but unfortunately it uses a peer-to-peer architecture, while I need a client-server one.



#8 DvDmanDT   GDNet+   -  Reputation: 968

Like
0Likes
Like

Posted 11 July 2014 - 10:04 AM

What about it is it that you're having problems with? Sending/receiving data is really easy with Lidgren. Figuring out what data to send and how to actually read/write that data from/to your entities is something that no solution will free you from, except possibly using an existing engine..

 

How much stuff do you need to synchronize? tens, hundreds or thousands of entities? If it's ten or so, then you can probably get away with sending everything all the time. If it's on the scale of hundreds or even thousands, then you'll need to figure out what to send to which player at each given time.



#9 FrontBack   Members   -  Reputation: 179

Like
0Likes
Like

Posted 11 July 2014 - 10:33 AM

What about it is it that you're having problems with? Sending/receiving data is really easy with Lidgren. Figuring out what data to send and how to actually read/write that data from/to your entities is something that no solution will free you from, except possibly using an existing engine..

 

How much stuff do you need to synchronize? tens, hundreds or thousands of entities? If it's ten or so, then you can probably get away with sending everything all the time. If it's on the scale of hundreds or even thousands, then you'll need to figure out what to send to which player at each given time.

 

In each map there will be about from 50 to 200 entities (the maximum supported entities is 65536, a ushort) for a max of 24 CCU, and for each entity I have to send 7 data parts: position, rotation, scale, velocity, color, texture index and render depth, plus the entity unique ID.

My problem is that I know how to send/receive packets with Lidgren, but I don't know how to store and read them in an efficient way to do lag compensation and input prediction.

In fact, I'm very noob at game networking. I read numerous times the Source Multiplayer Networking, but I still don't understand it completely.



#10 DvDmanDT   GDNet+   -  Reputation: 968

Like
0Likes
Like

Posted 11 July 2014 - 02:41 PM

What kind of game is it?

 

You'll have to structure your game so it can handle not being in sync. Each entity will probably need a local state, last known "real" state and extrapolated current real state. When the local and the real state differs, you begin moving towards the extrapolated real state. You may not need to care about how an entity wound up in a specific place, all you need to care about is finding a way to get to that position within the game rules.

 

[edit]

Disclaimer: I have never written a game using this kind of synchronization. I'm writing an RTS with input command synchronization which comes with a completely different set of challenges. The above is just from the top of my head.


Edited by DvDmanDT, 11 July 2014 - 02:49 PM.


#11 FrontBack   Members   -  Reputation: 179

Like
0Likes
Like

Posted 12 July 2014 - 02:39 AM

What kind of game is it?

 

You'll have to structure your game so it can handle not being in sync. Each entity will probably need a local state, last known "real" state and extrapolated current real state. When the local and the real state differs, you begin moving towards the extrapolated real state. You may not need to care about how an entity wound up in a specific place, all you need to care about is finding a way to get to that position within the game rules.

 

[edit]

Disclaimer: I have never written a game using this kind of synchronization. I'm writing an RTS with input command synchronization which comes with a completely different set of challenges. The above is just from the top of my head.

 

Thanks for your response.

I'm writing a 2D sidescroller multiplayer shooter game. To simplify things, like a Super Mario but with multiplayer and weapons.

I read your tips and I have some doubts: the first one is about extrapolation. Isn't it a bit "dangerous"? We're getting data from the "future", so I don't think it will be accurate enough. The second one is about data storing: what about the previous known snapshots from the server? Do they matter? Or only the last one?



#12 DvDmanDT   GDNet+   -  Reputation: 968

Like
0Likes
Like

Posted 12 July 2014 - 05:19 AM

How "dangerous" it is to extrapolate depends on the game. You _will_ end up in incorrect states and positions, but for most games this isn't a problem unless the difference is huge. For your game however, it might be slighly more problematic since I'm guessing it'll be prone to butterfly effects. It's really hard to sync those kinds of games.

 

A typical problem is when a player is on a platform running forward, intending to jump when he reaches the very end of that platform. If another client just extrapolates his position, it may have him of the platform falling down before receiving the jump information. If the game is very fast paced, you  might get away with a "super jump" in the air or even teleporting when the states go to far appart. For a slower paced game, chances are bigger that you'll receive the information before the problem arises.



#13 hplus0603   Moderators   -  Reputation: 5548

Like
0Likes
Like

Posted 12 July 2014 - 01:51 PM

If you do entity extrapolation, you don't want to be triggering any sensors or running physics on those remote entities -- just display them extrapolated, and do basic collision checking so they don't go through walls on the screen. The real physics should ideally happen on the server, or if you're server-less and don't mind cheating, on the controlling client for each player.
enum Bool { True, False, FileNotFound };

#14 FrontBack   Members   -  Reputation: 179

Like
0Likes
Like

Posted 13 July 2014 - 02:34 AM

If you do entity extrapolation, you don't want to be triggering any sensors or running physics on those remote entities -- just display them extrapolated, and do basic collision checking so they don't go through walls on the screen. The real physics should ideally happen on the server, or if you're server-less and don't mind cheating, on the controlling client for each player.

 

Sure, but I mean, wouldn't be safer to delay the rendering on the client and interpolate the received data between two packages?



#15 rip-off   Moderators   -  Reputation: 8540

Like
0Likes
Like

Posted 13 July 2014 - 05:01 AM

Sure, but I mean, wouldn't be safer to delay the rendering on the client and interpolate the received data between two packages?

Yes, it would be safer, but now you are limiting the client responsiveness to the latency from the server. Depending on the type of game, this could result in unsatisfactory gameplay.

#16 DvDmanDT   GDNet+   -  Reputation: 968

Like
0Likes
Like

Posted 13 July 2014 - 05:49 AM

Yeah, imagine if you drop a packet. A player who keeps running would appear to stop for a split second and then continue. So it's not optimal.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS