第11話:後半 モダンコード

 ここに剣士と魔法使いがいてモンスターに攻撃している。……この世界にはある意味実在するんだが、今思い浮かべるのはあくまでゲームの話だ。


 まず単純に剣士だ。剣士は腕力と武器の攻撃力を合せたダメージをモンスターに与える。わかりやすく腕力10で持っている武器(ロングソード)の攻撃力は10としよう。モンスターのHPは100とする。防御力は考えない。


 これを素直にプログラムするとこうなる。


======================

10+10=20:ダメージの計算

100ー20=80:モンスターの残りHP

======================


 これはプログラムを書く人間にとって解りにくい。それぞれの数値や式の意味が直感的に理解できないからだ。しかも、戦闘毎に同じ式を書かなければいけない。


 仮に、剣士が攻撃力15のグレートソードに装備を変えたり、【スキル攻撃力+10パーセント】などを組み込むことになったら悲劇だ。ミスが入り込む余地が限りなく大きい。


 ここで関数化だ。武器攻撃という関数を定義する。


======================

関数:武器攻撃(武器名)(腕力)

ダメージ=武器の攻撃力+腕力

モンスターのHPーダメージ

======================


 剣士の攻撃はこの関数を呼び出すことになる。


ーーーーーーーーーーーーーーーーーーーーーー

武器攻撃(ロングソード)(腕力)=80:モンスターの残りHP

ーーーーーーーーーーーーーーーーーーーーーー


 ダメージ計算という過程を関数として分離する。プログラムする人間に取って何が行われているか明確になる。何回攻撃が行われようと計算をいちいちしなくて済む。そして、スキルを加えるとしても、関数を修正すれば、それで全てに反映される。


 次に魔法使いだ。同じように魔法攻撃という関数を定義する。


======================

関数:武器攻撃(魔法名)(知力)

ダメージ=魔法の攻撃力+知力

ダメージを与える

======================


戦闘はこういう風にプログラムされる。


ーーーーーーーーーーーーーーーーーーーーーー

モンスターのHPー武器攻撃(ロングソード)(腕力)

モンスターのHPー魔法攻撃(ファイヤーボール)(知力)

ーーーーーーーーーーーーーーーーーーーーーー


 ここまでは魔導でもやっていることだ。だが、これでも限界がある。腕力や知力というデータや武器や呪文を入力し間違えるリスク。さらに、戦士が魔法と使おうとしたり、魔法使いが杖で殴ろうとするようなミスが入り込む。


 それを避けるために、まるでキャラクターそのもののように、関数とそれに必要なパラメーターをパッケージしてしまおうというのがオブジェクト指向の考え方だ。抽象的な計算をまるで実体を持つオブジェクトとして扱うことになる。


「簡単に言えば、関数……。魔導文字だけでなく、魔導文字に入力されるパラメーターや呼び出しの基本までを一つの単位として扱うんだ」


 俺はいった。メイティールが首をかしげる。


======================

オブジェクト:戦士

名前:女騎士

HP:100

腕力:10

装備武器:ロングソード

関数:武器攻撃

関数:台詞「くっころせ」

======================


======================

オブジェクト:モンスター

名前:オーク

HP:150

腕力:15

装備武器:棍棒

関数:武器攻撃

関数:捕縛

======================


ーーーーーーーーーーーーーーーーーーーーーー

女騎士の攻撃

オークの攻撃

……

……

女騎士「くっ、ころせ」

ーーーーーーーーーーーーーーーーーーーーーー


 最終的にはこの二つのオブジェクトが勝手に戦闘をする。オークが勝って、女騎士が「くっ、ころせ」というまで共通性と個性を両立できる。


 キャラクターがレベルアップして攻撃力が上がろうと、使用する武器がパワーアップしようと、自動的に反映される。


「少し分かってきた。設計図を作ると言うよりも、まるで人間の組織に対する指示ね」

「ああ、まさにそういうことなんだ。これまでの魔導設計が、幾つもの道具かんすうを組み合わせて作業していた一人の職人だとすれば、これは木工職人や鍛冶屋、布職人というチームを作って馬車を作るようなものになる」

「……例えばそれぞれの材料の購入とかは、必要な人間が必要な時に勝手に行なうわけね」

「そう。職人に権限を委譲するんだ。その権限の範囲内では上司は下手に口を出さない。流石に理解が早いな」

「……最後のちょっと耳が痛いわね。まあ、こっちに来てから色々と気がついたんだけど……」


 メイティールはなぜか照れたようになった。


 それはともかく、組織のトップに居たメイティールの理解は早い。組織が大きくなればなるほど、決断しなければならないことは指数関数的に増える。当然、一人のトップが全ての決断をすることは出来ない。究極的には、トップは目的を決め、必要な仕事を誰に任せるかを決めるのが理想だろう。


 10個の事業があろうと、それぞれの部長を決めるという10回の決断ですむ。問題が起こった事業があればそこの部長一人とだけ話せば良い。もちろん単純に考えればだけど。実際、前の世界ではビジネスプロセスモデリングといって経営の視覚化などにも応用されていた。


 難しいことの難しさは難しいことではない。その多くは、単に人間の脳の容量を超える事にあるのだ。


「魔導のためじゃなくて、設計者のための工夫……。でも、それって無駄が多くない? 魔力の効率的使用という意味ではマイナスでしょ」


 メイティールが問題に気がつく。魔力効率という意味ではオーバーヘッドが多いのだ。


「ああ、そう言った無駄は出る。ただそれを考慮しても魔導の規模がある一定を越えれば、効率はこちらが良くなる。この方法だと部分部分を規格化できるし、もっと言えば抽象的にもできる」


 基本オブジェクトという考え方だ。


 動物の分類のようにベースとその派生という形で、デザインできる。例えば女騎士だろうと、オーガだろうとキャラクターなら皆HPを持っていると考えれば、


======================

基本オブジェクト:生物

名前:X

HP:X

======================


 みたいな形で基本オブジェクトを設定することも出来る。個々のオブジェクトはこれを継承して関数スキルを加えて派生させる。職業システムやモンスターの種類などに使える。また、武器や魔法みたいなオブジェクトを作れば同様の応用ができる。


 オブジェクトが要素としてオブジェクトを持てるようにすれば、入れ子上の構造も可能だ。戦士は武器として特定の武器オブジェクトを持てる。武器の持つ特殊効果などはあくまで武器自身が処理するみたいな形にも出来るのだ。使用者は武器に「効果を発揮せよ」と命じるだけで炎の剣は相手を焼き、氷の剣は凍らせる。


 持てるオブジェクトの種類や量の管理は、戦士オブジェクトの中で行なえば良い。そうすれば戦士は魔法を使えないなども自然にデザインできる。もちろん、特定のスキルを特別に保たせることも出来る。例えば【ステータスオープン】とか。


「螺炎の規模だと……。ううん、さっきミーアが言ってた並列化にぴったりの考え方じゃない。魔導文字だけじゃなく、それに対する数値も束ねれば、並列化の容易性は上がる。ううん、今の考え方だと、並列化という概念そのものを抽象化して魔導過程に組み込むことも考えられる」

「ああ、実は抽象的な過程もデザインできる。例えば魔力の供給、演算、発動をそれぞれ基本的な部分だけ共通化して、個々の中身はそれぞれの魔導に合わせて派生させるみたいな方法だ」

「なるほど、どの魔導もその流れは一緒ね」

「更に言えば、これは設計を一つ一つ分離できるから、複数の人間が関わるレベルの設計では効果が大きい」

「一見迂遠だけど、そう考えれば今までにない規模の魔術をデザインできる。魔導回路の微細化と合せれば、オーバーヘッドも吸収できる。紙の上のデザインの効率化だけでも意味がある。具体的には!!」


 メイティールは目を輝かせて俺を見る。


「……いや、だからその先は俺には全く手が出ないんだけど」

「ちょっと待ってよ。今の機能の分離をどう実現するのよ」


 メイティールの要求に必死で知識をかき集める。


「……設計上近くに固めるというよりは、それぞれの連絡の組織化だな。具体的にはアクセス権限を設定して、オブジェクト内部のみ。全体からみたいな区分けをする。これで、人間組織で言えば「上司の口出し」の弊害が物理的に起こらない」

「リカルドはもうちょっと部下に恵まれてることを……。まあいいわ。ミーア、ノエル。今のをどう応用できるか考えましょう。アクセスは回路では結局線の繋がりだけど……」

「回路の配線の複層化です。設計図上で回路を階層化して、オブジェクト内の処理とオブジェクト間の遣り取りは別階層を使うようにする」

 ミーアが言った。

「回路の重層化……。それってまだ可能性の段階で……」

 ノエルが悲鳴を上げた。

 だんだん熱を帯びてくる議論はあっという間に俺の理解を超える。まあ、魔力が流れるためには閉じた回路じゃ無くてその周囲に空間が必要だからな。


「リカルドの言ってた方法で回路を新しく付加するわ。現状で元の回路を変えるわけにはいかないけど。例えば、照準は最後の工程だからカートリッジと同様にアタッチメントにして付加するのに適している。本格的な応用は次の話ね」


 メイティールが言った。


「それは大きいな。何しろこっちの騎士はまだ螺炎を使いこなせていないんだから」

「ええ、だからそこに集中して改善する」

「なるほど、それに命を預けることになる俺としてはありがたい話だな」

「べ、別にそんなことじゃないわ。私はあくまで魔導師として実現性を考えて……。まあ、リカルドにおかしなところで退場されたら私の研究も滞るというのもだけど。そうだ、一つ提案がある。クレイグ王子に伝えて欲しいのよ。私と……」


 メイティールはとんでもないことを言い出した。


「いやいや、そりゃ流石に……」

「あら、速度を最優先でしょ」


◇◇


「なんとかなりそうだな」


 俺は大公邸への帰りの馬車でミーアに言った。


「はい。……そう言えばですけど」

「どうした。さっきの並列化ならもう俺にはどうしようもないところにいってるぞ。多分ミーアから説明されても分からない……」

「いえ、魔導ではなくて……」

「ヴィンダーのことで何か問題でもあるのか」

「いいえ……」


 珍しくミーアが口ごもった。


「今回のこと、アルフィーナ様とはちゃんと話されましたか?」

「…………」


 俺ともアルフィーナとも一緒に住んでいるミーアの質問に、俺は沈黙した。

  • Xで共有
  • Facebookで共有
  • はてなブックマークでブックマーク

作者を応援しよう!

ハートをクリックで、簡単に応援の気持ちを伝えられます。(ログインが必要です)

応援したユーザー

応援すると応援コメントも書けます

新規登録で充実の読書を

マイページ
読書の状況から作品を自動で分類して簡単に管理できる
小説の未読話数がひと目でわかり前回の続きから読める
フォローしたユーザーの活動を追える
通知
小説の更新や作者の新作の情報を受け取れる
閲覧履歴
以前読んだ小説が一覧で見つけやすい
新規ユーザー登録無料

アカウントをお持ちの方はログイン

カクヨムで可能な読書体験をくわしく知る