クリック待ち

Nscripterではすべてのコマンドがシームレスに遷移していく。
紫電ではアクションという概念のおかげでそうはいかない。スクリプトになじみがない人に
受け入れられやすいおうにアクションという概念を入れたけど、これがちょっとやっかいだ。

Nscripterでは基本的にクリックを待つときは特殊文字で制御しているけど
紫電では特殊文字とアクション毎の設定で制御している。
二重にクリック待ちの制御をできる要素がある。
アクション毎のクリック待ち設定を排除してアクション間の遷移は必ずクリック無しで行えるようにして
特殊文字だけで同様のことをやることは現状できる。
hoge.jpgという背景を表示してクリックを待ってfuge.jpgという背景を表示する場合
ただこのようにすればよい。Nscripterがまさにこのような仕様っぽい(文字を置くのにコマンドを用いる必要がないが)。

背景変更 hoge.jpg
文字を置く @
背景変更 fuge.jpg


このようにクリックで次へ行きたいときはとにかく文字を置くというアクションを入れて
特殊文字を置けばよい。ただこうするとスクリプトに馴染みの無い層にとっての敷居が上がりそう
なので今は以下のようにしている

背景変更 hoge.jpg クリックで次へ
背景変更 fuge.jpg 自動的に次へ


うーーーん、やはり２重に制御できちゃっても現行の方が無難だよな・・・・。

あの仕様

どうもあの仕様とその周辺ソフトウェアを調べるにつけ
あれにこだわるのはあまり意味がないことに気付いた。
独自フォーマットでいくのは論外で
標準技術で目的を達せられるのであればあれにこだわる必要はない。
下手にこだわって痛いめにあう業者とか出てきそうだな。

が、流通の部分をガチで押さえようとする人たちにとっては
確実にこだわる必要があるんだろうな。


なんにしろDRMのことを考えると今の所あのフォーマットしか選択肢がないわけで・・・・。

うみねこ

ふとしたきっかけでうみねこの鳴く頃にのゲーム画面見た。
ガチで吹いた。

DL数

Androidやiphoneの開発者向けのダッシュボードでは
アプリの日ごとのDL数が見れるんだけど、あれどうやってDB実現しているのか謎。
日毎にデータの数が増えてそれらをわけて管理しないといけないわけで、まさかアプリ毎にテーブル作って行を追加しているわけではあるまい。
列を追加していくのは完全に無理だ。

そういうケースをDBで扱う定石みたいなのがあるのだろうか・・・。

いろいろ考えたけどファイルも使って管理している気がする。

更に考えると別に日毎のダウンロード数わからなくてもそんなに不便じゃないと思った。
今日のDL数
直近1週間のDL数
直近1ヶ月のDL数
直近3ヶ月のDL数
直近半年のDL数
TotalDL数
これらがわかれば充分な気がする、これならデータの数が６個と固定されているので
DBだけで実現できる。

追記:
こういうデータ数が増えるのをDBだけで実現する方法を思いついた。
blob型を使ってphpのスタックやキューのオブジェクトをそこへ突っ込めばいい。

紫電のとんでもない仕様違反

今の紫電エディタと紫電の実装では元来予期しないことができてしまう・・・・・。
受託開発なら確実にアウトな完全に仕様違反
divノードにtextノード作ってぶっ込んでるだけだからそうなってしまうんだけど、
これはこれでありな気がしてきた。
てか、もうちょっと手を加えてこれをサポート外の隠し機能として盛り込もうかと思う。
気付いた人だけ使えるみたいな。

Androidでの配信

昨日初めてXcode使ってiphoneアプリ制作をしてみたんだけど、
おそらく今回やりたいことを実現するだけならもう勉強は必要なく
１時間足らずでキミキメ紫電 for iphoneができそうだ。

問題はAndroidの方。。。いろいろ制約があってネット上から
ゲームの全データ(50Mバイトくらい)をネットからSDカードにダウンロードして展開しないといけない。
できればここで作ったものは伝ノベ用クライアントアプリにもそのまま流用したい。

ここで問題になるのはどうやってサーバーからSDカードへデータを流すか。。。
SonscripterではSocket接続でtcpでzipファイルを送っている。伝ノベでは
webページからコンテンツをダウンロードさせたいのでSocket接続は却下。
httpclient接続でhttpでzipファイルを送るようにしたい。
が、zipで送るとなるとサーバー側はゲームデータをzipで持っている必要がある。
キミキメだけならいいけど伝ノベでは全てのデータはwebでプレイされるので
無圧縮で持っている。なのでできればzipで持ちたくない。

するともうhttpで全てのゲームデータファイル・フォルダを送るという方法に
絞られてしまう。まあゲームデータの大半は圧縮された画像や音声が中心だから
zip化してもしなくてもサイズ的にはかわらない。ただダウンロードすべきファイル数
が多い分httpリクエストの数が増えることになる

一番理想なのはあれに対応することだわなあ。

横幅の%指定

横幅を%で指定していると、どうも右にスクロールバーが出たときと
出ないときで全体の横幅が変わるせいか%指定したコンポーネントの
横幅がかわってくる。まあいいか。

伝ノベ by IE

予想通りレイアウトがくずれまくり。
さすがIE。。。

XNovel

どうもXNovelは「涅槃」という日本語組版エンジンを使っているようだ。

http://code.google.com/p/nehan/

なーーるほど。これはすごいなあ。これがあればepub3.0の日本語絡みの仕様
サポートしてないリーダーでもそれっぽいことができるじゃん。
これで一つわかったのはXNovelはエンジンの一部にjavascriptを使っていること。
epubはjsのサポート必須ではないからつまりそこが純粋epubから逸脱している
ことになる。やっぱりjavascript抜きでノベルエンジンは無理だぜ。

なるほどね、、ということは厳密にはXNovelはやはり専用ビューワーでそれ用に作られた
epubしか読み込めないということになる。
とはいえjavascriptを読み込めないepubリーダーなんてあまりないだろうから実際には
わりといけちゃうと思われ。

rePublish

紫電とは関係ないけど、ちょっと面白いものを見つけた。
なんでもjavascriptのepubリーダーらしい。

http://www.moongift.jp/2010/06/republish/

が、更新が去年の5月で止まっているのを見るともう頓挫してしまっているのだろう。

追記：
おなじようなコンセプトのものを発見
http://blog.threepress.org/archives/

これはまだ開発が続いている模様

紫電 on iphone

ちょっとキミキメ紫電をiphoneで動かしてみた。。。。。。

とんでもないことに気付いた。。。。。。。

どうもローカルでUIWebView使って表示するときにhtmlやリソースの階層構造
無視しやがる。。。。。

iOSめ、やってくれる。。。。。

どうしたもんかなiOS系だけ処理をわけるしかないかなあ。
いやいやネット越しならiOSでもちゃんと階層を認識できるわけで。

まったくやってくれるぜ。

ヘッダー

なんというかヘッダーがどうしてもスカスカで変だ。
mixiとかピアプロはヘッダーの真ん中に広告バナーいれてるようだからそれを真似てみよう。
広告バナーも使いようによってはデザイン向上に寄与するような気がする。

サイトデザイン

とある方面から教えて頂いた資料に基づき
配色は以下のようにしようと思う。

ベースの薄い色(2色)　オレンジ, 灰色
ベースの濃い色(1色) 赤
指し色(1色) 水色

右を重くするか・・・。
ノベルエンジンがよこに長いから基本的に右コラムはいれれない
となるとヘッダー部分の右側になにかいれるべきということか。
何いれよう・・・・。
とりあえずログインとか検索フォームとか置いとこう。
そもそもヘッダー部分がスカスカでへんなんだろう。
まずはヘッダー部分にいろいろ付け加えるか

紫電エディタがいまいち

紫電エディタにいろいろ問題がでては潰しているという感じ。
そもそも実装がイマイチなんだよな。jsのプログラミングスキルがなっていない。
jsのプログラミングスキルをあげないことにはなんとかバグをここで
潰しつくしても今後こういうことが沢山あってげんなりしてしまう。

そこでこの本を買ってみた。これでjsのプログラミングスキルをあげようと思う。
amazonでの評価はかなり高いぜ。

ニコニコニュースのtwitter連携

いろいろ調べたけどあれはなんらかニコニコニュースが自前でデータベース持ってるとしか考えられない。
ツイートのデータ自体はtwitterにあるのは確かなんだけど、検索で見つからない。
どうもtwitter apiの仕様らしい。

となるともうデータそのものかメタデータをもってる以外考えられる。
しゃあない覚悟を決めて伝説のノベルにもtwitter用db持たせるか・・・。

uploader

CakePHPにuber_uploaderを組み込んだけど、かなり苦戦した。
一応一通りできたけど今はただファイルを置くだけでしかない。

次はtwitter連携機能を実装する、これができたら全体的なデザインの見直し、
検索機能やお気に入り機能なんて最悪リリース直後はなくてもいいや。どうせ始めは数えるしかコンテンツないんだろうから。

Ajaxのpostタイムアウト

バグというか実装のし忘れで一部アクションがpostできていなかった。
２度押しを防止するため１度submitボタンを押したらpost応答が帰ってくるまで
ボタンを無効化してたからそれらではリロードしない限りずーとボタンが無効になっていた。

postするようにしたら正しくボタンの無効を解除するようになったが、ここで一つ
思い当たった。サーバー側の状況によっては必ずpost応答を返さないかもしれない。
そうなるとずーっとボタンが無効のままでになってしまう。
これはまずい。なんらかタイムアウトの処理を入れる必要がありそうだ。


追記:
以下のようにタイムアウトとタイムアウト発生時のエラー処理ができるようだ
http://www.openspc2.org/JavaScript/Ajax/jQuery_study/ver1.3/chapter05/003/index.html

冗長性

いろいろ修正しながら思った。サーバーにあるスクリプトファイルもしかしたら
なんらかの原因で壊れる可能性があるんじゃないかと。ファイル書き込み中に
フリーズしたりとか。ext3が完全にうまいことやってくれると期待してはダメだと思う。

なので全スクリプトにバックアップを持たせようと思う。読み込めなかったら復元する。。。。
スクリプトだけなら大した要領にならないだろう。

あーー、でも同じファイルシステム上にバックアップも置いといたらファイルシステムごと
逝かれたときは意味がないのかRAIDかなにかでバックアップは別ファイルシステムにおいとかないと。
よくわからん世界だ。

肩こり

右手でマウス使っているのだけど、キーボードの幅が広すぎるせいか大きく体の中心から
右にずれたところでマウスいじくってるからかなり右腕と右肩に負担が来る。

おかげでおとといくらいから右肩がとんでもないくらいの肩こりになってた。
昨日と今日はもう呼吸が明らかにしにくいくらいに違和感があった。
右肩をぐりぐりしてみると3cm四方くらいのシコリがあった。これを
中心にしばらくもんでいたらなぜかしこりがなくなって呼吸もしやすくなった。

ふーーー、しんどかった。これからしばらくはマウスを左手で扱うことにする。
Eclipseでvimエディタが使えればマウス使わなくなってだいぶ楽になるんだろうが。。。。

DBのテーブル連携

例えばユーザー管理テーブルとコンテンツ管理テーブルが別だったと刷る

ユーザー管理テーブルがこんな感じ
userid:username:sex :age
0001 :userA :male :26
0002 :userB :male :25
0003 :userC :female:23

コンテンツ管理テーブルがこんな感じ
contentsid:title:userid
00001 :hoge :0001
00002 :hage :0002
00003 :moge :0001
00004 :toge :0003


コンテンツ一覧を表示したいけど、そこにはuseridではなくそのuseridに
紐づくusernameを載せたい時は一々ユーザー管理テーブルを検索しなくちゃいけないのだろうか・・
なにかいい方法はないものかのお。

追記
こんな手法をみつけた

http://homepage1.nifty.com/rucio/main/VBdotNet/Database/Database10.htm

joinというものでテーブルを連結したかのようにして操作できるっぽい。

CaskePHPでモデル使ってjoin使うのはめんどくさそうだから直接phpでクエリを書いてしまおう。いやそれほど面倒でもなさそうだ。

http://d.hatena.ne.jp/aroundthedistance/20090422/1240396315

fieldsというものを定義してるのがポイント。実際にはfieldsの中には*(全てのカラムの意味)を使った。

プロフィールページ

プロフィールページはとりあえずテキトーにpixivとmixiにインパイアされとけばいいのかなと。
そんな感じ。

twitter連携

ニコニコニュースのtwitter連携のコメントの仕組みについて

どうも自前でDB用意してコメントを管理しているわけではない事がほぼ確定。
例えばこのページ

http://news.nicovideo.jp/watch/nw166819 (サイトAと呼ぶ)

http://nico.ms/nw166819 #niconews (タグAと呼ぶ)
というタグAを付けてとにかくどこからでもツイートするとサイトAにある
コメントのTL上にツイートが載っている。

つまりあのサイトAのTLはなんらかtwitter apiを叩いてタグAをもつツイートを取得して
表示しているにすぎない。

サイトAにあるコメント投稿用のフォームはそこから投稿すると確実にタグAを
付与する点だけが特別なただのツイート投稿用のフォームでしかない。


従って以下２つの方法が判明すれば、同様の機能の実装が可能となる。

twitterへツイートする方法
twitterから指定のタグをもつツイートのみ取得する方法

CakePHPのフォルダに書き込み

$folder = new Folder('./hoge', true, 0755);

ってやった場合hogeディレクトリはwebroot直下にできる

CakePHPが神すぎる件

実は伝ノベ作る前にSoncripterの管理サイトを構築したんだけど
それがもう完成度低すぎててごめんなさいという代物。XOOPSを使ってカスタマイズしたんだけど
きつすぎた。すっごい時間かければもっとちゃんとしたものが出来ただろうけど。。。。

今ならCakePHP使えばちゃんとしたものが２週間程度でできると思われる。

もっと早くに知っていれば。。。。

XNovelを理解した

ああ、なるほどXNovelがどんなものかようやっと理解できた。。。
これは危険だなあ。あれじゃなきゃ見られないっていう代物だと思ったら違った。
あれはSonscripterみたいなものというわけか。コア自体は自前じゃないという。
XNovelがちょっとずれた代物と期待してたけど。。。やっぱり将来的に本命なとこ狙ってるよなあ。


Nscripterベースは将来的には敵にならないがAIRNovel+XNovelは完全に被ってる。
キミキメ紫電版出すとき紫電だけじゃインパクトが足りない。伝ノベも一緒に
ローンチさせたい。

AIRNovel+XNovel陣営は性能良いけど難しそう、紫電+伝ノベ陣営は必要最小限の機能しかないけど簡単そう
というイメージで差別化したいと思う。どうもそれにAIRNovelとXNovelは相互連携できてないようだな。充分に戦えると思う。

CakePHPで他のモデルを使う

http://d.hatena.ne.jp/cake67/20100115/1263531561

ここに回答が！

CakePHPで他のコントロールのアクションを使う

http://cakephp.pha22.net/index.php?%E4%BB%96%E3%81%AE%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%A9%E3%81%AE%E3%82%A2%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%92%E4%BD%BF%E3%81%84%E3%81%9F%E3%81%84

ここに答えがあった。
$this->requestAction('/コントローラ/アクション')
こんな感じらしい。
いやあ、CakePHPまじですごい。 まともに設計しなくてもいいからなあ。用意するコード量を大幅に
減らせるというふれこみだけど、それ同じ位設計の手間が省けるという利点があるぞ。
もう完全にCakePHP信者になってしまった

CakePHPでのビューの共通化

サイト内のメニュー部分とかはたいがい同じなので以下の要領で共通か出来る模様。

http://onlineconsultant.jp/pukiwiki/?CakePHP%20%E7%B9%B0%E3%82%8A%E8%BF%94%E3%81%99%E8%A6%8B%E3%81%9F%E7%9B%AE%E3%82%92%E5%88%A5%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%81%AB%E3%81%99%E3%82%8B

CakePHP2.0.4で独自cssを使った時にうまく動かなかった。

CakePHP2.0.4を使う事にした。


コントローラーからViewのctpファイルというhtmlみたいなのを呼び出してブラウザに表示するようなんだけど、ctpファイル内でcssファイルを指定しても無視される。
かってに規定のcssが使われるようだ。これを独自のcss使えるようにする方法が以下のエントリーに書かれていた

http://libro.tuyano.com/index3?id=10003

ただ、これはcakephp1.3までを対象にしているぽい。

<?php echo $html->css("cake.sample"); ?>

このタグがエラーを吐く。この$htmlというのはヘルパーのオブジェクト
と思われるのだけど、それが無いっぽい。CakePHP2.Xでは以下のようにすれば動いた。

<?php echo $this->Html->css('cake.sample'); ?>

CakePHPのコンセプトが理解しにくかった理由

http://libro.tuyano.com/index3?id=9001
このサイトに以下のような記述が

"フレームワークでは、「これこれこういうときにはこう処理する」といった仕組みがすべて組み込まれています。プログラマは、「こういうときには、この処理を用意する」という、フレームワークに指定された通りにプログラムを作っていくだけです。

つまり、フレームワークでは、プログラムをどういう形で作るかを決めるのは、フレームワークなのです。プログラマではありません。プログラマは、フレームワークの指示にしたがって、予め決められた通りにプログラムを用意していくだけなのです。

なんか堅苦しそうだな……と思うかも知れません。けれど、考えてみましょう。Webアプリケーションって、基本的な構造はほとんど同じと思いませんか？　フォームを送信して、データベースにアクセスして、結果をレイアウトして……そうした基本的な流れは、ほとんどのものが同じなのです。"

なるほどね。今ならだいたい理解できる。なぜなら
Webアプリケーションって、基本的な構造はほとんど同じと思いませんか？
と聞かれたたら知らねーよ！って感じだったか

サイトの方

サイトの方の名前は「伝説のノベル」という名前にした。略して伝ノベ。
昨日の時点でかなり開発が進んだ。DB操作が必要なとこ以外の実装が終わったんじゃないかな。全体の進捗としては60%くらいといったところか。

CakePHPの利点というかどういう用途で使いものなのか大体わかってきた。
phpでやることって言ったらDBの操作、セッションの管理、htmlの出力の３つだと思われる。CakePHPはそれらの操作のフレームワークを提供してくれるっぽい。

なので伝説のノベルのDB操作する部分はCakePHPを使うつもり。なのでとりあえず


というものを買ってみた。

なんか書こうかな

たまにはコーディング以外のことやってみたいわけで、
なんか自分でも短いシナリオを作ってみようかと思う。

ちょっと考えて候補は僕が小学生の頃に出会った今で言うニートと思しきお兄さん(推定30ちょい前位)との思い出を脚色した話。。

当時地元のちょっと大きめなスーパーていうかヤオハンにゲームコーナーがあって友達と結構な頻度で行っては極上パロディウスをやってたんだけど、お小遣いの関係上１日１回しかプレイできずたいてい３ステージめ(お菓子のステージ)で終わっていた。
でもなぜか極パロはすごく楽しかった。

或る日、僕らがくる前に先客がいた。しかも大人だ。午後３時位なのに！。その20代後半位のお兄さんは極パロをやりこんでいたのか1コインでラストステージまで行ってしまった。全然見た事もないステージだった。僕らは単純にスゲーと思った。もし極パロのプロと呼べる人がいるとすればこの人しかいないと思った。その後もよくそのゲームコーナでそのお兄さんが極パロをやっているのを目にした。

僕らはゲームコーナーに行った後はそのまま僕の祖父が運営している塾へ行くのが日課だったけど塾でそのお兄さんの神プレイと極パロの攻略についてよく話したりした。でも、相変わらず３ステージ目止まりだった。

このお兄さんのプレイの仕方について僕達は疑問を持つようになっていた。お兄さんはミカエルかガブリエルという豚のキャラを好んで使っていたのだけどなぜか自機を最高までパワーアップさせないのだ。最高レベルの一個手前までしかパワーアップさせないのだ。更に不思議なのはバリアも付けない。パワーアップやバリア取得用の条件は揃っているのにだ。

或る日僕が一人で行った時に勇気を出してその疑問をぶつけてみた。一瞬お兄さんは驚いたようだったが快くその疑問に応えてくれた。どうもパワーアップすると敵のレベルもあがってむしろ難しくなるとのことだった。特にボス戦ではその違いが大きいらしかった。なるほどと思った。それをきっかけに僕とそのお兄さんとの交流が始まった・・・・・となるかと思ったらそうはならずその後ゲームコーナで会っても特に話したりするわけではなかった。
その後僕らはそのお兄さんの真似をするようになってモアイステージまでいけるようになっていた。

更にその後重大な出来事があった。なんとコナミが極パロのスーファミ移植版を出したのだ。たしか小学５年生のクリスマスだった気がする。サンタさんにお願いしたら25日の朝枕元にラッピングされた極パロがあったのだ！！
それ以来もうお金を払ってまで極パロをやる気にはならずゲームコーナーへはほとんど行かなくなった。なのでそれ以来あのお兄さんにもあっていない。

でも今考えると変だよな。あんな平日の午後３時とかの昼間にゲームコーナーにいるだなんて。今考えるといわゆるニートの可能性が高いと思っている。ただ世の中的には白い目で見られるニートだけど、当時の僕らにはあのお兄さんが本当に神に見えた。ただただ僕らが熱中していた難しいゲームがうまいというだけなんだけど、当時の僕らは本気ですげーーと思っていた。

僕は今となってはあのお兄さんの正体についてそのように邪推してしまうようになってしまった、サンタさんの正体についても同様に実は本当は親が極パロをくれたのではないかと邪推してしまうようになってしまった。もう２０年近くも前の話だなあ。


これを脚色してヴィジュアルノベルにしてみようかなとw

ふと

前のエントリーで書いたコンセプトとは全くもって関係ないけど、
ビジュアルノベルというかビジュアルノベルエンジンってパワポ的なプレゼン資料にもなるんじゃね。

紫電のコンセプト

紫電のコンセプトを改めて考えて今までとは違ったコンセプトとなった。
おそらく当分このコンセプトでいくと思う。このブログを読んでる人は
ほとんどいないと思うけど一応キミキメ紫電版がリリースされるまでは伏せておこうと
思う。ブラウザさえあればどんな環境でも動く汎用性とか、グラフィカルなエディタでとっつきやすいとかそんなものはどうでもいい仕様だ。紫電を使ってくれる方々にもっとすごい恩恵をもたらすコンセプトだと思っている。


たぶんAIRNovel作ってる人とかなり似たコンセプトだと思う。AIRNovelに加えてXNovelなるものまで出したことから、未来に起こる事について似たように考えてる気がする。紫電がそれなりに成長できればAIRNovel陣営とがっつり競合してシェア争いみたいな展開になるかも。てかなってくれーー、よっしゃーーー戦いだぜーーー。それでこそ独立したかいがある。まあ、あっちはまだ紫電のことなんかまったく気にもとめてないだろうけど。でも現時点でこのコンセプトがまだ世の中にほとんど認知されてない以上紫電にも充分にチャンスがあると思う。

AIRNovel作ってる人がどのように考えてるのか知りたい。

アップローダー

結局uber_uploaderというアップーダを使う事にした

http://www.webdice.org/uber_uploader/

かなりいい感じ。かなりの優れもの
今回ユーザー毎にアップロード先やもしかしたら最大サイズを変えたいんだけど
コンフィグでそういうのを切り替えるための仕組みを用意してくれてる。

設置に苦戦して３時間ぐらい消費してしまった。
perlというcgiをサーバーで動かす方法をしらなくて上記のパッケージにあったcgi-binフォルダをそのまま同じ改装においていた。
どうもcgi-binというフォルダが/var/www下にあって/var/www/cgi-bin/
という感じ。そこに中身を入れる必要があったみたい。web系のプログラミングはホント
素人だから困る。組み込みエンジニアじゃなくてweb系エンジニアにクラスチェンジすべきだった。

このアップローダーはGPLなんだけど、どうもwebサービスではGPLのソース使っても
その他のコードの公開義務はないらしい。いよっしゃーー。

アップローダー

素材アップロードのためのクライアント側の実装でおもしろいものをみつけた。

http://javascript.webcreativepark.net/library/jquery_multiple_file_upload_plugin

なかなか便利そうじゃん。

あとこんなのも

http://www.webdice.org/uber_uploader/

うっはーー、自分で1から作るよりはだいぶ楽だけど、めんどくさそーー。。
てか、はよjsの本かえよ

紫電エディタの改修

一応完了した。
欲しい機能が他にもあるけど、当面この仕様とする。
公開後に折を見て機能を追加していくって感じ

まだ試してないどおそらくIEでは当然のようにうまく動かないんだろう。
圧倒的シェアを持ってくれてれば独自仕様でも何とも思わないけど、
シェアが分散してる状況下で独自仕様だとひたすらうざい。

紫電エディタの改修

どんどんマジックナンバー使いまりくりのうんこコードになっていく。。。
おおむねマジックナンバーが使われてしまうのは子ノードを取り出す時のchildNodesだ。
みんなどう管理してるんだろ。いちいちグローバル変数に値を定義してるのかな。
独学じゃ厳しいよなあ。

紫電エディタの改修

とりあえず色でアクションを判別できればなんのアクションかわかりやすくなると
思って色をつけてみた。

なんか変な気がする。色使いわるいのかな。。ところどころボタンとかフォームが
白いから変なのかな。なんか変な気がするけどなぜかはわからない。
まあいいか。

紫電エディタのajax対応2

全然対応できていないことが発覚した件
そうだ。httpでデータのやりとりはほぼ実装してあったけどそのあとのdhtmlで
動的に表示を変えたりする処理がごっそり抜けて落ちていた。
しかもそこの部分が実に骨がおれる。
もとの実装がお試し実装をそのまま延長したものなのでまるでajaxのことなんか
考えてないヘボ設計になっている。てか設計なんてないようなものでいきあたりばったり。

案件の方もやらなくちゃいけないから今日、明日でサクっとは終わらないだろうなあroz。

てか、もっといいUIがあるはずなんだ。ここでテキトーに実装しちゃうより、もっとよく
どういうUIだと使ってくれる人が使いやすいか考えるべき。。。

各アクションをドラッグして任意のアクションの前とか後ろにドロップできたらいいよなあ。
ただ、1ページ50アクションまでしか表示してないからページをまたいで移動しようとするとどうしたものか。
あと悩みどころは新規アクションをどのように追加できるようにするかなんだよなあ。
今はアクションテーブルの一番上に新規アクション用の行があるけどこれだと新規アクションを
追加しようとしたらテーブルの一番上までもどらないといかんわけで。

ひとつ思ったのがエディタのモードを２つ用意する。Aモードでは今まで通りな感じ、Bモードでは
各アクションのサマリーだけ表示して各アクションを小さく表示するかわりに全部表示するようにする。各アクションの中身は編集できないけどアクションの移動、削除、追加が直感的にできるみたいな。


追記：
あともう一つ考えるべき重要な点として今は1アクション毎にしかセーブできないようになっている。おそらく使う人としては編集をバーーーっとやってしまって一括で保存みたいにやれた方が便利だと思う。ただちょっと変更しただけでいちいち保存するような人が大勢いると毎回全データがサーバーに送られるので効率が悪い。。。

そもそも、今は標準でアクションの中身がみれてすぐに編集できるようになってるけど、そのおかげで幅をとるからページわけされている。
もしかしたら、使う人からすると別にアクションの中身見れなくていいから1つのアクションを小さく表示して全部ならべて欲しいと思っているのかもしれない。それで編集したいところをクリックとかして編集モードに切り替えて編集みたいな。
うーーーん。

いやー、でも今のエディタは便利でないけど直感的にわかりやすい気がするんだよなあ。
現時点でまるで紫電に知名度がないから、多少不便でももうホントだれでもわかるようになっているべきな気がする。便利さとわかりやすいさってイコールじゃないんだよね。。
うーーむ、難しいなああ。

紫電エディタのajax対応

これまでは紫電のエディタは1アクション変えるごとに一々ページ遷移して
たから編集を再開するのに元のページにいちいち戻る必要があった。
これをajax化することで各アクションの確定ボタンを押せばその場でそのアクションの内容が保存されるようにした。

おそらくエディタの使いやすさが倍増と思われる。そもそもが洗練されなさずぎてる
わけでまだまだ改善する必要がある。

ajaxの名前をよく聞くようになったのは5年位前からだけど、どんなものかは今までよくわかっていなかった。要約するとページ遷移なしでhttpサーバーと通信してその結果をdhtmlを用いて動的に表示することを指すようだ。

なるほどねーー。てか、それまではこんな事もできなかったのか。
こんなあたりまえだけどかなり重要だからああも騒がれたのだろう。

紫電のスクリプトの仕様

今日紫電のスクリプトは本当に今のがよかったのか、やはりNscripterと
全く一緒にすべきだったのではないかと考えていた。
結論としては概ね今ので良かったと考えている。

昨今のwebコンテンツを構成する要素は以下のようになっている
html (構造、モデルを定義)
css (見た目を定義)
js (振る舞いを定義)

ようはMVCってやつだな。で、ノベルエンジン用のスクリプトというのは
やはりデータとして存在すべきだと思う。つまりxmlやjsonとして存在すべき。
それはMVCモデルでは振る舞いを決めるのはjsだからという設計思想もあるし、
xmlやjsonにすればコンピュータがデータとして認識しやすいから。Nscirpter自体はwin上でしか動くのを想定してないからああでよいけど紫電はいろんな所で動いたりなんらか連携できることを想定している。認識しやすいというのは非常に重要だ。

なので、データとしてスクリプトが存在するようになるというわけだ。
で、ここは今後の方針にもなるけど、データとして存在するスクリプトで使われるコマンドについてはできるだけNscripterに近づけようと思う。紫電は完全にはスクリプトになれないので完全に一緒にできるわけではないけど。。
あとあとNscripterのスクリプトをサクッとjsonでデータ化したらすぐ動くって感じにしたい。

CakePHPが思っていたものと違っていた件

いろいろ調べた結果どうも表題のとおりとなった。
どうもこれはコミュニティサイトみたいのをサクッとつくれるようにするためのもの
ではないことが判明してしまった。じゃあなんなんだろう、これ・・。

おそらくCakePHPで利点にあげられてることをやろうと思ったときにこれがあると
便利なんだろう。。。


別に利点であげられてるようなことは特に使わなくてもサーバー側実装できちゃうし。
当面はCakePHPは置いておこう。

とりあえず、ログインと会員管理部分はありもののやつを使ってできてた。
更にログインしてるときだけエディタが表示されるようにもした。

CakePHPのインストールとmod_rewrite

 http://www.phpbook.jp/cakephp/install/

これを参考にCakePHPをインストール。その中にmod_rewriteという単語があったので調べてみた。
まずこれはapacheのモジュールらしい。

Apacheのモジュールのひとつで、アクセスURLを正規表現で書き換えることができます。
いわゆる、リダイレクトという処理を行うのに便利なモジュールです。
モジュールの解説ドキュメントによれば
URLを操作するためのスイス製のアーミーナイフ

と例えられるほど、非常に複雑な処理を行えます。

なるほど。これだけじゃ、さっぱりわからん。

が、その後の詳細をよんで理解した。 
動的ページを静的ページに見せるとのことで本来
http://www.sample.com/cgi-bin/sample/sample.cgi?a=123&b=456
でアクセスすべきところを
RewriteEngine on
RewriteRule ^/cgi-bin/sample/([0-9A-Za-z]+)/([0-9A-Za-z)]+)\.html$ /cgi-bin/sample/sample.cgi?a=$1&b=$2 [L]
 とどこかで定義すると
http://www.sample.com/cgi-bin/sample/123/456.html  でアクセスできるようになるらしい。


この処理をやってくれるのがmod_rewriteらしい。

参考url: http://tech.bayashi.net/svr/doc/apache/mod_rewrite.html

機能はわかったけど、実際どのようにCakePHPで使われるのかは謎のままである。

CakePHPの利点

http://codezine.jp/article/detail/670

ここにCakePHPフレームワークの利点なるものが書かれている。
なるほど、さっぱりわからん。8割がた本当にわからん。

現時点で理解できるもの
・PHP4/PHP5の両方に対応（PHPのバージョンによってコードを読み分けて対応）
PHP4/PHP5があるのは知ってる。しかも結構違うからいろいろ面倒だけど
それを吸収してくれるならとても便利だ
・バリデーション（入力値検証）機能

・活発なコミュニティの存在
なるほど。すばらしい

現時点でなんとなく理解できるもの
・PEARライブラリを必要としない
 たしかこれはユーザー認証系のライブラリだったはず。つまり手軽にユーザー認証的なことを
やってくれるのだろう。 ユーザー認証自体具体的にどのようにやるのか知らないけど

・生成されたSQL文のデバッグ機能
SQLのデバッグができるのだろう。生成されたSQL文というのは誰がどのように生成するんだ？
このCakePHPがなんらかSQLを叩いてそのデバッグができますということか？

・Ajax、htmlなどの各種ヘルパー

ヘルパーってプラグインみたいなもの？そもそもどうCakePHPとAjaxやhtmlが絡むんだろ？

現時点でさっぱりわからないもの

・O/Rマッピング（テーブルアソシエーション）
O/Rマッピングって何？
・CRUD（データの作成、読み込み、更新、削除）画面の自動生成
CRUDってなに？
・ビューのキャッシュ機能で表示の高速化
ビューって何？
・セキュリティ、セッション、リクエストなどのコンポーネント
わからん
・ACLによる認証システム
ACLってなんだよ
・データのサニタイズ
さっぱりわからん
・「vendor」ディレクトリで各種のPHPクラスを取り込める
で？

CakePHP

紫電で運用する上で重要になってくるサーバーサイドについて
のメモや雑記も今後載せていくことにする。

jsもphpも実のところこれまでまともに使ったことなくてかなりマズイ。
とりあえずサーバー側ではCakePHPを動かすことにした。。

といってもCakePHPが一体どういうものでないんができるのかさっぱりわからないので
明確な目的があって置く わけじゃない。

IMPACT

http://techwave.jp/archives/51534698.html

HTML5のゲームエンジンらしい。
enchant.jsとかこれとかやはりhtml5が今盛り上がりつつあるのを
激しく感じる。紫電もこの潮流に乗りたい。。。。

IEで文字送り

うわあああ、IE・・・。
IE上で文字送りがまるでまともに動いていない。なんなんだこれは
本当にIEだけろくでもない。

どうやら、原因はsubstrで1文字取り出すのをやめて配列アクセスで取り出すように
したのが原因のようだ。う～～～ん。

これはそこまで文字送りのパフォーマンスに寄与してないっぽいから
元に戻すか。

紫電ver 0.9

タブレット対応が完了した。
写真はタブレット上でアプリを起動したところ。vr1.0に必要な全機能が概ね意図通りに動いているのでこれをもってver0.9としたい
これから一週間いろいろテストして特に問題がでてこなくなったらver1.0とする予定。
つまり紫電の完成である。

タブレット対応

うはあーーー。めんどくせーーー。
Androidタブレットは標準で横長だから傾き角0の時に横長、傾き角90の時に縦長になる。
スマフォは標準で縦長だから傾き角0の時に縦長、傾き角90の時に横長になる。

たぶんipadも同じだろう。てか同じじゃなきゃこまる。回避策としては傾き角取得した時の
画面サイズの縦と横を比べてタブレットかスマフォを判別して処理を変えるしかない。
なのでipadだけ振る舞いが違うとかなったら実に困る。

XNovel

XNovelはepubベースらしい。
ゲームデータがepub形式ということはわかっているが、パーサーや描画を
どのようにやっているのかはわからない。どっかに書いてあるのかな。
知っている方は是非教えて下さい。

epub対応というのはすごくうまいけど、もしかしたらちょっと残念な取り組みとなっているかもepubリーダーでそのまま動くのであればすばらしいけど、このXnovel専用アプリ
上でしか動かないとなるとわざわざepub準拠の意味がない。

なのでepub準拠のノベルエンジンというものは・・・。

文字送りパフォーマンス3

１行ずつテキストノードを用意する方法で目論み通り
文字送りパフォーマンスが劇的に改善した。これで満足なレベルにならなかったら
とても困ってたところだ。

とりあえず実装できた程度なのでバック、スキップとかにはまだ対応できていない
でももうスマフォでもPC同様文字送りがカクカクすることはない。

おおおお

いやいやいやいやーーー。


まじっすか。ちょっとしたきっかけで某同人販売大手の社長さんとお会いする
機会がやってきた。
心の中で師と仰いでいるわけでこれはうれしすぎる。てか、普通ありえんよ
そこらのソフトウェア開発してる技術者社長と会うだなんて。別の実際に取引させて頂いている業者様の社長さんに会った事ない。

ただ万が一にもなにか仕事を発注してくれる方向になったとしても
今すぐにはうごけるかどうかどうかはわからない。。
紫電開発と既存案件をどれだけ早くやれるか。。
てか、仕事発注してもらえなくても全然構わない。
経営哲学をちょっとでも聞かせてくれたらそれでもうすごく満足だ。

クリスマス、正月もガッツリ働く。
僕に取って休日がうれしいのは世の中がとまってくれるから。

文字送りパフォーマンス２

文字送りするとき１列分の文字列から１文字ずつsubstr使って
取り出してたところを1文字なんだから配列アクセスで取り出すように
したらちょっとだけパフォーマンスがあがった。

あともう一つ、こっちが本命の改善方法だけど、それをやればもう
かなりパフォーマンスがよくなる。実験レベルではその効果を確認ずみ

セーブ・ロード

セーブはアクション番号のみ記憶するかアクション番号＋ページ番号
で記憶させるか迷っていた。
アクション番号だけだとロードしたときアクション番号から
なのでテキストが実際よりちょっと後ろになっている場合がある。
ページ番号も加えると後ろにならなくなる。

が、アクション番号＋ページ番号だとゲーム内容を変更した場合ページ構成が
変わったら不整合がおきてしまう。
アクション番号だけならアクション番号が変わるような変更しなければ
不整合がおきない。。。。
どうしよう。

どうすればいいんだーーー。


あ、、、まずいロードして再開した場合
バックモードで戻ろうとしてもロードして再開した場所までしか戻れない。。。。
ああああ、安易に楽な実装をしたからだorz。。。。
今から直すのはかなり大変だ。

追記；
とりあえずアクション番号＋ページ番号でセーブできるようにした。
おそらくキミキメはすでに完成したものがあるのだからページ番号がかわるような
変更はないだろう。

既存案件

うむむ、既存案件の方、先方が本気だしてきたっぽい。
こちらも本気にならないとまずい・・・。かなり紫電の開発ペースが遅くなるはず。
ただ完全にとめるとそれこそ頓挫フラグなので完全にはとめない。


セーブ・ロードをかっちり実装が終わればPC向けの実装はほぼ完了
あとはスマホ向けのチューニング。これがかなり骨折れそう。。

文字送りパフォーマンス

スマートフォンでの文字送りのパフォーマンスがなぜか悪くて
いろいろ試行錯誤してて、ひとつタイマーの呼び出し方は前々から
おかしいとは思ってった。jsでのタイマーの正しい使い方がどうこうではなく
 オブジェクト指向プログラミングをする上で完全におかしな実装をしていて
その解決をしたらなぜかパフォーマンスも大幅に向上した。

 要はオブジェクトの中の関数でその関数自身をタイマーで呼ぼうとしてたのだけど
できなくてタイマーで無理矢理windowの関数を呼びだしてそこから目的のオブジェクトのタイマーのある関数を
呼び出してた。

以下のを参考にタイマーで自身を呼べるようにできた。
 http://thinkingbear.net/blog/item/24

まだちょっとカクカクしてる感じがする。
あとはアレをやれば更にパフォーマンスが改善するはず。

大まかにものができてからが大変なんだよなあ。。ソフトウェア開発ってやつは

リファクタリング

なかなかリファクタリング終わらない。。。。
今までのコードがクソすぎた。Javascriptロクにこれまで触った事がなかった
からしょうがないと言えばしょうがないのだけど。
いや、今もまだまだレベルとしては低い。
なにかjsの本でも買ってみようかな。体系的に勉強しないといかん。


現在Androidのブラウザで普通にプレイしていると途中で落ちる。
なぜかSkipや Autoで見ていると落ちない。
このことからおそらく文字送り中にクリックで次のクリックポイント
まで文字を一気に表示する機能がおかしいんだと予想できる。

と思ったら違った。。。。

いや、文字送りの最中でクリックすると落ちるんだけど、いっきに文字を
表示する処理があってもなくても落ちる。。。。これは一体なぜだ

JQueryを使ったフリック

このページが参考になるし
ここで公開されているプラグインがすごく使い勝手がよさそう。


http://d.hatena.ne.jp/makog/20110526/1306428975

Androidアプリ版 デモ画像

これがAndroidアプリとして動いてるところの画像。
スクロールせずぴったりフィットしているからまるでネイティブアプリのよう。
たぶんhtml5+jsって言われなきゃわからないはず。

ちなこれはブラウザで表示した時。
アスペクト比を維持するためゲーム画面の横がかなり短くなってる。
ただ拡大縮小を許可してあるので適宜拡大とスクロールを組み合わせれば
アプリ版の大きさと同じにすることができる。

JapanManga

全然紫電開発と関係ないけどメモ

今日東京中野にあるコンテンツインキュベーションなんちゃらとか
いうところで虎の穴社長のセミナーを聞きに行った(無料)。
社長のセミナー自体すごくためになったし、そこで面白そうなスタートアップ企業を見つけた

http://jpmanga.jp/application/index.html

JapanManga。。中核メンバーは現役東大生の３人組。
これうちの会社でやりたいこととほぼ同じ。同人誌の海外販売。
僕は今の会社のリソースでは無理と考えてやらなかった。
むしろすでにそこそこの規模の同人DL業者と組んでシステム開発をやらせてもらって
一緒に海外展開できたらと考えている。

さてさてどうなるかな。。。同人誌はエロがあってナンボのものだと思う。
iphoneでしかまだ展開してないようだけどどうやっていくのか。iphoneだと
りんごの課金システム使わなければいけなくて、りんごに必ずお布施として売値の3割
もっていかれることになる。つまり売値の７割を作者と運営で分配する。
その時点でだいぶ不利だ。てか、こういうやり口まじでりんご嫌いだ。
モノはいいのは認めるけどさ。

生暖かくウォッチしていこう。。。

まあでも最近では同人DL業者と組んで海外展開以外の方法も
視野に入れてる。それとこの紫電開発が実はけっこう関連してたりするわけで。。
まだまだかなり先の話だけど。。。

Androidブラウザが・・・

まじでやっかいだ。
前々から気付いてたけどローテートして高さと横幅の取得した時の値が変だ。
一定ではないんだけど、だんだんその変化する規則がわかってきた。
本当にうざい。iphoneはいつも一定なのに。

と思ったら
IS06がおかしな振る舞いをしてLYNXだとiphoneのように一定の値を返してきた。
どうもIS06はブラウザにメーカーカスタマイズが入ってるのではないかと。
たしかに妙にIS06のブラウザは滑らかにレンダリングするんだよな。

こういうおかしな振る舞いをする端末は仕様とする。いちいち構ってられん。
もしそういう端末使ってレイアウトが崩れるのがいやなら
ブラウザのローテートロックをオンにするかアプリ版でやってもらうこととする。


開発者にとってオープンなプラットフォームは良い事ばかりではない
一例だわな。。。。

スマホ対応

スマホ対応にあたってちょっと複雑な処理を入れるので
その前にレイアウト絡みのコードをリファクタリングしてきれいにしなければ。

スマホ向け

スマホ向けの調整の大まかな部分が完成した。
現状スマホでブラウザから見てもアプリとして見てもスクロールせず画面一杯に表示して
まるでネイティブアプリのようにプレイできるようになってる。

この過程でAndroid2.2でテストしてるときに気付いたことがある。
どうもブラウザの高さをjsで取得しようとした時にソフトウェアキーがでていると
ソフトキーパネルの高さがブラウザの高さから引かれてる。

今開発中のゲームをプレイするためにパスワードを入力しないといけないのだけど
パスワードを入力するときに出したソフトキーが出しっ放しだと
とんでもなくゲーム画面が小さく表示されてしまう。

パスワード入力フォームは正式版ではなくすから問題ないとは思うけど念のため
Anrdoidはゲームが始まる直前に一度リロードしてソフトキーが必ず出ないようにする処理をいれようかな。


それはそうとスマホ用にはまだこれだけじゃダメなんだよな。。。。
アプリとして見られたら今のままで問題ないけど縦横切換えされたらぴったり表示されない。
どうにか縦横が変わるイベントを受け取れないものか

追記：これでローテートイベント取れるかかも
http://stackoverflow.com/questions/1649086/detect-rotation-of-android-phone-in-the-browser-with-javascript

ちなみに、PCでもxrandrとかやったらスマホの回転みたいなのと同等なイベントが発生するのかな。

あと、スマホでは縦モードの時はメニューを横ではなく下にだすべきだなあ。

AIRNovelってこういう縦横の切換えにも対応してるのだろうか。。。。

てかiphoneのsafariでAIRnovel見れないのは当然としてAndroid2.2の標準ブラウザでも
見れないぞ。。。まだちゃんとは対応してないのかな。

メニュー

おおよそ世の中のディスプレイというのは横長の状態で使われている。
紫電は4:3のアスペクト比を想定していて横を長く使うようにしているけど
それでも縦に対して横の方が空いている事がおおいと思う。
そこでメニューはゲーム画面の横に縦に並べて表示しようと思う。

メニューを右側に出したはいいけど、おおきな問題が。
前々から知ってたけど、実は人物画像は画面に収まらない分は見えないだけで
はみ出ている。そのはみ出ている部分とメニューが重なっているのでメニューをクリックしても
画像をクリックしたことになっている。。。。
どうしたものかなあ。
クリッピングできればあるいは・・。

でもそもそもメニューが人物絵より上になるようにしてるのになぜ人物絵にイベントを持ってかれるのだ。。


追記:
と思ったら簡単にクリッピングできた。
http://www.htmq.com/style/overflow.shtml

ノベルエンジンデモ動画

取り直したデモ動画がこちら

mac

なんでだろうなあ、まったく同じwebページで同じFirefoxなのにmacの方がなぜか
断然windowsより美しく見える。。。。
たぶん気のせいじゃない。同じfirefoxでもwindowsとmacで実際にレイアウトが
微妙に違ったりしたからなあ


別に僕自身はりんご信者じゃなくて今年からしょうがなくmacを使い始めた
むしろアンチりんごのLinuxユーザーだったんだけど、やはりmacは
見た目が洗練されていると認めざるを得ないと思った。
でもま、僕は見た目とか割とどうでもいいからmac信者にはならないけどな。

開発デモ動画

おおよそ主要な機能は開発されたかなという感じで動画をうp
0:45までがNscripterでの動作でそれ以後がsidenovelでのデモ。

オートモード

オートモードと文字送り中にクリックによる次のクリック箇所までの文字表示の
実装が完了した。

この実装をしている途中に@が本来文字数としてカウントされてはいけないのに
されていることに気付いた。これを除く処理入れたんだけど。。。。
かなり力技というかマシンの負担になる処理になってしまってる。
文字列一文字ずつ@があるかどうかチェックしてあれば無視するような処理。
他にいい方法が思いつかなかった。

Androidアプリ

Androidアプリとして開発中の紫電をAndroidに突っ込もうとしたら
問題にぶちあたった。bgmファイルの容量が1MBを超えてる。
現在Assetsにリソース全部突っこんでるけどAssetsに置けるファイルは1MB以下だ。

この仕様まじでうざい。つまりこれってAndroidアプリに入れれるファイルのサイズは
1つ1MBまでということだ。

まあ仮に入れれたとしてもキミキメのリソース全部で60MB近くあるから
本体メモリへのアプリインストールをためらう人が多数だろう。てか今の僕の端末の本体メモリにとうていインストールできる
サイズじゃない・・・。

Noesisもゲーム本体を別途ダウンロードさせるようにしてるのはこれが理由だろう。

とりあえずBGMは抜いてAndroidアプリとして動作することは確認できた。
AndroidについてはNoesisと同じようにゲーム内容はサーバーからダウンロードして
SDカードに入れるようにしよう。

SDカード内のHTMLファイルをWebViewに表示するには？
http://blogs.yahoo.co.jp/sao_kun2000/26567716.html

スキップモード、履歴モードほぼ完了

たぶんタイミングや押すボタンによってバグってると思うけど、
一応スキップモードと履歴モードの実装が完了した。

スキップモードはctrlボタンを押し続けても、Autoというボタンを押して
再度Autoボタンを押すまでスキップするようにした。
まだ読んでないところはスキップしないという機能は無い。
セーブ問題と絡むのであまり弱点を広げるのはよろしくない。

履歴モードはBackというボタンを押す事で履歴モードになり画面をクリックするごとに
１ページする戻るようにした。
再度Backボタンを押すと元に戻る。

Androidでもiphoneも想定通り動いてる。
あとはIEで確認しないと。

文字送り再実装完了

文字送りの再実装が完了した。
こんかいから改行、改ページとかは文字送りしながら判別
するのではなく文字表示のアクションがある毎に
一気ににそのアクション内の文字列を解析してページ、行に分割して
キューにいれることにした。

これにより以前より若干文字送りのスピードがあがってる気がする。

履歴機能を実装するにあたりこれまでに表示したテキストを全て配列に保存しとくことにした。
つまり最大でシナリオの文字数分メモリを食うわけだ。
仮に日本語で10万文字としたら必要となるメモリは約20万バイト
200000B = 200KB

最近のパソコンはもとよりスマホでも200KBなんて容量塵みたいなものよの。
800*600の画像2,3枚バッファリングするのと同じくらいだ。
問題なし。

文字送り再実装

セーブの問題どうするにしろ今の文字送りの実装じゃダメだ。
javascriptがよくわかってなかったころに適当に実装してそのまま来てしまったので
あまりにもダメすぎる。
今の設計だと履歴モードを実現するのがすごく面倒だ。

なので文字送り部分を設計からやり直す。。。。
orz.......

わかってる、開発とはこういうもんだ

セーブ、スキップモード、履歴モード

なにげにこのセーブ、スキップモード、履歴モードというのはすごく密接に関係している。
おおまかにセーブとスキップモードの実装を進めてしまったけど、
今すごくどうしようか悩んでいる。

件のゲーム内容アップデート時のセーブデータの問題のいい解決策が
ぜんぜん思い浮かばない。。うまく整合性をとれるような仕組みがないものか。。。

JQuery CycleプラグインのFadeアニメーション

IEでJQueryのCycleプラグインを使ってFadeアニメーションを
行うと透過pngの透過が無視されてしまう問題がある。
これはIEのバグらしい。開発者コミュニティでいろいろ議論されているが
その中にあった以下の方法で解決できた。

$(divimgid).cycle({
cleartype:false,
fx:'fade'
});

cleartypeをfalseにしてあるのがその解決方法

スキップモード

横の文字数制限とかクリック待ち文字(@)の処理とか
細々したところはまだできてないけど、おおよそスキップモードの実装が完了した。

実はスキップ中は関数の中からもう一度再帰的に自身の関数を呼び出している。
なのでコールスタックが溢れないか心配である。
追々ちゃんとタイマーつかって関数を呼んでもらうようにしないとなあ。

追記：
横の文字数制限とクリック待ち文字(@)の処理を実装し
最初から最後までキミキメをスキップモードで通してみたが
特に問題無かった。

AIRNovel

http://famibee.web.fc2.com/intro/home.htm

うむむーーー、ブラウザ上でプレイできるノベルエンジンに
AIRNovelというものがあるようで既にかなりの完成度になってるようだ。。。
FlashじゃなくてAIRだからiphoneでもアプリとしてできる。。。。
ただiphone+ブラウザではできないのがちょっとあれか。

もしかしたらこれにセーブの扱いのヒントがあったりして

セーブ機能

今セーブ機能は単純にアクション番号を保存している。
もし後々ゲーム内容を更新した場合、保存されたアクション番号に相当する部分に変更があった場合
データの整合性がとれなくなる可能性がある。

う〜〜ん、いろいろ考えてもよい解決策が思いつかない。
web版はこれはかなりの問題だぞ。。。。

案1.
サーバー側ですべてのバージョンのゲーム内容を持っておき
セーブ時にバージョン情報も保存する。ロードしたときはそのサーバー側にそのバージョン
のゲーム内容を要求する

案2.
整合性がとれなくなっても仕様とする

案3.
ユーザーにバージョンアップを通知して整合性がとれないまま続行するか
始めからやるか選択させる

今の所、案２でいきたい。。。。。

この件で思案していたら、エディタには下書き保存と公開という２つの機能が
必要な事に気付いた。

文字ウィンドウについて

文字ウィンドウの改修がだいぶ進んだ。

とりあえずこれがmacでの文字の表示。
文字ウィンドウの左側余白と右側余白がほぼ等しいように見える。

これがwindowでの文字の表示
macの方と同じくfirefoxなのになぜか左右の余白の大きさが違う。。。。


どうも画像を比べるとwindowsの方が1文字あたりのx方向のサイズが小さい気がする。
なので左に詰まっているっぽい。フォントサイズはmacもwindowsも同じなのに
ただしフォントの種類はどちらも明朝だけどwindowsはＭＳ Ｐ明朝、macは平成明朝
を使っている。

スキップモード

ctrlキーを押している間はスキップモードとし、
文字を高速で送れる機能を実装する。

javascriptの仕様上、どうもプログラムから能動的にキーの状態を取得するのは不可能
でキーアップ、キーダウンのイベントを外部から呼んでもらってキーの押下のイベントをハンドリング
するしかないらしい。

本当に必ずキーアップ、キーダウンのイベント来るという保証があるのかどうかすごく不安だ
キーダウンイベントでスキップモード発動してユーザーがctrlキーを離したのにキーアップイベントが
来なかったらそのままスキップしっぱなしだぞ。。。。

かならーずここへーかええーってくると・・・信じるしかないのか。

背景画像のプリフェッチ完了・・・

背景画像もプリフェッチするようにした。

今気付いたんだけどAndroidでもiphoneでもフェードのアニメーションを使った
画像表示ができていない。
今フェードを使って人物を登場させているけど、それらがことごく登場しなくなってる。
以前は表示されてたはずだから、たぶんIE対応のために大幅変更した箇所のどれかが
問題なのだろう。

ホントIEは・・・・一番ピーキーなくせにデバッグ環境が充実してなくて。。。
それに比べてwebkit使ってるChrome,Safariの安定感は抜群だ。
Windows Phone7も標準ブラウザがそれらのどちらかだったらいいのに。

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