2019年9月30日月曜日

[Sider] goodcheck.yml not found を直して頂いた

結論
.gitattributes の export-ignore 指定がされているファイル・ディレクトリは、検証対象になっていなかった。
この挙動を修正していただき、export-ignore されているものも検証されるようになった




経緯
iutestSider を使わせていただいていたのですが、
実はだいぶ昔に goodcheck 使おうと思って有効にしたものの、ずーーーっと警告が出ていました。。
対応しないとなーと思いつつ、後回しにしてきたのですが、
つい最近、Slack 通知が以下のように変わったのがきっかけでした。


ご覧のように新しい通知はシンプルになっていいとは思うのですが、以前の通知にあった「Warnings」が消えてしまいました。
この表示が消えたらたぶん一生そのままなんだろうなーと思い、重い腰を上げました。



で、yml いじったりしてみたのですが、
にっちもさっちもいかなかったので、右下から質問して解決に至るわけです。

最後に
  • 日本語で話せるの楽(いろんなサービスでチャットっぽくサポート受けられるのが定番になってるけど、日本語の安心感)
  • 挙動が変わったので注意(export-ignore 使ってることってほとんどないかもしれないが)
  • 同じところでハマって諦めた人に、どどけ~
  • サポートありがとうございましたmm


2019年9月24日火曜日

[Codefresh] PR comment に特定の文字列があったらトリガーする

Codefresh の Free Plan では1ヶ月のビルド数制限があるため、すべてのブランチや PR に対してテストを実行しないようにしています。
が、たまにこの PR でも Codefresh のテスト回したいなーというケースがあったので、PR の comment に反応してテストが実行されるようにしてみました。

(※ Codefresh の Free Plan はちょっとよくわかってないことがあるので、ビルド数制限なにそれ?な場合もあるかも。詳細:「ブログズミ: [Codefresh] Free Plan の内容がよくわからない・・」)

設定の仕方
まず、プロジェクトのパイプライン設定を開きます。
右側に「TRIGGERS」のタブがあるのでそれを開きます。


「ADD TRIGGER」を2回押します。


「GIT」を選択して、次へ。


「TRIGGER BY」は「Pull request comment added」のみを選択。


「PR COMMENT(REGEX EXPRESSION)」に特定の文字列を識別する正規表現を入力します。
今回は「run codefresh」がコメントに含まれていたら、TRIGGER されるようにしてみました。

設定は以上です。

キックしてみる
PR に「run codefresh」とコメントすると、ビルドが始まります。(CI 失敗してるのは気にしないでください)
テストリポジトリはいつもの iutest です。


まとめ
フリープランで CI を使わせていただていると、ビルド制限で困ることが多いです。
ブランチフィルターなどで実行数を減らすことができますが、逆に、フィルターアウトされるブランチでもテストを実行したいケースがでてきます。

そのようなケースに備えて、コメントトリガーに対応しておくと CI Life がより快適になります。
今回は Codefresh で行いましたが、他の(コメントトリガーできる)CI でも随時対応していきたいと思います。

では。





2019年9月17日火曜日

[Codefresh] Free Plan の内容がよくわからない・・

トップページの Pricing には Unlimited build / 1 small resource となっているが、
自分の今の Plan を見ると Free Plan ではあるが、120 build/month でマシンリソースはおそらく Medium resource になっている。

Doc:


My Plan:



120 build/month の制限は正直きついが、Samll resource になるのもきつい・・・

どっちがいいかってのはないのだが、正しい状態なのかよくわからないので正解が欲しい。
それに合わせて、パイプライン調整するので・・・

2019年9月13日金曜日

[CEDEC2019][感想] LUMINOUS ENGINE のログ分析と自動テストで提案されたリプレイ的自動プレイ手法について

一応仕事で行っているので、個人のブログにこういったことを書くのはほとんどしないのだが、
個人的に手詰まりを感じていた分野に対して、非常に興味深い手法が提示されたことと、どこかが実現してくれないかなーという気持ちを込めて、ブログに書き起こすことにした。


セッションについて
まずは、当該セッションについて簡単に説明をしておくが、
大規模開発のためのLUMINOUS ENGINE のログ分析と自動テスト
こちらのセッションではいくつかのトピックが出ていて、AI の詳しいことはさっぱりわからんので、このブログで書きたいことと関係のある部分だけ、かいつまんで書きます。
(詳細は資料(CEDiL)または今ならタイムシフトを見て下さいmm)

ズレを許容するリプレイ的自動プレイ
自動リプレイの実現方法としては、大きく分けて2つに分類できる。

* パッド入力を記録
* スクリプトで制御

パッド入力を記録する方式は、ゲーム非依存で録画したものを再生するだけで実現が可能。ただし、ゲームに依存しないのでゲーム特有の状態変化に弱い(乱数・FPS・演算誤差とか)
スクリプトで制御する方式は、ゲームに特化した制御ができるのでなんとでもなる。ただし、パッド入力方式ほどの手軽さがない。

セッションでは、パッド入力方式を軸に
リプレイがずれないように、がんばるのではなく、
一度ずれても、復帰できるように
がんばった方が、よさそう。
という考えから、マシンラーニングによるラーニングリプレイを実装されていました。(スゴイ)



個人的に、ゲームに依存してはいけない(できない)絶対条件でリプレイ方法を考えていたので、
この方式はすごく参考になった。

ゲームの情報に依存しない
個人的に素晴らしいなと思ったのは、ゲームにおける意味のある情報を要求しないでも実現できているところ。
入力に使われる値は、ゲーム内の意味のある情報ではありますが、AI はそれを認識しておらず、単なるデータ配列として扱っています。
出力は「キーパッドの入力」であるため、こちらもゲームの内容には一切関わらないものです。

セッションでは、リプレイの撮り直しもマシンラーニングで行っていました。(スゴイ)
ただ、こちらはゲームおける特定の状態が認識できた方が、よい結果が得られるようで、セッションでは壁との衝突を認識させていました。
ここで、ゲームから壁に当たったよーという情報をもらうことなく、入力はあくまでデータ配列のまま解決していたのが素晴らしいと思いました。


これをそのまんま使いたい
たぶん、このセッションを聞いた方の多くがこう感じたのではないか?と思うのですが、私もその一人です。
システムとしてはゲームに依存しないので、このシステムは切り売りできるのでは?
(ゲームジャンルには依存するかもしれないが、考え方としては流用できるのでは?)

と、思ったところで1つの案を思いつきました。
ハードウェアでできるんじゃない?

開発ツールがリプレイ的自動プレイをできるようになる?
単純に時間とパッド入力の録画を再生する機能(パッドリプレイ)は実は存在しますが・・
これは当該セッションや他の自動プレイ関係のセッションでも語られてますが、しょーじき全然再現できないです。
(乱数シードの固定はもちろんしてても、どうしてもずれちゃう)

なんらかの同期信号も録画して、ゲーム内のループと同期しながら再生したらいいんじゃない?とか考えたりもしてましたが、
バグの再現方法としてのパッドリプレイをゴールにしてたので完全再現という呪縛から逃れられず、考えが凝り固まってましたね。。
なので、(開発ツールでやるなら、ここどうするの?ってところはありますが)ラーニングリプレイはなんか良さそうだなと思いました。





LUMINOUS ENGINE のリプレイ手法は、メモリ上の任意の値を入力に、パッド入力を出力するものでした。
開発ツールであれば、メモリ上の値はいくらでも見ることができますし、パッド入力などデバイス入力の状態も取得できます。
ログとして値の変化をためていく部分もハードウェアで処理させるほうが有利ですし、GAME への影響もありません。

メモリ上の任意のアドレスをどう示すかは、デバッグシンボルとなんらかのマーカーをおけばなんとかなりそう。
ゲーム機の Vsync は取れるが、ゲームループは単純には取れないので、これも上の方法で取得。
「取り扱い注意な値」は、デバッグ情報あればなんとかなるんじゃないかな。

出力として得られたパッド入力は、当然開発ツールから流し込めますし、わりと現実的なのでは?と思ってしまいました。。。
(テキトーに殴り書いてます・・)
(あ、リプレイの撮り直しは構想から除外してます)


ここでポイントになってくるのが、「ズレの許容」と「ゲームの情報に非依存」であるところです。
「ズレの許容」は単純なパッドリプレイの弱点を克服し、「ゲームの情報に非依存」であることで汎用的なツールやゲーム開発者が誰しも使う開発ツールにも適用できる。はず。

ぜひ、将来の開発機材には標準で搭載されていて欲しい。


最後に
勢いでここまで書いたが、まぁだからなんだという内容だ・・
他力本願です。って言ってるだけなんだが、まぁなんだ気持ち伝われ。
(そういうのまたやってみたいという気持ちはあるよ)

では。

2019年9月4日水曜日

[CEDEC 2019] 行ってくる

今日から CEDEC 2019 ですね。
私はいつもの CI love T シャツで参加します!



では。会場で!!