最近の記事

【unity】外部クラスからinstantiateしたオブジェクトのpublicメソッドを叩いたとき、どの順で実行されるか

Awake > 呼び出したメソッド > Start の順 Startより先に呼び出したメソッドが実行されるので、外部から実体化を伴って呼び出されるかどうかでスクリプトを切り分けると初期化で事故らなさそう (一応インスペクタから入れておいたりAwakeで準備したり色々できるが、そのあたりをオブジェクトによって変えてナレッジ化したくない意図) この辺の切り分けは何かしらの機能とか性質で定められてる気はするんだけど、ちょっとわからない みやぶりてえ……

    • Instantiateするとコードがめんどくさくなる件

      Instantiate()を使うためには下記がおまけで付いてくるため、dotweenなどで手を加える際に変数のスコープを気にしたり、また単純にコードが増えて複雑な追跡が必要になる。あまり使うべきではないかもしれない。 プレハブなどの参照を保持する変数 生成した実体を入れる変数とそのスコープ管理 用済みになった際の破棄や演出などの処理(実体) 上記生成や破棄などが適用される先が、実体かもとの参照になるかの判断(継承やインターフェース実装が挟まると急にダルくなった) 使

      • 進捗:バージョン管理とクラス機能整理

        やろうやろうと思って後回しになっていたunityのバージョン管理をついにやった。 UnityHubからバージョン管理のページ飛べるので、そこから流れ作業で特に難しい手続き等もなくできた印象。簡単すぎて拍子抜けしちゃった。 調べるとnoteとかでもまとめ記事見つかるので、初めてでも一時間もかからないかもしれない。 バージョンの巻き戻しとかもできることを確認したので、まず安心か。 よだん なんで今さらかというと、steamで売っているあるゲームのソースコードがトラブルで紛失

        • 遠くに見えている地雷の香り

          メモリ解放、やってますか。(やってない) unityでassetを動的に読み込む仕組みを調べる中でResources.UnloadUnusedAssets()というものを見つけた。 どうもメモリの開放をするような役割っぽいのだが、そういえば深く考えずに実体化させたり読み込んだりデータ作ったりしてるけど大丈夫なのかなと不安になった。 ぶっちゃけ、今のところは扱う量も仕組みも大した事ないからPCとかUnityがうまくやってくれてるけど、いつかアセット自体が豪華になったりした時に

        【unity】外部クラスからinstantiateしたオブジェクトのpublicメソッドを叩いたとき、どの順で実行されるか

          閾値テーブルをどう設定するか考えた

          制作中のゲームで俗に言う親愛度システムを採用する予定なので、ここ最近はその仕様決めのようなことをずっとやっている。 んで、親愛度のテーブルがゲーム全体の制御に関わる部分に食い込んできていたので、ちょうどいい機会だし考えてみるか、と自分なりの手順を整えたのでメモ書き。 y=ax^2 まずは下記の画像。 下記画像はわたしのprocreateでの筆圧曲線である。どうでもいいですね♨ 本題は下記画像y=ax^2の図示 これの都合が良さそうなところは横軸をレベル、縦軸をそのレベ

          閾値テーブルをどう設定するか考えた

          敗北(EditorWindow)

          ここ数週間ずっと、リストを持つ自作クラスのリスト(ややこしい)をEditor拡張機能良い感じにで表示できないかと触っていたが、敗北した。 ヤムチャ視点での敗北のためこの失敗が糧になることもなかろうが、おれのようなヤムチャにそれヤムチャですよとヤムチャしてくれるヤムチャ記事があってもいいはずなので記す。 ver21.3.21fです。 敗因 自分のちょうどやりたいことを実装するためには写経では足りなかったため、色々と仕組みや方法を探ったわけだが、属性の付与や未知の型の知識サル

          敗北(EditorWindow)

          クラス図の継承/インターフェース実装における矢印の向きついて、SOLID原則(のO)からなんとなく理解した

          結論、疎結合で書けばクラス図がスッキリするため。 「継承する/実装する」という語感から、より上位にあるものを受け継ぐというイメージがあり、「下される」ことの図示であれば親クラス(インターフェース)>子クラス(実装)の向きの方が直感的ではないかとずっと疑問だった。 継承/インターフェース実装により、子のインスタンスや実際のオブジェクトを直接参照・検知する必要なく、基部から処理を実行できるようになる。 クラス図でその図示を行う際、呼び出し側から何本も線を引いて実体と結びつける(

          クラス図の継承/インターフェース実装における矢印の向きついて、SOLID原則(のO)からなんとなく理解した

          カスみたいな躓き~UnityHubのアップデートを添えて~ 進捗もあるよ

          PackageManager>MyAssetsに購入済みのAssetが表示されない 調べても「ログアウトしてる」「そもそも買ってない」の2パターンがヒットするがどちらでもなくて無駄に沼ったのでメモ ディレクトリの構成をいじった覚えもないしなんでかな~と思って色々触ったが、Unityやアカウントの方ではなくUnityHubを最新版にアップデートしたら治った 以上だ… いやほんとカスみたいな時間だな…… 余談: Unityに限らないんだけど、アプリの最新verって情報が出

          カスみたいな躓き~UnityHubのアップデートを添えて~ 進捗もあるよ

          Unityでタワーディフェンスっぽいものを作ったときに困ったこと

          そういえばこんなことあってキレたなと思い出したので備忘録として記載。 unityのverは2021.3.21f1 OnTriggerEnter/Exit2Dが適切でないタイミングで機能する、または機能しない前提 各レベルはマップエディタで作成しており、またマップには「壁」と「そうでない部分」の2種類が存在している仕様にしていた。 自軍ユニットは壁マスにのみ配置可能で、対して敵ユニットは壁でないマスをゴールに向かって進軍する形である。 また、自軍ユニット一つの大きさは壁1

          Unityでタワーディフェンスっぽいものを作ったときに困ったこと

          unityでタワーディフェンスっぽいのを作ったので振り返りメモ2-2:レベルデザインと今後の制作

          https://note.com/___9743/n/n950abfdf1869 の続き これもきっちり反省したかった。 完成させてわかったこと:後編https://unityroom.com/games/syusakutowerdiffence タワーディフェンスというそれなりに凝ったシステムのゲームを作ったことで、ブロック崩し等の小さなゲーム制作では気付けなかった気付きがあった。 それらにより今後の制作に大きく影響が出そうな予感があったので、整理するために書いていく。

          unityでタワーディフェンスっぽいのを作ったので振り返りメモ2-2:レベルデザインと今後の制作

          unityでタワーディフェンスっぽいのを作ったので振り返りメモ2-1:仕様決め

          https://note.com/___9743/n/naf021812df7a  の続き この記事が一番書きたかったまである 完成させてわかったこと:前編https://unityroom.com/games/syusakutowerdiffence タワーディフェンスというそれなりに凝ったシステムのゲームを作ったことで、ブロック崩し等の小さなゲーム制作では気付けなかった気付きがあった。 それらにより今後の制作に大きく影響が出そうな予感があったので、整理するために書いてい

          unityでタワーディフェンスっぽいのを作ったので振り返りメモ2-1:仕様決め

          unityでタワーディフェンスっぽいのを作ったので振り返りメモ1

          https://unityroom.com/games/syusakutowerdiffence unityとC#の勉強の一環でタワーディフェンスの習作みたいなのを作って公開できたので、得られた知見など色々振り返っていく。 まず断っておくこととして、自分は独学でunityとC#を学んでおり、やり方や考え方、何よりつまずく場所とつまづき方の正しささえ知らない身の上なので、本職やちゃんとした頭脳の持ち主が見たら吐き気を催す記事になるかもしれない。その点ご承知いただいたうえで、も

          unityでタワーディフェンスっぽいのを作ったので振り返りメモ1