Powered by Movable Type 6.7.1
« 2008年9月 | Home | 2008年11月 »
この手のゲームをやっている人には、PCパーツにも一定以上の興味を持っている人が多いのではないかと思いますが、総合PCパーツ店の九十九電機さんが民事再生法の手続きを取っているそうです。
僕もTSUKUMO eX.にはよく行っていたクチなので、このニュースを驚きと残念な気持ちで読みました。確か自分が中学生くらいの頃には既にあったような。
常に秋葉原最安なお店というわけではなかったと思いますが、主要パーツをセットで買うとお得感がありましたし、普通に品揃えは豊富、接客態度もこの界隈では最もいい方なので、パーツを買う時はまず最初に寄る店って感じでした。そう言えば、今使っているPCのCPUとマザーボードはこのお店で買ったものです。
民事再生法の手続き開始ってことなので、どこかいい買い手に巡り合えて、また何事もなかったかのように繁盛していたらいいなと思います。応援の気持ちも込めて、とりあえず週末に何か買ってこようかしら。
今週は「個人用の2階建ての家」制作週間です。
メタセコでのモデリング→カラーマップ作成→O2PEへのインポート→シャドーボリュームの作成までは終わりました。衝突検知用のジオメトリを作る手前で、今夜は終わり。
衝突検知用のジオメトリは積み木を組み合わせるように作らないと、ほとんどうまく検知してくれない気がします（壁をすり抜けてしまう）。これまで結構な数の建物を作ってきましたが、面の数や形なのか角度に依存するのか、どこまで許容されてどこからは許容されないのか、このジオメトリのことを良く分からないままです。検証するのも面倒なのでこの手のモデルの時はいつも、元モデルをコピーせず、積み木を置くように0から作っています。
自分がよく分からなかったので、分かりやすい訳になりませんでした。すみませんね。
でも遵ﾜpan醇Tl弟?さん的にはなんか重要なことを成し遂げたらしいですよ。
===========================
Breaking the 32 bit Barrier(32bitの壁を破ってます)
Written by Ond醇yej 遵ﾜpan醇Tl
Tuesday, 11 March 2008
原文: http://www.bistudio.com/developers-blog/breaking-the-32-bit-barrier_en.html
メモリの最適なハンドリングを探す旅は、結末を迎えられそうか?
仮想アドレス空間の問題
ArmA が発売されてからの最大の問題のひとつは、仮想アドレス空間が引き起こす安定性と互換性に関する問題でした。これは注目に値する多くがグラフィックボードのドライバが同時にシステムの他の部分が広大な仮想アドレス空間を同時に使用しながら、多数の仮想アドレスを使ってたくさんのデータを格納するゲームならではの問題です。この問題はArmAを発売する前から始まっていました。OFPの時を振り返ると、最初のグラフィックカードが256MBのRAMあるいはそれ以上を使用していました。同じシステムの上で稼動させた場合、OFPはArmAより安定性に優れているとは言えませんでした。これはメモリマッピングで使用されるファイルアクセスにその理由があります。素早く、手軽に使っている間は、メモリマッピングはたくさんの仮想領域を使用します。暫定回避策として、私達はこれらをマッピングすること無しにファイルにアクセスする手段を提供しました(-nomapとしてよく知られるあのコマンドラインのことです)。ArmAのために、私達はファイルへのアクセス方法を完全に設計しなおして、ファイルが全てに対してマッピングしない作りにしましたが、通常のファイルはAPIを実際には使用します。同時に私達は、私達がバックグラウンドでテクスチャとその他のリソースをロードできるようにするため、オーバーラップ I/Oに切り替えました。私達も、そしてみなさんも、これだけでは十分ではなかったと理解したと思います。
空の限界?
現在起きていることは、OSが各アプリケーションに対して割り当てるアドレス空間が2GBまでであることです。2GBと聞くと、その制限がどうしたのと思うかもしれませんが、実はあまりいいことではありません。何らかの方法でコンピューターはもっと多くのRAMを積んでいます。今、最も御知らせしたい重要なことは、メモリの物理サイズのことではなく、私達が言いたいのはアドレス空間のことです。アプリケーションは、2GBまでのアドレス空間の制限があり、たとえみなさんのPCが、物理メモリサイズとして512MBであれ4GB以上積んでいたとしても、それはここでは全く関係ないのです。
2GB は、全てのアプリケーションが必要とするので、これらに使用されます。そして最近のグラフィックカードは、数百MB単位で食いつぶします。悪くならないように、大きなパーツを消費しないようにするシステムコンポーネントがありますが、しかしあちらこちらで消費してしまうと、小さな単位の複雑なフラグメントされた空間が発生します。私の経験では、システムが極端に不安定にならないようにするために、ゲームコードが割り当てる仮想空間は約700～900MB以上がないとほとんど不可能だと思っています、また隣接する大きな単位で割り当てなくてはならないというわけではなく、むしろ10～100MBサイズのチャンク(塊り)であれば良いと思っています。悪夢としないよう、ドライバーのプログラマーはリソースの中のアドレス空間の制限の事実を知らせようとはしないように見受けられます。そしてドライバーは、仮想割当の失敗をハンドリングしてくれるわけではありません。ゲームといものは、一旦、大き過ぎる仮想空間を割り当ててしまうと、画面上に三角形のゴミが散乱したり、時にはシステムがリブートを始めたりと、とても奇妙なことが起こり始めるのです。
将来、64ビットへ
長い間、64ビットOSへの移行と64ビットアプリケーションとしてゲームをコンパイルがこの問題を解決すると考えられていました。このような問題解決は、 ArmAでは現実なものとして実現にはなりませんでした。なぜならばまだ多くの人に64ビットOSが普及していないこと、一方でこの変化にはリソースと時間が掛かり過ぎるからです。
私達は、いくつかのパッチ（このフォーラムトピックを見ても）を組み合わせた結果、様々な経験と最適化を遂行しています。しかし完全に動いているわけではなく、各ソリューションの性能や安定性はいくつかのシステムの上に被ってしまいました。ArmA2の開発を続けている間、私達はもっと多くのテクスチャとメモリを割り当ててやる必要が出てきました。そしてもっと強くこれらの制限を強く受けるようになり、ゲームはたくさんの異なる全てのシステム環境の上で安定して動作させることが出来ない時代に来てしまいました。
アドレスのないメモリ
そしてある日、あるアイデアが、いつもと同じようにどこからともなくこんなアイデアが浮かびました。このようなアイデアが普段からも、実装されたあるシステムが、それはとても明確に見えましたし、しかし以前によく使ったものとして一度も聞いたことがない、付け加えるとそれは私が持ち合わせてことを誇りに思ったことがないものでした。私はこの技術を「ノン・アドレッサーブル・メモリ・ストア(アドレスのないメモリへの格納)」と名づけることにしました。
この技術は、ファイルAPIマッピングの使い方を基礎としています。はい、みなさんも聞いたことがあるかもしれません。OFPでトラブルを引き起こしたのと同じAPIのことです。ですが、これはあの時とは異なる方法で使います。ファイルを読まないように使用しますが、メモリは割り当てるという使い方です:
* ゲームを初期化する際、十分なメモリをファイルマッピングを作成するAPIに予約、占有することにします。物理メモリを消費しますが、アドレスは仮想のものです。
* ページデータを格納または参照する際に、一度アクセスが完了したものが再び破壊されたMapViewOfFileを使用して、一時的なビューが作成されます。これは64KBというとても小さな仮想空間を使用します。形式的に、いくつかのページのみがメモリにマッピングされ、これを同時に使用します。
Windows は、このパターンのハンドリングに適していて、空間がページファイルをバックアップしている間に、ページファイルの書き換え量が0になって、全ての情報が物理メモリの中だけでハンドリングされたことにより、使用可能な物理メモリが十分にありさえすれば、実際にそのような方法で動作します。この格納タイプにおける確保されたメモリは、仮想アドレス全てに対してマッピングされることなはく、実際のマッピングされたファイルのオフセットによって識別されるのです。各アドレスは、キャッシュの中身を詠みに行く時だけ、一時的に割り当てられます。これは独立した位置(何らポイント情報は何ら含もうとしない)にあるファイルキャッシュの中にデータが格納されていた事実が可能にしたことに感謝をしています。
バリアは破られた
.jpg)
テクノロジーの常識では、32bitアプリケーションが使用するメモリは32bitのアドレス空間に限定するのが普通です。このサイズは、フリーなRAMとファイルをマッピングするサイズの限界によってのみ制限されます、よって32bitOSでは管理可能なデータは約3GBまでで、64bitOSの場合はそれ以上ということになります。これは私達がやっているArmAでのことではありませんが、とても小さな改良をすることで512mb以上のキャッシュファイルを持ったのをみた体験があります。ですが、私達がやみくみにさくさんのデータを読みこんだりしないように、他のアプリケーションのためのオプション機能を付けるかもしれません。ファイルのキャッシングに制限はありませんが、格納すべきコンテンツには限界があります。もうひとつ重要な限界があって－ポインターは一度アンマップされたメモリは無効になるのと同じように、通常は永続的なポインターとしての使い方で、アプリケーションというものは決してポイントの中にメモリを割り当てることはしません。
ArmAに持ってきたのは、あなたの所有するPCの搭載RAMに依存した100から 500MBのサイズの内部ファイルキャッシュであり（-maxmemコマンドで指定する量も設定できます）、これはほとんど仮想的な空間を使いません。数百MBをシステム用に残すようにしとけば、だいたい十分であると言えます。既に修正されたものとして有名な「Cannot allocate system memory surface(システムメモリを割り当てることが出来ません)」のように、ほとんどすべてのシステムにおいてゲームによって使用されるメモリに制限がないことを確かめるテストを行いました。
近日のパッチで使用可能になります
そして、このメモリのハンドリング方法は、1.11のパッチでリリースされるでしょう。みなさんも気に入ってもらえればなと思ってます。
ここ数年、Newsweek誌(日本語版)を定期購読している。
社会人になってまもない頃、何となく格好いいビジネスマン気分に浸りたくて、駅売りのスタンドで度々買っていた。読み終えて家に持ち帰ると妻も読むことだしと、ある頃から面倒くさくなって定期購読を始めた。米軍をはじめとした兵士さん達の写真もちょくちょく載ってたりして、暇つぶしにもいい。
この雑誌は、基本的にはアメリカ人の視点でアメリカ国内や世界の重大ニュースを報じる形式の雑誌なんだけれど、これが結構、日本に与える影響を少し前から予告するような記事が多い。例えば日本にまだブログという言葉がなかった頃、アメリカではブログという日記形式のホームページが流行っている記事を読み「なにそれ?」と思ってたら、そのうち日本でも流行り出して「あぁ、Newsweekに書いてあったあれか」と思ったこともあった。SNSも然り。9・11より前にアルカイダというヤバいテロ組織があることも教えてくれた。
特にサブプライム問題の特集を最初に読んだ頃、「こりゃ大変なことになるかもね」と思ってたら、数週間した頃に日本の新聞にも取り上げられるようになった。それからしばらくして、今の世界的な金融危機がやってきた。まめに情報をチェックしている人には何てことのない雑誌かもしれないが、面倒くさがりな自分にはまとめて教えてくれる貴重な情報源だからだ。
最近、定期購読を来年も更新してくれませんか、という封書が届いた。
もちろん更新することにした。
最近また忙しくなってきて、制作のペースが落ちてきてますが、とりあえず今日は2時間ほど取り組みました。
ポリゴンのワイヤーをご覧になると、また怪しい作り方をしているように見えると思いますが、できるだけ少ないポリゴン数、テクスチャサイズ節約、不自然に見えないシャドーボリュームの3つを合わせて、バランスよく取れるArmAでの王道的な作り方がまだ分からないためです。なので、毎度試行錯誤しているわけです。
以前までは、大きめの正方形テクスチャの中に全てのポリゴンを押し込めるように作ってましたが、今回は128x512のサイズで1枚の外壁テクスチャを横方向にタイリングして貼りつけ、屋根と窓はそれぞれ別のテクスチャを用意してやってみようかと。窓を壁と接続させず少し浮かせることでポリゴン数を節約しようかと迷いましたが、シャドーが奇麗に出るか不安だったので、こんな作り方になってしまいました。
とりあえず外壁は目論見とおりいったので、明日は屋根テクスチャを描こうと思います。
現在、3種類目となる住宅を作っているところです。
とりあえずモデリングは終わりました。
明日からテクスチャ作業。
今回は、外装で3種類、屋根で2種類くらいのテクスチャを作成して、テクスチャパスの書き換えだけでモデルは同じなんだけど見た目が異なる住宅が6個できてしまう楽チン技を試してみたいと思ってます。
清涼飲料水の自動販売機を3種類用意しようと思います。
C社とD社のは、まだ各種LODを作っていないので完成ではありません。シャドーボリュームも未だですが、このモデルに関しては掛けない方がアクリル板が綺麗に見えていいんじゃないか、と思いました。手抜きせずに、シャドーボリュームにおける凹みをちゃんとくり貫けばいいのかもしれません。でも、マニュアルを読むと最短間隔とかに制限があるみたいです。
1年以上も前のSpanel兄弟の投稿ですが、発表当初の意気込みについて語られています。
=========================
ARMA 2 Expectations(ArmA2に期待されること)
Written by Spanel Bros.
2007年10月1日
原文: http://www.bistudio.com/developers-blog/arma-2-expectations_en.html
ArmA2の発表をしたところですが、きっとみなさんは今、もっと詳しい情報を知りたがっているのではないかと思います。
ArmAと比較して、私達はARMA 2用に次の改良を取り組もうとしています。
* ロールプレイングゲーム的な要素とダイナミック(動的)なイベントを集めたストーリー
* AIの改良、CQB(近接戦闘)は特に。
* 臨場感をの向上、連携するためのハンドシグナルや挑発するAI
* 現実世界にある実際のワールドデータを元にした、よりリアリスティックな地形
* デュアルコア、マルチコアシステムへの最適化
* PCとコンシューマー機でのリリース
そして、そんなに重要ではないけれどいくつかの変更点かもしれませんが、ArmA2ではもっとゲームを楽しめるようにお手伝いしたいと思っています。
* 顔のディテールの向上(訳者注:顔ではなく"見た目"かもしれません)
* 植物のディテールの向上
* 生息する動物
* 建物が破壊される様の改良
AIの改良、特にCQB(近接戦闘)面で
ほとんどの人が既に先日のGC2007の後のTiscaliで公開されたAIのビデオを見たのではないかと思います。割といいリアクションをたくさん、私は見かけました(つまらない粗探しみたいなのもありましたが)。提供したビデオは、初期の段階に撮影したもので、リリース版ではみなさんが今まで見たことがないようなもっと感動的なゲームをお届けできるであろうと私は確信しています。AIがスクリプトで制御されること無しに、プレイヤーが命じたまま完全にダイナミックに動作するこのシステムこそが、最も優れた部分です。
ロールプレイングゲーム的な要素
主要なシングルプレイヤーモードにおいて、プレイヤーは米国海兵隊の偵察チームの指揮官の役割を担うことになります。作戦名"Harvest Red(赤色の収穫)"における大規模PKO部隊の一部として派遣される中央司令部の特殊部隊の精鋭の中の小規模な特殊チームとしてこの役割を演じることになります。ストーリーについてもう少し語ると、プレイヤーはリソースマネージメントに対し責任を持つ立場となって、戦場シミュレーションの深い部分を通じて進行を手助けするロールプレイングの要素があります。成功に向けて必要不可欠なものは、エリアにおける今の実際のメンバーと非戦闘員とのコミュニケーションです。ゲームプレイの最中、完全に詳細を把握、コントロールするために、どんな時であれプレイヤーは小隊の各メンバーに切り替えることができます。
AIが使う挑発とハンドシグナル
私達はみなさんに中古品を売りつけようとしています。。。。というのは冗談ですが、ある意味においては正しいかもしれません。でも怖がることはありませんよ、これは再生された中古品になるでしょうから。ここではたくさAIがスマートにそしてもっと人間臭くなるようなリアルさを出すためのたくさんの作業が行われています。この特別な作業が何なのか、一部をお教えしまょう。私達のAIの弱い部分を認識エリアにおける弱点を確認していると、私達はとても興味深いことに偶然気が付いてしまいました - 私達のAIはかなりスマートになっていますが、それをお示しするのはちょっと難しいです。で、私達が何を"セールス"しようとしているかですって? - AIが、思考、挑発、あるいはその他のアニメーションを使ったコミュニケーションを行うようにさせることです。AIに何らかのスマートさをもたせないとしたら、もっとよく見せるべきだし、もっと生活感や、熱中度を増加させるべきでしょう。
リアリスティックな地形
Charnarus(訳者注:ArmA2の舞台となる島)は、ポスト・ソビエトな架空の国です。このマップはチェコ共和国の北部にある本当の風景をベースにしており、大きな港湾がある海岸の工場地帯、松の木の深い森、山岳の村がある約100キロメートル四方の地形がカバーされています。環境は、特別な演出が施された秋の季節でデザインされています。もっと詳しい情報や私達がゲームマップをリアリスティックに作ろうとしたアプローチについては、Landscape Almost Realの項を読んでみてください。
デュアルコア / マルチコアへの最適化
マルチコアの出現は、どのデベロッパーに対しても本物のチャレンジであることを意味しています。高フレームレートの達成に向けて、私達のエンジンの中でも可能な範囲のひとつであると私達は理解しています。ですが、公園を散歩するような簡単なものでもないことも承知しています。
デュアルコア、マルチコアテクノロジーへの転換はとても大きな変更点であり、これまでの10年間を通して全てのコンピューターを比較するものではありませんでした。いくつかのパラレルに動かすテクノロジーは30年も前から開発されていましたが、メインストリームなプラクティスになることは決してありませんでした。そして開発全体のチェーンを通して、これに向けた態勢が完全に整っていませんでした(プログラマーへの教育も含めて)。
ArmA2はこの領域において重要な進化を遂げることができると私達は間違いなく確信しています。私達は粒が粗い並列処理ときめ細かい並列処理をミックスさせる狙いがあって、多くの他のゲーム開発者がやろうとしていることと類似の方法で行おうとしています。AIのスマートさ、たくさんのユニットの所で、フレームレートの改善が見込めるようにしようとしていますが、しかしながらこのテクノロジーの実装と十分なテストのことを考えると、本当に約束するにはまだ早すぎるかなと思っています。
コンシューマー機でのリリース
ArmA2 をコンシューマー機でリリースを実現する様々な方法を探している所です。いくつかのハードコアなPCゲーマーは、あまり歓迎しないでしょうし、どうしたものかゲームのレベルが落としてやさしくするのではと心配する向きもあるでしょう。他方、コンシューマー機との融合してこのような戦場シミュレーションをプレイできることを楽しみにする向きもあるでしょう。
ともかく、Bohemia Interactiveにとって、これはロジカルなステップにしか過ぎません。PCゲーム業は全体的に下降基調にあり、特にそれは北米市場において顕著です。PCプラットフォームは互換性や安定性の面で様々な影響を受けますし、そして短期間でWindowsVistaへの移行は、短期間ではこれを手助けしないことにも注目しています。よい点として、私達は既にOperation Flashpoint EliteをXboxに移植したという点で長い間もがいてきた経験があります。戦場シミュレーションをコンシューマー機の上に開発するまたは遊ぶという意味では、好ましい点、好ましくない点を私達は既に分かっています。そして、このハードへの知識実績と共に、私達はArmA2というケースでのプラットフォームへのアプローチは、商業的な発展への一歩だけでなく、両方のプラットフォームでゲームをすることを手助けになるとも感じています。私達がしたいとのすべては、もっとアクセスしやすくそして現在のArmAより裾野を広がるようにすることです。OFPとArmAで製作した全てを消し去りたくないし、必要がないものにしたくないからこそ、もっと熱中できて、オープンなシミュレータゲームの世界にリアリズムを持ち込む私達のセンスを変えずに済む余地を残しておきたいのです。
次回に向けて
読んでくれてありがとう。私達はArmA2の機能、特長についてもっと詳細な情報をこのブログでお伝えして共有していこうと思う。次のブログ記事は、BI開発チームの他のメンバーに書かせることにするよ。
Killing Bugs(バグ潰し)
Written by Ond醇yej 遵ﾜpan醇Tl
2008年2月16日
原文: http://www.bistudio.com/developers-blog/killing-bugs_en.html
バグ修正のプロセスについては、いくつかの"背景となるシーンの情報"があります。
バグ修正は、ゲーム開発における大事な仕事です。この仕事は全く楽しくありません、なぜかと言うとほとんどの場合はクリエイティブなものではないですし、でも必要不可欠な作業だし・・これさえなければ、製品としてリリースさえしてなければ。
このブログエントリーでの狙いは、Bohemia Interactiveの中でのバグ修正プロセスをどのようにして組織的に行っているかを簡単に説明することにあります。いくつかの慣習を説明していくとその中には、この産業に共通する慣習もあれば、私達の会社での特殊なやり方があるかもしれません。
製品寿命においてはいくつかの異なるフェーズが存在します。そしてバグ修正にはそれぞれ少しずつ異なる方法があるのです。みなさんがバグセクションを使うことができる、あるフレキシブルな形式化は、最適化の問題としてみなされることがあります。バグを修正した時、その修正によっては、みなさんはちょっとしたボーナスを受けることになるでしょう(あるいは、未修正のバグが引き起こすペナルティといった形で、自分で見ることもあるでしょう)。バグを修正するコストとして挙げられるもの、それは時間だったり、お金だったり、作業だったり・・・。そして時としてそのコストは明白ではないかもしれません。プログラマーの側面からみたら簡単な修正でも、ゲームプレイの面では重要なインパクトであったり、更なる広範なテストが必要になったりもしますから。
バグの修正
最初に、単独のバグを修正する場合を見てみましょう。これは通常、いくつかの段階を経た上で実施します。
* バグリポートを読む
* それをもう一回読んで、理解を試みる :)
* バグが引き起こしている原因が何かを探し出す。
* バグを修正する
* 修正バージョンを展開する
素晴らしいバグレポートは、決定的な重要性を持つものです。素晴らしいバグレポートとは、人は修正に際して、その人自身の目で事象を確認しますから、それを段階的に再現してくれるものを指します(あるいはデバッガー、またはその人自身の扱うセンス)。素晴らしいバグレポートとは、再現の段階を短く区切っていること－もし再現までのステップが複雑であったり、追いかけるのが大変だったりすると、バグ修正にかかるトータルコストが増大します。（訳者注: 「バグレポートしてくれるんだったら、自分らが後で再現しやすいように、長文かつ抽象的にたらたら書いたりしないで、再現条件を簡潔に区切って報告してくれよ」と言いたい気持ちをオブラートに包んで、曖昧に書いているようです）
作成 - ゲームのビルド
設計から開発された製品がベータになると、新しい機能が実装されます。
バグの元となるもの:
* ゲームにおけるチーム作業に起因する人の問題
* ハプリシャー(販売元)へのフィードバック
バグによるペナルティ:
* ワークフローへのインパクト - 作業から入ってくる何らかのバグは防げますか?
バグ修正にかかるコスト:
* 修正するための時間
* テストするための時間はそんなに重要ではありませんが、このステージは大規模なゲームテストはいつでも私達の前に居続けます。
計画されたバグ修正のキャパシティ:
* チームの各人は、週に1日はバグ修正に専念すべきです。
仕上げ - バグの修正フェーズ
ベータの状態からゴールドに進むと、たいていの場合、新しい機能を実装することはありません。出てきたバグを修正するのみで、既に盛り込んだ機能をたまに改良するだけです。
バグの元となるもの:
* パブリッシャーの要求 - パブリッシャーは製品を受け取らないこともできます、なぜならば"クリティカル"であると彼らが考えたいくつかの事象があるからです。このような事象は修正を必要とし、あるいはいくつかのケースでは私達はパプリシャーを交えてコミュニケーションを取る必要があります。そして時として「これは重要ではないんだぜ」と納得してもらう時もあります。
* 内部テスト - 製品としてリリースすることに立ち塞がるバグを見かけることがあります。
* クローズな外部向けベータ
バグ修正のコスト:
* 修正に向けた時間 - これは明白なコストです。事象を修正するのに必要なものは、プログラマーであったり、アーチスト、設計者であったりします。
* 試験に依存する中身に費やす時間: AIバグは代表的です。AIの修正のいくつかは、ゲームのプレイアビリティに強烈な変更を伴うこともあります。リリース日が迫った頃にAIのバグが見つかった時は、それがリリースを遅らせるほどクリティカルなものでない時は、後日パッチとして修正することを前提に進めることもあります。
バグによるペナルティ:
* 製品に対する悪い評価がされることを背負うリスク、レビュー記事が悪くなり、セールスに影響する結果に繋がります。
* ワークフローへのインパクト
計画されたバグ修正のキャパシティ:
* バグの修正は、チームの中でも最も最優先のアクティビティです。
サポート - リリース後のメンテナンス
リリース前に修正することができなかったものは別として、私達さえリリース前には知らなかったバグを修正します。
バグの元となるもの:
* ユーザーからのフィードバック - これこそみなさんです。様々なチャンネル(技術サポート、コミュニティのバグトラッカー、フォーラム等)によって、バグに関する不平が上がってきます。
バグによるペナルティ:
* 悪い評判が付いたことによるセールスへの悪影響
バグ修正にかかるコスト:
* 内容によって左右されるテストの時間 - これはとてもいろんな問題をはらんでいて、このステージにおいては一般的にはパブリシャーやその他からの品質保証に掛けさせてくれる資金提供はないのです。(訳者注: デベロッパーの瑕疵責任になるので、デベロッパー自身の資金の中で解決しないとならない)
* 修正にかかる時間。既に開発下にある次の製品に影響を及ぼすかは定かではありませんが、バグの修正は旧製品が新製品のスケジュールに何らかの影響を与えることもあります。新製品と関連のない修正事項などは特に。(訳者注: 例えばArmA1で出たバグが、ArmA2に影響するものだとしたらそれはコストではないけれど、ArmA1にだけ現れるバグだとしたら、それは ArmA1のコストとなってしまう、という意味)
* ここでいう興味深いシチュエーションを言うと、修正コストというものは、既に開発中にある製品に対して開発、テストされたものに修正をかけることが重要な意味を持つということです。ArmAのパッチではいくつかのバグ修正を含んでますが、これを引き合いに出すと、ArmA2の修正に繋がる時があったりするのです。こうして時々起こる修正された事象ですが、これはとても重要なやり方ではありません。移行に掛かるコストとしての修正は比較的低めですが、 ArmAの中の修正ではこれらがよく含まれていました。
計画されたバグ修正のキャパシティ:
* もしもゴールドの締切日にたくさんの既知のバグがあると、これらは相当な量の時間を修正作業に割き続けることが一般的でしょう。それでユーザーへのインパクトは最小限に留める、または減らすことができるのです。時々ですが、後日、これら全てのことについてキャパシティを割り当てないままにしておいて、ある時に単独または小さなチームを編成して短期間で一気にバグの修正に専念することもあります。
初めてノーマルマップを使ってみました。
右側の画像の手前にある自販機の方が、ノーマルマップを使って窓に反射効果を掛けてみたものです。
画像じゃ分かりにくいですけど。
実際に見ると、土台のコンクリや扉のところなんか程よく凹凸感が出ています。
ですが正直、自分としては微妙な感じ。
ノーマルマップを作る手間隙とテクスチャに倍のファイルサイズをかけて表現すべき効果かなぁって。やりもしないで批判するのもアレなんで、今回やってみたのですが、建物ごときにはこんなのいらんのじゃないか、と。まぁ、四角くのっぺりとした形状の自販機に対して、ノーマルマップの効果がイマイチだと言っても恥の上塗りでしかないんですが。
ただ少なくとも自分なら、自販機に凹凸表現があっても気付かずに通り過ぎる自信があります。作ってしまったのでこのまま封入しますけど、今後は適材適所で使うかどうかって感じでやってこうと思います(これから作る塀モデルとかでは使うと思います)。
もちろん、戦車とか航空機とか人体とか気合入れて作られるユニットは、できうる最高の技巧表現でもって作られることに何の異論もありませんし、ノーマルマップを否定しているわけではありません。ただ重くなりがちな市街地に置く建物にはこんなのいらんだろ、ってだけです。
最高の表現で作られるユニットが十二分に活躍してもらえるよう、僕が作る建物群が無駄にリソースを費やして足を引っ張ったりしちゃいけないわけですよ。(描くのが面倒くさい、というのが最大の理由ではありますが)
とりあえずカラーマップを描き終えて、メタセコからO2PEに持ってきて、Visitor3で設置して、ArmAのミッションエディタで表示させるところまで来ました。リアル自販機と同じ寸法なので、自分的には満足してます。
dammage=treeにして、バズーカ砲みたいのを撃ち込んでみたら、一枚の平べったい板になって横たわっていました。別個でダメージモデルもちゃんと作んないと駄目みたいです。何でこんな面倒くさい仕様を実装したんだ。OFPと同じモードも残してほしかった。全部をdestruction=noにしてやりたい。
次の作業は、ノーマルマップとアクリル板が反射するマテリアル設定。
あるのとないのとで、どれだけこの自販機の質感が上がるのか試してみようと思います。
どちらかというとArmAのQ.G.に関係する話ですが、BISのDev. Blogの記事の一つを訳してみました。
========================
Portoからコンニチワ
Ivan Buchta
2007年11月8日
原文 : http://www.bistudio.com/developers-blog/greetings-from-porto_en.html
こんにちわ、僕はPortoに関するいくつかの情報を共有してみたら面白いんじゃないか、と思ったんだ。僕らのゲームマップのほとんどは、本当に巨大なんだけど、Portoだけはちょっと違っててね。なにしろたった2kmの長さと700mの幅しかないのだから(本島のエリアは1km四方であることを意味します)、銃弾を装備したタクティカルギア、フラックベスト、バックパックを着て降り立って、ライフルを握って走り回るまでは、この島はとても小さく見えるかもしれないね。モチベーションの背景にあったのは、むしろマルチプレイに適そうとコンパクトに作って、小さなマップにしようということがあったんだ。マルチプレイのシナリオ全体をやりやすいようにね。Portoは、ハードウェアに負担をあまり掛けずに、たくさんの戦闘車両を巻き込んで素早く乗り降りしたりする中規模サイズの戦場を簡単に作ることができるんだ。
Portoは、公式拡張パックであるARMA: Queen's Gambitに収録され、Sprocketidea.comのオンラインストアやその他の販売店を通じて全世界で遊ぶことが出来ます。
この土地の背景にいくつかの"ストーリー"を含ませたかったんだ、Sahraniからそう離れていない海沿いのどこか遠い場所で起こる現実世界をみんなに感じて貰えるようなね。PortoはSahrani王国の管轄にあって、Sahraniの南部の海岸から遠くないんだ。ArmAのキャンペーンで述べたように南部のSahrani王国と北部の民主Sahrani共和国との間で紛争がおきている間、SLA軍が島を占領し、それをRACSとアメリカの同盟軍が打ち破ったよね。大昔はアラブの強大な武器商人が重要な貿易港として使っていて、でも現在では死んだ魚の匂いや密輸入したアルコールと倦怠感が漂っているのがPorto。今日では、Portoは船舶の航行ルートからも外れ、非常に美しい魚場とダイビングポイントがあるだけで、でもPortoの市民は観光の後の"夢のビーチビレッジ"の崩壊になんか興味がなくてね。
Porto のロケーションにはいくつかの鍵があって、それはアクセシビリティとバランスを取ることに注意を払って、全てのことを設計したんだ。最初にしてもっとも重要なのは北の外れにあるPortoの市街地。ここには港湾地区があって、町の中心にはイスラム寺院と市場があって、と。町の大きさはParaisoや Bagangoと比べると、一般的なディテールは高い。長い間、私達は新しい道路と歩道と一緒にArmAのオリジナルコンテンツのみを使っていたからね、だけど僕らはこの町には特長が圧倒的に欠けているんじゃないかと感じていたんだ。終わり頃になると、僕らはVBSからイスラム風の塔を借用してきて、町の中央にまっすぐに伸びるところに置いてみました。街の中の大きなアイコンで示したその塔は、プレイヤーが完全にアクセスすることが出来て、167段の階段をあがって最上部まで上ることができます。
西に向かう道路を進むと、ほどなくしていくつかのバンガローとコテージがある放棄された海辺のキャンプに辿り着くことでしょう。細部については話せませんし、聞かないで下さい。南部の海岸沿いの良い散歩道、東には小さな岩、島の西端には岬があります。岬から、小さな島にある放置された軍事無線施設のマストを見ることができるでしょう。もし北西に向けて1kmほどボートを漕ぐと、砂の浅瀬に横たわる廃船を探検する機会が訪れることでしょう。中に入る時は、注意してくださいね。古びた廃船というのはとても危険なんですよ。あなたが船の幽霊が出るという地元の怪談を信じてないならばね。
島の東エリアも、観光にはうってつけです。西部よりオオカエデの森がいくつかあって、もしあなたが町から北に向かって進もうとするなら、Largoへ続く道の左側に岩の丘のところで、朝を迎えてみてください。僕は不思議に思うんです、もしあなたが埠頭から難破した車も止めることができたら－Portoの市民はその環境を気にかけないように見えるってことを。海岸を東に沿って進んでみるなら、Largoという小さな漁村に辿り着くことでしょう。ここについては多くを語りたくありません、よろしければ周りの空気を読んで、Marauder's Mojitoとという地元の水兵が開くパブで一杯やってみてください。
地元住民が環境を気に掛けてないの、Portoに戻る道路が改善されていることでしょうか。狭い上にでこぼこした地面に、嫌な匂いが立ち込めてきます。この道を西に向かって進むことを忘れないで下さい。僕は南部の海岸の丘にある灯台に立ち寄ることを強くお奨めします。ここの岩場は、防衛上の要害としてとっても魅力的なんです。18世紀には固定銃座がすえつけられていましたし、岩場は地元の都市開発のために切り出されていきました。そして気をつけてくださいね、この場所に集まる住民は・・・蛇と蠍ってことで有名なんですから。
マップを開発する過程において、この地形を使ってマルチプレイのテストを広範囲に渡って行い、建物やオブジェクトのレイアウトをたくさん変更してきました。Portoの戦いに、無数の開発者が大規模に戦って、何人かの設計者が都市強襲部隊の地獄に向かいました。頭上から降り注ぐデテクターからの無慈悲な銃弾によって、ズル賢しこくベテランスキルの連中の血がPortoの土地に撒き散らしていったのです。友軍はみんなに警告しました: イスラムの塔は一見、狙撃に最適な場所のように見えるかもしれないけど、最初の仕事はそこからだからね、と。：）
海上自衛隊館山航空基地で開かれたヘリコプターフェスティバルに行ってきました。
都心を抜けるのに大混雑して、到着したのはだいぶ遅い時間になりましたが、木更津に帰っていく陸自ヘリの飛行展示を見ることが出来ました。
館山なので海はSH-60J,SH-60Kはもちろん展示されていましたが、他に陸がAH-1S,UH-1J,CH-47,OH-6,UH-60とLAV,HMV、空がUH-60J、それとユーロコプター(ドクターヘリらしい)も来ていました。
館山は比較的、来訪者が少ないようで、他の見物客に遮られずゆっくりとそして360度を観察できるのでお勧めです。
僕のPentax istDSの通算シャッター回数がようやく1万ショットを超えました。本当に撮影好きな方からしたらかなり少ない筈ですが、自分にしてはよく撮った方ですよ。フィルムで言えば277本ですぜ。1万を超えたら新しいカメラを買おうかなんて漠然と思っていたので、ボーナスをあてにして次期機種を検討したいと思っています。
自動販売機を作ってます。
雨の中、メジャーを持って寸法を測ってきましたよ。ちゃんと実寸仕様(H180xW100xD69)です。
通行人にじろじろと見られました。
交番の近くにある販売機なんで、ちょっとびくびくしながら。
いつもなら、立方体モデルにテクスチャをぱっと貼って手早く完成させてしまうのですが、今回は凹みを入れたりアクリルパネルを入れたりして、ちょっと奢りました。100ポリゴン超えてます。さすがにペットボトルとか缶のモデリングは止めましたが。
病院名に全く意味をありません。ありふれた名前ってだけ。
手抜きしまくったお陰か、約1週間で完成しました。
後は病院にありがちな、「ご案内 内科 整形外科・・・」みたいな看板でも用意してやれば、きっと本物っぽく見えてくるんじゃないでしょうか。しょぼいモデルとテクスチャを隠すため、ちょっとした小物を足すことで、何とか本物っぽくみ見せようという浅ましい魂胆です。
それと病院なので、隣に調剤薬局を置かないと駄目ですね、うそ臭くなってしまう。パチンコに景品交換所、病院に調剤薬局、これ日本の風景では基本です。
今度材料になりそうな薬局の写真を撮ってきます。
BIS公式サイトのDevelopers BlogにあるARMA Technology Insideを翻訳してみました。
ArmA2でのマップの仕様は、ArmA1とも異なる(進化する)ように読めて、ちょっと困りました。
=====================
ArmAでの内部技術
Written by Ond醇yej 遵ﾜpan醇Tl
Monday, 04 February 2008
原文 : ARMA Technology Inside
http://www.bistudio.com/developers-blog/arma-technology-inside_en.html
このエントリーでは、コンピュータゲームの開発で得た新しいテクノロジーに関するいくつかの経験について、私はみなさんと共有していきたいと思います。願わくば、最大の効果が使用された新しい機能のために必要とされる作業に興味を持ち、そしてこの複雑さに対する理解を深めてもらえればと思います。
衛星画像の利用
ArmA の開発中盤の頃、ビジュアル面での技術はほとんどOperation Flashpoint:Eliteで使用した技術を利用していました。その段階で、私達は他社のゲームのビジュアル性と比較し分析を行いました。すぐに私達は、すくつかのエリアにおいてArmAには重要な欠点があったことを認識しました。そして、地形のバラエティさとディテールにおいて、その欠点が顕著だと考えました。以前のシステムでは、もう限界が来ていました(その最大の限界は、サーフェイスのタイプが40m四方のグリッドとして定義されたことです) ので、巨大で多様性とディテールが豊かな、もっと大きくもっとフレキシブルに地形が使えるよう、私達は抜本的に作り直すことを決断したのです。システムは、一ヶ月あまりで設計し、実装することができました。システムはMegaTextureとして知られるものと良く似たものですが、それとは関係なく自分自身のものとして開発しました(事実、私達がこれを実装した時、MegaTextureの技術はまだ公表されていませんでしたから)。私は特別な何かを主張するつもりはありません、何かというのはCarmack氏(訳者注:「Doom」や「Quake」の開発者。MegaTextureはDoom3で使われたらしい)でえ、「技術は誰が見たって分かる」と言ってたわけですから。
綺麗な窓のようにこれらの全てが見えることでしょう。しかしながら、リアリティはもっと複雑なものです。最初の繰り替えしにおいて、地形製作ツールはとても大雑把で動作の遅いものでした。小さなデータの時は、このツールはそれなりに動きましたが、製作過程において32GBものソースデータを要求するSahrani島では、とても遅いわ、落ちまくるわでした。
更に悪いことに、現在の地形表現が作成された時、Sahrani島でのほとんどのデザインと編集作業は既に完了することが想定されていました。島の全体が架空のものとしてデザインされ、そして現実世界のデータとして使えるものが何ら存在しないのです。ステージとして新しい世界全体を建設することが可能ではありませんでした。結果として、Sahrani島ではこのテクノロジーを、以前できとことと同じように使用することができません。仲間のIvanは、Landscape Almost Realの回で、「ArmA2と一緒に変わるべきだ」と書いたように、ArmA2はこの地形に関するテクノロジーを活かすことになるでしょう。ただしその頃には、このテクノロジーはゲーム界全体のデザイン傾向でみても既に知られたものになっていることでしょうし、もっと良い結果を引き出しているかもしれません。
アニメーションのコントロール
アニメーションシステムと一緒に、Operation Flashpoint:Eliteから受け継いだ第1世代のシステムを既に持っていました。ユニバーサル･シェーダーのソリューションをベースとして、アニメーションは"Animation Controllers"の意味によって意味づけされたものから分離されたように見えるでしょう。この方法によってアニメーションは、統合され、相互にレイヤー間をまたぎ、あるいは複数のアニメが、航空機の車輪のような部類ですが、これがひとつの"state change"としての描写を使えるようになります。その結果、完全な一連の動作として可動するよう、アーティストがターゲットとする機能は何で、彼らが期待すすべきものが何かをはじめから知った上で、それを可能とするツールを作成し、アニメーションのテストを行いました。
これはゲームが Goldの過程に進む数週間前のことです。アーチストが物理的な運動にすっかり興味が行っている間、彼らのリアクションを観察しながら、こう説明しました。「見てくれ、この全ての車輪とガジェットの動きを。これから全てのビークルモデルがこんな動きができるように今から作り直そうぜ」こういった特別な好機が来た日のために、このような習熟の時間を予定にいれておくべきでしょう。
テクノロジーは、熟成を必要とする
最初の段階から長い時間がかかるのが、テクノロジーの実装というものです。それがうまく使えるようにするには、私達は次のものを必要だと思っています。
1.使用可能なテクノロジーを持っていること
2.それらのためのコンテンツの作成を可能とするツールを持っていること
3.それが使えるように要員に教育してあること
4.経験のある要員がいて、かつその利点/弱点を熟知していること。
結果として、テクノロジーが使われるようになる前には、通常の場合、少なくともひとつのサイクル(世代)を経ることになります。
パターンは分かっているのか?
何にも邪魔されず、私がここにつらつらと書いている間にも、自分達がやろうとしていることに立ちふさがろうとする何かが現れてくること事実です。通常は、テクノロジーが最初に生み出され、そして熟成の時を待ちます。同じことが、頂点シェーダーやピクセルシェーダーの時にも、またマルチコアCPUのアーキテクチャや(SSEのような)CPUへの命令セットの増強の際にもありました、いやあります。これらテクノロジーの第1から第4ステージのタイムラインの完全に読み取る練習を私は今後もしていくことでしょう。
ArmAへの建物の移植作業を続けてます。(本当はArmA2へのつもりですが)
テクスチャの解像度はOFP時代と全く同じですが、僕的にはさほど違和感を感じずに済んでます。BIS純正の建物を一緒に並べてないからかな。
移植にあたり、せっかくなのでセルフシャドーだけかかるようにしてるわけですが(マテリアルはいじってない)、やっぱり影がかかるだけでも、なんかいいなぁと思ってしまうのです。
せっせこ15個くらいの建物の作業を終えたら、久しぶりに何か作りたくなってきたので、個人病院みたいなものを作ることにしました。このくらいの形状ならモデリングに時間はさほどかかりませんが、やっぱりテクスチャがねぇ。時間掛かるのです。
今後の作業省力化計画も考えて、今回はテクスチャのタイリングと、窓テクスチャの使い回しでどこまでやれそうか、をテーマにしようと思ってます。うまくいけば、看板とベーステクスチャの差し替えだけで、もう一個別の建物が出来るようにしたいなぁと。
こうして楽はしてるんですが、壁全面をタイリングでやると、テクスチャのファイルサイズを小さくできるとかのメリットはあるけれど、縦横両方向にタイリングするので、雨だれとか、汚れとかね、こういうのを表現しにくくなって、どうしてものっぺりしてしまうというか、ヤッツケ感が強く漂うのです。上手い人はそこも巧く何とかしちゃうんでしょうけど。
先日、GachopinさんがリリースしたPS-1/US-1/US-2ですが、それを報じるBIS Forumのトピックを読まれた方はいらっしゃいますか?
哨戒飛行艇の話なはずなのに、「BOHはどうなってる?」みたいな質問が多く、ちょっと笑ってしまいました。楽しみにしてる人は、まだ世界にいるんでしょうね。
僕はvehicle系の制作で3つ続けて挫折したわけで"some people who making JSDF model in japan."ではないから、無責任なことは言えませんけど。
BIS公式サイトのDeveloper's BlogにあるARMA 2 - Building Destruction （ArmA2における建物の破壊）の日本語訳です。
============== 以下、訳 ==============
ArmA2における建物の破壊
Written by Ondrej Spanel
Tuesday, 20 November 2007
原文: http://www.bistudio.com/developers-blog/arma-2-building-destruction_en.html
全ての破壊できる建物は、どこに行ってしまったの？（ずっと前から）
ArmA2のアナウンスの後、予測される2大特長である、動的なビルの破壊とロールプレイングゲーム的な要素はどうなっているの、というに件に関するたくさんの質問を貰いました。
"みんな墓場に行ってしまったのかな？"とも言われたことがありますし、私達が見たフォームの中に描写されるだろうか、BISは意図的に隠しているのか、なぜだ？とも。
このブログでは、その質問に対して回答していきます。
破壊できる建物について
Game 2の特徴のうちの一つである動的に破壊される建物のデモンストレーションを行った時、またはこれについて私達が語った時、これを見た人からたくさんの好評を貰いました。
私達が実現できたこと:
■利用できるようになった動的に破壊できるいくつかの建物のプロトタイプがあります。破壊シーンはとても印象深いものになっていますし、物理シミュレーションも使えています。そして永久に持続するものとして動的なデブリ(残骸)として残ります。
私達が実現してないこと:
■変化した環境に合わせて、AIがリアクションを取ること
■マルチプレイ時での問題
■大規模な環境で広範囲に使うのに十分な最適化技術
■破壊できる建物を能率的に作成するためのパイプライン（作業工程の流れ）
戻りますと、私達はこれらの問題はそのうち解決できるだろうと願っています。残念なことにリアリティとは異なるかもしれません。オリジナルのフォームが必要とするやり直し作業を解決するアイデア、特に最後の項目を解決するのが困難すぎたことで、この問題を解決するためにたくさんの時間と作業負荷を私達が投資してきたことは、確かに悪い意味での事実でしょう。
私達が抱える問題から学習し、いくつかの設計のやり直しがありました。そしてその後にArmA 2 では、破壊できる建物を次のように見せることにしました:
■ArmAでの破壊をベースとする
■建物は独立した組み立て式のパーツの集合体とする
■壁と残骸の落下に物理シミュレーションを使う。
■残骸が永続的に残るのはやめる
私達は解決方法と、ゲームに対して動的に破壊される建物が生み出す効果について考えてみますが、実装がそんなに簡単ではないのです(そしてデータの用意も)。シミュレーションのために必要とするCPUパワーのこともあり、AIとマルチプレイ両方への親和性も考えなくてはなりません。
私達が実装に向けて努力していたものがなくなって、私達がかつて言っていたことが無くなったら、少なからず失望する人がいることは理解しています。しかしこの決定を下すことが私達にとっても簡単なものではなかったこと、そしてこの方法を決断したことがみんなに理解されることを願っています。なぜならば、私達はみなさんのために開発を行っているこのゲームが最もベストなものになったことを私達は分かっていたからです。
RPG elements ... stand by
ロールプレイングゲームの要素については・・・・準備中です。
Game2の大きな特長として宣伝していたRPG要素は、非スクリプトの会話形式です。それがあるとどんなことが起こるんだ？時として完全にスクラップしたり、削減したりするのか？このブログでの次回の記事で詳しくお伝えします。
一年以上前の記事ですが、BISのDeveloper's BlogのLandscape Almost Real(ほとんどリアルな景観)を訳してみました。
============== 以下、訳 ==============
原文: http://www.bistudio.com/developers-blog/landscape-almost-real_en.html
ほとんどリアルな景観
Ivan Buchta
2007年9月20日
私達の会社では、まるで現実であるかのような景観を創り出したいという大志をいつも思っていました。なのでコンスタントにツールを改良し、私達の技術に磨きをかけてきましたが、そしてついに現実世界の田園地方のイメージを最善の形でArmA2に持ってくることが可能になりました。私達は北ボヘミア地方の忘れられた土地を選び出し、野生と丘陵の環境を安定かつ大きなスケールの戦場にして皆様に遊んでもらえるのではないかと思っています。
現実世界の景観は実際にある土地の構造を提供し、全てのビークルと武器のプラットホームを使用できるようにし、実際に存在する驚くほどとても小さな戦闘やその時間、瞬間を皆様に提供して兵士の生活をプレイヤーに体験してもらおう、というのが私達設計者の観点です。もちろん、戦闘はArmA2の中で主要な体験をするでしょうし、現実に戦闘が散在するような景観になるでしょう。そのような戦闘によって私達は数ある戦争ゲームの中で皆様がかつて見たことがない印象深いものになることを願っています。
私が知っている最新のディテールをもっていくつかの場所を作り直したいという大志が常にありました。幸運なことに、ゲームプレイとビジュアル的な外観について、私に思い出させてくれるあるいは忘れさせてくれないそれ以外のことが周囲にありました。あなたが人間に素晴らしい何かのプレイを与えようとした時、そのリアリティは時として捨て去らねばならない時があります。それが意味するのは、生み出した全てのパーツが含む現実の田舎の風景を丸写ししたものをお見せするわけではありませんが、大雑把に地形をベースとしたゲーム環境となるということです。しかしながら、私達は、Chernarus地方の北部を構築することをひとつの目的にしてこれを創り出すべく、空撮写真や正確なGISデータベースを含む大量の現実世界のデータを参考材料として今なお活用しています。
自由な芸術性を確保するために海岸線を応用するべきでしたが、残念なことに北ボヘミア地方には海がありません。上の画像から比較できるように、私達が最近取材に行ったチェコとスロバキアの国境付近の山岳地帯から強い印象受けたこの森林地帯の構成を選択することを決断しました。地図上のリアルなカウンターパートと比較して、エゾマツ系の木が広がるそこは、さらに"山岳地方"っぽく表現させることを間違いなく手助けしてもらえそうだったこと、そして私達の当初の目的である「対立勢力による反乱・内紛に満ちた東ヨーロッパのどこかの山岳地方の国」に完全にマッチしていたからです。
昨日、今日と過去の自分のモデリングしたお店を中心に移植作業を進めました。
移植といっても、セルフシャドー用のLOD作りとディレクトリ構造、テクスチャパスの変更くらいなんですけどね。ノーマルとかマテリアル作りをしてないので、激しく手間がかかるわけじゃないです。
で、昨日書いた記事のようにBISのDevelopers Blogの続きを訳してると、ArmA2のマップの大きさが225平方kmだと知りました。これってArmA1より狭くなってるんです。狭くなるのはいいとして、225平方kmというのが不思議。これってArmA1と同じ10mメッシュと考えたらサテライトテクスチャのサイズが15,000px x 15,000pxになり、こんな半端な数がありうるのか不思議に思われたのです。
メッシュサイズがもっと狭くなるのかなとも思いましたが、どうも整数ではなさそうです。するとこの辺もまた仕様が変わるのかなと思うと、早く詳細が公開されないかなと気になってしまいました。
