How I might do it… and I guess if your using nifty then you might have an app state per screen which is useful there but still kind of unfortunate.
MainMenuState - the main landing point. Your SimpleApplication would setup basic service app states and the MainMenuState. For example, my DragonflyOdyssey’s app constructor looks like this:
[java]
public Main() {
super(new StatsAppState(), new DebugKeysAppState(), new BasicProfilerState(false),
new AnimationState(),
new SoundManager(),
new MainMenuState(),
new LightingState(0.35f),
new SkyState(),
new SkySettingsState(),
new MusicState(),
new PostProcessingState(),
new CreditsState(),
new ScreenshotAppState("", System.currentTimeMillis()));
}
[/java]
MainMenuState manages the main menu and potentially any subscreens… if you have an app state per screen then you could attach them in main, too. Really, though, I prefer to keep as few states here as makes sense. Since options are reusable (like for the in-game menu) then I might leave options as a separate state that MainMenuState attaches. These would always be attached and simply enabled/disabled as needed. (BaseAppState for the win)
In your case, probably a lobby state also. I don’t see any reason to have multiple lobby states. To me they shouldn’t be any different functionality-wise.
The player may use mode-specific UIs to configure the settings for the ultimate game they will run. This is not really an app state thing, though. You have a UI you pop up to get info that is mode-specific but it doesn’t need to be a state on its own. (If you are using nifty maybe you will have screen controller states but I consider that an artifact of nifty and not a ‘design’, really… so you may have a state per screen but lets not count those as real app states for this discussion. They are idiomatic byproducts of the boiler plate that makes nifty easier to deal with and are basically unnecessary in other libraries. Not knocking nifty but let’s not consider these in the same vein as the other app states which implement your app functionality.)
Once the player has configured the game they want to play through the game-mode specific UI, then that information is used to launch the game mode specific app state. SingleRaceState, CampaignState, whatever. They will manage all of that. At worst, they will be attaching some app states (probably shared by both) and monitoring the state of the game.
@loopies said:
I used an ES at start but never understood why people were adamant only one component of one type (per entity) was ever needed and so went with the idea that I was not doing it right and therefore was going for the wall and ended ripping it out. I have no idea how to deal with 2 missiles hitting a car for example.
I’d have to know more about your example but in general if you need multiple things attached to an entity… then they aren’t components, they are entities. “But I want to have a bunch of gun turret components!!!” No, you want to have a bunch of gun turret entities. “But I want to attach a bunch of damage components.” No, you want to attach a bunch of damage entities… and those entities might have half a dozen components describing the type of damage. (Is it fire damage, electric damage, ongoing damage, does it have a debug name, does it have a creator component tying back to who dealt the damage, and so on.)
In all cases I’ve ever come across where “I want to have multiple components” comes up, the design opens up tremendously by doing it a different way. Components are attributes. So it’s very strange to have two of a kind.