SFC期DQシリーズにみるタスク指向からオブジェクト指向設計への転回

オブジェクト指向設計やUIのモードレスネスを扱った記事には普段からアンテナを張っているのですが、

先日、この記事が偶然目に留まりました。そして内容に触発された形で(タスク指向設計とオブジェクト指向設計の比較という擦り尽くされた感のあるテーマではありますが)自分も有名JRPGを参照しながら書いてみようと思い立ちました。ちなみにポケモンでは初代でキャラクターを遅延読み込み的に表示させている挙動が好きです。

この記事で取り上げるJRPGとは「SFCオリジナル版ドラゴンクエスト6」と「SFC移植版ドラゴンクエスト3」です。それぞれ1995年と翌96年の12月に発売されています。

この2作品間では、アイテム格納ストレージの「ふくろ」システムにて操作体系が刷新されています。ここでの差分がタスク指向な設計からオブジェクト指向性の強い設計への転回がどのようなものだったか捉えるのに良い題材だと思えたので、両作品におけるふくろシステムを振り返ってみます。

6から3へ

DQシリーズ中屈指の人気で知られるDQ5の次のナンバリングで発売されたDQ6は、DQ3を彷彿とさせる転職システムが再び導入されたり、個性的なキャラクターに加えて敵モンスターを仲間にできるDQ5からのシステムなど過去作品の要素をリッチに盛り込んだ感じの設計になっています。

また初期のDQシリーズではアイテムの種類が現在と比べると少なかったのですが、DQ4, 5辺りから一気に増加した感があります。しかしキャラクター1人につき決められた数のアイテムを所持できるDQのシステムでは持ち運べるアイテム数との兼ね合いが厳しそうです。持ちきれないアイテムを格納する施設「預かり所」もゲーム中には存在するのですが、いちいち預けたり引き出すために行き来するのも少々面倒です。

そこでDQ6では「ふくろ(袋)」システムがDQシリーズ中で初めて導入されます。これは仲間キャラクターのアイテム所持枠の他に、枠数が無制限のふくろへアイテムを格納して持ち運べるシステムです。おそらくはゲーム要素のインフレにともなってキャラクターごとの所持枠に収まりにくくなったアイテムの扱いを検討した中で、リモート(預かり所)ではなくローカルに格納できる利便性を狙ったシステムとしてふくろが実装されたのだと推測できます。

このようにリリースされたDQ6の翌年には、かつてFCをハードとして発売されたDQ3をSFCへ移植したリメイク作が発売されます。
このSFC版DQ3(以降、当記事ではSFCDQ3と表記)は歴代DQシリーズでもかなり評価の高いリメイクで、現在でもRTA競技などをはじめ盛んに遊ばれているようです。
一方のDQ6は何かと評価が二分される作品で(筆者は結構好きでした)、とりわけふくろシステムについては「使いにくい」「操作が面倒」とネガティブな感想に偏っている印象です。
この2作品の評価に少なからず影響した要素として、ふくろシステムUIの変化を観察してみます。

DQ6のふくろ

先に取り上げたように、DQ6での「ふくろ」はDQシリーズで初めて導入されたということもあり、それ以降のふくろシステムとは異なった操作体系になっています。それは6以前のDQナンバリング作品における「預かり所」の

  1. 預ける/引き出す(コマンド選択)

  2. コマンドの対象アイテムを選択

という操作体系を流用したようなシステムでした。

プレイヤーがメニューから「どうぐ」を選択すると、「ふくろを含めたキャラクターの一覧」と「各キャラクターが所持するアイテム」のMaster-Detail(一覧-詳細)パターンがマルチウインドウにて展開されます。

DQ6 「どうぐ」から「ふくろ」を選択した時のコマンドのスクリーンショット
「どうぐ」から「ふくろ」を選択した時のコマンド

キャラクターを選択すると、そのキャラクターのアイテム所持枠から操作対象のアイテムを選択するステップになるのですが、ふくろだけは扱いが特別です。ふくろを選択すると操作対象のアイテム選択ではなく、まず「何の操作をするか」の選択を迫られます。

DQ6 ふくろから「だす」モードでアイテムを選択しているスクリーンショット
ふくろから「だす」モードでアイテムを選択している
DQ6 「だす」コマンド対象のアイテムを誰に渡すか選択しているスクリーンショット
「だす」コマンド対象のアイテムを誰に渡すか選択している

例えば「だす」コマンドを選択すると、どのアイテムをふくろから「だす」のか選択できるようになります。この段階でプレイヤーは初めてふくろの中身を自由に閲覧できるようになります。
(OOUIの前提知識を共有されている方にとっては冗談のように感じられるかもしれませんが…「みる」コマンドを選択すると、何もアイテムの操作を行えず、本当にただアイテムを「みる」だけのモードへ入ります。そして「だす」コマンドでもふくろ内のアイテム閲覧は可能です)

SFCDQ3のふくろ

一方で、SFCDQ3のそれはDQ6と逆のフローに変更されています。

SFCDQ3「ふくろ」からアイテムを選択しているスクリーンショット
「ふくろ」からアイテムを選択している

最初はDQ6と同様に、メニューから「どうぐ」を開くとキャラクター(+ふくろ)とそれぞれのアイテム所持枠がマルチウインドウで表示されます。

SFCDQ3 選択したアイテムに対するコマンドのスクリーンショット
選択したアイテムに対するコマンド

ここで何かアイテムを選択すると、そのアイテムに対して「つかう」「わたす」などのコマンドが並んだポップアップウインドウが表示され、プレイヤーはこの中からコマンドを選択することでアイテムとそれに対する処理を実行する流れとなります。

先述の「預かり所」に倣ったようなDQ6のシステムでは、同じ「どうぐ」内でもキャラクターとふくろで操作の順序が逆になっているUIだったのですが、SFCDQ3では統一されており、キャラクターのアイテム所持枠と同じ操作・感覚でふくろのアイテムも扱えるようになりました。

タスク指向設計とオブジェクト指向設計

ここまで読んでいる人の多くを占めると思われるコンピュータソフトウェアのUIデザイナー・デベロッパーの皆さまにおかれましては今更紹介するまでもないと思いますが、それ以外で、単にゲームに関するトピックとしてこの記事を読まれている人向けに、タスク指向設計とオブジェクト指向設計を紹介します。

(なお今更ですがこの記事では「設計=デザイン」と読み換えていただいて構いません。「デザイン=審美性・見た目だけの話」と捉えている人が未だに多くてノイズが増えそう・実態をイメージしにくそうな点と、単に文字数が少なくて済む点から、なるべく「設計」表記に寄せています)

例えば…私たちがスーパーやコンビニで買い物をするとき、買いたい物を選んでからレジでお金を払うのが普通です。逆に、レジでお金を払ってから買いたい物を選ぶのはあまりあり得ないというか、なかなか困難に思えます。

ところが「お金を払った後で買う物を選ぶ」ことを誰もが自然に行なっているものがあります。その代表例が飲み物などの「自動販売機」なのですが、この場合

  1. 120円を投入する

  2. 飲みたい物を選んでボタンを押す

といった手順の操作を自販機に対して行います。これだけ見ると特に違和感はなさそうですが、実際には

  1. 飲みたい物を選ぶ(自販機へのアクションは無く、脳内で)

  2. 選んだ飲み物に対応した金額の120円を投入する

  3. 飲みたい物を選んでボタンを押す(複数のボタン群の中から1で目星をつけた飲み物のボタンを選択する)

といった形で、まず最初の1でユーザーは(自販機に対して暗黙的に)何を飲むか選んでいるため「飲みたい物を選ぶ」行動が2回繰り返されている、と捉えることができます。

この「お金を入れる」「ものを選ぶ」手順を逆にしてみると

  1. 飲みたい物を選ぶ(=そのままボタンを押す)

  2. 120円を投入する

この簡素な2ステップのみにできます。

自販機が開発された当時は技術的な制約など黎明期ゆえの様々な苦労があったのだと思われますが、今日では電子マネーで支払えるタイプの自販機でこの手順の操作体系になっている機種がありますね。

このように、まずユーザーの目当てのもの(オブジェクト)を先に選べるようにして、次にその目当てに対する行動(タスク)を選択する操作体系の性質を、UIデザインの分野では「オブジェクト指向」と呼び、その性質を持つUIをオブジェクト指向UI(object-oriented user interface・略してOOUI)などと呼んでいます。
プログラミングの領域で用いられることの多かったワードですが、元来はMacintoshの元ネタとして知られるSmalltalkのアラン・ケイ氏が生み出した、ソフトウェア設計の考え方です。オブジェクト指向プログラミングはアラン・ケイ氏の考え方から派生するような形で変遷を遂げて今に至りますが、オブジェクト指向設計・オブジェクト指向UIは同氏の考え方を比較的率直に継承したものとして認識されています。

一方で、行動(タスク)を先に選択したのちにオブジェクトを選択する操作体系の性質は、オブジェクト指向との対比軸を語る上で「タスク指向」と呼ばれています。

UIデザインの分野では元々オブジェクト指向の性質を備えたMacintoshなどが知られていたものの、(ここでは割愛する諸般の要因や経緯によって)タスク指向のUI設計が良いとされてここ最近まで広まっていたのですが、オブジェクト指向設計について体系的に記された書籍の出版と時を同じくして多くのデザイナーがGUI本来のオブジェクト指向性を改めて意識した上で筋の良いデザインを目指すようになった、というのが私の認識する限りでのここ2,3年における大まかな流れです。

オブジェクト指向設計の特性としては「システム全体の操作体系を明快にでき、タスク指向と比べてページ数・画面(ビュー)数やモード(特定のボタンを押した間だけ操作方法が変わるような状態のこと)数を減らして認知負荷や学習効率を向上できる」ことが挙げられます。

例えばDQ6の場合だと、先に「だす」「いれる」「みる」などのタスク選択を行う設計なので、タスク選択後に表示される画面として「だす画面」「入れる画面」「みる画面」といった具合にタスクそれぞれに対して対応する画面が計3つ用意されています。

しかしオブジェクト指向設計のSFCDQ3だと「アイテム一覧画面」があるだけです。プレイヤーはまずアイテムを見て、目当てのアイテムがあればそれを選択した上で「そのアイテムをどうする?」というタスク選択の意思決定を後回しできるのです。DQ6だとこうはいかなくて、ふくろ内に目当てのアイテムがあるかどうかをまず確かめたい場面でも「だす」「いれる」「みる」のタスク選択を完了しないといけません。

また先の自販機の例で言うと、飲み物選択と支払いを逆順にすることは単に1ステップ分を省略できるだけでなく、自販機全体の設計にメリットをもたらす可能性が考えられるのです。
というのも、先に支払いを行なうタスク指向自販機の場合、まず120円を投入すると、飲み物ごとのボタンが点灯して有効になる「商品選択モード」に入るのですが、「やっぱり今は買わなくていいかな」と思った時にはこのモードから脱出して最初の支払いをキャンセル・返金処理をしなければなりません。
逆に、飲み物自体を先に選ぶオブジェクト指向自販機の場合は、仮に飲み物ボタンを押しても購入の意思が無くなったらその場を立ち去れば済みます。つまり、商品選択モードと、それをキャンセルするための返金処理が必要なくなるのです。加えて、お釣りも一律的に返却するような(120円を入れて110円の飲み物ボタンを押したら飲み物と10円が同時に出てくるような)仕組みにしてしまえば、お金の返却レバー自体を備えなくて済むようにでき、まとめ買いのようなレアケースに閉じた限定的な利便性と引き換えに、お釣りの回収忘れや操作ミスが限りなく少ない自販機を実現できるかもしれません(現実的には内部機構の見直しなどが必要そうですが…)。

この辺りの話は「ソシオメディア | OOUI – オブジェクトベースのUIモデリング」などでより詳細に説明されているので、面白そうに感じた方は参照してみてください。

オブジェクト指向設計が変えたもの

先のDQ6とSFCDQ3の例に当てはめてみると、DQ6では「ふくろ」というオブジェクトに対するタスクとして「だす」「いれる」「みる」コマンドが存在するので、「ふくろ」オブジェクトを先に選択するというオブジェクト指向性は一応見受けられます。しかしどうぐシステム内におけるプレイヤーの最大の目当ては、ふくろや各キャラクターを選択する階層ではなく、アイテム自体の階層です。この「ふくろ内のアイテム」という最大の目当てに注目すると、

  1. アイテムが所属するふくろを選択

  2. ふくろ内アイテムに対するコマンドを選択

  3. ふくろ内アイテムの選択

というように、オブジェクト(ふくろ内アイテム)を見る前にタスク(コマンド)選択を強いられるというタスク指向性を抱えています。

この弊害として、SFCDQ3以降の作品では可能なふくろ内のアイテムを直接使う」のがDQ6では不可能で、ふくろ内のアイテムは必ず「だす」コマンドからキャラクターの誰かへ渡した後でないと使えません。ふくろから出さないと使えない、というのは物理的には自然な気もしますが、SFCDQ3以降の作品における操作体系を経験してしまうといささか面倒に感じてしまう…と言えば多くの賛同を得られるのではないでしょうか。

このタスク指向性の高いシステムからコンピュータソフトウェアのGUIらしいオブジェクト指向性へ転回させたSFCDQ3のふくろシステムは

  1. アイテムが所属するふくろを選択

  2. ふくろ内アイテムの選択

  3. ふくろ内アイテムに対するコマンドを選択

といった具合に、自然な「オブジェクト選択→タスク選択」の流れに沿った設計になっています。

オブジェクト指向設計というと数ある手法の一つであるかのように受け取ってしまいがちですが、コンピュータのGUIが生まれて40年近くにわたって本来当たり前に備えている性質です。GUIであることはすなわちオブジェクト指向的でもあることを意味します。が、この原理的な性質や設計思想を単なる手法の一つとして捉えてしまうと、オブジェクト指向への転回をデザインできなくなってしまうのです。

もちろん「ゲームUIや開発の歴史はコンピュータGUIとは異なるもので、全く別の歴史的背景を経て現在の設計に繋がっているものだ」といった主張もごもっともだと思います。

この点に関連して、作品こそ違いますがドラゴンクエストXを題材にした書籍で開発側からの興味深い言及がありました。

そしてドラゴンクエストXのUIは、ドラゴンクエストらしさが表れているものの一つです。ここでは、呪文を唱えるUIを例に解説します。
ドラゴンクエストシリーズにおける呪文は、特殊な効果を発動するものです。たとえば「ホイミ」は、ダメージを受けたプレイヤーキャラクターを回復する呪文です。ドラゴンクエストシリーズで呪文を唱えるためには、図1.3のようなシンプル画面から開始します。そしてメニューを表示→「じゅもん」を選択→呪文の種類を選択→呪文をかける相手を選択という順に操作します。
一方、標準的なMMORPGのUIは異なります。世界的MMORPGの代表格『World of Warcraft』や、日本発で世界に展開している図1.4の『ファイナルファンタジーXIV』などの形式が世界標準とされます。そこには常に大量の情報とアイコンが表示され、たとえば呪文を使用する場合は、呪文をかける相手を選択→呪文アイコンを選択という順に操作します。世界的に見れば、このタイプに慣れている人が多いでしょう。
そのため、ドラゴンクエストXをMMORPGの世界標準UIに近付ける選択肢もありました。しかし、従来のドラゴンクエストシリーズのお客さまにとってわかりやすいものにするため、従来のUIをできるだけ踏襲することにしました。

青山公士 (2018). ドラゴンクエストXを支える技術ーー 大規模オンラインRPGの舞台裏 WEB+DB PRESS plus 技術評論社 pp.6-8

これを読んだ自分の中で「コマンドベースのUIで"DQらしさ"を表現する?せっかくDQナンバリングにわざわざMMORPGを持ち込むのに、MMORPGというメディウムに根ざした表現ではなく?」といった疑問は生まれましたが…MMOへの転換自体はXのローンチと前後して散々議論し尽くされた領域だと思われるのでここでは割愛します。
コンピュータソフトウェアやアプリケーションのGUIとは別のコンテクストで、ゲームというメディウムに則ったUIを考える、という点ではこの本にあるような選択にも一定の合理性を感じとることができました。

しかし、少なくとも当記事で取り上げたDQ作品のふくろシステムにおいては、"タスク(コマンド)ベースではなくGUIらしいオブジェクト指向性へ転回して利便性が向上した"ことは覆らないように感じますし、実際そのようにして利便性が高く愛されるシステムになったことは歴史が物語っていると言えるのではないでしょうか。

デザインが変えたもの

ここまで読んで、「少し操作が楽になっただけに見えて、その裏にはタスク指向からオブジェクト指向にするみたいな色々難しいことを考えてるんだな」と思われた方がいるかもしれません。
実際、UIデザイナーの中にもそういった意識の方は少なからず(というよりも過半数が)いるように見えます。

オブジェクト指向設計への転回は、単に操作体系の簡略化や利便性の向上を目指しただけのものなのでしょうか。

先述したようにDQ6のふくろは、単に預かり所をローカルに持ち運べるようになっただけで、操作感が変わっていないがために収納や引き出しの手間も預かり所とあまり変わっていないようなシステムでした。
一方でSFCDQ3のふくろは、キャラクターのアイテム所持枠と同じ感覚で扱えて、かつ無制限にアイテムを格納できる、という点で、四次元ポケットを使えるキャラクターが1人追加されたかのような感覚を擬似的に体感できる発明・イリュージョンの類になっています。「預かり所」という概念から「仲間キャラクターと同列に扱える無制限ストレージ」へと存在自体が拡張されているのです。

これは「デザインは世界におけるものの在り方自体から変えることができる」ことを示しているように思えます。
よく巷で「デザインは問題解決でアートは問題提起」などと言われていますが、オブジェクト指向設計への転回は、単に問題解決だけに留まるのではなく、「こういう存在のふくろシステムはどうか」といった問題提起も含んでいます。少なくともDQ6以前には存在しなかったシステムなので、プレイヤーは6のそれを問題としてはさほど認識していなかったはずです。そうなると問題解決とは違った性質を帯びてくるわけで、SFCDQ3にて改めて「ふくろとしての存在はどうあるべきか」などと開発者は思いを巡らせ、結果的にその存在自体を新たに設計することでプレイヤーへ提示した、と捉えることができるのではないでしょうか。

例えば最近だとオブジェクト指向UIデザインの書籍を読んで、実際にワークアウトへ挑戦してみるような記事などがよく目に入ります。もちろん意欲的で素晴らしい試みに感じるのですが、単に書籍で紹介されているようなオブジェクトのMaster-Detailパターンをなぞるだけになっているような事例も見受けられます。
オブジェクト指向の設計とは、先述の「世界を・オブジェクトをどのように捉えるか」といった認識の変容のようなものを伴ってこそだと思うのですが、パターンや構造の模倣に終始するだけだと「これも設計手法の1つだな」といった認識に閉じてしまい、オブジェクト指向設計への転回は難しくなるのではと不安に感じています。

例えば簡素で原始的な<a />タグのテキストリンクひとつとっても、そこにはオブジェクト指向性を備えた設計か否かを見てとることができます。

この点を考慮した上で、私が所属するデザイン組織でデザインシステム・UIガイドラインをどのように策定しているか紹介した記事にも目を通してもらえると面白いかもしれません。こういったあらゆるオブジェクトから固有のオブジェクト指向性を見出すことは、書籍にある情報構造を模倣するだけでは難しく、その背景にある思想から咀嚼しないと辿り着きにくいような気がしています。

デザインに限らないと思いますが、物事の背景にあるものや、そのもの自体が何を意味しているか、世界にとって・人にとって何なのか、といったことを意識すると、よく言われるような「筋の良さ」「奥行き」「丁寧さ」「誠実さ」などに繋がってくるのではないでしょうか。少なくとも自分の場合、この記事のように30年近く昔のゲームに対しても新たな地平からの発見ができ、コンテンツを一層楽しめるようになっていますし、"批評的に物事を視る"というのはそういうことだと思っています。

ここまで書いておきながら、筆者はDQシリーズでXだけプレイしていないタイプの人間なので、今夏発売予定のXオフラインがリリースされた際にはUIにも注目していければ、といった感じで楽しみにしています。

この記事が参加している募集

ゲームで学んだこと

ゲームの作り方

この記事が気に入ったらサポートをしてみませんか?