Sunandshadow I think you misunderstood some of what I was saying. For one thing I was not suggesting that GameState be a good class in any way, it is merely a data storage class where all of your common and persisted data is stored. By that I mean any data that is used two or more independent class as well as any data that you might want to maintain beyond the life of a single instance of that class. By putting it all in the GameState class and having other classes access that data on a as needed basis you can ensure that the data is correctly insynch and reduce the risk of memory leaks. It also allows you to make saving and loading easy since if you want to load a save game you simply dispose of the current GameState and replace it with a saved copy.

After looking at you new diagram I can see that you still have some organizational problems. I think you should decide how the data flow of your program is going to work and what you want it to be able to do, and do classes need to know to work. Try creating a hierarchy chart showing the programs flow from the user through the classes you might find it useful. You also still have loops which are a very bad thing; at no time in a program should you have cyclic dependencies.

You mention about how the program needs to know which class has control at one time. That is what the context handler class I mentioned before is for. ContextHandler is the name of the class I use to control all of the IO between the game and the user, which amounts to screens in terms of output and key presses for input. The ContextHandler essentially has an array of screens and maintains the knowledge of which screen the user is currently viewing, passes any input to that screen, and changes the screen when instructed to. There many fancy techniques you can use to tell it which when to changes screens and to what but the simplest and most effective is to have input method on the screen class return a value from an enum.

So basically what I’m saying is that your exploration mode, subgame modes, dialog, and menu, all inherit from the screen class. While they all do different things they have some basic method that they all have in common namely activate, show, and input, which is all the ContextHandler needs to know about them. The only exception to this is the movie player class which needs to know what movie to play.

I think if you look reevaluate your design a little you will realize there is less dependency between classes then you think. Other then that it looks like you are on the right track on terms of your classes, although I think you are missing a level class which should go between exploration and trigger object. The level class is where you hold on the data regarding a game level, including objects, triggers, layout, enemies and npcs. Also you might want consider making treasureObject a type of trigger since that is what it is. Meaning that player opens a box and finds a dime is essentially the same as stepping on the invisible square that causes 3000 zombies to attack.

As to your question as to whether or not a lead programmer could use that to develop a game I would have to say no. By looking at your chart I have a rough idea of how you want things to work but I would end up just using it as reference and then go and make my own with how I want the game to work. There are just too many parts that don’t make sense to me. For instance what is the difference between startup, new game, and new game+? You have them as 3 separate classes but I can’t see why. Would they not all be part of a StartMenu class?

In terms of what a lead programmer would need to program your game, there 3 documents you should provide considering the level of control you want to have.

- A requirements document - you probably already have this is some form or another. It is a short document which outlines in point form the features you want to include in the game and any nonfunctional requirements you have. Such is it must run on a PS2.
- A class diagram - you have one a present but it still needs work.
- A functional spec - this is the document in which you describe in detail what you want each class to do.

In the end though the alot of it comes down to how much control you want on the implementation of your project. If you are going to be the only perment memeber of the team then you will probably want to have a great deal of control over the implemenation simply because if you replace your lead programer you don't want the replacement to have to spend more time then nessary getting up to speed on where the project is at.