ゲーム開発に関わるいろんなこと
今日のお昼は、浅草橋のカレー屋の中では比較的気に入っているカレーの王様。CoCo 壱よりボクは好きである。前も書いたと思うけど、ここのカレーで一番好きなのが、牛タンカレーである。750 円。
中にゴロゴロと牛タンが入っているのだ。
これの辛口を頼むのが、ボクの定番である。
で、オニオンフライとらっきょうは有料なんだけど、いつも無料券をくれるので、結局この二つは無料でつけてもらっている。
夜警の写真はとあるビルから見下ろした浅草橋駅。このアングルから見られることってあんまりないなぁと思って、撮ってしまった。今日は会社の忘年会があり、その会場がこうして浅草橋を見下ろせる場所だったのである。
忘年会も終わり、今日で仕事納めなんだけど、ボクが関わっているプロジェクトはこのあと大晦日イベント、新年イベント、お年玉イベントとイベントが目白押しで正月休みはなさそうだ。
勤め先の会社は三つの開発室があるんだけど、それらのネットワークを管理している。で、そのうちの一つの開発室で利用しているプロバイダから、どうも大量の不正パケットが流れた形跡があると連絡をよこしてきた。
ログをみたら、一目超然、DNS amp 攻撃だった。
ぎゃーす！ そういえば、DNS の設定ってどうなってたんだっけ？＜ヲイ
って色々調べたら、amatsukami.jp サーバもオープン リゾルバになっていた……orz
皆さんがウェブサイトを閲覧するとき、そのサイトを運営しているサーバに正しくアクセスするためには DNS という仕組みが不可欠である。インターネット上のサーバはすべて一意の重複することのない番号（IP アドレス）が割り振られていて、この IP アドレスはグローバル IP アドレスと言って、インターネット内で重複しないように割り振られている。例えば今あなたが見ている TAMA Networks を提供しているサーバのグローバル IP アドレスは 210.136.205.247 であり、これは世界に一つしかない IP アドレスである。この番号を他の誰かが使うことはない。
でもこの 210.136.205.247 という数字を使ってデータをやりとるするのは非常に非効率だ。この数字は将来的に変わるかもしれないし、この IP アドレスで提供されるサービスは一つに限ったことではない（FTP、メールなど）。
そこで、この数字と抽象的な名前（○○.co.jp とかのことで、これをドメイン名という）を関連づけることによって、柔軟なアクセスを提供するのが DNS という仕組みだ。たとえば、TAMA Networks のブックマークをブラウザで呼び出すと、ブラウザは amatsukami.jp にアクセスしようとする。ブラウザはまず DNS を提供しているサーバに「amatsukami.jp は何番でっしゃろ？」と問い合わせに行くのだ。すると、DNS サーバが「210.136.205.247 でんがな」と答えてくるので、ブラウザはその DNS から答えられた番号の振られているコンピュータ（サーバ）にアクセスしに行くのである。
これはなにも amatsukami.jp に限ったことではなく、世の様々なサーバ（sony.co.jp とか honda.co.jp とか）すべてがこの方法でアクセスしたいサーバを求めており、これを名前解決と言い、このような DNS サーバを「フルサービス・リゾルバ」という。
ではどのフルサービス リゾルバ DNS にアクセスしに行くのかというと、それは各プロバイダが提供している。他にも Google なんかが自由に使える DNS サーバを用意してくれたりしているし、自分で設定することも出来る。
また会社では会社で建てたフルサービス リゾルバ DNS サーバがその役を担い、ウチの会社もそうなっている。
さて、では DNS サーバというのは全世界中の IP アドレスと名前の情報を持っているのかというと、そう言うワケではない。DNS サーバは例えば「amatsukami.jp は何番よ？」と問い合わされたら過去に同じ問い合わせがないかをまず調べる（キャッシュ）。なければ、.jp を管理している DNS サーバに問い合わせに行く。すると .jp を管理している DNS サーバは「amatsukami.jp なら 210.136.205.247 っていうサーバが詳しいことを知ってるぜ」と返してくるので、210.136.205.247 に問い合わせに行くと、210.136.205.247 の DNS サーバ（つまりボクのサーバ）が amatsukami.jp に関する様々な名前と数字の対応を返すのである。このようにフルサービス リゾルバは、次々とより上の DNS サーバに問い合わせていくようになっていて、これを再帰呼び出しと言う。
amatsukami.jp に関する様々な名前というのは、例えば ftp.amatsukami.jp や www.amatsukami.jp など、amatsukami.jp がつく様々な名前である。ここで初めて、amatsukami.jp も 210.136.205.247 だとって返ってくるので、これを問い合わせしに来た機械に渡すのである。
この時、この「問い合わせをしに来た機械を詐称」することができる。
つまり本来は、A というコンピュータが「amatsukami.jp は何番よ？」って聞いてきたら、その結果を A に返すはずなのだが、ここを B というコンピュータに返せとすることが出来てしまうのである。
こうすることによって DNS サーバは B に答えを送ってしまうどころか、本来定義されていない情報を問い合わせる（この問い合わせ内容が、普通の DNS 問い合わせより遙かに情報量が多いように細工されている）ことによって、DNS サーバはコンピュータ B の回線をパンクさせてしまうのだ（実際には何万台という乗っ取られたパソコンをつかって、DNS サーバにこのような攻撃を行う）。
そのためフルサービス リゾルバは、インターネットの誰からでも受けてはいけないように設定しなければならない。そもそもこの名前解決の問い合わせは各プロバイダが提供しているのであって、わざわざ他人のサーバに問い合わせる必要などない。従ってウチも社内でのみ、このサービスは提供すべきなのである。
ではなぜそれがインターネット全体にも提供していたのか？
それは上の説明にも出てきた「amatsukami.jp なら 210.136.205.247 っていうサーバが詳しいことを知ってるぜ」という部分である。ボクのサーバは全インターネットに向けて、amatsukami.jp に関してのみ責任を持って名前解決をしなければならない（こういう DNS サーバをコンテンツ サーバという）。
amatsukami.jp のついたものに関しては、ボクのサーバだけが真実を知っているのである（実際には真実を知っているサーバを定義することが出来るが）。
そして Microsoft の DNS サーバは、フルサービス リゾルバとコンテンツ サーバを分離出来ない。もし分離したかったら、フルサービス リゾルバ用の DNS と、コンテンツ サーバ用の DNS をそれぞれ別に立てないといけないんですな（ちなみに UNIX の世界で使われている BIND という DNS のプログラムは、この二つの機能を分離出来る）。
まぁ、Windows でも BIND 使うべきなのかもしれないけどね……。
で、とりあえず会社の方はコンテンツ サーバとしての役割を他の外向けサーバに移し、ルータ側で DNS の外部ポートを閉じた。
一方の amatsukami.jp は LAN 内の Active Directory を提供しているマシンにフルサービス リゾルバを設定し、SMTP（メール）のゲートウェイをしているサーバに新たに DNS をインストールし、そちらでコンテンツ サーバとして設定した。これで amatsukami.jp サーバがオープン リゾルバではなくなった。
あー、説明が長かった……orz
ちゃんと正しく説明できているかなぁ……。
以下のようなニュースを見た。マニアにはなかなかたまらない一品じゃなかろうか？
こういうのって時々見るんだけど、おおっぴらにやってるのはあまり見ない。座席だけと言わず、酸素マスクとか、非常扉のコックとか、シートベルトをお閉めくださいのパネルとか、コックピットの計器の一部とか（メーターとか？）、マニアがほしがりそうなものは沢山ありそうなのにね。
解体費用がまかなえるぐらい、売上げが立つんじゃないかしら？
どうせスクラップになるのなら、の話だけど。
航空機の場合、おおっぴらに売らない理由はいくつか思い浮かぶけど（再利用率が高いとか、痛み方の研究に役立つとか、まだ機密なところがあるとか）、飛行機に限らず、電車や車、船、クレーンなどの重機などなど、スクラップになるもののウチ、形として取っておけるものはもっとオークションとかしたらいいんじゃないかなぁ？
というのもね、エロゲ会社でもけっこういろんなものが処分されるのよ。例えば色校。印刷会社から「こんな色で上がってきます」ってサンプルがあがってくるのね。こういうの、結局プロジェクトが終わったら捨てちゃう。
抱き枕カバーの色校なんかは本物の生地に印刷されたものを持ってくる（抱き枕カバーのように閉じられておらず、裏と表が一枚の布になってるけど）。
他にも台本。これもみかん段ボール箱に何箱もあるんだけど、全部捨てる。
あとは社員のみんなで話し合ったキャラデザの紙とか。色んなキャラデザや色が載せてあって、あーでもないこーでもないとやったもの。
失敗したグッズ類（色が間違えていたり、傷がついていたり）。
落丁本。
CG さんや原画家さんの落書き。
余ったグッズ類。
まー、他にも色々。数年もエロゲ会社やってると、こういうので倉庫がいっぱいになってしまい、結局捨てる。
でもどうせ捨てるなら、発売して 1 年経ったものとかはユーザさんにあげたりプレゼントしたりしていいんじゃないかなぁと思う。もちろん、ユーザさんが欲しがるのかどうかはボクも解らないけど……ムリヤリあげるんじゃなくて、欲しい人をサイトやイベントで募れば欲しい人はいるんじゃないかなぁ？
ボクの同人用のサイトというのは別にあって、そちらで制作物の紹介やイベント参加の告知なんかをやってるのだけど、こちらではその裏方的な話を紹介してみたいと思う。
とりあえず同人ソフトの方は、その制作資金を貯め中で、100 万円を目指している。
プレスするかどうかは悩んでいて、HTML5 で作ろうかと思い始めている。
一番直近に出せそうなのは小説で、『OZ Meets OZ !』というタイトル。
こちらは 2013 年にほぼ書き終わっていて、戦闘シーンだけ残っていた。絵そのものは、2014 年 5 月 18 日に発注。
ただこのあとボクが精神的に壊れたりなんだりして、戦闘シーンが書き終わったのは 9/29 だった。
戦闘シーンはたった 9KiB。文字数にして約 4600 文字。たったこれを書くために 9 ヶ月……そうとうまいっていたと思われる。
そして 12/21、表紙絵が FIX したので Twitter で告知となった。
本来は 11 月の文学フリマに出したかったのだが、それは結局かなわなかった。
今回は戦闘シーンが残っていたとは言え、基本的に文章を書き上がってから挿絵を発注するという形式をとっていて、今後もそのスタンスで行きたいなぁと思っている。
ところで表紙絵はソファの柄が二種類有った。最初赤で上がってきたのだが、原画家さんが白のバージョンも上げてきていただき、最終的に白に落ち着いた。ブログでは赤が使われている(^^;
今やっているスマフォの案件でデバッグが始まった。
作りはじめてまだ一ヶ月半だけど（笑）。
まぁ、サービス インはクリスマスなので（ぁ
いやー、よくまぁ、この短い時間でやったもんだと思いつつ……ネトゲっていいよね、後からいくらでも補修効くから。エロゲーもそうなって欲しいわ～。
でね、クライアントさんはバグ報告に Redmine を使ってるのよ。
これがもー使いにくいのなんのって。
Redmine ってのは確かにバグ報告的な機能もあるんだけど、もともとはプロジェクト管理システムであって、タスク毎のスケジュールとかどのタスクがどれくらい進んでいるかとかを管理できる。
それの応用で、そのタスクを一つのバグとして扱い、スケジュールが修正の度合い（確認、対応中、対応済み、確認済み、終了）に対応している。
で、バグ報告を受ける立場のボクとしては、どのバグがどの状態（ステータス）なのかを知りたかったりする。例えば、ボクに確認を求められているバグはいくつで、ボクが対応中のモノはいくつで、対応済みはどれだ……みたいな感じ。
ところが Redmine はこれらのステータスを一発で見ることができない。
BTS というバグ管理に特化したシステムだと、対応中を一操作で表示できるし、対応中以降のバグすべても簡単に表示できる。が Redmine だとソート条件を各状態ごとに追加して、さらに担当者がボクという条件も追加しないと見られない。
他の状態を見たいときは、せっかく設定したソート条件をいったん外して、また別のソート条件を追加しないといけない……。
うがー！！
素直に BTS 使おうよ……orz
まぁ、Redmine に BTS プラグインとかあるのかもしれないけどね。
というわけで、バグ対応がめんどくさいんじゃ、このクソがっていうお話。
あと関係ないけど、東京は今冬、初雪だったそうな。都心部でも降ったらしい。
今日はウェブ上でのエフェクトのお話。
今回ボクが担当しているプロジェクトは期間が短いこともあり、余り凝ったことがやれない。とはいえゲームなので演出は派手に越したことはない。
そこで考えたのが、Adobe Flash で作ったものをそのままウェブ上で再生すること。実は以前にも別のプロジェクトでアバターのアニメーションなんかを Flash でやってたりするので、今回もそれで行こうと思ったのだ。
ん？ スマフォで Flash なんて再生できないって？
Adobe Flash CC は作ったアニメーションなんかを HTML5 にコンバートできるのだ。
なのでできあがった HTML5 をあとは再生するだけ……！
って思ったんだけど、HTML5 化されるのはエフェクトやアニメーション部分だけなのね……orz
Flash の中で変数を使ったり、条件分岐したりしてるんだけど、それらは全部無視されるみたい。
で、結局どうしたかというと、その部分は Javascript で書いた。
Flash でコンバートされた HTML5 は CreativeJS というのが使われていて、この CreativeJS というのは元 Flash のプログラマが作ったようだ。なので、Flash で利用される様々なエフェクトは CreativeJS の中に関数として用意してあって、ほぼ同じように再現できるらしい。
まだ完全にファイルの構成を理解出来たわけではないのだけど、一応、Flash から HTML5 にコンバートされた Javascript を色々と制御できるようにはなった。
写真は今日食べたもの。かくやという立ち食いソバ屋。けっこう気に入っている。
今回はレスポンシブ ウェブ デザインの話。レスポンシブ ウェブ デザインって何かっていうと、一つのデザインですべてのプラットフォームとブラウザに対応することである。つまり PC でアクセスしてもスマフォでアクセスしても、同じデザインで出力される……というわけではなくて、一つのデザインしか定義してないんだけどそれで PC でもスマフォでもちゃんと表示されることである。
今やっているスマフォのゲームも最初、レスポンシブ デザインで作っていた。
このレスポンシブ デザインの肝は簡単に言ってしまえば％で作ると言うことである（ぁ
どういうことかというと、例えば 2 段組をするとき、全体幅が 1024 ドット、左側がメイン コンテンツで 640 ドット、右側がメニューとかで 384 ドットにしよう……ってのが今までの作り方。
レスポンシブ ウェブの場合は、全体幅は 100% で作り、本文左側は 62.5%、メニューとかの右側は 37.5% にしようってこと。そうすればどんな機器だろうが割合で区切られるので、それらの機器に従った大きさになる。
これはレイアウトだけでなく、画像の大きさに至るまで何もかも％で指定する。
ところが、この作り方には二つの欠点がある。
ブロック要素や画像などは画面の大きさに従って勝手に変わってくれるのだが、文字の大きさはそれに追随してくれない。なので細かいディスプレイに出しても、荒いディスプレイに出しても同じ大きさ（ドット）で表示されてしまうため、要素の中に表示される文字数が変わってしまい、結局レイアウトが乱れる。
これはディスプレイの画素数と CSS ピクセル比ごとに文字の大きさを定義しておく必要がある。
さらにゲームではインターフェースに凝るため、ドット単位でのボタンやゲージ（メーターやプログレス バー）などの表示が必要となる。ブラウザは小数点第三位くらいまでの％値しか見てくれず、ドット単位での微調整はできない。これの回避方法は、ドット単位で組んだあと、Javascript や CSS の ZOOM を使って最適な大きさに表示するのだが、iOS の Safari などでバグが発生し使えないことが多い。これに関しては、まだボクの中では特に解決策は見いだせていない。
今回はドット単位で調整が必要なところは、合成した画像を変化する種類分作って対応するというわりと原始的な方法で回避した(^^; どういうことかというと、下地があってその上にボタンをドット単位で並べなければいけないような場合、下地とドット単位で並べたボタンを合成してしまい、どのボタンが光っているかというパターン分の画像を用意することによって、ドット単位での調整をしなくて良いようにした。ただこの方法は、パターンが膨大にある場合は使えない……。
まぁ、一番いいのは Javascript の ZOOM である。コイツさえ正常に動いてくれれば、レスポンシブ デザインは一気に楽になる。何故かというと、ドット単位で自由に作れるからだ。従来の作り方のように、例えば全体幅を 1024 ドットとか 640 ドットとかと固定して自由にレイアウトした後に、Javascript で機器のディスプレイの大きさに合わせて拡縮するようにすれば楽ちんなのである（爆。
他にも Table を使うのが難しかったり、横幅を必要とするモノがどうしてもスマフォなどだレイアウトが崩れてしまったりなど、一つのデザインで様々な機器に対応するのは一筋縄では行かない。TAMA Networks も燃費なんかの表の部分や、説明付きの画像の場合はスマフォで見ると崩れてしまう。
この辺、何とかしたいなぁと思いつつ……。
写真はこの日食べたもの。バーガーキングのブルーベリーのハンバーガーと、秋葉原の万豚記。
