Dividing my game into classes?

Newbie & Debugging Questions
#1

So, my game is starting to get a bit cluttered and I’ve been thinking about trying to divide parts into separate classes, and I must admit that my inexperience with Java is catching up to me. I have Character and Projectile classes, but what I would like to have is an InGame class, Menu class, and LevelLoader class which are currently methods inside the main class. The problems that I don’t already know the answers to:

-The levelLoader methods create images which are declared in the main declaration section, and are used in the main loop run() for inGame purposes. Can Images/any variable or object be passed as arguments as not read only, or can I access the parrent class’s global variables some how?

-The Menu method shares the same keyboard and mouse listeners as the in game code. I’m assuming I can have a Menu class with mouse and keyboard listeners, I don’t know if I need to remove the in game listeners before adding listeners in the Menu class, or the proper way to do this. Also, the update() and paint() methods check to see what to draw (game/menu) and does so accordingly. If I want the them to have separate drawing methods how would I do that?

Thanks in advance.

#2

I think you should read this http://docs.oracle.com/javase/tutorial/java/concepts/index.html
http://docs.oracle.com/javase/tutorial/java/javaOO/index.html

[quote=“gbeebe,post:1,topic:37934”]
YES! :smiley:

#3

How about making a state-based machine? Each “state” is a different screen, such as the Menu, InGame, GameOver, etc…

I found this older post that should explain how this works, and this is what your Screen/State class should look like.

#4

@ra4king, this looks like what I’m looking for, but now I’m even more confused.
What I think I understand now:
-The idea behind this is I can have my main class create a couple of states, and depending on what the current state in use is, I can call the appropriate states identical method. My update() method of the main class can call the update() method of the menu class.
-I only need to have listeners in my main class then and then have corresponding methods in the states.

I’m not 100% sure why I need to use interfaces, I assume it’s for simplicity. And how would I share variables between these?

#5

Your main class would have a State variable, that your game loop calls the update on. Then when you change state, you replace the variable in main with the new state class. Kind of like this:
(pseudo code)

changeState() {
 if (mainmenu) {
  state = mainMenuObject;
}
else if (game) {
  state = gameOjbect;
}
#6

This is how I would do it, something that Android does good with states:

I would have a constant integer for the states, like:


const int MAINMENUSTATE = 1;
const int GAMEPLAYSTATE = 2;
const int HIGHSCORESTATE = 3;

int currentState = MAINMENUSTATE;

Then whenever I want to switch between the states, I just call a method, something like:


changeStates(int state) {
switch(state) {
 case MAINMENUSTATE:
     someFunctionOrClassThing();
     break;
 case GAMEPLAYSTATE:
     youGetTheIdea();
     break;
 case HIGHSCORESTATE:
     whyDidIMakeThreeStates();
     break;
 default:
     meh();
 }
}

And then just handle all of the necessary codes in their respective classes / functions.

#7

Lvl Class is a Jpanel object load all images here;

Main program- creates a jframe and loads a new lvlclass();

Sprite class–hold all data about the sprite coordinates etc mouse events.

etc etc, you want everything to be object orienated to be able to reuse instead of a cluster f**k program in one class, you need to divide everything logically.

And just create threads for updating and repainting which get called when the Lvlclass gets painted to the MainFrame program.

Main Game Class- is a frame
_
Sprite Lvl class-panel projectile class extends sprite class

  •              -

_ _

Pretty much make it like that IMO, hope that helps.

#8

You need some common type to assign a screen to a variable, so you need to extend from a base class or implement a common interface.

Use case is something like that:


// Available Screens
MainMenu mainMenu = new MainMenu(game);
Highscore highscore = new Highscore(game);
Level level1= new Level1(game);
Level level2= new Level2(game);
...
Level levelN= new LevelN(game);

// The screen currently shown to the user
Screen currentlyShowing;

...

// Switching screens because of some useraction or whatever
switch(nextScreen) {
 case MAINMENU:
     currentlyShowing=mainMenu;
     // You will need some kind of input delegation thingy, that calls keyPressed() or something on the screens
     inputManager.delegateInputTo(mainMenu);
     break;
 case LEVEL1:
     currentlyShowing=level1;
     inputManager.delegateInputTo(level1);
     break;
 case LEVEL2:
     currentlyShowing=level2;
     inputManager.delegateInputTo(level2);
     break;
 case LEVELN:
     currentlyShowing=levelN;
     inputManager.delegateInputTo(levelN);
     break;
 case HIGHSCORE:
     currentlyShowing=highscore;
     inputManager.delegateInputTo(highscore);
     break;
 }
}

...

// Your gameloop
while(notExited)
{
    // you might want to pass the gametime to methods, too 
    currentlyShowing.update();                    
    currentlyShowing.render(renderTarget);
    // your sync-method shoud sync to some fixed fps 
    sync();                                                  
}

Thats the purpose of passing game to each screen, so you can read out and manipulate common variables contained in the game class.