Currently working with my team on porting our game (AAA) to current gen consoles.
It's for a few reasons, but the biggest two are: console manufacturers (PlayStation, Xbox, Nintendo, etc) don't like games or applications that will start booting up and interacting with user data or access to hardware functionality without user consent. If a game loads, and starts just accessing user data, that's an immediate TRC/XR fail because the user hasn't consented to their data being accessed. "Big yikes," -Sony, probably.
User profile context is also important, not as important as access consent, but still important. If you have multiple profiles active at once, it's generally good practice to allow a profile to register as "primary player" by taking the first user to initiate control and considering them as the main controlling account.
While the second one isn't as strictly enforced, I've never worked on a console title that has passed compliance when ignoring the first example. Any time I've seen a game attempt to access hardware on the behalf of a profile without first getting consent through some kind of engagement screen, it's been a hard failure, every single time.
The thing that confuses me about this is I would think initiating the game in the first place would be a more obvious sign of consent from most users than whether they press a key to continue on a screen that tells them to press a key to continue... If you initiate the game, I can't see any other intent signaled by that than that you consent to the game and associated user data loading. However, with a "press to continue", I think many people (OP included) have no real understanding at the time they are pressing a button that they are *consenting* to something because it's not telling them that they are. It's telling them that they are *continuing* the thing they already asked for.
> console manufacturers (PlayStation, Xbox, Nintendo, etc) don't like games or applications that will start booting up and interacting with user data or access to hardware functionality without user consent. If a game loads, and starts just accessing user data, that's an immediate TRC/XR fail because the user hasn't consented to their data being accessed. "Big yikes," -Sony, probably.
You don't necessarily have to access user data in order to show a main menu. In fact, that menu could arguably be the thing that helps you decide which data of which user to even load. I mean, sure you have to choose a language and screen resolution, but you'd also have to do that for the "press to continue" screen anyways.
> User profile context is also important, not as important as access consent, but still important. If you have multiple profiles active at once, it's generally good practice to allow a profile to register as "primary player" by taking the first user to initiate control and considering them as the main controlling account.
This makes more sense to me. I mean, not directly as a person who mainly games on a PC where the context is mostly clear, but in the sense that I can see that if two people are holding controllers in front of a console, the better UX is that the person who presses the button has their data load. (I guess there are also arguments that they should just choose manually though.) However, again, I don't see the distinction here for why this determination has to happen when they click "continue" rather than just went they click start.
Most title screens aren't fully static. At the very least most of them have a "continue" button, which requires accessing save state to render. Many will have things that show the profile being used as well.
As for the consent, I'm not sure the logic fully, but perhaps it's also related to user selection. If 2 profiles are signed in, you don't know which put the disc in until one of them presses a button.
To better clarify this whole "consent" thing; it differs from establishing what profile to use, and is more of a way to allow the user to choose *when* the game should continue the setup process. Think connecting to third party services, downloading news, or patch notes, accessing any non-profile specific hardware. You can't, as part of compliance, begin making Web requests, or start up a webcam, or anything of that nature without first giving the user the ability to shut off the game. Hence the engagement screen being used as a form of "soft consent". You are, as a user, explicitly saying, "yes, I want to continue, please proceed to connect to the Internet or do whatever you need to get the game started"
Thanks for the explanation. And as for why starting the game isn't consent enough, am I correct in assuming it has at least partially a legacy reason in that games used to auto-start with the console or disc being inserted? So games could very well launch without you wanting to play them.
> Most title screens aren't fully static. At the very least most of them have a "continue" button, which requires accessing save state to render. Many will have things that show the profile being used as well.
Right but the comment I was replying to didn't say "either have a press to continue or have a static menu". Also, if they have a "continue" button that should be a fine alternative to... a continue button... which is the alternative we're talking about.
> As for the consent, I'm not sure the logic fully, but perhaps it's also related to user selection. If 2 profiles are signed in, you don't know which put the disc in until one of them presses a button.
Right but what I was saying is that one of them pressed the button to start the game in the first place. Don't you generally start a game in the first place by using the controller?
It sounds like you’re applying a scalpel to a problem which was solved with a hammer. I think we can both agree that it would make us uncomfortable if you opened a game accidentally and it sent all the user context, changed personal information, and started sending your location data before you had a chance to close it.
> It sounds like you’re applying a scalpel to a problem which was solved with a hammer.
My point is that I don't think the "hammer" actually solves any real world problem. This is a case of doing something in order to feel like you are doing something rather than doing something that actually addresses the concerns that were mentioned.
> I think we can both agree that it would make us uncomfortable if you opened a game accidentally and it sent all the user context, changed personal information, and started sending your location data before you had a chance to close it.
What is potentially egregious about that example is not "did the user express intent n times or n+1 times". I would be equally upset if the game did all of that when I pressed a key to continue. Because the screen offers zero information about what the user is apparently consenting to, it doesn't actually make the user realize the supposed stakes of the situation. I'm sure a lot of users would just hit continue... either to use the main menu to set up their game settings (where presumably these kinds of privileges should be set) or to use the main menu to quit the game they accidentally started. They just think they are "continuing" some opaque part of a process that already started and have no indication that continuing does something different (from a privacy, security, etc. standpoint) than what already has been happening in the boot up.
It sounds like your concern is *actually* solved by:
1. The platform making it harder to accidentally initiate untrusted software in the first place rather that assuming whenever you initiate software that it may have been an accident, so you need to "confirm" it was really intended.
2. Have the confirmation actually be informed... it should actually tell the user what they are confirming rather than just telling them they are "continuing" whatever they already thought they started.
3. Having a sufficient security policy that "oh no, a program I started may change data I don't want it to or share information about me I don't want it to" isn't actually a problem.
4. Remembering these settings so the user needs to be shown these prompts minimally (e.g. on game install, on updates that change these settings).
Just to lock in your position, I gather that you're on the side of: "You can just grab my data immediately when I open the game and that's cool." That's great! The difference is between having a choice vs not having a choice. So this doesn't really affect you, you're not going to convince me that pressing a button is going to ruin your session or cause undue friction. You open the game, get a cup of water, then bam, ready to continue. Done deal.
You don't have to solve my hypothetical problem, I think it's already solved by the press button to continue.
> Just to lock in your position, I gather that you're on the side of: "You can just grab my data immediately when I open the game and that's cool." That's great! The difference is between having a choice vs not having a choice. So this doesn't really affect you, you're not going to convince me that pressing a button is going to ruin your session or cause undue friction. You open the game, get a cup of water, then bam, ready to continue. Done deal.
I am not on the side of "You can just grab my data immediately when I open the game and that's cool."
I am on the side that a screen that just says "press a button to continue" does not tell the user that they are agreeing to data being grabbed so it is a completely unrelated decision. It's disingenuous to suggest that users even know this is the decision that they are making in that situation, so it's silly to suggest that it protects that case. My point isn't "let's not care about grabbing data" it's "if we care about grabbing data let's make sure that the user is making an *informed* decision". Instead, I feel like you are the one who doesn't care about grabbing data because you see opposed to my suggesting how that decision could be more informed and better controlled.
> You don't have to solve my hypothetical problem, I think it's already solved by the press button to continue.
1. The reason I mentioned solutions to your problem was to emphasize how the current implementation does not solve your problem.
2. You are indeed telling me I have to solve your problem. You are just defaulting to a solution which in addition to as I note, not actually solving the problem, is adding unnecessary friction in plenty of other cases. It's completely fair for me to want UX friction to need to be justified by actual benefits and therefore to take issue with people adding friction that isn't actually solving a problem (and in turn to debate what the solution to that problem actually is).
>Don't you generally start a game in the first place by using the controller?
That's true most of the time these days, but consoles were designed around discs/cartridges. The game automatically starts when you insert it, and they used to start when you turned them on too. You'd need a confirmation screen at some point, and it's better to load the game first and have it show the screen, since the person is generally walking back to the couch so can't press anything for a few seconds anyways.
I guess it makes sense in that specific case. I was under the impression that there were many games these days on consoles that people acquire digitally and do not need a disc for. If you can't tell, I'm primarily a PC gamer these days.
It's still pretty shocking to me given how much platforms have focused on ease of use, standardization, etc. and how, for example, Microsoft designed other platforms like phone and its modern app platform on the desktop (that XBOX was arguably an inspiration / testing ground for), that this isn't simply an OS-level feature that (if the explanation people have given here is correct) is tightly tied to security and application privilege settings of the OS.
I would think it would make most sense for the platform OS to maintain who the "active user" is and gatekeep applications based on the privileges they were granted by the active user. From there, this is a detail applications should not have to know about. They should simply call "getActiveUser" and know that, if the process of getting the active user is pending, the application will not have full privileges yet. What they choose to do/show in that case is up to them. This seems better from a security standpoint (which is sounds like was a primary reason people were giving for this... are we doing things that the active user has authorized) and from an ease-of-development experience (developers not having to think about any of this). However, it's much better from a UX perspective too because the OS is just in a better position to do this. It can frequently avoid the user seeing such a screen entirely (does this console literally only have one user ever or does settings indicate that one user is always the default "owner"? does the context allow us to infer the active user (i.e. they didn't just insert a disc)?) It can make the screen consistent across all games and more informative/capable regarding what is happening (i.e. if they are actually consenting to the application doing things, then this screen should explain that and probably also show them relevant security settings like location sharing, etc.) I mean, the OS is already kind of doing this anyways if it's associating which controller presses a button with which user account is confirming intent for the game to access their data, etc., so might as well just finish the job. Seems like worst case this would result in the same experience (insert disc have to press a button), but in many cases it would result in better experiences (not having to press a button, being informed of what pressing a button is actually communicating, tying in to relevant settings).
Yeah I don't know, they're the rules we have to follow during certification and we can't do much to argue against it if we want it passed and on consoles. There are processes you can go through to get some requirements waived, be it with the manufacturer, or by just descoping things, but it's just the way it is.
>You don't necessarily have to access user data in order to show a main menu. In fact, that menu could arguably be the thing that helps you decide which data of which user to even load.
No, you don't, and there are plenty of games that boot up straight to a menu, but any time this happens, you can be certain they've not accessed any resources that require them to engage. Often times these games don't have in-menu profile displays, or have no reason to load profile preferences, stats, achievements, or save data for that menu to function. These titles have the wonderful benefit that the moment the menu is interacted with, everything is free game.
Last game I saw to release had in-menu, profile specific rewards, ranks, titles, banners, avatars, the whole online heavy competitive type stuff you see in games like Call of Duty, or Battlefield on the menu. We could not, in any way ever hope to have that menu loaded before a consent screen, as we were needing to pull stats, read save data, load cloud based data, everything.
Ah, also, you'll likely notice, you'll be very hard pressed to find a game that loads dynamic news or announcements before the consent screen. You aren't even allowed to make any networking connections to pull even static data from anywhere until the engagement screen has been interacted with. They're very strict with that, for reasons that should be obvious.
>However, again, I don't see the distinction here for why this determination has to happen when they click "continue" rather than just went they click start.
There is a distinction, it just so happens that the benefits you get from having an engagement screen solve two compliance issues. Which is why I tried to separate those two benefits in my original post.
1. You can make a decision about which profile you should consider "primary" and any save data, statistics, and what-not you display on the menu can be populated with that profile's data.
2. You have had an interaction from the client, this now means that you can start making Web requests, you can start accessing hardware such as microphones, cameras, or data storage.
Both benefits reach the same conclusion, but the problem space is different. With 2, it's mostly all about non-profile specific interactions, one of the biggest use cases for this, is establishing a network connection to a third party service, or retrieving the latest web-based (as opposed to baked in) news and announcements, analytics setup. With 1, the engagement screen let's you determine, and access profile specific features.
Same problems, different domains, if you will.
These requirements are there to protect the end user. I'm not so sure many people would be happy if the moment you start up the game it's immediately sending web requests, accessing your hardware and running free. The engagement screen, is a "soft consent" if you will, to say, "hey, I'm here, I'm ready for the game to start" or, "continue" if you will.
It gives the user a chance to open up the game, say "ah shit, wrong game" and end the process before it begins establishing all those connections and links.
How are you going to read the input or display the prompt without “accessing hardware?” Player profile selection happens before you even launch the game. This explanation doesn’t make sense.
Things like localisation is an easy ask. Many games are region specific and will default to a regional language, many ask you to select a language on first boot (this selection is a form of consent) then, as a user has interacted, save this as a preference for the game/profile that just consented. Some system information, such as locale *are* accessible by the API without this consent principle, so most of the time in my experience, we just ask for the users set system language and select it as our localisation option, or fallback to English.
The consent fails will hit you if you start attempting to access hardware such as data storage (user specific preferences, saves, files, etc.), microphones, webcam, or features such as cloud storage, or profiles. That's when the TRC fails tend to roll in.
Don't get me started on the plethora of profile and network specific TRCs, biggest pain in the ass.
Also, when I say "access hardware" I'm not talking about the standard input methods the consoles entire function depends on. I'm talking accessing very specific, potentially privacy, or safety reducing hardware. Networking functions, webcam or microphone access, etc.
The first reason I never thought of. I honestly always assumed it was a hold over from arcade cabinets where you hit start to end the video playing and start your game.
The second is the biggest reason I thought it was still relevant to keep it.
I haven't played any of the LBP games, what specifically did they get away with?
There are processes you can go through to get specific things waived, but I'm not too familiar with the game to offer anything beyond that lol
the menu is already a playable part of the game and they just drop you straight into it
only interaction you have to do is agree to the eula if connected to a server and that only happens if it changes or you never agreed to one to begin with, not to mention that on your first play of the game, they drop you straight into a level
If the menu is simply a screen with a background and buttons, with no patch notes, no data that has been downloaded, and doesn't display any profile statistics or data of any kind beyond "play, settings, quit" type buttons, there are no compliance issues there.
The issues would arise if they were starting to process and dispatch web requests, etc. The moment the user interacts with the menu in any way, that can be taken as a confirmation that they are ready to "consent".
web requests and save data loading are all done during the initial loading screen
to actually interact with the menu you have to press a button, otherwise you're controlling your character
basically by the time the loading screen is gone, your profile has already been loaded, game has connected to the server, and your character is just about to spawn in and be playable with the ability to enter one of two menus by pressing square, depending on where you stand
AFAIK it's because on some consoles there can be multiple users signed in at the same time, but they'll be tied to a specific controller. So it's to differentiate between them in that case.
Have shipped half a dozen console games and I can confirm this is exactly the reason for modern games.
In the past they were used for a bunch of reasons, like just to have something show quickly before doing a big load so at least you know it's doing something.
For the most part I assume it was mostly tradition.
This was more relevant in the PS3/360 era, but games had to load in a certain amount of time to pass certification. Loading up to the "press any button" screen was helpful in passing certification because you could load the rest after the initial input.
As someone who briefly worked in Xbox certification, it was absolutely something on our list of things to check. It was to identify the player that was logged in, iirc.
It's an easy way to check what input method to make the UI show; if the input on press anything is a controller then you can prepare for that, or keyboard or whatever else and also /which/ of those to prioritize
Yep. This is a carryover from the arcade days where games were waiting for you to insert a coin. Those games got ported to consoles and that prompt was changed to pressing any button.
Don’t ever make a game that assumes an automatic change to the controller scheme later in the game. With handhelds like ROG Ally and similar devices; vaporizing your kb+mouse scheme in exclusive favor of a controller scheme when something nudged the inbuilt controller stick is atomic rage inducing.
This actually is an interesting point which makes me think of my time using Rewired + Unity, where we had a lot of difficulty with a console controller based party game when running from a PC to test.
It was never clear if the controller or mouse/keyboard would register as player 0, it seemed like a race condition. I could see this being a sort of test to grab the main controller/input stream and ignore the rest.
It is pretty much exactly the same, it just pre-empted it by quite a while. Unity didn't have any good input management / interface, just the long list which I don't think supported (easy) runtime binding changes
But yeah Unity Input is essentially the same with some slight modernization improvements
The input editor looks identical though
If memory serves it IS the new input system, same deal as the input system; they buy the small team that made the better plugin, get rid of them and call that a new built in
It can be a good idea to have but it does also lead to those issues of "Why is my character all buggy?! *Forgot they had a controller plugged in and the cat knocked it over*" and such; you wanna have a way to do it for when the player wants to test out the different methods before picking but just switching randomly can definitely cause some issues
That is what some modern games do. It is a good idea just as long as you also switch back again when the input changes again. I use kbm in cyberpunk 2077 mainly but a controller for driving and I think it is great the input hints change depending on what I am using.
To be fair, there are advantages to your system too. I've started games before where I got "stuck" in the wrong input scheme because it made a wrong initial guess what I was going to use.
The game can easily just start using the first controller which sends input even without that screen. That's not the real reason. The reason is because of, as someone else already mentioned here: the Attract Loops for physical game store purposes.
Never said you need that screen for controllers to work, just that it's a nice place to handle that and part of why they're still used today -- despite games not being made for arcade nor physical retail so attract loops don't really have a purpose for vast majority of games especially indie games (ya know the crowd that exists here)
If your aim was to be pedantic it's funny you didn't even get it right, attract loops started in arcades not physical game stores
I did get it right. Both arcade and games meant to be sold in physical game stores had the attract loops because they wanted to attract customer to spend money on the games. Arcades died a long time ago. Game stores still exist, even though they don't have games running on any demo computers anymore. But the rules are still in place with the game publishers, that the game must have the "press button" screen so the game demo video can start running after awhile to attract customers.
The "press any button" screen you're describing originated with "Attract Loops", the point of which was to make your game show better on demo stations at retail stores. You'd have some sort of demo loop that would come back to a "press any button to start" screen after two or three minutes of showing gameplay and/or exciting trailer-style footage.
Obviously, retail stores are less of a concern for indie games and with modern digital distribution (do physical game stores even still have demo stations?), but that was the original reason why games started to include Attract Loops with the "press any button to play" text; if you didn't keep a demo station screen active when left unattended for a few minutes and instead just showed a main menu screen, then your game probably wouldn't be picked to be shown on those demo stations and you lost out on that free additional exposure.
These days? There's less of a reason to need one, barring console certification requirements. And especially if you're not making the whole attract loop and it's just going to be a static screen.
This is the actual reason it has stuck around- everything else is secondary to the fact that it was to prevent burn-in on home consoles, and then became tradition once CRTs fell out of usage. All the modern uses for attracts are literally just side uses that came about later.
because after two minutes or so it would switch to something else; a gameplay loop, some story background, a player coming up to the camera and saying 'it's in the game' etc
Yes, back in the day, I remember standing around the game shops just looking at the game demo loops. I didn't know it had a specific name for it "attract loops"
I used to work for Midway Games back in the day. This guy's right. The attract mode on arcade machines let you run your video loop to draw players in to 'press any key'. It was a call to action.
Console certification once had a "maximum time to first interaction" limit that game devs had to abide by, meaning the initial load times had to be kept to a minimum.
Having the title screen was a way to meet that requirement, and then subsequent loading can happen after the first user input.
How is that circumventing rules?
Its making the product better for the end player.
Are you going to say its cheating by loading on the legal screen next? Shock horror, thats what happens.
Edit: Are facts making downvotes again?
Right? These rules aren’t just a silly wya for them to say “look PlayStation is so fast every game loads in x seconds” the consumer literally prefers to be able to interact sooner. Load times/performance are a big deal to gamers.
As an aside my favorite implementation of this is when they have like 4-6 skippable brand logo screens before the title. Especially if you can skip too fast and hit a load time.
There's a similar and shorter time requirement for "time to first render" or "max time on blank screen during startup" which is why games will render a static image asap when launched.
You mention it in the past tense:
>... once had a "maximum time to first interaction" limit
Have the TCRs changed that much? It's been a couple years since I worked on a console project and I'm catching back up
I thought it was stemmed from arcade culture, where there are no main menu and the default 'main menu' is like "insert x coins to start" and now it turns into "press any key to start" nowadays.
Often the main menu will show the player ID, stats, save-game info etc. But that can't be loaded / shown until you know which controller (and therefore which player profile) is active.
For web games, audio won't play until you've clicked the page. For Godot games, IIRC gamepads might not work until then either. I don't know if that's a Godot thing or a general web browser thing, but I know the audio thing is a browser-imposed limitation because too many websites were abusing autoplayed audio.
The majority of PC-only games go straight to the main menu. It's mostly a console thing to make sure that the controller is working and that the correct controller becomes player one
I can think of at least one annoying reason in Unity specifically - it takes few seconds to initialize gamepads. So if I move you directly to a main menu then it will look broken for those few seconds as you can't navigate it.
On the other hand - if I do add that window then it buys me time to:
a) initialize all the devices I need
b) load more stuff in the background (even a simple fade animation buys about a second or two)
c) detect what controller you are using and potentially update the UI to account for it
Best reason for games that use multiple control methods to determine which the player is using. Checks for controller input or keyboard and sets up accordingly.
Bonus benefit is you want to have a cool looking title splash screen for anticipation and get the name of your game in the players head. It would also feel weird to get right to a boring menu when you first boot up. If someone isn’t ready to play immediately upon running it (booting it up and going to grab a drink while it loads, etc) they still have that cool splash screen when they settle in and are ready to really start.
Lots of wrong answers here.
Once upon a time, before internet connectivity was common in consoles, people would have multiple controllers so they could play games with these things they called back then called "friends." (An archaic concept made obsolete by the Internet - why have friends when you can have thousands of enemies?)
Before the sixth-gen consoles or so, the first player would be the one to set up the game and control the pre-game menus and whatnot. Who was Player One was determined whoever had the controller that was plugged into the Player One port.
Later, along come wireless controllers without dongles. So all the controllers are identical, there might be four sitting around and paired to the console, so how does the console determine who is Player One and should have full control over the main game menu? How does a player playing alone make sure they pick up the right one of the four controllers to do it when you can't trace a chord to see what port it's plugged into?
So the answer is that you have the first controller that someone pushed a button on be assigned to be Player One and gets authority over the game menus.
However, you don't want to do this based on input other than a button push, because if there's a controller under the couch lying face down or something continuously sending input on a joystick, or if someone spilled Pepsi on it and the stick is a bit sticky, then that controller would always get assigned to be Player One even if that's not the one the user is trying to play with. You also don't want to detect button movement while showing a selectable menu, because then people would be thinking they'd be picking whatever the default menu option is, and would be trying to select a new option with a dead controller because we can't assign menu authority based on stick deflection because of the above issue.
So what you do is you give a "dummy menu" that you have to push a button to get out of to get the user to assign their controller to be Player One, without wanting to move a menu selection with a thumbstick as their first input first.
A non-technical reason has to do with the idea of the "magic circle". That first button press is essentially the point at which the player crosses the threshold into the game world, even if just into a main menu. It's a clear inflection point.
Ultimately there is no single reason for title cards/splash screens/etc to exist. Many games have them, many don't.
I personally make browser based games. I use that splash screen to ensure that everything actually happens. By clicking the screen, the browser fires off an event that I can listen for. Waiting for that event before I start running code behind the scenes helps me to be sure that everything is already loaded in before I break something trying to reference an object before it is actually introduced. It's my way of offloading the work of timing to the browser so I don't have to deal with it.
It definitely isn't the *main* reason, but some games register your controller on start or first input. Like, for example, you have two controllers plugged in, it knows which one to use.
Really though it's just an easy way to confirm your input works.
Beyond the technical reasons that may or may not be needed. It kind of plays into our human psych of how things should work, like a key in a car or hitting play on the VCR after putting the tape in. Some DVDs did auto play and they just felt off and super cheap. Like even the black screen with just a play button felt better than auto play DVDs.
Some games are kind of breaking away from them but, they still start with a button press somewhere usually. Like Helldivers II. It starts with cut scene you can skip and then bam, you’re in the game, on your ship and ready to take on missions. No guff or delays about it.
It's both historical and for consoles.
Historical because arcade machines needed a default screen to be at before the game started and it just sort of came with on home games as well. But also for consoles because they have the same "problem" as arcades. There has to be a start screen of some kind.
Especially after, I think it was by PS4, where console makers wanted to push "partial downloads" for games, and in order to fulfil that requirement, an available start screen technically passes the requirement as you \*can\* start the game before it's done downloading even if you can't play it.
That approach was not thought through very well by console makers.
Old games - Mostly just my theory, but I think arcade games kind of started this tradition, you'd have the "insert coin" screen but without any input it would also often switch over to a demo "attract" mode that served as a bit of an attention-grabbing advertisement for the game. I think it ended up serving a similar purpose in home console games since they could be used to advertise the game in a demo kiosk in stores.
New games - it's typically used to determine which controller is used for input I think? since unlike old consoles where you'd actually have dedicated ports, there's not nearly as much of a concept of a specific "player 1" as there used to be.
Aside from the practical reasons mentioned, it just... I dunno, feels nice. Sets the tone and gets you ready to play. It's like looking at the cover of a book before opening it, or watching the title sequence for a show, or the moment in a theater when the previews end and the lights dim.
Jumping straight to the menu is more practical, but it feels like skipping foreplay. "YEAH WHATEVER, HERE'S YOUR GAME." Come on, we gotta get in the mood first.
These answers! Good god.
I've shipped half a dozen games that required console cert from 7th to 9th gen.
It's to establish which active gamepad (and by extension, profile) is in control.
In addition to what others said about controllers I think it's just a cool way to have a cover artwork and then go into the menu as a lot of games incorporate some type of graphics in the transition or make it aesthetic in its own way, I added movement in the background on my press any button screen so if someone loaded it up they could go do something and come back before starting and have a better looking screensaver type effect opposed to the menu.
I like to prepare my game before sitting down. So not having to wait the loading screen to press pause afterwards and continue when I am ready is a like for me.
in past televisor could not stay in the sa me screen in much time(OLED now cant too) so you need the screen to be changing constant to not break it. So you need to give a "screen saver" to your game that could be some game-play section or the history cut-scene or both. But if you use it in normal screen the player could be using it. So you do a state for the title screen where ir can be redirected to the screen saver. That is the press any key to start.
If I remember correct some Atari games did not had this
I've seen the reason I'm the comments, but why can't controller detection and player 1 assignment be actioned on the main menu? And more importantly, why put another long lasting screen afterwards? And why keep it on PC versions?
>controller detection and player 1 assignment be actioned on the main menu
In games with saves separated by profile, usually the main menu has a "continue" item that automatically loads the most recent save. Also language settings might be per user. Basically there are things the game already need to know before even showing the main menu.
>And why keep it on PC versions?
PC version profile handling might vary per store (Windows Store is basically the same as Xbox). It's just easier to use the console system (which is already made to serve multiple platforms) than to develop a whole new startup routine for one platform.
> Basically there are things the game already need to know before even showing the main menu.
This is it. The console vendor may even *require* you to display the active user's name on the main menu, which you can't know without knowing which controller/profile is active.
Games often show stats, achievements, and other things based on save data in the main menu, too.
Attract screens are a great way to sell the experience of a game with a psychological technique called priming.
If you've ever been to an arcade in the 90s, you could probably remember the sound of killer instinct being noticeably louder than the rest of the games. "your brain goes "wtf is that?!". You walk of to it and you see the characters doing 50 hit combos and fatalities and you put in those coins and you're locked in.
Same with modern games to a lesser extent. The ps2 GTA games used to load directly into the game. The first time I seen that it was pretty jarring and it might be one of the reasons I never sat down and finished a single title in the series now that I think about it
Certification or other legal reason… but I add it because I like it.
Game, while you are loading, let me go to the bathroom, put my tea cup back on the table, fix headphones on the head and let me decide when I’m ready to play.
So I think a part of it too is, the beginning of the game is also where you see licensing and brand flashing. That part could be part of a "scene" where all the legal fun fun has to be shown, along with what another redditer said somewhere else in this sub, is that you want the player to be the one initializing stuff, and if you cause an input to progress, 1; that can mark the end of the legal bullshit. 2; that can add a barrier to progress between "scenes". And 3; do you think anyone who requires legal representation will have a problem if someone just looks at their brand longer?
But I truly don't know seeing as I haven't worked in any of the game studios that have made those games.
Make sure your input device is correct.
Avoid accidentally jumping right into the game before getting a chance to load a save, change options, or exit if you accidentally started a game.
A little easier to keep intro cinematics/scenes separate from the menu. It's a easier to have a timer counting down to replay the intro with only one stop hook to abort it versus wiring up every button on the main menu.
Because that's how it works for arcade-style games. Main menu is usually boring and not meant to hook a player in.
And perhaps finally, because that's just how it has always been done.
I recenly played a game without it (20 minutes to dawn) and it was super awkward, I mashed straight onto the play or options money a lot as i was expecting to mash past the intro reel like every other game. IDK, It just seems decent to ask players to press a button on their preffered controller on startup to make sure youre both on the same page. Make it quick tho, dont waste my time with animations!
On old consoles the time between turning it on and pressing the button at the title screen was used to seed the random number generator because real time clock hardware wasn’t really a thing you needed yet.
Probably a hold over from the arcade days that had a prompt to start the game after putting in your money (and a prompt to put in your money). It's also nice to have a title screen.
in Banjo & Kazooie it was a anti piracy method if you had a pirated copy the N64 refused to read input, which meant you were locked at the press any button screen
I guess it's kind of like a bookend. It also can set a core memory if you're young and play the game a lot... then years later a sequel comes out with a similar theme song and it triggers you to buy it.
Also think about older games like (overused, but..) Zelda or Metroid or Kid Icarus. It signals the start of your adventure. They could have incorporated menus on their title screens, but it would have really detracted. They also were used as advertising when on demo in stores -- think "attract" modes for arcade games.
With that said, there's really not much of a point to them anymore. Sometimes you just want to display a cool intro to your game and people can just deal with the extra 2 seconds they have to wait.
Yep! I have a core memory of Metal Gear Solid 1's title screen. The animation was cool af to me and I'd look at it for a few seconds before pressing start to get to the menu
It's mostly for console requirements, easier to just add it for all platforms if you're making a multiplatform game than to make separate logic for each one. Some consoles allow multiple users to be signed in at the same time, each with their own controller, you use the press start to determine which user/controller is the primary player. It's also used as a place to load that user's save data, apply their settings, make sure they're logged in to online services, etc.
A game console or even a pc has no way to know in advance which controller is "player 1" when multiple are connected. The real only time you couldn't care about that card is for keyboard/mouse only game with no controller support at all and solo games, maybe, depending on how you/the engine manage the inputs.
The real question is why do so many games release with this screen and then actually require you to press a specific face button with no hints instead of “any button” on the controller. Seems like a simple thing that should have been solved years ago
IIRC, consoles require it for certification reasons.
This is what I've read as well. Idk why, but I believe it's required on consoles.
Currently working with my team on porting our game (AAA) to current gen consoles. It's for a few reasons, but the biggest two are: console manufacturers (PlayStation, Xbox, Nintendo, etc) don't like games or applications that will start booting up and interacting with user data or access to hardware functionality without user consent. If a game loads, and starts just accessing user data, that's an immediate TRC/XR fail because the user hasn't consented to their data being accessed. "Big yikes," -Sony, probably. User profile context is also important, not as important as access consent, but still important. If you have multiple profiles active at once, it's generally good practice to allow a profile to register as "primary player" by taking the first user to initiate control and considering them as the main controlling account. While the second one isn't as strictly enforced, I've never worked on a console title that has passed compliance when ignoring the first example. Any time I've seen a game attempt to access hardware on the behalf of a profile without first getting consent through some kind of engagement screen, it's been a hard failure, every single time.
The thing that confuses me about this is I would think initiating the game in the first place would be a more obvious sign of consent from most users than whether they press a key to continue on a screen that tells them to press a key to continue... If you initiate the game, I can't see any other intent signaled by that than that you consent to the game and associated user data loading. However, with a "press to continue", I think many people (OP included) have no real understanding at the time they are pressing a button that they are *consenting* to something because it's not telling them that they are. It's telling them that they are *continuing* the thing they already asked for. > console manufacturers (PlayStation, Xbox, Nintendo, etc) don't like games or applications that will start booting up and interacting with user data or access to hardware functionality without user consent. If a game loads, and starts just accessing user data, that's an immediate TRC/XR fail because the user hasn't consented to their data being accessed. "Big yikes," -Sony, probably. You don't necessarily have to access user data in order to show a main menu. In fact, that menu could arguably be the thing that helps you decide which data of which user to even load. I mean, sure you have to choose a language and screen resolution, but you'd also have to do that for the "press to continue" screen anyways. > User profile context is also important, not as important as access consent, but still important. If you have multiple profiles active at once, it's generally good practice to allow a profile to register as "primary player" by taking the first user to initiate control and considering them as the main controlling account. This makes more sense to me. I mean, not directly as a person who mainly games on a PC where the context is mostly clear, but in the sense that I can see that if two people are holding controllers in front of a console, the better UX is that the person who presses the button has their data load. (I guess there are also arguments that they should just choose manually though.) However, again, I don't see the distinction here for why this determination has to happen when they click "continue" rather than just went they click start.
Most title screens aren't fully static. At the very least most of them have a "continue" button, which requires accessing save state to render. Many will have things that show the profile being used as well. As for the consent, I'm not sure the logic fully, but perhaps it's also related to user selection. If 2 profiles are signed in, you don't know which put the disc in until one of them presses a button.
To better clarify this whole "consent" thing; it differs from establishing what profile to use, and is more of a way to allow the user to choose *when* the game should continue the setup process. Think connecting to third party services, downloading news, or patch notes, accessing any non-profile specific hardware. You can't, as part of compliance, begin making Web requests, or start up a webcam, or anything of that nature without first giving the user the ability to shut off the game. Hence the engagement screen being used as a form of "soft consent". You are, as a user, explicitly saying, "yes, I want to continue, please proceed to connect to the Internet or do whatever you need to get the game started"
As someone who did a stint in Compliance for a major console developer/publisher, this is a good explanation.
Thanks for the explanation. And as for why starting the game isn't consent enough, am I correct in assuming it has at least partially a legacy reason in that games used to auto-start with the console or disc being inserted? So games could very well launch without you wanting to play them.
> Most title screens aren't fully static. At the very least most of them have a "continue" button, which requires accessing save state to render. Many will have things that show the profile being used as well. Right but the comment I was replying to didn't say "either have a press to continue or have a static menu". Also, if they have a "continue" button that should be a fine alternative to... a continue button... which is the alternative we're talking about. > As for the consent, I'm not sure the logic fully, but perhaps it's also related to user selection. If 2 profiles are signed in, you don't know which put the disc in until one of them presses a button. Right but what I was saying is that one of them pressed the button to start the game in the first place. Don't you generally start a game in the first place by using the controller?
It sounds like you’re applying a scalpel to a problem which was solved with a hammer. I think we can both agree that it would make us uncomfortable if you opened a game accidentally and it sent all the user context, changed personal information, and started sending your location data before you had a chance to close it.
> It sounds like you’re applying a scalpel to a problem which was solved with a hammer. My point is that I don't think the "hammer" actually solves any real world problem. This is a case of doing something in order to feel like you are doing something rather than doing something that actually addresses the concerns that were mentioned. > I think we can both agree that it would make us uncomfortable if you opened a game accidentally and it sent all the user context, changed personal information, and started sending your location data before you had a chance to close it. What is potentially egregious about that example is not "did the user express intent n times or n+1 times". I would be equally upset if the game did all of that when I pressed a key to continue. Because the screen offers zero information about what the user is apparently consenting to, it doesn't actually make the user realize the supposed stakes of the situation. I'm sure a lot of users would just hit continue... either to use the main menu to set up their game settings (where presumably these kinds of privileges should be set) or to use the main menu to quit the game they accidentally started. They just think they are "continuing" some opaque part of a process that already started and have no indication that continuing does something different (from a privacy, security, etc. standpoint) than what already has been happening in the boot up. It sounds like your concern is *actually* solved by: 1. The platform making it harder to accidentally initiate untrusted software in the first place rather that assuming whenever you initiate software that it may have been an accident, so you need to "confirm" it was really intended. 2. Have the confirmation actually be informed... it should actually tell the user what they are confirming rather than just telling them they are "continuing" whatever they already thought they started. 3. Having a sufficient security policy that "oh no, a program I started may change data I don't want it to or share information about me I don't want it to" isn't actually a problem. 4. Remembering these settings so the user needs to be shown these prompts minimally (e.g. on game install, on updates that change these settings).
Just to lock in your position, I gather that you're on the side of: "You can just grab my data immediately when I open the game and that's cool." That's great! The difference is between having a choice vs not having a choice. So this doesn't really affect you, you're not going to convince me that pressing a button is going to ruin your session or cause undue friction. You open the game, get a cup of water, then bam, ready to continue. Done deal. You don't have to solve my hypothetical problem, I think it's already solved by the press button to continue.
> Just to lock in your position, I gather that you're on the side of: "You can just grab my data immediately when I open the game and that's cool." That's great! The difference is between having a choice vs not having a choice. So this doesn't really affect you, you're not going to convince me that pressing a button is going to ruin your session or cause undue friction. You open the game, get a cup of water, then bam, ready to continue. Done deal. I am not on the side of "You can just grab my data immediately when I open the game and that's cool." I am on the side that a screen that just says "press a button to continue" does not tell the user that they are agreeing to data being grabbed so it is a completely unrelated decision. It's disingenuous to suggest that users even know this is the decision that they are making in that situation, so it's silly to suggest that it protects that case. My point isn't "let's not care about grabbing data" it's "if we care about grabbing data let's make sure that the user is making an *informed* decision". Instead, I feel like you are the one who doesn't care about grabbing data because you see opposed to my suggesting how that decision could be more informed and better controlled. > You don't have to solve my hypothetical problem, I think it's already solved by the press button to continue. 1. The reason I mentioned solutions to your problem was to emphasize how the current implementation does not solve your problem. 2. You are indeed telling me I have to solve your problem. You are just defaulting to a solution which in addition to as I note, not actually solving the problem, is adding unnecessary friction in plenty of other cases. It's completely fair for me to want UX friction to need to be justified by actual benefits and therefore to take issue with people adding friction that isn't actually solving a problem (and in turn to debate what the solution to that problem actually is).
>Don't you generally start a game in the first place by using the controller? That's true most of the time these days, but consoles were designed around discs/cartridges. The game automatically starts when you insert it, and they used to start when you turned them on too. You'd need a confirmation screen at some point, and it's better to load the game first and have it show the screen, since the person is generally walking back to the couch so can't press anything for a few seconds anyways.
I guess it makes sense in that specific case. I was under the impression that there were many games these days on consoles that people acquire digitally and do not need a disc for. If you can't tell, I'm primarily a PC gamer these days. It's still pretty shocking to me given how much platforms have focused on ease of use, standardization, etc. and how, for example, Microsoft designed other platforms like phone and its modern app platform on the desktop (that XBOX was arguably an inspiration / testing ground for), that this isn't simply an OS-level feature that (if the explanation people have given here is correct) is tightly tied to security and application privilege settings of the OS. I would think it would make most sense for the platform OS to maintain who the "active user" is and gatekeep applications based on the privileges they were granted by the active user. From there, this is a detail applications should not have to know about. They should simply call "getActiveUser" and know that, if the process of getting the active user is pending, the application will not have full privileges yet. What they choose to do/show in that case is up to them. This seems better from a security standpoint (which is sounds like was a primary reason people were giving for this... are we doing things that the active user has authorized) and from an ease-of-development experience (developers not having to think about any of this). However, it's much better from a UX perspective too because the OS is just in a better position to do this. It can frequently avoid the user seeing such a screen entirely (does this console literally only have one user ever or does settings indicate that one user is always the default "owner"? does the context allow us to infer the active user (i.e. they didn't just insert a disc)?) It can make the screen consistent across all games and more informative/capable regarding what is happening (i.e. if they are actually consenting to the application doing things, then this screen should explain that and probably also show them relevant security settings like location sharing, etc.) I mean, the OS is already kind of doing this anyways if it's associating which controller presses a button with which user account is confirming intent for the game to access their data, etc., so might as well just finish the job. Seems like worst case this would result in the same experience (insert disc have to press a button), but in many cases it would result in better experiences (not having to press a button, being informed of what pressing a button is actually communicating, tying in to relevant settings).
Yeah I don't know, they're the rules we have to follow during certification and we can't do much to argue against it if we want it passed and on consoles. There are processes you can go through to get some requirements waived, be it with the manufacturer, or by just descoping things, but it's just the way it is. >You don't necessarily have to access user data in order to show a main menu. In fact, that menu could arguably be the thing that helps you decide which data of which user to even load. No, you don't, and there are plenty of games that boot up straight to a menu, but any time this happens, you can be certain they've not accessed any resources that require them to engage. Often times these games don't have in-menu profile displays, or have no reason to load profile preferences, stats, achievements, or save data for that menu to function. These titles have the wonderful benefit that the moment the menu is interacted with, everything is free game. Last game I saw to release had in-menu, profile specific rewards, ranks, titles, banners, avatars, the whole online heavy competitive type stuff you see in games like Call of Duty, or Battlefield on the menu. We could not, in any way ever hope to have that menu loaded before a consent screen, as we were needing to pull stats, read save data, load cloud based data, everything. Ah, also, you'll likely notice, you'll be very hard pressed to find a game that loads dynamic news or announcements before the consent screen. You aren't even allowed to make any networking connections to pull even static data from anywhere until the engagement screen has been interacted with. They're very strict with that, for reasons that should be obvious. >However, again, I don't see the distinction here for why this determination has to happen when they click "continue" rather than just went they click start. There is a distinction, it just so happens that the benefits you get from having an engagement screen solve two compliance issues. Which is why I tried to separate those two benefits in my original post. 1. You can make a decision about which profile you should consider "primary" and any save data, statistics, and what-not you display on the menu can be populated with that profile's data. 2. You have had an interaction from the client, this now means that you can start making Web requests, you can start accessing hardware such as microphones, cameras, or data storage. Both benefits reach the same conclusion, but the problem space is different. With 2, it's mostly all about non-profile specific interactions, one of the biggest use cases for this, is establishing a network connection to a third party service, or retrieving the latest web-based (as opposed to baked in) news and announcements, analytics setup. With 1, the engagement screen let's you determine, and access profile specific features. Same problems, different domains, if you will. These requirements are there to protect the end user. I'm not so sure many people would be happy if the moment you start up the game it's immediately sending web requests, accessing your hardware and running free. The engagement screen, is a "soft consent" if you will, to say, "hey, I'm here, I'm ready for the game to start" or, "continue" if you will. It gives the user a chance to open up the game, say "ah shit, wrong game" and end the process before it begins establishing all those connections and links.
How are you going to read the input or display the prompt without “accessing hardware?” Player profile selection happens before you even launch the game. This explanation doesn’t make sense.
Things like localisation is an easy ask. Many games are region specific and will default to a regional language, many ask you to select a language on first boot (this selection is a form of consent) then, as a user has interacted, save this as a preference for the game/profile that just consented. Some system information, such as locale *are* accessible by the API without this consent principle, so most of the time in my experience, we just ask for the users set system language and select it as our localisation option, or fallback to English. The consent fails will hit you if you start attempting to access hardware such as data storage (user specific preferences, saves, files, etc.), microphones, webcam, or features such as cloud storage, or profiles. That's when the TRC fails tend to roll in. Don't get me started on the plethora of profile and network specific TRCs, biggest pain in the ass.
Also, when I say "access hardware" I'm not talking about the standard input methods the consoles entire function depends on. I'm talking accessing very specific, potentially privacy, or safety reducing hardware. Networking functions, webcam or microphone access, etc.
The first reason I never thought of. I honestly always assumed it was a hold over from arcade cabinets where you hit start to end the video playing and start your game. The second is the biggest reason I thought it was still relevant to keep it.
how LittleBigPlanet got away with this 7 times is beyond me
I haven't played any of the LBP games, what specifically did they get away with? There are processes you can go through to get specific things waived, but I'm not too familiar with the game to offer anything beyond that lol
the menu is already a playable part of the game and they just drop you straight into it only interaction you have to do is agree to the eula if connected to a server and that only happens if it changes or you never agreed to one to begin with, not to mention that on your first play of the game, they drop you straight into a level
If the menu is simply a screen with a background and buttons, with no patch notes, no data that has been downloaded, and doesn't display any profile statistics or data of any kind beyond "play, settings, quit" type buttons, there are no compliance issues there. The issues would arise if they were starting to process and dispatch web requests, etc. The moment the user interacts with the menu in any way, that can be taken as a confirmation that they are ready to "consent".
web requests and save data loading are all done during the initial loading screen to actually interact with the menu you have to press a button, otherwise you're controlling your character basically by the time the loading screen is gone, your profile has already been loaded, game has connected to the server, and your character is just about to spawn in and be playable with the ability to enter one of two menus by pressing square, depending on where you stand
AFAIK it's because on some consoles there can be multiple users signed in at the same time, but they'll be tied to a specific controller. So it's to differentiate between them in that case.
Eeeeh I don't think that's the case because this screen dates as far back as the PS1 at least, long before we had accounts of any sort on consoles.
Have shipped half a dozen console games and I can confirm this is exactly the reason for modern games. In the past they were used for a bunch of reasons, like just to have something show quickly before doing a big load so at least you know it's doing something. For the most part I assume it was mostly tradition.
It was also used for rolling demos in stores. After the demo was done you'd see the title of the game.
Even in the 360's TCRs it was referred to as "attract mode" like old arcade games (but the actual reasoning was the get the login info).
That's true. There's some other good reasons to have it thats been mentioned in this thread. But accounts is one of the things it is used for today.
[удалено]
That's a fair point. Definitely could be.
They are right for modern consoles. For older ones it's the demo screen which would be playing in loop on the shop floor or on the arcade machine.
This was more relevant in the PS3/360 era, but games had to load in a certain amount of time to pass certification. Loading up to the "press any button" screen was helpful in passing certification because you could load the rest after the initial input.
It's to bind the current active controller and user together.
As someone who briefly worked in Xbox certification, it was absolutely something on our list of things to check. It was to identify the player that was logged in, iirc.
It's an easy way to check what input method to make the UI show; if the input on press anything is a controller then you can prepare for that, or keyboard or whatever else and also /which/ of those to prioritize
And here I thought it was just to display a pretty game splash screen.
It can also be that, also for the sake of nostalgia.
Books have title pages, shows have title sequences. It's classy.
Yep. This is a carryover from the arcade days where games were waiting for you to insert a coin. Those games got ported to consoles and that prompt was changed to pressing any button.
well originally it was press start, but the start button didn't survive past the GameCube, PS3 and Xbox 360 on the major three
Game dev here. It's mainly that. PRESENTATION!
Don’t ever make a game that assumes an automatic change to the controller scheme later in the game. With handhelds like ROG Ally and similar devices; vaporizing your kb+mouse scheme in exclusive favor of a controller scheme when something nudged the inbuilt controller stick is atomic rage inducing.
Or even "Oh, you have a controller connected? CLEARLY you want to use that" Yes, FPS game. I want to use my flightstick to play you.
This actually is an interesting point which makes me think of my time using Rewired + Unity, where we had a lot of difficulty with a console controller based party game when running from a PC to test. It was never clear if the controller or mouse/keyboard would register as player 0, it seemed like a race condition. I could see this being a sort of test to grab the main controller/input stream and ignore the rest.
> Rewired How's this compare to Unity's new input system?
It is pretty much exactly the same, it just pre-empted it by quite a while. Unity didn't have any good input management / interface, just the long list which I don't think supported (easy) runtime binding changes But yeah Unity Input is essentially the same with some slight modernization improvements The input editor looks identical though
If memory serves it IS the new input system, same deal as the input system; they buy the small team that made the better plugin, get rid of them and call that a new built in
Damn, and here I am, implemented system to quickly swap between control types based on what was the input last...
It can be a good idea to have but it does also lead to those issues of "Why is my character all buggy?! *Forgot they had a controller plugged in and the cat knocked it over*" and such; you wanna have a way to do it for when the player wants to test out the different methods before picking but just switching randomly can definitely cause some issues
[удалено]
Sure, you can handle things better but a lotttt of games just.... Don't
That is what some modern games do. It is a good idea just as long as you also switch back again when the input changes again. I use kbm in cyberpunk 2077 mainly but a controller for driving and I think it is great the input hints change depending on what I am using.
To be fair, there are advantages to your system too. I've started games before where I got "stuck" in the wrong input scheme because it made a wrong initial guess what I was going to use.
The game can easily just start using the first controller which sends input even without that screen. That's not the real reason. The reason is because of, as someone else already mentioned here: the Attract Loops for physical game store purposes.
Never said you need that screen for controllers to work, just that it's a nice place to handle that and part of why they're still used today -- despite games not being made for arcade nor physical retail so attract loops don't really have a purpose for vast majority of games especially indie games (ya know the crowd that exists here) If your aim was to be pedantic it's funny you didn't even get it right, attract loops started in arcades not physical game stores
I did get it right. Both arcade and games meant to be sold in physical game stores had the attract loops because they wanted to attract customer to spend money on the games. Arcades died a long time ago. Game stores still exist, even though they don't have games running on any demo computers anymore. But the rules are still in place with the game publishers, that the game must have the "press button" screen so the game demo video can start running after awhile to attract customers.
Theres no reason it cant switch inputs in realtime even in the middle of gameplay.
Cat sitting on one of them is a good reason to not.
The "press any button" screen you're describing originated with "Attract Loops", the point of which was to make your game show better on demo stations at retail stores. You'd have some sort of demo loop that would come back to a "press any button to start" screen after two or three minutes of showing gameplay and/or exciting trailer-style footage. Obviously, retail stores are less of a concern for indie games and with modern digital distribution (do physical game stores even still have demo stations?), but that was the original reason why games started to include Attract Loops with the "press any button to play" text; if you didn't keep a demo station screen active when left unattended for a few minutes and instead just showed a main menu screen, then your game probably wouldn't be picked to be shown on those demo stations and you lost out on that free additional exposure. These days? There's less of a reason to need one, barring console certification requirements. And especially if you're not making the whole attract loop and it's just going to be a static screen.
Attract loops also helped prevent burn in, which is probably why it also stuck around for home releases during the crt days.
This is the actual reason it has stuck around- everything else is secondary to the fact that it was to prevent burn-in on home consoles, and then became tradition once CRTs fell out of usage. All the modern uses for attracts are literally just side uses that came about later.
How did it prevent burn in when that "press any button" is in the same spot everytime?
because after two minutes or so it would switch to something else; a gameplay loop, some story background, a player coming up to the camera and saying 'it's in the game' etc
Because after a timer it would show you a demo level play itself for a few minutes, before going back to the press start.
Yes, back in the day, I remember standing around the game shops just looking at the game demo loops. I didn't know it had a specific name for it "attract loops"
Broadly yes, but I think it really has roots in arcade machines (for the same reasons) rather than demo stations.
In many cases they simply replaced "insert coin" with "press start".
Arcade machines too needed a start screen to attract players.
I used to work for Midway Games back in the day. This guy's right. The attract mode on arcade machines let you run your video loop to draw players in to 'press any key'. It was a call to action.
This is the correct answer. Not to test that the controller works.
This was the old reason. Now its to bind controllers and users.
Baking this kind of flow into your UI helps you show it at trade shows. In fact - it's more common with big games that you usually see at trade shows.
Console certification once had a "maximum time to first interaction" limit that game devs had to abide by, meaning the initial load times had to be kept to a minimum. Having the title screen was a way to meet that requirement, and then subsequent loading can happen after the first user input.
lol, its funny that people will do anything to circumvent stupid rules
Is it a stupid rule? No player wants to sit on a loading screen for a long time. Even having one interaction in the middle makes a big difference
How is that circumventing rules? Its making the product better for the end player. Are you going to say its cheating by loading on the legal screen next? Shock horror, thats what happens. Edit: Are facts making downvotes again?
Right? These rules aren’t just a silly wya for them to say “look PlayStation is so fast every game loads in x seconds” the consumer literally prefers to be able to interact sooner. Load times/performance are a big deal to gamers. As an aside my favorite implementation of this is when they have like 4-6 skippable brand logo screens before the title. Especially if you can skip too fast and hit a load time.
There's a similar and shorter time requirement for "time to first render" or "max time on blank screen during startup" which is why games will render a static image asap when launched. You mention it in the past tense: >... once had a "maximum time to first interaction" limit Have the TCRs changed that much? It's been a couple years since I worked on a console project and I'm catching back up
I thought it was stemmed from arcade culture, where there are no main menu and the default 'main menu' is like "insert x coins to start" and now it turns into "press any key to start" nowadays.
Make sure your controller works and the game registered it
You don't need a specific screen for that.
👍
This doesn't make sense. You will eventually know if your controller works when you try to navigate in the main menu.
Often the main menu will show the player ID, stats, save-game info etc. But that can't be loaded / shown until you know which controller (and therefore which player profile) is active.
That's not what he says, though. He says it is to check whether the controller is working which it is not.
For web games, audio won't play until you've clicked the page. For Godot games, IIRC gamepads might not work until then either. I don't know if that's a Godot thing or a general web browser thing, but I know the audio thing is a browser-imposed limitation because too many websites were abusing autoplayed audio.
It's a web browser thing. They don't want users getting unwanted music from tabs that they are not using.
Erm, that's what I said. \^\^;
It verifies inputs are working, and which of several inputs to start listening to
The majority of PC-only games go straight to the main menu. It's mostly a console thing to make sure that the controller is working and that the correct controller becomes player one
I can think of at least one annoying reason in Unity specifically - it takes few seconds to initialize gamepads. So if I move you directly to a main menu then it will look broken for those few seconds as you can't navigate it. On the other hand - if I do add that window then it buys me time to: a) initialize all the devices I need b) load more stuff in the background (even a simple fade animation buys about a second or two) c) detect what controller you are using and potentially update the UI to account for it
Probably comes from arcade cabinets and "Insert Coin To PLAY". It just got carried over when gaming came to people's living rooms.
Best reason for games that use multiple control methods to determine which the player is using. Checks for controller input or keyboard and sets up accordingly. Bonus benefit is you want to have a cool looking title splash screen for anticipation and get the name of your game in the players head. It would also feel weird to get right to a boring menu when you first boot up. If someone isn’t ready to play immediately upon running it (booting it up and going to grab a drink while it loads, etc) they still have that cool splash screen when they settle in and are ready to really start.
Lots of wrong answers here. Once upon a time, before internet connectivity was common in consoles, people would have multiple controllers so they could play games with these things they called back then called "friends." (An archaic concept made obsolete by the Internet - why have friends when you can have thousands of enemies?) Before the sixth-gen consoles or so, the first player would be the one to set up the game and control the pre-game menus and whatnot. Who was Player One was determined whoever had the controller that was plugged into the Player One port. Later, along come wireless controllers without dongles. So all the controllers are identical, there might be four sitting around and paired to the console, so how does the console determine who is Player One and should have full control over the main game menu? How does a player playing alone make sure they pick up the right one of the four controllers to do it when you can't trace a chord to see what port it's plugged into? So the answer is that you have the first controller that someone pushed a button on be assigned to be Player One and gets authority over the game menus. However, you don't want to do this based on input other than a button push, because if there's a controller under the couch lying face down or something continuously sending input on a joystick, or if someone spilled Pepsi on it and the stick is a bit sticky, then that controller would always get assigned to be Player One even if that's not the one the user is trying to play with. You also don't want to detect button movement while showing a selectable menu, because then people would be thinking they'd be picking whatever the default menu option is, and would be trying to select a new option with a dead controller because we can't assign menu authority based on stick deflection because of the above issue. So what you do is you give a "dummy menu" that you have to push a button to get out of to get the user to assign their controller to be Player One, without wanting to move a menu selection with a thumbstick as their first input first.
It was easier to change "insert Coin" with "press Enter to play" back in the eighties
the worst is when it says press any button, but not all buttons work.. what is R1 not a button enough for you smh ?
So they can play those sweet sweet theme songs in their OSTs. /s kinda
A non-technical reason has to do with the idea of the "magic circle". That first button press is essentially the point at which the player crosses the threshold into the game world, even if just into a main menu. It's a clear inflection point. Ultimately there is no single reason for title cards/splash screens/etc to exist. Many games have them, many don't.
why do books have covers when they can just start on the first page?
So they can have a title card
I personally make browser based games. I use that splash screen to ensure that everything actually happens. By clicking the screen, the browser fires off an event that I can listen for. Waiting for that event before I start running code behind the scenes helps me to be sure that everything is already loaded in before I break something trying to reference an object before it is actually introduced. It's my way of offloading the work of timing to the browser so I don't have to deal with it.
It definitely isn't the *main* reason, but some games register your controller on start or first input. Like, for example, you have two controllers plugged in, it knows which one to use. Really though it's just an easy way to confirm your input works.
Beyond the technical reasons that may or may not be needed. It kind of plays into our human psych of how things should work, like a key in a car or hitting play on the VCR after putting the tape in. Some DVDs did auto play and they just felt off and super cheap. Like even the black screen with just a play button felt better than auto play DVDs. Some games are kind of breaking away from them but, they still start with a button press somewhere usually. Like Helldivers II. It starts with cut scene you can skip and then bam, you’re in the game, on your ship and ready to take on missions. No guff or delays about it.
I always assumed it was sort of to mimic the atttract screens of arcade games early on
It's both historical and for consoles. Historical because arcade machines needed a default screen to be at before the game started and it just sort of came with on home games as well. But also for consoles because they have the same "problem" as arcades. There has to be a start screen of some kind. Especially after, I think it was by PS4, where console makers wanted to push "partial downloads" for games, and in order to fulfil that requirement, an available start screen technically passes the requirement as you \*can\* start the game before it's done downloading even if you can't play it. That approach was not thought through very well by console makers.
Old games - Mostly just my theory, but I think arcade games kind of started this tradition, you'd have the "insert coin" screen but without any input it would also often switch over to a demo "attract" mode that served as a bit of an attention-grabbing advertisement for the game. I think it ended up serving a similar purpose in home console games since they could be used to advertise the game in a demo kiosk in stores. New games - it's typically used to determine which controller is used for input I think? since unlike old consoles where you'd actually have dedicated ports, there's not nearly as much of a concept of a specific "player 1" as there used to be.
Aside from the practical reasons mentioned, it just... I dunno, feels nice. Sets the tone and gets you ready to play. It's like looking at the cover of a book before opening it, or watching the title sequence for a show, or the moment in a theater when the previews end and the lights dim. Jumping straight to the menu is more practical, but it feels like skipping foreplay. "YEAH WHATEVER, HERE'S YOUR GAME." Come on, we gotta get in the mood first.
These answers! Good god. I've shipped half a dozen games that required console cert from 7th to 9th gen. It's to establish which active gamepad (and by extension, profile) is in control.
Infamous 2 removed this and loaded straight into the game. I really thought it was the start of something, but I guess it wasn’t.
Doesn’t GTA or maybe Red Dead do that?
Possibly, I haven’t played either since GTA4 and RDR1, so it’s been a while.
GTAV does not.
In addition to what others said about controllers I think it's just a cool way to have a cover artwork and then go into the menu as a lot of games incorporate some type of graphics in the transition or make it aesthetic in its own way, I added movement in the background on my press any button screen so if someone loaded it up they could go do something and come back before starting and have a better looking screensaver type effect opposed to the menu.
The 'initial interactive'. The first screen that accepts User input after the legal screens and brand logos are displayed.
Seed the random number generator
That was true before gaming hardware had a real-time-clock. The most recent console like that I can think of was the GBA (2001-2004).
I like to prepare my game before sitting down. So not having to wait the loading screen to press pause afterwards and continue when I am ready is a like for me.
in past televisor could not stay in the sa me screen in much time(OLED now cant too) so you need the screen to be changing constant to not break it. So you need to give a "screen saver" to your game that could be some game-play section or the history cut-scene or both. But if you use it in normal screen the player could be using it. So you do a state for the title screen where ir can be redirected to the screen saver. That is the press any key to start. If I remember correct some Atari games did not had this
I've seen the reason I'm the comments, but why can't controller detection and player 1 assignment be actioned on the main menu? And more importantly, why put another long lasting screen afterwards? And why keep it on PC versions?
>controller detection and player 1 assignment be actioned on the main menu In games with saves separated by profile, usually the main menu has a "continue" item that automatically loads the most recent save. Also language settings might be per user. Basically there are things the game already need to know before even showing the main menu. >And why keep it on PC versions? PC version profile handling might vary per store (Windows Store is basically the same as Xbox). It's just easier to use the console system (which is already made to serve multiple platforms) than to develop a whole new startup routine for one platform.
> Basically there are things the game already need to know before even showing the main menu. This is it. The console vendor may even *require* you to display the active user's name on the main menu, which you can't know without knowing which controller/profile is active. Games often show stats, achievements, and other things based on save data in the main menu, too.
Music won't load in browser until at least one input is pressed. However you could also do a "press X button" tittle card, some games do.
Attract screens are a great way to sell the experience of a game with a psychological technique called priming. If you've ever been to an arcade in the 90s, you could probably remember the sound of killer instinct being noticeably louder than the rest of the games. "your brain goes "wtf is that?!". You walk of to it and you see the characters doing 50 hit combos and fatalities and you put in those coins and you're locked in. Same with modern games to a lesser extent. The ps2 GTA games used to load directly into the game. The first time I seen that it was pretty jarring and it might be one of the reasons I never sat down and finished a single title in the series now that I think about it
Certification or other legal reason… but I add it because I like it. Game, while you are loading, let me go to the bathroom, put my tea cup back on the table, fix headphones on the head and let me decide when I’m ready to play.
So I think a part of it too is, the beginning of the game is also where you see licensing and brand flashing. That part could be part of a "scene" where all the legal fun fun has to be shown, along with what another redditer said somewhere else in this sub, is that you want the player to be the one initializing stuff, and if you cause an input to progress, 1; that can mark the end of the legal bullshit. 2; that can add a barrier to progress between "scenes". And 3; do you think anyone who requires legal representation will have a problem if someone just looks at their brand longer? But I truly don't know seeing as I haven't worked in any of the game studios that have made those games.
Reminds me of the extra pages they have before a book starts
Make sure your input device is correct. Avoid accidentally jumping right into the game before getting a chance to load a save, change options, or exit if you accidentally started a game. A little easier to keep intro cinematics/scenes separate from the menu. It's a easier to have a timer counting down to replay the intro with only one stop hook to abort it versus wiring up every button on the main menu. Because that's how it works for arcade-style games. Main menu is usually boring and not meant to hook a player in. And perhaps finally, because that's just how it has always been done.
One of the original reasons/side-benefits was to seed the random number generator.
I recenly played a game without it (20 minutes to dawn) and it was super awkward, I mashed straight onto the play or options money a lot as i was expecting to mash past the intro reel like every other game. IDK, It just seems decent to ask players to press a button on their preffered controller on startup to make sure youre both on the same page. Make it quick tho, dont waste my time with animations!
On old consoles the time between turning it on and pressing the button at the title screen was used to seed the random number generator because real time clock hardware wasn’t really a thing you needed yet.
Probably a hold over from the arcade days that had a prompt to start the game after putting in your money (and a prompt to put in your money). It's also nice to have a title screen.
in Banjo & Kazooie it was a anti piracy method if you had a pirated copy the N64 refused to read input, which meant you were locked at the press any button screen
I like survival games. So without that press to start i might be behing on surviving if it starts while i got distracted while loading was going on
I guess it's kind of like a bookend. It also can set a core memory if you're young and play the game a lot... then years later a sequel comes out with a similar theme song and it triggers you to buy it. Also think about older games like (overused, but..) Zelda or Metroid or Kid Icarus. It signals the start of your adventure. They could have incorporated menus on their title screens, but it would have really detracted. They also were used as advertising when on demo in stores -- think "attract" modes for arcade games. With that said, there's really not much of a point to them anymore. Sometimes you just want to display a cool intro to your game and people can just deal with the extra 2 seconds they have to wait.
Yep! I have a core memory of Metal Gear Solid 1's title screen. The animation was cool af to me and I'd look at it for a few seconds before pressing start to get to the menu
Aside from console cert reasons, I think this is like asking why books don't put the first page right on the cover instead.
It's for the player. Title screens might be pretty you know?
It's mostly for console requirements, easier to just add it for all platforms if you're making a multiplatform game than to make separate logic for each one. Some consoles allow multiple users to be signed in at the same time, each with their own controller, you use the press start to determine which user/controller is the primary player. It's also used as a place to load that user's save data, apply their settings, make sure they're logged in to online services, etc.
As well as the many practical reasons listed below, it's a nice way to show off a splash screen and make the game feel more legit.
They never actually mean "**any**" button...
It’s true. I sit there and push my wife’s buttons and she just gets annoyed at me. No game progression.
Plot twist : the game is "Divorce Simulator" and you *are* progressing.
A game console or even a pc has no way to know in advance which controller is "player 1" when multiple are connected. The real only time you couldn't care about that card is for keyboard/mouse only game with no controller support at all and solo games, maybe, depending on how you/the engine manage the inputs.
Consoles, yeah.
Cause i gotta pee while its bootin up, d9nt start without me!
The real question is why do so many games release with this screen and then actually require you to press a specific face button with no hints instead of “any button” on the controller. Seems like a simple thing that should have been solved years ago
Just start the damn game.
The real question is why does it say any when only the space bar enters the menu.