In-game menu for RPG

Newbie & Debugging Questions
#1

I’m trying to implement a standard in-game menu/display for my RPG similar to the one in pokemon, with the option to show player stats, inventory, options etc.
I’m wondering what’s the best way to integrate this into my game in terms of game state management?

Right now I’m planning to have a boolean value for each option, like showingStats and showingInventory and a unique class for each menu option, like StatsMenu and InventoryMenu. In my paintComponent method in the main game loop, it will check if a menu is showing and call the proper draw method. I feel like this approach is pretty inflexible, results in a lot of constant checking, and would require a lot of ugly nested code. For example if I have many submenus, I would need to create a separate class and hold a boolean value for each one.

Also the menu is transparent over the game, so it should be in the same JPanel. Can anyone suggest a more streamlined and extensible approach? Thanks

#2

Well, what I did was basically your approach, but then I have subclasses for showing wordwrapped text within some certain boundaries, and they all had their own draw-method.
It takes next to no CPU to check a boolean. Alternatively you could have different states in your menus, represented by a single integer, and have some constants to identify them. That is if you know your don’t have too much random stuff going on.

Take a look at what I did for mine. I did a lot of work to get there, but it ended up being very few classes for all that. Each menu (stats-panel, abilities, shop etc.) is a separate class, but all the individual text-boxes are the same three types: One wordwrapped box (each individual conversation-box and the ability-box at the top when fighting), one with the ability to choose from a list (the talk menu panel), and one where you can choose things from a list with the ability to have some things unavailable (the main menu and boxes in battle).

Showcase Video

EDIT: I wrote another guy here a long description of how I set all this up. If you want I can PM that big momma to you

#3

Menus are relatively simple and for the most part relatively stateless, at least as far as these things go.

Your game’s state machine would have a ‘Menu’ state, which would ensure that your Game’s State won’t change considerably (Use of items, moving of abilities, etc don’t constitute a major state change in this case) while you’re in a menu. From there, your Menu State would just be composed of different screens which you would display (This more like a flow chart than a true state machine).

In the Menu State all input is forwarded straight to your Menu System instead of being processed by the regular Game State Machine. This is because your Menu System will typically have a completely different event system than the regular game would, mostly corresponding to things like Select Menu Item X, Select next, Select Previous, activate menu item and back.

#4

@Ultroman
cool game :), could you please PM me the “big momma” you mentioned? looks like it could be very helpful. Any chance I could take a look at your code?

@UprightPath
I was thinking along those lines. A general Menu class would have a variable like currentScreen and would draw according to that?

#5

Mhm. Or at least mostly.

It really ends up depending on how complicated things are going to be in your system, what sort of input you’re accepting and what you library is. If it already has some sort of GUI management system for setting up focus/selected menu items and the like it becomes considerably simpler. Otherwise, you’ll need to add in a bit of extra data for tracking the selected menu item and the like.

Also, depending on how complicated your menu system is going to be, you might want to actually define it as some sort of tree that allows you to backtrack through it, perhaps holding onto cursor position information. Think about like in Pokemon. When you cancel using an item that still has some uses (Like if you use one of six PP Ups) you’re returned to the item select with PP Up still selected.

#6

Thanks :slight_smile:
Well, sure. The classes are written so you can actually just pop them into your game very easily. I’ll send them to you with the bits of graphics I did for them. You might want to change them, but if you change the sizes of them, there’re a lot of offsets you have to change around. Luckily, if you strip anything about images, you can build your own graphics around the middle, which is just plain drawString on fillRect

#7

Here’s how I do it:

Menu class


public class Menu {
	public void tick() {
		//empty
	}
	
	public void render() {
		//empty
	}
}

Example of how to create a new menu class, this one will be called InGameMenu


public class InGameMenu extends Menu {
	@Override
	public void tick() {
		//update menu stuff, like what is selected and what not
	}
	
	@Override
	public void render() {
		//draw your menu
	}
}

Example of how to render and update the menu


public void tick() {
	//This represents your main updating method, called from your game loop
	if (menu != null)
		menu.tick();
	else
		game.tick();
}

public void render() {
	//This represents your main rendering method
	game.render();
	if (menu != null)
		menu.render();
}

Here’s how to create a new Menu


public void tick() {
	if (input.escape.isPressed()) {
		menu = new MainMenu();
	} else if (input.e.isPressed()) {
		menu = new InGameMenu();
	}
}

This way of doing things prevents unnecessary boolean checks and improves overall readability and functionality.

Hope this helps.

| Nathan

#8

Thanks for the help guys, I got it working for the most part. I have a MenuHandler class that holds a list of all the menus that will be used, and a stack of all the menus that are currently showing on screen (it keeps the order they were opened so when one exits it simply calls pop()). The handler opens and closes menus when the game tells it to, and when a menu is open all input data goes to the menu.

Each menu object extends an abstract Menu class which has information and behavior common to all menus. Every menu must implement a draw() and doSelection() method that each have a switch statement that tells it what to do with the currently selected option. Each menu also has child and parent fields for submenu stuff. It’s just fillRect and drawString right now but it works for now :slight_smile:

#9

Cool :slight_smile:

Good luck with it!

#10

Whoot! Yeah, stack makes a lot more sense than a tree (At least, for how you actually store it.) Good job. :3