Where do you draw the line between "weird edgecase of the

A glitch is something that occurs outside of what is intended. It's an abnormailty. Your Mario example is interesting and odd, but the game is working as it was designed to, so it's not a glitch.

>>3176347
mario is designed to work like that so its not a bug, just weird programming. A bug is something like certain Final Fantasy 1 spells just not fucking working.

>>3176373
One might say the same for all the weird wall jumps and passing through walls and stuff but that seems a little murkier.

>>3176373
>>3176376
See, just because it's legal by the rules of the game doesn't mean it was intended. Since you can't do this in the Mario 3 engine, that implies that the designers didn't you to be able to do that. If that's the case, then it was programming-related design oversight. That sounds like a glitch to me.

On the other hand, it's clearly not caused by because of integer overflow, a typo in the source code, or anything we normally associated with a glitch, but neither is the wall jump.

>>3176451
Exactly. Why would we consider wall jumping a glitch but stomping from below not a glitch? Is it because wall jumping is just weirder? If we're going to get that subjective, then where do we draw the line?

I don't see any line between "weird edgecase" and "glitch." In either case, you have code doing something not intended by the programmer. In this case, I'm sure they did not intend for mario to be able to be hit from above as long as he was moving down, this sounds like the consequence of a shortcut in the code. Actually computing if Mario is right above the enemy and his feet land on the enemy's head is much more complicated than checking if mario is in a falling state and if he and the enemy make contact, so they took a shortcut to help the game's performance.

The definition of "bug" is very general, but I would categorize any "oddity" or "abnormality" or anything else that's been discussed in this thread a bug. It's just an imperfect implementation of code.

>>3176493
CISscum here

There is a big difference between a code bug and a design bug. Before a (good) programmer starts typing in code, they draw out a diagram or a flowchart that shows what they want their code to do. Then they start writing the code itself in the programming language. These measures provide focus and help minimize mistakes.

However, mistakes do still happen, both in the process of designing and writing the code. Depending on the language used, the mistakes during the latter may not be that much of an issue -- Java, for example, is very bitchy about what you can do with it. In C, on the other hand, everything you do is at your own risk.

Both design errors and code errors can have strange effects. Coding errors are the ones that are more often called "glitches", whereas design errors tend to be called "oversights" instead. "Bug" can refer to either. Of course, to the end user, it doesn't make much difference.

>>3176464
>just because it's legal by the rules of the game doesn't mean it was intended.

Cheers. I work in videogame QA and every fucking day I have to repeat this same shit to somebody trying to justify exploits as a playstyle.

Just because something is engine-legal, doesn't mean the devs intended or endorse it, it might just be impossible to patch out without breaking the game.

>>3176373
So according to your definition, glitches don't exist, unless you intentionally fuck up the physical support of the game to not read data properly.

>>3176647
In multiplayer games especially this is a big deal. In some genres of game, like roguelikes and metroidvania, taking advantage of things the designer never thought of is actually a big part of high-level play, and the designer's job is to only remove the really easy and really game-breaking ones. In roguelikes in particular, the game itself will do things the designers never dreamed of.

It's fallacious to try to say that it's some sort of moral failing on the player's part if they try to play the game in a way the designers didn't intend it to be played, but it's equally fallacious to say that the player's best possible experience with the game is always off the railroad tracks.

>>3176693
Yeah, absolutely.
I know people who try to justify spawn camping as a legitimate playstyle. Life is suffering. Play videogames as a job, they said.

File: 1435121162948.png (62KB, 382x395px) Image search: [Google]

62KB, 382x395px

>>3176702
>spawn camping
>legitimate playstyle
Are you fucking kidding me. That's not just breaking the game anymore; that's being a poor sport.

Did they completely disable the ability to fuck with Mario's face on the VC version? If so thats fucking lame as hell.. I keep trying to do it but it doesn't work like the original, unless its just a crappy inaccurate ROM

>>3176567
I didn't mean to imply that bugs are all the same. In fact, I meant to say that every bug is unique, both in their source and in their effect. As for the Mario thing, they just used a heuristic solution. They might have even realized this glitch could happen, but decided to leave it as it was because it's too computationally expensive to do it accurately, and the glitch isn't really that bad.

>>3176347
You draw the line wherever your definitions of the two differentiate them. It's much easier to say if a behavior was intended it's not a glitch and everything else is a glitch. Then it's just a question of whether the glitch matters at all or a lot.

>>3176347
>draw the line
I don't. The game itself is the infallible oracle on what is allowed. This also means that if the game relies on dynamically linked libraries like the C standard library and does not bind them to a specific version, the player is allowed to switch to another contract-conforming library that might violate some of the invariants falsely assumed by the developers. My malloc initializes with 0xff and if that allows me to get more hit points, so be it.

>>3178138
>The game itself is the infallible oracle on what is allowed
kind of disrespectful towards the designer

>>3178138
If that's the case, then you're playing a very different game from the game the designers designed. It might be the game they coded, but it isn't the one they designed. The question you should then ask is, "Which game is more fun?" If the game the designers designed, i.e. the game played without jumping through major hoops to change how it functions from what the designers expected, is more fun, then you should play that game. If the game designers are half-good, then there's a decent chance that that game will be more fun if you play by the rules they designed, not by the rules they coded.

>>3178143
Not him, but I believe strongly in applying Death of the Author to most literary critique and see no reason that shouldn't apply to videogames.

>>3180225
fair enough, I strongly oppose it

>>3176373
Working as "designed to" (i.e; coded), but not working as intended.

File: postmodernism2.png (184KB, 547x323px) Image search: [Google]

184KB, 547x323px

>>3180225
The Death of the Author is a useful concept, but it makes the assumption that abstraction always loses something. The fact that the glyphs and phonemes that comprise a word do not inherently contain meaning, neither on their own nor in combination, does not mean that you cannot use that word to express complex concepts and thus connect intellectually with other people.

Take the word "ball" for example. It may not contain meaning on its own, but it is still used as an abstraction of a clear concept. When you hear the word "ball", something comes to mind, and to most English speakers, a similar thing comes to mind: you think of a spherical object, possibly to be used in the playing of a physical game. With context, complex concepts can be communicated -- you can use words to convey information to someone that allows them, and many other people who have heard those words, to play a complex game with one another based on a common understanding of those words! If words were truly meaningless, such a thing would be impossible.

We can extend this idea to games by thinking of the designer's intended rules and the rules they ended up coding. By interpreting the symbols, words, and patterns on the screen, the player can infer with a reasonable degree of accuracy how the designers intended their interactive world they have created. If you could not infer this, games would be unplayable. You wouldn't know that Mario was a person representing you, who will be hurt if he touches certain moving objects, which themselves represent other creatures in the world, which can be safely defeated by jumping on them.

Yet, because the designers are human, through human error they end up representing something slightly different from what they imagined. If the game is well-made, it should be relatively easy to play the game in the way the designers intended. It's foolish to adhere strictly to what the designers imagined, but it's equally foolish to reject that vision altogether.

>>3180869
What about non-human players?
Deepmind's AI didn't need any context to play a bunch of Atari games.

>>3180886
They play it as >>3180225 and >>3178138 described

>>3176347
> Where do you draw the line between "weird edgecase of the game system" and "glitch"?
Everything that is not intended, BUT is harder to master and/or perform than the intended way IS NOT a glitch.
Everything that is not intended, AND is easier to master and/or perform than the intended way IS a glitch.

Both of the cases are BUGS, but not GLITCHES.

Glitches by my personal definition (>inb4 "personal definition") are bugs that make the gameplay easier for the player. If you exploit the bug, but in the process show the better mastery and/or performance of the game mechanics than the intended way (i.e. it's harder to pull off than the intended way and the "usefulness:difficulty" ratio is skewed towards difficulty), then it's not a glitch.

>>3180912
nice inb4allacy

>>3180912
What you're describing as a glitch is more commonly called an "exploit".

If as the programmer you didn't know about a deviation from spec then it's a bug. If you did know but didn't fix it, it's a feature.

>>3176706
> That's not just breaking the game anymore;
It's not breaking the game at all. But it is being a poor sport. But it is a legitimate strategy. Those two aren't mutually exclusive.
The problem isn't that the player broke the game, the problem is the game itself is broken and worse for it (possibly even a bad game). A good game should be difficult if not impossible to spawn camp.
If multiplayer is sole function or large function of the game, not getting that right is literally one of the biggest fuck ups you can make. Multiplayer has key fundamental concepts for competition and being able to spawn into the competitive area in a way that lets you actually play the game is one of them.
When multiplayer is kind of tacked onto an otherwise solid singleplayer experience, well that sucks but multiplay was never the real intention so it's kind of forgivable that the multiplayer portion is broken. It's a novelty at best and dead.