Transitioning from Main Menu to entirely different games

Game Mechanics
#1

I use the Test-Driven Development framework to develop my game. Whenever I start off developing, the first thing I have to do is to get a game to work, and skip the visuals until I’m sure the game is working as intended.

Starting from scratch, when I develop a game, I head straight to the game core mechanics. Basically, when I start debugging, I go straight to the game, not straight to the main menu. The game core mechanics are glued tightly together with the outer game framework (i.e., a JFrame object wrapping a GameComponent that envelopes the core game, and nothing in between).

And then after I finish developing the core gameplay, I begin working on the main menu. And this is where I usually end up messing the code structure up. When I try to work on transitioning, the code that was anchored in to the GUI layer (the GameComponent wrapping around the main core game) now becomes hard to separate. I then have to create tons of Boolean flags, add new variables, delete some deprecated codes, and then try to mash them all up without even glancing at how the code structure should be, because I know the structure itself is in shambles from the moment I start adding in the visuals. It’s really frustrating knowing that by adding in a middle layer between GameComponent and the core game, I remove the relationships between them two Objects, and tying them up with a temporary container that strings through the middle layer and connect those two Objects.

And that’s not all. After stringing the middle layer in-between the two Objects, adding more core games to that mess can make the job tougher than ever. It’s so messy, that I don’t feel like working on it.

What do you do after that? What do you do that can prevent this from happening?

#2

Separate menu logic from the game logic.

Usually if you plan a game out first, it becomes easier to make your game modular. I prevent making tangled messes by making sure that each of my code sections are separated into “screens”. In my games, the “main menu screen” is separate from the “game screen” which is separate from the “options screen”. Each one of my screen is accessible via a switch statement.

I did a lot of BASIC, where programming is a big script. If you don’t separate the logic and make it easy to tell it apart, you end up with a jungle that can’t be tamed.

#3

I’d use a state based method to transition. Create a super class Screen, for example, and then have you games extends from that. E.g. MarioGameScreen or DungeonCrawlerScreen etc. And in your main loop just type screen.render() or whatever. To switch screens create a method called setScreen(Screen screen). In this method you will change your current screen (this.screen) to the new screen. You might also want to create another object called lastScreen which when the new screen is set will set the old screen to the lastScreen. Just in case you want to revert.

#4

Hard to comment without further details/examples as starting out just with core should give you pretty good preconditions for a separation of visuals and the game core.