Essentially just look at the menu as an alternate state for your Update and Draw features. I.e. If!InMenu - then draw the game, else draw the menu. Then you have your menu show up as you would any other gameobjects, and your updates/interactions are just focused on presenting the menu now.

If you're talking about a particular engine, like Torque, GameMaker or Unity, there maybe some options to purchase an interesting menu system, but you need to include what engine your talking about.

Edited by Dan Violet Sagmiller, 21 February 2013 - 08:13 AM.

Moltar - "Do you even know how to use that?"

Space Ghost - “Moltar, I have a giant brain that is able to reduce any complex machine into a simple yes or no answer."

Essentially just look at the menu as an alternate state for your Update and Draw features. I.e. If!InMenu - then draw the game, else draw the menu. Then you have your menu show up as you would any other gameobjects, and your updates/interactions are just focused on presenting the menu now.

If you're talking about a particular engine, like Torque, GameMaker or Unity, there maybe some options to purchase an interesting menu system, but you need to include what engine your talking about.

If you don't know how to make a menu then you don't know how to make a game.

Actually, I do know how to make a menu. This question is for a real time rendering menu...

Actually, I believe that you seems to know how to use an API that provide menu components... You don't seem to understand that your "menu" is just another game element that is managed like other game elements and displayed if your game state tells that it should be displayed.

Actually, I do know how to make a menu. This question is for a real time rendering menu...

Several people have asked this, but I'm interested too.

What kind of menu do you create that is not *real-time*? Why is it not? Are you creating menu's that some how have lag?

And what do you think makes a Real-Time menu? I'm guessing that your just not asking your question in a way that anyone understands. Real-time, is a common term. According to Wikipedia, "Real-time programs must guarantee response within strict time constraints." And so when we create menus, we typically expect a response to the players actions to be instant. I.e. when the player clicks, there is no perceivable time that passes before the program reacts and either begins its animations to the next menu or immediately displays the next menu or what ever other task was expected.

The only thing I can imagine, is that your menus are somehow resolved based on Client/Server interactions. I.e. you see lag/loss of real-time because of the network delays. If that is the case, you should make sure that your client side has all the menu's it needs immediately, and that additional network based options load after the view is already visible. Or, in a separate thread, download the menu options (for the menu items available to click) behind the scenes so that if it is clicked, it already has its content on the way. and if you click something else, stop the loading threads that aren't associated with the new menu.

Essentially just look at the menu as an alternate state for your Update and Draw features. I.e. If!InMenu - then draw the game, else draw the menu. Then you have your menu show up as you would any other gameobjects, and your updates/interactions are just focused on presenting the menu now.

If you're talking about a particular engine, like Torque, GameMaker or Unity, there maybe some options to purchase an interesting menu system, but you need to include what engine your talking about.

Thanks, but I'm asking about a real time rendered menu...

Again, if you are expecting to purchase a component for this, you need to include what engine or language you are developing your game in. HTML? Silverlight, Unity, GameMaker, C++, Java, etc...? Any menu components that exist are typically dependant on that information at least. But honestly, most people just develop their own, as the menus are far easier than the rest of the game development.

You may also want to consider where you are spending your time and money on this project. Unless the 'fun' of your games is in the menu system, you should really just put the easiest/most obvious thing in for it, and spend your time on the components people will play.

Edited by Dan Violet Sagmiller, 22 February 2013 - 08:02 AM.

Moltar - "Do you even know how to use that?"

Space Ghost - “Moltar, I have a giant brain that is able to reduce any complex machine into a simple yes or no answer."

Actually, I do know how to make a menu. This question is for a real time rendering menu...

As mentioned, all GUIs (including menus) are either real-time or event-based. For event-based menus, you use a GUI toolkit like Win32, Qt, or another.For real-time menus (like what 99.9% of games require), you make them yourself and treat them similar to any other game object in your game.

I suspect you are accidentally drawing your menus outside your rendering loop, so they don't get redrawn.

This is probably a communication issue because of different lingo we are using. Why don't you post an example of your working, non-realtime, code, and we'll tell you where to go from there? We might not all speak using the same terminology, but we all speak computer code.

What language are you using? Our answer will change depending on your chosen language. What APIs/third-party-libraries are you using to draw graphics on-screen? Our answer will also change depending on that.

Finally, what is a small working example of your existing non-realtime menu? We don't need an entire project, just the main loop and the functions involving the menu. We want to help you, but sometimes it's a bit difficult for us to understand someone's problem without seeing at least part of their code.

GameState_Menu_SoundSettings also has a button called "Back", or "Return to previous", or whatever. When clicked, instead of pushing the previous GameState (which is already on the stack underneath GameState_Menu_SoundSettings), then it just pops itself, leaving the previous GameState at the top of the stack, and pushes GameState_OceanSlideInAndOut again.

Each gamestate might have Update(deltaTime), Draw(), HandleInput(), or similar functions to handle their own functionality.

That's one way you could handle the logic. Which part of the menu are you specifically having trouble with? The logic? The drawing? The buttons functioning?

GameState_Menu_SoundSettings also has a button called "Back", or "Return to previous", or whatever. When clicked, instead of pushing the previous GameState (which is already on the stack underneath GameState_Menu_SoundSettings), then it just pops itself, leaving the previous GameState at the top of the stack, and pushes GameState_OceanSlideInAndOut again.

Each gamestate might have Update(deltaTime), Draw(), HandleInput(), or similar functions to handle their own functionality.

That's one way you could handle the logic. Which part of the menu are you specifically having trouble with? The logic? The drawing? The buttons functioning?

It's not the programming. It's HOW do i design the ocean? I know the programming for it, but the animations for it? I'm not necessary sure about that.. I don't know what program would best suit me.

That can be done in a number of ways, and almost seems like an art question.

You can use algorithms to manipulate pixels, like this (the concept applies to many languages and APIs, not just C++ with SDL).

You could use basic frames of an animation where you go from Frame 1 to Frame 2 to Frame 3, and so on.

It might even look fine just to have a static image move down the screen and then back up, depending on the style you are looking for.

Or you can use another method like playing a video (which can get more complicated, especially when you want your menus to appear underneath the waves).

That's assuming 2D. For 3D ocean waves, then you could google "OpenGL ocean wave simulation" (or DirextX if you're using that) where there are plenty of resources and discussions on many different methods.

When you say 'design', are you talking about how it should visually look, or how it should programmatically move?

You might have better luck creating a new thread about the art in the Visual Arts subforum, if you're asking how you can draw ocean waves or if you're asking about what art programs to use - those gentlemen would know better than I.

Otherwise, I just can't comprehend what you're asking. Maybe I'm just thick.

1), you need to learn how to get water/waves in your game at all. @Servant of the Lord and @Shadowisadog have both provided some excellent starting points for that.

2), is simply how to separate your Update/Draw functions at the root of your game. (presuming you understand the idea of loading, and then repeating the Update then draw methods for the duration of the game.)

- What I will typically do, is setup a variable somewhere, called "bool InMenu = false;"

- Each section of my game will be split up for processing, so I might have background.update(), units.update(), shots.update(), foreground.update(), etc... and then .draw() for each as well.

When we are in the menu, I only process the things needed to keep the graphics updated, like the current wave position. but I'm also calling the menu update method.

The draw still draws everything, juyst including the menu.

It sounds like what you need is that you would just re-point the camera at a spot with the waves. However, you may want to consider letting it show what ever was happening at the point of pausing/starting the menu. Because if you always want waves at the pause menu, your going to have to either reload a wave scene, which opens up lag points, or you would have to manage repointing the camera.

However, it sounds like all you want this for would be a starting menu. and in that case, you just need the wave scene initially, which is fine.

Moltar - "Do you even know how to use that?"

Space Ghost - “Moltar, I have a giant brain that is able to reduce any complex machine into a simple yes or no answer."