2017-06-30

Appleの話〜AppleIdの作成手順〜

考察（技術）

前提として、どこかメールを受信できるメールアドレスを持っている事。
GMailでいいと思います。

1. サイトに飛ぶ

https://appleid.apple.com/account#!&page=create

f:id:mochimoffu:20170625141154p:plain

こんな感じのページが出ると思うので、必要な情報を入力する

2017-06-23

Luaの話～で、商用に使えるのどうなのよ？～

考察（技術） Lua

筆者は、まだLua歴半年なのであまり偉そうな事は言えないが、思った事をメモしておく。

まず、Luaを使う場合も2パターン存在すると思う。
・UnityC#側があくまでメインで、Luaを一部の計算式等だけに使う方法
・ゲームロジック全てをLua側に逃がす方法
上記2種だ。
後者の方が、所謂筆者が言っている「アプリ更新無しでゲームの振舞を変える実装方法」の方法だ。

前者は、商用にでもすぐに使える内容だと思う。
マスターデータ代わりにできるし、その辺りを全て計算した結果を取得する事だって可能になる。

後者は、正直言ってすでにUnityの開発ノウハウを溜めてきた企業に新しく導入するというほどの価値はないのではないかと思う。
まず、間違いなく一人、Unity側とLua側の橋渡しをする部分の設計をし、Lua側の記述方法のルールを決める人が必要になる。
開発メンバーは、そのルールに則り、メジャーとは言い難く、Utility関数にも乏しい「Lua」という言語を1から勉強し、開発に臨むことになる。

Unityを導入することに決めて、そこからノウハウを蓄積していった軌跡を、今度はLuaで同じことをすることになるのだ。

Unityの場合は、今はもう日本語のドキュメントや情報がたくさん出ているし、そもそも C#はかなり親切な言語なので、調べながらでも何とか開発できたと思うが、それがLuaで同じ事が出来るかと言われると、正直どうなんだろうかと思う。

かといって、これから新規でUnity開発を始める企業にも、似たような理由でお勧めしない。
仮にLuaでの開発のノウハウが蓄積できたとして、企業規模を拡大しようとしても、Luaが出来るエンジニアなんてものは早々いるとは思えないし、需要も供給も少ないと思う。

結局の所、開発メンバーも資金も豊富で、技術開発という名目が行える企業なら、試してみてもいいんじゃないのかなという感想。

Luaがもう少しメジャーになって情報が出ない限りは、主流にはなりえないんだろうな―。

と思いつつ、次のUnity開発案件があったら、がっつりLua側に処理全部書いてやろうと思っている事は内緒。

その為に、自作アプリをアップル申請通して、実際にアプリ更新無しで内容変えられるかの実績を積もうと頑張っている。

がんばろ。

-----

2017/6/23現在、ひとまずApple申請は通ったので、使えそうではある。
その辺りの詳細は、また来週以降少しずつ情報を書いていく予定。

2017-06-16

仕事の話～人に問題を伝える～

考察（仕事その物）

※デザイナーさんをディスってるわけではないのであしからず
※ゲームアプリ開発の話だと思ってください

仕事をしていると、たまにこういう事がある

-----
デザイナーAさん「この画像データ、ジャギが酷くて問題あるんですよ」

筆者「はぁ」
-----

筆者は、「画像がジャギってるからって、何の問題があるの？」といつも思う。
これは極端な例だが、今回はこのようなやり取りから得られる物を見ていく。

まず、ここで言う「問題」とはなんなのだろうか。
問いかけに対して答えが欲しいわけではないだろう。

仕事上で問題問題と言われるの物を定義すると

・その事柄を解決しないことによって、将来的に不利益・不利・マイナス・悪い事が起こる

としておくのが良さそうだ。
つまり、あまりみんなが幸せになれない事が起こるというのを問題があるというのだろう。

とすると、上記の例は以下のように置き換えられる

-----
デザイナーAさん「この画像データ、ジャギが酷くて「将来的に悪いことが起きる」んですよ」

筆者「はぁ」
-----

なるほど、どうやらAさんは、画像のジャギを直さないと、将来みんなが不幸になると思っているようだ。
だが、ここまで来ても、筆者としては

筆者「で、なんでそれがみんなの不幸になるの？」

となってしまう。

理由は簡単。筆者はその分野の専門ではないからだ。
その領域に対しての「知識」が無い。「知識」が無いために、「問題」を「認識」も「理解」もできない。
理解できない物を問題と捉えるのは、思考停止状態でもなければとても難しい。

更に、上記の例はもっと根本的な問題がある。
Aさんが思っている問題の理由が、適切ではない可能性が高い。

もし仮に、Aさんが思っている問題が
「ジャギが酷くて、とてもじゃないが絵のクオリティが低いから問題だ」
とする。

なるほど、確かに理由としては真っ当である。
だが、個人的にはこれは根本的な理由ではないと思う。

一番の問題は
「ジャギが酷過ぎて、絵のクオリティが低く見えるので、商品のクオリティが下がって、収益に影響が出る」
から、問題なのである。

ここから得られる教訓と、明日から使える手法にまとめるとすると

1. 問題は、その領域の「知識」が無い人には、理解も認識もされない
2．問題の理由が、根本的な物を指していない可能性がある

1に関しては、問題提起する側は、それを聞かせる人の知識を汲み取って、その人が理解できる言葉で話すことを心掛ける事。
特に、分野が違う人に問題を話に行った時に、どうもピンと来ていない様子だったら、間違いなく問題を理解してもらえていないので、言葉を変える必要がある。
上記の例で言えば

-----
デザイナーAさん「この画像データ、輪郭がギザギザして見栄えが悪いんですよね」
-----

くらいになれば、とりあえず見た目を気にしているという事は伝わる。

-----雑談
ちょっと、話が逸れるが、上記のように知識が無い人に伝える言葉で話す事を
「レベルが低すぎてやってられない」と、否定的な人がいるが、
筆者はこれはあまりよろしくないと思う。

気持ちはわかるが、チームで作業する以上、最終目標が「商品のリリース」なのだとしたら、
その様な個人的な感情はチーム作業には必要ないので、例えレベルが低くても
作業が一番効率よくでき、成果が出るような方法を取るのが一番だと思っている。
-----雑談終わり

2に関しては、その問題が引き起こす根本的な不利益を探るというのは、癖にしておいた方がいいという事だ。
問題の根底にあるものが見えないと、解決策が正しい物ではない可能性が出てきてしまう。

例えば、上記の例で、デザイナーAさんのジャギが気になるという事に対して、
ひとまず時間をかけて直したとする。
しかし、そのせいで描画負荷が上がりゲームの動作が重くなったとしたら
根本の解決すべき問題である

「商品のクオリティが下がって収益が下がる」

が、結局解決されていないのである。

もしかしたら、その商品に責任を持つ人が、そのジャギ自体を全く気にしていない可能性だってある。
これは、プログラムのバグ修正などにも同じ事が言える。
表面に見える物だけ見て、それだけの修正を重ねていくと、
本来解決すべき問題が何も解決されずに、作業量だけが増えるといった事態になる。

なので、何かしら問題が発生したら、「それが引き起こしている一番の問題はなんなのか」というのを良く考えるようにした方がいい。
それが出来て、妥協案なども出せるようになる。

ここまでした話は、大半の人は、1，2のステップを経験則などで無意識に思考して行っていると思うが、
たまにチーム作業という事を忘れて、上記のようなコミュニケーションを取ろうとする人が居るので、
ドキッとした人は、是非明日から初心に返って業務に取り組んで欲しい。

ゼネラリストになるだとか、チームの潤滑油になるだとかいう人は（ｒｙ

2017-06-13

仕事の話～「何でもいいです」の無責任～

考察（仕事その物）

これは筆者の個人的考えであり、考え方は人それぞれ持っているというのは理解している前提を記載しておく。

表題だが、何の事を言っているかというと、そのまんまの意味だ。
ぶっちゃけ、ただの気遣いレベルの話でしかないが、こういう細かい所で効率が上がったりミスが減ったりするから、覚えておいて損はないと思う。

ちなみに、ここでする話は、仕事で発生する「何でもいい」に対しての話であり、プライベートではないのであしからず。

仕事に限らず、こういう経験はないだろうか。
こちらが何かを相談を持ちかけたことに対して

「何でもいいよ」

という回答に困ったことだ。

筆者も全く使っていないわけではないが、この「何でもいい」という回答は安易にすべきではないと思っている。

「何でもいい」とは、質問した側の人間を思って、良かれと思って言っている人が多いと思うが、それは間違いである。

理由としては、やり取りの中で「結論の確定」がなされないからだ。

そもそもとして、質問者側の視点に立つと、相談する内容を予め揉んだ上で、その内容を踏まえて「相談」を持ちかけている。それに対しての「何でもいい」という回答は、その相談を拒否・放棄していることと同じである。

例1）

A：ここの実装、１と２の設計考えたんだけど、どっちがいいと思う？

B：何でもいいんじゃない？

例2）

A：仮データのモデル、何がいいですか？

B：何でもいいです

1に関しては、文面だけでコミュニケーションが破綻しているのがわかるし、何も確定しない
2に関しては、質問者の質問もよくないが、やはり何も確定しない

確定しない事の何が問題かというと、その後に「で、結局どうするの？」というのが間違いなく発生する。つまり、確定をあと延ばしにして忘れ去られる可能性を増やしているだけなのである。

これの解決策は簡単だ。「何でもいい」のであれば、その「何でもいい」中から一つ指定をすることだ。

上記の例2に関しては、問いかける側の問いの問題もあるとは思う。「何がいい？」ではなく「どれがいい？」と選択肢を予め絞るべきだ。それに対しても「何でもいい」と答える輩は、もはや論外だ。

この手の「何がいい」「何でもいい」は、仲が良かったりお互いの事を良く知っている間柄であれば通用するかもしれないが、仕事をする上でそれを前提で頼るのはよろしくない。
何でもいいと言った物は、何でもよくない事の方が多いので、後々トラブルの原因になる。故に、潰せるのであれば潰すべき。

ゼネラリストになるだとか、チームの潤滑油になるだとか言う人は、この「何でもいい」という回答に関して、上記のような事を感じられるといいのではなかろうか。

2017-06-09

Luaの話～LuaStateを作ると、どの程度メモリを消費するのか1～

考察（技術） Lua

▼検証コードメモ
   void Start () {
       Application.targetFrameRate = 60;

       StartDebugLog += "↓↓↓↓↓start↓↓↓↓↓\n\n";

       uint monoSize = Profiler.GetMonoHeapSize();
       uint monoUsed = Profiler.GetMonoUsedSize();
       uint tempSize = Profiler.GetTempAllocatorSize();
       uint totalUsed = Profiler.GetTotalAllocatedMemory();
       uint totalSize = Profiler.GetTotalReservedMemory();

       StartDebugLog += string.Format("mono:{0}/{1}kb\ntotal:{2}/{3}kb\ntemp:{4}kb\n\n", monoUsed/1024, monoSize/1024, totalUsed/1024, totalSize/1024, tempSize/1024);
       StartDebugLog += "↑↑↑↑↑start↑↑↑↑↑\n\n";

       StartCoroutine(CoroutineStart());
   }

   private IEnumerator CoroutineStart() {
       GameSceneManager.Instance.Initialize();
       GameObjectCacheManager.Instance.Initialize();
       AssetBundleManager.Instance.Initialize();
       ResourceManager.Instance.Init();
       RijindaelManager.Instance.Init();
       VersionFileManager.Instance.Initialize();

       yield return null;
       yield return StartCoroutine(LuaInit());
       yield return null;

       ClickDebugLog = "↓↓↓↓↓click↓↓↓↓↓\n\n";

       uint monoSize = Profiler.GetMonoHeapSize();
       uint monoUsed = Profiler.GetMonoUsedSize();
       uint tempSize = Profiler.GetTempAllocatorSize();
       uint totalUsed = Profiler.GetTotalAllocatedMemory();
       uint totalSize = Profiler.GetTotalReservedMemory();

       ClickDebugLog += string.Format("mono:{0}/{1}kb\ntotal:{2}/{3}kb\ntemp:{4}kb\n\n", monoUsed/1024, monoSize/1024, totalUsed/1024, totalSize/1024, tempSize/1024);
       ClickDebugLog += "↑↑↑↑↑click↑↑↑↑↑\n\n";
       OutputText.text = StartDebugLog + ClickDebugLog;
//       yield return null;
   }

▼UnityEditor上（ターゲットはAndroid）
〇LuaState作成をする
mono:4940/20852kb
total:48811/205184kb
temp:16384kb

↓

mono:5312/20852kb
total:49065/205184kb
temp:16384kb

〇LuaState作成をしない
mono:4944/20852kb
total:49083/205184kb
temp:16384kb

↓

mono:5028/20852kb
total:49323/205184kb
temp:16384kb

約300kbくらい？

▼Android実機
〇LuaState作成をする
mono:0/0kb
total:5748/8823kb
temp:1024kb

↓

mono:0/0kb
total:5844/9249kb
temp:1024kb

〇LuaState作成をしない
mono:0/0kb
total:5751/8828kb
temp:1024kb

↓

mono:0/0kb
total:5843/8991kb
temp:1024kb

ほぼ変わり無し…？