good stuff - Nuclex

Search

Advertising

Informations

Home

Forum

Welcome, Guest
Please Login or Register. Lost Password?

Nuclex

Forums

Feedback

good stuff

(1 viewing) (1) Guest

Have some feedback to share? Don't be shy and drop us a note.
Suggestions for new articles, comments about the website and other input are always welcome!

Page: 1

TOPIC: good stuff

Forum Tools

good stuff 2 Years, 2 Months ago	Karma: 0
The new site looks good! I didn't have a chance to read the response to my last post on the old forums, just wondering if you still had it. Thanks!

coycash

Fresh Boarder

Posts: 2

The administrator has disabled public write access.

Re:good stuff 2 Years, 2 Months ago

Karma: 0

Sure! Always backing everything up... just in case

Few questions here:

1. What is the best way use the GuiManager inside a GameState? Currently I create the GuiManager in the main Xna Game class, add it to Components, then request its service in the GameState.

2. Is there a way to access the Game class from a GameState? For example if my game is comprised of GameStates how would I go about exiting the Game itself (ie Game.Exit())?

3. How should/do I access services from a dialog window deriving from WindowControl? In other words how do you get any events in the WindowControl to affect anything outside the WindowControl?

Just wondering how you deal with these things or if you had any examples you could share, thanks!

Cygon

Code is Art

Admin

Posts: 1

Last Edit: 2009/12/03 07:54 By Cygon.

The administrator has disabled public write access.

Re:good stuff 2 Years, 2 Months ago

Karma: 0

Yes, that's how it's intended to be used. If you had a dialog that's displayed while the game is paused, for example, you could create a PauseGameState which adds the dialog to the GuiManager in its OnEntered() method and removes it again in its OnLeaving() method.

I'm trying to prevent references to the Game class because it can be troublesome when you use the components in WinForms (where you can't use the Game class).

In your example, I would probably create an IQuitService that was implemented by the Game class itself. That way, the Game class could call Game.Exit() when someone calls quitService.Quit(). And if the state was run in a WinForms environment, the dialog could implement the service and do a this.Close() or Application.Exit().

Now it gets complicated

I normally design my dialogs so they are only concerned about the GUI, but don't go shopping for references or access the object model of my game directly.

If you wanted to create a dialog in which the user could enter his name for a highscore table, for example, I would design the dialog with a method to obtain the entered name and create a game state that would keep active until the dialog is closed, after which it would read out the name from the dialog and do the processing the game needs to do to update the highscore table.

If a dialog is interactive (eg. triggers actions within being closed), you could publish events in the window-derived dialog class (so upon creating the dialog, the game state would register to those events). This makes the code a bit longer, but minimize coupling between game state and GUI, which is good for writing unit tests.

It's also possible to just make the window-derived class aware of its surroundings by handing it the required references in the constructor. Then a button handler could directly trigger a game action or ask the game state manager to switch to another state.