奈良北部のなにか

Arch Linuxサーバでてきとうにpacman -SyuとかでアップデートしてたらいつのまにかDBD::SQLiteがコアダンプはくようになってて掲示板とか曲目データベースとか動かなくなってた。

なにか共有ライブラリのパスでも変わったのだろうかとcpan -i DBD::SQLiteを試みるもそこでもコアダンプをはいている模様。

DBD::SQLiteをダウンロードしてきてperl Makefile.PLをたたいてもコアダンプ。

不審に思ってMakefile.PLを見てみるとその中でバージョンチェックのためにrequire DBD::SQLiteしているところがあって納得。
とりあえずそこをコメントアウトしてmake / make testすると問題なく通った。

さてmake installをたたこうかと思ったが、せっかくならcpanで処理したいなと思い、ためしにcpan shellでinstall .をたたいたらすんなり通った。
パスでもいけるのね。

この記事は【その1】ドリコム Advent Calendar 2015の20日目です。
前日はおーはらさんのElixirを使ってSidekiqを操作するでした。

なお弊社今年は募集盛況で【その2】ドリコム Advent Calendar 2015も出来ました。よろしくお願いいたします。
ついでに個人的に伺か Advent Calendar 2015とかLinux Desktop Advent Calendar 2015とかElectron Advent Calendar 2015とかNode.js その2 Advent Calendar 2015とかももんが Advent Calendar 2015とかも参加しているのでよろしくです。

自己紹介

ドリコムの新卒エンジニア、奈良阪と申します。ネットで奈良阪|Narazakaっぽいアカウントを見つけたらたぶん私です。
こんなアイコン

物理学専攻として生まれPerlで育ちJavaScriptでゲテモノを作る仕事Ruby使いでErlang勉強中のインターネットラクガキマンであり、メインWindows(10)でArch Linux好きなMacアンチでオープニングアニメーション愛好家なぬるめの時刻表鉄でもあります。
業務ではRailsをいじりつつ、Electronでプランナー向けツールを作ってみたり、管理画面にJavaScriptを仕込もうと狙ったりしています。

まあ変な人です。

新規ゲームアプリをモデルとビューに分けて作ったり色々したら捗った話

新卒エンジニアなので新卒研修というものがありました。
プランナー、デザイナー、プログラマーを含んだ6人のチームでゲーム1本作るといったものです。

そこでUnity3Dでスマホゲームを作ることになり、エンジニア3人のうち僕を含む2人でクライアントを作ることになりました。

作業分担としては、UnityでUIを作るあたりをもとからクライアントエンジニアであるchu-hiくんにやってもらい、もともとサーバーエンジニアである僕はUIがあまり関わらないロジックの部分を担当することになりました。

ロジックの部分を請け負ったのでそこの全体的な設計は僕がやることになりました。
そこで色々なことを個人的な趣味で仕込んでみて捗ったりしたという話です。

1.モデル(的な部分)とビュー(的な部分)に分けて単体テストを書いた

かねてから個人的にゲームのクライアントにもサーバーでやるような自動テストを導入したいなあという思いを持っていました。

今メインでいるプロダクトもそうですが、基本的に弊社ゲームのクライアントには自動テスト的なものがないのが現状です。
無論十分手動でテストが入れられているから回っているんですが、プログラマーたるもの怠惰にゆきたい。テストとか面倒なルーチンは機械にやらせたい……。
一般的に見た目に関わる部分の自動テストが面倒なのはあるんですが、見た目に反映する前の、例えばダメージ計算とかそのへんの部分まではある程度現実的に自動テストが入れられるんじゃないかと思いました。

そこにきて本ゲーム、前述のような分担をすることによって、作業者によってロジック（モデル的なところ）とUI（ビュー+コントローラ的なところ）を分離することに成功しました。

というわけで自動テストを書きました。
xUnit.NETつかってだいたいこんな感じです。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Xunit;
using NewGame.Word;
using NewGame.Status;

namespace NewGameTest{

    using ExecutableString = String;

    public class WordFrequencyElementTest{

        [Theory]
        [InlineData("return 1")]
        [InlineData("return 0.1")]
        [InlineData("return 'a'")]
        [InlineData("return true")]
        public void condition_enabled(ExecutableString condition) {
            var status = prepare_status();
            var fe = new WordFrequencyElement(condition, "");
            Assert.True(fe.IsEnabled(status));
        }
...

ロジックがUnityに依存しないPure C#でできているのでxUnit.NETとかそういう汎用のツールでかけて実に清々しいです。サーバーの人間にもスルッとかけます。

UIのテストはできていないんですが、その中で動いている複雑な部分のテストがあるというのは品質に対して実に安心感があるものです。個人の感想ですが。

これによってゲーム開発によくある（らしい）仕様変更にともなうコード修正に戦々恐々とすることはなくなりました。

2.データエディタを作った

かねてから個人的にExcelを撲滅したいなあという思いを持っていました。

基本的に弊社ゲームのデータはExcelで作られています。
・エンジニアにとって:
Excelはマージができませんし、差分もgitネイティブでは見られませんし、バイナリだからひたすらリポジトリが重くなりますし、ゲームに落とし込めるようテキストに変換するのに数分かかります。
・またプランナーにとっても:
RDBまんまなのでいちいち色々なところに数値のIDを関連づけのために入れなければならないし、複数人作業するときに手動ロックしなければいけない（自動マージできない）です。

つらいです。

というわけでこのゲームではExcelを生まれる前に消し去るために、すべてyamlやjsonをマスターにしたいなと思いました！

……と、言うは易し行うは難し。

実際データを作るプランナーの人とかにyaml直接いじれというのは酷というもの。
エンジニアが楽した分プランナーが闇を背負ってはいけません。
「データをいじるためのUI」＝「データエディタ」は必須なわけです。

普段はExcelがその役を負っているわけですが、Excelが嫌なら他のツールを使うしかない……。

というわけで今回は自分で作りました。
こんな見た目のやつです。

いわゆるゲーム中のシナリオみたいなやつのエディタで、yamlファイルを吐くものです。
ツリー状の構造になるゆえにExcelでは管理しにくかったので専用のを作ってみました。

Electronを使うことでWebアプリと同じような制作ができつつWin/Mac両対応が行え、UIライブラリとしてwebixを使うことでデスクトップアプリに遜色ない操作性を確保できました。

こちらはプランナーデザイナー陣にも好評で、「ならツール」などと呼ばれ親しまれました。
が、プロト提出の締め切りギリギリの中で結局デザイナー少しとあとほぼプログラマしか入力しなかったなど、課題は残りました。

3.データエディタにゲームのモデル部分を接続した

かねてから個人的にゲームのデータ調整やチェックを実際のゲームの処理に突っ込んでやりたいなあと思っていました。

ゲームにバグを出さないためにデータチェックツールというのが往々にして作られるわけですが、なにぶん仕様追加変更の多いゲームのこと、本体の変更に追従してゆくコストがかかります。
なのでゲームのデータを簡単に「本物」のゲームの処理に突っ込んでテストできれば、そういった外部ツールの辛みもなくなるのではないかと思いました。

というわけで先ほどのゲームのモデル部分処理だけを切り出してコンソールアプリケーションにし、先ほどのエディタがその入出力に対応することで、「本物の処理」を使って「プレビュー」を行えるようにしました。

右側がその「プレビュー」で、「実行」ボタンなどを押すと現在編集中の部分のシナリオが実際のゲームでどういった動きをするのか、選択肢などの挙動も含めて再現できるというものになっています。

この機能もやはり好評でして、プレビュー機能の成果か突貫工事なデータ入力作業でもレビューでバグっぽい動きはしませんでした。

実装としては単純にパイプで入出力しました。C# CLIなexeとnode.jsのchild_process.spawn()との通信です。
Edge.js、そのElectron対応版のelectron-edgeを使えば、node.jsからDLLのごとくC#内部の関数を呼べたのですが、やったかぎりだとあいにくそれができるのがWindowsのみだったので、Win/Mac両対応を崩さないためにパイプにしました。

ゲーム本体は本来ならシナリオを最初から再生する機能（上記ボタンの「戦闘開始」のみの機能）しか持たなくて良いので、本番では使わないテスト用の機能の追加は避けた方がデバッグコストなどもかからないでよさそうです。
本質的な処理をするモデルをゲーム全体から切り離せるようにしておくと、UIの必要性が薄いテストツールを気軽に外部アプリケーションとして作り込めると思います。

ただしこの手法の反省点としては、簡易プロトコルを作ったり、初期化処理だけですが本体に追従したり、Electronとの結合だったり、工数的にはちょっとお高くついてしまった感があるあたりでしょうか。
やっぱりゲーム自体にテスト機能を組み込んでしまう方法をとって、Unity3DのWebGLビルドを使ってブラウザ内完結させるとかのほうがもしかしたら簡単だったかもしれません。

まとめ

研修で新規ゲームの設計をやるに当たって、かねてから周りのゲーム制作を見つつ個人的に抱いていたゲームクライアント制作手法への提案を試してみました。

・モデル的な箇所とビュー的な箇所を分離することでテストをかきやすくし、実際書いて品質を担保しました（まだリリースしてないので主観になってしまいますが）。
・Excelには向かないデータ編集に対して独自ツールを作り、企画工数を減らしました。
・さらにデータ編集ツールにゲームの本物の処理が動くプレビュー機能をつけることによって、ミスを減らしたり調整を楽にしたりしました。

やってみた所感としては、

・モデルビュー分離はコードの質を保つのに貢献し、一方で爆速感の不足や、やや仕様変更に手間がかかる感がありました。ただテストなしで仕様変更後などにバグチェックするコストを考えると、実際には仕様変更の手間というのはこちらの方が軽いのかもしれません。
・データ編集のための独自ツールはプレビューもあって非常に便利でした。調整も楽だし、Gitフレンドリーでエンジニアも楽です。ただし初期投資はその分かかるので、短期間で運用を終了するゲームの場合はもしかしたらExcelに任せた方が良いのかもしれません。

基本的には目論見通り、テストや調整のコスト削減につながって良かったと言える感覚です。が、弊社ゲームの既存手法と比べると別のところでコストが新たに発生しており、なかなか八方うまくは収まらないなあと思いました。
ただこれはあくまで最初の試行であり、この方向でうまくやればなにか新境地があったりするかもしれません。

新しく1本ゲームを作るという研修、こういった試行錯誤も含めて多くの学びがあります。
現状まだ道半ばでいろいろあって修羅っていますが、なんとかいいゲームができるように頑張ってゆきたいです。

またここで得た経験を生かしたりして次なる手法の改善を考え、よりゲームの本質的な品質アップを目指して運動してゆきたいです。
そんなわけでまた変な実験を始めたら生暖かく応援よろしくお願いいたしますm(_ _)m＞社内


次回の【その1】ドリコム Advent Calendar 2015は、僕の教育担当でもある@shinya_131さんのエンジニアからデータ分析になって3ヶ月が経ったです。

うっかり遅れてしまいましたが、これはNode.js その2 Advent Calendar 2015の3日目の記事です。Qiitaでもなくてすみません。

2日目はnode.jsでバイナリファイルやバイナリデータをいじる　4日目は俺的gulpでTypeScriptをインクリメンタルビルドする　です。

突然ですが、軽量言語で簡単なツールを作りたいという場合、ありますね。

で、それを人に配布したいという場合、どうするでしょうか。

プログラマ間ならgithubにあげるとか、npmやらCPANやらRubyGemsやらに上げるとかいろいろ定石があるんですが、
でも、プログラマでは無い、しかもWindowsユーザーなんかに配るというケースが発生した場合は？

自分のケースでいうと、ゲームを作っている時に、デザイナーや企画の人がデータをいじったりするツールを作りたいということがありました。
とくにゲームのパラメータとか、最終的にゲームに投入する形はJSONとかそういうのになるんですが、それをプログラマ以外に手書きしろっていうのはやっぱ酷な話。
というか、いや、むしろプログラマこそ手書きしない。そのためのツールを作れるから。
だったら安直に考えればJSONをプログラマがいじればいいんですけど、でもプランナーだけでデータ調整してゲームの体感チェックしたいじゃないですか。
なのでそういったツールをちゃちゃっと作って気軽に配りたいわけです。

そのちゃちゃっと作って気軽に配ること、node.jsならできます。

方法は簡単。

1. node.exeを落としてくる

2. ライセンスも落としてくる

3. てきとうにmain.jsとかにjavascriptを書く

4. main.js冒頭に下記を追記し、拡張子をbatにする(改行はCRLFで)
rem=0;/*
"%~dp0\node" %~0 %*
pause
exit
*/

参考: バッチファイルでNode.jsを1ファイルで実行する方法

5. node.exeとLICENSEとmain.jsをてきとうにzipにしてWindowsユーザーに送って、「ここらへんのフォルダにおいて、main.batをダブルクリックしてNE」と言う。

ね。簡単でしょ()


PerlやRubyなど他の軽量言語ではこうはいかないです。
あれらは実質perl.exe、ruby.exeだけで動くものではありません。
いえ、perl522.dllがいるというのもそうですが、node.jsとの大きな違いはライブラリの扱い方。

Perlでuse utf8;を書きたい場合、binmode STDOUT, ":encoding(cp932)";を書きたい場合……
perl.exe以外にいくらの*.pmファイルを同梱しなければならないことか。
調べるのも大変だし、かといって全部入れようとなるとクソでかい。
Perlなどの言語は基本がっつりPCにインストールされることを想定していて、そのためモジュールも整理されて細切れになっているわけです。

node.jsはそれと違って、node.exeに標準添付モジュールを全て同梱する形になっているので、このようなかんたん配布ができるわけです。

というわけで、Windows用コマンドラインツールをてきとーに作りたい場合は、node.jsがおすすめです！（てきとう

以上、

遅れたせいで最初からリンクを張れる4日目は俺的gulpでTypeScriptをインクリメンタルビルドするです。

結局何使えばええねんと調べてみた。

参照: 最近のインフラ系ツールが多すぎて何が何だかわからない！からの卒業

Bootstrapping Tool

Docker & Packer / Vagrant

まだよくわからん

Configurarion Management Tool

Chef(ruby) / Puppet(ruby) / Ansible(python) / Itamae(ruby) / Serverkit

リモートにもインスコってのはちょっと微妙だと思ったので、push型のItamaeかAnsibleだと思った。
会社で主にRubyなのでまずはItamaeかな。

Application Deploy Tool

capistrano(ruby) / Mina(ruby) / cinnamon(perl) / Fabric(python)

いわゆる軽量系、暗黙の動作がないやつが好みなのでcap以外かなと思ってたけれど、会社でrubyでという制約をつけると、cap or mina。
しかしminaはマルチステージ非対応だったり、capnistranoがなんかwebistranoとかpployとかStranoとかブラウザ上から扱うツールをもってて強そうだったりするので、cap学ぶのが結局つぶしがきくのかなあと。

Web Application Framework

ついでに。

軽量系: Mojolicious(perl) / Sinatra(ruby) / Padrino(ruby) / CherryPy(python) / Flask(python)
手軽系: Rails(ruby) / Catalyst(perl) / Django(python)
よく知らない: Express(js) / koa(js)

と2ラインあるわけだけども、手軽系はやはり暗黙の色々があるので軽量系の方が好き。

自分としてまともに使ったことあるのはこのうちMojoliciousとRails。
Sinatra/Padrinoでまともにアプリかいてみるべきだな。

オチはないです。

主だっては同人ソフト、創作ジャンルの日です。
Linuxとかの解説本が同人ソフトなのはなんだか解せないけど。
なお普段買わないがもらいでエロ同人が入ったりした。

・艦これ

1日目に回らなかった艦これだが、3日目も通りすがりで目についたものだけ
鎮守府に出会いを求めるのは間違っているだろうか　とくに紐とかは関係ない普通の艦これ本。内村かなめブースにあったのでついでに。
OH!スーパーマキグモチャン vier　なぜOH!スーパーミルクチャンをフィーチャーしたのか。しかも途中から割と関係なくなっているし。巻雲+ミルクチャンの衝撃に負けて買っちゃったけど。
RJこれくしょん　ラブコメの波動を発しようとしている本
提督におねがい！　龍驤ラブ本で良いのだけど、艦これのケッコン設定を素直に取り込んだ結果妙にゆがんでて、艦娘設定なかったほうが素直に楽しめた気がする。うーんむずかしい。
艦隊りのべーしょん　ゆるいギャグ。駆逐艦勢同人はほのぼの寄りの本が多くてもっとギャグがほしいんだという需要に合致した

・ギャルゲー系

ギャルゲーム批評　DMMの艦これとかアイギスとかそれ系のブラウザ系ギャルゲー批評本
⇒ねこねこソフトが出展して無いだと 2　なんかよくわからないやつだった
大図書館の羊飼い 総作監修正集　タイトルまんまのアニメスタッフ本 アニメ見てなかったけど作画好みだった。あと桐谷成分。
トレスを科学する　トレスというか、ギャルゲ原画家の絵柄分析本総集編。
みずいろモザイク　きんモザネタみずいろ
水これ　艦これネタみずいろ

・アニパロ系

ファンタジスタドール二次創作ノベルゲームのシリアルコード　走り出せていないマスターの感じ
GJ部TCGプレイマット　走り出せていない
グッジョぶ島にようこそ！2　GJ部オンリーで得た本の続き
なのはまんが大王2,3,出張版　なかなか面白かったので1もほしかったがなかった

・アニパロ(エロ)

みーくん部活やめないで！　漫研のOBである小梅けいと先生にもらった本邦唯一のエロ同人。がっこうぐらしキャラがくんずほぐれつするやつ。

・創作少年

小学生尾道紀行　小学生漫画と見せかけて尾道本
ぬるま湯　ゆるい不条理漫画
CLOSER THAN 4　漫研同期の漫画。前の3までと間が開いているから今一度読み直さないと。
輝くコーンポタージュ　漫研後輩の漫画。出オチかと思ったら、ツッコミがあるくせに最もおかしいところにはみんな突っ込まない系不条理漫画が第二部に続いていた。
九十九の売子　絵やテイストが好みだったので
4コマ目で僕が死ぬ　タイトル通りの不条理漫画

・その他

馬車道用語の基礎知識　絵やテイストが好みだったので あと用語集系ってわりと好き
MOEPOP 29　つばす先生
はむはむ時間　内村かなめオリジナル
妹はいいものだ 冬から夏ラフ集　妹はいいものだのイラスト本
おやしきのなかとそとのおはなし　内村かなめオリジナル

・ゲーム系

箱庭の学園　梱枝りこゲンガーとだけで評を見ないまま買う程度に財布ガバガバ
鉄道事業戦略 完全版　2chの鉄道経営系ゲームスレで黎明期をみていたゲームの完全版
ぐるぐるちよちゃんX Ver2.0.0　「目玉」のキャラ版
はたらくミントさん！　なんかGAのミントのゲームらしい。

・伺かとその他デスクトップマスコット

伺奉行日月抄 六,七　さくらとかの漫画。読むと充実する。
Liplis各種　伺かで言うヘッドラインセンサに特化したマスコットソフト。敵(違)情視察のため。Win/Android/iOS対応らしい。

・PC情報系(ネタ)

ハロー!!きんいろMOSAIC　なんかNCSA MOSAICを今ビルドしてきんモザのサイト見てみたっていう……
なれる！SELinux エピソード0　SELinux解説本になる雰囲気を醸し出しながらとくになにもなく終わった
汝はエンジニアのような名状しがたい何かなりや？　つまるところ人狼らしい
進捗どうでしょう？　闇のゲーム

・PC情報系(オライリーっぽいやつ)

解説CoreUtils　coreutils解説本
Shell Script ライトクックブック　タイトル通り
Compatible ShellScripting デスクトップリファレンス　環境非依存なシェルスクリプトを書くための手引き本
雅なPerl入門　まんまPerl入門書。キャラが解説する形式
Acme大全2015　毎年恒例冗談モジュールAcme名前空間解説本

・PC関係(Linuxやネットワーク関連)

nm vol.1～4　ネットワーク関係のいろいろ
Linux USER　いつもの小江戸らぐの。slax7のライブCDつき。
DNT Info 15　トランスポート層あたりのことを書いているようだ。全然知らないので買ってみた。
セキュリティという概念が存在しない退屈な世界　まあそれっぽいやつ

・PC関係(その他)

エロゲー人工知能　ダッチワイフと会話する系のことをやっているシリーズの中で、音声認識と人工無能みたいなことをしている巻
HANA Student　インメモリデータベースHANA本。普段MySQLとかしか使ってないので他のことも読んでみようかと雑に購入
イメージできるGit　デザイナーの人がGitをイメージで解説する本。だいたいいい気もするが、いきなりコマンド使ってたりブランチの説明が不十分だったり初心者向けとするには中途半端で補足必要そう
中二からはじめるBlender総集編　Blender使い方本
ラボ泊グラフィティ　こういう場では少ないWindowsネタがのってて買いだった
RSpec Hacking Guide　RSpec解説本の電子書籍版


輸送改善ハンドブック　鉄道の輸送改善提案
ANORON　面妖な論文を載せている本
「CC-Viewer」と「にけきち」とサークルについて書いたチラシ　割とよさげなスマホ用コミケカタログビューアCC-Viewerの作者がお亡くなりになった関係のやつ
同人イベントに電子マネーを紛れ込ませる　電子マネー決済導入ハウツー　プリペイドもののみ
SSDベンチマーク集2015年夏号　まあそのまんま
HDDベンチマーク集3　上記のおまけ
これからどのメディアで見る？TokyoMXの歩き方　電波の届きが悪いと評判のTokyoMXの視聴方法をまとめた本

以上、今回のコミケは家が目黒になったのと社会人になったのでお金に糸目をつけずに買うスタイルに切り替えたらやたらたくさん買ってしまった。
正直本棚が休息に埋まるので今後自重してゆきたい。