kidoOooOoooOOom

ゲーム開発やってます

「現場で役立つシステム設計の原則」と「レガシーコードからの脱却」を読んでUnity開発のテスト自動化への危機感UP

現場で役立つシステム設計の原則」を読み終わって、今は「レガシーコードからの脱却」を読んでいる途中。

先日のEOF2019であったt_wadaさんの「質とスピード」、ryuzeeさんの「レガシーコードからの脱却」の資料も合わせて読むと理解が深まってくる。

speakerdeck.com

slide.meguro.ryuzee.com

内部品質であるソフトウェアの保守性を高めること

f:id:gidooom:20191123095532p:plain
t_wadaさんの「質とスピード」スライドより

f:id:gidooom:20191123095556p:plain
t_wadaさんの「質とスピード」スライドより

最初から作るべきものが正しく予測できて、それを一発本番の開発フローで正しく作ることが「幻想であること」がもう分かってきたので、最近はアジャイル開発がキャズムを超えてきている。

当てになりにくい「予測」よりも「対応」(=変更容易性=適応性)を高めるプラクティスが重要になってきていて、テスト自動化やドメイン駆動、モブプロなどが効果的になっている。

現場で役立つシステム設計の原則」では、以下のような変更しやすいソフトウェアのための実践的なテクニックが分かりやすく説明されていて、基礎力向上に役に立つなぁと感じた(自分は科学系の本ばかり読んでてプログラミングの基礎力弱い)。

  • データとロジックを別クラスにするのではなく、三層+ドメインモデルを考える
  • 値オブジェクトやコレクションの型を言語が用意した汎用的なやつにしがちだが、ドメインに合わせた型にして不変にもなるようにする
  • 区分ごとのロジックを enumなどで実装する。C#の場合はenumに対してエクステンション使う
  • 手続き型プログラミングらしい書き方とオブジェクト指向らしい書き方とを判断できるようにしておく

テスト自動化

node.jsでサーバーサイド開発をやっているときはテスト自動化をできていたけれど、Unityでゲーム開発をし始めてからはまだ自分自身でテスト自動化を実現するのに至っていない。

区分ごとのロジックをenumで実装してそれの単体テストぐらいは書けたが、これでは全然足りないし、これのメンテ自体もまだちゃんとできてない。

kidooom.hatenadiary.jp

Unityの複雑なゲーム起動、データ読み込み、様々なinput処理、組み合わせを考慮できたテスト自動化ができる仕組みと設計を考えていかないと、「質とスピード」の悪い方のプロダクト開発に進んでしまいそうで危機感を持っている。

いきなり開発途中のでかいプロジェクトにテスト自動化を作ろうとしても超難しいので、Unityテスト自動化のプラクティスを見ながら小さいサンプルプロジェクトに何度も適用していって、徐々にどういう設計でどういう仕組みを作ればいいか勘所を探っていくしかないかなと思った。

blogs.unity3d.com

www.slideshare.net

ウェーバーフェヒナーの法則とRPGの経験値および人間の経験値

ゲーマーズブレインを読んで、ウェーバーフェヒナーの法則は気に留めておいたほうがいいなと思ったのでメモ。

ウェーバーフェヒナーの法則とは

ヴェーバー‐フェヒナーの法則 - Wikipedia

www.cradle.co.jp

ドイツの心理学者が1834年に『ウェーバーの法則』なるものを発見し、それを弟子のフェヒナーが拡張したもの。

たとえば、100の刺激が110になったときはじめて「増加した」と気付くならば、200の刺激が210に増加しても気付かず、気付かせるためには220にする必要がある。

また、100の刺激が倍に増加して200になるときの感覚量と、200の刺激が倍に増加して400になるときの感覚量の変化は等しい。

というのを実験によって発見したこと。

ゲームのパラメータ設計もこれを意識したほうがいい

ゲーマーズブレインでは、このウェーバーフェヒナーの法則をゲーム開発でも考慮すべきと述べている。

例としては、アナログスティックの入力の強さと出力の関係もウェーバーフェヒナーの法則を考慮して線形的にしないほうがいい(実際そうなってる気がする)。

また、RPG等におけるレベルアップの必要経験値の入手量も線形的ではなく対数で設計したほうが良いし、これもだいたいそうなっている。

序盤は経験値1とか2から始まって10, 15, 20 みたいにちょっとずつ敵の強さなどに応じて増えるけど、後半は1000 -> 1100 - > 1500 みたいに 増える量も大きくなっていく的な。

人間の成長もどんどん鈍感になっていく

ウェーバーフェヒナーの法則に関連して、下の記事の内容も近いなと思い出した。

readingmonkey.blog.fc2.com

人間も、新しいことを学び始めたときはどんどん成長できている感覚を味わえるが、ある程度(それが中級ぐらい?)まで来ると成長を感じにくくなる。

その成長を感じにくくなった時の状態を壁にぶつかったと捉えて、学ぶのを辞めてしまうケースは結構ありそうだけど、そんなもんなのだから諦めずに続けることが大事だなと改めて思った。

MacでOctaveのplotコマンドが動かない件の環境整備

Coursera Machine Learning コースの2週目から Octaveによるプログラミング課題がある。

kidooom.hatenadiary.jp

MacOctaveを素でインストールしても、グラフ描画のためのplot コマンドが使えなかったので、そこの環境整備メモ。

出力されるエラー

Octave上で plot コマンドを実行すると、下記のようなエラーが出力される。

octave:1> plot(1)

gnuplot> set terminal aqua enhanced title "Figure 1" size 560 420  font "*,6" dashlength 1

参考記事を見て、まずは gnuplotbrew で install

brew install gnuplot

インストール後にgnuplotを起動すると、terminal type に qt が使われていることが分かったので、ホームディレクトリに .octaverc を作って、環境変数の設定を追加。

$ vim ~/.octaverc

setenv("GNUTERM","qt")

この設定を反映することで、octave コマンドラインから plotでグラフ窓が表示されるようになった。

f:id:gidooom:20191121135257p:plain

参考記事

katuo-ai.com

www.ketsuago.com

社内Podcastをやってみて良い感触を得た

先日のEOF2019のレポート記事で社内Podcastに興味が湧いたと書いたところ、

kidooom.hatenadiary.jp

まさにそのEOF2019でPodcastのセッションをしてくれた ゆのんさんから言及Tweetをもらえた。

ここまでくれば後に引けないので、チームのエンジニアメンバーに声をかけて2人参加してもらい、自分と合わせて3人で初の社内Podcast収録をしてみた。

iPhone1台あればいい

マイクなどの収録機材を持ってないので、今回使用するiPhoneのボイスメモだと音質や音量に問題が出ないかが一番心配だった。

テスト収録して音声を確認したところ特に問題が無く、本収録後の音声ファイルも何も問題が無かったので、iPhone1台あれば十分収録できるんだと分かった。

テーマと人さえ決めれば収録できる気軽さが確認でき、今後も継続運用できそうで良かった。

事前に決めたネタ無視で時間も超えて話す

初回なので勝手が分からず、普段聞いているPodcastを参考にして話題になりそうなネタをいくつか用意していたが、それらはほとんど使われなかった。

メインテーマから発散して色々と話題が尽きないので、当初想定してた内容とかなり違う展開になったのはある意味良かった。

(もっと話が続かずに、何話そうか?的な雰囲気になるかと思ってた)

あっという間に40分も話していることに気づいて収録を締めたので、Rebuild.fmがどんどん長くなってしまっているのもこんな感じで話し込んじゃうからなんだなぁと理解した。

チームへの共有

自分で聞き直しながら(自分の声を聴くの最初は嫌だったけど途中から慣れてきた)、簡易的な文字書き起こしをしてチーム向けに公開した。

何人かから、すぐに聞いてくれて感想も貰えたので、とてもうれしかった。

次は自分も喋りたいと言ってくれるメンバーもいてくれたので、是非2回目も収録してメンバーのことをどんどん深堀っていきたい!と思った。

ハースストーン新モードのバトルグラウンド(BETA)にハマってしまったので自分的攻略メモ

先週リリースされたハースストーンの新モード「バトルグラウンド」が面白くてハマってしまっている。

www.4gamer.net

なかなか勝てずにレートも上がらないので、攻略も兼ねて自分的にメモっていく。

(※以下は2019/11/17時点のデータをベース)

まずはリソースを理解

ヒーローピック

8割ぐらいのヒーローを使ってみたが、強さはほぼ以下の記事と同じような感触だった。

hearthgamers.com

自分が1位を取れたことがあるのは、「ミリフィセント・マナストーム」と「ネズミの王」を使ったときで、いずれもMech主体のデッキを構築した時だった。

1度使ってみないと使用感が分からないヒーローも多いので、選択したことが無いヒーローが来たら死ぬ覚悟で選んで一旦学ぶのが良いと思う。

カードプール

バトルグラウンドで使えるカードプールも公式で公開されていた(この記事を書くことで見つけられたので良かった)

playhearthstone.com

改めてカードプールを見ることで、Mech主体とBeast主体が安定して強いイメージ湧いた。

Demon主体はソウルジャグラーがハマれば強いんだけど、ソウルジャグラー自体がDemonじゃない上にこいつがアッサリやられるとコンセプトが崩壊するので不安定。

ソウルジャグラー

最優先ピックはAmalgam(融合体)

どのデッキでも採用できる万能ユニットがAmalgam(融合体)で、こいつはグレード2で見かけたら絶対にピックしたい。

Amalgam

Mechデッキで不足している貴重なPoison要因となれることが大きい。

スタッツが膨れ上がったTaunt & Poison付きのこいつがいるだけで序盤〜中盤は絶望的な状態になる。

現時点で強いと思われる戦略

基本は種族染めになるが、前述した通り Mech 主体とBeast主体が強い。

Mech主体

全体的に外れミニオンが少なく、安定した立ち回りができる。

相手にしててとにかく辛いのが、

  • 高火力になった「コバルトの守護者」が次々と死亡時効果で出てくるメカによってDivine Shiledが張りっぱなし状態になる
  • 気づいたらスタッツが膨れ上がっている「ジャンクロボ」
  • 挑発ユニットを次々と産出する「警備ローバー」
  • 最後の最後に戦況をひっくり返す「ケンゴーの弟子」

対戦しててボコボコにされた相手の戦略を覚えておくのが攻略のカギとなることがよく分かった。

Beast主体

Beastで強いのは下の2ミニオン

ネズミ軍団から大量に出てきた小型ミニオンを倒しているうちにハイエナがものすごいスタッツになっていて蹂躙される。

ネズミ軍団から出てくる小型ミニオンも、以下のミニオンがいる場合は凄まじい攻撃力になってしまう。

敢えて弱点をあげるとすれば、火力重視で体力は少ない印象なので、Divine Shiledが張りっぱなし状態のMechには苦戦するかもしれない。

進め方

やはり1位を目指して中長期的な運用をしていくことが必須になる。

序盤だけ強い効果をもつヒーローは、その時点で厳しい状況になっている。

序盤

自分のヒーローとのシナジーになるミニオンを選ぶことになるが、星1のミニオンを最後まで使うことは少ないので、売る前提で序盤向けミニオンを取るのもあり。

2ターン目にはグレード2に上げるのが安定。

3ターン目の購入がかなり大事になっていて、ここで良質なグレード2ミニオンを2体買いたい(最初に買ったミニオンを売れば2体買える)

中盤

こっから力の差が出始める。

多少のダメージは覚悟しながら、長期的に勝てそうな戦略につながるユニットを選択して購入していく必要がある。

Mech主体、Beast主体であればコアミニオンはグレード2〜3のユニットになるので急いでグレードアップを目指さずにそれらの強化を続けても良さそう。

イマイチな構成のままであれば、グレード4以上にいる単体で強力なミニオンを揃えて、4位以内を目指すことにスイッチすることを仕方ないかもしれない。

終盤

とにかく高スタッツ、高シナジーのぶつけ合いになっており、猛毒ミニオンがいないと倒すのが無理な体力にまで育っている可能性もある。

基本的に死亡時能力によって高火力ミニオンが増殖する状態(Beast主体とかそう)にもなっているので、シナジーが何もない単体そこそこスタッツミニオンは役に立たずに死んでいく。

裏に隠れているコンボ系ミニオンを抹殺できるので、下記2ミニオンは優先ピックしてもいいと思う。

その他細かいルールやTips

攻略wikiを見て初めて知る知識も多かったので、こうやって情報を得ないものはカモになるのだなと改めて知らしめられた。

wiki.denfaminicogamer.jp

まとめ

勝率はまだ全く安定してなくて初期レートからあんまり変わってないけれど、色々試したことで攻略法が見えてきたので更に面白くなってきた。

ただ、これにハマって勉強の時間をあまり削らないようにしないと・・・。

「ワンナイトKPT 狂気Ver」というのを考えて試してみたら、意外と発見があった

定期的にチームでランチを食べながらボードゲームをしていて、この前やった「ワンナイト人狼 狂気ver」がとてもカオスで面白かった。

ワンナイト人狼 狂気ver とは?

まず、「ワンナイト人狼」というアナログゲームがあって、それは人狼ゲームをサクッと10分程度で終わらせるようにしたものでこれもとても面白い。

それに少しアレンジを利かせたのが狂気verで、ランダムに各プレイヤーに「狂気カード」というのが配られる機会がある。

この狂気カードが特徴的なものになっていて、以下のような効果があり、そのカードを受け取ったプレイヤーはそのルールを守らなければならない。

  • 他のプレイヤーのことを「ママ」としか呼べなくなる
  • 1分ごとに全員にハイタッチをする
  • 事実と反対のことしか言えない
  • 発言をするときは、白目を剥いてでしか話せない

などなど、傍から見たらかなりイッちゃってる集団にしか見えないヤバいルールが揃っている。(その反面、やってる側はかなり盛り上がる)

もっと詳しいルールは、こちらのサイトなどを参考。

www.comonox.com

この狂気カードによって普段の人格と異なる発言や行動をすることを強制されるため、そこが新鮮でとても面白く感じた。

そこから着想を得たワンナイトKPT 狂気verとは?

この強制ルールを、「普段のMTGや振り返りのKPTにも使ってみたらどうなるんだろう?」という好奇心が湧いてしょうがなくなってしまったので、無理を言ってエンジニアチームのKPTの時間を使って「ワンナイトKPT 狂気ver」を開催させてもらった。

ルールは割と単純で、あらかじめ話しておきたいアジェンダを決めておき、話を始める前に狂気カードを伏せて各自に配って、そのルールを各自が守って議論をするだけ。 (狂気カードは他の人は見せないこと)

今回用意した狂気カードはなるべくKPTが新鮮に感じられるようなものを想像して作ってみたけど、やってみたら想像以上にカオスな状況になったし、意外と良い議論ができるキッカケにもなったりして、いくつか発見があった。

  • 発見
    • ひたすらホワイトボードを書くルールがあると話が整理されやすかったので、やはりホワイトボードに書きながら議論するのが良いんだと実感。
    • 「社長になったつもり」など、なにか自分の中にロールがうまれると、いつもと違った考えが生まれたり発言が増える。
    • ただし、1人変な雰囲気のロールの人がいたりすると、議論が進まなくなりがち。

今回用意した狂気カードの中で、まあまあ良い効果だったものは以下の通りだった。

  • 良かったカード
    • とにかくたくさん話す。発言数1位を目指す
    • 最終的になんか1つActionを決められるように話をまとめる
    • 社長になったつもりで話す
    • CTOになったつもりで話す
    • ホワイトボードに話しの内容をずっと書く
    • かなり批判的に話す
    • めちゃくちゃポジティブになる
    • できるだけ斜め上の意見(突拍子もないこと)を言う

逆にあまり意味がなかったり、話しがやりづらくなるマイナス効果のものは以下の通りだった。

  • マイナスだったカード
    • 自分の意見や意思と逆のことを言う
    • とてもゆっくり話す
    • 英語で話す
    • 立って話す
    • 他の人がどんな感情なのかを注目し、たまに実況する(ちょっとカチンと来てる?とか)
    • ずっと誰かの目を見て話す

(マイナス効果のカードはその場ですぐに捨てた)

まとめ

まあ、正直くだらない事をやってしまったかもしれないけれど、何でも試しにやってみてそこから何かしら発見する機会にもなったので良かった。

前にバズっていた下の記事にも結構インスパイアードされているとも思う。

dailyportalz.jp

今後、「議論が進まないなぁ」とか「なんかいつもの違った空気でKPTやりたいなぁ」と思ったときは、おもむろに全員に「CTOになったつもりで話す」のカードなどを配ってみて、意識高い議論に持っていったり雑な雰囲気にさせたりするのも、個人的には良いんじゃないかなと思った。

ブクログ再登録して読んだ本を管理していく

今年初めから勉強へのモチベーションが再燃してたくさん読書もするようになった。

読んだ感想や学んだことをブログ記事にしてアウトプットしてはいるけど、まだまだ一部の本しかアウトプットに繋げられていない。

読んだという蓄積記録だけでもどこかに残しておきたいので、10年以上前に使っていて最近放置していたブクログサービスに再登録して使うことにした。

booklog.jp

とりあえずamazonの購入履歴を辿って、読み切った記憶がある本をひたすら登録(人によってはこの初期登録がかなり大変になりそう・・・)。

本棚にある本や図書館で借りた本も覚えている範囲で登録したが、まだかなり登録漏れはありそう。

ブクログを使ってた時は買ったばかりの本もすぐ登録してたけど、登録しただけで満足して読まない本が結構あったので(なんかそこで欲求満たされてる感)、今回は「読み切った本」を登録する運用ルールにしてみる。

これによって、登録するためにも読み切らなきゃ!というモチベになることを期待。

あと最近の感想として、エンジニアはみんな読書好きの印象を勝手に思っていたんだけど、意外とそうでもないんだなということも感じてきていて、読書好きというのは十分自分の強みになるんだなと分かった。

とはいえ自分も技術系の本の割合がそんなに多くないので・・・そこは頑張っていきたい。