Talk:Ragnarock/@comment-110.142.176.178-20131228020619/@comment-1321146-20140101071800

Drecom isn't a startup company. They're a rather succesful japanese company. They've been at this a while. So, as you point out, of course they have a plan for quality control. But no plan can take every possible occurance into consideration. You know this, because you've seen tons of companies be surprised/make mistakes/fail in some way.

It may just be that this issue hasn't been a problem before. It's not cost-effective to spend resources on monitoring something you don't have a good reason to suspect will happen. And it definitely isn't cost-effective to monitor for anything-that-might-happen.

No company does that. They react if and when the unforseen does happen. This is true for every company from Mobage to Blizzard. From Intel to Ford, for that matter. For a reason.

Conspiracy theories aren't interesting to me. If you want to think that they know about things and aren't doing something, then you go right ahead. They have already addressed several issues, and in time will probably address this as well. No company can come up with a bug fix at the snap of your fingers. You also cannot count the time from when you notice the bug. Only from the time the company becomes fully aware of it, which is after they have tested it fully, which again is some time after it has been brought to their attention, which again is some time after someone starts abusing it.

Yes, the game becomes more complicated, as more and more is added, and changes are made to existing code. The alternative is to increase the time between each event, or to have no evolution in the events (including no bug fixing), or to make the events MUCH simpler and more boring. And even then, you cannot protect yourself against things like the proxy-method.

As one of the largest companies in the business (Blizzard Entertainment) puts it: "You can't just throw money at the problem". Hiring more people wouldn't help. If the person making bug fixes in the code isn't the same person who wrote that code, you're only asking for more bugs unless you allow that person to be very thorough.

So - You have to accept that there ARE only two options, whether you like them or not:
 * A. Have the developer check his own code, slowing down the creation of new content.
 * B. Have another person go through it thoroughly, slowing down the fixing of bugs.

Flags are used to decide whether there is an event running, that modifies the effect of a card. It's the simplest way to program for Event Specialists.

As for noticing that some people are questing faster than others, they wouldn't notice that in the logs unless they looked for that specific condition in them. The timestamp for one "Begin Quest 32-5"-action would have to be compared with the timestamp for the next, etc.

Now, if someone would feed them with examples of who does this, it would allow them to see the problem. If you just complain about the fact that people are doing it, it doesn't help them a whole lot. - And even when they've become aware of the fact, it will take time for them to figure out how it's done, what is required to allow it to occur, and find a way to prevent issues, that aren't directly caused by bugs in their code, such as the multiple-device-method and the proxy-method.

Again: No company has people sit around monitoring the logs live. It isn't cost-effective. They react after something has been brought to their attention (a proper bug report should include player names, (preferably exact) time-stamps, and a fulfilling description of the actions made as well as the results of the actions and how they differ from the intented.

Unfortunately, most people just go "GODDAMIT!!1! FIX UR GAME PB IS CHEATING ILL QUIT IF U DONT DO SOMETING NOW!!!11!!" - Or don't bother, thinking that the company will magically discover that something is up, or that complaining on a forum monitored by a single employee tasked only with deleting spam and foul language, and NOT with forwarding information to the developers, will somehow be enough.