としるみSoftの制作ブログ

主に作っている作品の紹介や今やっている活動の紹介を書いています。おすすめポイントですらなくなっちゃった。

進む力を付けたい

どもです、としです。

 

今のところUnityLearnの今やっているところは順調に進んでいて、

なんとか今月中に終えられるように進行して次の講座に行きたいです。

あとはそろそろ2月に入るので漫画のネーム作業をやるやる詐欺にならないように何とか始める感じです。

ちょっと最近ゲームやUnityばかりなので、ちょっとイラストの腕慣らしもしたいし、

音楽も本格的に勉強したいしと意外とあれこれしたいにはなっています。

ただ、時間も限られているので1か月にこれしかやらないという感じにしないと、

全部どっちつかずになってしまうと思いますのでその辺は何とかしたいです。

とりあえず来月はイラストは必ずやって、その流れでネームが始められたらいい感じです。

本当は毎週の更新で昔みたいにイラストを出したらいいのですが、

そればかりやっていたら実際の目標にたどり着かないのでやめておきます。

(実際の目的の進捗なら別ですが。)

とにかく簡単でいいのでわかりやすい終わりを作ってそれに向かってやるというスタンスにできれば、

このあとも何とかできるかもしれません。

とにかく自分での中間ゴールをピンを打ちながら進めるだけです。

まずはとにかく目先のゴール(今やっているUnityLearnの項目)を終えられるようにするだけです。

今週はかなり何も動いていないので、これ以上ネタが無いです。

 

ということで今日はこれにて!

では!

(UnityLearn)Adventure Gameを作ってみた3

どもです、としです。

 

UnityLearnの項目ごとに記事も分けた方が分かりやすいかなと思い分けてみました。

と言いつつ、1は1章の導入と2章が一緒になっていますし、

この記事は4章と5章を一緒にしています。

 

(前回はこちら)

 

toshirumisoft.hatenablog.com

 

(今回のやる項目)

learn.unity.com

 

 

1.体力システムを作る

このステップだけではなかなか動作は確認できませんが、

キャラクターに体力を作るのがこのステップです。

この辺からコードが増えてきてわからなくなってくる場合が出てくるので、

コメントで変数とコード内容を後の自分が見ても大丈夫なようにしておくと便利です。

今は覚えられても何か月、もしくは何年か空ける可能性があるので、

覚えているやろーではなくちゃんと書いておいた方がいいです。

 

Unityではpublicで変数を定義するとInspecterで編集できるようにはなりますが、

基本的には他のコードで呼び出せれば変更することができる変数ということです。

publicが付いてない変数はそのコード内でしか直接読み書きできないです。

次のコードは体力を変更するメソッドを作成します。

ただ、今の段階ではどこからも呼び出すことができないので動作は確認できません。

またこのメソッドは引数付きなので、呼び出す際にはカッコの中に数字を入力しないと

エラーになります。

Mathf.Clampは1つ目引数の計算式を行った際に2つ目(最小)と3つ目(最大)の値を超えないようにする関数です。

この場合0からmaxHealthの範囲内でcurrentHealthにメソッドの引数を足す命令になっています。

(足すって言ってもマイナスを足せば引けます。)

最後にキャラクターのスピードもInspectorでいじれるようにpublic変数を作ってこのステップが終わります。

 

2.回復アイテムを作ろう

体力があるゲームは回復がやっぱり必要なので、構築がてらトリガーによる当たり判定を学ぼうというのがこのステップです。

始めに説明通りに画像の設定を行い、Scene上に配置します。

この時画像が大きいのでサイズ調整をしてからBoxCollider2Dを設定します。

サイズはこのぐらい

ここでBoxCollider2DのオプションでInTriggerにチェックを入れるように書いてありますが、

チェックを入れてから起動すると以前とは違いトリガーとして機能しているのでキャラクターは通過します。

ただ、トリガーに対して何も命令がないので、次のステップでコードを作成しています。

新しいコードを作成後に作った回復アイテムのオブジェクトにアタッチして、

OnTriggerEnter2Dメソッドの中身を書きます。

このメソッドはオブジェクトが持っているColliderに何か別のオブジェクトが入ることによって、

メソッド内の命令を実行するものになっています。

デバッグログのステップが終わったら、次に本格的にコードを書いていきます。

まず、初めのコードは当たったオブジェクトのPlayerControllerを取得するためのコードになります。

これによりこのコードでPlayerControllerの中身にアクセスできるようになります。

次のif文でcontrollerの中身がnull(何も入っていない)かどうかをチェックしてから、

PlayerControllerのChangeHealthを呼び出します。

しかし、今の状態だとアクセスできないということでエラーになります。

そのためにPlayerControllerのChangeHealthメソッドにpublicを付けて、

他コードからでもアクセスできるようにします。

次のDestroy関数でこのコードがあるゲームオブジェクト自身を削除します。

すべてのコードが書けたらステップに従ってテストを行います。

テストが終えられたら、作ったオブジェクトはPrefab化しておきます。

 

3.体力がMaxなら取れなくする

前のステップのコードだと体力がMaxでも取れてしまうので、

Maxの時には取れないように仕様を変えるのがこのステップです。

始めにアイテムを取った時のコードの方でアイテムを取った後に、

今の体力が最大体力より低い時というif文を追加しています。

(controllerはnullじゃないよー->controllerの体力は最大値より下だよーの2条件)

このまま進めてもいいのですがif文が2つで長いコードになってしまっているので、

&&で2条件を両方満たした時に実行するように変更してコードの短縮化も行います。

このコードを入力するとcurrentHealthがアクセスできないというエラーが出るので、

前みたいにpublic変数にすればすぐに解決できます。

しかし、場合によっては内部変数を外に出したくないということもあるので、

このステップでは別の方法でこの問題を解決しています。

PlayerControllerの方で新しくhealth変数を作成していますが、

見慣れない方法で作成されています。

詳しくはリファレンスなどを参考してもらった方がいいのですが、

簡単に言えばこの変数は常にcurrentHealthの値が入っているという感じです。

(うまく使えば常に計算した値を入れられるかも。)

これのコード追加にともない先ほどのif文も変更することで、エラーが発生しなくなります。

 

4.ダメージ判定

増やす方があれば減らす方も作らないといけません。

このステップではダメージ床を作るみたいです。

始めに前のステップでチェック用に変更したコードを元に戻します。

ダメージ判定のコードはチュートリアル的には以前の復習として、

課題としてコードはまず答えを見ずに自分で書くようなっています。

アイテムを取る時の当たり判定を理解できていればすぐです。

ただ、このままでは入ったときにコード内容が実行されますが、

チュートリアル的にはダメージゾーンに入っている間はダメージを食らうようにしたいということです。

なのでここではOnTriggerEnter2DをOnTriggerStay2Dに変更します。

ただ、このままではすぐに体力が無くなってしまうので次のダメージまでの無敵時間を追加するみたいです。

まず、PlayerCharacterのRigidBody2DのSleepingModeをNeverSleepに変えます。

説明がチュートリアルに書いていますが、

初めの設定ではオブジェクトが止まっているとRigidBodyが停止してしまって演算がされなくなるから

静止状態でも動かすようにしようということみたいです。

次にダメージを受けた時の無敵時間を追加するコードを書きます。

Bool型の変数isInvincibleがオン(True)になったら無敵時間の値をクールダウン時間に代入して、

毎フレーム、クールダウン時間からTime.deltaTimeを引いて0以下になった時に

isInvincibleをオフ(False)に変えるという感じです。

ステップのコードに従ってコードを追加すれば大丈夫です。

確認できれば次に行きます。

 

5.体力を表示するUIを作る

ここから章が変わります。

learn.unity.com

今までコンソールで体力などの数字を見ていましたが、

こういう数字は遊んでいる人に見せないといけないものなので、

このステップは体力バーを作るみたいです。

以前のRuby'sAdventureチュートリアルやUnity2020までぐらいの書籍では、

Hierarchyで右クリックしてUIからテキストや画像など目的のものを探して編集していました。

このチュートリアルではUIToolKitを使用してUIを作成していくみたいです。

前のUIをuGUIといい、UI自身もゲームオブジェクトとして扱っていくスタイルということらしいです。

今回やるUIToolKitはHTMLやCSSなどと似たアプローチで作れる新UIシステムということらしいのですが、

とりあえずステップを進めてどんな感じか見ないとわからないです。

UIDocumentを作成した段階

チュートリアル通りにアスペクト比を合わせたい場合は設定を先に変えておくと

同じようにできます。

始めの段階でやっておくといいかも

UIToolKitは基本的にはGUIベースで設定していくみたいで、

基本的にSceneと切り離して作業ができる感じです。

ステップ通りに一通り作成できたら、Scene上に配置してみます。

メイン画面の方のHierarchy(UIToolKitの方にもあるので)で、

UIToolKit->UIDocumentを選択してからSourceAssetに先ほど作ったUIDocumentファイルを割り当てると

Game画面の方で作ったUIが出てきます。

あとはステップ通りに進めていきます。

PanelSettingはメイン画面の方のUIDocumentを選択して、

InspectorのPanelSettingのところをダブルクリックして開けます。

次は顔グラフィックを先ほど設定したバーの上に置きます。

一応ステップ通りにやっても数字が変わってしまうかもしれませんが、

慣れていくしかなさそうです。

今のところは形になるように調整できれば次に進んでもいいかもしれません。

 

6.UIToolKitのUIをコードで動かす

旧UIシステム(uGUI)の時はUnityEngine.UIを追加していましたが、

UIToolKitではUnityEngine.UIElementsを追加するみたいです。

uGUIの時はオブジェクト単位でGetComponentして変数を作成して変更していた覚えがありますけど、

UIToolKitの場合は全体のUIDocumentをGetComponentで代入してから、

要素単位でそれぞれ変数を作っている感じみたいです。

コロンの数で区切る数は増えていますが、UI全体がUIDocumentに格納されていると思った方がよさそうです。

始めのコードができた時点でチェックをしてみますが、

ステップの参考画面ではHealthバーは満タンになっていますけど、

実際は半分の大きさになっていればここまでできています。

次はチャレンジとしてコードの変更をしますが、

難しければ答えのコードを読みながら理解した方がやりやすいです。

(英語を訳すのがめんどくさいというのは言い訳にしたい。)

このチャレンジでコードを変更したことによって、

バーの大きさの変更が他からも呼び出せるようになりました。

次のステップでは作ったコードを静的メンバーにしようという話ですが、

動作の度にメモリに呼ばれて終わったらメモリから出ていくのではなく

ずっとメモリに滞在していつ呼ばれてもいいようにするということらしいです。

Awake関数はUnityが起動したときにStart関数よりも先に実行する関数で、

処理によってはこの関数で行わないとエラーが出てしまうこともあります。

ここで追加したコードで作ったUIHandlerを常駐させることで、

わざわざGetComponentで呼び込むことなくUIHandlerのpublicに設定しているものにアクセスできるようになったという感じです。

コード的にはUiHandlerにある自分自身が格納されたinstanceの中身を変更するという感じです。

動作チェックをしてバーがダメージによって変われば、このステップは完了です。

 

まとめ

Healthシステム自体は前のRuby'sAdventureの時とあまり変わらなかったのですが、

UIシステムがUIToolKitに変わったのでその辺が以前とは違う点でした。

UIToolKitの方が感覚的に使えそうな気がするので、

こっちをマスターした方が今後いいかもしれません。

Ruby'sAdventureの時はバーの画像に対してマスクをかけることもやりましたが、

この新しいチュートリアルでは今のところやっていないので、

その辺を見つけておくようにしておけばあとあといいかもしれません。

次は敵キャラとアニメーション周りですが、ある程度は復習になるかもしれません。

やってみないとなんとも言えないですけど。

 

ということで今日はこれにて!

では!

決めておくのはいいけど実際にやろうね

どもです、としです。

 

今週は不定期更新がありました。

来週も結構早々に不定期更新で今やっているUnityLearnについて書くと思います。

今日は土曜日の定期更新で今後のことを少し書こうかと思います。

 

とりあえずは1月中は今のままでUnityLearnをやりながらダラダラという感じでやっていこうと考えています。

最近は積みゲー崩しをやっている感が強いですが、

そろそろ2月に入ったら積みゲー崩しも一旦キリを付けてゲームをする時間を減らしていきたいです。

2月の目標はとしてはUnityLearnのやりたい項目をやりつつ、次のステップに手を出すか考えること。

溜めている漫画のネタでGoしてもいいプロットをいい加減ネームだけでもいいのでまとめてしまう。

年賀イラストとしてはやめたけど作品としては完成させたいネタの完成。

せっかく本を買ったので音楽周りの勉強の再開。

この辺のどれかを始められたら(時間のルーティンに組み込めたら)いいかなぁって感じです。

特に終わりが分かりやすいやつは今からでも始めるようにすれば、

後々楽にできそうなので何とかするために気合を入れたいです。

どっちにしても自分の頑張りでしか進めないので、やっていくしかないです。

少なくとも段階的にはゲーム制作や音楽はインプットでイラスト関連はアウトプットになっている感じなので、

その辺のバランスをうまく管理していくしかないです。

あーだこーだー言っても毎回やるしかないってしか言えないのでやるしかないです。

 

ということで今日はこれにて!

では!

 

(UnityLearn)Adventure Gameを作ってみた2

どもです、としです。

 

UnityLearnも順調に進んでいますが、

やりたいなぁと思えているチュートリアルが全部終わったらどうしようかなーとも悩んでいます。

パスウェイというコースでの講座もあるらしいので、

他のも含めてキリが付いたらやってみてもいいかもしれません。

 

 

toshirumisoft.hatenablog.com

(前回はこちら)

learn.unity.com

(講座のリンク)

 

 

1.1枚画像を分割してタイルマップを作る

前に作ったタイルマップに他の画像を追加して、新しいタイルマップを追加するステップです。

アセットにあるタイルセット用の画像を選択し、SpriteModeをMultipleに変更します。

Singleでは画像をそのまま使うのに対して、

Multipleは指定したサイズで画像を区切ることで1枚の画像を複数枚の画像に変換する機能です。

ここではPixelsPerUnitを64に設定することで、1ユニットのサイズを64x64のサイズにしています。

SpriteEditorを開いて、文章通りにSliceを選んで画像を分割してApplyで確定します。

縦3横3に分割。

あとはタイルパレットに追加することで使えるようになります。

残りの画像もやってしまってから次に進みます。

 

2.画像を配置してオブジェクトにする

このステップでは画像をオブジェクトとして作成し、

再利用できるようにPrefabとして保存するようにしていきます。

まずは置きたい画像をHierarchyかSceneにドラッグドロップで持ってって配置します。

この状態では何も設定していないのでキャラクターがただ通過するだけです。

次のステップでRenderer2Dの設定をいじるのでProjectからSettingsを探そうと記載されていますが、

あれれ?

ありません。

ということで、まずはこのステップで指定されている場所を探してみます。

目的としてはエクスプローラーで表示されている

プロジェクト全体の中身

このProjectSettingsをUnity内で表示させようという感じです。

あれこれやってわかった答えとしては

Edit->ProjectSettings

ここのカメラセッティングを説明と同じように変更すれば、

キャラクターが木の上部に差し掛かると木の方が上になるようになりました。

バージョン違いでこう違うと初心者にとってはかなり厳しいなぁと改めて思いました。

このあとは画像のPivotを調整します。

Pivotとは簡単に言えばUIで画像を判定する中心点で、ここの場所でTransformは判定します。

このステップの最後にPrefabフォルダを作成しておいて次にいきます。

次は針の画像を同じサイズのまま引き延ばすとタイル状に拡大できるようにしていきます。

Sceneに画像を配置してSpliteRendererでDrawModeをTileにしてTileModeをAdaptiveにすればいいのですが、

このままでは警告が出るので画像の方で設定を行います。

画像のMeshTypeをFullRectに変えると警告が無くなります。

この状態で拡大縮小を行うと特定の大きさまでは拡大されるが、それを超えるとタイル状に再配置されます。

この辺は実際に確認して試すのが早いです。

 

3.物理エンジンとPrefab

ステップの始めにPlayerCharacterオブジェクトをPrefabディレクトリに移動して、

Prefabを作成します。

Prefabとは再利用可能のオブジェクトのことで、Project画面から出すことで同じオブジェクトを作成できます。

Prefabの編集は注意が必要で、ディレクトリに格納された元ファイルとSceneに追加されたものと編集した後の扱いが違います。

元ファイルを変更すると使用しているPrefab自体に影響がありますが、

Sceneに追加されたPrefabを一部変更するとその部分だけオーバライドしたオブジェクトになります。

直すポイントによって挙動が変わるのでその辺は気をつけないといけないです。

ステップではPrefabの元ファイルを変更して、作業が進みます。

始めにRigidbody2Dを追加して物理エンジンをオブジェクトに追加します。

追加しただけの状態で起動すると物理エンジンにより下方向にキャラクターが落ちていきます。

次のステップではGravityScaleを0にして重力の影響を無くしていますが、

編集場所がScene内のPrefabをいじっています。

このままでは元Prefabは変更されませんが、オーバーライドした内容を元Prefabに適応すれば大丈夫です。

次のステップはHierarchy上のPrefabの右にある矢印を押して元ファイルを編集して進んでいます。

Prefabの編集方法はたくさんあるので、この段階で覚えるのがいいです。

ここではBoxCollider2Dを追加して当たり判定となる部分を作ります。

ステップではキャラクターの下半分に当たり判定を設定しています。

次のステップは当たるものを作成するために何か1つの装飾オブジェクトをPrefabにして、当たり判定を作ります。

例は針のオブジェクトで作成しています。

説明ではPrefabにしてからColliderを追加していますが、逆でも可能です。

これで障害物に当たれるようになりましたが、動かした時にキャラクターが回転してしまいます。

これを回避するためにキャラクターのRigidbodyにConsttaintsのFreezeRotationのZ軸を有効にします。

ここ

これによりZ軸が動かなくなり、回転することが無くなりました。

しかし、Collider同士が衝突している時にキャラクターがブルブル震えてしまいます。

これをジッタリングというらしく、次はコードによってこれを解消しようということです。

ジッタリングは物理演算とオブジェクトの位置のずれから起こっているようなので、

コードでは物理演算を読み込んで演算上の位置を変更することで解決しているみたいです。

新しくFixUpdateが出てきましたが、これは毎フレーム呼び出すUpdateとは違って

一定間隔で毎回呼び出されるメソッドになります。

なのでフレームに関係なく読み込めるのでフレームに依存しない動作ができるみたいです。

 

4.タイルマップに当たり判定

前のステップの見本用の動画ではすでにタイルマップに当たり判定があるので、

いつやるのかと思いましたがこのステップでやるみたいです。

まずGridの中にあるTilemapを選びTilemapCollider2dを追加します。

この段階ではすべてのタイルマップに当たり判定が有効になり、キャラクターが動けなくなります。

なので、Tilesディレクトリにある通れるタイルマップ画像を選択してColliderTypeをNoneにしていきます。

そうすれば一部のタイルマップ以外が通れるようになります。

これで目的は達成ですが、このままだと大きいマップになった時にColliderの多さで負荷がかかってパフォーマンスに影響するみたいです。

解消するための作業としてまずCompositeCollider2Dを追加します。

この時にRigidbody2Dも追加されます。

次にTileColliderの方でUseCompositeにチェックを入れ、RigidbodyをStaticにします。

Staticにしたことで静的オブジェクトになり、他に影響は与えるが自分は影響を受けないオブジェクトになります。

この設定にすることでタイルマップは絶対に動かないオブジェクトとして認識され、

計算が最適化して動作が軽くなるみたいです。

あとは適宜装飾にBoxCollider2Dを追加してこのステップは終了です。

 

まとめ

これで一通りの当たり判定ができました。

今の段階は通過できるかできないかの判定がメインで、

次は当たり判定によって処理を行うコードをやっていきます。

この辺は前にやったRuby'sAdventureとほぼ一緒ですが、

コードがどのぐらい変更になっているのか、もしくは一緒なのか

その辺を確認しつつ進めていきます。

ちなみにこの辺はほとんど一緒だったので、復習になりました。

 

ということで今回はこれにて!

では!

(UnityLearn)Adventure Gameを作ってみた1

どもです、としです。

前の更新で言っていたUnityLearnを今週から始めてみます。

やる項目はこちらです。

learn.unity.com

 

 

1.導入

learn.unity.com

UnityLearnの項目は推奨エディタのバージョンが2019か2020が多い印象がありますが、

この項目は2022を使うみたいです。

なので今回使用したバージョンは2022.3.2f1になります。

バージョンによってはアセットの導入方法が違うので、慣れない場合は絶対にバージョンは揃えた方がやりやすいです。

またUnityLearnはUnityHubの導入が前提なので、インストールしていない場合はまずは入れましょう。

チュートリアルではコース資料のファイルを手に入れて、サンプルを動かしましょうと記載されています。

が、チュートリアル内で手に入れられるファイルでは

記事に書いてある通りにプロジェクトの追加をしても無効になりますし、

そもそもパッケージファイルなので何とかする必要があります。

新しいプロジェクトを作成して、パッケージをインポートするとファイルがコピーされました。

ただ、肝心のサンプル用のシーンは入っていませんでした。

 

実際の中身

チュートリアルを見ていると説明不足になっていて補足をすると、

このパッケージファイルは実際にこの後に制作するためのアセットになります。

サンプルをプレイせずにチュートリアルを進める場合はこのアセットのみで大丈夫です。

 

それでもサンプルが遊びたい方のために方法を書いておきます。

まずはアセットストアに行き、今回のサンプルアセットをマイアセットに追加します。

assetstore.unity.com

その後UnityHubでサンプル用のプロジェクトを作成します。(2Dで)

プロジェクトを開いた後、Window->PackageManagerを開きます。

ここを押す

MyAssetを選び、さっき追加したサンプルアセットを選択してインポートします。

インポートが終わってからチュートリアルの画像のパスをたどると、

サンプルのシーンが見つかります。

これで、サンプルは遊べます。

 

2.キャラクターを作成

learn.unity.com

前にRuby'sAdventureの項目をやったのでほぼここの項目は復習になります。

基本的にキャラクターを配置して、動かすプログラムを書く項目でした。

 

まずはUnityHub上でプロジェクトを作成します。

2Dで作成するのでタイプは2Dゲームを選択して、わかりやすい名前を付けて作成すればエディターが開けます。

(アセットまわりの関係で導入の時点で終えています。)

最初にシーンを作成するようにと書いていますが、

前に読んだ本などではSampleSceneの名前を変更しても大丈夫だったので、

この辺は自分の好みで大丈夫そうです。

 

次のステップではアセットのArt->Ruby->PlayerCharacterを配置して、

位置の確認をしていました。

その後はカメラの確認をしていました。

この辺はまだまだ基礎の部分です。

 

次はキャラクターを動かすスクリプトを書く項目です。

まずはScriptディレクトリを作成して「PlayerController」ファイルを作成することからスタートです。

始めはx軸に対してどんどん右に行くプログラムを書きました。

位置を読み込んで計算して、代入するだけの簡単なプログラムになりますが、

自分の言葉でやっていることを読めるようにしておいた方が後々楽かもしれません。

Unityではプログラムを書いただけでは動かないので、

必ずそのコードを使用するオブジェクトにアタッチする必要があります。

この状態であれば大丈夫

確認や応用を試して納得できれば次に進みます。

 

3.タイルマップ

次のステップは地形用の画像データをタイルマップにして、

クリックで簡単に画像を配置していこうという内容でした。

まずは下準備としてHierarchyで右クリックして2d->TileMap->Rectangularを選択して、

タイルマップを置く下地を作ります。

タイル制作用にディレクトリを作成して、右クリックをして2DからTiles->RuleTileを選択して作成しました。

その後アセット内にあるTile1を作ったRuleTileにアタッチして使えるようにします。

Selectをクリックして画像一覧から探す

その後Windowから2D->TilePaletteを探して開いて、

NoValidPaletteのところからCreateNewPaletteをクリックして新しいパレットを作成します。

新しいパレットをさっき作ったTilesディレクトリに保存してから、

使えるようにしたタイルをドラッグドロップしてタイルパレットに貼り付けます。

同じようにもう1つもやる

何もないとわかりにくいですが、貼り付けるのはちょうど画像でタイルが表示されている部分です。

前にやったのは1つの画像を特定の大きさで区切ってタイルパレットを作っていたのですが、今回はまずはこの方式なのかもしれません。

あとはステップの通りにタイルを置いていきます。

このままではサイズが合わないので、ステップ通りに画像のサイズを修正して調整します。

タイルは置けた。キャラは隠れた。

タイルは置けましたがキャラクターは隠れたので、次はレイヤー調節を行いました。

2Dゲームは要するに紙の上に絵をいくつも重ねていく表示方法なので、

画像の順番を決める必要があります。

ステップ通りにタイルマップを下に、キャラクターを上にすればキャラクターが表示されます。

 

4.キャラクターを操作する

今まででしたら入力はUnityの基本機能でコードを入れていたのですが、

(復習しないとかなり抜けてしまっている)

このステップでは入力は「InputSystem」のパッケージを使って製作するみたいです。

パッケージのインストールはWindow->PackageManagerから探して行えば大丈夫です。

探すのに苦労した

初期画面ではプロジェクトにインストール済みのパッケージしか表示しない場合もあるので、よく探せば大丈夫です。

このパッケージは入力のコードを楽にできるようにできていて、

以前の方法に比べて比較的少ない労力でまとめることができるらしいです。

(最後にちょっとまとめてみる。)

前に入力したコードの始めのUnityEngineの後にusingでInputSystemを組み込めば、

(上に同じような並びがあるのでそこに書けば、問題なし。)

今後このコードのファイル内ではInputSystemは使えるようになります。

入力するコードは右を押せば水平値が+1.0、左を押せば水平値を-1.0にするようにして

前に作った座標変更に掛け算することでどちらに進むかを決めています。

 

チャレンジとして垂直方向を自分で入力してみようというステップがありますが、

horizontalをverticalに変更しxをyに変更、キーを上下に変えれば問題ないです。

positionはVector2ですでにyも作られているので、Vector2の初期化は1つだけで大丈夫です。

 

5.入力を最適化する

今の状態だとコントローラを使ったときなどに反応しないし、実装のために多くのコードを書く必要があるそうです。

これはとてもめんどくさいのでInputSystemの機能であるInputActionを使って、入力を最適化するのがこのステップみたいです。

 

ステップではまずPlayerControllerにpublicでInputAction型のLeftAction変数を用意して、

(public変数はStart関数より先に書く)

Inspector上のLeftActionの設定変更(歯車)でActionTipeをButtonに変更しました。

その後+を押してKeybindingを選び、対応するキーバインドを追加します。

新しいキーバインドをダブルクリックして対応するキーを入力すれば完了です。

キーを検索する時にListenボタンをクリックしてボタンを押すと押したボタンが表示されるので、これをうまく使うと検索できるようです。

これで左キーを押すとLeftActionがtureになるので条件分岐に使えるようになるので、

左キーを押したときの条件文をLeftAction.isPressed()に変更することができます。

しかし、これではキーの方向ごとにpublic変数を作らないといけないので、

コードは長くなるし手間もかかります。

そのため次のステップでひとまとめにする方法が説明されています。

 

新しく先ほどと同じようしてMoveAction変数を作成し、Inspector上にあるMoveActionの設定のActionTypeがValueになっているのを確認します。

(前はボタンが押されたかどうかだったけど、今回は値を取得するみたい。)

次に入力するボタンを追加するのですが、ここではAdd Bindingではなく、

Add UP,Down,Left,Right Compositeを追加するみたいです。

間違えないように

その後、対応するボタンを設定することで、キーバインドを設定できます。

設定が出来たらコードを記入します。

まず、Start関数でMoveActionを有効にするためにMoveAction.Enable()と記入します。

(説明だけで済まされていたので、書くのが分かりにくかった。書かないと動かない。)

その後のコードはmove変数はMoveActionの値を読み込み、

position変数に次フレームの位置を計算してtransform.positionに代入しています。

これで実行すると前と同じように方向キーでキャラクターが動きます。

この状態だとキーはInspectorで増やせるし、コードも短くて済むようになるという感じです。

 

6.フレームレートを調整する

特にPCで遊んでもらう時にはユーザーのマシンスペックによっては、

フレーム飛びが発生してゲームが遊びにくくなります。

このステップではフレームレートを調整して、パフォーマンスの改善を行うみたいです。

フレームレートについては他で調べていただいた方が分かりやすいです。

簡単に言うと1秒間に何枚絵を更新するかという感じです。

始めに提示されているコードをStart関数に入力すると、フレームレートが10fpsに固定されます。

この状態だとすごく遅く感じます。

(垂直同期を無くして、フレームを10に固定する感じ)

ただ、少なくとも前のコードに比べるとちょっと押しただけで猛スピードで行くことは無くなりました。

フレームレートは可変するものなので、固定にせずハードウェアに合わせて変化させるようにした方がパフォーマンス的にもいいです。

次のステップではキャラの移動に「Time.deltaTime」をかけるコードに変更しています。

Time.deltaTimeはUnityがフレームレートを次のフレームまで更新する時間を格納していて、かけることによってフレームレートに合わせることができるみたいです。

(詳しい説明はリファレンスを参照)

この状態だと1フレームに対して0.1しか進まないので、すごく遅い移動になります。

なので、移動の0.1fを3.0fに変更して速度を上げました。

 

ここまででチュートリアルの2章分まで終えることができました。

 

7.(やってみた)入力方法の違い

このチュートリアルでは入力をUnityの基本機能ではなく、

基本追加パッケージのInputSystemを使って書きました。

2019などのバージョンやそのぐらいを扱った書籍などでは基本機能で書いているので、

違いやコードの長さを分かる範囲でまとめてみます。

InputSystemの方は長い最初のやつではなく、最後にやったMoveActionの方で考えます。

 

基本機能ではProjectSetting内のInputManagerでまずキーバインドなどは設定でき、

Input.GetAxis()でキーの情報を読み込みます。

この時垂直と平行は別々で読み込む必要があり、ちょっとだけ長くなりますが気になる程度ではないです。

設定できるキー数は見た感じ少ない気がします。

InputSystemは始めにpublic変数を設定することでエディター内でキーを設定することができるようにしています。

キーバインドを視覚的に設定できるし、複数設定できます。

うまくいけば同じコードで複数の操作体系が組めることができそうですが、

Start関数で有効にしないといけないや設定がややこしそうという手間が感じられます。

リファレンスをもうちょっと熟読すればInputSystemの方が利便性が高いような気がするので、

今後の制作では環境に合わせて実装してみるのもいいかもしれません。

 

まとめ

項目は変わっていますが、ほとんどやることは前にやったRuby'sAdventureのチュートリアルと一緒でした。

 

toshirumisoft.hatenablog.com

この時とどのぐらい違うか、もしくはあっちこっち言っていることが変わっているかわかりませんが、

(あんまり過去記事を見直さないので)

とりあえずは最後まではやっていきます。

ただ、InputSystemについて新しく知ったのでこれはいい感じです。

うまく使えば操作の切り替えを瞬時にできそうな気もするので、

使い方はちゃんと覚えたいところです。

次は地形の配置と当たり判定になるみたいなので、

この辺はたぶんほぼ前の復習になりそうです。

 

この記事は下書きでやった日に書いていった感じですが、

記事自体は木曜日あたりにできていました。

必ず土曜日に更新ということで今回は土曜日に投稿しましたが、

別に不定期+定期更新でもいいと自分でも前に決めていたので、

次回の分からは勉強した分の内容は不定期で更新します。

どっちにしても定期更新の近況報告で伝えたいことも別に出る可能性は高いので、

内容を分けて投稿できるようにします。

 

ということで今日はこれにて!

では!

運勢は自分から行くもの

どもです、としです。

年賀イラスト後の新年1発目の定期更新です。

今回は休んでいたのでイラストはありません。

 

お正月はなんだかんだあったものの遊んでいなかったゲームなどを始められて、

まぁまぁいい感じに充実しました。

で、来週からまたやることを再開していこうと考えています。

と言ってもやることが多くて何から手を付けようか迷っています。

今のところのやりたいことは

  • いい加減漫画を1話目だけでも作業を開始する
  • 年賀イラストの案として考えたネタを制作する(イラスト+3Dモデリング)
  • 作曲の練習のために1か月1曲以上の習慣をつける。
  • 前に見つけた気になるUnityLearnの項目を開始する。

ぐらいです。

プラモデルやゲームは時間の合間にやる感じなので、

基本的に作業時間に割り振りたい内容はこの4つに絞れました。

はっきり言いますと漫画を早よ描けが1番いいのでやるべきですが、

どうも今の気分はUnityLearnな気分です。

そりゃ、作りたいゲームもあるのでスキルを高めるのもいいのですが、

実際作りたいゲームの前にやってから流れで作り始めるのがいいですけどね。

合間を開けるのはよくないのですが、今やりたい気分になっているからここは正直に自分の気持ちに沿って行きたいです。

 

やりたいなぁーと思っている項目は

learn.unity.com

learn.unity.com

この2項目です。

上の方が新しいコースになるみたいですが、上から順にやる予定です。

あと前みたいにまとめをこのWeblogで更新もしていく予定になります。

できる限り今月中に終えて来月からは別のことを開始できるようにやっていきます。

(次はどっちにしても漫画と作曲になりそうです。)

 

話はちょっと変わりまして、新年って言ったら今年の運勢占いがよくメディアで出ますが、

ぼくは今年の運は割かしいい方らしいです。

ただ、運がいいからってそれが叶うかって言うと絶対そうではないですし、

努力がないといい運も引き寄せられないので

あーだこーだ言っても行動あるのみで行くしかなさそうです。

ある運勢占いとかでは「いい人に会える」とか言っていましたが、

「いい人」ってきくとある意味今プロットで描いている漫画で言いまくっていたので、

やっぱ今年中に漫画はやらないといけないなぁという気持ちにはなりました。

 

toshirumisoft.hatenablog.com

この時でも「いい人」とはっていう感じで描いていました。

こう見るとぼくにとっての「いい人」は自分自身に対してじゃなくて、

自分のキャラクターに対しての「いい人」でそれを結びつけるのがぼく自身なのかもしれません。

どっちにしても自分のキャラクターに「いい人」を会わせてあげられるのはぼくしかいないので、なんとかやっていきます。

 

なんか今日の記事を見直すと漫画を描かないといけないと言いつつ、

UnityLearnをやろうとしている自分が見えています。

なんだかんだまだフラフラしているのかなぁ。

 

ということで今日はこれにて!

では!

明けましたよ!おめでとうございます

どもです、としです。

明けましておめでとうございます。

今年初めての更新になります。

と言っても、つい先日更新したばかりになりますけど……。

 

今日に更新できたということはもちろん、年賀イラスト2枚目が完成しました。

2023年最後の更新の後に気合が入り、その日のうちに文字以外を仕上げることができました。

あの時は3分の1ぐらいと言っていましたが、意外と3分の2ぐらいの制度だったのかもしれません。

ということで今年の年賀イラストはこちらです。

2024年年賀イラスト(ドラ歌手)

背景はちょっと魚眼レンズ風の技法を試してみました。

久しぶりのオリキャラのドラ歌手たちになります。

12年前の辰年でもドラ歌手を描いていましたが、いつの間にかそんなに月日が経ってしまったと思うとなんだか嫌気がしてきます。

何も変わっていないのかどうかはわかりませんが、結局自分が納得していないのであればそれは変わっていないのだと思います。

あーだこーだ言っても終わったことより次を考えないとなぁ。

 

例年通りFacebookページの方では年賀イラストまとめのアルバムを作りました。

もしかしたらアカウントがないと観られない可能性があるかもしれませんが、

もう1枚の年賀イラスト(送付用)を投稿するので気になる方はそちらでお願いします。

 

新年1発目の更新はこのぐらいにして、三が日はしばらくイラスト以外の溜めていたことをやっていこうと考えています。

どっちにしてもすぐに更新日の土曜日がやってくるので、本年度のやりたいことや次にやりたいことなどのあれこれはその時にまとめます。

どっちにしても去年からの延長線上になるだけなので、特に変わる感じはないですけどね。

 

ということで今日はこれにて!

では!