(Help) A Pause menu in Worlds?

[Cleberson]

Well, the years do not ask for more help to you is not it? xD.

In those days I have been looking for a way to make a pause menu, the Sonic Worlds fan for my game, but I've tried everything and could not (this includes the Sub-App, I can not move ..). I already know that the Sonic Worlds can not make a pause menu in the frame, but it does make one pause menu in a Sub App? and if, how I can put?, an example of how events in the engine would be nice =).

the version I'm using is: Sonic Worlds 0.5 (Spin Platform)

A tip: I would like to make a pause menu the same as the Sonic Fusion (one fan game that appeared in this year on SAGE) simply was what inspired me to take a pause menu with Retry, Resume, etc. .. in my game xD

[luksamuk]

I've already implemented this on the new Sonic Phoenix engine, and it's built off of Sonic Worlds. Well, it's a real pain in the ass. Mostly because I don't pause the game; all the events are inactivated and certain objects must have their animations stopped.

You may want to try this: Group all the frame events, except those related to the pause menu itself, in a group; while paused, all you have to do is deactivate the group and pause the animations of the objects.

And most important of all: DO NOT make MMF2 pause the application.

[Cleberson]

I've already implemented this on the new Sonic Phoenix engine, and it's built off of Sonic Worlds. Well, it's a real pain in the ass. Mostly because I don't pause the game; all the events are inactivated and certain objects must have their animations stopped.

You may want to try this: Group all the frame events, except those related to the pause menu itself, in a group; while paused, all you have to do is deactivate the group and pause the animations of the objects.

And most important of all: DO NOT make MMF2 pause the application.

very very logical XD, but, I not only know it professional...Mean I do not know 'off' everything to make this kind of pause this, so I want to do a more practical and easy as possible, without breaking the engine or etc.

[GSF]

The sub-app method has the following advantages:

1-Seamless. The main frame won't even "know" you've paused, as when you close the subapp, it will resume operating as if nothing happened. Kinda like when loading savestates in an emulator - seamless.

2-Customizability & functionality: In a subapp, you can make all sorts of things without breaking your main frame. Inventory menu, a minimap, whatever. If you want the main frame to "react" to certain things from the pause menu (or viceversa), simply set up a global value "PauseMenuReturnValue" or something like that, and set it to a certain number for X action. Then, in the main frame, evaluate whether said value is 1, 2, or whatever. This easily lets you implement "retry" and "quit" options.

3-Universality. Create just one frame to be used as the pause window, and add the relevant creation events in your level frames. Done

Disadvantages are as follows:

1-Subapps are an extension, not supported on every mmf export method. If you're exporting a regular windows EXE, it's not an issue.

2-Lack of transparency. Subapps create their own frame, so if you want a "transparent" menu, you'll have to take a shot of the current game and "paste" it as a BG.

Personally, I've used the subapp method for all my apps simply because of the versatility I get. (I can add a secondary minigame in the pause menu if I want!)

It can get a bit complex, though. Then again, I don't like the "event switch off" method because it's unwieldy, and can bring on several bugs or odd behavior, making me check and re-check all the time.

----------------------------------

So, in short: to make a subapp pause menu work...

1-Create subapp object in your level frame. Make sure it's "modal" (check properties).

2-Create the frame that will work as a pause frame. Go to frame editor, make new frame, you know the drill. If you don't want the menu to take the whole screen, drop down the size.

3-Make your subapp object grab that frame (Again, object properties.)

4-Make it not visible and not active at start of frame (once again, properties window)

5-Create event. When hitting "pause" button, go to the subapp object and select Visibility>Show, and make it restart the application (not your game application, the application inside the subapp, this is in the subapp object events).

6-Now your subapp takes control. Make sure you implement an exit option. To do so, create a "End application" event in the subapp frame (as before, this will not end your game, only the frame inside the subapp)

7-Game will resume operating as if nothing happened.

I can whip up a quick example if you wish. Just gimme some time and I'll post it tomorrow.

----------------------------------

EDIT: The "deactivate" method works as follows:

1-Group all your game events inside a major "master" event group

2-Add pause events outside said master group

3-Make pause event deactivate said master group (special object actions) AND stop all animations

4-Make unpause event reactivate the group.

[Cleberson]

The sub-app method has the following advantages:

1-Seamless. The main frame won't even "know" you've paused, as when you close the subapp, it will resume operating as if nothing happened. Kinda like when loading savestates in an emulator - seamless.

2-Customizability & functionality: In a subapp, you can make all sorts of things without breaking your main frame. Inventory menu, a minimap, whatever. If you want the main frame to "react" to certain things from the pause menu (or viceversa), simply set up a global value "PauseMenuReturnValue" or something like that, and set it to a certain number for X action. Then, in the main frame, evaluate whether said value is 1, 2, or whatever. This easily lets you implement "retry" and "quit" options.

3-Universality. Create just one frame to be used as the pause window, and add the relevant creation events in your level frames. Done

Disadvantages are as follows:

1-Subapps are an extension, not supported on every mmf export method. If you're exporting a regular windows EXE, it's not an issue.

2-Lack of transparency. Subapps create their own frame, so if you want a "transparent" menu, you'll have to take a shot of the current game and "paste" it as a BG.

Personally, I've used the subapp method for all my apps simply because of the versatility I get. (I can add a secondary minigame in the pause menu if I want!)

It can get a bit complex, though. Then again, I don't like the "event switch off" method because it's unwieldy, and can bring on several bugs or odd behavior, making me check and re-check all the time.

----------------------------------

So, in short: to make a subapp pause menu work...

1-Create subapp object in your level frame. Make sure it's "modal" (check properties).

2-Create the frame that will work as a pause frame. Go to frame editor, make new frame, you know the drill. If you don't want the menu to take the whole screen, drop down the size.

3-Make your subapp object grab that frame (Again, object properties.)

4-Make it not visible and not active at start of frame (once again, properties window)

5-Create event. When hitting "pause" button, go to the subapp object and select Visibility>Show, and make it restart the application (not your game application, the application inside the subapp, this is in the subapp object events).

6-Now your subapp takes control. Make sure you implement an exit option. To do so, create a "End application" event in the subapp frame (as before, this will not end your game, only the frame inside the subapp)

7-Game will resume operating as if nothing happened.

I can whip up a quick example if you wish. Just gimme some time and I'll post it tomorrow.

----------------------------------

EDIT: The "deactivate" method works as follows:

1-Group all your game events inside a major "master" event group

2-Add pause events outside said master group

3-Make pause event deactivate said master group (special object actions) AND stop all animations

4-Make unpause event reactivate the group.

Oh, thank you ^ ^, Well, I'll wait for your example and let's see the next step xD, I hope your answer =)

[GSF]

EDIT: Here you go.

Fire 1 is spacebar, Fire 2 is "P".

Sub-apps have a few quirks with the window depending on the properties you use. I put up info about the two workarounds in the event comments. Basically, you can either create and destroy the subapp object as needed (less hassle), or leave it hidden and add a window refocus event at the start of frame (hidden subapps with pop-up style steal focus, hence the issue.)

The current method in the example is the second, but you can easily change it by deactivating "Create at start" in the subapp properties, and adding "Create Object" and "Destroy Object" events as needed:

+Condition
---*Action

In this example, a return of value "1" means the player
chose "Resume Game" and "2" means "Quit Game".

+(player presses pause button)
---*Create "Sub-Application" at 200,120 (random position example)
---*Sub-App: Restart
---*Sub-App: Show

+Pause Return Global Value = 1
---*Set Pause Return Global Value to 0
---*Destroy Sub-App object

+Pause Return Global Value = 2
---*Set Pause Return Global Value to 0
---*Destroy Sub-App object
---*Jump to frame X

If your pause menu is particularly "heavy", this method should be more effective when it comes to performance.

This covers the basic pause method with a subapp, what you put in the pause frame itself is up to you.

If you need further assistance feel free to ask. :>

subapptut.mfa

[Cleberson]

EDIT: Here you go.

Fire 1 is spacebar, Fire 2 is "P".

Sub-apps have a few quirks with the window depending on the properties you use. I put up info about the two workarounds in the event comments. Basically, you can either create and destroy the subapp object as needed (less hassle), or leave it hidden and add a window refocus event at the start of frame (hidden subapps with pop-up style steal focus, hence the issue.)

The current method in the example is the second, but you can easily change it by deactivating "Create at start" in the subapp properties, and adding "Create Object" and "Destroy Object" events as needed:

+Condition
---*Action

In this example, a return of value "1" means the player
chose "Resume Game" and "2" means "Quit Game".

+(player presses pause button)
---*Create "Sub-Application" at 200,120 (random position example)
---*Sub-App: Restart
---*Sub-App: Show

+Pause Return Global Value = 1
---*Set Pause Return Global Value to 0
---*Destroy Sub-App object

+Pause Return Global Value = 2
---*Set Pause Return Global Value to 0
---*Destroy Sub-App object
---*Jump to frame X

If your pause menu is particularly "heavy", this method should be more effective when it comes to performance.

This covers the basic pause method with a subapp, what you put in the pause frame itself is up to you.

If you need further assistance feel free to ask. :>

Thx for the great help

EDIT: Well, I copied and pasted the events to do a test on the Sonic Worlds and when I got to the 'glue' I saw that everything was working perfectly, exert one thing: When the pause button precione sub app appears on the bottom and when it precione again she walks to right, and when precione for the third time it disappears from the screen, how can I fix it?

[GSF]

Oh, of course.

Following the frame might be a problem. See how regular objects such as Sonic or the monitors have "Follow the frame" checked in the properties?

Check out the HUD elements (TIME, SCORE, RINGS, etc) and notice how they don't have Follow the Frame enabled. When you do this, the object will stay in the screen, no matter how far you go. This is normal for HUD elements.

What you must do is uncheck "Follow the Frame" in the subapp object, and move said object close to the SCORE, TIME, RINGS HUD elements. MMF2 draws a little "outline" of the basic screen size in the frame editor's top left corner. Notice how all HUD elements are inside said "outline". This is your guide to define where the menu will show up.

EDIT:

You can see the outline there. When you use objects that don't follow the frame, their position is guided by this outline. For example, if you place your subapp in the yellow area, the pause menu will always show at the upper-right. If you put it in the red area, it will appear right on the center.

[Cleberson]

Oh, of course.

Following the frame might be a problem. See how regular objects such as Sonic or the monitors have "Follow the frame" checked in the properties?

Check out the HUD elements (TIME, SCORE, RINGS, etc) and notice how they don't have Follow the Frame enabled. When you do this, the object will stay in the screen, no matter how far you go. This is normal for HUD elements.

What you must do is uncheck "Follow the Frame" in the subapp object, and move said object close to the SCORE, TIME, RINGS HUD elements. MMF2 draws a little "outline" of the basic screen size in the frame editor's top left corner. Notice how all HUD elements are inside said "outline". This is your guide to define where the menu will show up.

EDIT:[qimg]http://i230.photobucket.com/albums/ee299/TGM_02/PR/General/mmf2_followframe.png[/qimg]

You can see the outline there. When you use objects that don't follow the frame, their position is guided by this outline. For example, if you place your subapp in the yellow area, the pause menu will always show at the upper-right. If you put it in the red area, it will appear right on the center.

The GSoft what i would be without you xD

Now we need one more thing, I was testing and in fact his plan worked, and when I pressed the button to select "resume" soon Sonic jumped and fell on thorns (he died xD) I was wondering how I can fix for when I select any option from the pause menu Sonic not jump right away

EDIT: Sorry not to have told you before, about this 'bug' I knew I was forgetting something

[GSF]

Oh, right. That's because MMF2 captures input way, way too fast.

Simply add a delay:

In your pause frame, make it so that after hitting the confirm button, it will set some value, and wait until a bit of time passes. Once this time is reached, the pause menu closes. You can use this delay to add some "exiting pause menu" animation or a little sound.

In fact, if you use a sound blip when pressing the confirm button, you can add a "When sound.ogg stops playing" condition, and THEN execute your action. That would save you from adding an "Every xx:xx" event. Just make sure the little sound has enough duration.

+Fire1 pressed
+(selected option is Resume)
---*Set PauseReturnValue to 1
---*Play sample "confirm.ogg"

+Fire1 pressed
+(selected option is Retry)
---*Set PauseReturnValue to 2
---*Play sample "confirm.ogg"

+Fire1 pressed
+(selected option is Quit)
---*Set PauseReturnValue to 3
---*Play sample "confirm.ogg"

+Sample "confirm.ogg" stops playing
---*End application

Then, back in your main frame, it will be motionless, since the player must've released the "confirm" button while the confirm.ogg sound was playing.

[Cleberson]

Oh, right. That's because MMF2 captures input way, way too fast.

Simply add a delay:

In your pause frame, make it so that after hitting the confirm button, it will set some value, and wait until a bit of time passes. Once this time is reached, the pause menu closes. You can use this delay to add some "exiting pause menu" animation or a little sound.

In fact, if you use a sound blip when pressing the confirm button, you can add a "When sound.ogg stops playing" condition, and THEN execute your action. That would save you from adding an "Every xx:xx" event. Just make sure the little sound has enough duration.

+Fire1 pressed
+(selected option is Resume)
---*Set PauseReturnValue to 1
---*Play sample "confirm.ogg"

+Fire1 pressed
+(selected option is Retry)
---*Set PauseReturnValue to 2
---*Play sample "confirm.ogg"

+Fire1 pressed
+(selected option is Quit)
---*Set PauseReturnValue to 3
---*Play sample "confirm.ogg"

+Sample "confirm.ogg" stops playing
---*End application

Then, back in your main frame, it will be motionless, since the player must've released the "confirm" button while the confirm.ogg sound was playing.

Sorry to ask again (I'm embarrassed until xD), you could do it at the MFA that you gave me?, I'm trying to edit difficulties here (Yes I'm a noob with N caps)

[GSF]

Sure thing, but gimme some time, and I'll edit this post when it's done. :]

[Cleberson]

Sure thing, but gimme some time, and I'll edit this post when it's done. :]

Oh thx ^^ you is patience personified, really thank you gsoft!

[Felik]

Wow great example gsoft! Rep up! I didn't know that you can actually make different frame of the same application work properly. But there is still one issue. If you resize application's screen the sub-app will keep the same screen size and it's position will remain the same. Do you know how to fix that?

[GSF]

Oh, first of all: Sorry for taking so much time, cleberson. I kinda screwed my virtual machine where MMF2 was. I need to get my updates and extensions back. I'll get back to it and post soon.

@Felik: You'll have to dynamically reposition the subapp. This is pretty simple. Insert a Window Control object (which lets you retrieve sizes and positions), and add repositioning events in your "on pause" event:

With the "dynamically destroy and recreate subapp object" method:

+Upon pressing "P"
---*Create "Sub-App" at <main window X Size /2>-<subapp frame Y size /2>,
<main window Y Size /2>-<subapp frame Y Size /2>
---*Subapp: Restart
---*Subapp: Show

With the "hide and show" method, simply replace the create event with a Set Position event.

Size explanation: To place a window centered on your main display:

MainWindow X Size / 2 - SubWindow X Size / 2

MainWindow Y Size / 2 - Sub Window Y Size / 2

We basically grab the main window size, cut it in half, and subtract half of the sub window size. This will result in a centered window.

e.g. 800x600 main window / 320x240 sub window:

XPos: (800/2)-(320/2) = 240

YPos: (600/2)-(240/2) = 180

This way, the window will start at 240,180, where its 320x240 will "expand", making the opposite corner 560,420. If you calculate the remaining space, it'll be the same in all sides, effectively centering the window.

Use the window control object to retrieve sizes.

As for resizing, you could calculate the proportion between the original and current window size, and multiply XSize and YSize of the subapp by said proportion. However, I don't know if the subapp will "expand" itself, instead of leaving just a white border.

[Felik]

Oh, first of all: Sorry for taking so much time, cleberson. I kinda screwed my virtual machine where MMF2 was. I need to get my updates and extensions back. I'll get back to it and post soon.

@Felik: You'll have to dynamically reposition the subapp. This is pretty simple. Insert a Window Control object (which lets you retrieve sizes and positions), and add repositioning events in your "on pause" event:

With the "dynamically destroy and recreate subapp object" method:

+Upon pressing "P"
---*Create "Sub-App" at <main window X Size /2>-<subapp frame Y size /2>,
<main window Y Size /2>-<subapp frame Y Size /2>
---*Subapp: Restart
---*Subapp: Show

With the "hide and show" method, simply replace the create event with a Set Position event.

Size explanation: To place a window centered on your main display:

MainWindow X Size / 2 - SubWindow X Size / 2

MainWindow Y Size / 2 - Sub Window Y Size / 2

We basically grab the main window size, cut it in half, and subtract half of the sub window size. This will result in a centered window.

e.g. 800x600 main window / 320x240 sub window:

XPos: (800/2)-(320/2) = 240

YPos: (600/2)-(240/2) = 180

This way, the window will start at 240,180, where its 320x240 will "expand", making the opposite corner 560,420. If you calculate the remaining space, it'll be the same in all sides, effectively centering the window.

Use the window control object to retrieve sizes.

As for resizing, you could calculate the proportion between the original and current window size, and multiply XSize and YSize of the subapp by said proportion. However, I don't know if the subapp will "expand" itself, instead of leaving just a white border.

I tried to resize the sub-app and unfortunately you can't do that during runtime.

And also it's position is varied somehow depending on what resolution was at the start of the frame. But I guess I can fix that by simply not allowing the player to change res mode during stages.

[Cleberson]

Oh, first of all: Sorry for taking so much time, cleberson. I kinda screwed my virtual machine where MMF2 was. I need to get my updates and extensions back. I'll get back to it and post soon.

@Felik: You'll have to dynamically reposition the subapp. This is pretty simple. Insert a Window Control object (which lets you retrieve sizes and positions), and add repositioning events in your "on pause" event:

With the "dynamically destroy and recreate subapp object" method:

+Upon pressing "P"
---*Create "Sub-App" at <main window X Size /2>-<subapp frame Y size /2>,
<main window Y Size /2>-<subapp frame Y Size /2>
---*Subapp: Restart
---*Subapp: Show

With the "hide and show" method, simply replace the create event with a Set Position event.

Size explanation: To place a window centered on your main display:

MainWindow X Size / 2 - SubWindow X Size / 2

MainWindow Y Size / 2 - Sub Window Y Size / 2

We basically grab the main window size, cut it in half, and subtract half of the sub window size. This will result in a centered window.

e.g. 800x600 main window / 320x240 sub window:

XPos: (800/2)-(320/2) = 240

YPos: (600/2)-(240/2) = 180

This way, the window will start at 240,180, where its 320x240 will "expand", making the opposite corner 560,420. If you calculate the remaining space, it'll be the same in all sides, effectively centering the window.

Use the window control object to retrieve sizes.

As for resizing, you could calculate the proportion between the original and current window size, and multiply XSize and YSize of the subapp by said proportion. However, I don't know if the subapp will "expand" itself, instead of leaving just a white border.

Well, when you put it back and you can put it with this solution appear in the center of the screen (even when in fullscreen or widescrenn), and also with that method of sound that you had explained to me before leaving their Felik opinions ^ ^

[luksamuk]

Thank you, gsoft. I will also be adding this to Level Collab. Never thought it could be so simple.

+rep

[GSF]

@cleberson: Sure, I'll add it. My idea is to add a little Sonic sprite that will dash off (with sound) when you unpause, creating the delay we need.

We'll see how it turns out.

@Felik: Yeah, I was expecting that it wouldn't resize. The repositioning method might need a few tweaks, since the window control object considers window borders: If you're on fullscreen, it might behave differently.

But yeah, make an options menu or something. And store the display size in two separate global values, which you'll use when repositioning. Even better, you can directly implement the calculations in the options menu, storing what would be the position of the subapp itself in these global values (e.g. 240x180)

@LH: Awesome. :]

EDIT: Gaaaaah, positioning is hell. When you reposition the subapp, the previous method would actually leave it waaaaaay out of the main window, as the "Set coordinate" actions are in relation to the whole desktop, not just the app window. Therefore, half of the screen size needs to be taken into account as well.

I'll give it another go. I'm close...

EDIT: Updated attachment.

subapptut.mfa