It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
I was just watching some videos of a troll level in Super Mario Maker 2 that had intentional hardlocks. That is, the game froze, and the player had to quit out of the game. Can you think of a situation where an intentional hardlock like that would be justified?

A hardlock is when a game (or other piece of software) locks up in a manner that no input is recognized, at all, and you have to force quit the game. (In Windows, this would mean opening the task manager and force closing the game; on Linux this is when you need to send SIGKILL to the game.) A kernel hardlock is also possible, in which case it's necessary to hold the power button in to force a power down, or if that doesn't work, pull the plug and disconnect the battery (if there is one). (Note that a kernel hardlock likely indicates either a kernel bug or a hardware issue.)
Only if it immediately fallowed an auto-save. And either in response to the game running for long enough that the player might be sleep-deprived, or a Kojima-style 4th-wall break, like maybe the story takes a Call of Duty-style twist and your character dies in that moment. So when you next boot up, you continue the story with a new character, either previously established or custom-made like the predecessor.
The only thing that occurs to me, is when there is a possibility of damage to the user's hardware or files.

Aside from that, there should always be some kind of accompanying notification with an explanation.
avatar
LegoDnD: Only if it immediately fallowed an auto-save. And either in response to the game running for long enough that the player might be sleep-deprived, or a Kojima-style 4th-wall break, like maybe the story takes a Call of Duty-style twist and your character dies in that moment. So when you next boot up, you continue the story with a new character, either previously established or custom-made like the predecessor.
There are other ways to get the same effect without a hardlock:
* Have the game abruptly quit, as though it had crashed. Alternatively, have the game intentionally crash. (This isn't an option on older consoles, and I think recent console policies might disallow this.)
* Have the game suddenly restart, from the title screen. (I believe this is how some older consoles would handle a crash, like in Final Fantasy 2 Advance (IIRC) if you somehow won the first battle (via cheating).)
* Put in an intentional softlock. This could even be something that looks like an intentional hardlock, except that you would be able to access the menu that would allow you to quit the game (though, of course, one could make there be something *different* about the menu, like that Fission Mailed screen I've heard about).
avatar
Timboli: The only thing that occurs to me, is when there is a possibility of damage to the user's hardware or files.

Aside from that, there should always be some kind of accompanying notification with an explanation.
In that case, I think a crash would be the more appropriate choice. (Or a kernel panic, if this happens at the kernel level.)
Post edited January 19, 2023 by dtgreene
No? Have we run out of topics to discuss that we have to ask if forcing a game to shit itself is in anyway justified?

Though this does remind me of a video of Little Big Planet 3 I think where there's user levels that corrupt your game, or crashes it, or otherwise straight up messes with the experience outside the level. Which makes me the think of the times where my character was straight up unable to do anything in VtMR multiplayer and this persisted across multiple game sessions and the only fix was to make a new character because the jerks running the game room made it so.
avatar
dtgreene: I was just watching some videos of a troll level in Super Mario Maker 2 that had intentional hardlocks. That is, the game froze, and the player had to quit out of the game. Can you think of a situation where an intentional hardlock like that would be justified?

A hardlock is when a game (or other piece of software) locks up in a manner that no input is recognized, at all, and you have to force quit the game. (In Windows, this would mean opening the task manager and force closing the game; on Linux this is when you need to send SIGKILL to the game.) A kernel hardlock is also possible, in which case it's necessary to hold the power button in to force a power down, or if that doesn't work, pull the plug and disconnect the battery (if there is one). (Note that a kernel hardlock likely indicates either a kernel bug or a hardware issue.)
Maybe as a concept for a joke in a quirky game (the game would have to set this up for it to be funny). That's it.

I can't see any other situation where that would be remotely justifiable (concerning Timboli's suggestion about preventing damage to hardware, that's what the OS is for, it is not the responsibility of userland software to do such things).

And even in the above case, I'm not entirely sure it would be well received by a majority of players, though I could totally someone who is doing a not for profit art piece doing it.
Post edited January 19, 2023 by Magnitus
I could see it for a psychological horror type of game, if the hardlock is solved after restarting the game and it acknowledges that it was messing with you.

Not that it would be good design, but it would make its own kind of jump scare.
avatar
ConsulCaesar: I could see it for a psychological horror type of game, if the hardlock is solved after restarting the game and it acknowledges that it was messing with you.

Not that it would be good design, but it would make its own kind of jump scare.
An MS-DOS user would "solve" the problem w/ Ctrl-Alt-Del to manually reboot the system. The old ways never go out of fashion.
Post edited January 19, 2023 by KeoniBoy
avatar
Warloch_Ahead: No? Have we run out of topics to discuss that we have to ask if forcing a game to shit itself is in anyway justified?

Though this does remind me of a video of Little Big Planet 3 I think where there's user levels that corrupt your game, or crashes it, or otherwise straight up messes with the experience outside the level. Which makes me the think of the times where my character was straight up unable to do anything in VtMR multiplayer and this persisted across multiple game sessions and the only fix was to make a new character because the jerks running the game room made it so.
Or VVVVVV. If you have 2.2 or earlier, it's possible to create a level that overwrites your main game save data (for example, by triggering the credits). Of course, one had to take advantage of a bug in the game, one that allows a custom level to inject internal scripting commands, but that bug is one that is actually widely used (and people have documented the commands available).

In 2.3, the code injection bug is still there (probably intentional at this point), but the commands that could cause serious issues were changed to not. (For example, a custom level can still trigger the credits, but doing so will not overwrite the player's main save.)

Worth noting that there was a huge time gap between 2.2 and 2.3, which I think may have been around a decade, and the game's source code was released before 2.3 came out.
avatar
ConsulCaesar: I could see it for a psychological horror type of game, if the hardlock is solved after restarting the game and it acknowledges that it was messing with you.

Not that it would be good design, but it would make its own kind of jump scare.
avatar
KeoniBoy: An MS-DOS user would "solve" the problem w/ Ctrl-Alt-Del to manually reboot the system. The old ways never go out of fashion.
Unless the game overwrote the associated interrupt handler, causing ctrl-alt-delete to fail to work. (Or the computer somehow locks up so hard that even ctrl-alt-delete doesn't work.)
Post edited January 19, 2023 by dtgreene
Plain and simple: No.
avatar
dtgreene: Can you think of a situation where an intentional hardlock like that would be justified?
No and a developer who does that should be avoided.
avatar
Magnitus: concerning Timboli's suggestion about preventing damage to hardware, that's what the OS is for, it is not the responsibility of userland software to do such things
I did not mean it in that context, but something that is coded into the game to keep an eye on things so-to-speak ... to not overwrite or delete something or even just react to a rising temperature, memory issue etc. All highly unlikely, but only thing that makes any kind of sense, and I say that very reservedly.
Wtf? Hell no. Not even in that psychological horror example mentioned above. Pretend to damage or lose saves, maybe. Pretend to damage system or other files, at a real stretch, maybe, in games intended to be really, really frightening in a 4th wall breaking way. Actually do either of those? Absolutely not. And also obviously absolutely not, in no way, shape or form, under any circumstances, go past that and do something that may cause actual freezes, require reboots or worse, hard resets, or even application kills, which for less knowledgeable users may be the same thing if they don't know how to regain system control to do so. Not just that game, but anything else released by a developer doing that must be avoided.
avatar
Cavalary: Wtf? Hell no. Not even in that psychological horror example mentioned above. Pretend to damage or lose saves, maybe. Pretend to damage system or other files, at a real stretch, maybe, in games intended to be really, really frightening in a 4th wall breaking way. Actually do either of those? Absolutely not. [...]
This!
The only game that I played and that did stuff like that was Eternal Darkness - Sanity's Requiem.
And when it happened, it scared the shit out of me.
And there all the system failures were just fake. Not real. If it would have been real, and not just real, but deliberately done, I think, I would have gone on a little journey to tell some people what I think about such "funny stuff".
Post edited January 19, 2023 by BreOl72
Ordinary users probably won't know how to kill a process, and will press the reset button on their PC instead. This could result in data loss from unrelated applications, which is categorically unacceptable.