Question

This is a topic that has been bugging me recently.

When creating a game in a JFrame, and you want to add the graphics to a JPanel with the paintComponent()-method, how would you give the game different stages? Which is best for performance?

The two ways I can think of doing it are:

1. Adding and removing panels which contain their own paintComponent()-methods and timers. A different panel would be used for each stage of the game (level etc).
2. Keep everything in one panel or frame, and have many boolean values and if statements. For example, if it is game over have a boolean value change to true, and within the paintComponent()-method, have an if statement which says if(gameover) and then paint the graphics for this stage of the game.

Or are there other, better ways of doing this?

Answer 1

“Abandon all hope, ye who enter [through Swing to create games]!”

To answer your question, JPanels are just a surface to draw on, like a chalkboard, or a piece of paper. They have nothing to do with stages, or anything else other than being a thing you can draw on, and a container for other sub-components.

To address the game-specific question, I’d recommend you don’t waste your time using Swing components to build a game interface. While it’s possible, you’re going to run into a bunch of performance problems that will just eat up your time. Based on your question you’re already thinking about low-level stuff like Timers to schedule things, and overriding the paintComponent() method – a very common mistake, and a road that many a failed project spend time on just to find out it’s not the best way.

If your question were literally a path in a forest that you could see, you would notice these things:

• It is well trodden (as it seems to be the most direct approach)
• Just around the corner are several spiky death pits of performance, and obscure, non-cross-platform compatible tweaks
• You have to figure out how to use Swing’s painting manager to do what you want, when in most cases for most games, you want direct, deterministic control over your rendering pipeline/process
• It is littered with the bodies of projects that try to use Swing for games, for weird (and silly) reasons such as, “I wanted to build a game that only uses the standard Java library.” Well, the standard library is nice and all, but at its heart it was designed to solve business problems, and be really good at server and networking software, among other things. If you’re not using at least some gamedev libraries, you’re probably missing out on using the right tool for the right job. Swing was definitely not built to be used by games, as it serves basically no needs that game developers have, unless you’re talking about the desktop apps/tools to build and edit levels and that sort of thing.

Instead, use something like Slick2D (for 2D games), or jMonkeyEngine for 3D shtuff. These libraries are designed specifically for building games, and are going to save you from having to reinvent the proverbial wheel, just to get your game up and going. They also have their own communities that can help you with library-specific issues.

On top of that, they have already solved some of the trickiest cross-platform issues, like dealing with various versions of OpenGL, and other technical details that I’ll bet you don’t really care about when at the end of the day, what you really want is, “Hey, just give me an [arbitrary resolution], graphics-accelerated surface to draw on, and don’t make it complicated!”