Hijack 新作 中間報告　現状／方向性整理

　こんばんは。皆様いかがお過ごしでしょうか。私は近年[いつ?]、ミクササイズが性癖に刺さりすぎてしまいました。

　それとCi-en記事を読んでいて、シナリオライターさんの書く記事の語彙力と読ませる文才に恐れおののく毎日です。

　今日は Hijack の企画上の、1月から3月時点での変更点とその理由、および今後のスケジュールについて軽く書いてみたいと思います。

2.5D→3Dへ

　1月時点での企画と、3月時点での企画の最大の変更点は「2.5Dから3Dになったこと」です。これは、今週決まりました（？）。

　理由は、主にふたつ。

• ADVパートの仕様が固まり、2Dキャラを配置することで、3Dキャラモデル1体からでも現実的にゲームがつくれそうだな、という感触を得たこと
• Unityのカメラワークについて勉強して、Cinemachineを使えば現実的に3Dゲームをつくれそうだな、となったこと

　です。

ADVパート
↓2Dキャラ主体でシナリオが進行する。
ACTパートの建物に入るなどしてこのパートに遷移する。
（まだないが、「買い物する」「雑談する」「お店から出る」といった選択肢を用意し、ACTパートに戻れるようにする）

ACTパート
↓3Dモデル＋ステージで進むパート。
雑魚敵やボスは自力でモデリングする予定（鬼門）。

ステージの進行

　基本的には、ADVパートでテーリが「依頼」を受けます。具体的なことはまだ考えていませんが、たとえば「これこれこういう場所で、お花をとってきて！」とか……まあ、RPGとかにありがちな依頼だと思ってください。

　で、テーリはその場所に行って、お花を取るためにアクションします。お花を入手するとステージクリア。そういうのを繰り返して進むイメージです。

♥を探せ！

　ただ、お花とか、そういう特殊な目標をたくさん用意するのは大変なので……。ここは、思い切って♥を集める感じにしようと思っています。

　ハートと言うと、多くの作品で回復アイテムだと思いますが、 Hijack 新作ではステージクリアの目標です。「世界でハートを集める」……そういうイメージです（？）。

　お花はオブジェクトとして配置して、そのお花を見つけると、ハートが出現する。そういう感じの仕様です！

依頼を受けたら即ステージに行く

　依頼……と言うと、よくあるのが、いわゆる「クエスト」で

1. 依頼を受注する（複数受注することも可能で、「依頼リスト」から見たりできる）
2. 「ワールドマップ」的な場所から目的のステージへ行く
3. 目標を達成するために行動する

　みたいなパターンです。……つまり、ステージ≠依頼のパターン。

　Hijack 新作では、ステージ＝依頼、にしようと思っています。依頼を受けたら即ステージに移動し、クリア＝依頼達成、ゲームオーバー＝依頼失敗、とします。

　ステージでゲームオーバーになると街に戻りますが、街に残機のような概念はありません。平和で、何度でも再挑戦できます。

　つまり、依頼とは言いますが、単純に「ステージ間の移動に伴う会話イベント」が依頼方式なだけ。依頼、というシステムがあるわけではないということです。

現在進行中のもの

　まだ公開できない内容も多いですが、少しだけ。

3Dモデル制作

　現在、3Dモデル制作が進行中です。

ADVパートの新キャラ

　ADVパートにキャラクターを増やすべく、新キャラの制作も進行中です。
すべて3D化するのは現実的に難しいので、2Dオンリーのキャラがほとんどになると思います。

3月上旬の振り返り

　正直、2ヶ月＋も2.5Dと3Dの仕様でブレてるのは、ゲーム企画者としての実力不足を痛感しますね……。

↓仕様を変えることに関する、好きな動画

https://www.youtube.com/watch?v=e9zu3-L6Elc

　仕様を変えるのは、ある程度仕方ない状況もあります。ただ、やはり「仕方ない」というだけで、基本的には変えないほうがいいと思っています。

　上の動画の冒頭にもあるんですが、究極的には、開発とは仕様を決める過程そのものです。仕様が真の意味で決まるのは、完成するときだけです。それまではどんなに精細な仕様書でも、必ず漏れがあると思ってよいと思います。

　もし、ソフトウェアの仕様を漏れなく記述したドキュメントがあるとしたら、それはソースコードだけでしょう。

なんたるマッポーか！　おおブッダよ、もはやこの世に救いはないのか？

A. いいえ、実際あります。

　仕様を変えないことは難しい。とはいえ、仕様を極力変えない方法はあります。

　それは、「変えにくい」所から仕様を決めていく、という方法です。開発とは仕様を決める過程そのものなので、全く同じ手法が開発にも使えます。「変えにくい」所から開発しましょう、ということです。

（単なるスケジュール上の話ではなく、コードやリソースの管理上も、「変えるもの」と「変えないもの」を分離しておく手法はとてつもなく強力です。「変えないもの」はC#などで、「変えるもの」はエクセルだとかで書いておき、開発初期はとりあえずダミーの値で埋めておいて、C#で読み込むなどするのがおすすめです。閑話休題。）

　たとえば今回の場合、2.5D→3D、という変更はあったんですが、グラフィックが3Dという点では変わっていません。そのため、これまで開発した3Dグラフィックの要素や、現在依頼中の3Dモデルに関しては影響はないわけです。

　コンセプトは貫くもの、という動画でも触れられているんですが、コンセプトや仕様を変えないことで、極力「つくりなおし」を避け、それまでつくった素材を有効活用するのは大事です。

https://www.youtube.com/watch?v=ykrpUAoEJ9U

　特に依頼が絡む場合、「依頼したけど使わなかった」というのは、コストもかかりますしせっかく受けてくださったクリエイターさんにとても失礼です（無論、仕方ない状況もあると思います）。

　ですから、私は変更する可能性が極力0になるまで仕様が固まった個所から依頼するようにしています。

3月中旬（～3/24）目標

　最後に本題というか今後の目標になるんですが（遅い）、3/24までに「街」を最低建物がひとつある状態で用意し、依頼を受けてステージに行く……という基本的なルーチンが動く状態までに持っていきたいと思っています。

　街は一応あるんですが、2.5D前提で横方向に並べていたので、つくりなおしです。

　これを書こうと思ったのは、なんというかやっぱ自分は目標を決め明文化しておかないと無限にだらだらしてしまうタイプだなと思ったので（？）。まあ、あと約2週間、頑張ります！！！（？？？

　すこし長くなってしまいましたが、なかなか読み応えのある記事になったのではないかと思います。さて、それでは今回はこのへんで！　また次回もよろしくお願いします～～～～～～！！！！！！！！！！！

Cinemachine 実験その④　Cinemachine Collider

　こんばんは。今日の進捗その②を報告します。

Cinemachine Collider 実験

　Cinemachine Collider というものの実験をしていました。プレイヤーとカメラの間に障害物があると、それを回避しプレイヤーが映る位置に移動してくれます。

　“Collider” と名がついていますが、単にカメラに Collider がつくわけではありません。 Collider を回避するようなカメラ、という感じです。

　色々プロパティがあり、デフォルトでは障害物を回避して瞬間移動する感じになっていて、不自然です。「カメラマンが障害物を回避して移動した」……というような自然な動作にするには、 smoothing とかの設定をします。これらを設定すると、瞬時に移動せず動画のようなぬるぬるした動きになります。

カメラワークはゲームの本質的な要素ではないが、土台として非常に重要

　最近は、 Unity のカメラワークの基本的な所の実験で手一杯な感じですね……。ゲームとしての本質的な要素であるところの、アクションだとかには全然手がつけられていません。

　ただ、カメラワークの動作を fix してから要素を増やしていかないと、いざプレイしてみて「足場がカメラに映らない」とか「キャラが映らない」なんてことになりかねません。アクションも同じです。

　後からカメラの動作を変更すると、それまでつくったマップが全部つくりなおし、なんてこともあり得ますから……。カメラの動作を先にかっちり決めて、それにあわせてステージやアクションをつくるほうが楽です。

　ただ、できるだけ早い段階でゲームとして本質的な要素に着手したいので、そろそろカメラの動作を fix したいところです。

　それでは今回はこのへんで！　また次回もよろしくお願いします～～～～～～～！！！

Cinemachine テストその③　ズーム

　こんにちは！　今日の進捗を報告します。

右スティック前後でズームできるように

　前回までは右スティック左右で回転するようにしていましたが、今回は右スティック前後（上下）でズームするようにしました。単にズームするだけでなく、引きの時は見下ろし型、アップの時は FPS みたいな感じになるような曲線を描きます。

数学ちゃんとやってよかったなぁ（？

　Unity で 3D プログラミングをしていると、いわゆる「プログラミング」というよりも、数学の知識が役立っているのを感じます。ベクトルとか、指数とか。

　三角関数はもちろん、「滑らかに」動かす時に指数・対数を使うという発想は大事で、単に「プログラミング」をしているだけだとなかなか得られない気がします。

　もちろん Unity には LookAt や RotateAround といった、数学の知識が不要な便利な関数もあります。ただ、やっぱりちょっと凝ったことをしようと思うと、自力で計算する必要がある場合も多い。そうなると、このあたりの勉強は避けられない気がしますね。

　学問に王道なしとはよく言ったものだと思います。

　ところで、ちゃんと「勉強」ができる人はいいんですが、私は勉強が苦手なタイプでして。 OpenGL でのプログラミングや、クオータニオンの再発明を通じて頭というよりも身体で覚えたんですが（ほんまか）、そういう知識が活きるのは嬉しいですね。

　それでは今回はこのへんで！　また次回もよろしくお願いします～～～！！！

Cinemachine テスト２・Orbital Transposer

　こんばんは。今日の進捗を報告します。

Cinemachine 実験その②　Orbital Transposer

　Orbital Transposer というものを導入し、右スティックで動かせるようにしました。

前々回との比較

　前々回でも一応カメラは動かせたんですが、これは Cinemachine ではなく、自力でベクトルを計算していました。

　ただ動きが線形で、ぎこちない感じです。Cinemachineだと慣性がついていて、プロっぽい感じがしますね。

技術的な話

　前回の記事では、 Cinemachine の（Orbital ではない） Transposer というものを使っていました。 Transposer は対象を自動的に追尾してくれるカメラです。

　実際の3Dゲームでは、自動追従だけでなく右スティックでカメラを操作できることが多いため、この操作に対応できるものを探していました。

　Orbital Transposer というのは、対象の周囲をぐるりとまわることができるカメラです。この X Axis というものを変更するとぐるりとまわってくれます。

　デフォルトでマウス操作に対応しているのですが、実際にはスティックの操作で動かしたい。ノーコードでする方法もある気がしますが、私の場合、C#から操作することにしました。

　参考にしたドキュメントは以下。

• https://docs.unity3d.com/Packages/com.unity.cinemachine@2.1/api/Cinemachine.CinemachineVirtualCamera.html
• https://docs.unity3d.com/Packages/com.unity.cinemachine@2.1/api/Cinemachine.CinemachineTransposer.html

　実際のコードは↓みたいな感じになります。

using UnityEngine;
using Cinemachine;

/* ...中略... */

[SerializeField]
private CinemachineVirtualCamera virtualCamera = null;

/* ...中略... */

var orbitalTransposer = virtualCamera.GetCinemachineComponent<CinemachineOrbitalTransposer>();
orbitalTransposer.m_XAxis.Value += /* 右スティックのコントローラの値 */;

　それでは今回はこのへんで。また次回もよろしくお願いします～～～！！！

Hijack新作・Cinemachineのテスト

　こんばんは。今日は Cinemachine というものを使ってカメラの操作をするテストをしていました。

　なんかリッチな動きになった気がします！

　特に3Dのゲームをつくる上で一番難しいのはカメラの操作だなぁとつくづく思います。カメラにあわせて入力の方向も切り替えなければならず……大変です。

　それでは今回は短くなってしまいますがこのへんで。また次回もよろしくお願いします！