We Keep Coding

Event driven board game and GUI: How to connect?

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.

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

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

Java 2D Game Performance with Java Swing Timer

I am developing a shoot'em up type video game using Java Swing and I'm using a Java Swing Timer to control all of the screen updating. The main screen uses a BorderLayout, and I perform my graphics on a Panel contained within the BorderLayout, and use the AWT Graphics calls to draw.
Now as my game progresses, I would like to speed up the movement of my screen objects (ships), yet I still want them to smoothly cross the screen. I thought I could speeed things up by dropping the timeout value for the Java Swing Timer, down to around 5ms. But, I've noticed when I set it to anything less than 15ms, there does not seem to be much difference. Once you cross that threshold, there is almost no noticeable difference in performance. -Why is that?-
Another option would be to increase how many pixels each ship moves per update, but anything beyond 3 or 4 pixels, and things start to look jumpy.
Any ideas? And really want to keep the game in Swing, would prefer at this point not porting to a 3rd party library.
Thanks.

In all likelihood, this isn't a software issue, nor is it fixable with software. Your screen probably only refreshes about 60 times a second, meaning that the frames are only drawn 60 times per second, or once every (approximately) 16 milliseconds. Since this is a hardware barrier, there's no way to get it to update faster with software. You can probably count on your users only having 60Hz monitors, too, so it's more worthwhile to look into other solutions.
One solution that pops to mind is adding in motion blur, to make it seem like the ships are moving faster when they really aren't. It'll allow you to 'jump' a greater distance before it looks jumpy, since the blur tricks the eye into thinking it's going really fast instead of hopping across the screen. Unfortunately, the only things that I see to do motion blur are third-party libraries, though you may have better luck Googling.

I advise you that you change your Swing engine for JavaFX (at least), a technology with better performance and more tools to your disposal. Swing nowadays is considered a dead technology, as well as with the AWT before it. A great place to study and start JavaFX would be this one:
http://docs.oracle.com/javase/8/javase-clienttechnologies.htm
The ideal for the development of games, would be to use a library prepared for it, such as libGDX:
http://libgdx.badlogicgames.com/
But if your desire is to create a game in Swing, who am I to judge? Sometimes it is good to see old things. I myself still like Swing, even being obsolete compared to other things.
I think you may be implementing a wrong gameloop. Swing Timer does not really seem like a good way to update game logic. Even with different settings between different computers, is generally practical and easy to implement a gameloop to work properly, especially for the correct movement of the characters.
You see, a gameloop is the heart of a game, and needs to be implemented straight otherwise the game is developed wrong and with several limitations. Generally, in gameloop we have to take into account the desired FPS. Among game updates, we must take the time elapsed between the last update and the current update, so-called delta by many developers. You will find many materials about it on the internet, which I recommend:
http://dewitters.koonsolo.com/gameloop.html
http://www.java-gaming.org/index.php?topic=21919.0
https://www.youtube.com/watch?v=9dzhgsVaiSo
The past links will help you for sure, but if you want more about it, I recommend that you take a look at this book:
http://www.brackeen.com/javagamebook/
Even the material being old (as Swing is) you'll find details of how to implement a good gameloop with a keyboard and mouse iinput system, sound, the use of the best possible performance swing has to offer, among other cool things. And one more thing... To give you a better result with respect to the movement of the characters, I advice you to use position variables (X and Y) with decimal types such as float or double.
I hope you can do what you want. Good luck!

What should I do to speed up a slow GWT app using MVC

I have changed my app to use MVC and it has gotten pretty slow.
Description:
The application has a number of 5 composites, each composite represents different data and is not always showing
The app is using MVC and I am passing the model to each composite when an update occurs.
I am rebuilding a Tree (and all tree items) every time a notify is recieved, however, only one of the tree items would have changed, so this is possibly a waste.
Due to the style of the app I have to even notify() for insignificant things like changing the text in a text box or selecting a menu because I have a saved icon that turn to unsaved whenever something is changed in the tree Item.
All the composites are implementing the same Observer Interface, so all are getting updated on every notify().
Can someone give me some tips on what I should do to speed this app up. Which of the above might be more CPU hungry than others, ie, is rebuilding a Tree with < 20 items on every notify() going to use that much CPU time, do I need to re-design this? Should I create a seperate interface such as SaveStateChanged that will only notify the tree, or is this just a waste of time.

When an application is getting slow, then most time is often not spent performing the JavaScript calculations themselves (e. g. I don't believe, that just calling a lot of observers is a problem - it depends on what they do!). Very often, slowness is caused by things like redundant layout (e. g. when each of the observers causes a layout call). Sometimes, lots of DOM manipulations can also be a problem (mainly with Internet Explorer).
I would suggest to play a little bit with Speed Tracer, especially the redundant layout example. If that's not the specific problem in your application, you should be able to take a similar approach as shown in the example to track it down. Use markTimeline("String") to make special parts of your code show up clearly in Speed Tracer's graphs.

The first step you need to take is to isolate exactly where the performance problem is occurring. You've identified some good possible candidates, but you'll want to back that up with cold hard stats.
You may find you only need to address one of the above points, or that there might be another sticking point entirely

I suggest you get rid of the Observer interface in favour of something more finegrained. Look at the MVC architecture in Swing where a JTree is associated with a TreeModel and implements TreeModelListener interface to hear of changes to the model. The TreeModelListener interface has specific methods called by the model to indicate nodes changing, being added or removed from the tree. In addition it has a TreeModelEvent which provides even more data about which nodes are affected. If the model tells you precisely what has changed you will have a lot more scope for reacting intelligently from your listener implementations.

GUI guidelines for swing

Is there a resource where GUI design for swing is explained? Like best practices and such.

Design guidelines aren't exactly followed much anymore because Swing works on so many different platforms. Sun wrote up some a long time ago, and never changed them so I'd say read it if you think it will help. Here is some practical knowledge about doing swing development.
Never use GridBagLayout. Grab TableLayout. It radically simplifies layout for you Swing UI. GridBagLayout is the devil.
Don't over embed components just to get a layout right (i.e. embedded BoxLayout, etc). See point 1 for how to do this. There are performance issues having components on the screen.
Separate your program along MVC lines. Swing has View and Model separation, but in large programs the View (i.e. what subclasses a Swing Component) turns into a psuedo View/Controller only making things complicated to reuse and maintain. It turns into spaghetti code fast. Break the habit and create a Controller class that DOES NOT extend Swing. Same goes for the Model (no swing). Controller instantiates high level view classes, and wires itself as a listener to views.
Simplify popup dialogs using simple panels only. Don't subclass JDialog. Create a reusable dialog class that wraps a panel that can be used something like JOptionPane. Your panels will not be tied to dialogs only and can be reused. It's very easy when you work this way.
Avoid actionlistener/command. This is old junk and not very reusable. Use AbstractAction (anon classes are your choice I don't have a problem with them). AbstractAction encapsulates text, icon, mneumonics, accelerators, reusable in buttons, popups, menus, handles toggling enabled/disabled states, can be shared among multiple components, it also is the basis for InputMap/ActionMaps for mapping keyboard strokes to actions. ActionMaps give you loads of power for reuse.
It's best to have to view dispatch events to the controller. I'm not talking about mouse/keyboard junk, but high level events. Like NewUserEvent, AddUserEvent, DeleteUserEvent, etc. Have your controller listen for these high-level business events. This will promote encapsulation by keeping the concerns of the view (should I use a table, list, tree, or something else?) separated from the flow of the application. The controller doesn't care if the user clicked a button, menu, or checkbox.
Events are not just for the Controller. Swing is event programming. Your model will be doing things off the SwingThread or in the background. Dispatching events back to the controller is a very easy way to have it respond to things going on in the model layer that might be using threads to do work.
Understand Swing's Threading rules! You'd be surprised how few people actually understand that Swing is single threaded and what that means for multi-threaded applications.
Understand what SwingUtilities.invokeLater() does.
Never* ever use SwingUtilities.invokeAndWait(). You're doing it wrong. Don't try and write synchronous code in event programming. (* There are some corner cases where invokeAndWait() is acceptable, but 99% of the time you don't need invokeAndWait() ).
If you're starting a fresh project from scratch skip Swing. It's old, and it's over. Sun never really cared for the client like it did the server. Swing has been maintained poorly and not much progress has taken place since it was first written. JavaFX is not yet there, and suffers from lots of Swing's sins. I'd say look at Apache Pivot. Lots of new ideas and better design and an active community.

I have written a list of recommendations here.

In larger swing projects I do partinioning of the app like that:
Have one class per GUI element like JPanel,JDialog etc.
Use a separate package for each screen, especially if you have to implement customized TableModels or other complex data structures
Don't use anonymous and inner classes, implement instead an ActionListener and check ActionEvent.getActionCommand() in there.
EDIT: If you're rather looking for a tutorial or introduction you could start here

Maybe not exactly what your looking for but it won't hurt to take a peek at Java Look and Feel Design Guidelines

You can check the ideas behind FEST - a swing testing framework. It's main site is here and the project is hosted here

You can find some of best practices in chapter 4 of Professional Java JDK6 Edition

I have some guidelines too:
1) Use Maven and seperate your application into modules (view, controller, service, persistence, utils, model). Be sure you put your Swing components and dependencies only in view package, so if you want to change view framework some day, you can just reimplement view module but you can leave your business logic, controllers, etc... intact.
2) Use GridBagLayout because its very flexible and most configurable
3) Use a SwingTemplate (i can give you an example if you want)
4) Create a SwingFactory that creates components so you can reduces the amount of lines of codes since JFrames orso intend to be very large classes...
5) Let the view (JFrame, JDialog, etc...) have a dependency on controllers. Only do validation input on JFrames but then pass parameters to controllers. They will decide which business logic (service, processors, etc...) will be triggered.
6) Use lots of enumerations
7) Always think how your application can change or how it can be maintained. Therefore, use always code against interfaces or abstract classes. (Think abstract)
8) Use design patterns in your application because they provide confort and maintainability of your code. Make for instance all your controllers, services, dao's singleton classes. Make factories (swingfactory, ...) so you have to write less code over and over again.... Use observers so actions can be processed automatically.
9) Test your appliction: Make a choice between: TDD (Test Driven Design) or DDT (Design Driven Testing)
10) Never put any business logic on JFrames, because it is ugly and its not very Model-View-Controller design. JFrames are not interrested on how the data has been processed.
Hope that helps.

How can I best apply OOP principles to games and other input-driven GUI apps?

Whenever I try to write graphical programs (whether a game or really any GUI app) I always wind up with one or two god classes with way too many methods (and long methods, too), and each class having far too many responsibilities. I have graphics being done at the same time as calculations and logic, and I feel like this is a really bad way to go about organizing my code. I want to get better at organizing my code and abstracting out responsibilities to different classes. Here's an example of where I'd like to start - I want to write a Minesweeper clone, just sort of as practice and to try to improve my software engineering skills. How would I go about making this nice and object-oriented? For the sake of discussion, let's just say I'm using Java (because I probably will, either that or C#). Here's some things I would think about:
should each tile inherit from JButton or JComponent and handle drawing itself?
or should the tiles just be stored as some non-graphical MinesweeperTile object and some other class handles drawing them?
is the 8-segment display countdown timer (pre-Vista, at least) a separate class that handles drawing itself?
when the user clicks, do the tiles have mouse event listeners or does some other collision detection method loop through the tiles and check each one to see if it's been hit?
I realize that there's not just one way to write a GUI application, but what are some pretty basic things I can start doing to make my code more organized, manageable, object-oriented, and just over all write better programs?
edit: I guess I should add that I'm familiar with MVC, and I was originally going to incorporate that into my question, but I guess I didn't want to shoehorn myself into MVC if that's not necessarily what I need. I did searched for topics on MVC with GUI apps but didn't really find anything that answers my specific question.
edit2: Thanks to everyone who answered. I wish I could accept more than one answer..

Here is a simple (but effective) OO design to get you started:
First create a Game object that is pure Java/C# code. With no UI or anything else platform specific. The Game object handles a Board object and a Player object. The Board object manages a number of Tile objects (where the mines are). The Player object keeps track of "Number of turns", "Score" etc. You will also need a Timer object to keep track of the game time.
Then create a separate UI object that doesn't know anything about the Game object. It is completely stand alone and completely platform dependent. It has its own UIBoard, UITile, UITimer etc. and can be told how to change its states. The UI object is responsible for the User Interface (output to the screen/sound and input from the user).
And finally, add the top level Application object that reads input from the UI object, tells the Game what to do based on the input, is notified by the Game about state changes and then turns around and tells the UI how to update itself.
This is (by the way) an adaption of the MVP (Model, View, Presenter) pattern. And (oh by the way) the MVP pattern is really just a specialization of the Mediator pattern. And (another oh by the way) the MVP pattern is basically the MVC (Model, View, Control) pattern where the View does NOT have access to the model. Which is a big improvement IMHO.
Have fun!

use a MVC framework that handles all the hard organization work for you. there's a ton of MVC framework topics on SO.
using high quality stuff written by others will probably teach you faster - you will get further and see more patterns with less headache.

I'm not suggesting this is the only way to do it, but what I would suggest is something like the following. Other people, please feel free to comment on this and make corrections.
Each tile should inherit from something and handle drawing itself. A button seems like the best solution because it already has the button drawing functionality (pressed, unpressed, etc) built in.
Each tile should also be aware of its neighbors. You would have eight pointers to each of its eight neighbors, setting them to null of course if there is no neighbor. When it goes to draw, it would query each neighbor's IsMine() function and display the count.
If none of its neighbors are a mine, it would then recurse into each neighbor's Reveal() method.
For the 7-segment display, each digit is its own class that handles drawing. Then I would make a CountdownSegmentDigit class that inherits from this class, but has additional functionality, namely CountDown(), Set(), and Reset() methods, as well as a HitZero event. Then the display timer itself is a collection of these digits, wired up to propagate zeroes left. Then have a Timer within the timer class which ticks every second and counts down the rightmost digit.
When the user clicks, see above. The tile itself will handle the mouse click (it is a button after all) and call its Reveal() method. If it is a mine, it will fire the MineExploded event, which your main form will be listening to.
For me, when I think of how to encapsulate objects, it helps to imagine it as a manufacturing process for physical parts. Ask yourself, "How can I design this system so it can be most efficiently built and reused?" Think about future reuse possibilities too. Remember the assembly process takes small pieces and builds them up into larger and larger pieces until the entire object is built. Each bit should be as independent as possible and handle its own logic, but be able to talk to the outside world when necessary.
Take the 7-segment display bit, you could have another use for it later that does not count down. Say you want a speedometer in a car or something. You will already have the digits that you can wire up together. (Think hardware: stock 7-segment displays that do nothing but light up. Then you attach a controller to them and they get functionality.)
In fact if you think hard enough, you might find you want CountUp() functionality too. And an event argument in HitZero to tell whether it was by counting up or down. But you can wait until later to add this functionality when you need it. This is where inheritance shines: inherit for your CountDownDigit and make a CountUpOrDownDigit.
Thinking about how I might design it in hardware, you might want to design each digit so it knows about its neighbors and count them up or down when appropriate. Have them remember a max value (remember, 60 seconds to a minute, not 100) so when they roll over 0, they reset appropriately. There's a world of possibilites.

The central concern of a Graphic User Interface is handling events. The user does X and you need to response or not respond to it. The games have the added complexity in that it needs to change state in real time. In a lot of cases it does this by transforming the current state into a new state and telling the UI to display the results. It does this in a very short amount of time.
You start off with a model. A collection of classes that represents the data the user wants to manipulate. This could represent the accounts of a business or vast frontiers of an unknown world.
The UI starts with defining a series of forms or screens. The idea is that is for each form or screen you create a interface that defines how the UI Controller will interact with it. In general there is one UI Controller classes for each form or screen.
The form passes the event to the UI Controller. The UI Controller then decides which command to execute. This is best done through the Command design pattern where each command is it own class.
The Command then is executed and manipulate the model. The Command then tells the UI Controller that a screen or a portion of a screen needs to be redraw. The UI Control then looks at the data in the model and uses the Screen Interface to redraw the screen.
By putting all the forms and screen behind a interface you can rip out what you have and put something different in. This includes even not having any forms at all but rather mock objects. This is good for automated testing. As long as something implements the Screen Interface properly the rest of the software will be happy.
Finally a game that has to operate in real time will have a loop (or loops) running that will be continually transforming the state of the game. It will use the UI Controller to redraw what it updated. Commands will insert or change information in the model. The next time the loop comes around the new information will be used. For example altering a vector of a object traveling through the air.
I don't like the MVC architecture as I feel it doesn't handle the issues of GUIs well. I prefer the use of a Supervising Controller which you can read about here. The reason for this is that I believe automated tests are one of the most important tools you have. The more you can automate the better off you are. The supervising presenter pattern makes the forms a thin shell so there is very little that can't be tested automatically.

Sorry to say it, but it seems you have mess in your head trying to improve your coding too much in one step.
There is no way to answer your question as such, but here we go.
First start with OOP, think about what objects are required for your game/GUI and start implementing them a little at a time, see if there are chances to break up these objects further, or perhaps reunite some objects that make no sense on their own, then try to figure out if you have repeated functionality among your objects, if you do, figure out if this repeated functionality is a (or many) base class or not.
Now this will take you a few days, or weeks to really grok it well, then worry about dividing your logic and rendering.

I have some tutorials that are written in C#. It discusses this very same topic. It is a starting point for a RogueLike game.
Object Oriented Design in C# Converting Legacy Game
Object Oriented Design: Domain Type Objects
Object Oriented Design: Rethinking Design Issues
BROKEN LINK - Object Oriented Design: Baby Steps in Acceptance Testing