First Java Game - Help REALLY appreciated

[Gaz Johnson]

Hi guys. I'm pretty new to java / O.O Programming and a complete beginner as far as game programming goes so forgive me if i ask any stupid questions.

I'm trying to decide on a structure for my board game.

Here is what I have so far:



I'm pretty confident the majority of what I have so far is ok. However, the driver-->game-->board part i'm not 100% on and not sure where to go from here.
As it stands the "board" is the JPanel which will have a picture set as its background and the counters will be drawn upon. The "game" class is the JFrame but doesnt have much code yet other than to add the JPanel. The driver simply creates an instance of game.

Are there any obvious omissions or changes before I go any further. I know it doesn't matter if its not coded perfectly but I don't want to pick up bad habits

Background : The program will display a "board" and player will interact with that board via their own "control panel". The counters will move in an animated motion and not simply change position so i'm looking into threads.

Thanks for any comments / advice / suggestions in advance. It would be really appreciated.

[Gaz Johnson]

I was just thinking a bit more and it would make sense maybe to have the "Game" class to create the board as it does not but then two instances of a new "Game controller" class which would allow the user to interact with the game.

Would this be good practice to have 3 seperate JFrames? One for the board and another one each for controllers?

[Brian Legg]

I'd like to help you out but I need more information. I know this is a board game and it's one player, but that's about all I know. It is hard to come up with a design in an OO world without more details. Are there pieces the player moves? What do the counters do? I see you have 4 types of Counters... what do each of these do?

Don't be secretive, I doubt anyone here will steal your ideas

[Maneesh Godbole]

From the "Queen" "Black counter" "White Counter" "Striker", I think we can safely deduce it is Carrom

[Gaz Johnson]

100% correct. Also, the game will be two player as I want to get a grips on this before even thinking about AI but its a possibility in the future. I will just have the striker switch to the oposite side of the board and focus will be gained on the opponent players control panel but it will be player from one terminal.

Sorry, the only reason I left it pretty open is i'd considered changing it to something with similar principles such as snooker but i'l leave it as it is for now.

Thankyou both for the replies

[Brian Legg]

Never heard of Carrom or Snooker, sorry

I think you have a good start. I would make a Player class which belongs to the Game, this way the Game object can control the interactions between the Player object(s) and the Board object. Also, all the Counters should belong to the Player object(s). In this way the Game object will create a loop that goes until 1 Player wins or quits while all other events are handled here as well.

Have you ever created a state engine? If not, and you are still looking into multi threading this game, I would read up on it.... makes game design a lot easier.

GL

[Gaz Johnson]

Well snooker is like pool? or billiards? This is a LITTLE bit like a board version where the striker is flicked at the pieces.

Thankyou for your suggestions, I will implement them. If the player "owned" the pieces how would I go about putting the queen on the board? Or would I make the black and white counters belong to each appropriate player and the queen and striker belong to the board?

A state engine? No i'm not familiar with that. I will do some research. Thankyou again.

[Brian Legg]

Let me read up a bit more on this game first Gaz before I tell you something wrong. I was assuming the pieces belonged to the Players like in Chess or Checkers. I like to code my designs to match real life and make as much sense as possible so I'll get some more information on this game first.

[Brian Legg]

Gaz Johnson wrote:Or would I make the black and white counters belong to each appropriate player and the queen and striker belong to the board?

After reading up on Carrom I would agree with that. The only other thing I would consider changing would be the WhiteCounter and BlackCounter. These 2 objects have the exact same behavior and properties, the only thing that makes 1 different than the other is color and the Player that owns them. You could just make a Counter class, give however many to each Player object and whoever is going first sets all their Counters to white and the other Players Counters to black. Unless I missed something they don't behave differently so there is no need to seperate them.

Let me know how it goes or if you have more questions. Sounds fun.

[David Muhar]

Gaz Johnson wrote:

Judging by your picture, Id say you were programming in BlueJ. As its your OO layout thats your concern, I would highly recommend using another IDE like Eclipse or Netbeans. It makes organising projects alot easyer.

Yet BlueJ does have a nice graphical representation.

[salvin francis]

If this is your first game,
i honestly recommend dont try extreme graphics oriented stuff (like carrom)

anyways,

While i feel the design is Good,

its incomplete.

Things missing:
1. Player (very very important)
2. Controller (i will explain this)


Here is a hint on how you can proceed from here........


The Controller Object decides which player's Turn it is to play and sets the coins to the original locations to start the game
Player Object, if Human, plays his turn
Controller decides who should play next (eg: if piece is taken, then current player retains his turn)
[If i am not wrong, maybe the "Driver" object mentioned is same as my Controller]


Things that seems challenging:

physics object:
Moving the piece in proper speed, emulating "cuts" "rebounds" and "transfer of momentum" between 1 or more pieces

player object:
providing an interface (GUI) thats friendly allowing:
1. Direction to shoot
2. Force to apply

[Brian Legg]

salvin francis wrote:[If i am not wrong, maybe the "Driver" object mentioned is same as my Controller]

I assumed the same thing Salvin. Also, I agree that this is a challenging game for a first try. I didn't realize how much graphics would be involved until I read more on what type of game it is. You will definately need some type of update method in your controller (or driver) object that will loop through all the Counters, drawing them 1 frame at a time to make it appear they are all moving at the same time. Not the easiest thing to do with all the math involved.

GL Gaz, keep us updated

[Gaz Johnson]

Sorry for the delayed response, hoping to make some progress on this over the weekend.

Thanks for the comments guys. I might live to regret it but i'm going to give it a shot. I might fail initially but i'l learn along the way.

I'm going to work through the suggested changes now. To clear up the confusion about the classes and what they do, I should'v been clearer.

Board : extends JPanel -
Game : extends JFrame - just adds the Board JPanel to its content pane
Driver : Creates an instance of game, sets it default close operation and gives it visibility.

[Gaz Johnson]

For setting the position each instance of counter class will have an x and y value stored. I thought I could have a drawOn() method in the counter class. However i'm not sure how that class would "know" to draw onto the JPanel constructed as the Board class.

[Brian Legg]

Gaz Johnson wrote:For setting the position each instance of counter class will have an x and y value stored. I thought I could have a drawOn() method in the counter class. However i'm not sure how that class would "know" to draw onto the JPanel constructed as the Board class.

Each Counter could have the x, y location of it's center (since it is a round object) like you said, but I would not have a drawOn() method inside the Counter class. The Counter object should not draw itself, mostly because, like you said, it doesn't know about the Board object. I would create a drawCounter method inside the Board class which takes a Counter as a parameter and then draws it on its self. OR, if your Board class is just really just a JPanel then push the drawing code upto Game object.

I usually have a controller object I call GameEngine or GameKernal or something that does all the high level functions. The GameEngine will create the Board, the Players, the Counters, and everything else. Now that you have 1 object which has a reference to every other object you can easily have this object render the game graphics, control the game flow, manage resources, change game states, etc. It sounds like this class would be huge but it's really not. I usually declare and initialize all the objects and then pass them off to helpers like ResourceManager or StateManager to do the actual dirty work. It may not be the best design but it works.

Did you end up reading anything on State Engines?

[Gaz Johnson]

Again thankyou Brian, your an immense help. I did a search and looked in a couple of books and couldn't really find anythin to explain to me what they are exactly. Does it go by any other name?

[Gaz Johnson]

Brian Legg wrote:
The GameEngine will create the Board, the Players, the Counters, and everything else. ..

Is this ok to do? It takes away from the player owning the pieces, the queen and striker being owned by the board etc although having one class create them is would be SO much easier. I'm struggling to just conceptualise how il program this right now. As no one class owns all the pieces which makes the redrawing more difficult.

[Brian Legg]

I'm sorry, I wasn't too clear with my post. Really the GameEngine will create the highest level objects like Board, Player, ResourceManager, StateManager, InputManager, etc. When GameEngine creates the Player it will (in the constructor or right after construction) create the Counters. The Board will (same as the Player object) create the Queen and Striker. All of your objects will keep the same hierarchy, but since all the high level objects are created in one controller it can render anything it needs to. Something like the following:

(this is more psudo code then it is working code)

GameEngine {
     Board board = new Board();
     Player human = new Player("white");
     Player computer = new Player("black");

     //all Counters are all ready created at this point inside of Player class

     method draw() {
          drawBoard(board);
          for(counter : human.getAllCounters()) {
               drawCounter(counter);
          }
          for(counter : computer.getAllCounters()) {
               drawCounter(counter);
          }
     }

     method run() {
          while(gameOver != false) {
               human.takeTurn();
               computer.takeTurn();
               draw();
          }
     }
}

Obviously I am leaving a lot out, but I hope it gets the idea across. The ResourceManager may not be needed depending on how much graphic work you are going to do. If you are going to have title screens, help menus, and lots of other bmps/gifs then I would suggest having one to upload new graphics and null out the handles for ones you no longer need. The InputManager I mentioned would just be a simple object that constantly checks for user input like pressing enter, space, esc, etc.

[Brian Legg]

I did a quick search and found this interesting article on State Engines. It is not written in Java but the concepts are written out in English which are much more important than how you implement it. Let me know if you have questions.

[Gaz Johnson]

I'm currently stuck on working out the destination from the info I input using the three sliders. I've started a new thread however for that problem as it is a bit off topic

[Gaz Johnson]

Just wrote a longer post but somehow I got logged out and its lost. Anyway...

I've got a striker which I can use correctly. It recognises impact with walls and rebounds. It also decelerates.

Am I going to have to do multithreading when i introduce multiple pieces? So far the above operates without creating any extra threads. Am I missing something fundamental? I'm sure I had convinced I neeeded to use multi-threading?

[Brian Legg]

Loops should work fine, no need for multiple threads. The only time I have found it nessasary to create more threads is when I need to do some processor heavy activity without bothering the user by making him wait. For instance if I want to load graphics and draw a level but at the same time I want the player to see an animated loading screen then I will use a seperate thread. You should be able to move the striker and all other pieces without any additional threads.

Let us know if you need help with that.

[Gaz Johnson]

This part was working in the GUI :

public void move(Rectangle boardWalls)
    {
        setX(getX()+currentDxDy.getDx());
        setY(getY()+currentDxDy.getDy());
        
        
       //left
        if(this.getX() < 0)
        {
            //System.out.println("Left@ : " +this.getX() + this.getY());
            System.out.println("Left Impact");
            currentDxDy.setDx(-currentDxDy.getDx());
        }
        
        //top
        else if(this.getY() < 0)
        {
            //System.out.println("top@ : " +this.getX() + this.getY());
            System.out.println("Top Impact");
            currentDxDy.setDy(-currentDxDy.getDy());
        }
        
        //right
        else if(this.getX() > (boardWalls.getWidth()-getDiameter()))
        {
            //System.out.println("Impact right @ : " +this.getX() + this.getY());
            System.out.println("Right Impact");
            currentDxDy.setDx(-currentDxDy.getDx());
        }
        //bottom
        else if(this.getY() > (boardWalls.getHeight()-getDiameter()))
        {
            //System.out.println("bottom@ : " +this.getX() + this.getY());
            System.out.println("bottom Impact");
            currentDxDy.setDy(-currentDxDy.getDy());
        }
        //decelerate(0.1f);
   
    }    

Now i'm rebuilding the code to give it better structure and I mustv changed something.

I've created the following file to test

public class Driver
{
    
    public static void main(String[] args)
    {
        Rectangle rec = new Rectangle(500,500);
        Striker one = new Striker(10,10,10);// (start x position, start y position, radius)
        one.setMovement(new Vector(1.0f,1.0f));   //(set the movement vector to 1,1)
        while(one.isMoving() == true)
        {
            one.move(rec);
            one.printPosition();
        }  
    }
}    

Which gives the following results :
These correctly increment x and y by the correct values until a collision is detected. The X value seems to respond to collision correctly, but the y value (on impact with bottom) jumps about up 1, down 1 : registering multiple impacts one after another with the same side

 
..
..
X Position :488.0
Y Position :488.0
**************************************
**************************************
X Position :489.0
Y Position :489.0
**************************************
**************************************
X Position :490.0
Y Position :490.0
**************************************
Right Impact
**************************************
X Position :491.0
Y Position :491.0
**************************************
bottom Impact
**************************************
X Position :490.0
Y Position :492.0
**************************************
bottom Impact
**************************************
X Position :489.0
Y Position :491.0
**************************************
bottom Impact
**************************************
X Position :488.0
Y Position :492.0
**************************************
bottom Impact
**************************************
X Position :487.0
Y Position :491.0
**************************************
bottom Impact
**************************************
X Position :486.0
Y Position :492.0
**************************************
..
..
   

I think i've got a really simple error but can't see it right now

[Gaz Johnson]

Think i'm sorted. I'l reserve proper judgement as to weather i've handled it correctly until i put it back in swing. Sorry for the last post, bit lengthy

[Gaz Johnson]

For my FSM i've got the states:

1.WAIT (for player to take shot)
2. MOVING
3. COLLISION
4. POTTED
5. SCORE
6. BOARD COMPLETED

Any i've missed? Should I incorporate potted and scored into one?

EDIT: also maybe I should have some state which checks previously potted and decides whos turn it is or if a faul has been made?

EDIT: hmm.... player one and player two shoot from different sides of the board. So should I make 2 states : WAIT_PLAYER_ONE and WAIT_PLAYER_TWO rather than just WAIT?

Thanks guys

[Gaz Johnson]

Brian Legg wrote:

GameEngine {
     Board board = new Board();
     Player human = new Player("white");
     Player computer = new Player("black");

     //all Counters are all ready created at this point inside of Player class

     method draw() {
          drawBoard(board);
          for(counter : human.getAllCounters()) {
               drawCounter(counter);
          }
          for(counter : computer.getAllCounters()) {
               drawCounter(counter);
          }
     }

     method run() {
          while(gameOver != false) {
               human.takeTurn();
               computer.takeTurn();
               draw();
          }
     }
}

Sorry for all the posting guys. Ok, if I do something like above as suggestion very kindly by Brian, whats the best way of each player recognising each others counters. e.g. when i pass control to the player class and call the method takeShot or whatever I need it to check for collisions with counters stored in the array in the other player class........

Bearing in mind as soon as collision is detected the second players counter movement vectors are updated and then the movement picks up where it left off

[Brian Legg]

Gaz Johnson wrote:Sorry for all the posting guys. Ok, if I do something like above as suggestion very kindly by Brian, whats the best way of each player recognising each others counters. e.g. when i pass control to the player class and call the method takeShot or whatever I need it to check for collisions with counters stored in the array in the other player class

I would have each Counter have a property that identifies which player it belongs to and have all counters belong to the gameboard. When the Player class creates the counters it should add them to the board with the proper settings.

For example:

(inside Player class) {
private ArrayList<Counter> counterRefrences;

public Player(Board board, String playerColor) {
for(numberOfCountersPerPlayer) {
Counter tempCounter = new Counter(playerColor);
counterReferences.add(tempCounter);
board.addCounter(tempCounter);
}
}
}

Yes, the Player class and the Board class both have references to Counter objects. The difference is that 1 Player class will only have access to it's own Counters while the Board will have access to ALL Counters. This will allow the board to keep a constant number of Counters in different states, either on the board (able to be hit, etc) or in a pocket. The Player class can remove a reference to a Counter once it is pocketed so that once Player.counterReferences.size = 0 then the Player has pocketed all their Counters while the Board on the other hand will never remove any references to any Counters. When you need a Player to have access to all the Counters, for instance when they are taking a shot, you will need to pass it a reference to the Board object so you can retrieve all Counters which have not been pocketed. There are other ways to do this, for instance the Board could create your Player objects and assign them the correct Counters.... your Player objects could keep a reference to the Board object and forget about thier own Counters (just get the info from the board), etc. The bottom line is that any time 2 sibling objects need to get data about each other you need to either pass that object along, or pass a reference of thier common parent so that you can then access that information. I hope I didn't stear you in the wrong direction originally, but you may want to think about a slightly different way to structure your objects so that the correct ones can get the right data, as in my previous example.

Hope that helps a bit.

[Ram Kunwar]

[mg]removed hijack

[Maneesh Godbole]

Ram,
Welcome to the Ranch.

Please do not hijack other people's threads. You can post your question by starting a new thread.
Also, please read http://faq.javaranch.com/java/HowToAskQuestionsOnJavaRanch