Skip to content
Advertisement

How to have the program regenerate a “new game” where previous grid letters get swapped with new grid letters

In this program I’m trying to input a functionality to start game, where if I click start game (MainMenu) a new jpanel opens up (MainGame), creating another jpanel that creates jbuttons in a grid. If i go back, and click start game again, a new grid should generate instead of the previous one, effectively starting a “new game”. the problem is that if i go back and click on new game again, the program creates 2 grids.

I’ve tried removing the instance of the grid panel with = null but it doesn’t work

Main function:

JavaScript

main game class:

JavaScript

Main menu class (this one contains the game generation part):

JavaScript

settings class:

JavaScript

what method can i employ to regenerate a grid?

Advertisement

Answer

In general, you should be working on the concept of decoupling your views and your data, this means that you could have a “game model” which could be applied to a view and the view would then modify itself based on model properties, this is commonly known as “model – view – controller”.

The problem is, however, you never remove grid from it’s parent container when you create a new game

JavaScript

Instead, before you re-intialise the grid, you should remove from it’s parent container

JavaScript

or you could just remove the components from the grid panel itself

JavaScript

A different approach…

At all stages you should be trying to decouple you objects and workflows from each other, so that it’s easier to change any one part without having adverse effects on the other parts of the system or workflow.

Looking at you code, for example, the navigation decisions are tightly coupled to each panel/view, but in reality, they shouldn’t know or care about how the navigation works (or the fact that there are other views), they should just do there job.

You can decouple this workflow through the use of delegation (backed by an observer). This basically means that the individual view doesn’t care “how” the navigation works, only that when it makes a request for some action to be taken, it happens.

You should take the time to read through…

But how does this help you? Well, it will help you all the time!

Lets start with the “game” itself. The first thing we need is some kind of container to hold the data base logic for the game, so based on your current code, it might look something like…

JavaScript

I know, amazing isn’t it, but this interface would grow to hold the logic required to run your game.

Now, we can apply this to the GamePanel

JavaScript

Now, the nice “juicy” part is in the buildUI which is called by setModel when the model changes. This just re-builds the UI based on the GameModel properties.

As for the navigation concept, you can see part of it in the GamePane via its Observer interface. I started by creating a seperate class to handle the navigation workflows.

This means that the “how” or “implementation detail” is decoupled or hidden from the other parts of the system. Instead, it makes use of simple observer/delegation workflow.

Each view provides an Observer (for the what of a better name) which describes the navigation actions it needs performed. For example, both the SettingsPane and GamePane simply have back. They don’t care what came before them, that’s up to the navigation controller to decide.

JavaScript

Runnable example…

So, that’s a lot of out-of-context code. The below is basically an example of one possible approach you could take to further reduce some of the clutter and coupling which is growing in your code base at this time.

JavaScript
User contributions licensed under: CC BY-SA
5 People found this is helpful
Advertisement