I am writing a simple abstract game in an attempt to learn java programming, and eventually Android apps. I have been a windows/C++/C# programmer for over 20 years, but I am new to java. I have a solid understanding of the language, threads, GUI, etc.

My question is, how do I implement the state machine logic for a game where there is an initial welcome screen, which switches to the game screen, and allows the user to make a move, then the computer, then the user, etc.

I'm looking for a tutorial that goes beyond "Hello World" or "How to start a background thread". I just can't seem to get my head around the state machine logic for a simple game like tic-tac-toe.

I'm hoping someone has a link to a tutorial for a "your turn/my turn" type of game.

What I did for my game I'm working on is I just have 2 booleans: inGame and inMainmenu, and I flip the values when I switch from menus to game, or vice-versa. In your main game loop, just put the logic for each one there (or use an interface and put the logic for each one in it's own class)

I'm new to java too. I feel weird being the one giving advice for once x:

Don't feel weird, it's good advice, and appreciated.

I had considered a simple boolean flag to notify the computer player thread to actually make it's move.For some reason that seems "amateur" to me, and I thought there might be some other, more elegantsolution that I had never seen before. But, sometimes the simplest solution is the best.

You could use a state engine, which I believe is pretty much standard for this. I don't know how advanced your knowledge of Java is or anything, but it simplifies a lot of things and allow you to add as many different "states" as you want without having to change the main loop. It's pretty easy, but it relies heavily on object orientation, but as you have experience with C/C++ it should be a piece of cake.

Create a small State interface:

1 2 3 4 5

packagesomewhere.meaningful;

publicinterfaceState{publicvoidupdate();}

Then create a class that implements this interface for each "state" in the game; main menu, playing, pause menu, options menu, ending credits, e.t.c.

Should each state implement its own key listener, or is that a bad idea?

Probably not. They can, but it's probably not the best idea.

A better idea would be to have a key listener that forwards commands to your state, and allow the state to handle it some how. This doesn't mean the state itself has just that some member there should perform the logic.

Otherwise, you'll have to be adding/removing listeners all of the time to make sure that each state only receives the keystrokes when they're the active one.

My solution to listeners was to have the main class handle the actual "listening" and then sending the event to the current State.My State interface:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

publicinterfaceState {publicvoidnext(Graphicsg); //I'm not allowed to call it Update for some reason :(publicvoidmouseClicked(MouseEventevt);publicvoidmouseEntered(MouseEventevt);publicvoidmouseExited(MouseEventevt);publicvoidmousePressed(MouseEventevt);publicvoidmouseReleased(MouseEventevt);publicvoidmouseDragged(MouseEventevt);publicvoidmouseWheelMoved(MouseWheelEventevt);publicvoidmouseMoved(MouseEventevt);publicvoidkeyPressed(KeyEventevt);publicvoidkeyReleased(KeyEventevt);publicvoidkeyTyped(KeyEventevt);

}

Then my main class has the listeners and simply forwards the event; my keyPressed event in the main Class:

1 2 3 4

@OverridepublicvoidkeyPressed(KeyEventevt) {state.keyPressed(evt); }

You can set state to be any class implementing State. I am passing 'this' to my classes when creating them, and they set it to an internal variable of the main class called 'me' Then I can change state by doing a me.state = ... I do not have my main class implement State, the examples probably do so to make sure you have all the procedures necessary. Or maybe there's another reason, I dunno.

publicinterfaceStateextendsKeyListener, MouseListener, MouseMotionListener{publicvoidnext(Graphicsg); //I'm not allowed to call it Update for some reason :(//Probably because of a collision with the built in function in Swing with the same name }

And then just register the current state as a listener and you won't have to pass events through to the current state in your state handling code.

publicinterfaceStateextendsKeyListener, MouseListener, MouseMotionListener{publicvoidnext(Graphicsg); //I'm not allowed to call it Update for some reason :(//Probably because of a collision with the built in function in Swing with the same name }

And then just register the current state as a listener and you won't have to pass events through to the current state in your state handling code.

I was just as surprised as you were when I noticed it but it does make sense though. Name and argument collisions don't matter because there's no actual implementation of them, the "blueprints" just happened match up.

publicinterfaceStateextendsKeyListener, MouseListener, MouseMotionListener{publicvoidnext(Graphicsg); //I'm not allowed to call it Update for some reason :(//Probably because of a collision with the built in function in Swing with the same name }

And then just register the current state as a listener and you won't have to pass events through to the current state in your state handling code.

EDIT: Also, I'm assuming this, but it makes the most sense to me:

I have a canvas that I'm adding my listeners to. When you say register, then when we change states, we'll have to remove the current state's listeners from the canvas, change the state, then add the new state's listeners to the canvas, right?

Srsly gais, this is really helpful. Also, this implementation seems like it would make sense to have a state manager class. in between the various states and the game class that holds the changeState(State state) method.

You could use a state engine, which I believe is pretty much standard for this. I don't know how advanced your knowledge of Java is or anything, but it simplifies a lot of things and allow you to add as many different "states" as you want without having to change the main loop. It's pretty easy, but it relies heavily on object orientation, but as you have experience with C/C++ it should be a piece of cake.

Create a small State interface:

1 2 3 4 5

packagesomewhere.meaningful;

publicinterfaceState{publicvoidupdate();}

Then create a class that implements this interface for each "state" in the game; main menu, playing, pause menu, options menu, ending credits, e.t.c.

I think this is called a turn system and I believe you can just control the player's turns with booleans. I've actually made a Battleship recently and i've implemented a turn system inside of it. If you wanna see the code, just give me a message. xD

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