imog

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

WEB漫画「魔法使い」が完結するまで死ねない

このエントリは2018年オススメのマンガ Advent Calendar 2018の参加エントリです。前職の同僚である@june29さんのエントリがTLに流れてきたので速・登録しました。

好きなアニメは今期もガルパンが完全勝利しているんですが漫画は割と色々読んでいるので甲乙つけがたいのが実際のところです。ということで、今回は僕が長年読み続けているWEB漫画「魔法使い~Wizard~」を紹介します。結構なネタバレにはなりますが、問題ない方だけ先に進んでください。

今すぐ読むぞ!という方は下記のリンクからどうぞよろしくお願いします。

manabanai.opinet.jp

知ったきっかけ

僕がこの漫画と出会ったのは実は8年前で、学生時代WEB漫画漁りがマイブームだったときに偶然目についたのが始まりでした。その時に全部読み終わって感動していたものの、ブックマークもしておらずタイトルも覚えておらず、「何か面白いWEB漫画あった」というおぼろげな記憶しか残っていない状態でした。

しかし今年三月に何の拍子か再開してしまったのです。

どういう経緯で見つけたのかは覚えてないのですが、僕は8年分の更新を読み終えて再びファンとなったのでした。

概要

「魔法使い~Wizard~」はマナバナイ先生が2006年からWEBで連載しているバトル漫画です。2018年12月時点で全38話、現在も連載中です。

常人より遥かに高い身体能力を持つ人間「魔法使い(ウィザード)」が現れ始めた荒廃した近未来、村同士の資源の取り合いは魔法使いによる代理戦争で行われていた。名無しの村の魔法使い黒子は自分の村を守るために戦う・・というのが基本的なストーリーです。現在三章まで続いており、村を襲う様々な魔法使いと戦う第一章、正式な魔法使いとなるため都会へ向かう第二章、日本にクーデターを起こしたシャングリラ公国と戦う第三章(現在進行中)となっています。

好きなところ

魔法使いという設定

名前こそ魔法使いですが、火とか水とか好きに出せるわけとかではなく単純に超人のような動きをする人たちなので、バトルは基本的に殴り合いです。その中でもスピード特化、パワー特化などキャラクタごとに個性を活かした戦い方をしてきます。魔法使い同士の戦いは生死を賭けたデッドオアアライブなものではなく、魔法使い法によってルールが定められた異種格闘技に近いものなので技の応酬が激しく、空手、プロレス、八極拳など王道のバトルものとして読んでいて熱いです。それぞれキャラが立ってます。

個人的にはそれに加えて「魔法使いという超人の人権を守るための法律」である魔法使い法の設定が好きです。畏怖の対象とされたり、軍事利用されたりと人間を超えた故に人間に扱われないという問題への解決策としてなるほどと納得感が高かったです。これはこれで問題があるのですが、設定としてスッと入ってきました。

シャングリラ公国の魔法使いたち

三章で現れるシャングリラ公国の魔法使いたちは全体的にキャラが立ってて好きです。めっちゃ好きです。この手の敵陣営って基本主人公側より強いようなやつらが多くて、そんな敵にどう工夫して立ち向かうかみたいなところが物語の肝だと思うんですけど、魔法使いたちは各能力が数値化されていて、数値上で見るとシャングリラ勢は主人公側より弱いということも結構あります。実際クーデターなのでそんな大きな戦力を持つわけでもなく、本編でサラが言っているように魔法使いの大半は日本国が管理しているため質や量で圧倒的な差なんですよね。だけど強い。主人公勢はかなりの苦戦を強いられるバトルが多いです。敢えて国のトップ(普通の人間)を狙うことで前線の戦力を削いだり、自分の土俵に誘い込んで能力差を埋めたりなど敵の方がかなり賢く動き回ってます。なんなら愛の力で覚醒したりとどっちが主人公かわからないレベルです。シャングリラ公国のキャラクタは何かしらの信念を持っていたりと悪役ではなかったりするのもポイントかもしれません。

好きなシーン

全編好きだけど二大好きなバトル書いて終わりにします。

オール アウト アタック (20~22話)

連合軍VSシャングリラ公国の軍隊の正面からのバトルです。シャングリラ公国の軍隊はノーマルだけですが火力と練度で幾度も魔法使いを退けた最強のノーマル部隊。連合軍の魔法使い達は敵味方、たった一人の死傷者も出さずに制圧していきます。

魔法使いたちの圧倒的な強さを伝える回です。ここで魔法使いとノーマルの差をこれでもかと見せつけてくれます。テラフォのM.O回しかり村田版ワンパンマンの怪人協会アジト突入回しかり、登場人物の多いバトルものに必ず差し込まれる王道ですが、最高に気持ちいいから王道なんです。特に最後のアインは本編で一番かっこいいんじゃないでしょうか。

ファイヤーウォール (30~34話)

シャングリラ公国の本能寺真理&ユーリ・カーヴェ VS マリー&バッドのプロレスタッグマッチ回です。真理&ユーリは元々タッグ「ファイヤーウォール」で村を守っていた夫婦で数十年ぶりの再結成。基礎能力ではマリー&バッドに少し劣るがそれを補う圧倒的な技で二人を苦しめる・・といった流れ。

このバトルは本当に熱いから何回も見てほしい。この回の主役は間違いなくファイヤーウォールの二人だと思う。

最後に

WEB漫画は気長に自由にやれるのがいいところですが、それもモチベーションが続く限りの話です。僕らファンのできることは楽しみにしていることをこうやってアピールするのみです。

長生きするので完結まで描き切ってくれ!!!

manabanai.opinet.jp

上期ふりかえり

なんでこの時期に上期ふりかえりかというと、会社の上期が9月までなので。10月は面談とか自己評価とか諸々を行ったりそれの結果が出たり、人の出入りがあったりと転換としてちょうどよく、せっかくなのでやったことをふりかえることにした。

開発環境の整備

整備って言うと広いけど大きく書くと次の三つ。

長く生きられるように基盤を整えて行きましょうということでアーキテクチャを導入しテスト書ける状態にした。その際にZenjectを導入してstaticなオブジェクトを減らしてテストを書きやすくしたりなど。まだ半年くらいしか経ってないので効果絶大だったかはわからないけど、少なくともUnityやライブラリのバージョンアップ時とか新機能追加時にとりあえずテスト通ってるから大丈夫やろくらいの安心感は与えてくれたのでプラスなんじゃないかとは思う。

その辺りのやったことは書ける範囲でブログにしたり登壇したり本に書いたりなどしたので興味ある方はご一読ください。

speakerdeck.com

adarapata.hatenablog.com

career.xflag.com

前職でこういう活動していたわけではなく、そんなに設計に精通しているというほどでもないので大変だったけど、チームの人もすぐに馴染んでいったので凄くやり易かった。というかチームの人たちテストとかDIとかアーキテクチャもほとんどやったことないと言っていたのに、あまりサポートすることなく全員普通に書いてたので「ヤバい人たちだ・・」ってなった。 特に設計周りは割と実装しながらこのレイヤがいるかという議論もできたので納得しながら進められた気がする。例を挙げるとTranslater層を設けるかというのは結構議論した。結局Zenject Factoryが担ってるよねということでやめた。

ちなみに設計周りは最近だとこれを読んでいる。とあるアーキテクチャに言及というよりはもっと根幹の五大原則とかに触れていて、且つ読みやすいので便利。

www.amazon.co.jp

開発チームのサポート

ここで言うサポートは、開発をしやすくするための支援とかそっちに近い。止まっていたふりかえりを再開したりとか、カンバン復活したりとかプランニングポーカーやったりとか結果的にスクラムのサポートだった気がする。一応チームリーダーだったのだけど、個人的な裏目標として「人のタスクを管理しない」を立てていた。エンジニア全体の進捗どうですか的なのをリーダーに振られるとそれを把握するための作業が必要だし僕がボトルネックになるしなによりしんどさが高まるので自分に聞かなくてもわかる状態にしたかった。なのでカンバン立ててやってること一覧を見れるようにした。あと、タスクも極力これお願いという渡し方を避けて自分で選んでもらうなどしてた。結果的に決まらずこちらで決めるはあった気がしないでもない。

よかったこととしては、TRYの実行率が上がっていったというのがある。回数を重ねるごとに抽象的なTRYから具体的に実行できるレベルまでの落とし込みができるようになっていたと思う。

これまた今までやったことない活動だったけど、前職でやってた人たちの活動を思い出しながらやってるといい感じになった気がする。あと、エンジニアリング組織論への招待はやはり名著なのでチームで仕事をする全ての人に読んでほしい。

gihyo.jp

課題としては、これらの活動をエンジニア以外にあまり伝搬させられなかったので下期に頑張りたいなというお気持ち。

登壇とかアウトプットなど

今期は結構文章を書くことが多かった気がする。 上記のXFLAG Tech Noteや、UNIBOOK10など。

unity-bu.booth.pm

上期前半は登壇用のスライドを書いたり本を書いたりなどをしていて、上期後半は久々にハッカソンクソゲーを作るなどしていた。

adarapata.hatenablog.com

www.instagram.com

平沢進聖飢魔Ⅱが対戦したり、「卍」をバトルさせたりと、ハッカソンは作ったものに責任を持たなくてよいので非常に楽しい。

あと、自分のアウトプットだけでなく会社の人たちのアウトプットを増やすという活動にもいくらかお手伝いしたりしていた。勉強会を開いたり誘致したりしてイベントと会社の人たちの距離を縮めたり、何人か外部の勉強会で発表してもらったりなど。自分自身も社内LTなどは頻繁に参加していたりする。

adarapata.hatenablog.com

Unityからジョジョまで質も内容もバラバラだけど、実は半分近く喋ってることに気づいた。

課題

弊社のエンジニアは基本的にマッシブな人々が多く、それこそコンシューマ時代からガシガシやってた人もいたりして非常に強い。低レイヤーからUnityの最新までイケる感じの人が多く、完全に理解したとは口が裂けても言えなかったりする。そんなわけで開発の基礎体力がだいぶ違うなと感じた。こういう風に実装したら行けそうという発想が早く、実装も早い。経験もあるけどそれより多分知識量だなと思う。

ということで開発リーダーから簡単な数学本を借りて今読んでる。

Amazon CAPTCHA

設計する力もチームを進める力も実装する力も別軸なんだけど、今の自分は実装する力で度々苦戦しているので下期はこの辺重点的にやろうと思った。

ゲームも作り始めているんだけど、割と長いスパンになりそうなのでエターナらないように気を付けたいところ。

最後に

スマブラが楽しみです。

大八耐6をやってきました

もっと書きたいのだけど疲労と日本語力が足りないのでサッと書く。

www.instagram.com

八耐とは?

福岡で月一で行われているなんでもありハッカソンイベントです。

http://daihachitai.npo-spice.com/about/

八時間でゲーム、CG、サウンド等好きなものを勝手に作ります。八時間ではありますが0からスタートである必要はなくやりかけのもの持ってきたりとかも全然オッケーのゆる~いハッカソンです。次の動画が空気感わかりやすいです。

www.youtube.com

本当になんでもありで、過去にいた例としてはデアゴスティーニの週刊3Dプリンタを全号持ってきてその場で開封して作ったりとか、8時間でモバゲーとかmixiとかメッセージ送りまくって彼女を作るとかいました。

元々は自分が学生の時に教授が研究室のメンバーに「8時間でクソゲー作ろうぜ!」と発起したのがきっかけで、研究室内での開催を経て外部公開して徐々に人数を増やしていき、福岡では7年くらいほぼ月一開催しています。

ハッカソンですがジャンルを問わないので様々な職種の人たちが集まるのが結構面白いです。

大八耐とは?

年に一回行われる、二日かけてやる八耐です。

http://daihachitai.npo-spice.com

やることは基本同じですが、二日かけてやるのと、審査員などを呼んだりオーディエンス賞を決めたりなどちょっと大きくなってるのが特徴です。でもゆるいのは変わりません。福岡では6回目、東京では2回目の開催となります。

www.youtube.com

今回は残念ながら福岡が台風で中止になったため東京のみの開催となりました。出来上がったものをいくつかピックアップします。

ラーメン二郎の写真だけを上げられるインスタ「二郎スタ」です。二郎以外上げるとアカウント止められるようにするらしい。 バックエンドがFirebaseなんだけど、検証で通信しすぎて本番時に無料分超過してデモできなかった悲しみを背負ったアプリです。

SNS連動型TCGの企画案を作った人もいました。絵を描いてる視点から欲しくなるカードゲームです実際の資料はもっとあります。

「無限に浮気できるライブチャット」という危険な名前のアプリですが、要はtiktokのようなライブ配信は一度に一つしか見れないので同時にいっぱい見ていっぱいいいねしたいという欲求を満たすアプリです。 ただ、複数の動画が同時再生されたそれは完全にパチンコ店の音でした。

こちらはアナログでコス衣装を作っていました。会場に自前のミシンを持ってくる徹底っぷりです。推しの服を作っているようで、感想を聞いたら「部屋に無造作に置いていると、だらしない推しと同居している感じがして非常に良い」とのことでした。

自分がつくったもの

僕はUnityのAudioMixerを触ったことがなかったので勉強していました。その過程で「聖飢魔Ⅱ平沢進ってどっちが強いんだろう?」と思い立ち、音楽を同時に流してバトルさせるゲームを作りました。

基本はピンポンで球が自陣に入ると減点ですが、点数が下がるのではなくピッチやテンポが変動します。原曲からずれまくると評価が下がり、ある程度差が付くと負けになります。 初めて音声の合成をしましたが、何の知識もなしに単純に混ぜると耳が不快になるということがわかりました。

しかし、この発表により会場の平沢進ファンを炙り出すことに成功しました。公開予定はありません。

感想

正直なところ、もともと勉強会やハッカソンがそこらじゅうで開催されている東京では八耐はいらないのではないかという気持ちをある程度持ってたんですが、こんなごった煮のハッカソンで且つ、ゆる~く自由にやれるイベントは東京でもそうあるものではないなあと再度認識しました。最新技術を使うでもなく、レギュレーションがあるわけでもない唯々好きなもの作るだけのイベントです。であれば別に家で独りでやってもいいんじゃない?というのはその通りだけど、八耐は交流にも重きを置いています。自分と違う職種のクリエイターと話すのは結構面白いです。独りでやってもいいけど、八耐でやった方が面白いなと思わせられるようにしていきたいですね。 東京はまだまだ参加者が少ないので、今後やってること報告して参加者増やせたら面白いなあと思ったのでした。 通常八耐も不定期でやります。いつやるかは未定ですが興味ある方は是非お声がけくださいな。

追記

XFLAG側でもブログ上がりました career.xflag.com

転職活動ログ

こちらの記事は転職ドラフト体験談投稿キャンペーンに参加しています

job-draft.jp

amazonギフト券が欲しいので書くことにした。

転職ドラフト以外も使って就職活動していたので、それらを話しつつ転職ドラフトの話をします。せっかくなので転職活動でこんなところで悩んでこんな解決したよというのも話します。

転職活動開始時

最初は知り合いから紹介された転職エージェントと話しながらいろんな会社に書類を送ったりした。それと並行してリクナビマイナビも登録していたが、これらで受けれる会社は大体エージェントが紹介できたので不要になり退会した。エージェントが紹介できない会社に限っては自分で書類送って受けに行くという感じで進めていた。

ちなみに転職活動の進捗状況はGitlabに「job-hop」というリポジトリ作って管理してた。

f:id:adarapata328:20180830200042p:plain

GitLabにリポジトリを作って管理してた

履歴書とか職務経歴書もここに管理。githubでもよかったんだけど、gitlabはissueにweightを付けられるので何かと便利。 面接で何話したかとかもissueにコメントしてたんだけど、会社によって明らかに文章量が違うので熱量がしっかり形に残ってるのは面白かった。

初期の課題

エージェント経由でも最初はだいぶ高速でお断りされていた。大体理由は二つかなあと思う。

書き慣れてない職務経歴書

転職活動は初めてなので正直なにやればいいの?感はあった。とりあえず履歴書と職務経歴書書いてね見たいな感じでやったけどそれも結構難易度が高く。 特に職務経歴書が難解で、僕の書いた経歴書の例文では「上流で設計を担当しました」「品質管理・テストを担当しました」とかプロダクトの担当範囲をしっかり書きましょうと説明書きがされていたけど別に上流もないしテスト担当だったわけでもないし全部やっとるわみたいなという気持ちになった。とにかく自分のやってきたことを文章にしようとしたときに職務経歴書フォーマットみたいなやつが全然当てはまらなくて完全オリジナル文書みたいなのができてた。

これが良いのか悪いのかみたいなのが見えないのが精神衛生上よくなかった気がする。

業界未経験

エージェントとも話してある程度理解はしていたが、やはり業界未経験が飛び込むのはちょっと大変らしい。

元々WEB業界だったところをゲームで探したので業界未経験という立ち位置になってしまい、結構いくつかの会社は経験が足りないとお断りされたのを覚えている。面接でも「この年齢で新たな職種に飛び込むのはだいぶ勇気が必要だと思われますが」と言われたりした。これは今でも「そんなに勇気いらんやろ・・」と思ってる。

最速だと書類送って20分で落ちた会社がある。バッチが走っているのかと思った。

ただこれは経験の有無だけではなくて、上記の職務経歴書書き慣れていない問題が重なって全く自分のことを伝えらえていなかったんじゃないかなあというのは反省している。

ポートフォリオ作る

この二点が結構問題だったので、業界の人とちょっとご飯食べながら相談した結果、やっぱポートフォリオあった方がいいよねーという話になった。

ポートフォリオとは言えないまでも、実は簡単な実績書いてるページはあった。

adarapata profile

ただこれは殺風景だしなんかゲーム作ってる感がないのでやはりポートフォリオは作った方がいいということで、1日でさっと作った。

https://unityroom.com/games/portfolio

学生時代から遡って作ったゲームを紹介していった。実際に遊べるのは半分くらいだけどとりあえずこれで「ゲーム作れるんやな」感は出せた。

これも一緒に出してから選考通過率が上がったので最初からやればよかったほんと。 最終的には転職エージェント+自分で書類送った企業で合わせて2社内定いただきました。

転職ドラフトの話

転職活動初めて1ヵ月くらいのときに、ドラフト開催の情報がTLに流れてきたのでせっかくなのでちょっとやってみた。

レジュメは結構時間かかった。自分のコアに当たる部分なのでやはり経験だけかいても厳しいなと思い、何故やったか、何を解決したかったかというところに比重を置いた。業務の話になるので書けない内容も多くなるかなあと思ったけど、割と普段からブログで書いたり発表してスライド公開などしていたのでその辺をベースに書いていくと意外と分量は増えた。普段からのアウトプット大事。

個人的には現在の年収を問われないところが非常にありがたかった。前職を参考というのは本当によくわからない文化だと思う。

指名状況

最終的には7社から指名いただきました。 どれもちゃんとゲームでのお仕事というポジションだったのでありがたや・・と言ってた。そのうち3件辞退して、4件承諾してお話を聞きに行った。ちなみにミクシィもこの中の一つ。転職ドラフトは承諾後のフローは範囲外なのでここからは会社ごとでだいぶ動きが違っていて、通常の面接フローに入ることもあればカジュアル面談したら即内定もらっていたりなどかなり様々だった。指名されるいう形式なので志望理由とか特に聞かれないし、あちらもレジュメを吟味した後なのでしっかり話ができるというのはよかったなあと思う。

指名する理由がきちんと書かれているというのはこちらとしても納得感があり非常によかった。そこで自分がやりたいことじゃないなら最初から辞退できるし。

カジュアル面談で提示額が上がった

個人的にうれしかった話。

ドラフトで指名された企業とカジュアルな面談に行って、雑談してご飯食べて、その後公開してないソースコードを提出したらちゃんとした面接やる前に内定が出て、且つ当初提示された金額を更に引き上げてオファーいただいたことがあった。そこは人事の方もエンジニアで(兼任?)僕のソースコードをしっかりレビューしていただき、コードの良し悪しの話も含め、今後の成長性を評価して適切な額に変更しましたという連絡が来たのだった。ここまでしっかり理由込みでスキル面を評価してもらえたのは他社ではなかったのでかなり感動したのを覚えている。

最終的にはミクシィとその企業で最後まで悩みに悩んで、理由もすべてめっちゃ書いたお断りのメールを送ったらこれまた丁寧なお返事が返ってきたので、徹頭徹尾良い会社だなと思った。今もお会いしたら仲良くさせてもらっている。社名出していいなら出したい。

転職ドラフトの所感

僕自身はドラフトで見つかったのでいいサービスだとは思うけど、楽に転職できる!というサービスではないのでそこの理解は大事かなと思った。あくまでマッチングを目的としているので不相応な会社にいけるわけじゃなさそう。マッチングするためには私はこんな感じですという情報を出さないといけなくて、きちんと客観的に自分の能力とかスキルを判断できる何かが必要。そのためにはやはり定期的にアウトプットしないとなあという気持ちが強くなった。 なので僕は前職より更に会社で学んだことを公開するように意識している。

既に何かしらの武器を持ってる人には大変ありがたいサービスだと思うので、積極的に使ってよさそう。

最後に

転職活動中に色々相談させていただいた方々、本当にありがとうございました。おかげさまで僕は元気にUnityのバグ踏んでます。

社内LT会でキャリアキーノートをやってきた

弊社では隔週で社内LTが開かれている。

adarapata.hatenablog.com

テーマはなんでもいいということなので、今回は前職でやっていたキャリアキーノートをやることにした。

キャリアキーノートとは?というところは次のブログに全て記されている。

blog.hifumi.info

とはいえLT時間は5分なのでかなり端折ることとなり駆け足の発表になってしまった。

speakerdeck.com

5分で話せる内容は本当にごく僅かで、何を話そうかとかなり取捨選択した結果、自分が大事にしているものが見えた気がしないでもない。

周りに流されずに個人で黙々と続けられる人は本当に尊敬しているし自分もそうなりたいけどそれは本当に苦手。とにかく人の影響を受けまくる。後輩にも「周りの影響受けやすいですよね」と指摘されたことはあり、実際その通りだなと自覚しているので、じゃあいい人がいる場所を探した方がいいんじゃない?というのが僕の考え方になっている。転職活動時もその辺に気を使っていたので入ってから後悔も特にはないのだった。

ちなみにスライド内にある阿部さんのゲームは2008年製だけどWin10で動いて感動した。流石.NET Framework

開発方針についての文書を書いていた

色々決めごとをするときは社内にissueなりwikiなり残すのですが、これは外に公開してもいいんじゃない?と思ったので公開します。 今回は「開発方針について」です。

目的

  • クライアントアウトゲーム全体の開発方法、指針を把握する
  • あとから参加した人もスムーズに着手できるようにする

お品書き


アーキテクチャ


なぜソフトウェアアーキテクチャが必要か

  • 大規模開発、運用にはスケールを見通した設計が必要
    • 秩序なき開発は人間が犠牲になる
  • 設計ルールをその都度作っていくのは大変
  • すでに先人たちが積み上げてきた効率の良い設計が存在する
  • それがソフトウェアアーキテクチャ
  • 一般化されている設計ルールは独自設計より学習しやすい
  • 後から入った人も理解しやすい、むしろそれを前提とした採用もできる

プロジェクトの設計(アウトゲーム)


MV(R)P アーキテクチャ

image


Model

  • いわゆるロジックと呼ばれる部分
  • PureClassであり、MonoBehaviorではない
  • 自身を更新したり、処理結果を返すインタフェースを公開している
  • 自身のパラメータをReactivePropertyで公開もする
  • Modelと一口に言っても内部で分類が色々ある。
  • Presenterを知らない
  • Viewを知らない
  • ユニットテストが書けるようにする

View

  • ButtonやImageなど、画面に表示されるもの
  • MonoBehavior
  • 複数の要素をまとめてViewクラスとするのも可
  • Viewはイベントストリームを持っている
    • クリックされた、選択されたetc..
  • ストリームを公開して、外部から購読できるようにする
  • Viewは外部から情報を更新できるインタフェースを公開している
    • 任意のキャラの情報を表示など
  • Presenterを知らない
  • 自身の情報更新のため、Modelは知っている
    • メンバ変数で持つのは推奨しない

Presenter

  • ViewとModelの間に位置するもの
  • MonoBehavior
  • ViewとModelを知っている
  • Viewのストリームを購読し、Modelに更新をかける
  • Modelの変更ストリームを購読し、Viewに更新をかける
  • Presenterは複数のViewを購読してもよい
    • 大きくなりすぎたら別のPresenterに切り出す

Modelの詳細

Modelは多種多様なので、役割ごとに適切に層を分けないと開発に支障が出る。

  • どこにファイル置けばいいの?と考える時間は少ないほうがいい

逆に層を分けすぎてもそれは分割の手間や思考の時間を奪う

  • スパゲティコードに対してラザニアコードと呼ばれる

MV(R)Pにおいて、モデル下は規約は特に定まっていない。 が、スタンダードな考え方はいくつかある


プロジェクトで考えてるモデルの分け方

  • Model
  • Model/Entity
  • Model/UseCase
  • Model/Repository

Model

  • いわゆるロジックと呼ばれるもの
  • 現状はここに大半いる
  • 色々な役割のクラスが混ざっているので適切な分割は必要

Entity

  • ロジックをほぼ持たないデータのみのクラス
  • キャラクタのパラメータとか
  • 通信のレスポンスオブジェクトとか

Repository

  • リソースを処理する存在
  • リソースのGET,PUT,CREATE,DELETEのイメージ
  • どうやって処理するのかを書く
    • 通信?ローカル?etc...
  • 外部からはリソースがどこに存在するのかは見えない
  • キャッシュ機構を持つのもあり

UseCase

  • ビジネスロジックと呼ばれるもの
  • 「やりたいこと」単位でクラスを作る
    • UserNameChangeUseCase TitleUserLoginUseCase など
  • Presenterは基本UseCaseを使ってモデルを触る

名前変更処理の一例(現在こうなっているわけではない)

image


インゲームのアーキテクチャについて

  • 現状定めていない
  • パフォーマンスチューニングなどが必要になるので、レイヤーの分割が適切に行えないことがある
  • ViewとModelに分割はできるかも?くらいの認識

Rx


ReactiveExtentionsとは


MV(R)PにおけるRxの役割


image

ここの Subscribe OnNext の関係を実装するのがRx


async/await とObservableの使い分け

  • 単純に非同期を待ち合わせたいだけならasync/awaitが簡単
  • それだけじゃない複雑なことをするならObservable
    • 特にイベント処理はObservableのが楽
  • とりさんのスライドで大体かいてる https://niconare.nicovideo.jp/watch/kn3081

DI


Dependency Injection

DIはもはやもうこれ見てもらったほうが早い・・

https://qiita.com/toRisouP/items/b3d3c43db40857ca4ad4


プロジェクトにおける主なZenjectの使い方

  • staticなオブジェクトをなくす
  • 環境によるモジュールの差し替え

staticなオブジェクトをなくす

  • 実体に強く依存するため、差し替えづらい
    • isTestみたいなフラグは持ちたくない
  • ゲームはシングルトンによるstaticが生まれやすいイメージ
    • マスタデータ、サウンドマネージャetc...

これらをDIContainerに管理させることで、疎結合なシングルトンに変更する


環境によるモジュールの差し替え

  • テスト時には通信したくない
  • ローカルと本番でリソース取得先を差し替えるなど

通常だとこれらのフラグ管理などが必要 or 手でDIしなくてはならないが、これらをDIContainerに任せられる


何をBindすべきか

  • あらゆるメンバをBindするとかえって面倒になる
  • 普通にコンストラクタで渡せるならそれのが楽
  • 基本的にはシングルトンだったものが対象
  • Presenter、Viewの層まではやってしまってよい感覚

Model層にContainerを渡さない

  • 上記の通り、コンストラクタで渡せるものは
  • Containerそのものに依存してしまうのはそもそも設計としてよくない
  • Presenterから適切なオブジェクトだけをモデルに渡すのが良い
  • ここは努力目標で・・
public class BadUseCase {
    [Inject] DiContainer container;  // UseCaseがcontainerまで気にするのはおかしい

    public void Foo() { 
        var foo = new BadFoo(container.Resolve<Bar>());
    }
}
public class BadUseCase {
    private Bar bar;  // 素直に受け取る

    public BadUseCase(Bar b) { bar = b; }

    public void Foo() { 
        var foo = new BadFoo(bar);
    }
}

テスト


テストいろいろ

プロジェクトで書けるテストは2種類 - ユニットテスト - UIテスト

なぜ書くのか?


ユニットテストはどのくらい書く?

  • 基本的にモデルはすべてユニットテストが書けると考えている
  • 作成したメソッドのテストは書いてほしい
  • タスクの完了条件に「テストを書いている」を足したい
  • 現場の状況で書かない判断はしましょう

テストでよくある質問

Q.仕様変更はしょっちゅう起こるし、その都度落ちたテストを書き換えるのは手間では?

A.確かに手間です。が、どう落ちたのかが可視化されるのは大きなメリットです。影響範囲がある程度わかれば修正もやりやすくなるので結果的には開発速度は上がると考えます。


テストでよくある質問

Q.テスト書く時間をかけすぎて辛い。

A.テストが書けない理由を掘り下げることが大事です。

  • 何をテストしたらいいかわからない => そのクラスに何をしてほしいのか明確になっていない?
  • テストのための準備が多くて書きづらい => 1クラスの依存関係が多すぎる?
  • テストの構文がわかってない => ググるぞ!

コードレビューについての文書を書いていた

色々決めごとをするときは社内にissueなりwikiなり残すのですが、これは外に公開してもいいんじゃない?と思ったので公開します。 今回は「コードレビューの導入する」というやつです

なぜコードレビューをするのか

大きく二つの効果があると思っています

コードの品質を保つ

一人でコードを書いたときに、それが対応として適切であるかどうかを判断するのは結構難しいです。 基本的には機能を実装するとき、以下の三つについて確認する必要があると考えています。

  1. コードの書き方が適切であるか
  2. 解決方法が適切であるか
  3. 修正箇所以外の影響への対応は適切であるか

下に行くほど考えるべき領域が広くなっていきます。 領域が広くなるほどに一人で対応できる難易度は上がっていくため、漏れが発生し不具合が起きてしまいます。 特に3に関しては自分が予想だにしていないところに影響を与えるなどありがちです。 これを防ぐためにテストコードを書いたり、レビューにより他人の視点、知識から問題を発見していくことが重要になります。

コードの属人化を減らす

ゲームは特に専門性の高い部分が多く、この部分はこの人以外対応できないという問題が発生しがちです(属人化)

短期開発における属人化は速度が出せるので有効ですが、長期の開発においての属人化はボトルネックになりがちです。 これを回避するためには全員がある程度コードを把握しておく必要があります。 コードレビューは自分が把握していないコードを見る有用な時間です。 品質を保つためのレビューだけではなく、自身がコードの内容を把握するためにレビューしていく習慣をつけることで属人化に対処できると考えています。

どうやっていくのか

PRのマージは2人のapprovedを必須にする

  • 2人のapprovedを確認して、自分でマージしてもらいます。(書いた人が取り込みたいタイミングを理解しているはずなので)
  • 人数は暫定です。多いか少ないかはやってみて動的に変えていこうと思います。
  • 2人approvedもらえたら、そこからいつマージするかはPR出した人にお任せします。状況に応じてもっとレビューを求めるのも問題ありません。

スクリプトファイルのみの変更はレビュー不要

  • エンジニアが目視で見ても判断つかないため
  • レビュイーがUIテストなどが通ってるかは確認しましょう(いずれ自動化)
  • 「レビューポイント」のところにレビュー不要な理由を書きましょう(シーンファイルのみのためetc..)

インゲーム・アウトゲーム関係なく2人をランダムにレビュアーにする(ランダムな仕組みは後から作る)

  • 属人化を防ぐため
  • リード的な人のレビューを必須にするとボトルネックになってしまうため
  • この人に見てもらわないと不安!みたいなシチュエーションの場合はその都度その旨書いて指定する

レビューを優先する

  • レビューが終わらないのでマージできない!という状況を防ぐために、レビューを優先!という共通認識を持ちたい
  • 忙しすぎてレビューが本当に無理!ということになったらタスクの積み方から一旦見直す

レビュイー(PR出す側)に意識してほしいこと

PRの粒度を意識する

PRのコミット粒度を小さくすることを心がけていきましょう。 体感ですが、スクリプトファイルの変更が二桁突破するともう辛くなります! コミット粒度を小さくするためには、エンジニアタスクの適切な分解が必要になってきます。

例えば「APIからとってきた情報を表示する新規の画面の追加」というタスクがあるとしたら、それは以下のタスクに分解できます。

  • 画面に表示する情報を持つモデルを作成する
  • 新規のAPIと通信をするメソッド実装
  • 新規画面の追加(データは決め打ちのモック)
  • 画面にモデルの情報を表示するように繋ぎこむ

これらをまとめてやってしまうと肥大化してレビューしにくいので、適切な分割を心がけましょう、

背景が伝わるように文章を書く

PRから背景が伝わるように文章を書いていきましょう。 なぜこのPRをやるのか、どのように解決するのか、特にどこをレビューしてほしいのかなのかがハッキリすればレビュアー側の負担を減らすことができます。JIRAチケットのURLを貼るのもいいでしょう。 前職では以下のようなテンプレートを採用していました。これに近いものを用意しようかと考えています。

https://gist.github.com/adarapata/40ec5f66e0c348a639a1aa6cb519aee6

レビュアーに意識してほしいこと

HRTの原則を守る

「レビューはBARで語らうように」という名言があります。レビューとは相手のやったことに対してコメントするので、ともすれば相手を傷つけてしまうような悪い空気になってしまいます。それが発生しないように謙虚(Humility) 尊敬(Respect) 信頼(Trust) の気持ちをもってコメントしましょう。

HRTの原則 ~ソフトウェア開発はバーでしっとり語り合うように ~

http://blog.livedoor.jp/lalha/archives/50496623.html

なぜを書く

「良い」「悪い」という基準は主観的な言葉なので、どういう観点から良い、悪いを判断したのかを書くように心がけましょう。

悪い例:「ここはBのようにしたほうが良いと思います」 いい例:「ここはBのようにするとネストが減り可読性が上がりそうです」

わからないところは質問していく

レビューは品質の保証だけでなくレビュアーが要件を理解する場でもあります。なので、こうしたほうがいいというコメントだけではなくて「このコードは何をしているんですか?」みたいな自身の理解を深めていくのも目的です。 なのでこの辺りがわからない、というのもどんどんコメントしましょう。

褒める

めっちゃええコードやんと思ったらそういうコメントもどんどんしてください。