同人の裏側の話『OZ Meets OZ !』

ボクの同人用のサイトというのは別にあって、そちらで制作物の紹介やイベント参加の告知なんかをやってるのだけど、こちらではその裏方的な話を紹介してみたいと思う。

とりあえず同人ソフトの方は、その制作資金を貯め中で、100 万円を目指している。
プレスするかどうかは悩んでいて、HTML5 で作ろうかと思い始めている。

一番直近に出せそうなのは小説で、『OZ Meets OZ !』というタイトル。
こちらは 2013 年にほぼ書き終わっていて、戦闘シーンだけ残っていた。絵そのものは、2014 年 5 月 18 日に発注。
ただこのあとボクが精神的に壊れたりなんだりして、戦闘シーンが書き終わったのは 9/29 だった。
戦闘シーンはたった 9KiB。文字数にして約 4600 文字。たったこれを書くために 9 ヶ月……そうとうまいっていたと思われる。

そして 12/21、表紙絵が FIX したので Twitter で告知となった。
本来は 11 月の文学フリマに出したかったのだが、それは結局かなわなかった。

今回は戦闘シーンが残っていたとは言え、基本的に文章を書き上がってから挿絵を発注するという形式をとっていて、今後もそのスタンスで行きたいなぁと思っている。

ところで表紙絵はソファの柄が二種類有った。最初赤で上がってきたのだが、原画家さんが白のバージョンも上げてきていただき、最終的に白に落ち着いた。ブログでは赤が使われている(^^;

ill01_tex_white ill01_tex_rose

Redmine を BTS に使うのはどうかと思う

今やっているスマフォの案件でデバッグが始まった。
作りはじめてまだ一ヶ月半だけど(笑)。
まぁ、サービス インはクリスマスなので(ぁ
いやー、よくまぁ、この短い時間でやったもんだと思いつつ……ネトゲっていいよね、後からいくらでも補修効くから。エロゲーもそうなって欲しいわ~。

でね、クライアントさんはバグ報告に Redmine を使ってるのよ。
これがもー使いにくいのなんのって。
Redmine ってのは確かにバグ報告的な機能もあるんだけど、もともとはプロジェクト管理システムであって、タスク毎のスケジュールとかどのタスクがどれくらい進んでいるかとかを管理できる。
それの応用で、そのタスクを一つのバグとして扱い、スケジュールが修正の度合い(確認、対応中、対応済み、確認済み、終了)に対応している。

で、バグ報告を受ける立場のボクとしては、どのバグがどの状態(ステータス)なのかを知りたかったりする。例えば、ボクに確認を求められているバグはいくつで、ボクが対応中のモノはいくつで、対応済みはどれだ……みたいな感じ。
ところが Redmine はこれらのステータスを一発で見ることができない。
BTS というバグ管理に特化したシステムだと、対応中を一操作で表示できるし、対応中以降のバグすべても簡単に表示できる。が Redmine だとソート条件を各状態ごとに追加して、さらに担当者がボクという条件も追加しないと見られない。
他の状態を見たいときは、せっかく設定したソート条件をいったん外して、また別のソート条件を追加しないといけない……。

うがー!!

素直に BTS 使おうよ……orz
まぁ、Redmine に BTS プラグインとかあるのかもしれないけどね。

というわけで、バグ対応がめんどくさいんじゃ、このクソがっていうお話。

あと関係ないけど、東京は今冬、初雪だったそうな。都心部でも降ったらしい。

CreativeJS と Flash

今日はウェブ上でのエフェクトのお話。
今回ボクが担当しているプロジェクトは期間が短いこともあり、余り凝ったことがやれない。とはいえゲームなので演出は派手に越したことはない。
そこで考えたのが、Adobe Flash で作ったものをそのままウェブ上で再生すること。実は以前にも別のプロジェクトでアバターのアニメーションなんかを Flash でやってたりするので、今回もそれで行こうと思ったのだ。

ん? スマフォで Flash なんて再生できないって?

Adobe Flash CC は作ったアニメーションなんかを HTML5 にコンバートできるのだ。
なのでできあがった HTML5 をあとは再生するだけ……!
って思ったんだけど、HTML5 化されるのはエフェクトやアニメーション部分だけなのね……orz
Flash の中で変数を使ったり、条件分岐したりしてるんだけど、それらは全部無視されるみたい。
で、結局どうしたかというと、その部分は Javascript で書いた。

Flash でコンバートされた HTML5 は CreativeJS というのが使われていて、この CreativeJS というのは元 Flash のプログラマが作ったようだ。なので、Flash で利用される様々なエフェクトは CreativeJS の中に関数として用意してあって、ほぼ同じように再現できるらしい。

まだ完全にファイルの構成を理解出来たわけではないのだけど、一応、Flash から HTML5 にコンバートされた Javascript を色々と制御できるようにはなった。
写真は今日食べたもの。かくやという立ち食いソバ屋。けっこう気に入っている。

1412090757 1412090758 1412090760 1412090762

レスポンシブ デザインのめんどくささ

今回はレスポンシブ ウェブ デザインの話。レスポンシブ ウェブ デザインって何かっていうと、一つのデザインですべてのプラットフォームとブラウザに対応することである。つまり 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 も燃費なんかの表の部分や、説明付きの画像の場合はスマフォで見ると崩れてしまう。
この辺、何とかしたいなぁと思いつつ……。
写真はこの日食べたもの。バーガーキングのブルーベリーのハンバーガーと、秋葉原の万豚記。

1412080730 1412080731 1412080737 1412080740 1412080741 1412080747

Webkit オンリーで組んでも……

スマフォの開発を相変わらずしているんだけど、今回の案件は別に PC で動作する必要はない。で、スマフォというと iOSAndroid が主流で、他のプラットフォームに関しては、ほぼ無視して良い(ゲームの場合の話ね)。となると、ボクが思ったのは「じゃぁ、Webkit に対応して作ればいっか」であった。
iOS に搭載されている Safari も、Android の Chrome も Webkit というレンダリング エンジンで作られているからだ(Chrome は Webkit からさらにフォークして Blink となった)。

ところが、けっこう iOS と Android で表示が違うんですな。
更に困ったのが Android の標準ブラウザ。
実は Android に最初からついてくるブラウザというのは Google Chrome ではない。なんでなのかというと、これはボクの予想でしかないのだが、Android デビューに Chrome は間に合わなかったからだと思われる。ちなみにエンジンは Webkit である。
Android 版の Chrome は Android のバージョンが 2.3 だか 2.4 だかくらいにようやくデビューした。なので Android には「標準ブラウザ」という、別のブラウザがずっとついてきている(Android 4.4 でようやく標準ブラウザが Chrome となった)。

この標準ブラウザがとにかくタコい。
まず Javascript の実行速度が圧倒的に遅い。そして HTML5 からついた修飾(ぼかしや縁取り、グラデーション)などの再現率が低い。特にぼかしがおかしい。

次に Safari。コイツのフォント処理はおかしい。とにかく文字の大きさが合わない。
なんだこれー!?
しかもバグがあって、Javascript で拡縮をやると正しい大きさにならないという……orz(CSS でも ZOOM を使うと同じ症状が出るらしい)
これが実に問題で、先の記事の CSS ピクセル問題で、CSS を書き直しせず、Javascript で最適な大きさに拡縮するという風に逃げたのだが、この Safari のバグのおかげで結局この方法は使えなくなってしまい、CSS を全面書き直さなければならなくなった。

だ、ダメすぎる……orz

だが今回、「ブラウザの場合分けはしない」というポリシーで組んでいる。これは別にボクの勝手なポリシーなんだけど。場合分けってのは何かっていうと、Safari だとこっちの処理、Chrome だとこっちの処理というようにブラウザことに処理をわけることだ。
CSS / HTML は一種類の定義ですべてのブラウザで通用するように書いた。まぁ、なんだかんだ言ってもレンダリング エンジンが一つだったというのが大きいだろう。これが PC だとこうは行かなかったと思う。

PC ばっかり相手にしてたから……

スマフォのゲームで HTML や CSS / Javascript 部分を担当しているわけだけれども、本格的にスマフォに合わせて作るのは初めてで、色々と勉強しながら作っている。その中でどうしてもうまく動かないのが VIEWPORT
これは昔、TAMA Network の CSS をいじっている時も試したことがあるんだけど、どうしてもボクの思うように動かない。なんでだろうなーってずっと疑問だった。で、今回も案の定、ボクの思ったとおりにならない。
ただ経験上、iPhone で見ると、VIEWPORT の設定がボクが想定しているよりも倍の大きさになっているように見えるのは知っていた。なんでこんな仕様なんだってずっと疑問だったのだが、それがそもそも仕様だったことに気付いておらず、その動作がサッパリ謎だった。

で、今日、改めて調べて CSS ピクセルってのを知る(ぁ
ボクは今までデバイス ピクセルで組んでいたのである。

CSS ピクセルが生まれたきっかけは、今のスマフォってすごいドットが細かい。そのドットのまま PC のサイトを表示させると、文字が小さくてサッパリ読めない。そこで、例えば iPhone 6 までの iPhone は CSS ピクセルが 2 に設定されている。これは、デバイス ピクセル 2 ドットで CSS ピクセル 1 ドットになる。
そうすることによって、iPhone 6 の画面は 1334 x 750 ドットあるのだが、ウェブを表示する際には 667 x 375 ドットになり、2 倍に拡大されて表示されるのだ。

この仕掛けを知ってようやく VIEWPORT の動作が理解出来たというか、思った通りになるようになったのだが……しかし、全てデバイス ピクセルで作ってしまった……。しかも、Javascript や HTML 上で指定するピクセル数は CSS / デバイスどっちになるんだろうか(デバイス ピクセルで動いているように見える)?
HTML 上で <style></style> 宣言した場合は、その中は CSS ピクセルだった(当然か)。

そんなワケで、CSS 部分はほとんど作り直しに……。
やっぱ PC だけのサイトしか作ってないと、全然ダメだね、というお話。

次回はブラウザ間の色々な違いに苦労した話を……。

所変われば…

bs_yasu01h
某出版社に行ってきた。とある児童書をデジタルな何かで表現したいというすごい漠然とした要求があり、とりあえず話を聞いてみようというということで行ったのである。
出版業界とゲーム業界の違いが色々あって面白かったのだが、出版社も色々とデジタルの世界については模索しているようだった。ただ知識がない、情報がないため、彼らの中に描いているものがいくらかかって、どれくらいの期間が必要なのかと言ったことが解らずに、手をこまねいている状態のようだ。

なるほど、この業界に入ったら色々面白いことできそうじゃない。
とは、ちょっと思った。まぁ、角川さんとかはもうそんなことはない気がするけど……。

で、面白かったのが児童書は学校の図書館が使えること。
なるほど、と思った。
要するに卸先が本屋さんだけではなく、全国の小中学校にも卸せると言うこと。そしてそれだけでかなりの部数が稼げると言うこと。なるほどなぁ。で、営業マンは書店だけじゃなくて学校も回ってるそうな。

ところで、小学校で図書館を利用するのは圧倒的に女子。男子は 2 割以下とのこと。なので、女子受けする内容が好まれるらしい。へー。確かにボクが子どもの頃も、男で宿題や授業以外で本を読んでるヤツってほとんどいなかったなー。
でも成績上位の男の子は確かによく本を読んでいたのを憶えている。

写真は仕事帰りに寄ったすた丼。やっぱ 10 代 20 代の食べ物だなぁ……。
1411064133