Видео

明けましておめでとうございます！ 結局無駄の無いソースコードを組むことの第一歩は、いろんな手法を試してみることなのかもしれませんねw 気づいたら制作の半分の時間をリファクタリングに費やしてる。おそろしい話ですよw

なんやかんや四則演算はみんな足し算の繰り返しと条件分岐で表現できると言いますからねえ。ひょっとしたら「どこまで単純構造に分解するかを見極められる審美眼」が大事なのかもしれませんね。

そういう意味では、やはりキャラゲーは強い。例え他のキャラが刺さらなくても一人でも癖にぶっ刺さってるキャラがいれば、ゲームを続ける意欲が湧いてくる。 ある意味必然的に生まれたゲーム体系だったのかもしれないですね。

アナログ！一番良い表現！ 擬似的に連続的なものを取り扱えるようになったからこその難易度の上昇だったのかもしれないですね

うおお！同志よ！ 実はここら辺かなり悩んだ末の結論だったので、共感してもらえてとても嬉しいです！ プレイしてもらうターゲットは最も重要と言っても過言ではないので、今後もどんどん明確にしていきたいですねえ。

なかなかとても面白い。 そういう意味では、チーム開発の利点がまさにそこにあるのでしょうね。様々な視点を持った人が集まることでゲームの専門的な視点を削ることができ、より多くの人が楽しめるゲームを作ることができる。 逆に少数であればあるほど、作品の見た目も奇抜なものへと変わっていく。これはこれで一部の層に刺さるため、とても面白い。 ゲーム開発のやり方が一つではないことを実感させられます！

良〜い質問ですね〜 実はComponentのコンストラクタで初期化の処理をすべて任せるのは、作り方によっては可能だと思います。 ComponentFactoryを実装している利点は、ComponentやGameObjectの初期化に関わる役割を削減できるという点が挙げられます。ComponentFactoryを実装しておくことで、Componentそのものを登録しておく機能など、比較的「Componentの外部に任せたい作業」を実装することができます。 要するに「プログラムの構成がわかりやすくなる」というのが、結局のところの利点だと思います。（たぶんComponentですべてを管理する場合、static変数やstaticメソッドを使って同様のことが可能だと思います） あとnew演算子やdelete演算子をなるべく直接使いたくなかったり、作ったComponentをまとめて管理できたりすると便利だなーとか考えたりして、作っておいた方がいろいろ便利だなと実装に踏み切りました！ たぶん他にも実装方法はいろいろあります！

@@SukakiyoLab 返信ありがとうございます! たしかにランタイムで設定ファイルからもろもろ読み込むときなんかは結局条件分岐書いてインスタンス化対象を切り替えることになるので `Component`生成のもろもろを担うクラスがあった方が楽そうですね。いや～失念してました

いえいえ自分もまだまだプログラミング初心者なので、めちゃくちゃ助かります！ （やっべ、よくよく考えたら「ちょっと前までめちゃくちゃ読みにくいソースコード書いてた」なんて言えない）

@@SukakiyoLab (注:長文です。mdエディタに張り付けて読むこと推奨) いえいえ私も全然初心者ですので... 一応最近勉強しているなりの提案を書いておきます ファクトリ側に各`Component`ごとの定義を書いちゃってて、具体的すぎる気がするので、その部分をDI的な構造にして外に出すといいんじゃないかと思います。 `Component`が増える度に`ComponentFactory`の中身をいじりに行くのは面倒ですし。 C++わからんのでTypescriptで適当に書いた例: (型定義がクソ雑魚なのは許して...) ```typescript /* Static members */ interface ComponentConstructor{ tryCreate(option: unknown): Component | null; /* Add definitions below if you want. */ } /* Non-static members */ interface Component{ /* Add definitions below if you want. */ } /* おまじない (deep.tacoskingdom.com/blog/181) */ const Implements = <T>() => <U extends T>(ctor: U) => ctor; class ComponentFactory{ private readonly registered_components: Set<ComponentConstructor> = new Set<ComponentConstructor>(); public register(component: ComponentConstructor): void{ this.registered_components.add(component); } public createComponent(option: unknown): Component | null{ for (const component of this.registered_components) { const result = component.tryCreate(option); if (result) return result; } return null; } } @Implements<ComponentConstructor>() class StringComponent{ private readonly option: string; public constructor(option: string) { this.option = option; } public static tryCreate(option: unknown): StringComponent | null{ return typeof option === "string" ? new StringComponent(option) : null; } } @Implements<ComponentConstructor>() class NumberComponent{ private readonly option: number; public constructor(option: number) { this.option = option; } public static tryCreate(option: unknown): NumberComponent | null{ return typeof option === "number" ? new NumberComponent(option) : null; } } const factory = new ComponentFactory(); factory.register(StringComponent); factory.register(NumberComponent); console.log(factory.createComponent("Hi!")); // Output: StringComponent { option: 'Hi!' } console.log(factory.createComponent(42)); // Output: NumberComponent { option: 42 } console.log(factory.createComponent(false)); // Output: null ``` (staticなメンバーをinterfaceに書こうとするとややこしくなるのはJS由来のTSの仕様なので気にしてはいけない) これで`ComponentFactory#createComponent(option)`したときに`ComponentFactory`に`register()`した`Component`の`tryCreate(option)`を片っ端から呼び出して、成功したらその結果を返す挙動になります。 (全て失敗したら`null`を返す。一応雑に動作確認済み。) ただ、こういう定義をすると当然型による補完が効かなくなります。 動的に返すインスタンスを切り替えるのに使うだけなら大した問題にはならないと思いますが、ハードコードした`Component`を使いたい場合にファクトリから呼び出すのが補完が効かなくてうざかったりするかもしれません。 その場合は`Component`のオプションに補完を効かせるためだけの関数なんかを定義するといいかもしれません。 (もっといい方法あるかも...) 具体的な実装方法ですが、多分C++で実装しようと思ったら、 - `register()`あるいは`new`時に`tryCreate()`相当の関数を関数ポインタで受けて、適当なコレクションに保存 - C++でできるか知らんが、上のTSコードは(インスタンスではなく)クラス自体を受け取るような処理をしている。 もしできるならその方が分かりやすいコードになるかも。 - `createComponent()`時に保存した関数ポインタ達を列挙して片っ端から与えられたオプションと共に呼び出す という実装になるんじゃないかと思います。 ご参考までに。

大変ですが、リファクタリングは念入りにやっていきたいですね。ここをいかにわかりやすく作れるかが今後の活動にも響いてくるので。 ただし時間をかけすぎるとモチベも下がっていくので、システムの根幹部分に関しては次回で決めに行きたいところです。

自分がまだまだ未熟であることを痛感させられます。 どんどん調査と試行を繰り返さなくては！

そうなんですよ！ 要素ごとのターゲット層が食い違うと、それだけでかなりプレイしてもらえる人数が絞られてしまう！ 気を抜くとうっかりそういった間違いをする場合があるので、落ち着いて他の人が作ったゲームを分析することも大事なんだと思います

確かにちょっと足の出方が小さいような…… モーションの違和感はなかなか言語化が難しいので、ご指摘ありがとうございます！

やはりそうだったのか… いろいろ勉強したけど結局パラメータいじって試行錯誤してたような。 まあ、楽しかったから良し！（グッジョブ）

そうなんですよね！ 中身を知っておくと自然と理解してプログラムを作ることができる。そういう意味では、いろいろな面でオープンソースのツールは役に立ったりするんですよね。

英語読める人羨ましいですね！ 自分も普段はライブラリの使い方は必要な部分だけしか読まないタイプだったので、実はBox2D以外のライブラリに関しては知識が虫食い状態だったりしますw

仲間がいた！　行列こんがらがるのワイだけやなかったんや！ そして、複雑なシステムであるほどソースコードの整理が必要なのすごく同感です！ 諸事情あって最近2Dゲームの物理関連のシステム全部ぶっ壊すことがあったのですが、前にリファクタリングしてたおかげか、それ以外のシステムはほとんどダメージ無かったんですよ。きちんとソースコードの整理しておいて良かったと実感しました！

ありがとうございます！

確かに！ 「自分が何をわかっているのか」とか「自分はどれを学ぶのが得意なのか」とか、ひょっとしたら創作をする上で一番重要なのは「自己分析」なのかもしれませんね。

ありがとうございます！ モーション作成についてはまだまだ学んでいくつもりですので、ぜひお楽しみに！

コメントありがとうございます！ まさにその通りで、自作するとオリジナリティのある世界が作れてとても楽しい！ これからも頑張っていきます！

ありがとうございます！ キャラ褒めていただけて嬉しいです！ いや本当にいつも楽しく動画見させてもらってます！（もう一周してこようかな） いずれ追いついて見せますよ！

@@SukakiyoLab ありがとうございます 同じゲーム制作動画投稿主としてこれかもゲーム制作を盛り上げていきましょう！！

開発段階でエラーの出ないバグが見つかるなんて縁起が良いなー（白目） 設定に関しては、操作方法やレベルデザインといったゲーム内容にどれぐらい結び付けられるかが肝になっていく気がします！

コメントありがとうございます！ うおお！　いつも雪姫ちゃんの動画楽しく見てます！ これからもお互いゲーム制作頑張っていきましょう！（でも無理はなさらずに）

本当にUnityやUnreal Engineが多大な努力で作られてるのを実感します！ 無料で使えてることがなんとありがたい！

ありがとうございます！ 確かに抽象的な概念は「こうかな」と思って理解したものが間違っていることが珍しくないので、どんどん試行錯誤して学んでいく必要があると感じております！ ということで、イチゴちゃん。次は4倍速、行ってみようか。

手首確かに細い！　ただでさえ細い手首が、曲げた時にはエグいことに！ 調べてみるとウェイトペイントの塗りが甘かったようで……。このあたりは今後も勉強していく必要がありそうです！ 脳が、キーマウと繋がっていくのを感じる

まさにおっしゃられる通りで、リファクタリングは辛かったものの、ソースコードの見栄えやシステムのプロセスを大幅に綺麗にすることができました！ そのおかげで次回以降の作業のフォーマットもある程度決まり、おそらく見栄えのある動画を提供できるはずなのでぜひお待ちを！

これで電池切れを気にせずゲームをプレイできるね！ （なお遊びすぎるとプレイヤーが電池切れになる模様）

ありがとうございます！今後もマイペースで頑張って行こうと思います！ たとえ転んだとして車輪が如く進んでいきますので、ぜひご安心を！

ありがとうございます！ 今後も続々と動画投稿していくつもりですので、ぜひ楽しんでいってください！

コメントありがとうございます！ あのお方は我が教祖