• 10
• 12
• 12
• 14
• 17

good/best way to build up a menu

This topic is 3637 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Share on other sites
You seem to have a decent idea of how to use your tools, but your theory isn't quite there--from your description, I would say that you need to decouple interface and logic more.

For example, you say you're switching based on "rect2.top". This isn't a good idea; your logic is depending on an implementation detail. What you should be doing is having some sort of enumeration or other indicative value in the backend, using that for your logic code, and rendering based on that indicative value (assigning rect2.top, where you're drawing your indicator arrow, based on it). Your way works, but it is not clean and maintaining it is going to be a serious pain.

Generally--and this is not a hard and fast rule, but it seems to be true in this case--global variables are bad, and there are almost always better ways to provide the same functionality. I would abstract each rendering subsystem into a separate class (all inheriting from the same base class). My own projects generally have a "SceneController" class which I subclass for menus and the game itself, with an Update() and a Draw() method. Handle game logic and state changes with the Update() method, and Draw() the screen. It has some other benefits, but that's the big one. (I use C# rather than C++, so this may be a little harder to set up in C++, but it should be the same principles.)

-Ed

Share on other sites
Quote:
 Original post by EdRYou seem to have a decent idea of how to use your tools, but your theory isn't quite there--from your description, I would say that you need to decouple interface and logic more.

That's the point.
Even if I can 'render' what I have in my mind, I always lack of order and efficiency. Unfortunatelly I can see this is not an easy subject to 'teach' (and even learn) since maybe it's greatly based on experience.
I've read something about a script enging in order to setup the menu and handle it, but it really scared me. I was going to use class somehow instead but I needed some advices.

"My own projects generally have a "SceneController" class which I subclass for menus and the game itself, with an Update() and a Draw() method. Handle game logic and state changes with the Update() method, and Draw() the screen."

Do you mean that you have multiple Update() and Draw() for each 'state' (for example, menu page) your game should reach?

I'm very confused, forgive me :P

Share on other sites
Quote:
 Do you mean that you have multiple Update() and Draw() for each 'state' (for example, menu page) your game should reach?
Basically, yes. Here's a hypothetical example. This is probably not the best way to do this, mind you, but it works for me. Code will be C#-ish (this has not been actually built, so syntax errors ahoy), but the principles should be obvious.

public class SceneController{    protected Boolean isRunning = true;        public SceneController() { }    public abstract void Update();    public abstract void Draw();    public virtual void Go()    {        while (this.isRunning)        {            this.Update(); // my own code has Update return a Boolean                           // that is stored in my equivalent of isRunning,                           // but that's just implementation details            this.Draw();        }    }}

My individual scene controllers - be they a rolling list of credits, the main menu, or the main game scene - all subclass from SceneController. While there's probably a better way to handle shifting between scene controllers, I do it inline, as below. There are some probably-obvious advantages to doing it this way. (My own code has a few beautifiers that I've omitted here, that support gradual fade-ins and fade-outs, but you can add that yourself.)

public override void Update(){    // do some stuff    DialogBoxController dBox = new DialogBoxController("Do you want to answer Yes or No?", DialogBoxController.Buttons.YesNo);    dBox.Go(); // this starts the Go() loop of the secondary controller, which               // will run until it sets its own isRunning to false; for the               // example here we'll guarantee that dBox will store a result               // value in a field.    Debug.Print(dBox.Result); // will echo something like "Namespace.DialogBoxController.ButtonResult.Yes")    // do more stuff}

It's a little hackish if you're going one-way and never intend to return to the previous scene controller, I admit that, and I suppose you could have stack overflows from a truly obscene number of recursive calls, but I know of no more straightforward way to do it. I also do not work with 3D graphics, so there may be additional requirements in that realm that make this unfeasible.

-Ed

Share on other sites
I'm trying to code a .cpp class hierarchy using your example. I'm quite new with classes, virtual and abstract stuffs. It'll be a good exercise anyway :P
Still I don't get how do you manage to return to the previous menu page (SceneController). I mean:

dBox.Go(); // this starts the Go() loop of the secondary controller, which
// will run until it sets its own isRunning to false; for the
// example here we'll guarantee that dBox will store a result
// value in a field.

If the user types Escape in order to go back in the menu 'flow', your secondary controller will handle this message and terminate. (right?).
But what's next? How do you keep trace of the previous menu page? Do you store it somewhere or do you handle it just with classes?

I do admit I still lack of insight using classes and maybe there is something that should be obvious to me but it is not :P