Jump to content

  • Log In with Google      Sign In   
  • Create Account


noizex

Member Since 04 Jul 2011
Offline Last Active Sep 14 2014 03:19 AM

Posts I've Made

In Topic: How to send input data

24 June 2014 - 03:19 AM

Ok, since I got so many replies dry.png , I think it may be better that I ask some precise questions, maybe this will attact more crowd than my last post that wasn't probably clear on what the issues might be. 

 

Summary: client-server simple (no advanced physics yet)  player movement simulation using RakNet that supports UDP in RELIABLE and UNRELIABLE mode, allows ordering and sequencing of packets and so on. Right now server receives input commands that are sampled on client at fixed rate 30Hz, they are sent as soon as they're sampled but may be grouped into packets by RakNet. Server puts each received input command into queue and only consumes one command at its simulation tick (also 30Hz). This means it works as long as rate of messages sent from client is steady, and disallows problems with sudden jumps if I were to receive many commands at once. 

 

Question 1: Should I send "empty" moves, where player does not press any key? 

If I send empty moves I have sequential stream of client ticks, so it always goes 1,2,3,4,5,6 and missing tick would let me know that some message got lost.  But then, I can use some of RakNet's delivery modes to make delivery reliable - would it be enough? This is where I'm really lost. For now I tried sending only real actions (so instead of 1,2,3,4,5,6 where 1,2,3 and 6 are empty actions, I'd send only 4, 5) and it seems to work when using ordered stream, only drawback I noticed are enormous lagspikes when some packet is greatly delayed (usually with some packet loss). But then, I'm not sure how would I solve it better using some UNRELIABLE mode and working with tick numbers? 

 

Question 2: What mode should I use for sending user input commands to the server? 

This is follow-up to previous question, because I'm confused what mode (reliable, unreliable, sequenced, ordered) should be used for sending commands. As I mentioned, when I use ordered reliable it means I get every message in the right order, but sometimes big lagspikes occur and this causes the server to stop simulating such player for a while, then it receives burst of messages. This makes the message queue longer, and makes the gap between client and server simulation bigger. When client stops, server easily catches up because it only consumes messages that are real actions, and client that doesn't move don't send them anyway. But considering client moving in some direction all the time, this gap will be bigger and bigger, to a point where server is behind client local simulation by more than several hundreds ms. 

 

On the other hand, using unreliable fast messages I could probably avoid spikes, but at the cost of gaps between messages, plus I wouldn't know if I really lost a message that contained command, or there was no action taken by the client (assuming the same model I described in previous question, that I don't send empty moves). 

 

Can I even afford to loose input messages or it will break things? Should I make sure that messages are either resend, or that I send some redundant information (I read about sending more than 1 input in message, like 1+N previous inputs in case previous ones are lost). 

 

I hope these questions are better than in my previous post and will get some response - I read every thread I could find on the forums about client input prediction and timestamping and there are many methods and often discussions don't even end with some clear solution. I'd really like to at least start some discussion, I know this topic may be boring already, but somehow there is always something uncertain, no matter how much I read on this topic (probably due to many solutions that exist, different network frameworks used and so on).


In Topic: Indie game - Town of Salem

31 January 2014 - 09:41 AM

Reminds me of Salem (http://www.salemthegame.com/) /in art department of course/ You guys were inspired by that game or came with that art style yourself? It's weird how this look fits into "salem" theme somehow, and I can't exactly say why :)


In Topic: Server Handling of Game Objects

24 January 2014 - 07:36 AM

Most of MMOs seem to simplify this aspect to save on amount of objects. You can't drop items, mobs are spawned when server is running, not saved on shutdown and restored. What persists is a state of player mostly (inventory, stats) and probably a lot of event/action/state logging for further reference (I bet that stat collecting takes way more resources than actual player data in such games).

 

Also 10K+ objects is not too many for a single MMO server, a single player can have hundreds of objects stuffed in vault, on his character etc. Even considering what I said earlier (that usually only players are persisted, and game world state isn't really saved much) thats still way less than average MMO has in its database.

 

I'm by no means expert on this, its just observation of many MMOs I played. All of them avoid saving game world state as much as possible - probably due their "massive" nature. Thats also why I think we're plagued by massively bad games, but thats another topic smile.png

 

And just a tip for the future - try to avoid using "M", its usually better looked upon by people. Its not like there can't be an online game that hosts up to several hundreds of concurrent players and don't have million dollar budgets. We can also talk about such projects, and using term MMO in there usually screws a discussion that could otherwise be quite nice and informative. People tend to dislike hearing that someone "tries to make MMO" but if you try something less massive (not thousands of players online and hundreds of players accounts) it usually brings way warmer discussions.


In Topic: Using C++11 smart pointers for asset manager

09 January 2014 - 09:20 AM

I can't see how a solution that passes weak pointers would work in the case of multi-threaded code. In single-threaded code, I can check if my weak pointer is still valid before I use it, and I know that the object is not going away while I am using it. How do I get such a guarantee in multi-threaded code?

 

You're locking weak_ptr before use, which creates shared_ptr<> temporarily, so you have guarantee that it won't go away in that scope. Thats my understanding at least.


In Topic: Using C++11 smart pointers for asset manager

09 January 2014 - 03:06 AM

[Thats reply to cdoubleplusgood's post, in the meantime someone posted so just want to clarify as I didn't quote the original post ;)]

 

Question is - whats his plan to retrieve assets from manager? If he uses unique_ptr, he shouldn't really store any reference/pointer so he has to query manager every time he uses an asset, which will probably be every frame. He can't really pre-fetch assets that he uses and release them when he's done.

 

Also, when using shared_ptr manager knows when its the only owner left and can release resource (or keep it for some time before releasing completly). 

 

How would unique_ptr be used in such pipeline?


PARTNERS