Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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

share|improve this question
2  
WiFi and bluetooth are network interfaces, too. That means one device has to act as a server to the others. So I would recommend you to develop your server code just like you would for a game with a centralized server architecture. –  Philipp Apr 15 '13 at 13:13

1 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?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.