Thread: JButton ImageIcon Composed of Multiple Images

I have a grid serving as the playing field for a simple Tower Defense game (it's not necessary to know the game genre, but it might help). I need each individual grid location to be a clickable object, hence why I'm trying to use JButtons. Each grid location has one out of many possible background sprites associated with it, which will be determined upon loading the given map. However, each grid location also can have an arbitrary-length hierarchy of objects contained inside of it, each with their own unique sprite (E.G: Each grid location may contain a Tower, which may contain a Weapon, and so on). These objects may or may not be present when the map is created, and will be both added and removed frequently after it has.

Unless I'm mistaken, a JButton may only contain a single Icon. My problem arises because I need to be able to layer several images on top of one another for each JButton, and I'm not entirely sure how to approach the problem.

I've done some research, and there are several ways that I've come up with to accomplish this:

1. Combine the images and load them as a single Icon. Re-combine images and re-load a button whenever its grid location's contents change.
2. Make each grid location a separate JPanel and override its paintComponent to draw the images from back to front. Use a transparent JButton on top of each grid location.
3. A hybrid of the two: Have the front-most image be the JButton (the last to be drawn) and use an overridden paintComponent to draw the rest behind it.

I'm not experienced enough to know how well any of these would work. Are any of these non-starters or not worth the effort? What would be, in a more experienced programmer's opinion, the "best" solution in terms of expandability later? I don't need a working example or anything, I'd just like some advice as to which direction I should head in. I should be able to figure out a crude implementation on my own.

(I'm also worried about how I'm going to draw enemies at arbitrary locations on top of these grid locations, but I'll figure that out when I get there.)

I'd be happy to elaborate or try to whip up a code example for any of the above.

What would be, in a more experienced programmer's opinion, the "best" solution in terms of expandability later

'Best' solution is almost always relative...relative to the rest of the program, the knowledge of the programmer, and many other factors which are often temporal...what is 'best' at one time is often not several months down the line (I can't even count how many times I've looked at code months later and said 'what the heck was I thinking').

That being said, java is object oriented, so I would recommend using this to your benefit. Each image represents something, lets say a state - so create a class that defines that state. You can build off of these by creating classes that are composites of these states (these can define the overlay of the images). At this point, it doesn't matter if you use a JButton, JPanel, or whatever...because all you need to know are the state class instances that define what is (and even how they are) rendered.

Originally Posted by copeg

'Best' solution is almost always relative...relative to the rest of the program, the knowledge of the programmer, and many other factors which are often temporal...what is 'best' at one time is often not several months down the line (I can't even count how many times I've looked at code months later and said 'what the heck was I thinking').

I haven't been programming long, but I know exactly what you're getting at. I also completely understand that it may have sounded like I was asking to be spoon-fed. I suppose a better way I could have phrased it is: "which solution would have the fewest moving parts (and implicitly, dependencies on code I may or may not yet understand)". I'm absolutely positive I'll come up with a better way somewhere down the line; this program is probably the fifth total-rewrite of a game I started a year ago to learn my first language, after all.

Originally Posted by copeg

That being said, java is object oriented, so I would recommend using this to your benefit. Each image represents something, lets say a state - so create a class that defines that state. You can build off of these by creating classes that are composites of these states (these can define the overlay of the images). At this point, it doesn't matter if you use a JButton, JPanel, or whatever...because all you need to know are the state class instances that define what is (and even how they are) rendered.

I do have some skeleton code already which attempts to do this. The methodology I'm working off of in my head is that every level of the hierarchy has its own class object, and that object has an internal state that differentiates it. To use the bike metaphor: an object of Bike has a state of being Red, and has two objects of type Wheel which each have a state of being Black.

I doubt I'll have a problem with determining the exact composition of states the meta-object is in. My issue is more specifically of how I can combine this information to fit within the limitations of a JButton ImageIcon being the primary display mechanism (until I find a more appropriate way). That limitation is, to my knowledge, that the actual JButton itself can only contain a single image.

I also completely understand that it may have sounded like I was asking to be spoon-fed.

Not at all.

My issue is more specifically of how I can combine this information to fit within the limitations of a JButton ImageIcon being the primary display mechanism (until I find a more appropriate way). That limitation is, to my knowledge, that the actual JButton itself can only contain a single image.

Your 3 options originally posted all rely on a JButton...any reason why you need a JButton? A fourth option would be to use a JPanel and capture mouse events using a MouseListener. I'd probably prefer this option as overriding the paintComponent can give a bit more flexibility than merging images and/or setting a JButton icon with the composite, and you don't need to worry about having to overlay a JButton (which it seems, the only reason you want one is to capture action events, which can be done in a JPanel using a MouseListener)

Originally Posted by copeg

Your 3 options originally posted all rely on a JButton...any reason why you need a JButton? A fourth option would be to use a JPanel and capture mouse events using a MouseListener. I'd probably prefer this option as overriding the paintComponent can give a bit more flexibility than merging images and/or setting a JButton icon with the composite, and you don't need to worry about having to overlay a JButton (which it seems, the only reason you want one is to capture action events, which can be done in a JPanel using a MouseListener)

Simply put, because I had no idea what the interaction between them would be, or that they even could interact. Java is still a giant amalgam of unknown interactions to me, and sometimes it feels like that's the biggest thing getting in my way. JButtons, in some small way, are a known quantity to me, hence why I first looked to using them. Quite frankly, for most things beyond trivial syntax or common interactions it's hard to find a concise explanation on the internet (or at least find it from within the mound of "help!!1! my code iz not working!!" threads, which I'm sure you of all people know all too well). I'm not yet able to take any classes on programming, and don't know anyone capable of mentoring me, so I prefer to stick to my guns if they sound like they should apply. Usually there's a better solution somewhere, but I'm not a fan of flailing about in the API documentation hoping I'll find a better match for my problem. But that's just me ranting a little bit; wonderfully optimistic, isn't it?

Now that I know JPanels combined with an Action Listener would work well, I can warm up my search-fu and hopefully come up with search terms narrow enough to find me something relevant.

Java is still a giant amalgam of unknown interactions to me, and sometimes it feels like that's the biggest thing getting in my way

It doesn't come instantly, and there is a lot of information to learn. At times one needs to spend more time reading tutorials than writing code. For Swing, I would recommend reading through the following: Trail: Creating a GUI With JFC/Swing (The Java™ Tutorials)
I know, its a lot of information. But studying these at a higher level can give you a basic sense of the tools available to you. Once you have higher level idea of these, it will give you the knowledge to pursue them in more detail when needed.