Ok so to make a game run smoothly there needs to be latency right? As in the server waits two ticks to actually do command x or something is this the right way of thinking about it?

Also what is the best way to make characters "see" each other without sending the position of everyone on the server? It would seem that running a function to generate a list of people to tell a specific person hey these people are nearby would be costly in terms of time right and since you can't be gauranteed that say X can see Y and Z you can't say Y can see Z since they might be out of range of each other.

I am thinking a smaller server 255 or less people could be done with allocating a byte for each player like a quick update, but this structure won't work with larger amounts of people. What advice can you all give me to make a server that won't lagg horribly with just a couple people logged in and make for a good gameplay?

What I have right now is a server that will accept incoming connections and allow players to create and login. Working on coding shoot and pushing bullets/projectiles to a stack.

The server is written as follows I realize it may not be perfect and inefficent in some places:

Server.h

Server.cpp

main.cpp

No. Why would you think that?

Your server listens for the client(s) for however many ms you set it.

This is possible but only if your simulation is deterministic. You can only take input from your client(s) and send the update from your server with all the positions you changed.

From what I figure- the clients should only send updates when their state changes right? ie 1000xxxx (think up, right, down, left, 4 reserved bits) then lets say they walk up for some amount of time then they stop moving now we get a second packet 0000xxxx and the server stops them moving. Is this a good idea? It seems to have the least amount of traffic in a design that I can think up. The only thing I worry about is the server could potentially get hung up with someone flooding it with commands (repeated presses of a key like up thus sending many update packets) and as you can see from the server design that could cause lagg. Maybe I will need to code a lockout timer 5 commands per 5 seconds or something like that ideas?

Another thing you might try doing though I'm not sure what the code looks like for it is synchronizing the clients and the server so that the server expects to receive a message from the clients within some time frame. The clients basically have a timer that is in sync with the server and only send a message within a specific timeframe. The idea would work similarly for the server side as well. The gameloop would execute in sync with the client and the server and the updates ( your controls, scores, etc.) would be sent to your clients and the server sometime after the gameloop.

I added a thread to run updates on the players and such; while the other threads if they find nothing will yeild their timeslice to the update thread to make sure things keep going smoothly(so I hope).

Posted before I realized I don't have all the threads posted....

So I have the following threads:

Check for incoming connections - yields there is enough time for it to come back only checking one socket in this case so it is quick doesn't need to check twice.

Check for data on existing connections - does not yield connections could have data any second now....

Pull commands off the stack and execute them - yields with no commands

Update players, NPCs, Monsters, bullets, etc

Does that mean the server is always listening? If not how do you fix missing packets or are you using udp, thats the norm for games.

You have a thread that will always be checking out on the listener. You also have a thread that will always be checking for incoming commands from the clients/players.

TCP actually - The server doesn't "miss" packets although I could put an ACK in there to make sure the client knows the server got the data... The server queues commands up with an identifier and a char* with the command and params.

void Server::Initalize(short PORT)                                         //Calls mysocket::startup() and starts listening on a socket for incoming connections.
  {
      Port = PORT;
      Listener.Startup();
      _beginthread(Listen,0,(void *)this);
      _beginthread(Check_Connections,0,(void *)this);
  }

So I start two threads to handle communications and new connections. Now this main thread goes back to main and basicly goes and grabs commands off a stack the server is pushing commands onto. Now lets say people don't send any commands (Test_Server->Get_Command() == NULL) - there is nothing for my guy here to do so he yields that timeslice to someone who needs it.

while(!kbhit())
    {
        do
        {
            testcommand = Test_Server->Get_Command();
            if(testcommand)
            {
                HandleCommand(testcommand);
            }
            else SwitchToThread();
        }
        while(testcommand);
    }

It also does this while listening on incoming connections for a performance boost I hope.

and if you want to see how I handle commands:

No. You're not even vaguely on the right track. You haven't even begun to address the real challenge of making a fun and responsive network game which is latency hiding.

Have you even established how you are going to maintain consistent state? This will depend a lot on the type of game you are making. For example, for an FPS you'll want the absolute state to be server-side with each client seeing some predictive subset of the state. For an RTS, on the other hand, a good solution is to use a deterministic lock-step engine.

Once you've established this, you'll then want to work on decoupling game-play from communication as much as possible so that the game flows smoothly despite latency spikes.

Finally comes the hard bit: hiding latency and making the state displayed to the user believable despite the inevitable network latency. This involves interpolation, extrapolation, prediction and reconciliation. Moreover, it requires making the correct game design choices in the first place. You'll see this is all the best online multiplayer games: movement, weapon and gameplay mechanics are chosen to be predictable to within a reasonable degree of accuracy so that reconciliation can be done subtly.

It looks to me that you don't really understand the fundamentals. I suggest spending a lot more time thinking about it and reading articles before jumping into client/server design. There are plenty of good articles about like this one:

http://www.gamasutra.com/view/feature/3227/designing_fastaction_for_the_.php

I would also suggest that you stop dwelling on bandwidth usage. Compared to latency, bandwidth is a non-issue.

Wondered why I kept reading things about 28.8kbps modems... that was written in '97.

But you say I am wrong go read that page yourself technically speaking that is what I had said earlier.

"•Schedule events in the future if you want them to happen simultaneously for all users. "

Does that mean my lagging character might shoot someone even if I'm not really pressing the button?

No, this is not what you said. If this is what you were trying to say then you've either totally misunderstood it, or you've worded it extremely poorly.

It is referring to individual events. For example, jumping: This can easily be scheduled a short time in the future whilst still feeling responsive by adding a "crouch" period. So, the user hits the "jump" key, he sees his character start crouching and so it feels to him like there is immediate feedback; however, the message then travels off to the server at which point the server (immediately, or as soon as possible given the network latency!) notifies other clients of the players intention to jump. The actual lift-off only occurs a short (say 300ms) later than the original player hit his jump key.

Other players will see the player jump at roughly the same time as the player himself jumps; however, if they look really closely, they might notice that he didn't crouch at all.

This is what it is talking about when it says "scheduling events in the future". A few things to note: if you try to employ this technique alone to hide all latency, then the game will start to feel clumsy. So this is just one "trick" in your toolbox of latency hiding techniques. You can't use it everywhere, and so it should not be a mechanic underlying your entire client/server communication engine, or else you will not have the flexibility to use other techniques.

No. Go away.

Haha verthex ^^ I hope you were joking thought :-p

So you're saying the server gets the user input, processes it for physics, etc, and then sends the command for jump to every client including the user to jump. It would solve packet loss (somewhat keeping events in order) but 300ms is a lot of time.

He is still on the 28.8kbps modem mentioned in his other post... 300ms wasn't all that bad back then...

[EDIT]

I guess by tick he thinks seconds as well. I usually figure a tick to be around 50ms the wait two ticks is indicitive of It will probably be roughly 100ms+-50ms for a response to the client.

Everything that article says about latency is as applicable now as it was when the article was written, because guess what, the speed of light hasn't gotten any faster, and this is what latency ultimately comes down to.

The 300ms example I gave was a specific case where one wishes to guarantee (or at least ensure a high probability) that a particular event will occur at the same time across all clients. ~250 ms is roughly the "worst-case" that any good modern multiplayer game will deal with gracefully, even to this day. As I already said, this is just one technique and is probably not even appropriate for jumping. I just gave this example because I hoped that it would be easy for you to understand as comprehension is evidently not your strong point.

I suggest that you give up now, as you're clearly not even intelligent enough to be capable of discerning good advice from bad. You really haven't got a clue what you are doing, and I don't even know why I'm bothering to post in this thread. I guess it was more out of pity because the primary contributor, other than myself, was verthex who is the #1 bullsh*tter on these forums, and so I felt it my duty give some useful information to counter his "noise".

Then please don't post anymore. Actually go post at cprogramming.com they are all like you over there - quick to think they are gods and that no one else has any right to be doing anything.

So you posted a shitty article and now you know something. What experience do you actually have making client server games and if you've never made a FPS please don't reply. Thats what David is trying to make and so am I.

Hows this bullshit when everyones talking about it?

David,

Have you already read the Beej's guide ?
It's full of nice example and perhaps it has evolved since the first time you watched it.

On Gamasutra and talking about Network, particularly latency hiding, I loved these articles:
Dead Reckoning: Latency Hiding for Networked Games

Defeating-lag-with-cubic-splines, with these two in addition because they somewhat bring a correction/solution to an error in the article: http://www.gamedev.net/topic/401827-lag-reduction-using-cubic-spline-alias-bezier/ , http://en.wikipedia.org/wiki/Cubic_Hermite_spline

Translation:

I shall respect your wishes!

Meh !

I think you're both reaching too high. Start with something simpler. Its pretty much the same as trying to make an MMORPG right out of the gate. You will fail. Probably multiple times.

Please note I did have a working MMORPG with items enemies and such - it was all tile based wasn't very pretty and the classes weren't written well (that does not mean it didn't work - it worked fine). I see no problem making something simple for fun. You all act like I want to make money or plan to make money with this. It is just a hobby nothing more nothing less. I don't know everything, but judging me saying I'm already going to fail before I even really start to play around.

It's just a very common occurrence. A beginner comes along and says "I want to make an MMORPG" or "I want to make a RPG" or "I want to make an FPS", and inevitably, they spend more time fighting with the simple issues like timing and bliting, and give up.

Of course if you go into it not expecting to make the "BEST GAME EVER!", and know you're likely to restart several times, that's ok.

The trouble is not that I think you're taking on an impossible task nor that you are inherently incapable of succeeding, but rather that you don't seem to have the temperament for it. You came on here asking for advice, but then chose to totally ignore it (and the literature to back it up!) because you took a few of our criticisms personally.

Thus far I've used this as my server/client interface for irrlicht.

I can create clients, display each client as a cube, and allow each client to exit the system without crashing the server as well as ten other things related to basic services. That took me about two weeks to write.

Its a very easy to use server and I highly recommend it over every other socket oriented library. Its not easy to compile and it took me a few minutes to find the libs for it.

Ah, using a pre-made game engine will certainly make creating a game easier. If creating a game asap is your goal, that is definitely a good option.

[quote]
I suggest that you give up now, as you're clearly not even intelligent enough to be capable of discerning good advice from bad. You really haven't got a clue what you are doing, and I don't even know why I'm bothering to post in this thread.
[/quote]

No, thats not directed at anyone in particular couldn't be could it? So yes I take THAT personally who wouldn't? Go away I told you your input is worthless. You clearly can't remember what you type from day to day time to go find another thread troll.

{"name":"hrzfab.gif","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/5\/3540e6c4f5c1d2cc998e46257e43e30f.gif","w":275,"h":210,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/5\/3540e6c4f5c1d2cc998e46257e43e30f"}

I don't deny that I was made a personal attack on you; however, it's still up to you as to whether or not you let it get to you.

To you perhaps, because you're too blinded by emotion to listen. However other people will read this thread and so I will continue to contribute for their sake.

I'll take the low-hanging fruit first, thank you.

I wouldn't want your condescending derogatory help either.

Don't worry Edgar, helping you is well beyond me.

So your definition of help is :
1) Insult someone and say they don't understand what they're talking about
2) When they try to come up with a solution of their own, make sure they feel stupid about it

I remember the math library thread quite well thank you. You said I didn't understand how floating point values worked, but I understood it quite well. When I proposed a perfectly valid solution, you called it naive.

Just how is it that you actually help anyone here anyway?

With friends like that, who needs enemies?

You might make a good politician - you play both sides of the fence equally.

I have read Beej's guide to network programming. I used that and a couple others to write the server side code. I am up to about 30 files of code at the moment - from characters to items to communications code and collision classes. I have tested all the commands on the server doing a loopback through an old MUD client of mine to make sure I get the correct responses from the server. So, yes it isn't so much will it work it is what problems will I have that need tweeking to make it smoother. Keep in mind most games back in the 90's were like warcraft 2 I spent hours playing that back then on KALI and in an AOL chatroom trading IP addresses - also prompted me to upgrade to a 56k modem for like 80 bucks.

I admit that I was being an unpleasant ass. I also accept your criticism of my behaviour, and I agree that a consequence is that I've not been particularly helpful.

However, what is not acceptable is to start making totally illogical arguments, especially when they fly in the face of accepted literature on the subject. If you do this, then you make yourself an easy target.

If we're all completely honest on what's going on here then it's probably something along these lines:

David has had a good first stab at client-server synchronisation, but is struggling a bit because, if we're honest, it's not an easy problem.

I'd had a bad day, and, partly because I've been working on this problem for the past 2 years and now have my own client-server game working smoothly, and partly because I can be an arrogant prick at times, I was rude in my first post.

David got offended, quite rightly, but then made the error of criticising the information I was providing rather than my attitude. Illustrating a lack of understanding on the subject.

I was offended by this, and so said some unpleasant things.

I think that pretty much sums it up.

I'm completely unapologetic about the information that I have provided, and I still claim that he will fail to make something that is playable over the internet unless he fully understand what those articles are talking about.

However, I do apologise for my condescension, arrogance and unpleasantness.

Nice.

Obviously, James Lohr was correct, but it is pointless to tell others negative comments. We don't know everything, and, at one point in our lives, we were just as knowledgeable as the OP is.

Hell yeah. I remember being hurt as much as David in some of my first answers.

Anyway, a few smash aren't bad if in the end all is under control. That's just the result of burning minds exchanges.