Let's say you have a game that consists of a: splash, menu, gameplay and gameover-screen. I guess these are the most common "game screens" and somehow we all need to visually switch between these.
As I see it there are two ways of doing this:
100% in code. You simply add/remove UserControls from your main LayoutRoot dynamically
Good about this approach
You have 100% control over what's going on at any time.
Bad about this approach
If you have a designer working in Blend, or you work in Blend yourself, you don't get a very good picture of the game. You can't see in Blend, visually, what shown in the different "game states".
You can easially get a lot of "spaghetti code" that can be pretty complex, just for the purpose of switching between screens.
Using VisualStates in Blend
Good about this approach
I guess this must be the "right" way, as you use the tools fully.
You can easially make VisualStates within Blend and apply transitions between screens
Bad about this approach
You can't do "all" by doing it this way, sometimes VisualStates just isn't enough, or at least I have run into problems sometimes, maybe it's just me not good enough in Blend :)
So, I just want to hear how you guys are overcoming this very common scenario?
:)
--------------------------
Please mark the post as answered if this answers your question
http://www.laumania.net
In Squarepeg, I manage the switching between game screens 100% in code. I have various different Silverlight User Controls, representing for example:
- Layout Root / Main Menu
- Game 'container'
- Gameboard itself.
Each UserControl is instantiated and added as a child to the layout root. It raises its own events to indicate when it has closed, or in some cases when something has changed that means the parent display needs updating. (for example, the gameboard only
partially obscures the game container. The game container displays the score, current level, etc. so it needs to be told when these have changed)
I have static 'appSettings' and Functions classes too; these are most useful for the sharing of information and code between the various UserControls. (e.g. sound effects volume, common functions to show/hide xaml, username storage, etc.) This avoids lots
of messy 'chaining' of events and variables along the various parent-child relationships.
I also have a UserControl for display of modal-style dialog boxes, questionboxes and 'please-wait'-style notifications. The modal effect is achieved by using a partially transparent box that completely covers the window.
Hope this answers your question,
Carlos
====================================================
carlosp_uk
Windows Mobile and Silverlight Application Developer
www.fatattitude.com
I see, that IS pretty simple, but seems effective. One could extent this so IScreen could have some kind of "Intro" and "Outtro", for instance if you wanted it to fade in/out or what not.
Thanks again.
--------------------------
Please mark the post as answered if this answers your question
http://www.laumania.net
I just want to +1 on using code to switch between screens instead of using VisualStates. In the original Vector Space, I had all the controls on the Page at once, which got messy. For TowerOfBabble and Vector Space Armada, I did what others described,
where every "screen" is just a user control, and I have a method in a control class that handles all the screen setup and take down. It is much easier to maintain that way.
In tower of Babble I have a FadeIn and FadeOut animation on a storyboard on my Page, and oldScreen and newScreen instance variables. I set the targets on FadeOut to oldScreen and on FadeIn to newScreen. On FadeOutCompleted oldScreen is removed and set
to null and the targets are cleared on FadeOut. No interfaces were needed.
I just want to +1 on using code to switch between screens instead of using VisualStates. In the original Vector Space, I had all the controls on the Page at once, which got messy. For TowerOfBabble and Vector Space Armada, I did what others described,
where every "screen" is just a user control, and I have a method in a control class that handles all the screen setup and take down. It is much easier to maintain that way.
In tower of Babble I have a FadeIn and FadeOut animation on a storyboard on my Page, and oldScreen and newScreen instance variables. I set the targets on FadeOut to oldScreen and on FadeIn to newScreen. On FadeOutCompleted oldScreen is removed and set
to null and the targets are cleared on FadeOut. No interfaces were needed.
That's exactly my experience too. In Bubbles and Balloon Mayhem I have each "screen" as a UserControl, but all the UserControls are on the Page.xaml. I switch between them with VisualStates. I can see now that that, very quick, becomes way to complex control
and develop on in some scenarioes, thats why I created this thread. Thanks for you input guys, seems like the "best" way is to handle switching of screens in code. This rise another question, when do you guys then use VisualStates? Or do you just discard them
totally? :)
--------------------------
Please mark the post as answered if this answers your question
http://www.laumania.net
I too have each screen as a UserControl that's created and scoped in the custom Application class. My Application class has a method called ChangePage that takes an enumerated type that contains the various pages available. This makes the code a little
cleaner.
I think that a benefit of using different UserControls is that it would be easier to reuse one of the pages, for example a chat lobby page, in another application.
This rise another question, when do you guys then use VisualStates? Or do you just discard them totally? :)
I don't. Since I'm not developing any controls I expect to distribute, or even use as templatable controls within the app, then I don't see the advantage over just plain old Storyboard's.
Qbus
Member
611 Points
271 Posts
Best way to visually switch between game screens?
Jun 04, 2009 08:01 AM | LINK
Let's say you have a game that consists of a: splash, menu, gameplay and gameover-screen. I guess these are the most common "game screens" and somehow we all need to visually switch between these.
As I see it there are two ways of doing this:
So, I just want to hear how you guys are overcoming this very common scenario?
:)
Please mark the post as answered if this answers your question
http://www.laumania.net
carlosp_uk
Member
42 Points
20 Posts
Re: Best way to visually switch between game screens?
Jun 04, 2009 09:42 AM | LINK
Hi Qbus
In Squarepeg, I manage the switching between game screens 100% in code. I have various different Silverlight User Controls, representing for example:
- Layout Root / Main Menu
- Game 'container'
- Gameboard itself.
Each UserControl is instantiated and added as a child to the layout root. It raises its own events to indicate when it has closed, or in some cases when something has changed that means the parent display needs updating. (for example, the gameboard only partially obscures the game container. The game container displays the score, current level, etc. so it needs to be told when these have changed)
I have static 'appSettings' and Functions classes too; these are most useful for the sharing of information and code between the various UserControls. (e.g. sound effects volume, common functions to show/hide xaml, username storage, etc.) This avoids lots of messy 'chaining' of events and variables along the various parent-child relationships.
I also have a UserControl for display of modal-style dialog boxes, questionboxes and 'please-wait'-style notifications. The modal effect is achieved by using a partially transparent box that completely covers the window.
Hope this answers your question,
Carlos
carlosp_uk
Windows Mobile and Silverlight Application Developer
www.fatattitude.com
lionsguard
Member
170 Points
37 Posts
Re: Best way to visually switch between game screens?
Jun 04, 2009 02:00 PM | LINK
I do the same thing in Perenthia, each user control represents the screen view or state. I have a static manager class to aid in switching states.
Cameron Albert
Lionsguard Technologies, LLC
Perenthia
Qbus
Member
611 Points
271 Posts
Re: Re: Best way to visually switch between game screens?
Jun 04, 2009 07:40 PM | LINK
Ok great to hear, so doing this in code seems to be the most used way of doing this.
@lionsguard: "I have a static manager class to aid in switching states." Do you mind sharing some of this code here? Or just give an example?
Please mark the post as answered if this answers your question
http://www.laumania.net
lionsguard
Member
170 Points
37 Posts
Re: Re: Best way to visually switch between game screens?
Jun 06, 2009 02:48 AM | LINK
Yeah, sounds more complex to describe it that actually use it :)
I have two these two interfaces defined:
public interface IScreen { UIElement Element { get; } } public interface IScreenHost { void SetScreen(IScreen screen); }Then, the UserConrols that are to be screens just implement the IScreen interface and return themselves as the UIElement:public partial class PlayScreen : UserControl, IScreen { public UIElement Element { get { return this; } } }The IScreenHost is the container canvas for the screen (This control is placed on the Page surface):
public partial class Host : UserControl, IScreenHost { public void SetScreen(IScreen screen) { this.LayoutRoot.Children.Clear(); this.LayoutRoot.Children.Add(screen.Element); } }And I use this class to handle switching of the screens.
public static class ScreenManager { private static IScreenHost _host; public static void SetHost(IScreenHost host) { _host = host; } public static void SetScreen(IScreen screen) { _host.SetScreen(screen); } }In my Page.xaml.cs class, in the Loaded event handler I make this call to set up the host:
When I want to change screens or set a new screen as the default I just make this call:
Cameron Albert
Lionsguard Technologies, LLC
Perenthia
Qbus
Member
611 Points
271 Posts
Re: Re: Re: Best way to visually switch between game screens?
Jun 07, 2009 04:41 PM | LINK
Thanks for sharing :)
I see, that IS pretty simple, but seems effective. One could extent this so IScreen could have some kind of "Intro" and "Outtro", for instance if you wanted it to fade in/out or what not.
Thanks again.
Please mark the post as answered if this answers your question
http://www.laumania.net
DDtMM
Member
90 Points
103 Posts
Re: Best way to visually switch between game screens?
Jul 02, 2009 09:34 AM | LINK
I just want to +1 on using code to switch between screens instead of using VisualStates. In the original Vector Space, I had all the controls on the Page at once, which got messy. For TowerOfBabble and Vector Space Armada, I did what others described, where every "screen" is just a user control, and I have a method in a control class that handles all the screen setup and take down. It is much easier to maintain that way.
In tower of Babble I have a FadeIn and FadeOut animation on a storyboard on my Page, and oldScreen and newScreen instance variables. I set the targets on FadeOut to oldScreen and on FadeIn to newScreen. On FadeOutCompleted oldScreen is removed and set to null and the targets are cleared on FadeOut. No interfaces were needed.
Qbus
Member
611 Points
271 Posts
Re: Best way to visually switch between game screens?
Jul 02, 2009 12:56 PM | LINK
Please mark the post as answered if this answers your question
http://www.laumania.net
GlitchSCG
Member
111 Points
37 Posts
Re: Best way to visually switch between game screens?
Jul 02, 2009 01:02 PM | LINK
I too have each screen as a UserControl that's created and scoped in the custom Application class. My Application class has a method called ChangePage that takes an enumerated type that contains the various pages available. This makes the code a little cleaner.
I think that a benefit of using different UserControls is that it would be easier to reuse one of the pages, for example a chat lobby page, in another application.
DDtMM
Member
90 Points
103 Posts
Re: Best way to visually switch between game screens?
Jul 02, 2009 01:53 PM | LINK
I don't. Since I'm not developing any controls I expect to distribute, or even use as templatable controls within the app, then I don't see the advantage over just plain old Storyboard's.