●企画課のアートを、実際のゲームで具現化する

Ｑ．Blade＆Soul 開発チームの、本人がする仕事と、プログラムチームの紹介をして下さい。

Ａ．リードプログラマーを担当している。
　　プログラマーとして、全体的な具現化と、政策的な決定をして、これを上手く行く様に作る。
　　うちの課は、他の所と似ていて、グラフィックエンジン，サーバーとクライアントに仕分けされる。
　　私は 3個のチームが調和して運営出来る様に、滑らかに調整する役目をしている。

Ｑ．ゲーム初盤に登場して死ぬキャラクターの張本人として、どんな気分ですか？
　　また、後半にも登場するのでしょうか？

Ａ．率直に言って、ゲーム内に私の名前が登場する事は、私の意志では無かった。
　　ペ・ジェヒョン PD が入れなさいと言ったので入れた（笑）。
　　他の開発チームの人々も多数登場するので、内部では一種のスタッフロール的な意味で受け入れている。

　　初めに出るや否や死ぬ事は、個人的には幸いだと思う。
　　2次 CBT をしてみたら分かるが、大砂漠地域で魂となり、少しまた登場する。
　　その後の話はストーリーと連携されている為、私にも知らせてくれなかった。

ゲームでは、主人公の師父として登場する。

Ｑ．「Blade＆Soul」 は、一般 MMORPG と比べて、多くの差を見せています。
　　プログラマーとして区分したら、どんな風に見ているのか知りたいです。

Ａ．普通と何が非常に違うかと問われれば、「本当に非常に違う」 と返事をする。
　　基本的にジャンルが武侠なので、プログラムチームの立場では、ゲームを具現する時、
　　アクションという点で差を置いている。例えば、軽功が代表的だ。

　　ペ・ジェヒョン PD が、「MMORPG でするなと言う仕業は全て行った」 と言った事がある。
　　その言葉通り、スキルの様な事をデタラメに使う事も、「Blade＆Soul」 の代表的な差異で、
　　私たちゲームのアイデンティティだ。
　　「してはいけない事を、どんな風に具現する事が出来るか？」 たくさん悩んだ。

Ｑ．武侠ゲームを作ってみて、どんな点が難しかったですか？

Ａ．武侠ゲームでの私たちの挑戦課題は、アクション性を生かすというものだった。
　　実は、既存アクションゲームの戦闘を 「Blade＆Soul」 でも具現する事は、技術的に可能だ。
　　ただ、この様にする場合、サーバーが堪える事が出来ないという問題が起こる。

　　その為、一般的なアクションゲームのアクションを試みるのは無謀だった。
　　アクション性のピントを合わせる事が、一番難しかった。
　　どんなにみても抽象的な試みだった訳で、初盤から開発を進行していって見ても、
　　どんな模様で作っていけば良くなるのか、それは誰にも分からない。
　　初盤のデザインは、後半に行くと益々他の模様に変化していきました。

　　結果的に、どんな風に、何を作らなければならないか、
　　それが分からない状況で開発を進行したという点が、一番難しかった。
　　「するな」 と言うのは、終えて見なければ分からなかったからだ。

既存アクションゲームの姿を MMORPG の方式で具現しようとした。

●既知の問題は解決、最適化は現在進行形

Ｑ．2次 CBT を進行した所、スタン，掴み，反撃スキルなどに従って、
　　同期が取れない問題が良く露出していました。解決する方法はありましたか？

Ａ．CBT を進行する理由は、ゲームが完璧では無いので、多様なレポートを受けたいからだ。
　　実は、CBT 以後、ユーザーが見るよりもっと多くの問題が入って来て、対策を用意している。
　　「完璧でしょうか？」 と問われれば、「完璧な事は何処にあるのですか？」 と返すしかない。
　　しかし、問題点、特に、たくさん知られたバグ等は、大部分が解決した。

Ｑ．「Blade＆Soul」 は、グラフィックに比べて最適化を良くしたと思います。
　　今後は、どの位まで最適化を進行するつもりですか？

Ａ．最適化は、開発初期から気を使った部分だ。ターゲットを取って最適化をする。
　　率直に言って、開発者たちは良いハードウェアを使っている。
　　開発のパフォーマンスが良くなければならないからだ。しかし、それに合わせたら困る事になる。
　　初めに最適化をせず、「何年後（サービス時点）なら、ユーザー達のハードウェアスペックが
　　向上するか？」 を考えてはいけない。

　　私たちは最初にグラフィックリソースを作る時から、アートチームと会議をたくさん行い、
　　悪く言えばケンカもたくさん行った。
　　今、「Blade＆Soul」 の最低スペックは、GeForce 8600 位に合わせられている。

　　ユーザー達には公開しないが、内部的には 「超低スペック」 というオプションがある。
　　「超高スペック」 オプションも存在する。外部には見えない、多様なテストを進行しているのだ。
　　現在公開されたスペックよりも低いスペックでも、プレイは可能だと自信がある様に言える。

Ｑ．MMORPG で、アクションの判定性をどんな方式で解決したのですか？
　　また、ユーザーの疲労度の部分が問題になるのではと思われますが？

Ａ．ダメージ判定の場合、「Blade＆Soul」 はノンターゲッティングでは無い。
　　その為、判定問題は自由な方だ。コンソール用アクションゲームの様に見せようと努力した。
　　しかし、その中で入って行くシステムはそれでは無い。
　　簡単に言えば、「Blade＆Soul」 はターゲッティングゲームであり、
　　これを補助する為、オートターゲッティングを導入したに過ぎない。

　　ユーザー達は同期化を憂慮していますが...。
　　例えば、ノンタゲッティングというのは、全スキルが範囲スキルという言葉に似ている。
　　この場合、同期化による問題が起こるが、私たちではそんな問題では無い。

　　開発チームの時点で見られる判定の話しは、何種類かがある。
　　一般コンシューマゲームで見せる滑らかさをもっと出せる様に、気を使っている。

　　操作の疲れ感に対しては、CBT を通じて得た資料を見た感じ、楽観的に見ている。
　　コンテンツの強弱調節を通じて、解決していかなければならないと思っている。

Ｑ．一般的な MMORPG と違い、「Blade＆Soul」 はアクションが先行モーション後判定だ。
　　これを具現するのは難しい事ではありませんでしたか？
　　また、多くの人が殺到して負荷が掛かる場合、判定の問題もあるでしょう？

Ａ．一応 2次 CBT を通じて、十分な負荷テストは出来た。
　　予備で残しておいたサーバーを投入した位、予想より多くの人々が参加した。
　　おかげさまで、私たちが予想した線を超えてテストする事が出来た。
　　しかし、大きな問題は発生しなかった為、問題は無いと思う。

　　後判定に対しては、一つのシステムで作られた事では無い。
　　いちいち全て説明すれば、プレゼンテーションが一つ出来る位膨大な情報がある。
　　簡単に言って、遠距離スキルの場合、既存 MMORPG は発射する瞬間に判定が入る。
　　後判定は、その入って行く時間を延ばす方式なだけだ。

　　近距離スキルも、これに似ているシステムが入っていると思えば良い。
　　動作の大きいスキルは前判定にせず、後から判定を行う方式だ。
　　「Blade＆Soul」 では、全てのモーションが終わった後に判定を行っている。

2次 CBT で予備サーバーを追加した日の姿。

Ｑ．アンリアルエンジン3 を使っていますが、長所と短所はありますか？

Ａ．アンリアルエンジンを使う理由を、大きくは二つだ。
　　一つは機能だ。多くの事を無理無く行う事が出来るからだ。
　　また、他の一つはツールセットだ。
　　MMORPG の開発量を無視する事は出来ず、この二つは非常に大切だった。
　　アンリアルエンジンは、この二つに対して基本スペックが良い。
　　私たちが持って来て、改善しながら使うのには良いエンジンだ。

　　短所と同時に一番苦労した部分は、他のエンジンよりインターフェースが不便だ。
　　MMORPG で要求するユーザーインターフェースの量は、FPS で要求する物とは違う。
　　こんな部分は、私たちが一から作ったと思えば良い。

Ｑ．早いうちに 3次 CBT を行うと思いますが、プログラムパートで一番重点を置いている部分は？

Ａ．安全性だ。サービスを控えている為、コンテンツを準備して具現する事も重要だが、
　　安定的にサービスしなければならない部分は非常に重要だ。
　　最近はサービスを控えている状況の為、ゲーム以外の物も作らなければならなかった。
　　私たちはゲームさえ作ってはいけないかと言う冗談もたまに使う。

●してはいけない物などを具現するのが大変だった。

Ｑ．アクションを具現するのに当たり、基本的に 4個の制限された操作で開発したのですよね？

Ａ．全体的には 8個 だが、基本的な操作は 4個だ。
　　しかし、スキルの数はとても多い。条件によって使うスキルが違う。
　　それを簡単にする為に、オートターゲッティングと、条件によって使用するインターフェースを選択した。

　　これを作る作業が一番難しかったし、同時に開発のコンセプトだった。
　　条件に合わせるという事が、言葉は簡単で、実際の技術的でも大した事では無かったが、
　　「企画のスキル配置」 と 「私たちの具現」 と 「実際の戦闘」、この全て考慮された状態で
　　作らなければならなかったからだ。
　　モデルを作って適用して見れば、次々と考えが変わってしまう。

　　その為、今は具現方式もたくさん変化させた。
　　楽に使える様に、企画ではスキル配置図を多くして実験を通じて作った。この過程が長かった。
　　開発過程では終始、実際では、今もずっと変化を加えて改善を行っている。
　　長い間開発する過程自体が大変だと思っている。

スキルツリーは、状況と条件に従って、今も変化し続けている。

Ｑ．物理エンジンはどの位使っていて、また、これをどんな風に活用するつもりですか？

Ａ．オンラインゲームで物理エンジンを積極的に活用する事は大変だ。
　　サーバーが物理エンジンを回さなければならないが、現時点でこれを具現出来るサーバーは
　　存在しないと思う。
　　代わりに、クライアントでより自然に見せる様にしている。

　　「Blade＆Soul」 は、衣装からグラフィック的表現に至るまで、物理エンジンを積極的に使っている。
　　ただ、物理エンジンはハードウェアの加速が、現在ブランド毎に違っている。実装も簡単では無い。

Ｑ．ゾーン方式を短いローディングで解決したが、どんな意味があるのですか？

Ａ．「Blade＆Soul」 は、シームレス ワールドでは無い。
　　今は短いローディングをするゾーン方式で作られているが、開発初期はローディングが頻繁だった。
　　早いローディングを企てた意図は、言うのも面倒。ロードが見たくなかったからでしか無い。
　　それで、予めローディングをさせる方法を考えついた。
　　ユーザーキャラクターの移動予測アルゴリズムを通じて、最大限ローディングを減らしている。
　　これは現在も行っている事だ。
　　参照で、ハードウェアが良ければローディングは更に早い。

Ｑ．グラフィックリソースや、コンテンツ等を含めて、クライアント容量はどの位と見ていますか？

Ａ．2次 CBT のクライアント容量が、多分 6GB 程度だっただろう。
　　強いて言えば、他のゲームに比べては少ない方だ。
　　既存ゲームのクライアント容量が大きい理由を述べると、
　　一番大きな容量を食うフリー レンダリング ライトマップを持っているからだ。
　　開発初期では、Blade＆Soul も容量の圧迫が内部であった。

　　容量が大きくなってはいけないいう共感はあった為、これに合わせて技術を選択した。
　　基盤となる技術はあるのに、様々な理由で、これを選択をしなければならない。
　　シームレスとゾーン方式の差も、これに起因する。
　　私たちは最適化と容量に投資する事にした結果、こんな選択により、比較的少ない容量になったと思う。

Ｑ．企画チームが要求する事の中で、絶対に反対した事とか、デタラメだと思った事はありますか？

Ａ．実は、一番反対したのがオートターゲッティングだった（笑）。
　　開発を進行するのに当たって、デタラメで良くない企画というのは、
　　確かでは無い場合の数を並べる企画や、抽象的な企画などだ。
　　しかし、企画で初期デタラメだと思った事が、大部分良く開発する事が出来た。
　　オートターゲッティングの場合も同じだ。

Ｑ．最後に、ユーザーや後輩プログラマー、ペ・ジェヒョン PD に言いたい事は？

Ａ．ペ・ジェヒョン PD に言いたい事は、
　　「オリジナルなんて作らず、私たちも他人が作る様な事だけを作った方がいい」 と言う事だ（笑）
　　開発チームには、「是非家に帰りなさい」 と言いたい。
　　開発を進行してみると、自らの意思で家に帰らない場合が多い。

　　プログラマーは仕事に酔えば、ずっと仕事を捕まえている癖がある。
　　プロジェクト全体で見たら、これは良い姿では無い。
　　自らコンディションを管理しつつ、ゲームを開発した方が良いと思う。

　　後輩たちというより、プログラマーたちに言いたい事はある。
　　ゲーム業界に入ったと言っても、ゲームを沢山すれば良いプログラマーになれる訳では無い。
　　つまらない話だが、良いプログラマーになる為には、学校の授業をよく聞く事だ。

　　冗談で言っているのでは無い。ゲームが好きな事は良い事だが、
　　それだけでは好きな友達に会える物では無い。
　　プログラムは、ゲームをすればコードが見える訳では無いのだ。
　　人を選ぶ時も、学校の勉強が上手な人の方が選ぶ様になる。
　　明確な事だが、一番重要な事なのだ。