Cycle プラグイン

アニメーションはJQueryのCycleプラグインを使ってるんだけど、 アニメーションの最中に他の処理を行うと表示領域がおかしくなる時がある。 なのでアニメーション中は他に何もやらせないようにロックしてるのだけど、 なぜかたまにクリック連打してるとアニメーションが終わってなくてもクリックした時の処理が 動くときがある。理由はよくわからない。デバッガで追えるような問題じゃないから難しい。。。 もしかしたらロックする前にクリックされているのかも。。。。

紫電エディタのajax対応

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

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

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

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

紫電のスクリプトの仕様

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

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

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

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

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

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

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

セーブ・ロード

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

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

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


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

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

文字送り再実装完了

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

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

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

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

文字送り再実装

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

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

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

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

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

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