aspose file tools*
The moose likes Game Development and the fly likes Thread Problem In Text-Based Game Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Game Development
Bookmark "Thread Problem In Text-Based Game" Watch "Thread Problem In Text-Based Game" New topic
Author

Thread Problem In Text-Based Game

Dexter Ramsden
Greenhorn

Joined: Jul 17, 2013
Posts: 8
I just started programming a text-based game the other day and I'm having issues figuring out how to deal with handling the user input. I've read a lot of tutorials on how to do this, but none were really what I had in mind. What I want my code to do is display the text in the window and then use some method to grab the user's input and deal with it from there. I thought a good way to do that would be to use threads, but I can't figure out how to use them and not get a massive deadlock that makes the program appear as though it didn't even start. I don't have much experience with threads, which is another reason why I wanted to use them (good learning experience), but I've been fiddling with this for hours and haven't gotten anywhere.

Here's what I've got:

Main method:



InputField:



ProcessInput:



Thanks for any help you might be able to give!
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11408
    
  16

using threads seems WAY over-engineered. What has to be happening while you are waiting for input? All the text based games I ever played would print something, then wait for input. There was nothing to do until that input came. Then, the input would be processed, the state of the game would change, something new would be printed, then it would go back into a 'wait for user input' mode.

Threads are useful if stuff is happening while you are waiting for input - like drawing new images on the screen. But with only text, I don't see a need for them.


There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Dexter Ramsden
Greenhorn

Joined: Jul 17, 2013
Posts: 8
I had a feeling I was overdoing it.

I had another way going based on something I read in a tutorial that relied on using a "waiting" boolean variable, but when I did more than one thing with it, it didn't really work out. I'll experiment some more with different ways to make a "wait for user input" mode later.
Dexter Ramsden
Greenhorn

Joined: Jul 17, 2013
Posts: 8
I tried something new, which can catch input, but I'm not sure how to get my method to use the input it gathers. I tried adding a method to put the game into "wait for input" mode, but all that managed to do is freeze up the program while it waits.

Here are the changes I made:

Dragon:




InputField:


The setText() bit has a trim() method in it, now. Also, Dragon extends Thread.

I'm not really sure on a good way to go about this. I see the problem, but I can't figure out how to get around it.
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11408
    
  16

Dexter Ramsden wrote:...all that managed to do is freeze up the program while it waits.

I still don't understand what is your program supposed to be doing while waiting for user input...
Dexter Ramsden
Greenhorn

Joined: Jul 17, 2013
Posts: 8
Nothing. I want it to just wait, but right now, it never comes out of the "waiting" phase. The Dragon method is "stuck" even if InputField can successfully grab the input as it's typed.

When I run it and type something, the console displays:

"waiting" because it's in the waitForInput() method, and then the rest is from InputField. Dragon doesn't see that the "wait" variable is false, so the program looks frozen.
fred rosenberger
lowercase baba
Bartender

Joined: Oct 02, 2003
Posts: 11408
    
  16

How do you expect to ever break out of this loop:


wait is a local variable, and there is no way for it to ever change. Your stuck here forever in an infinite loop.

I think you need to slow down, and back up. You shouldn't worry about any GUI stuff until your underlying program works. Get your code to print to the command line. Have it wait for input. something like this may help. once you get that working, and working well...THEN start looking at adding a GUI on top.

Dexter Ramsden
Greenhorn

Joined: Jul 17, 2013
Posts: 8
I thought I could break out of it because I made wait a global variable that was being modified from outside the method, by InputField, but it didn't work the way I hoped.

As for the link, I've written loads of things using the console and readLine(), which is why I've moved onto a GUI-based interface. When I don't have a method attempting to use the input that's being entered, it "works." In quotes because the program will print whatever I type to the console. I'll keep fiddling with it.
Dexter Ramsden
Greenhorn

Joined: Jul 17, 2013
Posts: 8
I figured out a way to do it.

I added a "waitLock" Object and modified waitForInput and setWaiting, which is now setWaitingFalse:



Thanks for spurring my mind into thought, heheh.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 8008
    
  22

Dexter Ramsden wrote:I figured out a way to do it.
I added a "waitLock" Object and modified waitForInput and setWaiting, which is now setWaitingFalse:

I have to admit, I haven't read this thread exhaustively, but this just sounds like piling more logic on top of already redundant code. As Fred already told you, you almost certainly don't need to wait at all.

And BTW: please DontWriteLongLines. It makes your thread very hard to read. I'd split them up myself, but you have tons of them. I suggest you use the Edit key to break them up yourself.

Winston

Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Thread Problem In Text-Based Game