imog

主にUnityとかの事を書いています

2018年の抱負

明けて一週間くらい経ってた。

昨年は家を買ったり東京に引っ越したり、家族が体調を崩したりとだいぶ大変な年ではあった気がする。

今年は2017年より忙しくはなさそうなので、抱負を二つ宣言しとこうかと考えた。

プログラム以外の領域に手を出す

具体的には、絵を書いたり作曲とかをやろうと思う。

きっかけは、東京でいろんなコミュニティに顔を出して様々な開発者と話してからだ。誰も彼も凄まじい情熱を持っており、デザインからコーディングまで全てを一人でやる人も珍しくはない。 自分は基本的にコーディングのみで、音楽やイラストなどのリソースはアセットストアや知人に依頼などが多い。質の良いものを出すという点で委託は良い手段だと思うしこれからもやると思う。が、それはやらない理由にはならんよなあと話してて思った。 作りたいものを他人に伝えられないというところも大きい。以前モデラーの人に作りたいものを文章と口頭で話したことあるけどかなり大変だったし、デザインラフでも描いておけば楽だったんだろうなあと思った。 現状、自分の表現の幅が狭いんじゃないか?という気にはなった。あと単純に楽しそうだから。

とはいえ本業はプログラマーなので、そこのキャッチアップはきちんとしていかないといけないのでどうしようかな〜〜と思ったところで腹が減ったので松屋に行ってきます。

もう一つの抱負は、健康に気を使う事です。

RxJava2でオペレータを自作してみる

Android アドベントカレンダー 17日目の記事です。

qiita.com

Rxは非常に便利なライブラリです。特にオペレータ群はとても強力で、filterやmapやflatmapなど使っておけば割となんとかなります。 が、それ故に雰囲気で書けるとこもあり、「オペレータって具体的にどんな感じで動いてるの?」となることもあります。僕も雰囲気で書いてます。

今回は、実際にオリジナルのオペレータを作ることで、中で何が起きているのかをざっくりと見てみましょう。

事前準備

RxJavaリポジトリをcloneしておきましょう。

今回はforkして手元に持ってきました。

github.com

作るオペレータ

なんでも良いですが、とりあえず2種類作ってみましょう。

本来はFlowable、Single、Maybe、CompletableなどそれぞれのPublisherに応じたオペレータを作る必要がありますが、数が多いので一旦Flowableに対応したものだけにします。

Imo ファクトリメソッド

justやtimerなど、ストリームの最上流にいるメソッドです。 彼らは実際にデータを生成してSubscriberに流すのがお仕事です。

今回は、imoオペレータを作ります。役割は以下です

  • "imo" という文字列を生成し流す

需要は高そうですね。

Println オペレータ

こちらはfilterやmapなど、最上流ではなく上から流れてきたデータをごにょごにょするオペレータです。

役割は以下。

  • 上流から流れてきたデータをSystem.out.printlnで出力する

これら二つを作成すると、最終的に以下のようなコードが書けるようになります。

Flowable.imo().println().subscribe();
// => imo とログが吐かれるだけ

Imoオペレータを作る

FlowableImo class

RxJava2において、全てのオペレータは独立したクラスになっています。 例えばFlowable.justの中身は以下です。

https://github.com/adarapata/RxJava/blob/d3455d0c9d57d522c31b5c25af83e8f2b8df12b6/src/main/java/io/reactivex/internal/operators/flowable/FlowableJust.java#L26

コンストラクタで値をもらって、購読時はSubscriptionにデータを包んでSubscriberに渡します。

そのままだと利用者側はメソッドチェーンで呼びづらいので、Flowableのメソッドで呼べるようにいい感じにラップしてるようです。

https://github.com/adarapata/RxJava/blob/6a44e5d0543a48f1c378dc833a155f3f71333bc2/src/main/java/io/reactivex/Flowable.java#L2489

なので、新規にオペレータクラスを作るなら2つの実装が必要です。

  • オペレータクラスの作成
  • Flowableにstaticなメソッドを定義する

なのでまずはjustに習ってFlowableImoクラスを定義します。

public final class FlowableImo extends Flowable<String> {
    public FlowableImo() {
    }

    @Override
    protected void subscribeActual(Subscriber<? super String> s) {
        s.onSubscribe(new ScalarSubscription<String>(s, "imo"));
    }
}

imo の決め打ちになるので引数はありません。subscribeActualでは購読処理のためにSubscriptionをSubscriberに投げています。

継承元であるFlowableがSubscriberインタフェースを実装しているので、subscribeメソッドは実装済みですが、こちらは分岐させたりなどして実際にonSubscribeするところまで至ってないのでActualという意味で分けてるっぽいです。

https://github.com/adarapata/RxJava/blob/6a44e5d0543a48f1c378dc833a155f3f71333bc2/src/main/java/io/reactivex/Flowable.java#L13026

subscribeActualが呼ばれるのは、Flowable内で適切なSubscriberを生成した後のようですね。

https://github.com/adarapata/RxJava/blob/6a44e5d0543a48f1c378dc833a155f3f71333bc2/src/main/java/io/reactivex/Flowable.java#L13082

実際Subscribe呼ぶときはonNextだけのConsumerを渡したり、Subscriberを直渡ししたりだとバリエーションが多いので、それらを吸収するための措置っぽい。

定義し終わったら、Flowableから呼べるようにstaticなメソッドを追加します。

public abstract class Flowable<T> implements Publisher<T> {

~~~~~~~~~~~~~~~~~~~

    @CheckReturnValue
    @BackpressureSupport(BackpressureKind.FULL)
    @SchedulerSupport(SchedulerSupport.NONE)
    public static Flowable<String> imo() {
        return RxJavaPlugins.onAssembly(new FlowableImo());
    }
}

back pressure対応やスケジューラなどの設定アノテーションが付いていますが、長くなりそうなので今回は気にしないことにします。

やっていることは、FlowableImoを生成して返すだけです。その際に、RxJavaPluginsでFlowable生成時のフック処理を書いていた場合、それも引っ付けて返すために RxJavaPlugins.onAssembly を呼んでいます。

Printlnオペレータを作る

次は流れてきた値をprintlnするオペレータを定義しましょう。

public final class FlowablePrintln<T> extends AbstractFlowableWithUpstream<T, T> {
    public FlowablePrintln(Flowable<T> source) {
        super(source);
    }

    @Override
    protected void subscribeActual(Subscriber<? super T> s) {
        source.subscribe(new PrintlnSubscriber<T>(s));
    }

    static final class PrintlnSubscriber<T> implements FlowableSubscriber<T>, Subscription {
        final Subscriber<? super T> actual;

        Subscription s;

        PrintlnSubscriber(Subscriber<? super T> actual) {
            this.actual = actual;
        }

        @Override
        public void onSubscribe(Subscription s) {
            if (SubscriptionHelper.validate(this.s, s)) {
                this.s = s;
                actual.onSubscribe(this);
            }
        }

        @Override
        public void onNext(T t) {
            System.out.println(t); // ここがplintlnオペレータのやりたいこと
            actual.onNext(t);
        }

        @Override
        public void onError(Throwable t) {
            actual.onError(t);
        }

        @Override
        public void onComplete() {
            actual.onComplete();
        }

        @Override
        public void request(long n) {
            s.request(n);
        }

        @Override
        public void cancel() {
            s.cancel();
        }
    }
}

imoオペレータといくつか違う点があります。

AbstractFlowableWithUpstream は上流のFlowableを扱うための抽象クラスです。

https://github.com/adarapata/RxJava/blob/a00ea07a4d2ce409e8dbea66ddbca9c0a77ddab6/src/main/java/io/reactivex/internal/operators/flowable/AbstractFlowableWithUpstream.java#L29

HasUpstreamPublisher インタフェースを持つことで、自分より上流にPublisherがいることを保証しています。

この実装により、一個前のFlowableを保持させて、メソッドチェーンでオペレータを繋げられるようになっています。 FlowableImoはファクトリメソッドのため上流がありませんでしたが、printlnオペレータは必ず上流が存在するので継承が必要です。

また、インナークラスとして PrintlnSubscriber が存在しています。 このSubscriberがオペレータのコアの機能で、onNextでデータを送るときにごにょごにょする部分です。

今回はonNextでprintlnして、データには変更を加えずそのまま流しています。

あとはファクトリメソッドと同じようにFlowableにメソッドを定義します。

public abstract class Flowable<T> implements Publisher<T> {

~~~~~~~~~~~~~~~~~~~

    @CheckReturnValue
    @BackpressureSupport(BackpressureKind.FULL)
    @SchedulerSupport(SchedulerSupport.NONE)
    public final Flowable<T> println() {
        return RxJavaPlugins.onAssembly(new FlowablePrintln<T>(this));
    }
}

以上で、自作オペレータが実装できるようになりました。

Flowable.imo().println().subscribe();
// => imo とログが吐かれるだけ

できあがりはこちらです

見やすいようにPRにしてみました

github.com

所感

かなり端折りましたが、オペレータがどんな挙動をしているのかはざっくりわかりました。

ただ、SubscriberがSubscriberとSubscriptionの両方の役割を担っているので、そこのコードを追うのがめちゃめちゃ大変でした。 この辺りは別のタイミングで書こうかと思います。

昔作ったゲームを公開した

外付けHDを漁っていたら、昔に作ったゲームが発掘されたので、せっかくだし公開しました。

https://otoshiai.e-f-b.jp/

東方落試合という4人対戦型アクションゲームです。 弾幕とかでワイワイしながら相手を倒しましょう。

2~4人用なので1人では遊べないのと、2010年製なのでそもそも動くかわかりません。

手元のWindows10だと動きました。.NETすごい。

テンション高い学生時代に作ったゲームで色々恥ずかしいところあるけど、多分作ってて一番楽しかったし知らない人から面白かったですと直接感想もらえたりと思い出深いやつなので永久保存しとこうと思います。

リファクタリングは、コードを5秒見たあたりで諦めました

出稼ぎダンジョン進捗報告 2

割と時間開けてしまった。

今回は見た目の変更はほぼなし。その代わり、急ピッチで作った部分を色々とリファクタリングなどしていた。

Zenjectの導入

戦闘システム周りなど、敵と味方が相互に依存しあったりして割とつらいコードになっていた。そのあたりのリソースの参照を一か所に集中させるためにシーンごとにDataStore的なクラスを用意してそこから参照するようにしていたが、毎度用意するのがやや面倒だった。

また、Storeがシングルトンという役割を持つので、シングルトンにしたいPureClassなどもここに追いやられていた。

namespace Game.Store
{
    /// <summary>
    /// Battleシーンのデータを全て保持しているやつ
    /// </summary>
    public class BattleStore
    {
        public BattlePartyView Party { get; private set; }
        public BattleEnemyView Enemy { get; private set; }
        public ActionResult InBattleResult { get; set; }
        public ActionDisplayView ActionDisplay { get; private set; }
        public View.MoneyView MoneyDisplay { get; private set; }
        public Model.Money Money { get; private set; }
        public void Initialize(){
            // それぞれfindしたりなど
            // PureClassはここで生成したりなど
            Money = new Money();
        }
    }

    public class Hoge {
        private BattleStore store;
        private Model.Money money;
        void Start(){
            var party = store.Party;
            money = store.Money;
            // ほげほげ
        }
    }
}

こういうのを用意して、全部Store経由で取ってたりした。 流石に将来的にしんどくなる気がしたので、ここにZenjectを導入して、データは極力直接injectする方針に変更した

github.com

namespace Game.DI
{
    public class BattleInstaller : MonoInstaller<BattleInstaller>
    {
        public override void InstallBindings()
        {            
            Container.Bind<Model.Money>().FromNew().AsSingle();
        }
    }
}

public class Hoge {
    [Inject]
    private BattlePartyView party;
    [Inject]
    private Model.Money money;
    void Start(){
        // ほげほげ
    }
}
  • Storeが不要になった
  • PureClassの生成はInstallerに移行できたので置き場所がわかりやすくなった

コード量がだいぶ減って見やすくなったのだった。 まだ使いこなせたとは言い難いけど、現状でも十分便利。

BehaviorDesignerを導入

敵キャラの行動パターンは、完全なランダムで技を繰り出すだけだったので細かい思考を調整できるようにしたかった。

なので、昔に買ったけど放置していたBehaviorDesignerを導入することにした。

https://www.assetstore.unity3d.com/jp/#!/content/15277

BehaviorTreeを作ること自体はじめてだったけど、その辺はググりながらでサッと解決した。

上記のTreeは以下の思考パターンになってる

  • HPが30%より大きかったら、「たいあたり」「れんぞくたいあたり」のどちらかを繰り出す
  • HPが30%以下だったら、「すごいいちげき」「あばれる」のどちらかを繰り出す

いわゆる、ピンチになると発狂する挙動だけど、これくらいなら数分で書けるので非常に便利。そして楽しい

自前の戦闘システムに組み込むため、攻撃を行うActionとHPをチェックするConditionalは自分で実装した。 この辺りは仕組みが簡単なので割と量産しやすそう。

今のところ敵キャラだけに実装してるけど、味方もBehavior Treeで動けるような仕組みにはするので、HPが低かったら回復とかいい感じに思考してくれるやつをこれから作る予定。

裏側はだいぶよくなったので、そろそろ見えるとこも直していこう・・。

出稼ぎダンジョン進捗報告 1

定期的に書いていけってばっちゃが言ってた

前回のお産合宿の時からの変更点としては以下

  • テンションシステム
  • テンションアップコマンド

テンションシステム

パーティは戦闘時にテンションが変化します。テンションは攻撃したり、ダメージを受けたり様々な要素で上下します。

テンションが最高潮に達するとハイテンションモードになり、一定時間パーティが強化され戦闘を優位に進めることができます。逆にテンションが最低になればローテンションモードになりパーティは弱体化、ピンチになっていきます。うまいことコントロールしていきましょう。

テンションアップコマンド

先のテンションゲージを一回で最高潮にさせる大技です。具体的にはパーティにお金を払います。それなりの出費はかかるのでここぞというときに使うと良いでしょう。

あとダンジョンを一新したり。

f:id:adarapata328:20170919231047p:plain

ダンジョンは現状Nostalgia2を使ってます。

https://assetstore.unity.com/packages/tools/sprite-management/auto-tile-available-nostalgia-2-70610

次やりたいこと

まだコアである収益計算部分ができてないので、そっちをやりたいところ。

ただ、そろそろコードの依存関係がしんどくなってきたので、Zenjectを入れてDIしたい。Findしているアレコレをこの世から抹消したい。

https://www.assetstore.unity3d.com/jp/#!/content/17758

普段開発するとき1画面でも結構シーン分割して、動的にシーンをマージして全部結合したらFind云々をよくやってるんだけどその辺もZenjectで解決できるだろうか。

skipLast, takeLastオペレータはデータを流すタイミングをずらす

ちょっと面白かったのでメモ。

例えば複数のSubscriberを並行して処理したいなと思った時に、autoConnectで流すタイミングを合わせたとする。

Observable<Integer> foo = Observable.just(3, 4, 5).publish().autoConnect(2);

foo.subscribe(data -> System.out.println("A:" + String.valueOf(data)));
foo.subscribe(data -> System.out.println("B:" + String.valueOf(data)));
A:3
B:3
A:4
B:4
A:5
B:5

もちろん順番に値が流れることになる。

この時にskipLastで片方だけ流す量を調整してみる。

Observable<Integer> foo = Observable.just(3, 4, 5).publish().autoConnect(2);

foo.subscribe(data -> System.out.println("A:" + String.valueOf(data)));
// 5だけskipされる
foo.skipLast(1).subscribe(data -> System.out.println("B:" + String.valueOf(data)));

するとこんな感じになる。

A:3
A:4
B:3
A:5
B:4

ABABAと最後のBが流れないのかと思いきや、AABABと一つ目のBがなくなってしまった。 なんでだろうと思ってソース読んだらかなりシンプルだった。

github.com

指定した数だけキューに溜めて、数を満たしたら順次OnNextに流していく実装になっている。 オペレータから見た時に、どのくらいの数のデータが流れてくるのかという情報はないので、先に指定分ずらしておくようだ。 なるほどという感じ。

ちなみにtakeLastもほぼ同じ感じ。

https://github.com/ReactiveX/RxJava/blob/d3455d0c9d57d522c31b5c25af83e8f2b8df12b6/src/main/java/io/reactivex/internal/operators/observable/ObservableTakeLast.java#L59-L64

普通に使っててこの仕様にひっかかることはなさそう。

お産合宿11でゲーム作った

ペパボでは毎年お産合宿という創り出す系の合宿イベントをやっています。 今年はSUZURANというチーム名で参加してきました。僕はイーグルです。 osan.pepabo.com

僕は今までアクションゲームばかりでRPGを作ったことが無かったので、やってみたいなという気持ちからスマホ向けRPGを作ることにしました。

体調は良くなかったです。

www.instagram.com

そしてできたプロトタイプがこちら。

www.instagram.com

出稼ぎダンジョンというRPGができました。 借金を背負った主人公が金で傭兵を雇ってダンジョンに潜ってお金を稼ぎ返済するRPGです。いかにコストを抑えて稼ぐかというのが肝になります。

バトルシステムはSFC時代のFFを踏襲したアクティブタイムゲージによるリアルタイムコマンド式です。一方で、味方の隊列は半熟英雄仕立てになっていて、先頭だけダメージをうける「ちょくれつ」か、全体でダメージを分散する「へいれつ」の二つの陣形を駆使して戦います。

割といい感じにできたのでデジゲー博に申し込みました。間に合うといいなあ。

デジゲー博 | 同人&インディーゲームオンリー展示・即売会

おまけ

今回MVPアーキテクチャを採用しており、View = MonobehaviourとしてPureClassとしてPresenter、Modelを作成して開発してみた。 しかしながら、ゲームにおけるビューの責務は結構大きく、あれもこれもビューじゃね?みたいなことになってしまい結果的にモデルがないビューも存在したりしてしまった。あとビュー同士の関連(敵が攻撃を通知したら味方に影響を与えたりとか)もめっちゃあるので、その都度モデルにロジック書いて・・とするのが正しかったかもしれないがそれはそれで面倒さが増してたなあと思う。

下記のブログに書かれている Viewを積極的に拡大解釈していく というのは非常に大事だなと思った

yutakaseda3216.hatenablog.com

あと、今回初めてRPG作ったけど今までと全然違ったのでどうやったらいいだろうみたいなのを苦労しまくった。 そのときに戦闘のフローをPlantUMLで書いたものが出てきたので、せっかくだし公開。

バトルシーン全体は開始 -> 戦闘ループ -> 終了 -> 結果という一方通行なので下記のような感じ

BattleFlow@1-13

その中で戦闘ループを展開するとこんな感じ。アクションを受け付ける状態、アクションを実行している状態、アクションの結果を反映させる状態

InBattle@1-11

Wait

Wait@1-10

受け付けるアクションをICommandableインタフェースで抽象化した様々なアクションをキューに入れる。基本一個でもキューがあるなら即時にActionに映る。

このキューはWait状態以外の時でも突っ込むことは可能で、その場合は積まれていき、Waitに戻った場合にまた先頭を取り出してActionに移る。

ちなみにこのキューはUniRxのReactiveCollectionを拡張して作った。

Action

Action@1-8

再生するだけのアレ。ここは一方通行なので特に言うことはなく、Waitから送られてきたICommandableを実行するだけ。Animationだけ再生する予定が結局ICommandableががっつりロジック持ってたりするので失敗したっぽい。

Result

Reult@1-14

Actionの結果によってどうなったかというのを処理して、もし終了であるならInBattleのループから脱出する。

ゲームの良い設計、作ろうとしているものによって勝手が違い過ぎるので永遠の課題に思えてきた