software design question

[luckymutt]

I'm looking for an opinion as to what would be the more efficient and clean way of setting up an app.
In what what I'm working on there will be a main menu to select one of up to four levels.
The user would choose a level(mouse click) that would either open a second window for that level or load the level into that same window(hiding the mouse for fps at that point) , hitting the M key(or whatever) would return the user to the menu window and allow them to choose a different level.
So the questions are:
1. Do you think I would be better off using the Win32Window, or using second windows as in the User Interface tutorial?
2. Rather than putting this all into one huge *.cpp file, I'm inclined to say I ough to break it up (especially since I'd like to come back and add/change what some of the levels are)
So, if I use multiple file, how would you suggest I divide it up?
Each level would have the similar functionality (wasd, m to return to main menu, various other keys for similar events, starting/stopping animation and sound)
Would it make sense if in the main.cpp I defined everything in generic terms, and each level use the same names as eachother, so no matter which level is loaded it will react the same?
Or would each individual level file be the place to make the definitions (for events and such) and the main file just do the calling?

Does this make any bit of sense whatsoever?

?

[Midnight]

I struggle with this question myself.

Do I make sense? hehe

But seriously I don't know the proper way or the "best" way but Guice seems to run quiet efficiently and I'll be re releasing the source in the near future.

I run a winmain and stuff for Guice but the app itself calls void functions and such from a single file and the functions are broken into other files.

In the future I will try to convert as much of it to classes as possible they will operate a lot like Irrlicht itself by calling classes instead of void functions which should be used in the classes themselves.



class........void function..........variables
env....->....addbutton(.....rectangle ID parent color)

[SilentFuture]

If you design an aplication or a game you should take a pen and some paper or open a texteditor. Then write down how the app/game should work. Write down every step. and i mean realy every also if the step will be repeated.

Example in one window:
Starting App
show main menu
choose level
hiding menu
loading level
play/use
hit m for menu
show menu
choose level
hide menu
unload first level
load new level
and so on...

then think about how you could group them and how the functions should look. Which functions/classes you will need, which function are global and so on. You can see how you should build your app structure that you can use it and later add more functions and features.

In the example you can see, that you will need a main game function/class which holds the data which level is loaded and what is showed. Also you need a menu function/class and at least a level function/class. The game f/c will be the first which is initialiced and then showing the menu, the menu gives you choice back to the game f/c and then then hides it self or let the game f/c hide it. after this the game f/c tells the level f/c wich level to load or init the level f/c which is choosen if it is hardcoded.

There are many other steps, but this will give you a short overview how you could do it.

[area51]

I would use ?State Pattern? approach, each screen is a separate state, ie IntroScreen, MenuScreen, Level1 etc.

You will have a GameManager that stores a pointer to a ?State?. It will be the job of the ?State? itself to change this pointer and therefore change the screen.

To keep common functionality you can sub class the ?States?. Create a ?BaseState? then a ?PlayState? which inherits from ?BaseState?, then a ?Level1State? which inherits from the ?PlayState?. All generic level stuff goes in the ?PlayState?

Don?t use global variables/functions at all, but instead pass a pointer to the GameManager, which intern will have access to common areas of functionality, or other managers.

?State Pattern?, pretty much the de-facto framework for game design, your app will be no different in effect.
________
HEALTH INJURIES & PROBLEMS ADVICE

[luckymutt]

I had thought...tell me if this is dumb.
Instead of putting all the levels and gameplay into one *.exe, I was thinking that if I make each one as a separate app, then I'll make a simple windows gui app that does nothing but look pretty and has info, web links and buttons that simply call up the individual level.
In what I am doing, there is no information that needs to be shared or carried over from one level to the next, so this looks to me like a quick and easy way.

The windows "menu" app will just sleep in the background while an Irrlicht level is up and runnig, and when that is quit, you'll be back at the windows menu.

Besides being lazy, is there any reason this isn't a good approach in these circumstances?

[Fred]

Instead of putting all the levels and gameplay into one *.exe, I was thinking that if I make each one as a separate app, then I'll make a simple windows gui app that does nothing but look pretty and has info, web links and buttons that simply call up the individual level.
In what I am doing, there is no information that needs to be shared or carried over from one level to the next, so this looks to me like a quick and easy way.

I admit I didn't read the initial post, but this sounds horrible.

Create a generic "engine" executable, and drive it by plugins, scripts or data.