2012-03

2012-03-03 †

リハビリはまだ続いているとはいえ、しばらくサボリ気味だった運動を再会して仕事するときの作業環境を多少見直したことで、首と肩の状態は最悪から大分悪いまで回復した。それでまあ、3DSで遊びたいゲームもないしたまには据置のゲーム機で緻密な3D空間を暴れ回るゲームを遊ぶかーと思って、まあ買ったわけですよ。

アスラズラース

いや、事前情報でカットシーン多いとかQTEあるとか聞いていたけど、それにしてもQTEゲーにも程があり、そしてQTE以外の部分もちょっととんでもない事になっている。というかむしろQTE以外の部分がマズすぎる。QTE自体は即死QTEみたいなのがないようなので、BAYONETTAなんかよりは大分マシ。問題はそれ以外の部分も事実上イベントバトルみたいなのしかないっぽい事だ。未クリアなので断言はしないが、このまま最後まで同じだとちと厳しい。

2012-03-09 †

Catyの現状としてCIツール使ってないのはイマイチだなあと思ってbuildbotを導入しようと思ったのだが、これがまた最初はワケワカメな代物でね。俺はまず一体どういうメカニズムで動いているのか知りたかったが、まあチュートリアルなどでは省かれてんだなそういうのは。ムカつきつつドキュメントを読み進めると

buildbotのmasterはchange_sourceの記述に従ってソースコードの変更を検知する。
変更を検知した後、schedulersの設定に従ってテストのリクエストをslaveに出す。
slaveに出す具体的なテストの実行方法はbuildersで指定する。

という事が解ったが、調べてみたらIBMのdeveloper worksの図を見れば一発で解ることだった。こういうのはチュートリアルの頭に書いてくれよ、そっちの方が絶対にチュートリアルの内容を理解するのが楽だから。

そして次にブチ当たったのがbuildbotにはmercurialのリポジトリをポーリングする機能が無いということで、しょうがねえから自分で書くかと思っていたが、オフィシャルにbitbucketのPOST通知をbuildbotに通知するためのサーバスクリプトがあった。

https://github.com/buildbot/buildbot/blob/master/master/contrib/bitbucket_buildbot.py

手順としては

buildbot側でchange_sourceをPBChangeSourceに設定。
bitbucket_buildbot.pyを先のPBChangeSourceの起動してるポートをBUILDMASTERに指定して起動。
bitbucketのリポジトリの設定でServicesからbitbucket_buildbot.pyの起動しているURLをPOSTに設定。

という流れでいける。

2012-03-12 †

ソフトウェアを1から書き直して問題が出るケースというのは、大体において以下のような条件が重なっていると思う。

肥大化したソフトウェアである。
(特に外部仕様に基づいた)テストが十分ではない。
歴史的経緯で特殊な実装テクニックが使われており、それについてドキュメントがない。

いずれか一つだけでも問題になると思うが、妙なテクニックを使っていなければ挙動の再現の難度は相当下がるし、肥大化してなければまあ分量的には書き直せることが多そうだし、テストが十分にあったら普通リファクタリングでコードを少しずつ入れ替えていくよな。

というかこれらの要素は互いに関連しあっていて、

運用が始まってからの特殊な例外ケースへの対処や無理やりな新機能追加: 大抵、それらを手っ取り早く済ませようとするとスマートな実装にはならずトリッキーかつスパゲティになりがち。
様々な事情で妙な実装になっている: 大抵は行き当たりばったりで書かれているので、適切なテストもドキュメントもない。
要注意部分への十分なドキュメントがないのに動いているので運用が続く: 担当が抜けたらワケワカメな事になる。
謎のコードについて知る人がいない: コードの整理が困難なのでコードの肥大化に拍車がかかる。
動いている上に機能が十分なので使われ続ける: 運用が続くという事はバグフィックスや機能追加があるわけで……。

リファクタリングも困難な状況になるというのは、殆ど詰みに近い。1からコードを書き直すのが常に悪というわけではなく、むしろ1から書き直しでもしないと仕切り直しが困難に思える状況が悪いということ。

Catyのコードなんてどんだけ当初の姿からかけ離れているかわかったもんじゃないけど、これも大半はリファクタリングで少しずつ入れ替えているのであって、本当にリファクタリングでなしに1から書き直した所って、ANTLRをぶん投げてパーサライブラリを自前で書いたときだけだったはず。そしてその時は十分にコードの規模が小さかった。

またリファクタリングや大掛かりなコードの変更が比較的頻繁に行われる状況に置いて、FITは抜群に優れたテスト手法だ。何しろCaty自体の実装言語が変わっても使えるからな。

先週はインフルエンザでダウンしていたのでアスラズラースは全然進めていなかったが、しかしプレイを再開すると酷いゲームだと改めて思う。ムービーゲーなのはともかく、本当にそれ以外のゲーム部分がアレ。とりあえず操作方法とカメラまわりだけ見ても

ロックオン操作がトグル方式だが、これはロックオンしてるかどうかの判断ミスの温床というのが持論。何故ホールド方式を用意しない。
照準操作の上下反転を選べない。3Dシューティングの類は上下反転でしかまともにプレイできない俺には苦痛。
ラピッドシュート時のデフォルトの照準位置が不親切。
演出が派手な一方、それに紛れて画面外からいきなりぶん殴られる事が多々ある。そもそも大技は回避行動でキャンセル不能なくせに発動タイミングの自由度が低い。この辺は特にBAYONETTAなどの素晴らしさを改めて実感。
不意の一撃を避けるために位置取りをしようにも、完全なビハインドカメラではないので、位置取りと画面内の把握が両立困難な事がある。
攻撃中の向きの修正が困難。敵を軽く追尾するような調整もされてなさげ。

一応難度はハードで遊んでいるが、これがノーマルだったら単なる連打ゲーでさらに面白くなさそう。(ハードでも死ぬのは基本事故死だけど)

今のところの感想としては、意欲と熱意は伝わってるけどゲームでこれやっちゃダメだろという感じだ。というか俺の表情がアスラさん状態。

2012-03-14 †

俺はBIとか負の所得税とかには概ね肯定的なのだが、その大きな理由に「雇用を生み出すためだけに存在するクソのような仕事がある」「雇用を維持するために改善策の図られない仕事がある」というものが挙げられる。

どうせそんな仕事に従事しても次につながるスキルが身に付くわけでもないんだし、むしろ別の知識や技術を学ぶ時間を奪われていると考えるなら、それこそ本人のためになってない。そんだったら直接金を配った方がずっとマシだろ。

2012-03-15 †

なんかノマドワーキングとかいう言葉でオフィス外での仕事を持ち上げようとしている連中がいるようだが、ノマドワーキングというわけではないものの完全に在宅で仕事をしてる身からすると、これ無茶苦茶向き不向きが激しいと思うぞ。オフィスというのは無理やり全員の足並みを揃えて仕事モードに突入させるリズムを作るという機能もあるわけで、それなしでストンと仕事モードに入れるようでないと。

俺なんかは割と気分の切り替えが早い方で、尚且つ集中力を持続させるのも不得手じゃないので在宅でもさしたる問題になってないし、むしろ他人のペースに合わせずに済むのが気楽だとも思う。でもみんながみんなそうじゃないでしょ。

そして何よりも在宅作業が魅力的な選択肢になるのは、たとえば家族の介護しつつ働く必要があるとか、健康上の理由で遠いオフィスに通勤するのが難しいとか、そういう人達なんじゃないの。斯く言う俺も首と肩と腰を悪くしていて、そのせいでちょっと特殊な作業机で仕事しているので、まあ今のところは普通の会社勤めに戻るのは無理だな。

だからオフィス持たずにネットワーク越しに仕事というのを新しい働き方などと言って変に持ち上げるのはちと気が引けるし、それで向いてない人たちから「ダメじゃん」と言われて在宅ワークなどに否定的な風潮になるのもまずい。あくまでも向いてる人とか、そうせざるを得ない人向けの選択肢として広めていく方がいいんじゃないのかね。

2012-03-16 †

ソフトウェアの書き直しについてもう少し。

極端な例だと、長らく言語処理系のアップデートがされていない言語で書かれたソフトウェアがあったとして、それを別のちゃんとメンテナンスの続いている言語で書き直すなんてのは理由としては十分過ぎるだろう。そこまで行かなくとも、古いとかパフォーマンスが悪いとかの問題を抱えた言語で書かれたソフトウェアを別の言語で書き直すというのは実際にある。というかSIer時代にやった。

で、そういう場合にどういった準備をしなければならないのかを考えれば、同一言語でソフトウェアを書き直すときに何が必要か、そんだけ揃っていれば1から書き直しなんて手間のかかることの前にやれることはないかってのは見えてくるでしょ。その結果「書き直します」という結論に達したなら書き直せばいいわけで。

だからソフトウェアの書き直しの是非はケースバイケースになるので、とりあえず俺は一般論として「リファクタリングでどうにかならないのか」という問いかけを最初にすることにしている。

2012-03-17 †

格闘ゲームの初心者救済システムについて、今では俺はどちらかというと否定的だ。理由はいくつかある。

初心者用モードとそれ以外で分断されてプレイヤーの交流が起きない。
初心者モードと通常モードで後者の方が有利な場合、結局技術格差を埋めることにはならない。
初心者モードの方が明らかに強い、初心者救済システムがOffにできないなど場合、上級者はそれをさらに活用する。
初心者救済といえば聞こえがいいが、上手くなるためのモチベーションを殺いでいる部分もある。例えばストIVシリーズのガチャ昇龍。

これらに加え、そもそも格闘ゲームのゲーム性を考えるとシステムを簡単にしても即座に状況は好転しない。技のフレームなどの情報を互いに把握している場合、格闘ゲームは本質的に将棋などと同じであり、極論すれば1/60秒将棋といえる。そしてプレイヤー間の格差の最大の要因はその情報をどこまで把握しているかによるので、システムが簡単になったから初心者でも戦えるわけではなく、定石を一通り頭に叩き込んだ指し手vs駒の動かし方を時々忘れるレベルの指し手という構図にしかならない。

むしろ初心者救済モードのあるゲームは様々なサブシステムが存在して全体的に見れば複雑なゲームであり、それらのシステムを把握してゲーム独自の攻防を理解するというステップにおいて、昔とった杵柄である程度対応してより深く攻略できる中〜上級者とそれ以外の格差はむしろ広がる。

本当の初心者に必要なのは救済システムや簡単操作などではなく、情報格差の是正とまともなレーティングによる同レベル帯プレイヤーとのマッチングだと俺は考えているが、どうもゲームメーカーはそう考えていないらしい。

2012-03-20 †

インフルエンザ真っ最中に買ったというか買ってきてもらったので感想を書き忘れていたが、押切蓮介の「ハイスコアガール」と「焔の眼」を読んだのだった。

ハイスコアガールはエッセイ漫画のピコピコ少年をラブコメっぽくリファインした感じで、ゲームばっかやってて勉強もスポーツもからっきしのどう見ても作者の少年時代なんじゃねえのこれな少年と、厳格な家庭で育てられて鬱憤がたまっているのでゲーセンで憂さ晴らししてる押切漫画の王道デザインである黒髪ロングのお嬢様、そしてラブコメなんだけど昔のゲーセンとレトロゲームの思い出&薀蓄で話が回るという、いろんな意味で凄い煩悩の塊な漫画。そうだよねー、あの頃は待ちガイルで喧嘩になる時代だったよねー。

それにしてもほぼ毎回黒髪ロングのヒロインだってのにみんな別の可愛さを表現してるのは凄い。やっぱキャラクターの立て方や話の運び方が上手いんだろうな。

焔の眼はダークサイドオブ押切蓮介の暴力漫画。いや暴力描写というよりもむしろ精神的な方の描写の方がはるかにキツい。流石に侵略戦争に負けた国の売春宿から話が始まるというのは読んでて凹む。そこで範馬勇次郎みたいな武道家が大暴れするもんだから、むしろ人間が肉ミンチになって死んでいく場面が清涼剤になってる。

押切蓮介って絵柄が絵柄だけにグロ描写はそこまでキツくないけど、メンタル的な部分での追い詰め方はシャレになってないからな。「ミスミソウ」とか最後の方は作者の精神状態を本気で心配した。なぜあんな気の狂った台詞を考えつくのか。

2012-03-22 †

ドーパミックスを購入。内容は1ボタン音ゲーで、全12曲。曲は多分全曲オリジナルで、ゲーム音楽制作会社のスーパースィープの楽曲だそうだ。ちなみにヴォーカル曲も3曲ほどある。

シアトリズム同様、せっかくノートをカラフルにしたり複数のサイトがあるのにリズムとメロディの切り替えなどが視覚化されてない。リズムもバスドラに合わせるのかスネアに合わせるのか初見では不明。というか目押し不能で両手使って十字キーとボタン併用でないと間に合わなそうなパートが出てくるあたり、案外ハードコアなプレイヤー向け。あとドーパミックスモードでなんかSEがずれてて、それもやりにくさに拍車をかける。

まあ600円+12曲なら細々した文句を言うのはお門違いかもしれん。インスト曲は割と気に入ったし複雑な操作は皆無なので、時間のかかるテストの待ち時間に起動するなどのちょっとした暇つぶしには非常に向いてる。その目的で購入したので結構満足。

ちょっとCatyに関するメモ書きを二つほど。

2012-03-23 †

留年制度は効率的で効果的か？

十分に義務教育の内容を修めていない生徒を進級させ続けた結果を考えると留年制度はありなんじゃないかと思っていたが、こうして「学力向上には効果なし、むしろ逆効果の事もある」というデータが出てたのか。つまりダメだったと。

低学力の児童の問題が貧困問題に結びついているだろうというのは実際そうなのだろうから、そういう学校外での教育が不十分になりがちな家庭があるので学校側が特別補講などで介入しましょうというのは納得できる案である。

2012-03-24 †

The Sleeping City

前にまともな曲を書いたのが元旦だから、三ヶ月弱ぶりぐらいか。今回はミッドテンポで重低音リフをひたすらリピートするインダストリアルメタルを書いてみた。こうして聴いてみるとリードギターにちと不満があるんで、あとで差し替えるかもしれないし、面倒くさがってこのままかもしれない。

あとこれのベースパートを録音しようとしたらネックが洒落にならないぐらい反っている上にトラスロッドが回りきっているのが発覚、急いでベースパートだけ録音して休ませた。しかし流石に中古で買っただけあって購入当初から怪しかったが、ついにかなりヤバい状態になったようだ。

2012-03-26 †

CatyScriptのレイフィケーションができるようになった。

以下のようなコマンドに対して:

command hello :: void -> string {
 "Hello" | text:toupper
};

以下のようなレイフィケーションイメージを得ることができる。

caty:root> inspect:reify-cmd foo:hello
@command @_script {
    "exception": [],
    "resource": [],
    "name": "hello",
    "script": @_pipe [
        @_scalar "Hello",
        @_call {
            "typeArgs": [],
            "args": [],
            "pos": [
                11,
                5
            ],
            "opts": [],
            "name": "text:toupper"
        }
    ],
    "docstring": "undocumented",
    "profiles": [
        {
            "input": @_scalar {
                "typeArgs": [],
                "options": {},
                "name": "void"
            },
            "output": @_scalar {
                "typeArgs": [],
                "options": {},
                "name": "string"
            }
        }
    ],
    "typeParams": [],
    "annotation": @annotation []
}

今のところまだ実装していないが、このレイフィケーションイメージからコマンドを再現できるようになれば、scriptプロパティを弄ることでかなり強力な処理が書ける。例えば次のコマンドは、任意のCatyScriptのレイフィケーションイメージに対して、コマンド呼び出しの直前に入力値のダンプを仕込んだレイフィケーションイメージを生成する。

command wrap :: inspect:ReifiedScript -> inspect:ReifiedScript {
    case {
        inspect:RPipe | inspect:RDiscard => untagged |
                                            [item 0 | call foo:wrap, item 1 | call foo:wrap] |
                                            ["_pipe", pass] | tagged,
        inspect:RCommandCall => [cmdcall "debug:dump" , pass] | ["_pipe", pass] | tagged,
        * => pass,
    }
};

command cmdcall [string cmdname] :: void -> inspect:RCommandCall {
    @_call {
        "name": %0,
        "opts": [],
        "args": [],
        "typeArgs": [],
        "pos": [0, 0]
    }
};

結構処理は重くなりそうなのが気になる所だが、デバッグなどの開発時にポテンシャルを発揮するタイプの機能だからまあいいだろう。

後は例外関連の各種機能と、ちょっとしたデバッグ用のコマンドを組み込めばCatyScriptだけでデバッガらしきものが書けるようになるかな。

ドーパミックスはノーマル全部AにしてハードモードをC評価とはいえクリアしたが、ハードは致命的に面白くなかったな。メロディとリズムの切り替えがわかりにくい、ノートの軌道の関係上何分音符なのかさっぱり、ノートが等速で飛んでこない上にサイトに完全に収まってもサイトの色が変わらないうちはDOPA判定にならない、押しっぱなしのノートのSEが一瞬途切れるので不自然などというのはノーマル同様だが、ハードはさらに鬼畜譜面という問題が。

とりあえずクリアだけが目的の攻略っぽいものを。

ドーパミックスモード発動で一定時間はミスがそもそもなくなる。シューティングの決めボムのように使えばかなり楽になるので、苦手なパートまで取っておくのも手。(この辺シューティング作ってるガルチらしい)
ノートを逃す以外でミスにならず、空打ちし放題で、コンボが途切れるがミスにならないbreakの判定が広め。いざとなったらボタン連打でスコアはともかくやり過ごせる。
十字キーとABXYボタン全部の機能が同じ。連打系は十字キーをグリグリして誤魔化せることもある。十字キーとボタンの交互連打ができるといいかも。
まず目押し不能のハードの中でもトップクラスに目押しがやりにくい“Utopian Toybox”は、実は序盤以外にスネークプチ(押しっぱなし)が出現しない。なので序盤のスネーク以降はずっと連打でクリアだけなら可能。他にも“Chaos Float”, “Parade”, “Blue Place”などスネークが少ない曲はそこだけ真面目にやってあとは連打とドーパミックス発動で、評価気にせずクリアだけなら簡単。とりあえず先の曲の譜面を見たいときにでも。
A評価狙いなら曲を覚えないとダメだが、そもそも演出の関係やドーパミックスモード時のSEの遅れでそれが異常に難しい。

まあ、曲を聴きつつ時間潰すならノーマルで必要にして充分だから別にいいや。でもこんな面白くないハード付けるぐらいならエンディング曲のステージがあっても良かったな。せっかくドーパミックスモードが「どこで発動してスコアを稼ぐか、あるいは苦手パート用の保険にするか」という攻略性に繋がっているのに勿体ない。というか音ゲーあんまやらない俺が楽しめた要因は、このドーパミックスモードにあるだろうからなあ。

2012-03-31 †

終わるSIerの底辺を見てきた

俺が前に書いた「デスマーチを何とかしてしまう」「それが常態化してしまう」の例。というか俺の経験した炎上案件に似ているところが結構ある。テストのエビデンスとか、多少違うけど近い厳しさがあった。あの時うつ病で退職した人たちはきちんと治療できたのかなあ。

それで上記の記事の書き手や奮闘した関係者を責めるつもりは無いという断りを入れた上であえて書くと、「炎上案件であっても、利益をプラスに収めた経験を何度となく持つ百戦錬磨の男」みたいな人は確かに現場の人間として優秀だしそういう事態においては頼もしいが、だからこそデスマーチ案件でも利益が出てしまうし、成功した案件は事後検証が疎かになりがちなので、問題点が解決されないままというのは否定しきれないだろう。

あくまで俺個人の考えだが、酷い案件でも成功させて終わらせて周囲を見返すという発想は、勘違いに満ちた成功体験を生み出すというリスクを孕んでいる以上、極めて危険な考えであると言わざるを得ない。例えば上記の記事では厳しすぎるテストのエビデンスを提案した人がその百戦錬磨のリーダーという噂があったと書いてあるが、別にそのリーダーでなくとも過去のどうにかなった炎上案件から過ちを成功体験としてしまった人がいた場合、そこでのやり方を元にしてしまったという可能性はゼロではないだろう。成功体験ほど厄介なものはない。

かつて俺が経験したある炎上案件では最終的に損害を被り、その結果として俺のいた会社の経営層は炎上案件の回避のための教訓を幾つか得たようではあった。一方で利益が出たので炎上上等、多重下請けの下の方上等でやってる所では、ついぞそのような話は聞かなかった。短いスパンで見た会社の利益という点では成功した方が勿論いいが、いずれ現場の疲弊は限界に達するだろうし、その時にどうなるかは改めて書くまでもないだろう。