• Post Reply Bookmark Topic Watch Topic
  • New Topic

Layout advice needed  RSS feed

 
David Yu
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm looking to make a simple game in java, a tower defense style game, and I haven't really done much of anything with GUIs beyond really simple stuff. Because of the rather rigid structure of the layout and how I plan to deal with targetting, I'm looking for a layout class, component, or whatever that keeps components the size and relative location I tell it to no matter what the user does. I don't necessarily want/need a fixed window size, but if that's the easiest, it's fine.

It seems like Gridlayout, Boxlayout, and Flowlayout are out. Springlayout seems to be along the lines of what I'm wanting, but the only ways I can see it working are hackjobs. That's quite possibly my fault though. Anyone care to lend their expertise?
 
Craig Wood
Ranch Hand
Posts: 1535
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you are committed to a component approach (vs. graphics/drawing) you can use a null layout and control your components with "setBounds" and "setLocation" after adding them. Or you can write your own layout manager to make the components behave the way you want. The second option can make for more interesting resizing behavior.
 
David Yu
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not against graphics/drawing, I just don't know what they are capable of, interaction-wise. If have some other way of taking simple input like a single click that could work just fine, but I don't see anything indicating that in the Java docs.
 
Craig Wood
Ranch Hand
Posts: 1535
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Using a graphics approach allows more flexibility but requires more work. You can use
java.awt.geom primitives like Rectangle2D and GeneralPath as your graphic objects,
keep them in a collection and select, move, change, and hit-test them from within your
event code (eg, mouse listener, gui controls, swing timer, thread animations). You can
make up about anything you can imagine this way.
The general approach is to set up you graphic class to draw your game, pass a reference to
it off to your event class(es) which they can use to call methods in the graphics class to
make the changes you want. Put these together in your gui class along with any user controls
you want.
 
David Yu
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for your insight. Most of what you said makes sense and I'm sure I'll get the rest as I start applying it.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!