Discussion - IMPORTANT: Paragon Rewards Program Update - 9/12/2011

So you are completely familiar with the entire code base of the game, including the parts written in Visual Basic? Tell, me which particular programming language (of the 3 or 4 they mentioned) is the section dealing with the awarding of Reward Tokens written in? And how exactly does it interact with the sections dealing with badges and the various requirements for them being awarded? And which languages are those written in?

IOW:

Miss the part where I said "Overly simplistic"? And yes, I've had a few programming classes in C++ (did quite well in them) and TA'd a class or two on Visual Basic back in college. Though granted, it has been a few years since I last bothered with the stuff. And you know no more about the code base than anyone else who hasn't decompiled it and went through it.

They can figure out how to award the tokens every month, but they can't figure out how to do a lump sum deposit? They also managed to figure out how to tie awarding of badges to subscription time, but they just can't wrap their heads around doing this?

If it was such a massively complicated and difficult problem, why were the Community people allowed to tell everyone over and over that there would be, in fact, a lump deposit? And they only just discovered that they wouldn't be able to do it a day before it goes Live?

You do realize that means exactly nothing, right? At least, professional programmers would realize that. Knowing the language and understanding the situational issues that come up in large scale software development are as far apart as being a veterinarian and subscribing to the Animal Planet channel.

Pop quiz: a commercial application has a bug in it where if the Windows administrator password starts with a capital S, the program doesn't work. This bug affects no other password starting with any other letter including lower case S, and also doesn't itself *use* the administrative password for any specific purpose.

What part of your Visual Basic class would assist you in explaining how such a bug could possibly be introduced into a system?

(The commercial application in question was Citrix Metaframe: this was a real bug from about ten years ago)

Stuff like this happens all the time, and until you've been in the real world for a while doing real work, you tend to have an oversimplified view of the scope of the kinds of things complex systems can do.

Funny, my background is in psychology. Which may be part of why I find the Dunning-Kruger effect so fascinating.

FWIW, I have a lot of programming experience, random strangers I meet know who I am and have used my code, and I do not feel I have enough information to speculate usefully on how easy or hard it would be to assign tokens up front. Maybe it would be technically easy. Maybe it would be hard.

My first candidate guess would be that it's not that they can't give a bunch of tokens at once when you renew, it's that they can't prevent giving a token later when they would have if they hadn't given it up front. Subscription-type systems can be pretty rough at answering questions like "when did this payment apply". It might be possible to do it if you were starting from scratch and all subscriptions would be set up in the future and start then, but trying to do it right with existing subs which can be part-way through a multi-month thing would be harder.

Which is to say, not even having seen the specific code, just thinking about what it does, I can imagine a thing which would be hard enough to make work reliably that I would not be comfortable saying that I could deliver it.

More likely, the code to award those tokens themselves was actually pretty straight forward, but they discovered during implementation that it created an unacceptable side effect they could not eliminate before launch. While troubleshooting such problems, it is usually difficult if not impossible to generate an estimate for the amount of time they will take to fix. Problems that take only a couple of hours to fix can look on the surface no different than problems that take weeks to fix, because the end game isn't obvious from the symptoms.

And yet, said system can reliably deliver tokens every month, whilst keeping track of how many you've earned and spent. But it can't do a check that amount delivered = amount earned + amount bought? Sorry, I really don't buy the "technical limitation" for this mess up.

And yet, they felt quite comfortable enough to tell people over and over that it was in fact happening. It's only at the 59th minute that they say it's undoable. You would think that maybe, just maybe, they would've known, oh say, last week that they wouldn't get it done or that it was unfeasible.

I am quite comfortable in believing that said system will never be delivered. It doesn't make sense from a standpoint of the F2P setup. Why give the players all their stuff right away, when you can trickle it out over time, which would give the players the impetus to buy more points rather than wait for three months, or however long, to complete say the Celestial set.

Ah, Arcanaville showing up to knock someone down. Didn't expect that at all.

/sarcasm

I did say, didn't I, that it was a while ago? I could've sworn I said that. Along with having SOME limited experience, but nowhere near a "professional" such as yourself. But of course, that doesn't matter to Arcanaville.

I'll leave it here as I really don't care to converse to any length with you.

Promises, promises.

Right, but we've already established that you don't know enough about it to have an informed opinion.

And actually, what you describe seems very reasonable to me as a thing that a system couldn't do. You're just assuming that a system which can track one thing can automatically track all other conceivable things, and that just plain isn't how computers work.

Again, all you're doing is confirming that you have no meaningful knowledge of software development.

Last-minute bugs are pretty normal. Sometimes they mean that you can't deliver something -- or at least, can't deliver it without serious problems.

Well, uhm. I think her point is, you listed something as a qualification which is genuinely completely irrelevant, except in terms of Dunning-Kruger evaluation problems.

If you want to argue that, politically, it makes sense for them to be sneaky about this, well, yes, it would make sense. I tend to think that they're not inclined to bother -- there is really no need to try to convince the CoH player base to send them money.

But if you want to argue that there's no way there could be a technical justification, you have to show that you know enough about programming to make a qualified observation on this... and I don't think you do. Heck, I don't think I do -- all I can say is that I certainly can't rule it out, and I can think of several ways in which a system could be able to do what it's doing now, and have a hard time doing what they wanted to do without screwing something up.

Promises promises.

Whether an opinion is informed or not is also not a matter of opinion. If you have no experience in those specific matters, your opinion is uninformed.

If you're dropping $144 right now, odds are pretty good that you're enthusiastic enough about the game and have the pockets deep enough to drop $180 over the next year.

The loss of $36 per customer plus the loss of customer goodwill equals 'technical problem' to this educated observer.

Having a job in software support, it hasn't been an unusual occurrence to test a release of software, beta test a release of software, and then release said software only to find something broke we weren't unaware of. And I don't recall beta being set up to test lump sum token dumps to begin with.

Blood Widow Ricki * Tide Shifter * T-34 * Opposite Reaction * Shaolin Midnight * ChernobylCheerleader

Entropy Legion * Hyperion Force * Hero Heights

Then don't set expectations that a feature "will" be in a product. Or be smart enough to test it in beta.

I've got a ton of tech support experience and setting accurate expectations with customers is one of the most important things to do to keep your customers happy. You're in tech support, you know this.

Paragon set the expectation. If they didn't test in beta, that makes this result even worse, because they might have been able to re-set expectations based on their beta failures.

There's one big thing that I think sets this issue apart from others Paragon has had. In this case their mistake has directly affected their customers' wallets. This isn't about a virtual power, or currency, or PvP, or ED or anything else that's "just a game". These were expectations set that resulted in customers spending real money that they might not have spent otherwise (as seen in this thread and others) only to find out that the reward they were expecting, based on Paragon's statements, wasn't going to happen.

Paragon gets its reward: a nice lump payment. The customer however doesn't get the same consideration back.

When you're dealing with people's money, real world money, you have to be more cautious about setting and fulfilling expectations.

There are always undiscovered bugs or whatever (although I would hope this was tested in beta). The bug here isn't the problem. The mishandled expectations hitting customers right in the wallet are.

This part, I agree with. It's an understandable mishap, but it would have been better to stick with "we would like to do it that way" or something similar.

Sometimes, you can do all the tests you like, but until you go to try it with relatively current live data you don't know for sure if it'll work.

In large companies production databases are often not available to the developers of the software, and sometimes even getting a duplicate of production for testing is incredibly difficult.

When you're developing based on a description of what the data is supposed to look like, it gets rough.

Originally Posted by Arcanaville Softcapping an Invuln is fantastic. Softcapping a Willpower is amazing. Softcapping SR is kissing your sister.

And often for good reasons, too, lest people jump to the conclusion that it's just because Paragon aren't doing it right. Consider that the live account database contains the credit card details and all other personal details of every player in the game. This is not information which it is good practise to make available to people who do not absolutely need to have access to it. Faking that kind of data is often a lot harder than it sounds, too.

If you're suggesting subjectivity is irrelevant in decision making, especially when making choices about entertaiment, then it's simply a silly, or willfully blind, position to take. People usually don't think like Vulcans, weighing the logic of this or that dev decision. In addition, if you're commited to this game till the servers are turned off, you're perspective is vastly different than someone who may decide not to subscribe based on what you view as a minor, trivial annoyance. Such "irrelevant" decisions have led to significant attrition in the sub base. Or is the new model not evidence of that?

It may still be too little, too late for CoH. The free/hybrid MMO market is about to become somewhat crowded, including the game featuring the previously mentioned Vulcans by end of the year, and that other superhero game by the Distinguished Competition next month.

It's my private belief that this game could have been greater, and had the potential to explode in population at various points in the past. Certain decisions, like looking down on how some players used AE, have hurt their bottom line. In a game allowing us to play as villains in an environment created by an in-game villain, they clamp down on "improper" or "unintended" use of game systems? Who cares how they're having fun, as long as they continue to pay to play. In a fantasy environment, it doesn't make a lot of sense to talk about "immoral" use of what the game makes available. The pretend money doesn't matter as long as the real money keeps rolling in.

Yet I've met players who left this game because they felt like they ran into that kid who yanks the ball out of play because he doesn't like how it's being used. "It's my ball and I'm taking it home. You guys aren't following the rules." So potential customers are driven away. (But maybe I should have posted some of this in the MARTy thread... )

Anyway, I'm not optimistic about the future of this game, despite the denials from diehards or loyalists.

You mean the one that hit me, and simply updating my password fixed it? That "THe forums were down all week" issue?

First of all, when they made AE, they told us not to farm - unless you're referring to something else about it not making sense to talk about "immoral" use of the game?

And for the most part, the Devs have only really cracked down on exploits in the AE. Normal farms do get nulled by the GMs, but usually only after being reported. TO be honest, I think fire farms have only lasted this long because of a) i21 being in Beta, and b) they want to work out a good way to null that style of AE abuse without nerfing people playing normally.

And while not all farmers are such : there are plenty that don't understand that AE does not mean "Farm" - half the reason I am iffy with the AE is people who invite those looking for "AE arcs" then get pissed when said invited one leaves the farm.

Now if only we could teach project managers that.