Sonscripter作業

今日は思うところがあってsidebookが運営するSonscripterの改修をすることにした。
とりあえずストアは標準でコンテンツが新着順で並ぶようにした。サーバー側の改修なので
特にアップデートしなくても新着順に表示されるはず。

今後アプリ側もアップデートして新着順、DL数順、高評価順
で表示できるようにする予定。
サーバー側の改修を担当するので今日はSidenovel開発が滞るはず。

ほぼ復帰完了

javascriptでごりごりやってたのをやめて大幅に書き直した。
ほぼ大幅改修前までの状況に戻った。。

改修のおかげでIEでも結構まともに表示できている。
ふーーー。

と思ったらChromeで人物が表示されてないとか。まじっすか。
Chromeは一番信頼してたのに～。でもまあChromeなら簡単に直せるはず。

あーー、わかった。なるほどね。そうだったiframeに変えてたから。。。


メモ:
画像のプリフェッチが完了したあとに解像度変えられると
その画像を表示するときのアスペクト比がおかしくなるっぽい。

背景のプリフェッチ忘れてるのでやるようにする。

スペースキー押しっぱなしにしとくて音が鳴らなくなる模様@firefox mac

大幅変更

今の実装があまりにも邪道ということに昨日気づいた。
埋め込みタグの実現するためにJavascriptでレイアウトまでゴリゴリやってしまっている。
iframeタグの存在と動的にcssを変更できることを知らなかったのでJavascriptでゴリ押ししていた。
もっと早くにせめてiframeの存在に気づいていれば・・・。


おそらくjavascriptでやっていたレイアウトの部分をcssに持っていけばIEでも
もっとまともに動くと思う。

今から実装を大幅に変更しようと思う。。。。モチベーションがかなり下がるけど
やるしかない。

IEがあまりにも・・・

今までIEでの動作を放置していたので
IEで正常に動作できるよう作業中。これがもうホント大変で大変でIEだけいろいろおかしい。。。
javascriptが期待通り動かない。IEだけあまりにもやっかいだ。

あと、背景もプリフェッチしないとまずいな

閲覧数とプレイ回数

閲覧数はそのページが何回表示されたかを表す。
プレイ回数は実際にゲームを開始した回数を表す。
なのでプレイ回数は埋め込みtagでばら撒かれた先で
プレイされた回数も含む。


閲覧数はサクッとphpで実装できるので問題ない。
ゲーム回指数はjavascriptでイベントをサーバー側に投げなきゃいけないので
どうしようか迷った。formからのpostだとpost先へ遷移してしまう。これはありえない。

そこでJQueryのpostを使うことにした。
参考
http://semooh.jp/jquery/api/ajax/jQuery.ajax/options/

うは、簡単すぎ。JQueryやばいな。便利すぎる。

iframe埋め込みタグ

iframeタグを使うことで埋め込みタグの量を大幅に短縮することができた。
以前の10分の1以下だ。

これで手軽にコピペできるだろう

バッチリ

ほぼ文字ウィンドウの実装が完了。
ただ改行のしかたがNscripterと違うのでコンバーターで完全に吸収するのは無理そうだ。

IS06かつwifiでテストやってるけど
パフォーマンスはもうほぼ問題ないな。まるで違和感やストレスがない。
人物絵の表示サイズがおかしい時があるけどこれはプリフェッチの後の処理がまずいのだろう。

あとは3G回線でやった時にどうなるかテストだなあ。

デモムービーみたいなの作りたいなあ。

スマホページ

スマホ用のページを別途用意することにした。
http://sonscripter.com/QuizTest/

にスマホでアクセスすると
http://sonscripter.com/QuizTest/mobile.htmlに
リダイレクトするようにした。
どうもあの編集用のjavascriptがかなりパフォーマンス低下の原因になっていたようだ。
スマホ用ページならAndroid, iphoneともに文字送り、アニメーションが滑らかに動く。

文字ウィンドウ

画像のプリフェッチ処理が完了した。
これで文字ウィンドウ絡み以外の残作業が人と通り終わったので
文字ウィンドウの実装に取り掛かる。

この機能がホント重要だと思ってる。その上で
一番難しいしめんどくさい機能と思われる。
作りこんでいくしかない。

音声のフェード

とりあえず音声をフェードアウトできるようにしてみたけど
ちょっとイマイチ滑らかじゃない。

人間がラグを感じるれる時間は0.1秒らしいけど、今回フェードするときの変化は
0.2秒刻みで変化するようにした。おそらくこの時点でなんとなく滑らかに変わってない
と感じてしまうものと思われる。でもまあ、意識しないとわからない程度かも。。。

タイマーで0.2秒計測してるのだけど、もちろんもっと短くできる。
ただ音量コントロールバーを実装したときに薄々気づいてたけど音量の変化が反映されるのが
遅い。なので0.2秒より早くするとどんどん音量が変わっていくので全然音量変化が反映されないまま
突然音が切れる、つまりフェードがかからなくなる。デバッガで毎回止めて実行すると
正しく音量値が書き換わってるし音量も変化しているのが確認できるが実際に実行するとダメ
なことから音量が反映されてないという結論が得られる。

もしかしたら環境によっては0.2秒でも早すぎるのかもしれない。一応マージンはとってあるので
大丈夫だとは思うが。。。。

html5のAudioはまだまだ発展途上なので今後改善されることに期待したい。。。。
てかAudioに標準でフェード機能を付けて欲しい。

解像度変更

紫電は800×600の解像度か400×300の解像度か選べるようにした。
スマホでプレイするには400×300でも全然問題ない。むしろアニメーションが滑らかになって
そちらの方がいい。

800×600の画面

400×300の画面
こんな感じ。
夏川先生登場。メガネっ娘キャラ担当w

アーカイブ化

紫電ではローカルでもプレイできることを想定している。
PCで普通のブラウザでローカルでプレイしてもらうためには絵、音声、テキストとかリソースを
丸出しにする必要がある。

おそらく丸出しになるのをいやがる制作者さんもけっこういると思う。
商業、同人で有料配布する時に紫電を選択肢からはずす大きな要因だと思う。

スマホの場合アプリといっしょにパッケージされるので丸出しにはならないから
現状でも問題にはならないはず。問題はPC向けだ。

今この件への対応策としては考えられるのは専用ブラウザを作ること。
webkitがオープンソースであるしもはやブラウザを自分で用意するのはかなり容易だ。
それに手を加えてアーカイブされた絵、音声、テキストを読み込めるようにすれば
よい。
で、そのexe形式の専用ブラウザとアーカイブを一緒にzip化して配布する。
ユーザーはzipの中のexeをダブルクリックすればプレイできるというわけだ。
どうせ専用ブラウザには大した機能いらないんだから2,3Mくらいの大きさにしかならないだろう。

クライアント側プログラミングなら得意とするところ、こういうところでアドバンテージを付けたい。

スペースキーでクリック

はじめはエンターキーをクリックとみなして
アクションを進めようと思ったけどif-engineがスペースキーだったので
スペースキーにしてしまった。。影響されすぎな感があるけど
確かにスペースキーの方が面積広いしエンターは他に要素がフォーカスしていると
それの実行に使われるかもしれないからからスペースキーが妥当と判断。

後々にはキーコンフィグみたいなもの入れるべきかも。

とりあえずver1.0はキー入力についてはスペースキーを押せば話が進むようになっただけでよしとする

追記：
このキー入力を受け取る処理を入れたらiphoneでまともにうごかなくなってしまった。
クリックを受け付けない。どうしてそうなってるのかはよくわからない。
どちらにしろUser Agent見てiphoneだったらこの処理を抜くようにする必要がある。

大幅なパフォーマンス改善

メインループのいろんなところで

obj[progress].hogehoge != "xxx"

みたいなことをやってたけど
これを

var tmpobj = obj[progress];

のように一旦ローカル変数に落として

tmpobj.hogehoge != "xxx"

とやるようにしたらなぜか劇的に文字送りのパフォーマンスが改善した。
これで改善するとは思えないんだけど・・・なんでだろう。
iphoneではまるでカクカクがなくなった。XOOMでもちょっとカクカクしているようだけど
ちゃんと1文字ずつ表示している。うーんjsはよくわからんなあ。
これは多いにパフォーマンスを改善できそうだ。てか、今までコーディングがいい加減すぎ。。。

文字送りの処理自体もかなりごり押しで現状やってるからちゃんとコーディングすれば
もっと文字送りのパフォーマンスが改善するはずその上でプリフェッチ&バッファリングを
すればかなりしょぼい性能のスマホでもカクカクしないんじゃないかと期待。

追記：
アニメーションのパフォーマンスも明らかに改善している。
うーーん、なんでそうなるかなあ。よくわからん。jitかなにかと関係してるのかな。。。。

困難な課題リスト

◎ほぼ絶望的
・youtubeとかニコ動みたいなホントにディスプレイ全体を覆う全画面モードを
用意したかったけどhtml5+jsじゃ無理だ。正確には現状のhtml5仕様とブラウザじゃ無理というとこか。
if-engineもデモ見る限りじゃPC向けではブラウザ内でしか動作していない。
ブラウザ内での全画面モードなるものがあるのでそれをもって全画面モードと呼ぶ。
スマホではUIWebViewとかWebViewのみ表示すればあたかも本当の全画面モードのようにはできる。

・音声はオーディオタグサポートしてない、してても音声に対応するコーデックがないブラウザでは
音声再生あきらめるしかない。flashで再生できるようにすることもできるようだけど
そうやって無理に互換性を高めようとするいろいろ問題がポロポロでてきて頓挫する要因になるので
やらない。html5の普及とともに解決される問題と予期する。

◎かなり困難
・スマホの方で文字送りのパフォーマンスがやばい。iphoneではちょっとカクカクしてる。
xoomではカクカクどころではなく１文字ずつ表示されず10文字とかが一気に表示される。
原因は全角文字がユニコードエスケープで保持されていて表示するときにいちいちUTF8コードに
デコードしてしていること。なんらか対策を打たないと非常にまずい。
ルビ対応もこれが解決しないことには検討してもしょうがない。

・ロード時間の問題
この問題はひとまとめにできるほど単純な問題ではない。
ロードするものや状況により問題の症状が多岐にわたるためまずは問題の全容を把握する必要がある。

・パフォーマンスの問題
Cycleプラグインのアニメーションがかなり重い。
スマホでは明らかにカクついている。if-engineもデモでiphone,ipadでアニメーションを
出していないが、滑らかに動くのかどうか非常に疑問。
余力があればCycleプラグインに手をいれることも検討。


追記
文字送りのパフォーマンス問題のひとつの解決策として
次にくる文字設置のアクションをプリフェッチしてあらかじめデコードしてバッファリングしておく。
わりとシンプルだけど有効だと思われる。

残作業リスト

◎エンジン
menuバーのjs化
解像度選択
フルスクリーン
音量バー
画面エフェクト時間指定
文字ウィンドウ文字数
文字ウィンドウ改ページ、クリック待ち
スペースキー入力をクリックとして扱う
ルビ調査
画像プリフェッチ
bgmフェードアウト
文字ウィンドウ表示・非表示切り替え

以下は継続的作業
メモリマネジメント
パフォーマンスチューニング
エラーハンドリング

◎エディタ
画面エフェクト時間指定


◎コンバータ
文字ウィンドウ改ページ、クリック待ち


こんな所かな。。。。。

ロウンチ戦略

とりあえずこのキミキメリメイクが完了したら
紫電をver1.0としようと思う。

なんらかif-engineみたいなデモ作ってああいう感じで世間に
話題をもたらせばかなり紫電に注目が集まるんじゃないかと思う。
そこへフリーのキミキメが用意されていれば
if-engineと違ってその時にはプレイできる状態になっているので多くの人が
プレイしてくれるんじゃないかと。

if-engineを大々的に取り上げてるのはスラドっぽいのであそこに
持ち込むのがよさげか・・・。

キミキメ紫電を置くページもちゃんとデザインしていかにもやりたくなるような
感じにしないとダメだな。

あとははぐらかす感じでNscirpterコンバータもありますと付け加える・・・ver 1.Xではスプライトに対応する気はまるでないが。

もちろん完成度をできる限り高めたいけどif-engineや他にhtml5+jsというコンセプト
のエンジンが出てくる前にリリースしたい。絵師さんの都合も考えると
1月までにはなんとかリリースしたいなあ。

画面効果について

画面エフェクトは
JQueryのCycle Pluginを使う事でほぼ確定

http://www.malsup.com/jquery/cycle/

Nスクのようにそれぞれの効果に以下のように番号を振ることにする

16 blindX
17 blindY
18 blindZ
19 cover
6 curtainX
7 curtainY
10 fade
20 fadeZoom
8 growX
9 growY
0 none
13 scrollUp
14 scrollDown
11 scrollLeft
12 scrollRight
21 scrollHorz
22 scrollVert
23 shuffle
24 slideX
25 slideY
26 toss
4 turnUp
5 turnDown
2 turnLeft
3 turnRight
15 uncover
27 wipe
1 zoom

アニメーションが終わるまで待つかどうか設定できた方が良い気がするけど
面倒だなあ。とりあえずは待たずにやろうかと思う。設定できないにしても待つべきだろうけど・・・。


追記：
またないとダメだ。アニメーションが完了するまえに他の絵を描画しようとするとレイアウトがおかしくなる。しかもアニメーションしがらテキスト表示とか重すぎ。。。。
これはアニメーションをまたなきゃダメだ。

Canvas

HTML5ではCanvaというもので画面への描画ができるらしい

http://www.html5.jp/canvas/

うわあ、ゲームではこれを使うべきなんだろうなあ。
でもこれを使うとIE8以下は全滅、IE9もたぶんダメなんだろうなあ。
今は見送るべきだろうな・・・。

使ってみたい。。。。

追記
http://www.html5.jp/canvas/
これを見ると、canvasで描画した絵は移動できないらしい。
どうも思っていたものと違うな。flash的なことができると思ったのに
でも、描画を繰り返してアニメーション的なのはできるかも

Tableの各行にformを入れる

結局javascriptで書き直すことにした。
どう考えてもjavascriptで書き直す方が妥当。
でもこういう手戻りはほんとテンション下がるというか。。。。
これでjsで作り直してまた困難な問題に直面したらもう戻るのもいやだし
そのまま続行するのも無理だしでどん詰まりだわな。

if-engineもこういうのが積み重なって頓挫してるのかも。
まずは機能をしぼって、コンセプトを外れない範囲で動作するもを
作るよう心がけないと。へたにあれもこれもってやるとだめだ。

Javascriptでテーブルの各行にform入れようとしたらダメだった。
html直打ちだといけるのに。。。。

そこでこれがいけそう。
http://federmanscripts.com/2010/01/12/form-and-table-row-nesting-workaround/

一個テーブル外にform作って各行のsubmitボタンが押されたら
そのテーブル外のformに押されたsubmitの行を突っ込む
で、サブミットするというわけだ。

追記
とりあえず上の方法で実装できた。やはり500行くらい一気に表示すると
かなり重い。しかもメモリ解放とかすっごい適当。
表示する行の範囲の切換えをやってるとだんだんPCが遅くなる。
たぶんメモリリークしていると思う。

スクショ2

ハマルキター。。
とりあえずテキスト、絵、bgm全てそろってるので
一応ゲームとしてプレイできるようになっている。
左下のセーブ、ロードボタンも一応機能はしている。

セーブ、ロードボタンの横のへんなのは音量のスライダー。
まともに実装されてないけど音量を変えれる。なんか反応鈍いしいろいろおかしいけど、
適当実装だから今はよしとする。

このハマルのネコミミ帽子の下がきになるひとはlet's playキミキメ！

Nscripter2Sidenovelコンバーター 超プロトタイプ

Nscripterの構造がなんとなくつかめたのでNscripter to 紫電コンバーターの
超プロトタイプ的なものを実装した。
いやあ、サクッといくかと思ったけどホントphpでのjsonの扱いで苦労してしまった
マルチバイト文字をいちいちユニコードシーケンスで保存するとか
こまるな。人間が見てもよくわからないし。。。。
おかげで改ページの特殊記号は¥にするつもりだったんだけど&にすることになってしまった。
Nscripterはバッサリ半角切り捨ててるあたりがね、なんとも潔いというかね

とりあえずキミはキメラのリメイクをするにあたり必要なもコマンドだけ
当面は用意するつもり。
なのであとは
エフェクト変換機能をキミはキメラのリメイクのために用意したい。
というかその前に紫電の方にエフェクトをいれなければ。。。

後々は変数、条件分岐のような制御構文も用意したいけど
そもそも紫電がそこらの機能を持ってないのでまずはキミはキメラのあとに紫電の方に
そこらへんの機能を入れる必要がある。

Nscripterでいうところのスプライトは紫電でも、もちろんコンバータでもサポート
しない予定。紫電が想定するビジュアルノベルにそういうのは必要ない。


とりあえずエディット画面をロードするのがすごい重い。
５０行でページ切換え機能いれなきゃやってられん。

追記
ああああああ、、とんでもないことに気づいたorz。。。そうかエディタの部分はjsonデータを引っ張ってくるのはネットからだけと想定していいのか。。。ローカルでもゲームプレイできるのを想定して
いろいろ面倒なことになってたけどネットからjsonデータを引っ張れるのであればエディタの部分はjsだけでもっと簡単にできたのに・・・。ああ～～～、今から変えようかな。。。。どうしよう。。
ごっそりjsでやった方がページ切り替え機能の実装楽だしいちいちphpにpostしない分ページ遷移がなくてユーザービリティもいいんだよお。。変えるべきだとは思う。

ああーーーー。落ち着け落ち着け状況を整理してもっとちゃんと考えよう。まだ考慮漏れがあるかもしれん。

jsonでダメな文字

なぜか
―の文字が入っているとjsonデータをjsのオブジェクトに変換できない。
なにか別の文字でリプレースするとかの処理が必要

立ち絵の挿入と削除

現状立ち絵を挿入するときは位置を%で指定してその位置へ挿入する
が、絵を指定して削除をできず、削除するときは一括ですべて削除する仕様となっている。
従って３人いて１人だけ抜きたいときは一旦全員削除して残りの２人を再表示するという
手順になる。

立ち絵の挿入と削除をNscripterでどうやるか調べてみた

http://autumoon.s35.xrea.com/nscr/ns04.html#2

どうもNscripterでは立ち絵をおける位置が左、中央、右の３箇所ときまっているようだ。
従って削除するときもその位置を指定して削除するということになっている。
これは自由度がないけど楽だ。

この方式を採用しようと思う。ただ左、中央、右、の３段階ではなく0-9の10段階にしようと思う。


実装としては10個立ち絵用のImageオブジェクトを用意して立ち絵表示
アクションがきたら0-9に対応するオブジェクトに上書きする。
削除の場合はそれに対応するオブジェクトの画像を削除する。画像サイズがメガ単位
なんてことはないだろうからメモリ的にも問題ない

始めは画像にidとか振ってそれで管理しようと思った。位置で管理するという発想はなかった。
位置の方が断然楽だし、特に不自由もない。とても参考になった。

今後のノベルエンジン勢力図

もしや今後ノベルエンジンは
html5+jsが主流になってそういうノベルエンジンの戦国時代が
始まるのかもと予想。
紫電はifengineとは完全に設計・運用思想が違うからな。

たぶんifengineはかち合わず共存できるはず。それ以前にあれはまだ公開するつもりなのだろか。
他に出てきたら怖いなあ。

jsなんてまともに使ったことなかったから性能で
アドバンテージ得るのは無理だな。
androidやiphoneのアプリと連携したりと運用でカバー
するしかない。飽和攻撃だ。

セーブ・ロード機能

セーブ・ロードというかメニューをどう実装しようか
すごく迷っている。
まず判断すべき点としてはキー入力のような外部からの入力でメニューを出すか
あるいは画面上にオブジェクトをクリックでメニューをだすかどうか。

当然環境によってはキーがあるかどうかわからないので画面上のオブジェクトクリックでメニューを出すようにする。

次の判断すべき点としてはクリックすべきオブジェクトをゲーム画面の中におくかゲーム画面の外におくか。。。。これが今一番の迷いどころ。
PCだけを想定するならゲーム画面の外でもいいだろうけどスマホも想定するとなるべくスクロールさせたくないからゲーム画面の中に置くべきと思う。ただゲーム画面の中におくと邪魔な気がする。
邪魔にならずゲーム画面の中に置く方法があればいいのだけどこれといって思いつかない。
半透明にして左下に置くくらいか・・・。

スクショ

今スターゲーザーというサイトの管理人様と
そちらで配布されているキミはキメラというノベルゲーム
のリメイク版を紫電を使って作っています。こちらがそのスクリーンショット。
まだいろいろ未実装の機能があったり調整が必要だったりします。

リメイクしてゆうこたん←が萌えキャラ化してたらどうするよww
ちなみにこれはテストなので本番では絵が変わっています。

すごく気になっていますぐプレイしたい方は現行版をキミはキメラからダウンロードできます。

CatSystem2

世の中にはこういうものもあるようだ。

http://cs2.suki.jp/index.html


かなりの高機能ではあるが当然のごとく動作環境はwindowsのみ
なんだろう。もうそういうのは時代遅れだと思う。。。。

Audioオブジェクトについて

Audioオブジェクトはサクッと短い音声ファイルを再生することを想定して作られている模様で、
ストリーミング再生を行ってはくれない。ロード完了するまで再生してくれない。
従ってBGMで使うような数Mの音声ファイルをBGMで再生しようとすると3Gやおそらく
ADSLでは無視できないラグとなる。

これを回避するためにロード完了するまで待つという方法が考えられるが
、ユーザビリティ的によろしくない。

妥当な方法としては1個か2個先のbgmをプリフェッチしてバッファリングしておくのが
よいと思われる。その上でロードがおいつかずbgmの切り替えが間に合わなかった
場合そういう仕様とする。

メモ

http://www.pxsta.net/blog/?p=2971

とても気になる。
ぱっと見かなりよくできていそう。
音声の実装はaudioタグでやっていてやはり非対応環境は切り捨てのようだ。

セーブとかのメニュー系はメッセージウィンドウの右上に置いてあるもよう。
たしかにこれでもよいかも。

test