いまきたこうぎょう。

のんびり、ゆったりとスマホゲームを作ったり作らされたり。

うわー。停電で機械とまったー。
なのでブログ書きます。

◆条件分岐で呼び出す関数を分岐させよう!

なんかこう、処理を分けたいってありますよね。
ゲームでいうと、「剣のときはこう、斧のときは、槍のときは…」みたいな。
っていうと普通は

void Bunki(int BUKI_ID){
switch(BUKI_ID){
Case 0:
KEN();
Break;
Case 1:
ONO();
Break;
Case 2:
YARI();
Break;
}
}
みたいな。
コード縦に広がるし、5個程度ならいいけど種類が10個20個30個って増えるともう書くのがめんどくさくて死にたくなります。もうほんとめんどくさいです。
いまスキルで処理分けるところ作ってて、ほんともうやーめたって言いたくなりました。


んで、ツイッターなら天才がわんさかいるので








って投げてみたんですよね。
もうほんと天才お願いしますって丸投げ。





普通はそうですよね。
もう諦めてゴリゴリ書こうかって思ってた矢先、やはり神がいた…!









関数ポインタ…だと?
専門学校時代にCで投げたポインタ…うーんめんどくさそうだな…
と思ったけど、いちおうググってみた。
やっぱりポインタだとめんどくさそう…

という中に、ひとつの記事が。

[C#]関数を配列でまとめたい


うん。そう。これ。これがやりたい。
渡すIDを配列のインデックスにできればもう最高。めんどくさくない。

その中の記事からたどりついた、


これ!これだよ!これがさいつよなんだよ!


というわけでデリゲートから配列を作って(っていう言い方であってるの?)、その中に関数をぶち込む。そんで配列から関数を呼び出す!


using System;
public delegate void iFunction();
public struct iArray{
public iFunction iFun;
}

void Awake(){
iArray[] = new iArray[3];
iArray[0].iFun = KEN;
iArray[1].iFun = ONO;
iArray[2].iFun = YARI;
}

void Bunki(int BUKI_ID){
iArray[BUKI_ID].iFUN;
}

こんな感じになりました。ちなみに引数も渡せます。
ただし、引数は配列に入れる関数すべてで引数の型が統一されている必要があります。たしか。

switchだと縦長になって可読性悪くなるし修正するのくsssssssssっそめんどくさいし書くのくsssssssssっそめんどくさいので、私的にこれがさいつよだと思います。



が、



ってことですよねぇ…
なんかバグでて「なんだこれ書いたの誰だ出てこい」ってなってもヤですしね。

なにかのお役に立てたら、という備忘録でした。

ではまた。

暑いですね。暑いっていうと余計に暑くなるので暑いっていったらダメですよ。
こんにちは。8月終わるくらいまでアプリ作る気力なんてないんじゃないかなっていうくらいの感じの私です。

◆中国語版だよー


っていう前に、かつて


こんな記事がありました。
今は亡き(失礼)TOMEさんも、ポケガの件も他人事ではないので読んだ覚えがありました。

扑家吧(pujia8)」というところです。

そんなこともあるんだなー、大変だなー。と他人事でした。
どっちだよっていう話は置いといて。
この記事が2015年のおはなし。

そして時は流れて2019年。
さっきの記事のことをすっかり忘れ、サイコロ勇者をリリースしてから、リアルが大変なことになってる私のもとにTwitterでダイレクトメールが。

「中国語版出しません?」
はい、さっきのpujia8さんからでした。

おや?と思い、思わず検索…
出てくる出てくる。いろんな記事。
正直なところ、「うわこれヤバいやつや」と思いましたよ。

そんな中、ひとつの記事が目につきました。



っていうか、まっさきに目につくところに出てきますね。
前述のポケガの記事、プリンキピアの件では「著作権?なにそれおいしいの?」っていう感じだったpujia8さんですが、どうやら真っ当に生まれ変わったらしいです。

話を聞いてみる価値はあるかな、と思い、返信をしました。
非常に丁寧に話を聞いていただき、こちらのリスク(バグ、金銭的負担など)についても丁寧に教えてくれました。

細かいところは前述の記事を読んでいただければ、理解していただけると思います。

とりあえず、こんな感じ。

こちらがやらなくていいこと
・プロジェクトを渡したら、それを翻訳してくれる
・広告はあちらのADNWのSDKに差し替えてくれる
・ストアの準備、公開作業をしてくれる

こちらがやること
・プロジェクト一式を渡す


他に気を付けること
・バナー広告は削除。(あちらでは単価が激安で、バナーを出すという行為が画面占有のリスクしかないみたい
・課金は不可
・バグなんかの修正はこちらで(その都度、プロジェクトを送信してあちらでビルド、リリースしてもらう

お金な面
・翻訳などにかかる費用はゼロ
・そのかわり、収入の〇%をレベニューシェア
・一定に金額になったら振込


正直、こちらにとってはノーリスクです悪くとってもローリスク。私のアプリの場合、あちらにリスクしかないのでは?という感じがしないでもないですが…
日本の業者で「幾ばくか」っていうメールとは大違いです。
そこらへんのお話を聞いたところ、

「現在の我々は、いろんなアプリを広めたい、その思いでやってます。儲けがいらないわけじゃないけど、日本のインディーデベロッパを応援したい、日本のインディーアプリを我々の国に広めたい、という気持ちでやっている」
とのことでした。
作業量的にも、レベニューのパーセントはわりと納得できるところです。


美味い話には…という不安と、へっぽこな私のソースファイルをぜんぶ渡すという行為に若干不安を覚えましたが、「面白そうなことはどんどんやろう」がモットーの私。話に乗ることにしました。

契約書を取り交わし、プロジェクトを渡して、あとは待つだけ。

というわけで、7/30にiOS,Android両方でリリースされたという連絡あり。
まあ正直、どれだけDLされるかどの程度受け入れられるかという点についてはそれほど期待していないというのが本音です。

まだ出たばかりなのでどれだけDLされたのかというのもいまいちわかりません。
そのへんは、また続報があれば出したいと思っています。


ちょっと調べてみると、まだやっぱり「勝手に翻訳して自分のものとしてリリースする」というところもありますし、プジャさんと話を進めている最中に「ウチで翻訳しない?」っていう業者さんもいたり、あちらは現在のところカオスになっているようです。
ただ、かつてと比べて「そういう意識をもった人が出てきたんだな」というのが嬉しいところじゃないでしょうか。


いつになるかわかりませんが、今つくってる新作もお願いするかもしれませんね。
それでは。

皆さんこんにちは。
お元気でしょうか。私はサイコロ勇者をリリースしてから、リアルが大変なことになって、毎日が抜け殻です。Death。はい。
ぜんため行けません。


今回は久しぶりのUnityの備忘録。

皆さん、AddressableAssetは使っていますか?
PrefabとAssetBundleのいいとこどり…らしいのですが、Resources.Load至上主義の私としてはちょっととっつきにくい感じでいままで敬遠してました。AssetBundleとかもう宇宙の彼方の話。
まだPreview版なので、正式リリース待ちなところはあるのですが。

いま、新作にとりかかっているのですが、かなりリソースの量が膨大になって、Resources.Loadだとちょっと辛い&ファイルサイズがデカくなりそうなので、この際だからちょっと外部サーバーに出して、よくある初回起動時にダウンロードして、っていうのをやってみようかなと思い立ち、AddressableAssetを少し勉強してみました。

AddressableAssetについてはいつものKan様が丁寧に書いてくれているので、導入に関してはこちらを参照してもらったほうが絶対に良いです。




で、ちょっと触ってみた結果、




Resources.Loadのほうがぜんぜん楽やん! 手軽とか嘘やろコレ! 嘘つき!




ってなりました。まじで。99割自分がアホだから。なので、いったん諦めました。でも私はアホなので、再度チャレンジすることにしました。
とりあえずやりたいことは、

1.画像をAssetから読み込みたい
2.画像を一括で配列に保存して、動的に表示を切り替えたり横に並べたりしたい


というわけです。
で、なんとなくできたっぽいのでメモがてらに残すことにしました。
他の人に役立つかどうかは知りません。

あ、前のKanさんのブログだとAddressableAssetのバージョンは0.0.22ですが、この記事を書いた時点では0.5.3Previewになっています。そのおかげで若干、使い勝手が違っていますがKanさんに文句を言ったらダメです。

◆前準備をしようぜ

33
というわけで、画像の前準備です。
いつものごとく、フォルダを作って画像をぽいぽい。
画像は臼井の会様より拝借いたしました。いつもありがとうございます。
まあ、AddressableAssetを使う人なら常識でしょうが、「Resources」フォルダに入っていませんね。


で、これをAddressableAssetのところにぽいぽい。

37


で、ラベルをぺたぺた。

ここで、ラベルを「Sprite1」と「Sprite2」にわけました。

さて、ここでハマったポイント。

「新しいラベル登録するところがねえじゃねぇか!」

前述のブログでは、ラベル「default」の下に「new」で新しいラベルを登録することができましたが、0.5.3になったらその項目がありません。新しいラベルを登録することができません。

いろいろ探してみたら、こんなところにありました。

34


AddressableAssetSettingsの中に。
若干、新作で使ってるラベルが入っちゃってるのでそこはモザイクで。
無事にSprite1とSprite2のラベルを作ることができました。

◆AddressableAssetからアセットをとってこよう!


さて、それじゃあ本題。
CanvasにImageを作って…

32

仮の画像をぺたり。
で、ソースです。


using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEngine.AddressableAssets;
using UnityEngine.UI;
public class char_skin_test : MonoBehaviour {
public AssetLabelReference texture = null;

// Use this for initialization
IEnumerator Start () {
List<Sprite> sprites = null;

//AssetLabelReferenceのラベル名を指定
string texString = "Sprite2";
texture.labelString = texString;

//opにラベル名でAssets読み込み
//opはIListで帰ってくる
var op = Addressables.LoadAssets<Sprite>(texture.labelString, null);

//非同期なのでopがCompleteするまで待つ
yield return op;
//op.Resultをspritesに入れる
sprites = new List<Sprite>(op.Result);

Debug.Log("sprites:" + sprites.Count);

this.GetComponent<Image>().sprite = sprites[1];

}

}


using UnityEngine.AddressableAssets;
これを忘れないように。

AssetLabelReference
これがラベル指定で読み込みをするときに大事。
ラベル指定しないでAsset名で直指定するときは
AssetReference
を使います。使い分け大事。

今回は「Sprite2」のラベルを付けた画像だけを配列に入れました。
texture.labelString これがラベルの本体です。

var op = Addressables.LoadAssets<Sprite>(texture.labelString, null);
これでopに指定したラベルの画像が一括で入ります。
opはIListなので、このままではいつものように使えないです。
なのでIListの中身を改めてListにぶっこみました。

注意点として、LoadAsset及びLoadAssetsは非同期でのロードになります。
よって、Startで実行するとしても、IEnumeratorでyield returnで完了待ちする必要があるってことです。
実機でどれだけの待ちが発生するかはまだちょっとやってないですけど。

さて、これで実行してみます。

35

無事、spritesの中に2個のスプライトが入ってくれました。

36

実行画面も、ちゃんとsprites[1]の画像を表示してくれました。


画像が1個だけの場合、
LoadAssets
これを
LoadAsset
にすればいいわけですが、同じラベルの複数のアセットがある場合、たぶん最初に見つけたやつを持ってくるのでしょうね。
そんなときはラベル指定せず、AssetRefarence使おうぜっていうことなのかな。まだよくわかってませんが。

まあ、とりあえずこれで「複数の同じラベルを付けた画像を一括でロードして、動的に画像を変更する」という当初の目的は果たせました。これであの作業が捗る。

今後、サーバにファイルをアップするだとかめんどくさい作業があったりしますが、それはおいおい。

まあ…あれですね。Resources.Loadよりちょっとめんどくさいですが、AssetBundle使うよりは圧倒的に楽。小さいアプリならResources.Load一択。Prefabの数が多くなったり、Resources.Loadを大量に回したりするならAddressableAssetを使う。そんな感じを受けました。(※個人の感想です)

とにかく今は「管理が面倒」っていうに尽きますわ。
フォルダ分けして管理できるようになれば最高なんですがねぇ。

とりあえず小ネタな感じですが、今回はこのへんで。


次回はサイコロ勇者がアレしたりコレしたりするお話とか、新作のお話とか…
いつになるかはわかりませんが。

ではまた。

↑このページのトップヘ