A question about structure.

[Regenuluz]

So, I've started working on my own little 2d rpg game, but I have a few questions.

Obviously the game will have several different screens. A menu when you start the game, where you can choose a new game, load, exit, that kind of stuff. Some of those choices will lead to other menus etc.

There's also the game screen, after you start a new game/load a game. In this screen there'll be several small menus, like character pane etc.

The way I'm doing it right now is having a Screen interface which all the other screens will be extending, so that I can do something like:

1	Screen screen = new mainMenu(this); // "this" being a reference to the game itself, so that the screens can call stuff like "game.setScreen(some_new_screen);"

Also for the mouse/keyboard input I'm doing this:

1   2   3

im = new inputManager(); im.delegateInputTo(screen); this.addKeyListener(im);

This way the menu screens will know if the up/down/whatever-key was pressed and act accordingly.

Is this the "right" way to do it? Also, the screens aren't really the ones to control anything, are they? I mean, they're just graphical things that should get painted.

So where would I have the input to actually move the protagonist around?

[aazimon]

The answer to this various from person to person.
    (In a rough sort of way), I think it would be best to have the menu item listen for the key event. Then the menu item would trigger other events. This would work for the protagonist (Sprite or Entity). The protagonist object will tell the screen (map) that it has moved. The screen would just draw the elements, the elements would tell the screen where it is.
   Does that make it clearer?

[Regenuluz]

Hmm, yeah. I think so. I'll give it a swirl and see if it works out. Thanks!

Games published by our own members! Check 'em out!

[ra4king]

It is normal java convention to have all classes start with an upper case letter, so it is best to have MainMenu and InputManager.

What you're doing is a basic State engine. Yes, the "Screen"/"State" controls all logic (ticks/updates) and rendering. The way you have things setup is perfectly fine, in fact it's the way I recommend to everyone

[Regenuluz]

Heh, I'll go rename the classes. ^_^

So the screens should handle logic as well as rendering? How about entities, like the protagonist? They aren't really screens but objects. So should I just keep a "list" of them somewhere and have them painted when needed, or?

[ra4king]

Game is a container of Screens. Screens are containers of Entities. The Screen should manage a list of entities and make them interact but Entities should be a separate "Entity" class