New to Java game programming. Need help with threads?

Newbie & Debugging Questions
#1

Hey all,

Just a quick question really, I prefer to attempt to solve the answer on my own, though a shove in the right direction is always appreciated.

I’m currently writing a “Simon Says” type game, but I’m throwing in a Wizard of Oz interface for another user to use to ‘mess up’ the player.

My big problem is that I’ll need almost constant communication between the two programs (two computer over a LAN, not the same box.)

My question really boils down to: Should I be using 1 thread to pick up the incoming information, 1 thread for outgoing information and 1 thread for the actual playing of the game?

I’ve read most of Sun’s tutorial, but I’m still not 100% clear on what situations require, or should be use with, Threads.

#2

Well it sort of depends. If you’re using TCP (which I’m guessing you will be) then TCP can lock while waiting for lost packets, which can freeze up everything. Multiple threads will help here, but there are other ways to get get the same functionality. The problem with using multiple threads for networking is that if TCP locks in another thread, the main thread probably shouldn’t do anything either. In a more common example, if two players are playing Tic Tac Toe and one is waiting for another to make a move, it doesn’t really make much sense to let the waiting player do anything when it isn’t their turn… therefore the multi-threading just becomes pointless. You can also think of games like Warcraft III where you get a “Waiting for Players…” box that pauses the game if communications have been lost for too long. I don’t know what will work best in your case, but a Wizard of Oz scenario will probably need to appear seamless in any case, so it may indeed make sense to have another thread that will delegate the work to a simple Simon AI in case the controller player is lagging.

In the end, though, stuff like UI should probably be in its own thread anyway, so that the waiting dialog can still be properly updated while another thread is locked waiting for input from the other player.

#3

I suspect the latency over a LAN will be so low that blocking won’t be much of a problem, but the safest way is to use separate threads.

#4

An easier route would be to use the java.nio stuff which gives you non-blocking sockets so you don’t have to punt your networking into a separate thread.

#5

EDIT: sorry, wrong thread

#6

what is a “wizard of oz” interface?

#7

http://lmgtfy.com/?q=Wizard+of+Oz+interface

:wink:

Sorry, I couldn’t resist.

#8

sry it took me so long to read that, lol. I will have to remember that website :wink:

#9

Love that link, lol

#10

Are you serious? This guy says he’s new to Java, and is struggling with threads, and you recommend java.nio?

I’d recommend him to read the Sun Java Tutorial, which explains both threads and networking.

To keep it thread safe in the most basic way, simply pass all incoming packets from the TCP streams to a (synchronized) queue, and handle it from the Even Dispatch Thread. It will work, and you can always refactor it later to a ‘proper design’ - the main priority should be to get it to work though.

#11

Yes, absolutely every source of input and output has to have it’s own thread, so it can block
independantly of all the others. That includes arranging that all outgoing chatter is queued
and transmitted by an output pusher thread, rather than sending it from whatever thread
generated it. Remember that mouse events, window events, and keyboard events are
“sources of input” too.

And once separated, those threads should do absolutely NOTHING else. To be specific, they should
not parse messages, update displays, attempt error recovery or anything else.

Most important of all, don’t try to refresh your displays in the system’s event generator thread.

Ideally, you will have one run loop in which all significant processing occurs. Other threads will
only feed it events through queues.

#12

I would say you usually have one thread for each independent communication. When you have an established dialog of request and response, you only need one thread wjich will send and receive in turns. If you want to handle each direction of communication on its own, you have two threads.

-JAW