GameLoop architecture for local multiplayer

Question

I'm writing a game for Android to which I want to add a mulitplayer mode (local multiplayer via WiFi/Bluetooth, not online multiplayer via server). I stored the exchange-code between the client devices and the host device in th methods getInput() and pushInput(). I'm currently using a single-threaded gameLoop like this in my singleplayer mode:

public void mainLoopIteration(Canvas c, float deltaTime){
    compute(deltaTime);
    render(c);
    ...
}

My question is which of the following ways is the better implementation of the multiplayer "add-ons":

1. Adding exchange-calls to mainLoopIteration():

   public void mainLoopIteration(Canvas c, float deltaTime){
       pushInput();
       getInput();
       compute(deltaTime);
       render(c);
       ...
   }
   

2. creating a second thread that handles all the exchange stuff:

   public void run(){
       while(mainLoopIsRunning){
           pushInput();
           getInput();
           //???Thread.sleep(...);
       }
   

   }

Which solution you'd suggest or maybe do you suggest a completely other way?

Thx and regards Lisa

Answer 1

It depends on your architecture, but I think you're thinking about this too hard.

In general, if you're going to thread something it should be worthwhile to spawn that thread and keep it running (the operations on it should probably be at least somewhat expensive and timely to make.) In my experience, networking does not necessarily need to run on its own thread like this. Polling in the gameplay loop is simple, reduces locking and will probably simplify your architecture. It's unlikely your game will bottleneck from pushing a few states and receiving them - so I reccomend just pushing them out on the main loop.

Implement it and then profile it. If it really is a resource hog, then deal with the threading headache. If you don't need it though, why make yourself into more of a mess?