Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (601)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  New to Java game programming. Need help with threads?  (Read 2338 times)
0 Members and 1 Guest are viewing this topic.
Offline cbech

Junior Newbie





« Posted 2009-06-08 16:34:44 »

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.
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #1 - Posted 2009-06-08 16:42:22 »

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.

See my work:
OTC Software
Offline SimonH
« Reply #2 - Posted 2009-06-08 17:02:00 »

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. 

People make games and games make people
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #3 - Posted 2009-06-08 17:16:40 »

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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline davidc

Senior Devvie


Medals: 5
Projects: 2



« Reply #4 - Posted 2009-06-13 12:56:02 »

EDIT: sorry, wrong thread
Offline h3ckboy

JGO Coder


Medals: 5



« Reply #5 - Posted 2009-06-13 18:31:22 »

what is a "wizard of oz" interface?
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #6 - Posted 2009-06-15 23:37:26 »

what is a "wizard of oz" interface?

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

Wink

Sorry, I couldn't resist.

See my work:
OTC Software
Offline h3ckboy

JGO Coder


Medals: 5



« Reply #7 - Posted 2009-07-29 11:49:35 »


sry it took me so long to read that, lol. I will have to remember that website Wink
Offline Wildern

Junior Devvie





« Reply #8 - Posted 2009-07-29 16:02:05 »

Love that link, lol
Online Riven
« League of Dukes »

« JGO Overlord »


Medals: 840
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #9 - Posted 2009-07-29 16:54:13 »

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.

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.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ddyer
« Reply #10 - Posted 2009-07-30 03:12:47 »


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.
Offline JAW

Senior Devvie


Medals: 2



« Reply #11 - Posted 2009-08-05 21:28:35 »

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
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (30 views)
2014-12-15 09:26:44

Mr.CodeIt (20 views)
2014-12-14 19:50:38

BurntPizza (42 views)
2014-12-09 22:41:13

BurntPizza (76 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (51 views)
2014-12-03 16:27:13

CopyableCougar4 (48 views)
2014-11-29 21:32:03

toopeicgaming1999 (115 views)
2014-11-26 15:22:04

toopeicgaming1999 (103 views)
2014-11-26 15:20:36

toopeicgaming1999 (31 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!