Live data from Hacker News

Good software knows when to stop

ogirardot.writizzy.com

101–110 of 304 posts

Re: Good software knows when to stop

#101

> Ignore feature requests — don't build what users ask for; understand the underlying problem instead not quite in the same area, but this advice reminds me of blizzard and world of warcraft. for years and years, people requested a "classic" WoW (for non-players, the classic version is an almost bug-for-bug copy of the original 2004-2005 version of the game). for years and years, the reply from blizzard was "you thin…

But they didn't actually build WoW classic. They just built another version of the game. Gameplay wise it is drastically different. Economics & business wise it is very simple while it is popular: monetization.

>But they didn't actually build WoW classic. They just built another version of the game. Gameplay wise it is drastically different.

what?

i played vanilla in 2004, and i played classic when it released. your description is extremely inaccurate.

Re: Good software knows when to stop

#102
post #93
post #87

Earlier quoted context omitted.

Yea, good old days :) The catch was that old boxed software eventually breaks on new OS versions or devices. However, SaaS has the potential to "freeze" features while remaining functional 20+ years down the road. Behind the scenes, developers can update server dependencies and push minor fixes to ensure compatibility with new browsers and screen sizes. From the end-user's perspective, the product remains unchanged a…

My experience is actually the opposite. In the old days there was no expection when and if users would upgrade anything , so vendors had to take extra care to ensure compatibility or they would lose business. People in a single office could be running 6 different versions of Microsoft Office, and the same file had to be viewable and editable on all of them. A company could decide to upgrade to Office 2010 but stay on…

More like "you must be on the newest version of everything all the time, or you will get hacked".

Re: Good software knows when to stop

#103
post #83

Earlier quoted context omitted.

Arc Raiders and other involuntary pvp games will miss out on players like me who will not try it until pvp is optional and voluntary. Involuntary pvp is the long term death sentence for a game. It punishes new players by making them easy prey for veteran players. Player numbers will fall hard and fast, like every other involuntary pvp game does.

"I may play your game if you trim away a core appeal factor for the people who already play your game by splitting the active player base" is not that convincing a feature request to a gamedev. Many live service games that are punishing for new players are still thriving like LoL and DOTA2. Much that punish-factor can be resolved by good matchmaking, putting new players mostly with each other.

Plus, not every game needs to appeal to every player, which I think is where games like that eventually have their downfall. WoW was talked about earlier in the thread, and Blizzard continuously trying to make it appeal to other types of players is what kept killing it.

It's OK for a game to exclude entire demographics of players. A PvP first game shouldn't try to force itself to appeal to PvE only players.

Re: Good software knows when to stop

#104
post #83

Earlier quoted context omitted.

Arc Raiders and other involuntary pvp games will miss out on players like me who will not try it until pvp is optional and voluntary. Involuntary pvp is the long term death sentence for a game. It punishes new players by making them easy prey for veteran players. Player numbers will fall hard and fast, like every other involuntary pvp game does.

"I may play your game if you trim away a core appeal factor for the people who already play your game by splitting the active player base" is not that convincing a feature request to a gamedev. Many live service games that are punishing for new players are still thriving like LoL and DOTA2. Much that punish-factor can be resolved by good matchmaking, putting new players mostly with each other.

I thought the core appeal was the loot that you get from the PvE.

But I'm just an interested outsider, waiting for the crashing player numbers for the devs to come to their senses.

Re: Good software knows when to stop

#105
post #59

> Ignore feature requests — don't build what users ask for; understand the underlying problem instead not quite in the same area, but this advice reminds me of blizzard and world of warcraft. for years and years, people requested a "classic" WoW (for non-players, the classic version is an almost bug-for-bug copy of the original 2004-2005 version of the game). for years and years, the reply from blizzard was "you thin…

I have been in situations where a user makes a feature request and I don’t think it makes sense, but because they’ve been polite and understanding I decide to take the time to explain exactly why it wouldn’t work, but while doing so I basically rubber duck and come up with solutions to the problems I’m describing (which the user hasn’t foreseen yet). Sometimes that ends with me discovering yet even stronger reasons t…

Due to the XY problem what they ask for often isn’t what they need. And what they yell about won’t make them happy.

By and large I’ve gotten better feature requests out of looking at patterns of frequently asked questions and turning them into tasks instead of reacting to negative feedback.

Re: Good software knows when to stop

#106

Earlier quoted context omitted.

"I may play your game if you trim away a core appeal factor for the people who already play your game by splitting the active player base" is not that convincing a feature request to a gamedev. Many live service games that are punishing for new players are still thriving like LoL and DOTA2. Much that punish-factor can be resolved by good matchmaking, putting new players mostly with each other.

Plus, not every game needs to appeal to every player, which I think is where games like that eventually have their downfall. WoW was talked about earlier in the thread, and Blizzard continuously trying to make it appeal to other types of players is what kept killing it. It's OK for a game to exclude entire demographics of players. A PvP first game shouldn't try to force itself to appeal to PvE only players.

[deleted]

Re: Good software knows when to stop

#108
post #59

Earlier quoted context omitted.

I have been in situations where a user makes a feature request and I don’t think it makes sense, but because they’ve been polite and understanding I decide to take the time to explain exactly why it wouldn’t work, but while doing so I basically rubber duck and come up with solutions to the problems I’m describing (which the user hasn’t foreseen yet). Sometimes that ends with me discovering yet even stronger reasons t…

A variant of the first is the highly imaginative user who keeps coming up with new variations or expansions of their idea. It’s not malicious but it can be exhausting. Especially if you try to address their core need but their imagination doesn’t extend quite far enough to see how your effort would help, because they love their ideas.

I can imagine the kind of person you're describing, and I find the idea of the burn they get from reading this hilarious. They sound innocent and quirky.

Re: Good software knows when to stop

#109

> Ignore feature requests — don't build what users ask for; understand the underlying problem instead not quite in the same area, but this advice reminds me of blizzard and world of warcraft. for years and years, people requested a "classic" WoW (for non-players, the classic version is an almost bug-for-bug copy of the original 2004-2005 version of the game). for years and years, the reply from blizzard was "you thin…

To be fair on the Blizzard example, I think Blizzard could have also made the player base just as happy by, doing as your quote said, understanding the underlying problem. It wasn't only a "we want WoW classic bug for bug," it was "the modern game has become so unrecognizable that it's basically WoW 2.0, you ruined it with the modern systems" Blizzard could have rolled back LFR/LFG, class homogenization, brought back…

I spent some formative years helping people run MUDs and applying my pattern matching brain to the problem of how to make a multiplayer game succeed.

I played WoW precisely because they dodged the first bullet, which is inflationary or deflationary economies caused by each content creator trying to leave their mark by making better gear for their quests than are already available. The whole thing with used equipment only being for to be scrapped guaranteed that low level characters weren’t all carrying the third best helmet in the game.

But they still had the same problem with expansions - the need to change things in order to declare, “I made that”. They wouldn’t have needed classic if they followed your conclusions.

However, without those changes would they have stayed on everyone’s radar as long? Hard to say. Balancing in LoL and friends seems somewhat easier because the mechanics change less frequently. So maybe they would have been fine or maybe they’d be on WoW 2.0 now.

Re: Good software knows when to stop

#110
post #93

Earlier quoted context omitted.

My experience is actually the opposite. In the old days there was no expection when and if users would upgrade anything , so vendors had to take extra care to ensure compatibility or they would lose business. People in a single office could be running 6 different versions of Microsoft Office, and the same file had to be viewable and editable on all of them. A company could decide to upgrade to Office 2010 but stay on…

More like "you must be on the newest version of everything all the time, or you will get hacked".

Because security fixes don't get backported, when they could, and few are still doing separate security vs. feature updates.

Even Windows is doing it now with CUs, bundling feature & vulnerability patches together, then deprecating the last version. You don't have a choice anymore, it's "accept the features or else"

Post reply on HN