Hi I want to program my own game engine and I'm currently just starting out (after switching from c++ to java and from sdl to lwjgl). I'm planning out the design for my first iteration after which it should just be possible to have a window with some graphics in it. There I came upon 1 problem I wanted to ask what you think would be the better solution to it. Please take a look at the following diagram which is really all I have right now: http://www.starspring.de/serendipity/uploads/core.jpg And now the problem: I will have many classes that should be available to other classes often. So for example a game state needs to know the game state manager so that after the game state is finished he can advise the manager to switch to the next one and specify what the next game state is. So after for example the user clicked on start game in the menu game state the menu game state would say GameStateManager.changeToGameState("nextGameState"); Now my question of how to best achieve this. At the moment my approach is to make a main Game class which is a public singleton. Only the Game class has access to things like the GameStateManager. Altough GameStateManager has many public stuff it's in an internal package which is not to be used from anywhere outside this game engine layer. So a concrete game state could always say Game.getGameStateManager(); Are there problems with this when considering threads (I heard there are problems with static stuff)?

Oh I don't want to make an engine in the first place but of course games. I do not want to make only a game engine.

I will make a little iteration for the engine so I have some basic functionality and then I will start 2 games which will directly use the engine. Then, I will develop all 3 projects parallel.

So I will not develop an engine for 1 year and have nothing to show and without being stumbled over practical problems that will occur when using the engine for an actual game. You can see it as a part of the game I'm developing. Making or making not this seperation changes nothing in the end that there will be some functionality needed to manage game states.

Quote:
First notice:
Why should a GameState know that something like a GameStateManager even exists?
The Manager should query the State if it is finished.

This is really a good idea :-)

Quote:
Second notice:
Static stuff is usually meant as Singletons. Singletons really are bad, so one should avoid them at all cost.
(Explanations etc. are to be found in this subforum en masse, so I won't go into detail here)

I searched the board for singleton stuff. I really found much stuff that helped me a lot and I see now why it does not make sense for the Game class.