Topic: Major Switch games which haven't needed any updates or patches at all

@Polvasti I think the subtlety is that sometimes those are not small indie games not getting absolutely needed patches, sometimes (often) they are Nintendo or other major publishers 😆 I mentioned above Peach Showtime — sure, Switch has performance issues, but loading screens shouldn't look like janky PowerPoint slides, especially when there is an easy fix (static pictures during loading) which half of the game loading screens uses anyways. One simple patch would have significantly improved the game. That was clearly the 'don't care' camp. Bayonetta Origins is in that camp also, as is Kirby's Dream Buffet. Then there is the 'Publisher being actively antagonistic' camp — nsmbu deluxe is in that camp with a much-wanted controller change being hidden in a bizarre secret combination of buttons rather than in a visible option screen they could have easily added.

My point is, 'complete, flawless state' is much much rarer than not having a patch. Conversely, if a patch is only adding purely optional extra DLC content, the game may have been complete and flawless by itself but still gotten a patch.

That said, Kirby and the Forgotten Lands which you mentioned was a rare case where there was no patch and I don't recall anyone desperately begging for a patch for a legitimate reason.

What a coincidence that Sakurai's newest video talks about this very topic.

@BrazillianCara
lol yea, I thought that was kind of funny.

At the root of this, it's the nostalgia for a time when a game was released and it just... was. Because that's how it HAD to be on consoles. You couldn't connect your SNES to the internet to download a patch and fix a bug, much less get your horse armor until the Xbox 360 came around. (We all just HAD to have that horse armor lol...)

In a way, it was nice - it forced developers and publishers to be much more certain that their product was complete, working, and in a state ready to be shipped, reviewed, and (hopefully) be successful. BUT, it was also a time when games were smaller and simpler in all regards.

Nowadays, there is less pressure to make sure everything's buttoned tightly because you can hotfix stuff pretty easily, which is... "convenient," I suppose. But it does remove an element of discipline and quality control, if we're going to be real. And with these larger, more complicated games... it may be somewhat necessary unless we're willing to wait even longer for games to release.

It’s not as if old games were released perfect and glitch-free.

Any errors that couldn’t be fixed in time, and all the glitches that weren’t found before release, simply stayed there forever. Maybe a re-release would fix something later down the line, or if it was particularly bad they had to issue recalls.

—————

Anyway, Resident Evil Remake is on version 1.0 on the switch, in case that one counts for the list.

@FishyS I haven't played Peach Showtime but I remember Yoshi's Woolly World's loading screen stuttering despite being a very basic animation, as well as having a music track that was too short to fill the loading time but just faded out then restarted instead of looping seamlessly... So maybe Good Feel is just bad at loading screens

@rallydefault
You know, on one level I entirely get the nostalgia for games just being as they were on release. And I don't think it's anything at all to do with the quality of those releases, because in many cases they were not quality. I think when old games have had bugs over time we've kinda woven the bugs into the collective enjoyment of the game. The various glitches in the original Pokemon games for example. Or most of the tech in retro speed-running. Would watching the NES Tetris stuff going on lately be anywhere near as interesting without the glitched colours or crash screens? Almost surely not

But at the same time I think some people either only look at the "good" bugs/issues of older games or just colour everything with nostalgia goggles. Part of that is just that we tend to erase entirely games that were buggy messes from our collective memories. Like how everyone always talks about how music was better back in the day when, in reality, some of that is just because we only listen to old music that has remained relevant. But even with great games we paper over the cracks. I watch videos from a guy who since the Super Mario 64 decompile has made a project of optimising the game. He's managed to get the game engine to run significantly faster, with significantly more complex levels

Obviously, I doubt Nintendo would've done that much to Mario 64 if there was an option to do so back in the day. I'm also not saying that Mario 64 is a bad game. But the game shipped with debug flags on, it was hardly perfect. It was also not just an early N64 game it was THE early N64 game, it was a learning experience of a game. I think with Mario 64 there was enough left on the table that if it had been released today I'm fairly confident there would've been a performance patch similar to the one we got for BotW. One that would've maybe boosted it to a locked 30fps or something. That wouldn't have been a bad thing

But again, looping back, hard to say this in hindsight because of the nostalgia goggles. I wouldn't accept a version of Pokemon Red on NSO that took out Missingno. I find it hard to play C&C Generals on a modern PC because it just doesn't "feel right" when dropping a nuke doesn't tank the framerate. I'm sure some people would argue that the framerate tanking in Dire Dire Docks on Mario 64 is "part of the game" in the same way. And if patching wasn't an option today people 30 years from now probably would've been on forums like this arguing the same about item duplication bugs in TotK and the framerate dips in the release version of BotW

.... I understand both sides of the argument. I just think as a general rule it's probably a good thing that these things get patched out. Even if doing so inadvertently kills some of the bugs and stutters that might've become our friends. I also don't buy at all the argument that there's less quality control now because there is an ability to patch games post release. There's less pressure to get it "right" on day 1 for sure but..... in the long run I don't think the games we end up with are worse than what we used to get

@skywake
I think "quality" was higher for the casual player who wasn't actively looking for bugs and glitches and stuff or trying to break the game like we see speed runners doing (like SGDQ which is going on right now).

There were games, yes, that still shipped out that were buggy even for the casual player. But your average Joe can play through the original Pokemon games, Mario 64, etc. and probably not encounter a bug or glitch (I know I did as a kid).

I do think overall it's a good thing, but it does bring with it the propensity for a bit of laziness. It's kind of like back up cameras with cars: Overall, it's an excellent thing that cars are now mandated to have them, but those cameras do have the effect of making the driver a bit lazy and rely on it rather than still physically turning around and looking out the back of the car like we used to. It's a bit of a crutch, I guess I'm saying, to be able to easily patch games these days.

@rallydefault
Honestly I mostly just don't buy the "it makes devs lazy" bit. Mostly because as a developer (not of games mind you) I know what it's like to release a major version and also to release regular updates.

Our last major update had something like 6 months of development time plus around 3 months of user acceptance testing from our biggest clients. That was in addition to ongoing internal testing. The day that client upgrades? Suddenly 1000 users have their eyeballs on it and I find myself with maybe a dozen dev tickets to churn through. Ranging from "this warning should be more descriptive" and "when you have 5000 items this page is slow and appears to hang" to "when you add duplicate items it throws an exception"

So we bunker down and get through those as they come in. New minor release by the end of that week. Which includes some additional minor changes for things that were deemed by the client "not important". So something like 20 fixes all up

Does the ability to do this mean that we were lazy with the major release? I don't think so. We certainly used the fact that we could release an update to our advantage and there was generally an assumption that there probably would be one. But we aimed to release as good a product as we could

So yeah, I don't at all buy into the idea that the old "waterfall model" gave us higher quality releases. It just can't. Especially for more complicated software products. The more eyes on it the more stuff gets picked up. Especially when those eyes are from actual users actually using the software rather than testers pretending to be end users

@skywake
Honest question for you, then: How would the way you work on your products change if you knew you couldn't make changes to it after it released?

@rallydefault Although the question wasn't to me, I've been tangentially involved in development of products which couldn't get updates after release. The answer in that case was significantly slower and more expensive development which led to a more expensive product.

And when it turns out there was still a bug, you send usage guidance to avoid the bug which, ironically, might require the user to do some development rather than the product maker making a patch. If it had been a game I imagine that probably would have translated to 'don't do certain actions or your game will crash'.

Speaking of, I have so much less tolerance towards my game (or operating system or other product) crashing than I had when I was a kid. I would say crashes in all sorts of products are far less common now, presumably because automatic patches are so common now.

@rallydefault
As @FishyS said, significantly higher costs and slower development process. Mostly due to a significantly more bloated testing process and probably also more people to manage the additional people. Also I would think we would be more risk averse

I think the main killer would just be that people would just have to work around bugs and misunderstood requirements. We make enterprise software and we're also fairly small so it's not exactly the same. But oftentimes we'll pick up feature requests from clients or listen to feedback from support or sales and fold those things into a release. And the short minor release/patch cycle means it can be as little as a couple of weeks between feature request and a release. Lots of minor tweaks and changes

If there we had a single release cycle? It'd probably be a couple of years between every release. And we'd probably miss the mark in terms of what they end user actually wants far more often. Like trying to drive a huge truck vs a bike, much harder to make minor adjustments when driving a truck

@skywake
Interesting about the risk averse - the retro days of games were anything but risk averse (like NES, SNES era in particular I'm thinking of; there were some crazy ideas that went all the way back then lol)

@rallydefault I'm not sure if what you are describing is the same type of risk adverse. The job-related examples I have dealt with were risk-adverse in terms of engineering, not content. For example, not optimizing in a certain way because there is a possibility it would break for some users and the application would have no way to patch. So that doesn't change the main functionality, just the efficiency of the product. You can still be crazy in terms of ideas but conservative in terms of engineering. Fundamentally, whether or not there is a small bug is not going to be what makes or breaks a risky idea like e.g. virtual boy — it could have had the most conservative risk-adverse engineering and software design and it still would have tanked and it's not like a patch could have somehow helped that. Obviously there are exceptions if you have to really stress the hardware or codebase to even get e.g. a game to run - in those cases, sure, game idea might directly affect conservativeness of engineering.

@FishyS
Yep, I was talking more in terms of content and what companies thought would sell at the time. Which, in a way, can translate to game engines and stuff in the sense of reusing assets and engine or not. Like an Ocarina/Majora's Mask situation.

And... no longer 😆

@FishyS
And unsurprisingly in the comment section under that article there's someone complaining about it. How dare the developers be so lazy as to.... patch bugs you would've likely otherwise been unaware of

@skywake
Why patch these bugs that most people are unlikely to encounter?

@rallydefault
Given the very clear position the average person making that complaint is taking I'd suggest you step back for a second and maybe answer that question for yourself

@skywake
Uh... how about no? It's an honest quesiton and I want you to answer it.

These fixes are just minor grammar corrections in the dialogue and a couple small bugs that could have added to the speedrunning potential of the game, bugs that the average player doesn't encounter.

Why spend the time to patch them?

I suspect a lot of the issues were ones encountered when 100s of thousands of players suddenly started playing. Many average players likely ran into problems even if the majority was lucky and didn't run into errors. I think the majority can survive seeing the number 1.01 in exchange for the minority not suddenly running into annoying bugs.

Issues such as " controls would no longer respond properly sometimes after hitting an enemy with a hammer on the field" sounds like a legitimate problem, not a fun speed running quirk. I'm happy Nintendo fixes things like this personally-- I haven't bought the game yet and now my game is more likely to function when I do eventually play (I have the habit of playing games in weird ways so I think I run into more than my share of bugs).