I just started at the beginning, and wrote an entire menu-system from the ground up.I started by making my Message-class able to have a background of a certain color, drawn with fillRect using a defined position and size.Then I added text starting at a specific offset, using a specific font of a specific size, and wrote whatever was sent in the parameters. I logged the size of each letter, making sure to use a monospaced font for ease, to use in my calculations.Then I saw that I needed to be able to wordwrap strings, depending on how wide the box was and how wide the string was using the specific font I had chosen, so I did that.Then I quickly saw the need to (on instantiation) resize the messagebox to make it look right, depending on how many lines there were in total, so if I had created the box with space for just 1 line of text and the wordwrapping had made it into 2 or more lines, I had to add the extra space. Plus it's nice to be able to make it look just right, so if you accidentally spawn a message box which, with frame, margins and all that, is 4 pixels too tall or too small, you can make it automatically correct that, so it looks marvellous.

There are many things to consider. I now have 4 different messageboxes I use for different purposes. Some you can scroll in, and they stay in the dimensions I've provided for them, while others automatically fit themselves to the string I provide them and word-wrap on the set width of the box, and then there is one that doesn't do anything tricky, but merely exactly what I tell it to do in the constructor.

Then I made the buttons. Some can have animations, while some just require a string, a font, color(s) (multiple if they fade between colors when hovered) and such. When clicked they simply return a string to the class who asks them what to do when someone left- or right-clicks them. This is my MenuController asking them, if someone clicks within the button-boundaries (either using the animation-size and position, or FontMetrics when using Strings and drawString()). If the current MenuContainer (the current menu-screen) has the command in its own special command-list, the command is handled by it (like changing something from ON to OFF), but if the command is not known by the MenuContainer, it is passed on to the MenuController, which knows the game's Controller-class, making it able to apply a resolution change using information retrievable from the current MenuContainer.

Phew, that was a long one, but I hope you're getting the idea. I've spent about 3 months on this, and I've just barely finished the framework, but I can now easily make menus with all sorts of things in them, and I can very easily reuse everything I've done in my future games. I'm on to the hard part of making lists of buttons, which spawn message-boxes with stats when you hover over them...I'm scared, but I'm treading along, saving my entire projectfolder before I start every day, to make sure I can go back if I screw it up, or end up figuring out a better way to build what I've been working on on that day.

Really, there's no easy way out. Build what you want, and if you do it right, and remember to cut your losses instead of continuing down a faulty road, you'll end up having a menu-system you can use for any game, with minimum porting trouble. If you need new things for the new game, you simply add onto your framework, and you won't have to do that thing ever again. I just did a slider that can work with any number of increments, which automatically calculates the amount of increments itself upon instantiation, according to the values you pass it

I did something similar to Ultroman's. Since you use sprites in your game, why not treat the text as sprite as well. That way you can leverage what you did with sprites, such as the drawing method and mouse events. Start with a class for your text. Set the Font and text, and then use FontMetric to get the pixel size, and paint it the way you paint sprites, via paint(Graphics g). When I draw out my game map, I have it paint the text last, that way it's always on top.

@Ultroman:You... you... you did that with SWING??? (/Java2D/AWT)I could understand this if you did that with openGL, cause it doesn't give you windows and boxes and wordwrapping and stuff... but why did you do that with java2D, even if it already HAS that stuff?

@Ultroman:You... you... you did that with SWING??? (/Java2D/AWT)I could understand this if you did that with openGL, cause it doesn't give you windows and boxes and wordwrapping and stuff... but why did you do that with java2D, even if it already HAS that stuff?

@Ultroman:You... you... you did that with SWING??? (/Java2D/AWT)I could understand this if you did that with openGL, cause it doesn't give you windows and boxes and wordwrapping and stuff... but why did you do that with java2D, even if it already HAS that stuff?

Yes, I did all that with just a Graphics2D object and a lot of time

First of all, I wanted the training of doing an elaborate system, while retaining complete control of it. I've done that.

Secondly, I don't like Swing very much. I feel it is a bit clunky and doesn't leave much up to me. All that stuff with listeners, event-handling and all that, is very intricate and is hardly needed for a simple menu-interface in a game. Plus I'd have to extend just about all classes in Swing to get the results I wanted. Also, I've yet to see a visual editor be anything but a waste of time. It never lets me do what I want, because of strange restrictions I would've never put on the elements myself.

Then all I have to do is create the script to be run when calling the "BackThroughMenus" command in my MenuController (or in the MenuContainer, if the command is for that particular MenuContainer), and I'm good to go. Now I can design a new menu in a matter of minutes, and concentrate on building the commands I want for each button instead. I can make as many fonts as I'd like and put them in my ResourceHolder; actually I already have 2 sizes of that particular font.

You can see a little presentation of what I've achieved with this using the link provided below. It is all very much a test-environment while doing the framework, but the display-menu is working marvellously This particular menu is built with only 2 images, which are the slider-knobs and the background of the load-screen. Everything else is drawn with Java2D. I'm trying to keep it as lightweight as possible while doing the framework ^^Changing keys using the menu does not work at the moment.

NOTE: There IS something weird about the changing of resolutions I can't quite figure out, and I have a thread open where I'm trying to find the root of this problem. Very rarely, when changing to windowed mode, the screen will go black and you'll still be in full-screen, with your cursor.... Then if you click in the middle of the screen where the "APPLY"-button is, it'll set the resolution and windowed mode correctly. I have no idea why this is happening. If you have any idea, please do post it here.

publicvoiddraw(Graphics2Dg){ColorprevColor = g.getColor();g.setColor(bgColor);g.fillRect(posX, posY, width, height);g.setColor(textColor);// the +4 is just to give the text a bit of spacing from the edge, while +16 is because strings are// printed with the given position as their bottom, and they are printed "upwards", unlike images which// are printed downwards towards the right. If your text is smaller or larger, this number will vary// accordingly.g.drawString(text, posX+4, posY+16); }}

This is very simple, and does not take into account extra lines, wordwrapping or anything clever. I started out doing a system where my message-box would run through the entire text-string, find where I had put ¤ (resembling a line change), in which case it placed the strings in an array, and then I simply printed out each line of text using a for-loop with a drawString in it.There are obviously many ways to do this. Think about what you'll need, and do the easiest implementation of it.

How you handle exiting the window depends very much on your game-structure.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org