azile

I disagree that time should be completely taken out of the equation, but the current system is highly subject to the Ecological Fallacy. The more factors used to determine the rewards, the more robust the system as a whole. Complex problems often require complex solutions. Using simple solutions means that the problem has been simplified by making assumptions that may or may not be valid.

In addition to the what's mentioned elsewhere in this thread, I'd love to see the reward formula also take into account:

The number of task forces run on a monthly basis.
The total number of merits intended to be injected into the economy on a large timescale (measured in months).
Other global economic metrics.

I doubt this approach would be feasible without using relatively complex machine learning. If I were to tackle the reward problem, I'd train a Bayesian Network to estimate rewards based the data given by all these factors (and more), then update the reward table with each new issue release. However, programmer time would probably be better spent doing other things.

Even under the current reward scheme, reward values need to be looked at again. There have been some systems which dramatically changed the amount of time it takes to complete a task since the last time the task reward table was updated. Specifically, super side kicking made a huge difference. I can imagine the inherent fitness changes having a similar effect - especially for low level activities.

By completion rate, I mean specifically: number of task force x completed / number of task force x started. There's precedent for this as well, the devs have used this metric in the past to balance difficulty. Off the top of my head, they talked about the completion rate of the hero respec trial, and ended up toning down the difficulty shortly after it was introduced. Similar comments were made when the Heroes on the final mission of the Lord Recluse Strike Force were lowered to level 53. You'd also want to throw out outliers in the time-to-complete, and time-to-quit-without-completing when figuring out the success/failure rate. But again, this is data mining the devs have done in the past.

I'd expect the completion rate to be very close to 1 for most tasks (with outliers thrown out), and slightly lower for the "hard" stuff like CoP, RSF, STF, and so forth. I don't think this should be the only metric, I just think it is one that should be considered in the mechanism for determining rewards. There's others, as well: Organization time for events like CoP and Hamidon. A suggestion here would be to factor in number of people required to complete.

It's worth noting that *any* reward metric will be skewed by power gamers. Thus, it's important to choose as robust a metric as possible.

My initial post in this thread was to Castle, asking for the reasoning behind this change (instead of what I saw as another option, or doing nothing). With fitness becoming inherent, there's no change to offset the global buff every toon is getting (either immediately, or on a respec). We're getting power creep, and I am wondering why.

As I pointed out earlier, current power numbers would have to be re-examined if the base rates were changed, and that is a lot of work. And you're right, it would be a nerf to high end builds unless set bonuses were looked at as well. It's probably not a viable alternative at all, really.

The assumption in the majority of this thread seems to be that low level endurance recovery is really the issue being addressed here. But then there's an even simpler solution: just give Beginner's Luck an scaling endurance recovery buff, similar to it's accuracy buff.

Years ago (around i1 or i2) I had this same discussion with Statesman, when I felt that stamina should have become an inherent. It feels weird to be using his argument against it. But again, this approach causes power creep (even if it's simpler to implement).

And if you wanted the option to slot it, you could take the power, which would still be in a pool. What would be a much simpler solution is a global movement/regeneration/recovery rate buff, along with a nerf to fitness.

Don't get me wrong, I'm not against more inherent movement/regen/recovery. My question is why was this approach chosen.

EDIT:
Not just a change to fitness, but all other regeneration/recovery/movement powers to keep their power level the same.

So, it requires fewer spreadsheet changes to just make fitness inherent. This makes sense. However, it's causing power creep, and power creep leads to nerfs.

We've been told over and over again that the game isn't balanced around IOs.

Also, build form versatility which is "added" by *removing* a power pool instead of reducing it's necessity and/or effectiveness, making it less desirable to take? That's akin to saying "I gain more options by removing one."

Castle, any chance you can shed some light on why this choice was made as opposed to simply raising the base values for recovery/regeneration/movement?

I go into a bit more detail below, but this isn't accurate. What's happening in this particular example is that the programmer has to explcitly check for two pieces of hardware functionality: Programmable Shaders (GLSL), and Multitexturing. If they don't exist, he then turns off a particular portion of the render path. The driver does not handle this task automatically. Attempting to call the functions where the hardware does not support them causes an error. Some of us have seen this in COH. If we try to run it on a machine with default drivers or a lousy video card, a message pops up to the effect of: Unsupported Extension: GL_ARB_MULTITEXTURE.

OpenGL ES (Embedded Systems) is not a set of gaming-specific calls. It is a subset of OpenGL that is used for low-powered devices: cell phones, mp3 players, portable gaming devices, refrigerators, and other embedded systems. It is used for games on cell phones / portable consoles, but the major use is actually for user interfaces. It's not intended for PC games, or high powered consoles like the PS3 / Xbox 360, where a more full-featured 3D API would be appropriate.

The Direct3D API does change from version to version, but the changes from D3D 9 to 10 were not that different than the changes between OpenGL 2.1 to 3, depending on how you define your OpenGL rendering context. Some function calls are added, some are changed, and others are dropped. If you are going to support D3D 9 and 10, you'll need seperate render paths for each, as they have incompatible rendering contexts. If you generate a D3D 9 context, you need to use D3D 9 calls, and the same is true of D3D 10. Performing a D3D 9 Call on a D3D 10 context will fail.

OpenGL 3 has a similar mechanism: if you define an OpenGL context to be "forward-looking," you set the minimum version of compatibility - say 3.1, and you're strictly forced to comply with OpenGL 3.1+ function calls. For instance - because the fixed function pipeline was deprecated in 3.0, and removed in 3.1, certain basic calls to it like glTranslate() will throw an error. There is also a backwards compatible context, where deprecated calls aren't removed. However, the interaction between some deprecated OpenGL calls and the new OpenGL 3 calls is undefined. Thus, if you opt to use both the deprecated and new features, the action that will be taken is whatever the driver feels like doing, which can be the right thing, but is not guarenteed to be. Because of this, it can preferred to have a forward-looking OpenGL 3 context, especially with new code, or heavily optimized code. So you wind up with two seperate render paths with OpenGL (one for 2.1, another for 3, if you are planning on supporting both), much like you would with different versions of Direct3D. Personally, I'm curious what route the devs choose for Ultra Mode.

The deprecation in OpenGL 3 is long overdue. The Fixed Function pipeline has been around since the late 80s (OpenGL's been around since '92), and it's not indicative of how things are rendered anymore. Initially, The new features of OpenGL 3 were not going to have explicit backwards compatibility with 2.1 (Google "OpenGL Longs Peak" if interested in the history), but ultimately the Architecture Review Board decided to maintain backwards compatability, at the cost of performance. The majority of fixed function pipeline calls have a significant performance hit for rendering scenes with a large number of vertices.

Ultimately, OpenGL and Direct3D have different design philosophies. Like all APIs, they are slaves to the hardware. Which is "better" is really a matter of what the task at hand is.

I managed to ask a Microsoft developer at Siggraph about this a couple years ago right after Vista was released. His claim was that the reasoning behind not porting DX10 (really Direct3D 10) to XP had to do with a design decision made on integrating it with the Windows Vista Display Driver Model, which would also need to be ported, and doing that was supposedly deemed to be too much of an ABI change for a production OS. I've not actually been able to verify this anywhere else, so the guy could have been making this up. However, it did seem to be a reasonable explanation.

From my perspective, Nvidia's drivers remain more stable than ATI's at least for OpenGL development. Perhaps the better term would be more "forgiving," as they don't crash as often when I am debugging (and usually sending bad data in some form or another to the card). As always, YMMV. ATI certainly has the hardware lead for now.

Anyhow, hopefully this helps clear things up a little.