Client-host networking strategy

[Mutoh]

In the process of making a platformer with plans for a local multiplayer I have begun considering giving it an online multiplayer as well. I have done some research on networking an I want some input on my strategy.

Overall idea:

(click to show/hide)

I plan to employ a client-host architecture. The game would make a clear distinction between two separate states: physical and graphical. Game entities would actually be represented by two objects: one physical and another graphical; the physical object sends data to the graphical one after every step of the physics engine with the data changes that the graphical state needs to apply.

The game would use a semi-fixed timestep. Physics stepping at a fixed pace and graphics updating as fast as possible - with graphical objects using interpolations to translate between changes; the graphics would essentially  always be one frame behind the actual physical state in a local game. I consider using extrapolation on the networked game if it takes too long to receive the next graphical state, but only to a certain limit.

A host would process both a physical and graphical state of its own and clients would only have access to the host's graphical state. The host keeps sending the data changes that it's applying to itself for the clients to apply to their own graphical states - the host can also dump the entire graphical state to a client any time if requested. The criteria for when I should send entire dumps is not decided - I am planning on doing so once every second for every client.

---

Clients would only send input to the host, perhaps with intervals of once every [physics' step duration] seconds, but how the host should organize its received input packets is a more blurry area for me.

Should I use TCP when clients are sending inputs to the host, so that no inputs are received out of order by the host? I plan on having the host not wait for inputs from its clients, and keep gathering the inputs it receives into a queue. The queue would be depleted as it advances its physics' steps. The following pseudo-code should exemplify the procedure:

(click to show/hide)

struct InputBatch
{
        std::map<PlayerId, InputData> inputMap;
       
        bool addInputData (PlayerId id, const InputData& input)
        {
                if (inputMap.find(id) == inputMap.end())
                {
                        inputMap[id] = input;
                        return true;
                }
               
                return false;
        }
};

struct InputQueue
{
        std::deque<InputBatch> queue;
       
        void addInput(const InputPacket& inputPacket)
        {
                if (queue.empty())
                        queue.emplace_back();
               
                if (!queue.back().addInputData(inputPacket.playerId, inputPacket.inputData))
                {
                        queue.emplace_back();
                        queue.back().addInputData(inputPacket.playerId, inputPacket.inputData);
                }
        }
       
        bool isEmpty()
        {
                return queue.empty();
        }
       
        InputBatch pop()
        {
                auto result = queue.front();
                queue.pop_front();
                return result;
        }
};

// ...

void Host::handleInput()
{
        // The host keeps polling input from a separate thread where it receives the inputs from each client...?
        for (InputPacket& inputPacket: pollInputFromClients())
        {
                m_inputQueue.addInput(inputPacket);
        }
}

void Host::updatePhysics (sf::Time& accumulator)
{
        bool updated = false;
       
        while (accumulator >= m_physics.FRAME_DURATION)
        {
                if (!m_inputQueue.isEmpty())
                {
                        auto batch = m_inputQueue.pop();
                       
                        for (auto& pair: batch.inputMap)
                        {
                                PlayerId playerId = pair.first;
                                InputData& inputData = pair.second;
                               
                                m_players[inputId].handleInput(inputData);
                        }
                }
               
                m_physics.step();
               
                accumulator -= m_physics.FRAME_DURATION;
                updated = true;
        }
       
        if (updated)
                m_physics.update(m_graphics);
}

void Host::tick (sf::Time& accumulator) {
        handleInput();
        updatePhysics(accumulator);
        updateGraphics(accumulator);
}

I am worried about possible too bothersome delays between the clients and response time. After all, it takes on average 100-200ms for a client to receive response from the packet it just sent. I am willing to limit the online gameplay only to LAN connections if the only solutions are complicated predictions - a client-host architecture is still effective against preventing the lockstep asynching problem of peer-to-peer and even allows late-join.

---

I apologize for writing so much, but I want some critiques, suggestions and overall guiding from developers here with more experience with networking in games and SFML, as it hasn't been long since I started studying networks and I have done pretty much no experiments. Developing of the game has only started and this is the best time to decide on such critical points.

[Noctiphobia]

I suggest reading this:
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking

[Mutoh]

That was an insightful read. I think I should store whole previous sequences of graphical states in a buffer, then. If I'm on sequence 20 and I receive a client packet in which the client acknowledges the sequence 15, I will compare sequence 15 and sequence 20 in my buffer and send the delta to this client.

Of course, the buffer should have a certain limit size, probably determined dynamically. If the client acknowledges a sequence that is no longer in the buffer I can send them the whole current graphical state - instead of sending it whole every X period of time. If the client's acked sequence is, say, 7 sequences behind the latest server sequence and my buffer is storing only the last 5 states, I can probably expand the buffer's limit to 7 for some time.

But I still don't have certainty on how the server would process input. Should I have the client keep sending packets to the server until it receives an ack response from the server? Let's say that, for example, a client whose last acked sequence was 15 will keep sending packets with their current input to the server. The client ends sending three packets before receiving the server's ack, all with different input data. The first input packet to arrive to the server was the second one sent. Upon acknowledge, should the server ignore all further packets it receives from the client that were marked with sequence 15? That is, should it ignore the first and third packets sent by the client while the client waited for a response?

[blojayble]

Are you familiar with this? http://zeromq.org/
It's a very nice library that, I think, will satisfy your needs. It has a very good guidebook, be sure to read it.

@EDIT, I skimmed trough the post too fast first time and got it somewhat wrong. I've been doing something similar before and assumed you are making the same thing. That aside, it still might prove to be useful.

[Mutoh]

Ah, ZeroMQ provides a custom protocol, right? I think I'm fine with what SFML already provides in regards to network, I only need help on how to manage my data.

I noticed that the client packet receiving strategy from my last post wouldn't work with input combinations that required nicely timed combos. I cannot ignore any packets, but I have to ensure that they are processed in the order they were sent. I think for that I will timestamp the packets.