-1

So I've been making board game Funny Bunny (children's game) on Java. I first made it text based but now I've been building a GUI for it using Swing. The trouble is, I've never made a GUI before and tough the GUI itself has been fairly easy to make, I find it incredibly hard to combine my game and the GUI.

I'll first explain the basic idea of the game.

THE GAME

  • There are 2-4 players and they all have four game pieces.
  • There's a deck of special card that "run" the game (4 types: move 1, 2 or 3 steps and card for changing the board.

  • One turn consists of player revealing a card

    If it's a move card, the move a piece If it's change the board card, the board changes and holes may open. (Some places on the board aren't safe, game pieces might drop in a hole)

So, the idea behind the game is fairly simple.

The trouble, I've got no idea how to actually make it work with a GUI. I tought it'd be rather and started enthuastically building my GUI. I made the game view (I'll add a picture), main menu, number of players menu and all that stuff just to realize that I don't know how to really make it work with event-driven game.

Game view, work in progress, never mind the colors

I'd like to GUI version work along these lines 1. First, bunch of menus for setting up the players and stuff. That's okay. 2. In the game view, player reveals a card by pushing "Show card" 3. Based on the type of the card enter either stage: 3.1 Move a game piece. This would happen by clicking a game piece (either button on the side or a piece on the game board) --> This would start move a piece process --> Requires updating the board in the end OR 3.2 Change the board, which would updating the GUI board. I'm really lost with how to do this.

Should I use something like threads, or Swing Worker or what should I do? Do you people want to see some sample code? That'd probably help. Just let me know, and I'll post some (it requires some translating with the comments and stuff and that's why I didn't want just randomly post parts of my code here)

All help, comments, feedback... everything would highly appreciated and really helpful. Did I already mention I'm lost and stuck? I really am.

Rikkokiri
  • 85
  • 8
  • Are you porting the text based game or are you rewriting the whole thing from scratch? – Neilos Mar 20 '15 at 00:19
  • The concept is both simply and complex at the same time. Keep all you game "data" and logic that's required to manage that data, separate from the UI. The UI should monitor the state of the model and update it's view accordingly. It should also tell the model/logic that the user has done something (ie wants to draw a card, wants to move a piece). The model and logic layers should then decide how best to approach this and trigger appropriate state changes for the UI to update itself – MadProgrammer Mar 20 '15 at 00:19
  • MadProgrammer's point is exactly where I was thinking. If you're having trouble porting the code then it would suggest that you have tightly coupled game and UI logic (which is bad) you should be able to easily take your game code and plug any UI into it if it were well written. – Neilos Mar 20 '15 at 00:22
  • It is very good practice to compartmentalise your code keeping related things together and unrelated things apart (read into MVC for instance). The point is that you should be able to develop the game backend and the GUI separately. – Neilos Mar 20 '15 at 00:23
  • @Neilos Forgot to mention that! Currently I've been partially rewriting. There are classes for game pieces, board, cards, cards deck and players and I've been able to use those of course - like most of the original game code. But I started combining it with the GUI in a really odd way, I had to make a bunch of changes and I think I'm pretty much speeding to wrong direction now. (Sorry for such a long answer, I'm a verbal person.) – Rikkokiri Mar 20 '15 at 00:26
  • @Neilos I'd like to use to code as it is, but I don't how I should go about updating the GUI then. The whole GUI is new to me and there aren't really tutorial for building games like this (or I suck at finding them. I've been looking for weeks.) – Rikkokiri Mar 20 '15 at 00:29
  • :) if you have the characters use them! The Board, Deck, Cards, etc... would be the business logic of the app and would form the models in an MVC design they should define their own behaviour and nothing else. Controllers would be the Application logic (how you interpret user input etc... to give it to the models). This would leave you free to develop the views independently of these other bits. – Neilos Mar 20 '15 at 00:31
  • If your code is tightly coupled you'll likely have to rewrite most of it anyway. But if you just want to understand how to work with swing then there are lots of tutorials out there... what are your specific issues with tying the UI in? – Neilos Mar 20 '15 at 00:38
  • @Neilos I will! And I am! :) You and MadProgrammer seem to think alike! Thank youI'll take a look at MVC tomorrow (it's almost 3 a.m. where I am).Thank you for all the advice! I think I can pull this game off. – Rikkokiri Mar 20 '15 at 00:41
  • @Neilos The problem is mainly just I had no idea how to go on about updating the GUI. I had the right information but I couldn't find a way to nicely give it to GUI and do the updating. Also, "waiting" for the player to act (press take a card and game piece buttons) is a problem. – Rikkokiri Mar 20 '15 at 00:44
  • @Rikkokiri There are many ways to accomplish those tasks, in order to help we'd need to see code to see what you are trying to achieve (you'll get lots of different answers if you just ask "I want to accomplish X, explain..." which will be confusing). It'll be better to answer specific questions based on your existing code so that you don't get confused making massive changes unnecessarily. But that'll be better answered in a new more specific question I think (with code), good luck :) – Neilos Mar 20 '15 at 00:56

2 Answers2

1

You'll want to foster the concept of Model-View-Controller. The idea is to separate you program into layers of responsibility.

Model

The model is responsible for maintaining the data and stateful information about the program.

The model provides event notifications about changes to its state, which interested parties might need to know

View

Is responsible for representing the current state of the model(s) on the screen. It is also has direct connection to the user and is responsible for collecting user input which is handed to the...

Controller

Is responsible for binding them together. The controller takes input from the view and makes modifications to the model, based on it's rules.

The controller may even control information flowing from the model to the view.

In some implements of the MVC, the view and the model have no connection what so ever and only communicate via the controller. This is both good and bad. It's kind of bad as the controller needs to double up the communications coming from the model and pass them to the view, acting as a proxy, which can duplicate code. It's good as it protects the view and model from modifications which the controller may not allow for, based on it's rules. I tend to try and follow this model, but Swing itself hides the controller within the view, so it can seem more coupled.

This concept also relates to the idea of code to interface and not implementation. This means that the model, view and controller only know about the "contract" and not the details.

This allows you the flexibility to change the implementation (let's say, add network play-ability for example) without the need to change the entire program structure, as the components are only communicating with each other through the defined interfaces.

The overall intention here is to separate responsibility and allow each layer deal with it's own set of problems without mixing the through out the code. It also means that you can change certain layers over time with out adversely affecting the rest of the program, as they are not tightly coupled together

Now that you're probably completely confused, you could have a look at this example which demonstrates a login MVC

Community
  • 1
  • 1
MadProgrammer
  • 343,457
  • 22
  • 230
  • 366
  • @Rikkokiri hint if you are going to use MVC (i recommend it as it is good practice and learning to do so) then try hard to understand the difference between Business logic (models) and Application logic (controllers). Normally you should find you have fat models and skinny controllers. And the views are independent of this. Changing out the view would only require you to have the same signature for the classes, the content of the methods would change depending on the UI but crutially should not require any changes to the models or controllers. – Neilos Mar 20 '15 at 00:36
  • This is great! Confusing but great! I think I'll need to sleep on this but I'll get back to it tomorrow and apply this idea to making my game. Thanks for such an in-depth answer and comments! – Rikkokiri Mar 20 '15 at 00:39
  • @Rikkokiri Just take it in small steps, try getting parts of the game to work in isolation and then see how you can combine them – MadProgrammer Mar 20 '15 at 00:43
0

Not a while ago, I've made myself a card game in java. Not gonna give specific code details cause that would be impossible here but the best advice i could give you is this.

Find a tutorial about swing. This will help you understand the basics of gui-making as well as the basic components available.

Also search about Listeners in order to make your gui work based on the logic of your game.

These things alone would be enough to create something basic (or even advanced).

Good luck with your project

crystalfrost
  • 261
  • 1
  • 3
  • 14
  • Thanks for commenting! If' I'd have enough rep, I'd give you +1 for encouragment! I've been watching Swing tutorials and made quite a bunch listeners etc. when making the menu part (which works perfectly, thank god). I'm just not quite sure how to go about updating panels that are inside panels that are inside panels (the game board for example). – Rikkokiri Mar 20 '15 at 00:33