🔒 Locked

[java] Advice on menu system

Started by BlackArrow Jan 27, 2003 at 1:02 PM 2 replies 450+ views

Original Post

Jan 27, 2003 at 1:02 PM

Hello, and all that. Being a fan of the numerous incarnations of Bomberman on the SNES, I decided it would be fun (and good practice) to create a Java version of the classic game. The following is just how I expect my game/menu system to function. All I ask is advice and suggestions, if any. The system: The system is composed of three main components: a Screen, a ScreenDisplay and AbstractMenus. Screen - an abstract representation of any screen the game could display, such as the key binding screen, or the map select screen. ScreenDisplay - responsible for displaying a Screen. ScreenDisplay uses a fixed time step scheme** to alternatively "step()" and "draw()" the screens. Input is initially handled by the ScreenDisplay (to check for ESC presses) then passed to the Screen. Input is tentatively modeled as an array of booleans representing keyDowns (suggestions are welcome here). AbstractMenu - an extension of Screen representing a basic menu (since all menus appear on the same animated background). Specific menus extend this class to implement thier own functionality. Menus are keyboard only (for the retro feel) and are created with CyclableMenu and CyclableMenuItem***. Key presses captured by the menu are sent to the CyclableMenu, which handles moving the selection cursor and cycling through choices. When a screen is exited (enter is pressed), the menu logs all of its data to a static Configuration class which the game reads during initialization. The menu then proceeds to tell the ScreenDisplay which menu to load next (i.e. display.setScreen(NEXT_SCREEN) ) The game itself will be represented by a Screen (including the win/draw/match victory screens), since all it needs to run is step() and draw(). A drawback of this method is that menu flow needs to be hard coded. Advice? Suggestions? Please!? Thanks! **Taken from the article at [url=http://www.flipcode.com/cgi-bin/msg.cgi?showThread=Tip-MainLoopTimeSteps&forum=totd&id=-1]flipCode[/url]. Ensures that the logic is run at a fixed rate (say, 15Hz) regardless of the frame rate the machine is achieving. ***A list of items, with a cursor pointing to the currently selected item. Each item in the menu has a number of states which can be cycled through.

SpinParity

Jan 29, 2003 at 8:06 PM

I currently have a very similar system working for my applet game. (The sequencing of screens is about the only part of the game that works properly at the moment!). I am quite pleased with it. Its nice to see someone else bring up this particular topic.

I figured the best way was to represent the screen sequencing logic was by a single class, hence isolating the hard coding from my other classes, which I want to remain reusable. A ''ScreenLinker'' I suppose you would call it. This is responsible for starting Screens depending on the messages it receives from Screens that have finished execution. It also returns the currently running Screen if asked (Usually by the host Applet which maintains the rendering Thread).
I haven''t decided yet how information should be passed between screens. For instance getting the final score from the game screen to the highscore table screen.

I also have a KeyBlock object which does what you suggest regarding key input, it extends a KeyAdapter, trapping KeyPressed or KeyReleased events accordingly and then setting the appropriate public boolean variable. So far it has about 10 keys in it. Which is all I need for my game.

JP

BlackArrow

Jan 30, 2003 at 7:40 PM

It''s great to know someone else is interested in this problem!

As for passing information between screens, I have opted to use a static class to hold information. I can see several ways to handle this problem:

- Use a "singleton" pattern, such as GameVars.getInstance().*
- Use a static class and varibles, i.e. Config.curScore = 3;
- If the construction of the screens invlovles costly graphics loading procedures, instantiate them all at the beginning with a link to a Config instance, and later access the screens via something like ScreenRepository.getScree(KEY_BIND);
- Log all the information to a text file

The first two are the most appealing to me, but whatever will work best given your situation should be your choice.

One advantage to having the current input state in a single structure: If your game uses completely deterministic logic, you can simply reinput the same values into the game to create a replay system! Simply log the input state at each tick to a text file, and presto!

Dwiel

Jan 30, 2003 at 8:08 PM

I have used the same approach in my c++ game. i have one base class Screen, and then whenever I want to make a new screen, I derive a new class and override the functions such as FrameMove, Render, Etc. Seems to have worked for me. I don''t know if that''s how I will implement the screen system in my new game though... should probobly put some thought to it huh?

Tazzel3d ~ Dwiel

P.S. I''ll let you know when I decide on the method I will be using when I decide.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.