・Flooding with Powerful Items [from CoNB DevBoard - 2000/11/17]
Ubiqは強力なアイテムの氾濫を防ぐことに関し、以下の返答をしました:

1つの懸念を持っただけですか? 私達は正しい行いをしているに違いありません!

万能(uber)な武器の氾濫を防ぐ方法というあなたの質問の答えで、その返答は簡単なものです:

・ランダムな発生。
・まるのままのアイテムにする代わり、構成部分(component)を与える。
・未開の地(wild lands)に最高のものを置く(あなたが言っているのはこのことでしょうが、PK達がキャンプを減らします)
・死蔵することを防止するための合理的なものの腐敗。

助けになるであろう2〜3の他のことを私達は手に入れましたが、今のところは秘密にしておこうかと思います。ベータが訪れたときにそのことをあなた達全員が聞くことになるであろうことは、何の疑いもありません。

・More on Combat Math [from CoNB DevBoard - 2000/11/16]
斜体の質問に対する、Gafferの返答です:

アイテムのタイプ、魔法付加、スキルなどのための全ての変換器は、(EQがやっているように思われる)ダメージを与えるために使われる少数の数値に変換されるのでしょうか?

ええそうです、最終的な答えを出すため計算した合計値の小さな数に結局はなります(とにかく、結局あなたは2つのものに関与します: 攻撃をしたか、そしてどれだけのダメージを行ったか? です。その間には多くの数があります(+当てるチャンス、+ダメージ、ダメージロール。スタミナ消費、+防御するチャンス、+ダメージ吸収など)し、上記で挙げた基準を一つ一つ慎重に変換していく多大な方法があります。

あるいは代わりに、それら全ての変換器は次々と「即座に」適用されるのでしょうか?
後者はより集中的な計算(それゆえにプロセッサも)になるだろうと私には思えるので、それは前者だと思っています...

それらの変換機を「即座に」行うことはほぼ不可能です。何故なら、単にそれを導入するだけでは計算をするのにとても費用がかかり、さらに - 直接サーバ境界線をまたぐと戦うまねをすることになってしまいます。あなたが自分の攻撃を解析するようには防衛者の情報を事前に知ることが出来ないため、攻撃者から防衛者のそれら全ての変換器を入手するある程度の方法を持つ必要があるでしょう。とはいえ、ほぼ不可能であるにもかかわらず、行うことが出来ます。事実、我々はそれを行いました。能率よく、そしてサーバ境界線上でも動作する、我々(特にGunner10)が行ったとても巧妙なトリックがある程度あるのです。いや、末端ユーザには、それがどれだけクールなものなのかを知る手立てはないかもしれませんが、将来的に我々が追加の出来るクールなアイテムの種類、あるいは即座に変換する制限はとても少なくなります。例えば我々が望めば、我々がリストへ上位10人の猫の曲芸師の名前を入れると、そのリストの中からランダムに選ばれた人間に対して明確にダメージを変更するよう魔法がかかった剣を我々の宝物テーブルへと追加することができるでしょう - そのように、とてもクールで動的な魔法付加のものになります。もちろんタダでは出来ません(リストを保つことは新たなコードが必要だし、他の問題があります)が、この特殊なシステムはそのような効果を能率的に起きさせることが出来るでしょう。再度言いますが、目標は出荷時に猫曲芸師殺害剣のようなものを世界中に沢山持つことではありませんが、これからずっとイベント、新システムなどに対してライブグループへ自由な裁量を与えることです。それはとても自由なものなのです。

いえ、何故それほどまでにクールなのかの説明をうまくしたとは私は思いません(私が提供できたどの例も、私達がまだそれについて話し合っていない約束のように聞こえるでしょう)が、誰もしたことのない素晴らしいものを私達が持ったら、未来はそれを裏付けてくれるはずです ;)

私の元々の質問は、次のように向けられたものでした -- もし少ししか攻撃と防御のステータスが使われなかったとしたら、どうやって以前の計算が使われるのですか?

私が提供した上記の部分はほぼ正しいのですが、残念ながらまだ詳細が面白くはなっていないと思われる、調整すべきものが沢山あるのです。

そして私がそれに取りかかっているとはいえ -- 開発チームは発売前にファン達へ持ちかける、よいことをしました。ライブチームはその例に従って行動できることを私は望みます。

ライブチームはまだ完全には編成されていませんが、あなたは既にそれについて十分言及しているかもしれません - ゲームに取り組んでいる多くの人が、よくし続けることを本当に望んでいるのです(そして、あなたが数多くの本当にクールなものを動作出来るようにさせた途端、それに着手するそれらのエンジンを作るために多大な努力を使うのです!)。

やはり、我々はよい仕事をしていると聞けてうれしいです :)

・Combat Math [from CoNB DevBoard - 2000/11/14]
以下はGafferからのものです:

戦闘システムの計算は、ここに投稿されたものよりも遥かにずっと広範囲なものなのです; やはりDamionとBenは一般に計算の内部詳細を発表することについてかなりきちんとしていますので、長い間そうしない本当に強い理由がない限り、我々はそれについてかなり話すことになるかもしれません。

何故その計算は集中的なのでしょうか? 何故なら、基本的に「私はこれくらいのダメージを与えられる、これくらいのボーナスを持っている」ようなことは簡単だとは言え、あなたの持つ項目は、どのアーマー部分が打撃を受けたか、それはどのように作成されたか、何の付加魔法がそれ(とあなた)にかかっているか、アーマーは何のダメージ吸収を持っているか、あなたとあなたの攻撃者は何のスキルボックスを持っているか、などを基にして多くの異なる方法で影響するのです。それはスキル、特性、アイテム、作成のあらゆるものをカバーするため、2〜3のとても大きな文書になっています - 他のシステムへ打撃を与えず戦闘の計算をするのは、とても困難なのです。

その上、我々が今発表するものはベータ/立ち上げ時に見ることになるものと恐らく正確に似ることはないだろう十分な量のものを今だ調整(Mobiusはとてもクールなシステムにしましたが、あなたがそれを見、調整などをして導入している間に、全てのものが変更されています)していますし、(個人的に)多数の文書にすると混乱することになるかもしれません。

以上言ってきたことは物事が完成に近づくにつれ、計算についての話し合いで問題を持つべきではないと言うことです - あなた達は一般にあら捜しがとても上手ですが、可能である場合我々は稼動前にいつでも問題を探し出すことでしょう。

・Stamina Loss [from CoNB DevBoard - 2000/11/14]
Gafferはジャンプするときのスタミナ消費に関し、斜体の質問へ返答しました:

...どうかお願い、「お願いですから」、ジャンプと中空蹴りの使用制限をしてください。ある程度のスタミナを消費するように

一言で言えば、そうです(あなたは私のデザイン文書を読んでいるのですか?) :)

・Armor and Clothing [from CoNB DevBoard - 2000/11/16]
それからGafferは、斜体の質問へ答えました:

追伸: アーマーの上に衣類を着ることは出来ますか?
追追伸: アーマーの色は変更できますか?
追追追伸: もしプレイヤーが色を変更できるとしたら、魔法の色も同じようにはなりますか?
追追追追伸: アーマーを身につけているけど、タキシードを着ているような見た目には出来ますか?

キャラクタは衣類よりも他の方法で、近距離では明確なものとなるでしょう。例として、最近の(そしてこれからの)スクリーンショットを見てください。

順番に:
追伸: ある程度は出来るし、ある程度は下になります
追追伸: 我々はアーマーの色を変えられますが、アーマーを染められるようになるかは分かりません(もしそれがあなたの質問なら) - それはデザイナー次第です。
追追追伸: 染め桶はある一定の色のみ染めることが出来、他の者は我々が使用するために予約されています。また、ある物は染めることが出来ないようにするかもしれません。
追追追追伸: 出来ませんが、ゲームをしている間、自宅でタキシードを着ることは出来ます。

・The Screenshot [from CoNB DevBoard - 2000/11/14]
以下はGafferからのものです:

今出ているスクリーンショットから、一般のキャラクタの外見にさらに多くの多様性を見ることになるでしょう(ええと、そう、私の記憶が正しければ、最後のは全身をpneumaticアーマーに身を包んだ人ですが、一般の、です:) あるいは、ビデオを見た人達にコメントを求めてください...そこには多量の異なる見た目になっています(トレンチコートを着て、mohawkを手に持つJuka、ですよね?)。

月の初め、人間をカスタマイズするために多くを費やしました(GM/画像ツールを使ってアイテムなどを作らねばなりませんでした) - ですから、ビデオ内にいた多くの人が「元々あった」キャラクタでした。今はより多くのキャラクタ作成が適切なものになり、異なる髪形、肌/髪の色などはより簡単に出来るので、ビデオ/スクリーンショット内でより多くのバリエーションを見ます。それは簡単な答えだと知っていますが、道理に適ったものです。そう、それとまた、多くの衣類/アーマーが入ったので、それも見ることにもなるでしょう。

ビデオ内に入れるため10〜12人を調整するのはとてつもなく大変です(「オーケー、今から水晶の森へ入って自分のキャラクタを変更、いや、Jukaが多すぎるし、君ら2人は同じ服装をしている、そして...」)- 我々が滅多にそうしない理由です。少なくとも今のゲームプレイを見せるのは、簡単になっています; ゲーム内へモンスターの一団を入れて、誰かがその近くへカメラを移動している間に戦うのです。少し問題のあることは、戦闘中死なない様にモンスターとウォリアーに回復呪文をかけるヒーラーをカメラ近くに置かねばならないことでした - 我々はまだ、「死なない」チートフラグを持っていないのです :)

・Graphic Engine [from Official TechForum - 2000/11/17]
UbiqはOriginに使用しているグラフィックエンジンに関し、以下の発言を行いました:

明確にすれば、私達はプログレッシブメッシュ技術ではなく、詳細段階(Level of Detail)技術を使用しています。プログレッシブメッシュでは、頂点(とそれにより構成されるポリゴン)は実行時に除去されることに対し、LODでは、あらゆる物体に異なる段階の品質の3〜5つのバージョンを実際に持っています。

PM(プログレッシブメッシュ)は非常にクールな技術なのですが、それに対する実験では、まだ準備ができていないとの決断を私達は下しました。PMはよく頂点の除去時に適切ではない選択を行うことがあり、それは奇妙なものに結果として生じることがあります。私達の美術はその制御を任すことは好みませんし、その問題を直すには作成時間とCPUパワーのどちらも必要とするのです。

他の問題は、他の技術、特に多くは着色/変形可能なメッシュを高速に再構築/テクスチャの張り替えを合わせて行うと、PMが乱雑になることです。

LODはほとんど同じ事を行いますが、総合的に見ればCPUの使用は少なく、美術の考え方により信頼できるものです。よくないことと言えば、それに対しより多くの作業時間がかかり、慎重に見ている人間にはあるLOD段階から別の段階へ「急に」移行するのが見えてしまうことです。幸い私達の美術はとても素晴らしく、Hyperionが記述したLODシステムを巧みを扱い、切り替わる瞬間はほとんど分かりません。

(どんな間違いがあっても許してください、私はプログラマーではなく、暇を潰している単なるデザイナーなんです)

・Interface Scaling [from Official TechForum - 2000/11/17]
Ubiqはインタフェースに関し、さらに以下のコメントを続けました:

インタフェースの拡縮に関して - 私達のインタフェースは大抵のゲームのように見た目がよく、画面に「はまるよう」にデザインされていません。その代わり、あなたの望んだ画面上のどこでもgumpを開き、設置できるUOとほとんど同じく、可能な限りカスタマイズ可能なものとしてそれはデザインされました。従って、私達のgumpは固定せずに浮動し、多数の解像度/ウィンドウサイズでずっとよく扱えるようデザインされました。

・Color Depth and Interface Icon [from Official TechForum - 2000/11/16]
その後、Hyperionは色数とインタフェースのアイコンに関し、さらにこれを追加しました:

32ビットカラーは、16ビットよりずっとよい見た目となるでしょう... うーむ... 65536倍はいいです。16ビットではうまく表せない、緻密なテクニックを私達は数多く使っています - CyntheのVoodoo 3上で作成され、彼女が掲載したスクリーンショットのいくつかにその結果(縞模様)を見ることが出来ます。

大抵の近代的なカードは、32ビットモードでも同様に能力を発揮することでしょう。24ビットモードは、ハードウェアでのサポートがとても不十分です - 私達はそれを使うことはないでしょう。とにかく、それはピクセルの点からいってよい意味はなしません; ハードウェアはちょうど2の累乗で整ったピクセルを好むのです。

インタフェースの構成部分は拡縮しません; もしそうしたら、よい見た目にはならないでしょう。

・Resolutions [from Official TechForum - 2000/11/16]
Gafferは画面の解像度に関し、以下の発言を行いました:

ははは、よく分かってますね - 我々のスクリーンショットが異なる解像度(と実際には色数)でキャプチャされているという事実に気づいた人を、私は今まで誰も見たことがありませんでした。その中のある程度は、(戦闘に関係する)ある程度のUI要素がまだ最終的な画像ではない(それは機能的ですが、どちらかといえば見苦しいものです)ために時に取り除いているため、実際には妙な解像度になっています。

出荷時にはどの解像度が利用可能になるのかに関して言えば - よい質問ですね。我々は考えられるある程度のバリエーションを与えるでしょうし、恐らくまた(UIアイコンは32x32ピクセルのままで現状では解像度に従い拡縮することはなく、3000x2000モードのときは恐らく豆のように小さくなり、300x200では画面からはみ出ることになるでしょうから)ゲームがプレイ可能な範囲の解像度に制限することになるでしょう。(そしてそうです、それらは実際の解像度ではありません。今は午前9:30であり、2つの計算をする能力が私にはまだありません)

・Processor Speed [from Official TechForum - 2000/11/17]
以下はUbiqからのものです:

CPUが束縛されるほど強力なグラフィックカードを持つことは可能「です」 - つまり、CPUはそれに命令を十分高速に与えられない、ということです。もしあなたがPII-400とGeForce NV25を持っていても、多くのその能力は結局は手持ち無沙汰になることでしょう。

コンピュータを手に入れるとき、近頃の私の一番のルールは、廃れを予測して計画を立てることです。もしあなたが(私のような)ハードコアなゲーマーなら、それらに不満がつのるにつれ、恐らくそのパーツをアップグレードすることを望むようになるでしょう。もしあなたが私のようであれば、ビデオカードは12ヶ月毎、CPUは18ヶ月毎にアップグレードしたくなることでしょう。ゼロからは始めず、あなたにそうさせるようなシステムを構築してください。成長/開発サイクルの終わりではない、その初期のマザーボードを必ず持つようにしてください。メモリと新たな周辺機器向けに余分なスロットを必ず持つようにしてください。あなたがしばらく持ちつづけると計画している構成機器を必ず最高品質であるようにすれば、それを取り替えずに済みます。目標はそのコンピュータを安っぽくせず、2番目に安くするようにすることです。=)

・The Client Team and The Server Team [from Official TechForum - 2000/11/16]
以下はVaxhackerからのものです:

この返答は非常に単純なものです - 私達は簡単には「クライアントのみ」と「サーバのみ」の部分へとチームを分けることが出来ません。それらが分けられていると考えることは便利だとはいえ、単に1つ、あるいは別のことだけに集中することは本当に可能なことだというわけではありません。

例えば、私は主にサーバに取り組んでいますが、初めのうちはクライアントが使うネットワーク層も作成しました。同じく(クライアントとサーバが共有している)物理学エンジンは、最初Skicatによって書かれました。そしてほぼ全てのゲームシステムはクライアント側とサーバ側のコンポーネントを持っており、それは一般的には同じ人間、あるいは人々によって導入されています。

・System Requirements [from Official TechForum - 2000/11/16]
Gefferは4MBのノート型パソコンでも動作するのかと質問されたとき、以下の発言を行いました:

Originは8M以上のカードでのみ動作するでしょうし、よりよいカードを持てば持つほど、よりよいゲーム体験になることでしょう。残念ながら現在の携帯型のものにはそう多くはありませんが、次世代の携帯型には恐らく含まれることになるでしょう。

・Item Decay [from Official TechForum - 2000/11/16]
以下はGafferからのものです:

これは技術的な質問というよりかデザイン上の質問ですけど、我々は今のところ、アイテムの腐敗のある程度の方式について計画しています。

世界中に横たわった状態で固定されていないものを世界から排除する、という意味で腐敗させることを我々は保証します。あるアイテムは使用することで劣化するある方式(それは大いにあなたの経済を手助けします)に我々はすることになるでしょうが、それには我々が確かに完成させる前に、多大な調整/テスト/理論立てが必要です。

・Monster Spawn [from Official DevBoard - 2000/11/17]
Ubiqからの発言です:

「現実的な」発生に伴なう問題は、よい持ち物を持って発生するモンスター(つまりアーマーを着たorc!)は最終的に狩られすぎることに反し、何も持たずに発生するモンスター(つまりコウモリはコールドを運べません!)は最終的に無視される、ということです。そしてもしモンスターが最終的に無視されたら、モンスターのモデルが間違いなく無駄になります。プレイヤーは利益を得られる最短距離を見つけるのがとても早く、バランスのとれた曲線を台無しにすることでコールドに取って代わる十分な経験値を与えてしまうだけです。

私達は適切な宝物にしようとはしていないと言っているわけではないし、冒険者の経済が私達の主要な焦点であるという事実は正しいです - 私達は職人を時代遅れにするためモンスターからの略奪を望んでいるわけではなく、その代わりに価値のあるものにしたいのです。ただ、重点は今まで通りゲームが楽しみであることを確かにすることだし、「現実的」にするよりも、ずっと強力なコミュニティにすることなのです。

・Seamless World [from Official DevBoard - 2000/11/17]
以下はUbiqからのものです:

全くそのとおり。私達のマップはUOがやっている方法で「継ぎ目のない」ものとなっています(横切って分かるサーバ境界線があります)。例外はあります - 例えばダンジョンは、継ぎ目なくはつながっていません。 何故なら主として、同じ世界にそれを置くと地上と地下にいる両方の人が遅くなるであろうからです。

・Playing a Game In a Window [from Official DevBoard - 2000/11/16]
ウィンドウモードでの動作に関するGafferの発言です:

我々は現在のところ、ウィンドウ内でプレイできるようにしています(実際、ビデオはウィンドウモードで撮られました。)とはいえ - 今だ出荷時にこれを可能にするかどうかは、2-3の理由のために未定なのです:

a) alt-tab(タスク切り替え)を許可しないゲームは、ハック/マクロプログラムの試みを「ずっと」少なくします(それはプレイエリアを広くし、我々にとって少ない(あなたの払う)サポート費になることなどを意味します)
b) 3Dゲームは慣例上、(OSの関わり合いが少なくなるので)フルスクリーンモードのほうがずっと早く動作しますので、ウィンドウモードで常に走らせることをサポートするためのコードと開発時間を増やす代わりに、我々は恐らくその様にデザインすべきでしよう。

とはいえ、これはまだ未定なのです。とにかく「多くの」人々は、苦労することなしにICQなどを使用する自由を持つことを好みます。我々はそのことをまったく理解しています。それはまた、ゲーム中に情報を得るためウェブサイトを快適に開けるようにもなります。もしハードウェアがサポートしているのなら、1度に2つのクライアントを快適に走らせることが出来ます(やはりその方法は、悪用される可能性が確かにあります)我々の開発の何人かはテストするためにその方法で走らせていますので可能性はありますが、あなた達が言うようにそれはプレイ不可能なものでしょう :)

ですから...それは未解決の問題なのです。私は意見に興味があります、もっともこの問題の最終的な分析はTyrantsでなければならないかもしれませんが。

・What types of clothing will there be? [from Official DevBoard - 2000/11/16]
以下はGafferからのものです:

層毎に使える、途方もない量の異なる衣類があります - ですから、あなたはpneumaticアーマーの上に外套を羽織ることなどが出来ます。そのいくつかを見るため、最近のスクリーンショットに目を通してみてください。

それはもちろん、着色も出来ます。多くの選択があります。

・More on Reputation System [from Official DevBoard - 2000/11/16]
Windfeatherからの斜体の質問に対する返答です:

何があなたを「わんぱくさ(naughty)のポイント」と「名声」の度合い両方を持つよう決断させたのですか? 私の考えでは、それらは常に似通って変動すると思うのですが、何故両方あるのでしょうか?? 2つの間で上昇速度が違うのですか? 何故2つの要素を持たせるよう決断したのか、ゲーム内の例えで教えてくれませんか?

もちろん。名声は、君が他の人に対して行ったことを反映するポイントのカウンタです。その部分を理解するのは、十分簡単です。「わんぱくさのポイント」は、他に呼ぶべきものが恐らくあっただろうけど、その時私は気取ろうとしていたのです。私のデザイン文書内では「わんぱくさのポイント」は実際、「PvP頻度変換機(Frequency Modifier)」と呼ばれています。それは攻撃者/略奪者/窃盗者のどの立場に関わらず、また攻撃された場合にも少しだけ君がどれだけPvPに従事しているのかを追跡します。

もし私がPvP変換機なるものを持っておらず、代わりに他の人間の名声を基にして君の名声に打撃を与えたら、「青PK」のような問題を抱えることになるでしょう: ある人間は倒す、略奪する、あるいは盗むことを決してせず、妨害やルート権利の略奪(kill stealer)などをすれば高い名声のままなので、倒すのに大変大きな損失になってしまうかもしれません。

誰が厄介ものであるのか、私はいちいち追跡できるわけはない(例えば、君はどうやって君の無礼な友人を追跡すればいいですか?)ので、私に代わってプレイヤーにそうさせることを私は選びました: 君は年中倒されていると、非常に高いPvP頻度の度合いを持つことになります。「この人間は確かに普通の人間よりもずっと多くPKされているな。多分彼はそうされるに値するんだな。」と、ゲームは考えるようになり、苦労せずに君を倒せるようになります。

教訓: もし誰かがOriginでの厄介ものになったら、その首を切り落としてください。何故なら、そいつは誰に対しても恐らく厄介者であり、例えよい名声であるかのように見えても、低い損失で倒せるからです。人々は自身の段階に応じ、常に上下することになるでしょう。

これで助けになれば :)

・Reputation System [from Official DevBoard - 2000/11/16]
Windfeatherは斜体で書かれたAshenの質問に対し、以下の返答をしました:

私達のPvPバッファがどれくらいあるのかを知ることは可能になりますか? もし私達が誰かを倒す、略奪する、あるいは盗んで、著しい量の名声/PvPポイントを失うとしたら、どれだけ簡単に見分けることが出来るようになりますか?

うーん...手短に言えば、「ノー」だね。以下に何故そうなのかを書いときます:

現実の調査ではペナルティの厳しさよりもむしろ、捕らえられる可能性のほうが人々が法を破ることから阻止することを示してます。

ちょうど今それがデザインされてるように、君が大胆に行動したり、無法者をプレイすると決断するのでもない限り、システムはすぐれた判断能力を持つ君を頼ります。その判断の一部は、もし君が暴力的な挙動を繰り返し行えば名声システムによって「捕らえ」られるだろう、有益な懸念なんです。

PvEの(対人ではない)環境を望みはするが、必要なときには(あるいは同意の上での)他の者と戦える能力を持ちたい典型的なプレイヤーのため、君のバッファは滅多なことでは尽きるようにすべきじゃありません。それは経時で回復します - 君の気性が激しく、ちょっとしたことであらゆる人を攻撃、略奪、盗んだりするのでもない限り、使い切ることないはずです。

システムを正しく動作させるため、典型的なプレイヤーに - 捕らえられることの恐れ - に用心する意識を浸透させる必要があります。もし私が君に誰かを倒すときの正確な損失、そして正確な現在あるポイントを教えたら、用心する要素を取り除いてしまうだろうから、反社会的なプレイ量を実際に増やしてしまうことになるでしょうね: どんな時でも罰せられずに済む(つまり、バッファの枯渇により犯罪を犯しても捕まらない)正確なことを知ってしまうでしょうから。

とはいえ、悲痛な(grief)プレイヤーの可能性のある世間知らず(つまり、世間知らずになるために「捕らえ」られること)のような行動に対して倒されるという、有益な恐れを落ちつかせるために君が持ってるバッファポイントの量には十分気前よくしたいんです。私のオンライン経歴を通じ、どの人間が剣が彼らの首に振り下ろされることを知っても行動を起こさないだろうか、数多くの事例を考えることが出来ます。

うちらはそれがどのようになるのかを見るため、ベータで厳密に見聞きすることになるでしょう。私の目標は、自身が礼儀正しく振る舞える、礼儀正しく武装した社会にすることです。

・Interface [from Official Discussion Board - 2000/11/16]
Medwyndからの発言です:

実際インタフェース画像の大部分は、ほとんどが仮のものです。とはいえ、帯状のツールとボタントレイから構成されるであろうものは今だ準備中です。帯状のツール内にあるスロットがファンクションキーを通じて利用されるのは間違いありません。水平のバーは、ヒットポイントと経験値のためにあります。ボタンのトレイに関して言えば、それはアイコンを埋めるために持ってきたものに過ぎません。あるものはアイコンと対応しない機能を持っていたり、ある場所はなにも起きないアイコンだったりします。ただ、そこには機能する持ち物、ペーパードール、そしてチャットボックスがあります。

・Concerning Number of Character Slots [from UO2 Vault - 2000/11/15]
Ubiqはキャラクタスロット数といくつかの問題に対する弁明に関し、UWOO@egroups.comメーリングリスト上で以下に続くコメント群を作成しました:

1つのスロットしかないゲームに伴なう問題は、多くの人々が2番目のアカウントを購入してこれを回避し、正当な方法でプレイをするプレイヤーをひどく不利な状態にさせるということです。

それを行う人数は重要なのです。私は知っています。引き合いに出された多くの理由のためにアカウント毎に1つしかキャラクタの持てないゲームに私は取り組んだことがあり、そして莫大な人数が2つのアカウントを購入しました。後ほどプロジェクト中に2番目のキャラクタを与えるという、コミュニティにとってはかなり不健全なものでした。

1つの破片世界(shard)のサーバはよい論ではない、といっているわけではありませんが、それが代理キャラの作成(muling)や悲痛なプレイを止めるであろう、ということが間違っているのです。それどころか、パワーゲーマーとハードコアな人達の落差が広がります。

---

結構です(けれどももし私がその方向性で以って論じたら、あなた達はタールに羽を沢山つけて我が道を進んでいたことだろうと私は思います)。やはり私の挙げている問題は、破片世界毎に1つのキャラクタ、ということです:

・とにかく代理キャラを作らせることは止められません。(キャラクタ間で直接受け渡しが出来るので、より簡単になってしまいます!)。
・「よい」プレイヤーが代理キャラを作らないこととは対照的に、それを行う悲痛なプレイヤーを助長します。
・最も金銭を持つ者が著しい強みを持つ、「金の」ゲームに変わります。

私はゲームを売ることは好きですが、その決定が引き起こすであろう何かしらの波紋は無視できません。

もしあなたが代理キャラ作成を止めたいのなら、それは結構です。ゲームデザインの決断を以ってそうすべきです。正直なところ、アカウントレベルでそれを試みることは、間違いなく失敗すると私は思います。そしてもしあなたが買わないとしても、一人のプレイヤーがどれだけのキャラクタを持てるようにすべきかを決断するとき、他の要因は代理キャラの作成と同じ位重要か、それよりもずっと重要であることは確かに間違いありません。

---

デザイナーが設置したNPCは、低レベルの代理キャラよりも低レベルの職人へダメージを与えます。低レベルの冒険者は、デザイナーが設置した鍛冶屋が彼らの必要とする初心者用の装備を提供してくれる場合、低レベル職人を見つける知識、見つけるために人と話す勇気、あるいは探しに行く忍耐力は一般には持ち合わせていません。それがNPCのベンダーが売るものを最小限の品質と量にする理由です。

人々は、彼ら自身のアイテムを制作するために代理キャラを作ることになるのでしょうか? それほど多くはいません。ギルドに奉仕をする鍛冶のキャラクタを作るよう、とある人間を説得することの方がありそうです。キャラクタ間で物を交換するよりもずっと簡単です。ただ、もし彼らがギルド全体に奉仕するとしたら、彼らは本当に「代理キャラ」なのか、あるいはコミュニティの重要な要素なのでしょうか?

2番目のキャラクタか1番目のキャラクタかに関わらず、低レベルの職人を世界の経済に関係させることを確実にすることは非常に大きなデザイン上の問題だということに、私は確かに同意します。幸いなことに、私達はそれを助ける2、3のアイデアを持っていると思います。

---

家族のため破片世界上に複数のキャラクタを持つ重要性は、とても大げさです。家族がお互いにプレイしたく(それゆえに2つのマシン、2つ以上のアカウント、そして2つのインターネット接続を持たねばならず、そしてそうです、これはあなたが思うよりごく一般的なことです)ても、お互いプレイしないことが嫌でも、その場合は単に違う破片世界でプレイすればいいのです。ただ、本当にお互いでプレイしたい(つまり、他に言える点は本当に何なのでしょうか?)

---

まず初めに、多数のゲームデザイン上の決断はお互い相互につながっているのです。私達の特色のある程度をテストすることは、私達がその全てをテストするためにUOへ導入するよりもずっと多くを必要とするでしょう。

次に、UOは私達のテスト用の場ではありません。それは忠実で献身的なファンの土台を持つ、自身の権利があるゲームなのです。開発チームは自身の優先リストを持っており、ある意味では、彼らの目標は私達とは違う、ということです。あるいはゲームへの「付加的な」特色(つまり、新しい特色として考えられるであろうもの)をテストするよう彼らを説得することは出来たかもしれませんが、UOを生活するにはより難しい場所にしてしまう特色をテストすることは、相当にまずいことでしょう。それはORIGINの出荷後、私達がUOを見捨てるという(誤った)憶説を強めるだけであり、Originという会社、そしてORIGINというゲームに対し、現在のUOプレイヤー達の間に敵意を生み出してしまいます。

心配しないでください、それはベータで私達が厳密に監視するであろうものです。=)

・First Look At Vesper [from UO2 Vault - 2000/11/15]
このショットに関し、それがVesperで「ある」という確認の後、Ahrimanはその都市について以下に続く発言を行いました:

Vesperは、新生Britanniaの南東沿岸にあります。それは本当に美しい都市であり、建築学、魔法、そして技術の驚異であるGreat Lighthouse of Vesperの本家です。Regent Moriahの技術禁止令反体制派、特にそれに不満を持つ者達にとっては避難所としての評判を得ています。

・3D vs 2D [from UO2 Vault - 2000/11/15]
UWOO@egroups.comメーリングリスト上のUbiqからのものです:

3Dは、2Dを凌ぐ長所を持っています。パーティクル効果は氷山の一角です。UO3Dでのアニメーションはスムーズで継ぎ目がなく、ずっと現実的です。その上、アニメーションの作成がずっと早いです。スプライトだと、新たな笑う社会的なアニメーションは考えられるあらゆる衣類で、考えられるあらゆるコマの位置を描かねばならないので、ほぼ不可能です。3Dだと、それは骨格だけに過ぎません。作るのに容易だし、ダウンロードも少しで済みます。

他の人々は、新しいものの追加がどれだけ楽で、ポリゴンのモンスターとスプライトのモンスターのダウンロードは相対的にどれだけ違うのかといった、他の利点について話をしています。その上、nVidiaと3dfxが示した非凡な能力の3Dを使うことの恩恵もまた、些細な問題ではありません。

多くの理由のためにカメラを静的にしており、不幸にも狂わしてしまうであろうUltima Onlieに既に存在しているバランスをゲームプレイの様式を主要なテーマにしています。例えば、Joshuaが先週送ってくれたピアノのスクリーンショットを考えてみてください。UOで出来ることはそういった驚くべき1つなのですが、好きな場所へとカメラを動かせるようにしてしまうと、その繊細な幻影は破壊されてしまうという事実があります。他にも3Dクライアントのプレイヤーは2Dクライアントを持つ人以上に視野の強みを持たせないことを保証するような問題があります。

私は実際、UO3Dチームが行ったことに大変興奮し、感動しています。私の兄弟がそのプログラマーの一人であるから、というわけでは全くありません。=) 即座に却下する前に、UOが大好き/大好きだった人ならやってみるべきだと私は思います。

・Server Side Language [from Official TechForum - 2000/11/14]
Gafferはサーバに使っている言語に関し、以下の発言を行いました:

サーバ側は多くのコードがC++ですが、ゲームに関連するコードの大部分は特に、除湿器(moisture vaporator)に大変よく似た言語であるPythonです。かなりクールな言語です、http://www.python.orgを見てみてください。

・Graphic engine [from Official TechForum - 2000/11/14]
以下は、Hyperionからのものです:

これは優秀な質問です。その答えは、多数ある質問の答えでもあります: 「何故あなたは、<Quake/Unreal>エンジンを使わないのですか?」

とても単純です: 異なる目標、異なるエンジンだからです。Originのエンジンもまた、屋外のMMRPG向けQuake3エンジンと同じ位3Dシューティングには適さないでしょう。

QuakeとUnrealエンジンは、局地的に固定された室内のゲートを基にした環境を描くためにデザインされています。私達のエンジンは、予測出来ない大規模な3D環境を描くためにデザインされています。

予測できない、とはBritain銀行内にどれだけの人数が入るかを制御できないことを意味します。キャラクタがどれだけのアイテムを地面に落とすのかを、私達は制御できません。同時にどれだけの呪文が唱えられるのかを、私達は制御できません。プレイヤーがどれだけそのアバターに衣類を着せるのかを、私達は制御できません。私達はまた、あるユーザの帯域、あるいはハードウェア能力がどのように他のユーザへ影響を与えるのかを見込む事も出来ません。大規模とは、私達の「平面」が何千平方キロメートルもあることを意味します。私達はこれら全ての問題を扱い、称賛に値するシステムをデザインしています。

ただ、痙攣を起こすような制御システムをくれるよう私達には頼まないでください。Originにロケットジャンプはありません。リアルタイムにファイアボールを避けることは、今日におけるMMRPGエンジンの理解を超えています。3Dシューティングに必要とされる瞬間のリアルタイムの反応には異なるタイプの描画とネットワーク構造を必要とし、QuakeやUlrealエンジンの分野に直接入ります。あなたが指摘したように、そういったゲームは10以上のユーザでのみ程よく調整されているのです。

きっと間違いなく、帯域と能力の増加に伴ない3Dシューティングはより多くのプレイヤーをサポートするだろうと私達は思います。10年が過ぎるまでに百を超える大規模な戦闘が起こることは、誰でも容易に想像できます。MMRPGが同時に10万ものプレイヤーをサポートすることも想像できます。そういったタイプのエンジンの技術がひとつにまとまることになるだろうかは、私にはよくわかりません。

・Infrastructure of World Design [from Official TechForum - 2000/11/14]
Gafferは世界を構築するのにどんなシステムを使っているのかに関し、以下の発言を行いました:

我々の世界に使う座標は、主要となる世界のマップのためにほぼ任意で高度に運用することが出来(局地的なオフセットに浮動小数点を用いています)、現に4次元座標システム(4番目はマップで、時間ではないです)を使用しています。ですから例えば、主要となるマップはマップ0上に(サーバがその全てを覆っていると仮定すれば)連続した座標一式を持ち、マップ1、あるいは2(あるいはn、256のマップがあると私は思いますが、もしかしたら65536(short)、あるいは40億(long)だったかもしれません、忘れました)に全く新しい大陸一式をほぼ無限に作ることが出来ました。もちろん、マップ上の全てを単に歩くことは出来ないので、他のマップへ行くために特別なつながり(ムーンゲート、あるいは別の特別な接続器)を置く必要があります - 基本的には別次元のようなものです。

我々の座標/マップシステム以上にサーバ容量によって、明らかに制限されます。我々が座標を使い果たす前に主要となるマップの大きさで数百もの領域のマップを作れるだろうし、40億の世界マップにするのも容易に変更出来るでしょうが、もしそうでなくても帯域の占有は少ないでしょう。

・Development Environment [from Official TechForum - 2000/11/14]
Gafferは開発環境について、以下の発言をしています:

クライアント側は、大抵の人々がPIIやPIII上でWindows2000、98、あるいはMEを動かしています - クロックは下から200〜300Mhz、上は733Mhz辺りまでです。きちんと開発できるよう、かなり多くのメモリを積んでいます(256〜512M)。サーバ側は2つ、あるいは4つのプロセッサでWin NTを、4つのプロセッサのIntelマシンでSolaris86を、そして4つのプロセッサでVaxhackerがスペックについてコメントせねばならないであろうSparcマシンを我々は走らせています。大抵のサーバが数ギガのRAMを載せ、黄ばんだ古くて大きなRAIDアレイであるデータベースサーバへ接続しています。

・The Geography Of Sosaria [from Official Discussion Board - 2000/11/12]
Ubiqは斜体の質問へ答えました:

大都市の大部分は今までと同じ場所にありますか? 多少は破壊されましたか? 大異変(cataclysm)後に小さな農村は出来ましたか? もしそうなら、既に名前はついていますか....?

あなたの質問へ順番に答えます:

1) イエス。
2) イエス。
3) イエス。
4) イエス。

これで助けになれば。