2005年12月18日
Mr Tactの提案 対数関数化

Mr Tactが数値計算の対数関数化を提案しました。

news051217-etc-2.gif

2005年12月17日
Mr Tactの提案 対数関数化
2005年12月18日
魔法抵抗スキルの問題について
プロパティ表示手段の実装について
弓師への対処について
対数的漸減の上限について
ステータス計算への漸減適用について
降順ソートと適用変数について
キャラクター育成期間の長期化について
装備スロット数と対数的漸減について
対数的漸減とプロパティ価値
関数利用の問題点
対数的漸減の上限について#2
対数関数と対人戦勝敗
対数的漸減とは無縁の問題点
対数的漸減とプレイヤー格差
魔法抵抗スキルの問題について#2
対数的漸減とテキスト表示
漸減の開始ポイントについて
他の数値への対数的漸減導入

2005年12月18日 対数関数化に対する質疑応答

魔法抵抗スキルの問題について
意見)
現段階では特段指摘する事もないのだが、敢えて魔法抵抗スキルが対数的漸減とは逆の動作をしていることは伝えておきたいね。

Mr Tact)
その通りだ。魔法抵抗スキルも見直すべき問題を孕んでいるね。今回提示したものはあくまでダメージ増加プロパティに主眼を置いたものであり、手始めに過ぎないよ。

プロパティ表示手段の実装について
意見)
Mr Tactは同様に増加したプロパティ総合値を表示するシステムも実装すべきだね。

Mr Tact)
私が実装を望んでいるもののひとつに挙げているよ。

弓師への対処について
意見)
この対数的漸減の導入なんかじゃ問題の最大要因に対処することなんてできやしない。弓師こそが問題なんだ!

Mr Tact)
君が幾度となくこの問題を指摘し続け、私が返答してこなかった事は申し訳なく思っている。私見では弓師は遠距離攻撃を行えるという長所を有するが故に他の近接攻撃とは異なるべきだと考えているよ。尤も、今回はWilkiが注意を促しているように主題である対数的漸減に関する意見に限って欲しい。

対数的漸減の上限について
意見)
Mr Tactの提示した計算式を確認したが、未だに上限の概念を用いているね。

Mr Tact)
確かに私はスプレットシート上で「上限」という言葉を使ってはいるが、これは不適切だ。技術的には対数に収束値というものはなく増加し続けるね。そして対数の結果が1を越える場合だってあり得るのだ。つまり計算されたダメージ値が「上限」を越えることだってあり得ることを意味している。

ステータス計算への漸減適用について
意見)
この対数的漸減はヒットポイントや最大積載量、スタミナやマナといった値をSTR、DEX、INTから導く計算式に於いても採用すべきだよ。

Mr Tact)
その可能性は大いにあるよ。今回の提案はまず最初にダメージ増加プロパティに対してどのように動作するのかを確かめる必要があったに過ぎないからね。

降順ソートと適用変数について
質問)
今回の対数的漸減案にはよく判らない点が幾つかある。「最初の変数」が100%で2番目が50%・・・とあるんだが、この「最初の変数」とは何を指しているのだろうか?最初に装備したアイテムのことなのだろうか?

Mr Tact)
先の投稿で私は変数を降順ソートすると言及している。つまり、もし5%、15%、25%、10%のプロパティを備えるアイテムを装備していた場合には25%、15%、10%、5%の順に適用されていく事になるんだ。しかしながら、同じく言及しているようにこの案はプログラムの観点或いはプレイヤーの皆さんが困惑するという観点から実装不可能だったんだ。だから私は類似した結果を実現し得る対数関数を用いる事を目指している。ただし対数関数を用いる場合は全てのプロパティは同じように扱われるよ。

キャラクター育成期間の長期化について
意見)
小難しい数学談義は置いておいて、この案唯一の問題はキャラクターデザインにより多くの時間を割かねばならなくなるってところだ。

Mr Tact)
その通りだね、その問題はこの案最大の障害になり得るものだ。この関数の動作を判り易いものにする有効な手段に気づいた方がいたら是非報告して欲しいよ!

装備スロット数と対数的漸減について
意見)
対数的漸減が実装されてもウルティマ オンラインには多数の装備スロットが既にあるし、高強度のアイテムは価値を失わないだろうね。

Mr Tact)
その通りだ!

対数的漸減とプロパティ価値
意見)
皆は以下の点で誤っている。増加量の漸減という発想では「良いアイテム」でも特定プロパティ(例えばダメージ増加)の為だけに入手している事にしているが、それでは結果として有効性をもたらさない。より良いアイテムを入手すればする程、それぞれのアイテムから得られる有効性は減っていくのだからね。

Mr Tact)
増加量漸減という発想においても特定プロパティに特化すれば、同じような攻撃を行った場合に周囲の誰よりも15%多くダメージを与え得るプレイヤーになることができるんだよ。

関数利用の問題点
意見)
まず第一に指数的(ここでは対数的)減少は少々極端過ぎるのではないだろうか。代わりに多項式を用いた関数を採用すべきかも知れない。尤も対数関数の利用にはコンピュータ効率が良いという付加価値があるのだろうけどね。

第二に対数関数或いは何らかの連続関数という手段はダメージ増加のような連続的変数には有効だが、ファストキャストやキャストリカバリといった整数の変数で同様の結果を得ようというのであれば何らかの代替案を用意する必要に迫られるだろうね。

Mr Tact)
実に的を射たフィードバックだし、私自身が思案していた問題点とも合致するね。ファストキャストやキャストリカバリといったプロパティは我々のゲームクロック上充分にサポートし得ていないのだが、近似値でなんとか丸めようと考えているところだ。しかしながら、本当のところを言うと余り気の進まない対処法だ。勿論、ゲームクロックを更に細分化させる事も可能ではあるのだが、実施しようとすれば非常に大変な作業となるから期待しないで欲しい。

対数的漸減の上限について#2
意見)
チャート表示上はダメージ増加には300%の上限設定があるようだが、それが380%となり上限を上回ってしまう。もし上限がないというのであれば、今現在よりも多くのダメージを与え得るという事ではないだろうか?

Mr Tact)
まず、STRと解剖学スキル、戦術スキルからボーナスを最大値得た場合には200%近いダメージボーナスを得ている事となるが、これらは300%上限の適用外としている。但し今回のスプレットシート上では同じ土俵で処理させたんだ。したがって、300%のダメージボーナスを得る場合には実際は500%を必要とするし、スプレットシート上では約780のボーナスを要する事となる。

尤も、君の意見も適切だ。今回提示したスプレットシートはあくまで叩き台に過ぎないから最終的に採用する数値ではないよ。

対数関数と対人戦勝敗
質問)
今回の対数的漸減を採用した場合、どうやって勝敗を決すれば良いのだろうか。

Mr Tact)
大部分をプレイヤー自身の技量に依存する事となるだろう。おそらく運の要素も若干入り込む余地が生まれるだろう。

対数的漸減とは無縁の問題点
意見)
マジックプロパティとは無縁の弓師や武士道クリティカルヒットといった重大な問題が残されている点を除けばね。

Mr Tact)
確かに残されているね。

対数的漸減とプレイヤー格差
意見)
Mr Tactの考案した対数的漸減ではパワーゲーマーと一般プレイヤーとの格差を拡大させるだけでしかないよ。

Mr Tact)
私は一般プレイヤー或いは日頃は対モンスター戦しか行っていないプレイヤーが熟練の対人プレイヤーを打ち倒せるようにする事が適切な設計とは思わないね。彼らに戦う機会、或いは逃げるという選択肢を与える事こそが大切なのだと考えている。

魔法抵抗スキルの問題について#2
意見)
魔法抵抗スキル値120.0で全属性抵抗値を60にすべきだ。

Mr Tact)
私は魔法抵抗スキルでこれ以上の属性抵抗値を付与させるべきではないと考えているね。寧ろ以前の仕様に戻すべきなのだ。かつては魔法に対して今現在の受け流しスキルのような働きを担っていたのだが魔法抵抗スキルだ。もしローブを着込んで駆け回りたいというのであればしっかりと防御呪文をかけておくべきだね。

対数的漸減とテキスト表示
質問)
ダメージ増加35%が本当は35%と意味していないとなったらプレイヤーは困惑するのではないだろうか。速度+30%も30%を意味しなくなるのだろうか。マジックプロパティの表示について教えて欲しい。

Mr Tact)
それはテキスト表示を変更するだけであって簡単な事だ。問題となっているのはテキスト表示する数値そのものを如何にして決定するかということだね。

漸減の開始ポイントについて
意見)
実際の検証を開始する前にまず漸減の開始ポイント引き下げを検討すべきだ。

Mr Tact)
先に述べたように私はダメージ増加に関わるもの全てを同じ土俵で扱っていくことで対処し得ると考えているんだ。スキルやステータス、スペシャルムーブ、クリティカルヒット、特効、エネミーオブワンといったもの全てを対象としたい。

他の数値への対数的漸減導入
意見)
スキルやステータスも調整していかねばならぬ事になりそうだね。

Mr Tact)
今現在はダメージ増加以外に対数的漸減を導入する具体案はないのだが、もし順調に行けば他の数値への導入も検討していくだろう。

Don't have any specific ideas right now, although I guess I should point out that currently, resists are the OPPOSITE of diminishing returns.


Yup, going to have to look at resists as well. This is mostly just aimed at the damage increase stat. It's merely a start :-)

Oh yea, while implementing this, you should also implement a system that lets us see all the properties (the end result) on our character, as well.


It's on my wish list!

Unfortunately, it does not address the REAL problem that is causing the VAST MAJORITY of the problems:

ARCHERS.

You have pointed this out in a couple of places now, and I have neglected to respond. My apologies. In my mind it's a foregone conclusion that archery should work differently from melee, since they have the inherent advantage of range. But as Wilki mentioned, let's keep this thread on-topic.

I looked at your formula, and you are still using the concept of a cap.


Yes I used the word "cap" on the spreadsheet, which isn't quite right. Technically, the formula is open-ended and increasing. And eventually, the log exceeds 1, which means the calculated damage is greater than the "cap" value.

This concept should also apply to how hit points and carry capacity, stamina, and mana is calculated from the base strength, dexterity, and intelligence stats.


It's very possible. We'll have to see how it works with damage first.

However, there would be a few issues w/ diminishing returns... To me it looked like you said that the "first mod" would be at 100%, 2nd 50%, etc. Well, what is the "first mod"? Is it the first item equippied?


In the "first concept" section, I mention that the mods would be sorted in decreasing order of size. So if you had mods of 5%, 15%, 25% and 10%, they would be applied in the order 25, 15, 10, 5. However, as I mention, this model is not really viable from a programming standpoint (or from a "player confusion" standpoint), so I am now shooting for using a logarithmic algorithm that can achieve similar results. However, all contributing bonuses are treated homogeneously.

Manual math aside, the only problem was that conceptually, the players seemed to have a lot harder time designing their characters


Yes -- this is my biggest problem with this approach, so any ideas anyone has on how to make the learning curve more gentle are greatly welcome!

n contrast, I think that the fact that there are a finite number of equipment slots in UO already gives added value to high-intensity items under a logarithmic mechanic.


You've got it!

I believe that you're mistaken on this point. The whole idea behind diminishing marginal returns is that getting all of the "good stuff" for a particular attribute (such as damage increase) doesn't really benefit you all that much since the benefit you derive from each goes down as you get more and more good stuff.


Absolutely, although it also allows you to *choose* to focus on that one stat and be the one guy in town who does 15% more damage than anyone else with the same attack.

First, an exponential (that is, logarithmic) decrease in benefit might be a bit too steep, and it might be better to consider some sort of polynomial function instead (which would have the added benefit of being computationally faster). Second, while using logarithms (or any continuous function) would work well with a nearly continuous variable such as damage increase, you would have to find some other method for getting similar results with integer-valued attributes such as FC/FCR.


Excellent feedback, and they are consistent with some of the thoughts I've had on the subject. For stuff like FC & FCR, I've considered increasing the resolution of the ability, even though the granularity of our game clock doesn't support it, and then rounding to the nearest tick. Although, that might really suck :-) Of course, if we could actually increase the resolution of our timing system, that would be awesome, but I'm not holding my breath for that one.

Now, as the chart indicates, there is a 300% hard cap on damage increase. It would appear that at 380%, a template would achieve this cap. If there is NO cap, then, of course people could be doing more damage than they are doing NOW.


One thing -- you get almost a 200% bonus from having Strength, Anat & Tactics maxed. These are currently *outside* of the 300% cap. I want to move them onto the same continuum, so when you talk about getting a 300% dam bonus now, you're actually getting almost 500% in reality. Which would require about 780 in total bonuses on this spreadsheet.

Nevertheless, you are correct, this spreadsheet is just a starting point, and in no way intended to reflect the final numbers.

How do you see this fight ending?


It's pretty much down to the *players'* skill at that point, isn't it? With, perhaps, an element of chance.

Other than huge unbalances like archery and bushido crits, which have NOTHING to do with item properties


Yet.

Unfortunately, diminishing returns as they are planned will only create a greater cap between "power gamers" and regular players.


I don't know that it's a valid design goal that casual or even frequent PvM players should be able to take out experienced PvPers. I do think it's important that they have a *chance* (to flee, if nothing else).

120 magic resist should give 60s to all elemental resists.


I would rather not make Resisting Spells give more resists. I would prefer to return it to the old way of working, where it was effectively Parry for magic. If you want to run around in a robe as a mage, we should give you some defensive spells that don't suck :-)

What will people say if 35% damage increse will not mean 35%? if 30% SSi is not 30%? How do you change items properties display?


That's actually just a text change. It's easy. The hard part is figuring out what it *should* say.

Before a serious test you should consider lowering the point at which the returns start to diminish.


I think this is addressed by, as I mention above, putting *all* damage increasing effects on the same diminishing continuum -- skills, stats, weapon specials, crits, slayer bonuses, EoO, and so on.

This also seems like it would have to change skill and stat points as we know them out.


No concrete plans to apply this to anything but damage right now, but if it works well, we'll see.

MrTact
Designer/Engineer, UO Live
12/17/05 11:00 AM

2005年12月17日 Mr Tactの提案 対数関数化

上限設定の問題
何故上限設定を施す事はまずいのだろうか、それは上限に達する事は容易であり(実際、導入した上限設定のほとんどがそうなってしまっている)、上限設定に達する事こそが事実上の標準となってしまう事にある。皆さんはまず上限の数値に達しておいて他のパラメータを調整していこうとするだろう。顕著な例がメイジである。今現在のメイジはファストキャスト2、キャストリカバリ6が基本条件となっており、結果としてどのメイジも違いが見られなくなってしまっている。メイジはまず詠唱速度を最大まで上昇させた上で呪文ダメージや秘薬低減を調整していっているのだ。

もしダメージに上限設定を施す事になろうものなら、プレイヤーは速度や命中を調整しようとするだろう。ウルティマ オンラインの時間単位は細かくはなく0.25秒単位の為、速度の最大化を図る事など容易いし、多くの武器が利用されなくなってしまう。遥かに基礎ダメージ量の多い斧やハルバードが同速度で扱えるというのにダガーを使おうと考える方はいないだろう。上限設定は固定割合で行われる為、基礎ダメージ量が高い事がダメージ量を増大させる唯一の手段になるのだ。

この問題はプロモーションやイベントで新しい素敵なアイテムを提供していこうとする我々の試みにも弊害を来す。今現在、どの分野でも最高のアイテムが存在しているのだが、導入しようとする新アイテムがそういったアイテムよりも魅力がなければ価値はグラフィックのみとなってしまうのだ。グラフィックも決して無意味ではないが、パワーゲーマー観点では二の次の問題だ。

増加割合漸減の導入
増加割合の漸減を導入すればこうした問題を回避し得る。効果は上限設定と極めて似ているのだが、限界点達成は遥かに困難なものとなるのだ。増加割合漸減を導入すればステータスを上昇させて増加する値を上昇させるにはより多くの努力が必要となる。一例を挙げるとダメージ増加+0の状態でダメージ増加+50を追加した場合には+50をそのまま増加できるのだが、既にダメージ増加+100の状態でダメージ増加+50を追加した場合には+40しか増加できないようになるわけだ。

また、ストレングスや戦術スキル、解剖学のダメージボーナスといったキャラクター作成当初から備わっている能力をこの増加割合漸減システムに組み込めば、キャラクターが過剰な強さにならないよう調整する事に注意を払う必要がなく能力増加を図っていけるのだ。これはアイテム依存問題の低減にもつながっていく。

実装第一段階
実装への私の最初の案はダメージボーナス自体に小さな「ボックス」を組み込むことだった。我々はこの「ボックス」一覧を保持し、降順ソートする。そして適用時には「ボックス」の順序に従い増加量を減少させていくのだ。例えば最初の「ボックス」は最大限で適用され、二番目は半減し、三番目は3分の1に減少させていく。或いはもっと極端に減少させていっても良いだろう、×1、×1/2、×1/4、×1/8といったようにね。

この案の問題点はメモリー使用量増加に伴い非常に高価になってしまうことだ。変数一覧をソートし保持していき、そしてボーナス値が変更されるたびに有効なダメージ量を再計算していく事はコンピュータ計算の経済効果の観点で非常に高価なものとなってしまう。しばらく頭を悩ませた結果、私が辿り着いた結論は代わりに対数を用いる事だった。

どのように動作するか
対数関数には増加量が漸減していくという特徴がある。入力値が増えるにつれ出力値の増加量は減っていくのだ。これにより我々は数値漸減を1度の計算と1つの数値で出す事が出来る。対数関数も高価になり得るが、テーブル参照してメモリー使用量を節約する事で最適化できるはずだ。

さて、正確にどのような動作をするだろうか。よし、例を挙げれば判り易いだろう。そこでこのアルゴリズムをプレイヤーの皆さんにも判るようなスプレットシートを用意したよ。これを見れば私の考えがお判りになるはずだ。どのような類の調整をしようとしているのか知るためには「multi」「cap」「base」項目に従い試してみて欲しい。multi値は実際には「1/multi」の形式で数値化されるよ。そしてグラフがどのような変化を示すか確認してくれ。青線が直線的な上昇を示した場合であり、今現在の状況だ。ピンク線が対数ダメージ量であり、私が今回提案しているものだ。

Caps Suck And why do caps suck, you may ask? Because if the cap is easy to reach (as most of the fixed caps in our game are), then it becomes de facto: you achieve the capped value and then optimize elsewhere. Case in point: mages. It's basically de rigeur for mages to have FC2/FCR6 now, which means that all mages look exactly the same. They max out casting speed and then optimize for SDI or LRC.

If we use capped damage, players will just optimize for swing speed and HCI. Because of the coarseness of our game clock (250ms per tick), it's not hard to max out swing speed, either, which means that a whole host of weapons are out the window: who's going to use a dagger if you can easily achieve the same swing rate with an axe or hally that has more base damage? Since the cap is a static percentage, higher base damage is the only effective way to raise your damage output.

This also impacts our ability to introduce cool new items for promotions, events and whatnot. Basically, right now, for any given category of item, there is a "best" item. Unless any new item we introduce is better than that item, its only value is in the art (which is not completely insignificant, but from a power gamer perspective, the art is secondary).

Enter Diminishing Returns
Diminishing returns addresses these problems. The effect is similar to a cap, but it's much harder to reach the limit. With diminishing returns, the effort required to raise a stat goes up as the stat goes up. As an example, if you add +50 damage when you are currently at +0, you get +50. If you add the same damage bonus when you are already at +100, you might only get +40.

The reason this is nice is that you can continue to pile stuff on your character and increase in a particular stat. It's very hard to max out . . . and if you have more than 1 stat you care about (e.g. damage increase, hit chance increase & swing speed for weapons), it's nearly impossible to max all of them.

It also lets us be more liberal with making higher-powered items available, because it's inherently self-balancing: there are only so many equipment slots, we limit the total amount of damage bonus any individual item can give out, so we can balance the system based on that limit.

Also, if we integrate inherent player abilities into this system (e.g. strength, tactics and anatomy damage bonuses), diminishing returns lets us increase those abilities with less concern about making characters overpowered. This makes it possible to be less dependent on items.

Implementation, Take One
My first idea for implementing this was to have each damage bonus comprise its own little "box". We would keep a list of these boxes, sort it in decreasing order of size, and when we applied them, we would have an increasing reduction in effectiveness for each subsequent box. For example, the first box might be applied at full power; the second halved; the third, reduced to 1/3, and so on. Or, for a more extreme progression, x1, x1/2, x1/4, x1/8 etc.

The problem with this plan was that it is very expensive in terms of memory used, and computationally expensive to keep the list of modifiers sorted and to recompute the effective damage bonus each time one of the constituent bonuses changed. After racking my brain for some time, I arrived at an alternative mechanism: logarithms.

How This Would Work
Logs have the property that they give diminishing returns: as the input grows, the output grows in a decreasing fashion. This gets us the diminishing returns we want with a single calculation and a single numeric value (the sum of all damage bonuses). Logs can be expensive, but we may be able to optimize them with a table lookup, trading a little bit of memory for CPU.

But how, exactly, would this work? Well, an example is probably the best bet, so I have crafted a spreadsheet that will let you play around with this algorithm to see what I'm talking about. If you want to see the kind of tweaking that we do here in design, take this spreadsheet and play with the numbers next to mult, cap and base (two columns over from mult; the actual mult value is 1/that number), and observe how the graph changes. The blue line is linear damage: what we have now. The pink line is logarithmic damage: what I'm proposing.

Comments? Questions? Concerns?

MrTact
Designer/Engineer, UO Live
12/16/05 04:18 PM

投稿者 Siel Dragon : 2005年12月18日 22:27
コメント

突然訪問します失礼しました。あなたのブログはとてもすばらしいです、本当に感心しました!

Posted by: マークジェイコブス バッグ : 2013年04月17日 09:58
コメントする









名前、アドレスを登録しますか?