Unity: Addressablesでフォルダはネストできない

環境

• Addressables 1.8.4

現象

ざっくりフォルダごとにAddressablesで管理したい場合に、入れ子になったフォルダではできないようです。
ネストした状態でもUnity Editor上なら再生でき、ネストも一見できてるように見えるのですが、Androidビルドする時に以下のエラーが出るようです。

ArgumentException: An item with the same key has already been added.

以下のような構成にしてそれぞれのフォルダに対してAddressablesのチェックをonにしました。

- Prefabs (Addressablesのチェック)
  - 何かのspriteたち
  - Takoyakis (Addressablesのチェック) 
    - 何かのspriteたち

こういう構成だと、AddressablesのwindowではPrefabsとTakoyakisは別のGroupとして設定でき、別のラベルを設定できるのですが、いざビルドすると重複キーがあると怒られてしまいます。

対策

ざっくりチェックは諦めて、以下のようなツールを使って管理するのが良いかもです。
【Unity】【Addressable】Unity Addressable Importerでアドレスの設定を自動化する - LIGHT11

Unity: 落下の自前計算 (簡易版)

Cheap gravity script - Unity Answers

厳密には違いますが、簡易版で同じような動きになります。

そこまで正確に動きを計算する必要がないのでこれでいいならこれを使いたいです。

簡易重力を自前で計算した時の鉄球の動き↓

float velocity = 0;
void FixedUpdate() {
      var pos = transform.position;
      velocity += Physics2D.gravity.y * Time.fixedDeltaTime;
      pos.y += velocity * Time.fixedDeltaTime;
      transform.position = pos;
}

Unity: UniRxのUpdateAsObservable

UpdateAsObservable

Updateを実行することができる

使い方

using UniRx;
using UniRx.Triggers;

void Start() {
    this.UpdateAsObservable()
            .Subscribe(UpdateRx);
}

void UpdateRx(Unit unit) {
    Debug.Log("updating");
}

this.UpdateAsObservable()をSubscribeしてあげることで、Updateされ続けます。
そして、subscribeしたものはobject破棄のタイミングで消滅します。

便利だと思ったこと

Updateは別のscriptから初期化処理を呼び出してから呼びたい場合、

using UniRx;
using UniRx.Triggers;

public void Init() { // publicで他scriptからinit
    this.UpdateAsObservable()
            .Subscribe(UpdateRx);
}

void UpdateRx(Unit unit) {
    Debug.Log("updating");
}

こういう感じで書けるので、
Init
UpdateRx
の順番が保証できるので便利だな思いました。

Rust: getterとsetter

Rustでgetterとsetterを作りたかたったので調べました。

oop - Writing getter/setter properties in Rust - Stack Overflow
↑のサイトから拝借して、単純化してみると以下になりました。

#[derive(Default)]
struct Person {
    first_name: String,
}

impl Person {
    // Immutable access.
    fn first_name(&self) -> &String {
        &self.first_name
    }
    // Mutable access.
    fn first_name_mut(&mut self) -> &mut String {
        &mut self.first_name
    }
}

setterは関数内では値を代入せずに、&mutを返していて、受け取り元で値変更ができるようになっていました。
rustではこういうのはパターンの一つとしてあるようです。

疑問

setterで何かsetする前に値に応じて処理を行いたい場合はできないのではないでしょうか？

Rust：selfは糖衣構文

Rustのself引数まとめ - 簡潔なQ

selfは糖衣構文で&が付いていようがついてなかろうが、引数を使う時はself。
&selfで定義して、使う時は&をとったselfで使うことに少しもやっとしていたので、理解できてよかった
(&selfで定義するとselfが&selfとして利用できる糖衣構文)

struct ReactiveProperty<T> {
    value: T,
}

impl<T> ReactiveProperty<T> {
    fn value(&self) -> &T {
        &self.value // (self.valueの&)
    }

    fn value_mut(&mut self) -> &mut T {
        &mut self.value // (self.valueの&mut)
    }
}

Unityをアプデしたらエディタコンパイルが速くなっていた

環境

• Unity 2019.3.15 -> 2019.4.4
• iMac 2019

推測される原因 (予想です。)

Enter Play Modeが実装されてからソースコードを変更した時に行われるコンパイルが異常に遅くなっていました。昔なら3から5秒くらいだったのが、30秒以上かかることがざらになっていました。

推測ですがEnter Play Modeが実装されたせいで何か影響が出たのではないでしょうか？
Enter Play Modeで設定することで再生する速度はめちゃくちゃ速くなりましたが、エディタのコンパイル速度がとても遅くなったので、モヤモヤしていました。

2019.4.4に上げた

バージョンをあげると昔のようなコンパイル速度に戻っていました。

感想

いろいろ試しても全然元に戻らなく、開発効率が悪かったのですが、元に戻ってとても嬉しいです！
Enter Play Modeのおかげで再生のスピードも上がったし、コンパイル速度も元に戻ったので今のUnityのバージョンはとても嬉しいです。

デザイン：ナイトを描いた時の思考の備忘録

デザインスキルがないので、いつもデザインは気合と根性で描いています。

今回描いたのは「ナイト」です

(自作ゲームで使います)

自分的にはぱっと見良さげな感じに見えるのでとても満足しています。

精神状態

デザインはとても疲れるので、やる気も出ず、進捗も出ないので、なかなか進みません。
ナイトを描こうとした時、色々描かないといけない部分が想像できるので、気分が凹みます。(「1時間程度では終わらないだろう」など)

うまくいかないので、ココナラなどでデザイン依頼をいっそのことしてしまおうかと、色々検索してしまいました。(心が半分折れる)

心が折れる原因

• 時間がかかるのが容易に想像できる
• 完成が想像できない
• 序盤で詰まる

ナイトを描いた時の思考の備忘録

民族

全体的に中世の騎士というよりも少し民族風の色合いにしたかったので肌は赤褐色にしました。

おもちゃ

リアルよりもおもちゃのようなイラストにしたいので、ポンコツ感をだしました。

装備

頭だけ中世風の甲冑を装備させました。全体に装備させないのは工数カットと民族感を出すためです。

馬の色

全体的にかわいいイラストになるので、少し強くみせるために、青黒い色にして、強さを表現しました。
青黒い色と赤のコンビはとても引き締まった雰囲気が出ます。

影

キャラには影をつけていませんが、馬や装備には影をつけました。
なんか適当につけただけです。それっぽくなっていれば嬉しいです。

足の数

2Dなので本当に4本いるのかどうか、2本でも良いのでは？ (一応４本にしました。)

感想

案外描いてみるとうまく行く時もあれば、うまくいかない時もあるので、気合と根性で進めれば、なんとかなりました！

続ければなんとかなる！(たぶん)