1

I'm building a game where the object is to move a knight around a world and be able to fight other knights.

I've got a class Main that starts the game:

public class Main {

    public static void main(String[] args) {    
    new Game();
    }
}

A class Game that creates a JFrame:

import java.awt.GridLayout;

import javax.swing.JFrame;

public class Game {

    public Game() {
        JFrame frame = new JFrame();
        frame.setTitle("Knights Tournament");
        frame.add(new Board());
        frame.setSize(700, 700);
        frame.setLocationRelativeTo(null);
        frame.setVisible(true);
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    }
}

And a class Board which (you guessed it!) creates the GameBoard:

public class Board extends JPanel {

    Tile[][] grid = new Tile[15][15];

    public Board(){

        // Create the grid
        CreateGrid();

        // Add the player
        grid[0][0] = new Player(0, 0);
    }

    // Method that creates a grid of tiles
    private void CreateGrid() {
        setLayout(new GridLayout (15, 15));
        for(int i = 0; i < 15; i++){
            for(int j = 0; j < 15; j++){
                grid[i][j] = new Tile(i, j);
                add(grid[i][j]);
            }
        }
   }
}

The grid initialy consists of 15x15 tiles.

 public class Tile extends JButton implements ActionListener {

    public int xCo;
    public int yCo;

    public Tile(int x, int y) {
        setXCo(x);
        setYCo(y);
    }

    public void setXCo(int x) {
        this.xCo = x;
    }

    public void setYCo(int y) {
        this.yCo = y;
    }

    public int getXCo() {
        return xCo;
    }

    public int getYCo() {
        return yCo;
    }
}

The problem i'm facing is the following: I would like to replace grid[0][0] by another class Player that expands tile. The difference between tile and player would be that the Jbutton gets a text saying 'P' i've tried this:

public class Player extends Tile{

    public Player(int x, int y) {
        super(x, y);
        this.setText("P");
   }

}

In the constructor of the class board i tried changing grid[0][0] from tile to player so it would display P, but it doesn't do so for some reason (It does change the type of grid[0][0] to player...) I hope someone can help.

  • Why not just update the existing `Title` state rather then replacing it on the board? – MadProgrammer Dec 16 '14 at 23:22
  • The player class will be getting extra variables like 'attack', 'defence' etc... I also will be adding enemies whom i will be able to fight. To check wether a tile contains an enemy i would then like to use the instanceof function... – Nicholas Haesen Dec 16 '14 at 23:24
  • So the tile should be replaced by a player, if you know what I mean – Nicholas Haesen Dec 16 '14 at 23:26
  • This information should be part of the model layer, not the UI, the UI represents the state of the model, the model manages how things work, the controller managers the interaction between the two... – MadProgrammer Dec 16 '14 at 23:35

1 Answers1

2

You shouldn't try and maintain the state of the object with the UI, per se. Rather the UI should visualise the state of the underlying logic of the game (or model). This allows you to modify the model, change the rules, add/remove elements (think adding new monsters or loot for example), without need to physically modify the UI or how it visualise this state (to a large degree).

The idea is, the Player attributes should be maintain with an class of it's own, which is managed by the model. The UI would then be used to visualise the state the model.

When clicked the Tile would notify the "controller". The controller would request stateful information from the games "model" and based on this information the "controller" would change the state of the button(s) to meet the requirements of the "model"

This would simply require the "controller" to update the button(s) information (text/icons) without needing to change the physical buttons.

This separates the responsibilities into defined layers and reduces the coupling of the code, so one or more layers can change, but the overall structure doesn't break down or need to be heavily modified to handle these changes.

The model is responsible for maintaining the virtual state of the game, for managing the interactions between the individual game objects (combat etc).

The UI is responsible for providing a visualisation of the model for the user and the controller is used to manage the interaction between the take, taking user input and pass it to the model, monitoring changes to the model's state and telling the UI when it needs to update.

The Model–view–controller paradigm is a common approach used in GUI development across different lanuguages. Take a look at Model–view–controller for more details.

halfer
  • 19,824
  • 17
  • 99
  • 186
MadProgrammer
  • 343,457
  • 22
  • 230
  • 366
  • Do you mean Tile or Title? – dahui Dec 16 '14 at 23:36
  • @Jpa That's all part of the test ;) – MadProgrammer Dec 16 '14 at 23:45
  • Seriously? Anyone care to enlighten me on the reason for the downvote? – MadProgrammer Dec 16 '14 at 23:52
  • You didn't really answer his question, just looks like you suggested another pattern to use. – dahui Dec 16 '14 at 23:57
  • @JPA Yes, I suggested another pattern, to help the OP avoid common pitfalls to the approach that they "think" they need. Rather than sending the OP down a path which would cause them more issues, I suggested a new path which would allow them to not only achieve what they were trying to do, in a better way, but would also make it simpler to achieve and maintain in the long run, as well as introduce them to appropriate methodologies within the framework they are working. Rather than trying to simply point out where the trigger is (so they can shoot their foot off), I introduced gun safety... – MadProgrammer Dec 17 '14 at 00:02
  • @JPA There is more to "answering" a question then simply fixing the code that a person might think they need, sometimes, as professionals, we need to be prepared to let people know when they're direction is leading them astray and provide alternatives where appropriate. The MVC in this case is a better approach to the problem the OP is facing, the functionality they want to implement does not belong in a UI class, it belongs in the model layer, the UI then simply represents that (model) state... – MadProgrammer Dec 17 '14 at 00:04
  • Still don't think it's a good answer to be honest, you go straight into an explanation without actually explaining what you are suggesting. Also even if the OP did change the pattern used they would still have this same problem. If they get this part of the program correct it will be far easier to refactor, otherwise they will run into the same problem. – dahui Dec 17 '14 at 00:05
  • I think OP would benefit more from you fixing the problem and then suggest that they change the pattern, it will be easier with working code! – dahui Dec 17 '14 at 00:09
  • @jpa...It was probably light on pros and cons, guess it's to easy to simply see the tree and forget about the forest... – MadProgrammer Dec 17 '14 at 00:16
  • @JPA I'm reluctant to offer a fix to the OP's current approach, simply because they'd ignore any more advice and we'd be having a list of problems for weeks to come (and yes, we get that a lot) – MadProgrammer Dec 17 '14 at 00:20
  • Far better answer now, I removed the downvote, I just thought if anything it was more confusing before for the OP – dahui Dec 17 '14 at 00:20
  • @JPA No disagreement, thanks for taking the time to help improve the answer – MadProgrammer Dec 17 '14 at 00:21