Game Development: Artifacts & Artifice

[Potjeh]

You *have* to manually calculate because there is no indication whatsoever of what are high and what are low numbers, so it's impossible to eyeball it.

And I really don't see how an interface that doesn't present the information that it's supposed to present isn't horrible. I mean, isn't presenting information the primary function of interfaces? What else does it need to be horrible, gaudy colours?

[FutureForJames]

Going back to the brazier problem since braziers are one of the touched objects in this announcement: how the brazier mechanics worked a few months ago (something I don't expect to have been changed, or at least it didnt show in any announncement), the attacker can abuse it by buiding braziers without coal near defending braziers. That way they reduce the overall damage received from defending braziers since brazier damage is based on the amount of braziers within its radius no matter if they are inactive or active.

I haven't tested if simply building non-completed brazier signs reduce damage as well, and currently I don't have any desolate vault to hide my character so not willing to test it just yet.

A solution would be design the brazier damage so that the character notices where the brazier damage is coming from. I.e. first brazier shot from source A does full damage, then if the 2nd shot comes from another source B within X seconds of the shot from A, that 2nd shot gets reduced damage through division by factor (1 + 0.2*1 = 1.2). Then if A does yet another shot within X seconds from the shot from B, then A gets damage divided by 1.2 as well.

If A shoots first then B and C shoots within X seconds then damage from A would be base/1.0 while B would deal base/1.2, C would deal base/1.4. Then during 2nd round of shots, all would deal base/1.4 each.

Using the given suggestion, enemy wouldn't be abe to build extra braziers to reduce damage from relevant braziers. Furthermore, it would strengthen defense against multiple attackers attacking from different angles in such way that they all get hit by braziers, because a brazier hitting one attacker would not reduce the damage of another brazier hitting another attacker.

Finally, it would decrease the efficiency of the "let's destroy all braziers first" strategy since a red brazier (which is another form of inactive) would not reduce damage of other braziers.
-----------------

Another alternative woud be to design so that brazier damage is only dependent on surrounding healthy braziers with coal in them so that red braziers won't reduce the damage of other braziers. However, the problem is, that enemy can still build braziers in such angles that the newly built braziers won't shoot the attackers but still be within range to decrease the damage of the braziers that will shoot the attackers.

[Gacrux]

Going back to the brazier problem since braziers are one of the touched objects in this announcement: how the brazier mechanics worked a few months ago (something I don't expect to have been changed, or at least it didnt show in any announncement), the attacker can abuse it by buiding braziers without coal near defending braziers. That way they reduce the overall damage received from defending braziers since brazier damage is based on the amount of braziers within its radius no matter if they are inactive or active.

I haven't tested if simply building non-completed brazier signs reduce damage as well, and currently I don't have any desolate vault to hide my character so not willing to test it just yet.

A solution would be design the brazier damage so that the character notices where the brazier damage is coming from. I.e. first brazier shot from source A does full damage, then if the 2nd shot comes from another source B within X seconds of the shot from A, that 2nd shot gets reduced damage through division by factor (1 + 0.2*1 = 1.2). Then if A does yet another shot within X seconds from the shot from B, then A gets damage divided by 1.2 as well.

If A shoots first then B and C shoots within X seconds then damage from A would be base/1.0 while B would deal base/1.2, C would deal base/1.4. Then during 2nd round of shots, all would deal base/1.4 each.

Using the given suggestion, enemy wouldn't be abe to build extra braziers to reduce damage from relevant braziers. Furthermore, it would strengthen defense against multiple attackers attacking from different angles in such way that they all get hit by braziers, because a brazier hitting one attacker would not reduce the damage of another brazier hitting another attacker.

Finally, it would decrease the efficiency of the "let's destroy all braziers first" strategy since a red brazier (which is another form of inactive) would not reduce damage of other braziers.
-----------------

Another alternative woud be to design so that brazier damage is only dependent on surrounding healthy braziers with coal in them so that red braziers won't reduce the damage of other braziers. However, the problem is, that enemy can still build braziers in such angles that the newly built braziers won't shoot the attackers but still be within range to decrease the damage of the braziers that will shoot the attackers.

or the could remove building while you are being aggro'd during criminal acts.
I like the Alternative idea for the brazier influencing other brazier damage wise

[jorb]

You *have* to manually calculate because there is no indication whatsoever of what are high and what are low numbers, so it's impossible to eyeball it.

And I really don't see how an interface that doesn't present the information that it's supposed to present isn't horrible. I mean, isn't presenting information the primary function of interfaces? What else does it need to be horrible, gaudy colours?

Maybe I shouldn't be arguing the use of the word interface, but to me, speaking about an "interface problem" would imply a problem where the interface itself is poorly designed or lain out in such a way so as to make it hard or convoluted to acquire some piece of data from it or issue a particular instruction to it. A problem, indeed, in the very framework for I/O handling. The framework here is extremely minimalistic and very much in keeping with the game's established conventions (tooltips, hold and right-click to interact). Calling the fact that a particular datapoint has been left out an "interface problem" is just not very descriptive of the actual problem.

You can eyeball it in terms of easier versus harder. You know what to strive for if you want to have an easier time. You can't make relative eyeballs (at least not without a fair amount of experience), but I've already conceded that (I think, without having discussed it with loftar yet) you should get to see the calculated success rate.

Everything thereafter has just been you QQ:ing at me over nothing.

[alloin]

going complete offtopic here, but on topic regarding updates:

When will fish get an upgrade Jorb ?

[Potjeh]

Omitting the one and only interesting datapoint is a pretty major interface design flaw, IMO.

And no, we can't eyeball it at all, because we have no clue of how important the different variables are relative to each other. Which could've been easily averted by, you know, including that one and only interesting datapoint.

So yeah, I, and vast majority of the playerbase, won't be touching this update until Ender puts that datapoint in his client.

[jorb]

Omitting the one and only interesting datapoint is a pretty major interface design flaw, IMO.

But it isn't the only interesting datapoint. What the heck would you do with that datapoint if you didn't know what actually affected it?

we have no clue of how important the different variables are relative to each other.

Precisely what I said, and conceded long ago.

[jorb]

vast majority of the playerbase, won't be touching this update until...

If I had a penny for every time...

[jorb]

When will fish get an upgrade Jorb ?

I try not to make too many plans and schedules. God has a way of just laughing them away. I'm aware that fishing is fairly lacklustre, but I haven't really been inspired to do anything particular about it yet. The payouts need to be buffed at the very least.

[jorb]

Jorb: have you considered changing brazier mechanics so that the damage is only dependent on the braziers shooting the target and not on inactive braziers as well?

What is the reasoning for not doing that change? I can only see advantages with a such change.

I hadn't thought about making it, so that's the reason. I'll consider it.