Dev Harassment is concerning

[EaraGrace]

Sure, it's a domino effect. Valid criticism is perfectly fine, sending death threats to anybody, let alone the developers, is not. Just shows how people really are in this so called "wholesome" community in this game. It's hypocritical.

Not to mention it drags down valid criticism. The housing situation is a mess. But the devs know it, and are actively working to fix the problem as they should!

Death threats meanwhile hurt everyone. The players who are shit out of luck and the devs.

[Kuya420]

Not to mention it drags down valid criticism. The housing situation is a mess. But the devs know it, and are actively working to fix the problem as they should!

Death threats meanwhile hurt everyone. The players who are shit out of luck and the devs.

my (at least to me) valid criticism is this shouldve been tested thoroughly before being made live, maybe they didnt have enough time and were under the gun with pushing back the release of EW, and didnt wanna be compared to WoW with pushing back release after release, and thats fair, but the opposite is also true, we'd rather have things working as intended than things rushed out before they are 100% ready, right?

there are those saying there should be rollbacks and no, that will anger those that actually did win, others saying we should go the way of other mmos with instanced housing, to those i say if you want that play those, the reason housing is the way it is here is for the neighborhood/community feel so people interact more and more outside of dungeons/raids

what i think would be the best is just to unlock the fc wards after fixing the bug an let those that didnt get houses (and maybe have 8-12 wards or so still restricted to FC for any possible FCs that were locked out) in the end there really arent enough plots to meet the demand, and they know it, so we will likely see another increase in over all wards at a later date, whether it will be lottery or the old system is up for debate

[Broken_Wind]

my (at least to me) valid criticism is this shouldve been tested thoroughly before being made live

The thing is, none of us know this wasn't the case
I 100% understand why people jump to this conclusion, as it seems like this is something that should not have happened

But it is possible to thoroughly test something only to have a completely unforeseen thing come along

As far as MMORPGs go, FFXIV is not typically a game prone to major bugs. While its entirely possible that something slipped by that should have been caught with an appropriate amount of testing, there isn't concrete evidence of this.

And even if it is the case, if they properly fix it, give people their right lottery results, and most importantly ensure this isnt a pattern of severe bugs then its not a big deal.

[Packetdancer]

But it is possible to thoroughly test something only to have a completely unforeseen thing come along

Especially for games (and software in general).

As I've noted elsewhere, there's more than one way to test something. Game companies -- and really, many software companies in general -- tend more towards the QA methodology where you go "Okay, we've finished feature X, we should make sure that it works when you do what's expected." You'll try different ways to do X (hence the old joke about "A QA tester walks into a bar. Runs into a bar. Walks into a bar backwards. Skips into a bar. Crawls into a bar. Dances into a bar..."), but the goal of the testing is to make sure that Feature X works when you do the things that are expected to make it work.

The other approach, however, is to make sure that feature X does not fail. That may sound subtle, but it's very, very different. (And also a lot more work.)

To use an analogy, let's pretend you want to make a cake. The software QA approach is generally going to be something like "I have a recipe here. If I follow the directions, do I end up with a cake at the end?" as a baseline, and then trying a few other approaches that should hypothetically still work. Sometimes they work ("Used egg substitute, still produced cake."), sometimes not ("Used Splenda instead of sugar. Instead of cake, produced aardvark. Which exploded. Please fix.").

The test engineering approach is going to be where you have a massive list of things, many of which by rights should not affect the cake outcome. ("Time of day: morning, evening, night." "Stove type: gas, electric, inductive." "Other appliances powered: refrigerator, toaster oven, microwave." Etc.) Then you go through and try all the possible combinations to make sure that nothing goes wrong with the cake-production recipe in any of those states. This can be a lot of work, which is part of where a good SDET -- Software Developer/Design Engineer in Test -- is invaluable, as they come up with ingenious ways to automate these tests. To test the durability piece of hardware at work some years back, one of our test engineers made a literal foot robot that stomped on the design to see if it broke within X number of stomps. (It was not a quiet robot. The robot eventually got to live in a closet with some soundproofing so that it could stomp as much as its little silicon heart desired without the humans in the area wanting to stomp on it in return.)

The thing is, though, many systems are big, and complicated, and those features that shouldn't affect the cake sometimes do.

For games and desktop software, doing full test engineering is probably overkill; it would take a ton of time, and a lot of software development has the mindset of "move fast and break things" -- i.e., come up with neat stuff and fix it afterwards. Doing a thorough test engineering approach would require locking down a system's design much earlier so that you can come up with your comprehensive test plan before you have stuff to test. And if a feature fails in a game, the worst that happens (usually) is some players are inconvenienced and upset, or you get the public relations equivalent of a black eye when you completely f@$k up a release. Conversely, with mission-critical stuff, testing can be crucial; if someone lets a bug slip through on an ATM, people can lose money. If they let a bug slip through on a diving rebreather or a medical device or an automobile drive system, people can literally die. (I'm not joking; it happens.)

When you test to see if a thing works, it's much easier to check it off a list... but it's also a lot easier to encounter situations where something that you wouldn't think would affect a system causes it to break afterwards. Like if you test the controller code for your game, and it works on every test machine you have with every input device you have. Yay! Then someone else on the game team comes back and goes "Uh, my controller works in the test program, but does not work as soon as I start playing." And you go, "Huh. Do you have two controllers plugged in?" Nope, they do not. "Does it show up fine in other software?" Yep, it does. This works for everyone else working on the game, so what could be wrong? And then you find out they once had a Razer Tartarus MMO keypad installed, which happened to have a joystick on it, and that for some reason their system was borked and the Tartarus driver was still active and creating a gamepad entry that always took XINPUT (Windows game controller input system) device slot 0... and that your code was taking the first enumerated XINPUT device, not the first connected enumerated XINPUT device. Since generally, when a thing is disconnected it's no longer enumerated by XINPUT, the two scenarios seemed to be the same... but it turns out, they were in fact not.

(This is not strictly a hypothetical example; the XINPUT issue is in Unreal Engine 5's input library, and I was the person pulling my hair out about why my controller did not work when I was running the game within the dev environment, while literally everyone else in the Unreal developer groups I belong to was like "I ran your code to test, it works for me?" It turns out when Unreal says the play-in-editor mode uses "the first controller" it is very literal, and does not mean "the first connected and available controller.")

There are many, many possible ways things could go wrong in a codebase the size of an MMO, especially since almost no MMO system operates in a complete vacuum; it needs data from other systems, or pulls state from somewhere else, or relies on a utility library someone else wrote into the codebase 7 years ago or whatever else. Heck, there are many, many ways a thing can go wrong just in the game engine something uses, even without adding in the game-specific code. (Do not start me on Unreal 5. I like it much better than Unreal 4, but I have questions about how some things got through QA to the final 5.0 release we just got the other week.)

This doesn't excuse things; few things are absolute, and there absolutely is a middle ground to be found between "just test to make sure a thing works" and "perform comprehensive testing to make sure a thing does not fail". And a big, hotly-debated system that was going to have immediate heavy participation and people watching closely to see how well it worked... well, that's the sort of thing that probably should've had a rigor to the testing that fell somewhere in that middle ground. (Few game companies would do that even for big systems -- and I'm guessing SQEX is no exception -- but that doesn't change the fact that I think they should have.)

I don't think this is a failure on the part of the actual developers, per se. Everyone makes mistakes, and while we can all theorize at what the root cause of this (admittedly spectacular) issue was, none of us actually know. It could've been a typo by a tired programmer, or it could have been a bit of unexpected behavior three systems down in code written by someone who burned out and left the company during Heavensward, or a weird edge case involving database locking, or... *gestures vaguely* But I do think it's a failure of process, because while everyone makes mistakes sometimes, when the process works, those mistakes get caught. Even if I think it's not SQEX specifically but game development (and honestly, software development in general) that are failed by the "test for success" versus "test to ensure no failure" mindsets.

¯\_(ツ)_/¯

None of which changes the fact that folks have a right to be upset and/or irritated. Or to press SQEX to explain how this happened for the sake of transparency -- and because a post-mortem write-up of what went wrong can be of benefit to their own process -- or even to unsubscribe if they feel it was the last straw in their trust of the company.

[TaleraRistain]

The thing is, none of us know this wasn't the case
I 100% understand why people jump to this conclusion, as it seems like this is something that should not have happened

But it is possible to thoroughly test something only to have a completely unforeseen thing come along

As far as MMORPGs go, FFXIV is not typically a game prone to major bugs. While its entirely possible that something slipped by that should have been caught with an appropriate amount of testing, there isn't concrete evidence of this.

And even if it is the case, if they properly fix it, give people their right lottery results, and most importantly ensure this isnt a pattern of severe bugs then its not a big deal.

Most of the people I see jumping to this conclusion are assuming 1) the lottery is running on some general random number generator and 2) that the random number generation is the issue. When they mentioned patterns to the lottery in their system, that made me consider it's probably not some general system and when you make things more complex, more things can break. But people are happy to call the devs idiots and scoff that it's elementary level programming when they haven't even seen the code or what the code has to communicate with. Because that's the other half. The problem may not be in the lottery at all, but what the lottery code is touching. And like you said, you can test everything you can think of and still have something happen when it's in the production environment. We'll probably never get the full extent, but they do try to walk us through the layman's explanation when they have it. They just need time to figure that out.