I think it is fair to say this discussion is starting to heat up. I think we should all just chill a bit. We've each had our fair say on what we want, no need to draw this argument any further. Jack are you cool with agreeing to disagree?
Aggro Tactics - A tactical strategy virtual board game built with Unity3D 4.0, designed around the concept of Threat/Aggro inspired by the mechanics of chess and a customizable party like in table top games.
To the person saying hitting the system button while a game is loading is not a good idea.
The game activity will not be the focus and will become paused. Which will mean all loading will stop. Not only that but in the worst case the application will be terminated. Sure you can save what map you were loading for when you resume, but then you have to start reloading everything again.
While transparent activities do exist. I am not sure if the background activity continues to run. Or if it is simply the last snapshot of the screen. So it will not update. Which is still a problem with networked games. There is a android java solution which is creating a background service running all networking and game code. Then just have an activity that queries and and renders as well as sending input to the background service.
Not very good for those of us who want to use the ndk and use the native-activity activity.
I think it is fair to say this discussion is starting to heat up. I think we should all just chill a bit. We've each had our fair say on what we want, no need to draw this argument any further. Jack are you cool with agreeing to disagree?
Let's sum up my argument into this:
Lack of buttons is a poor argument. We could add 6 more buttons and there would still be games using up all of them and developers complaining there aren't enough. PC games suffer badly from this - while things like moving and jumping are fairly standard, developers rarely agree on specific functions like crouching and opening a parachute, and those tend to get scattered all over the keyboard. Less buttons motivates developers to simplify controls and unisg creative ways of condensing controls rather that scattering them.
Games that use start button for gameplay-critical functionality are the exception, not the rule. Numerous games similar to those often use other buttons for gameplay-related functions, so it's hardly natural at all to try pausing the game to reach those.
Guidelines are guidelines, nobody will prevent you from using L1 for the menu if you so desire. Though I personally think the recommended menu button should be Y, not U.
My thinking about the solutions is:
Giving an API to customize the menu - best, as it keeps the functionality and feel constant across all games, and a styling API would be enough to eliminating having an "alien" menu and would allow to display information while the player is in the menu. The developers that would use extra functionality will likely find other intuitive ways to do so. Aditionally, this implementation allows the player to choose what he wants to quickly view - a player might prefer to take a quick look at his messages rather than his frag count.
Not opening the menu if the event is consumed - best-of-both-worlds solution, as long as a way to force the menu to open is provided. The biggest problem is that it gives no constant behavior, and some players might be confused that a different menu than the usual opens when playing an specific game.
Double tap/hold to enter the dash menu - keeps things constant, but kills all the benefits of the proposed dash API. All developers will now have to code the menu themselves, there will be no instant access to the dashboard's information and no simplified, standard menus. Also, there's the problem that people don't like to read manuals, and those people will take quite a while to figure it out.
Adding a start button - I've said it before: having two pause buttons is dumb. Also, it would need major changes to the controller before release, which could delay the launch, and the developers will have no way of testing it before buying the final controller.
Have the game call the dash menu - even worse! That means extra certification steps because the OUYA team will need to be sure the menu is properly accessible.
greeniekin said: The
game activity will not be the focus and will become paused. Which will
mean all loading will stop. Not only that but in the worst case the
application will be terminated. Sure you can save what map you were
loading for when you resume, but then you have to start reloading
everything again.
That sounds like a testament of bad programming. Assuming they're going for the behavior of PS3/X360, the dash menu is accessible regardless of what's happening in the game. If your game crashes because you did not account for someone opening the menu while it loads, it's your fault.
That sounds like a testament of bad programming. Assuming they're going for the behavior of PS3/X360, the dash menu is accessible regardless of what's happening in the game. If your game crashes because you did not account for someone opening the menu while it loads, it's your fault.
Actually not true. The PS dash menu is not accessible on the startup of the game (and maybe at more places ingame). Also some other Sony developed applications on PS temporarily block the ability to call the dashboard.
I don't know how this is managed internally (probably the dash itself refusing a call because of 'reasons'), but it happens (a red logo is displayed in the top right corner when this happens).
That sounds like a testament of bad programming. Assuming they're going for the behavior of PS3/X360, the dash menu is accessible regardless of what's happening in the game. If your game crashes because you did not account for someone opening the menu while it loads, it's your fault.
The problem is inherent in the Android OS from what I can gather. But hopefully they can find a way to NOT pause the game while the system menu is open, especially since in a multiplayer game that almost surely means you will get booted from the server (the server thinks you've disconnected).
You didn't remember the plot of the Doctor Who movie because there was none; Just a bunch of plot holes strung together.
I just had an idea - what if the dash menu uses a port of CEGUI? It's mit-licensed and highly flexible, way beyond sliders and checkboxes. An API based on it could easily satisfy even some of the most feature-demanding developers. Here, have a demo:
As much as I'm a fan of having some sort of pause-button functionality, I would much rather use another button than have to go through the trouble of plugging options into the system menu, handling contextual bits, skinning, etc.
I think it is fair to say this discussion is starting to heat up. I think we should all just chill a bit. We've each had our fair say on what we want, no need to draw this argument any further. Jack are you cool with agreeing to disagree?
Yeah.. aside from this particular comment.. I've given up on this discussion.
This is a 3% problem that seems to be getting 80% of the attention and seems like a really minor thing to get worked up about given all the other stuff left to do. :) Standardizing pause seems like something the developers should figure out on their own within whatever constraints the environment puts in place.
OUYA needs a way of bringing up the menu independent of the app running. I think tapping the system button is fine for that. Just let us know it's been tapped and give the game an opportunity to respond to it in some way.
The odds of someone's game failing or getting bad reviews over a weird pause implementation is going to be virtually non-existent. In a review, it will be a "..and another thing that sucks about this game is the pause handling"... not a "this game sucks because of the way they handle pause".
I think it's perfectly acceptable to have the system menu come up on a single tap of the system button, and send the system button event to the app as well. If the developer decides to piggyback pause at that point, that's up to them. In fact, while playing the XBox over the weekend, I noticed that's what a fair number of games do.
If the system button is being used as a means of pause + managing other parts of the game, then that's a design decision the developer has made knowing very well what the consequences of doing that are (the system menu appearing). And at that point, if they are bothered by that, they should consider moving that functionality somewhere else. But in the end, that is truly up to the developer.
After some thought, I've personally come full circle to an original suggestion of tapping the touch pad for pausing, and that's probably how I'll address it in my own games. From a usability standpoint (vs. a traditional standpoint), tapping the touch pad to bring up a pause menu makes a lot of sense. It brings context to a "mouse driven" environment, which is ideal for navigating clickable menus anyway.
And if the touchpad is an integral part of the game experience, there will probably be a button on the screen anyway to navigate to a "pause" menu, or a piggy-backed system button experience will probably be very acceptable (or any other button for that matter).
Hopefully the folks behind the scenes at OUYA have come to a conclusion and aren't suffering from analysis paralysis. They just need to keep in mind a quote from Bill Cosby and just do SOMETHING.
Anyway.. that's my final words on the subject. Good luck, OUYA, we'll deal with whatever you come up with. You won't make everyone happy, but you can't make an omelet without breaking a couple eggs along the way.
This issue was one of the ones we discussed as a team today. We came to the following decision: A tap of the OUYA button is pause, and a short hold of the button will open the system menu.
In a bit more detail, a tap of the button will broadcast an Intent that the game can intercept like a menu button press. We decided against just sending a menu button event as a keydown would be sent even if the intention was to keep holding it to access the system menu. Holding the button for a moment will open the system menu, and the other "hold for __" functions will stay the same for now.
This issue was one of the ones we discussed as a team today. We came to the following decision: A tap of the OUYA button is pause, and a short hold of the button will open the system menu.
In a bit more detail, a tap of the button will broadcast an Intent that the game can intercept like a menu button press. We decided against just sending a menu button event as a keydown would be sent even if the intention was to keep holding it to access the system menu. Holding the button for a moment will open the system menu, and the other "hold for __" functions will stay the same for now.
I love you guys... ;) thank you for this.
Aggro Tactics - A tactical strategy virtual board game built with Unity3D 4.0, designed around the concept of Threat/Aggro inspired by the mechanics of chess and a customizable party like in table top games.
This issue was one of the ones we discussed as a team today. We came to the following decision: A tap of the OUYA button is pause, and a short hold of the button will open the system menu.
In a bit more detail, a tap of the button will broadcast an Intent that the game can intercept like a menu button press. We decided against just sending a menu button event as a keydown would be sent even if the intention was to keep holding it to access the system menu. Holding the button for a moment will open the system menu, and the other "hold for __" functions will stay the same for now.
Yes! Thank you! Having a dedicated pause/menu button is a very important thing for the OUYA.
You didn't remember the plot of the Doctor Who movie because there was none; Just a bunch of plot holes strung together.
This issue was one of the ones we discussed as a team today. We came to the following decision: A tap of the OUYA button is pause, and a short hold of the button will open the system menu.
In a bit more detail, a tap of the button will broadcast an Intent that the game can intercept like a menu button press. We decided against just sending a menu button event as a keydown would be sent even if the intention was to keep holding it to access the system menu. Holding the button for a moment will open the system menu, and the other "hold for __" functions will stay the same for now.
Ok.. I lied.. one more reaction.. :)
So to clarify, do you intend to suspend the process when the system menu pops up?
If not, hopefully you also broadcast when the system menu is about to open as well so the app can react and possibly go into a pause state from that action too (which as I said in my previous post.. is how I noticed many games on the XBox handle it)
This issue was one of the ones we discussed as a team today. We came to the following decision: A tap of the OUYA button is pause, and a short hold of the button will open the system menu.
In a bit more detail, a tap of the button will broadcast an Intent that the game can intercept like a menu button press. We decided against just sending a menu button event as a keydown would be sent even if the intention was to keep holding it to access the system menu. Holding the button for a moment will open the system menu, and the other "hold for __" functions will stay the same for now.
That is great news! Thank you very much as I was starting to worry! :P
@nick Thanks for communicating that to us, it's a huge relief knowing that a solid solution has been decided on. Any idea when this will be implemented for those of us that have an OUYA already? Also, any hint at when the next software upgrade will be?
In a bit more detail, a tap of the button will broadcast an Intent that the game can intercept like a menu button press. We decided against just sending a menu button event as a keydown would be sent even if the intention was to keep holding it to access the system menu. Holding the button for a moment will open the system menu, and the other "hold for __" functions will stay the same for now.
I was initially in favor of re-purposing the Android menu key for this function, but I realize now why you wouldn't want to send a "key down" event when the system button is first pressed, just a "key up" when it it released (or as you say, a "tap"), which will prevent devs from accidentally implementing an unintended function if the user is holding down the button expecting the system menu. This also prevents devs from short-circuiting the user's path to the system menu when an app is misbehaving.
So, we will still be able to tell when a player is using the system menu, correct? I'm new to Android development, is there a way of telling when your app loses focus?
Fantastic! Very simple and straightforward solution which I think the user will understand quite easily.
I'm also wondering about suspending the game when the menu is up, or being able to pause the game when the menu is up.
And as I wrote in an earlier post I think you could make it optional for the developer to make the game suspendable depending on whether you're playing over a network or not. But letting the developer pause the game when the menu is up works too, and as mentioned above that's how it seems to work on the Xbox 360.
We also made the decision that we aren't planning on modifying the Activity lifecycle. If we can find a way to have our menu not onPause the game, that's great, we'll implement it. If not, its up to the developer to correctly handle the Activity's pause.
Please leave pausing\un-pausing our apps to us. Just send the KeyUp event and also notify us when the system menu launches and hides and we will handle the rest. I imagine there will be some kind of certification process\TRCs to go through before release so this can be one of the things we will have to implement correctly, not a big deal!
Please leave pausing\un-pausing our apps to us. Just send the KeyUp event and also notify us when the system menu launches and hides and we will handle the rest. I imagine there will be some kind of certification process\TRCs to go through before release so this can be one of the things we will have to implement correctly, not a big deal!
It's not that simple. When the system menu is shown, it is the standard Activity lifecycle in Android that will be pausing our app. As nick said, if they can find a way to not pause our app without modifying the Activity lifecycle, then they will do it. If they cannot, then we'll have to deal with it.
Please leave pausing\un-pausing our apps to us. Just send the KeyUp event and also notify us when the system menu launches and hides and we will handle the rest. I imagine there will be some kind of certification process\TRCs to go through before release so this can be one of the things we will have to implement correctly, not a big deal!
Note that @nick is talking about "pause" in terms of the Android lifecycle. When the system menu is visible, you'll get an onPause event, when the user returns, onResume, or if they exit, onStop likely followed by onDestroy.
You aren't forced to pause your game, but is it recommended that you reduce the CPU load (animations, etc.) so you don't interfere with the dialog.
This issue was one of the ones we discussed as a team today. We came to the following decision: A tap of the OUYA button is pause, and a short hold of the button will open the system menu.
In a bit more detail, a tap of the button will broadcast an Intent that the game can intercept like a menu button press. We decided against just sending a menu button event as a keydown would be sent even if the intention was to keep holding it to access the system menu. Holding the button for a moment will open the system menu, and the other "hold for __" functions will stay the same for now.
Comments
Founder of ReachingPerfection.com
The game activity will not be the focus and will become paused. Which will mean all loading will stop. Not only that but in the worst case the application will be terminated. Sure you can save what map you were loading for when you resume, but then you have to start reloading everything again.
While transparent activities do exist. I am not sure if the background activity continues to run. Or if it is simply the last snapshot of the screen. So it will not update. Which is still a problem with networked games. There is a android java solution which is creating a background service running all networking and game code. Then just have an activity that queries and and renders as well as sending input to the background service.
Not very good for those of us who want to use the ndk and use the native-activity activity.
My thinking about the solutions is:
That sounds like a testament of bad programming. Assuming they're going for the behavior of PS3/X360, the dash menu is accessible regardless of what's happening in the game. If your game crashes because you did not account for someone opening the menu while it loads, it's your fault.
Here, have a demo:
It's a lot of work for questionable benefit.
Yeah.. aside from this particular comment.. I've given up on this discussion.
This issue was one of the ones we discussed as a team today. We came to the following decision:
A tap of the OUYA button is pause, and a short hold of the button will open the system menu.
In a bit more detail, a tap of the button will broadcast an Intent that the game can intercept like a menu button press. We decided against just sending a menu button event as a keydown would be sent even if the intention was to keep holding it to access the system menu.
Holding the button for a moment will open the system menu, and the other "hold for __" functions will stay the same for now.
Founder of ReachingPerfection.com
www.yummycircus.com
Brilliant solution. Well done, OUYA team! Hooray!
I'm also wondering about suspending the game when the menu is up, or being able to pause the game when the menu is up.
Note that @nick is talking about "pause" in terms of the Android lifecycle. When the system menu is visible, you'll get an onPause event, when the user returns, onResume, or if they exit, onStop likely followed by onDestroy.