キミはキメラ 紫電版 再

広告申請の承認記念にまた掲載

↓のゲーム手軽にwebでプレイできますのでとりあえずちょっとでいいのでやってみて下さい。
おもしろかったらそのままプレイするもよし、Noveliaで大きなサイズでプレイするもよし。
セーブデータはどこでも引き継がれます。

広告承認

うは、Noveliaの時は広告申請ことごとく却下されたのに
キミキメの特設ページはまだPC用のだけだけど審査通りまくりだ。
この調子でスマホの方もいってほしい。

追記：
あああ、いいことを思いついた。よしこれで条件はそろった。

影舞

なんか影舞にスパムがきてる。
うざいからフィルタ機能をonにした。実験でそのスパムと同じ内容を投稿してみたら
はじかれたのでおそらくスパムは無くなるだろう。

あとは投稿があった時のメール通知機能もonにしとこう。

レスポンステスト

0

やっぱり、スマホ版のレスポンスの悪さなんとかしたい！！ とりあえずこの超シンプルカウンターで紫電エンジンが悪いのか webviewが悪いのかはっきりさせる。

追記：
うーーん、やはりwebviewが遅いなあ。どうもスマホのブラウザではダブルタップすると
画面タッチではなく拡大や画面フィットを行う機能があるけど、連打するとダブルタップと見なされてwebページの方にイベントがいかないんじゃないかと思う。

iphoneのスプラッシュ

うわーー、そうかそうなるか。
キミキメ for iphoneは横画面専用だからどうしても
縦向きでアプリ起動されると横向きにかわるアニメーションしながら
スプラッシュが表示されてしまうようだ。

うーーん、下手に絵が入っているといかにも回転してる感がでてむしろ汚い。
さりとて起動にもたつく事を考えてなにかしら表示させておきたい。
シンプルとのことなので黒画面にNow Loading....とだけ表示することにしよう。

今後

とりあえずAndroid版、iphone版の準備はほぼできた。
あとは広告の審査が通れば。リリースだ。

当面はお客様付きの案件を最優先で、
メイルストロム計画をその裏でやっていく
必要に応じて適宜紫電、Noveliaの修正って感じだな。

メイルストロム計画は２月中に完了させたいけど、その頃にはNoveliaのエディタがまともになってないとまずいだろうな。

通勤時間の細切れ時間にはjsの勉強だな。紫電のクオリティの底上げのためにも。
jsはプロトタイプと継承がイマイチ理解できてないんだけど、たぶんそれらを
使いこなせるともっといいもの作れるようになるんだろうな。

広告

やべえ、そんな方法よりもっといい方法をおもいついてしまった。
しかもこの方法ならスクリプト書き換えずに広告を変えることができる。
なんでもっと早くに気付かなかったんだ

少なくともこの件で10時間以上費やしてしまった。こんなシンプルな解決方法なのに

広告

Admakerのスマホ向けwebページの広告をアクションから表示できなくて
あきらめてたけど、もしかしたらできそうなアイデアが思いついた。
方法自体は別の用途で思いついてたけど、その方法を広告表示に使うという発想がなかった。

なんか最近、脳の働きがいいきがする。最近朝飯ちゃんと食べる様になった
からだろうか

なんというかweb系の開発は
組み込み系開発の世界ににてる気がする・・・。いかに制限内でいろいろなことを実現するか。スタンダードなスマホアプリやPCアプリ開発がうらやましい。


追記：

http://zombiebook.seesaa.net/article/136658559.html

この方法で実現できそうだけど、さっぱりわからんぞ。
てか、ぱっと見ローカルで動作してる場合は無理そうな感じ。

iphone版

iphoneアプリ版でもやってみたけど、タッチのレスポンスはあまりAndroidとかわらない。。。
UIWebViewもたいしてかわらんなあ。
もっと細かくフィーリングを分析すると文字送り中のレスポンスはAndroidが上で
文字送ってない時のレスポンスはiphoneが上って感じ。
うーーん、iphoneのユーザーは操作性にうるさいからこれはよろしくないなあ。。。。

でもXNovelはなぜかレスポンスがいい。。。。もしやあれはUIWebViewをつかってないのかな。
UI部分は実はAIRを使ってるのかも。

あとでちょっと数値を用いた実験をしたい。

html5 audio対応

ちょっと気になって調べてみた。 http://d.hatena.ne.jp/shinobu_aoki/20110621/1308667618 iphone4以降ではaudio完全対応なのにAndroidは2.3でも完全対応ではないのか。 oggは再生できると思ってたのに再生できない機種もあるようだ。 テストにつかったAndroid2.3のinfobarは問題なくogg再生できたから てっきり2.3はogg対応しているものかと思ってた。 あるいは、これは2.3だから2.3.Xで対応を増やしてるのかも。。。

キミはキメラ 紫電版

↓のゲーム手軽にwebでプレイできますのでとりあえずちょっとでいいのでやってみて下さい。 おもしろかったらそのままプレイするもよし、Noveliaで大きなサイズでプレイするもよし。 セーブデータはどこでも引き継がれます。

リリース

web版のリリースがなんとかできた。

http://kimikime.co.cc/kimikime/

命綱

エンジンは完成したけどAndroidのアプリの実装が未完成。
アップデート機構がまだだ。
これは命綱だからキッチリ作らないと。
これさえキチンと動作すれば、リカバリーできるわけで。

もちろんこれが使われないにこした事はないが、、、、

完成

一応完成。
これからテストを

Android版オーディオ

ううーーむ、
スリープ中どうしても音がとまらない。js側ではどうしようもないからANdroid側で適宜
停止して欲しいんだけどなあ。

Androidでのクリックのレスポンス

Androidでのクリックのレスポンスが悪い原因がたぶんちょっとわかった。

まず文字送り中はWebViewがクリックイベントを捨ててると思われる。
これはバイブが振動しないことからこのような結論になる。

文字送りしてないときにクリックしても反応が鈍いけど、
これはおそらくルビのパースに時間がかかっていると思われる。
そこ以外文字送りが開始するまでの処理で重い処理がないからそのように思う。


追記：
いやあ、文字送りしてなくてもイベントがあがってきてないっぽい。。。
これはどういうことだ。。。Android側の限界なのか？

いやいや、そもそもレスポンスは悪くない。普通に押したらすぐに
文字送りが始まる。
ただたまにタッチが無視されているのがレスポンスが悪いと感じさせる原因な気がする。
なぜタッチが無視される事があるのかはさっぱりわからん。
仕様だろうか

あーー、やっぱりみんな言ってる。どうにもWebViewの仕様だなあ

http://matsuhilog.blogspot.com/2011/12/webviewjavascript.html

http://praxis.cube-cube.com/?cat=24

てか、上のブログの管理人、元いた会社の同期じゃないか。

文字送りのパフォーマンス改善

ちょっと気になってしらべたらこんな情報が得られた

http://d.hatena.ne.jp/hir90/20080620/1213987444

str_repeat2のやり方が速いらしいけど、ぱっと見意味分からん。

ビット演算してるのかな。 

時間がない・・・

とりあえず、致命的じゃなくてあとで修正できるのはあとまわしにして
致命的でかつAndroid版で発生するものを優先する。
webなら即アップデートできるけどAndoidとなるとそうはいかないからなあ

クリックのパフォーマンス

ガッツリ文字送り周りのソース見てたらたまたま無駄な処理を発見した。
これは結構影響してそう。取り除いたら更にレスポンスがよくなったと思う。
こういうパフォーマンス改善は実測しながらやるとパズル的なおもしろさが
あってわりと好きだったり。

もっと時間かければ他にも無駄な処理でてきそうだし、キューイングすれば
更にレスポンスがよくなると思うけど後回しだな。

インタプリタ

どうもjsだとあとからポロポロささいなミスが見つかるなあと
思ったら、そうだjsはインタプリタ言語だからだ。ミスがあっても
そのミスにぶつかるまで動いてしまう。

cとかjavaではコンパイルという作業がだいぶミスを省いてくれていたんだろう。
コンパイラは偉大だな。

というわけでjsでもコンパイルはなくともそういうささいなミスをチェックする
ものはないかと思ったらあった。

http://www.jslint.com/

リリースまでにこれを通す。

デュアルディスプレイ

前の会社でかなり多数の人がデュアルディスプレイにしてたし便利そうだと思っていたので
一昨日ヤフオクで4800円で7インチのUSBディスプレイを買ってみた。

これはたしかに便利だし生産性が向上するだろうなあ〜。

今まではコーディングとネットで調べものはいちいちウィンドウ切り替えてたけどこれは
メイン画面でEclipseを開いておいてサブディスプレイでブラウザを開いて同時に表示したままにできる。あるいは両方にEclipseおいて片方にクライアント側プログラム、もう片方にサーバー側プログラムを表示したり。

いやーー、7インチはちょっとちいさすぎたかなあ。8インチにしとけばよかったかも。
持ち運びの負担もそれほどかわらないだろうし

IE対応

とりあえずIEでもまともに動くようになった。

DOMの状態を見て処理を変えるっていうのはjsのプログラミングとしてどうなのかな。。。
普通に考えたらDOMがかわったらそこも変えなければいけないからjsでフラグをもつべき
なきもするけど、、、DOMでやった方が楽だし。。。。

ううーーーん、実はjsはもうDOMに依存する前提で書いてしまって当然な言語なのかもしれないわけで。

クリックのレスポンス

イベントのキューイングを実装したわけではないが、
テキストの瞬間表示のアルゴリズムを改善して
ちょっとクリックのレスポンスが改善したと思う。

うーーむ、Android版は改善しないというか別の問題ぽい。
そもそも連打してるとバイブが動いてないからjsにイベントがあがってきてない。
Android以下のレイヤーでイベントを捨てているっぽい。
これではいくらjsを改善してもしょうがない。

リファクタリング

jsの本で得た知識をもとに全体をリファクタリングしてる。
う〜〜ん、おそらく短期的にはちょっとバグが増えるかもだなあ。
でもこれでバグの発見や修正の効率があがるし、今後の変更にも強くなるからなあ。

なんにしろスマホ版は紫電のアップデートができるような機構をいれとかないとな。

始めの実装があまりにもアレすぎたなあ。今の実装もプロトタイプや継承をもっと使いこなせればもっと洗練したものになるんだろうけど、それはちょっと今の僕のレベルからすると高度すぎる。。。。だれか指導してくれる先生が欲しい。

audio

audio関連の処理を別ファイルにしてモジュール化した。
なぜかそこらにころがってるjsってファイルをわけずに１個につめこまれてるんだよなあ。
それの方が使いやすいけど、それをメンテナンスする方は大変じゃないのかと思う。

IEのデバッガ

おおおーーー、今まで気付かなかったけど、IEのツールから開発者ツールというのを
選択するとjsのステップ実行ができる！
これは感動。でも、firefoxやchromeに比べるとすごくしょぼい。
insightみたいな組み込み用のデバッガみたいだ。自動で変数を並べてくれないし
ステップ実行している間はブラウザ側はまったく描画されないから
プログラムの振る舞いはわかっても表示の振る舞いはわからない。

最近わかったのだけど、どうもFirefoxやChromeはjsの言語仕様から逸脱して
cやjavaみたいに書かれたjsもどきのコードも適宜解釈してくれてるっぽい。
だからfirefoxやchromeで動くのにieでは動かない。

こういうのはやめて欲しいなあ。間違ってるんだから拡大解釈せずエラーを出す
べき。

つまりこれは開発はieでやるべきだと思う。。。
ただあのデバッガじゃあまりにも効率が悪いんだよなあ。あれをもっと良くしてくれたら
なあ

IE対応

IE上でいちおうゲームが進行するようになったけど
まるで文字送りがおかしい。。。
うーーむ。

IEでの動作

しばらくまえからIEでなぜか動作しないのだけど、原因がさっぱりわからない。
どういうわけか外部jsファイルで定義するオブジェクトが認識されていないようなんだけど、
なぜ認識できないのかさっぱりわからない。。。

外部jsファイルは読み込まれているようなんだけど

わかった。。。。

            $('#divbg').cycle({
                fx: effectname,
                speed: effecttime,
                nowrap:1,
                cleartype:false,
                delay: spd,
                after: onAfter,
              });

こんな感じで書いてるのが問題なようだ。オブジェクトのプロパティの最後は
IEの場合必ず,をつけてはいけないらしい。
他のブラウザでは付け様が付けまいがどっちでもいい。

うーーんIEはいちいち厳しいくせにデバッグ環境がろくでもないから困るなあ。

スクリプト仕様

またまた、この期におよんでスクリプトの仕様を今のままでいいのかどうか悩みだしてしまった。

以前いまのjson形式のスクリプトでよいという決断をしたはずなのに、
またNscripterの仕様そのままにした方がよかったんじゃないのかと。。。。

それぞれの長所と短所を改めて洗い出そうと思う。。。。


Nscripter準拠の長所
1. これまでのNscripterのスクリプトが(エンジンの対応次第で)そのまま動く
2. スクリプトについての解説本や資料が多数ある。
3. 完成された仕様を1から作る手間がない


Nscripter準拠の短所
1. Nscrpterのバージョン違いでおそらく使える命令や命令の振る舞いが違うはずで
それらの違いをサポートするのはしたくない。しないとなると混乱を招く恐れがある。
2. Web系言語との親和性が低い(Ajaxを使った紫電エディタみたいなのはほぼ実現不可)

今のスクリプト仕様の長所
1. Web系言語との親和性が高い

今のスクリプト仕様の短所
1. 資料がそろっていない
2. 仕様を1から考える必要がある。

うーーーん、、とりあえず言えるのは今のスクリプト仕様でやる以上
まともなエディタを用意しないことには独自のスクリプト仕様を用意した
長所がまるで発揮されないということになる。

一方でNscripter仕様の長所を発揮するためには
Nscripterの持つ命令全てを忠実に再現する必要があるけど、今の僕のjsスキルでそれはかなり難しいだろうな。
するとやはり今のスクリプト仕様が妥当なのだろう。
すくなくともメイルストロム計画の結果が出るまでは

スマホ対応

http://firemobilesimulator.org/


このFirefoxアドオンを使えばFirefoxでiphoneのUAをエミュレートできる。
これで紫電のスマホでの振る舞いをPCブラウザで再現できる。

android

ノベリアとAndroidアプリとの連携の設計がほぼ目処がついた。 その上でAndroid版のアプリ部分が一応完成した。
やはりIS06では背景のアニメーションがちょっとカクつくなあ あとはパワーマネジメントをどうしようかな。

ゲーム中は電源ボタンやホームボタン押されない限り BLオンしとこうかなあ。


追記：
文字送りでバグがあるっぽい。たまに行の最後の文字が次の行の頭にきてたりする。

test

phpを入れてるのにこのブログでは無視されてるようだなあ。
紫電ではタグ直書きできるけど、phpが動いちゃうのかどうか心配。。。
動くようだとセキュリティ上とんでもない。

今ちょっと試したところだと紫電でタグ直打ちではphp動いてない。
これはおそらく以下の理由だからだと思われる。
本来phpが動くのはブラウザからサーバーへのphp取得のリクエストがあって初めて
サーバー上でphpが動くのだけど
紫電がただブラウザ上でphpのソースコードを書いてるだけだからサーバーで
そのphpが動くことはない。。。。。

すなわちphpのコードがjsonのデータ内にある限りphpは実行されないという結論になる。

cgi 2

やっとBTSの設置とアップローダーの修正が完了した。

cgiがうごいてない

影舞をいれるときに気付いたんだけど、cgiがうまく動いてない。
つまりアップローダーも動いてない。いろいろ設定しても動かない。
ううーーむ、もうこんな時間なのに。。。。困ったな

BTS

とりあえずはベータ版でいるあいだは
BTSを置こうと思う。それ以降どうするかは様子をみて決めよう。

lightbox

http://www.huddletogether.com/projects/lightbox2/#download

ここから落としたlightboxというjqueryプラグインがかなりいい感じ。

http://www.css-lecture.com/log/javascript/011.html

これを参考にすれば、サクッと設置できた。

初期画像

放置されてた初期画像表示機能を動くようにした。

セミナー

さっきtwitterのフォロワーからCodeZineのセミナーが来月あることを知った。

http://seshop.com/se/timetable/21

これはすごく勉強になりそうだ。
と思ったら役に立ちそうなのはもう満席だ。
とても残念。

SEOの本

いぜんamazonでかった
 この本

<iframe frameborder="0" marginheight="0" marginwidth="0" scrolling="no" src="http://rcm-jp.amazon.co.jp/e/cm?t=yuma300-22&amp;o=9&amp;p=8&amp;l=as1&amp;asins=4881666843&amp;ref=qf_sp_asin_til&amp;fc1=000000&amp;IS2=1&amp;lt1=_blank&amp;m=amazon&amp;lc1=0000FF&amp;bc1=000000&amp;bg1=FFFFFF&amp;f=ifr" style="height: 240px; width: 120px;"></iframe>


なぜかまだ届かない。8日経ってるのに。
先方は正月があって色々忙しいのだろうか

エディターがうまくうごいてないっぽい

どうもエディターがうまく動かないと思ったら
いくつか文字列を扱う関数がエラー吐いてる。どうも今回本番用に
用意したvpsサーバーではそれまでのvpsよりphpのバージョンが
上のようでいくつかの文字列を扱う関数が使えなくなってるようだ。

うむーー、使えなくなった関数に変わる関数がちゃんと用意されてればうれしい。

Favicon

Faviconがcakephpのままじゃあれだなあ。
テキトーにNのマーク作ってはっつけとこうかなあ

広告

mixiのトップページの上部にあるような広告を探してるんだけど、
全然みつからない。。。。。画像付きの広告が全然ない。。。。
テキスト広告じゃ変だ。。。


なんとかそれっぽいのを見つけたけど、画像サイズがでかい。
もういいや、これで。

 と思ったけど、、、、やっぱダメだーーー

素材共有機能の設計

ジョギングしてたらいい案がうかんだ。

1. システム全体の素材共有用の専用フォルダとそのフォルダ内に紐づくDBを作る
2. 各ユーザーは手持ちの素材を共有設定するとその素材は共有素材専用フォルダへコピーされる。
3. ユーザーは共有設定の際にその素材の説明文やタグ等付与できる。
4. コピーされるさいにはファイル名はユニークなファイル名に変えられる。
5. コピー完了後そのフォルダに紐づくDBに説明文、タグ、ユーザーid、ファイル名が書き込まれる。
6. そのDBのデータを用いてその他のユーザーに共有素材の情報を提供する。
7. その他のユーザーが共有素材を取得するときには各ユーザーごとに設置された共有素材用フォルダへコピーされる

この方法なら素材共有に関する現在想定する全ての課題が解決される。
以下が現在想定する課題。

1. 素材に説明文等メタ情報を付与できること
2. 素材提供者が公開停止してもそれまでに他のユーザーに取得された素材は取得したユーザーのみ使用し続けることができること
3. 取得した素材からその素材の提供者を判別できること
4. 素材の公開停止ができること。
5. 共有素材のファイル名がかちあう状況が発生しないこと。

この機能が実装できれば紫電の方に注力できる。。。。

いや、この設計通りなら1月20日の公開までに実装しなくても問題ない。
あとから継ぎ足し可能な設計だ。
DBや共有専用フォルダをシステムに１つだとすればたやすく変更できる。
当面は素材共有機能はなしでいこう。サイトデザインもベータということで
当面はこれでいいと思う。初期の頃のmixiみたいに適度にスカスカしていて。
どうでもいいけど最近のmixiのサイトデザインはごてごて積み込みすぎじゃないかと。
でも、本当は今左側にあるメニューを上部に横において、pixivやmixiみたいに左側にはユーザーのアイコンとかプロフィールとかマイミク的なものを載せたい。


ということで20日までは紫電の方を仕上げる。

embedded test

400*300のときだと文字表示がおかしい 追記： 修正した。

サーバー

予定より１日送れてるけど、vpsとドメインの申請をやろうかねえ。


追記：
背景非透明度の設定が反映されていない。
作品DBのタイムスタンプがクエリで更新されてしまう。

イベントハンドリング

紫電のイベントハンドリングが実はかなり簡素だったりする。
クリティカルな状況でイベントを受け取ったら全て無視する設計。

やっぱりこれではまずいかも。
とりあえず受け取ったイベントはキューイングする事にする。

キューイングするのはいいとして問題はそのあとだ。どう取り出そうか。。。
mainループを回すようなプログラムならどこかでキューを見に行けばいいけど、
イベントドリブンの場合どうやるんだろ。
クリティカルな状態が終わったらいちいちキューを見る様に作り替える
のかな。。

キューイングは別の心配もある。連打しまくってキューに積み上げまくると
後から後からキューにつまれた処理が実行される。ユーザーにしてみれば
もういいよって思うわけで。昔のwindows95,98,meではそういう経験がよくあったな。

評価・コメント

やっと実装終わった。。。かなりてこずった。
途中DBの設計を変えた。将来を見据えて手を抜かない設計・実装にした。

評価、コメント

やはりDisquesは使い続けようかと思う。
というのも、一般的に作品の評価・コメントとツイートは分離されているから。
例えばAndroidアプリの評価・コメントはそれ自体で存在してツイートのボタン
は別途用意されている。

したがってDisquesはDisquesで分離しておいて評価にコメント欄を
設けようと思う。

pixivでは評価は会員しかできないようだなあ。
これにならうか

今日中に実装する！！

リーンスタートアップ方法論は早くも時代遅れ, 製品は最初から完成度が高くないとだめ

らしい。

http://jp.techcrunch.com/archives/20120104details-matter/

う〜〜〜ん、本当かなあ。これ。
そりゃ、始めから完成度が高い方がいいに決まってる。
それじゃリスクがデカいからリーンスタートアップにするのではないか。

アダルト作品の管理

アダルト作品の管理は次のような設計にするつもり

DBテーブルは一般作品と同じにするけどアダルトかどうかのカラムを作ることとする。
一般用とアダルト用の２つサイトを用意する。
どちらもの同じDBテーブルをみるけどアダルトかどうかのカラムでそこで扱う
コンテンツを選ぶこととする。

評価機能

一応評価機能の実装できたけど、なんか微妙。
評価と一緒にコメント送れた方がいいと思う。

が、コメントは別途Disquesとかいう外部のサービスを使っている
外部のサービスなので今回実装した評価機能と連動させるのは無理。

うーーーん、Disquesやめようかなああ。。。。
そうするとtwitterと連携するには自前でDB用意してtwitter apiを使う
ようにしないといけないわけで、そんなことやってたら確実に20日リリースは無理だ。

Disquesを使うかどうか。。。。。
とりあえず使わない方向でいくという流れ。
が、決断はもう少し伸ばそう。

自作ノベル

以前自分で作品をつくろうかということで
こんなエントリーを書いた。

http://shidentest.blogspot.com/2011/12/blog-post_6479.html

この中に出てくるお兄さんは実は職業不詳だけどロボone的なものに出場している
技術者ということにしようかなと思う。いわゆるロボット同士を戦わせるあれである。

うーーん、当時使われていたマイコンてなんだろう。
Z80とかH8とかくらいしかしらないけど。
このお兄さんは汎用マイコン使わずCPLDつかって独自プロセッサを
作ってしまう凄腕の技術者という設定。もちろんロボoneでも優勝経験あり。

で、主人公はそのお兄さんのラボへいくことになりロボットに魅せられてしまう。

で、15年後主人公が大学生になったらロボone的なものに出場するようになると。
でももう15年後にはCPLDやFPGAを使って独自プロセッサを用意するより
ARMのような高速な汎用プロセッサにリアルタイムOSを載っけて動かすのが主流
というか強いロボットの主流となっている。

そんな中でも主人公は15年前のお兄さんとのやりとりがあってCPLD
やFPGAを用いた独自プロセッサでOS無しという構成を捨てれないでいる。
でもやはりARM + リアルタイムOSの構成には勝てない。。。。。対戦相手は
幼なじみの友達ということにしておこう。

もう技術者としてのこだわりなんか捨ててcpldやfpga使ったロボット開発やめようと諦める。
そこへとある企業から主人公にゲーム機開発の以来が舞い込んでくる。。。

その後の展開は全然考えてない。

てか、マイコンや電子回路についてはいろいろわかるけど、機械系はさっぱりわからん。
ロボットも作った事無いし。ロボoneのレギュレーション知らんけど、ジャイロあったらそうそう倒れない気がする。

作品評価機能

うわわ、忘れてた。直ちに実装をする。

作品閲覧数の集計機能 完了

とりあえず問題なく動いてるっぽい。
実装してみると２個目の案悪くないかもと思った。

html5

紫電はたしかにhtml5の機能をいくつかつかってるけど、
Canvas使わずしてhtml5ベースというのはいささか大げさというか誇大
と思う。。。。一部html5ベースというのが妥当か。

作品閲覧数の集計機能

ゲームが開始されたらカウントアップする仕様にしたいのだけど、
エディタから編集している時にテストプレイされた時はカウントアップさせたくない。
ゲームが"表示"された時でなく"開始"された時にカウントアップにすると
jsでカウントアップしないとダメだけどjsの中で編集中かどうかを判定するのは・・・
どうやったものかなあ。。

1時間くらい考えているけど、良い案がうかばない。ただ無情に時が流れて行く。
ちょっとジョギングでもしてみようかな。

追記：
とりあえず全部で２個案がでた。もっと良い案がありそうな気もするけど２個目に思いついた案でいこうと思う。
判定するのはjs内で判定するけど編集中かどうかのフラグはhtmlにあるという感じにする。

SEO

とりあえずSEO対策に


この本をamazonで買ってみた。

アカウント周りの日本語化

これはかなりしんどい作業だ。。。。

ただ訳せばいいってもんじゃない。
文字のエンコードをlatinからutf-8にしなくちゃならないし、
そもそもいろんなところでlatin以外の文字を弾く
チェック機構が入ってるからそれもはずさないと。

追記：
完了したけど夜までかかってしまった。
でもまあ、一番重いのが片付いてよかった。

アカウント周り

アカウント周りの機能のインテグレートがほぼ完了したけど
インテグレートしたアカウント管理モジュールが外国製だから
全て英語なんだよなあ。アカウント作成するときも、アカウント作成完了の
案内メールも、もちろん警告表示もすべて英語。。。。。

これ全部日本語に訳すのか〜〜〜。これは見積もり外だったなあorz。
が明日の昼までには終わらせる。


以下は登録確認メールの文面。これで指定のリンクをクリックすると
さらに登録完了メールがくる

Hello 

Thank you for registering with us. Here are your login details...


User ID: handmaiddog
Email: yuma18@mail.goo.ne.jp 
 
Passwd: *******



*****ACTIVATION LINK*****

http://sonscripter.com/******/*******&activ_code=3721


Thank You

Administrator
SONSCRIPTER.COM
______________________________________________________
THIS IS AN AUTOMATED RESPONSE. 
***DO NOT RESPOND TO THIS EMAIL****


追記:
今気付いたけど、mixiってどこから退会できるんだ!?

コミュサイト残作業リスト

リリースまでには必須な作業


1.アカウント周りの機能が完全に動く様にする
2.埋め込みtagの修正
3.作品閲覧数の集計機能
4.素材共有の設計
5.サイト説明ページの用意
6.紫電・紫電エディタのインストラクションページ用意
7.不正なページアクセス関連への対処
8.SEO対策
9.アダルト作品との共存の設計
10. サイトデザインfix
11.作品評価機能
12.コメントと評価の連携機能

オプショナルな作業
1.自動定期バックアップ
2.DL版周りの機能
3.クリエーター用コンソール画面での詳細なデータ表示

結構あるな。。。

クリック連打の問題

なるほど、解析完了。やはりロックの機構がうまく動いてなかったか。
さてどう直したものか。

分析 2

Sonscripterもまるでコンテンツ数が伸びてない点では頓挫していると言ってもよい。
理由を考えてみると

1. クリエーターに公開までの明白なインストラクションがない
2.クリエーター自身で公開できない
3. そもそもSonscripterがなんなのかよく分かりづらい


こんなところかな。もしかしたらここら辺をよくしたら
もうちょっとSonscripterでもコンテンツがあつまるのかも

ただ、集まったで集まったで色々困るわけで。
ベースとなるOnscripterが世の中のすべてのNscripterコンテンツに正確に対応しているわけじゃない。 Onscripterのソースコードはいじれるからがんばって対応しようと
思えばできないこともないけど、全てのコンテンツが使うわけでもないプラグイン
が正しく動かないと言われても、対応できないわな。割にあわなすぎる。

従って有料配信は絶望的。


ただ、一応ユーザー数はそれなりにいるわけでとりあえず有料配信はあきらめても
CakePHPでクリエーター用ページをちゃんと作って簡単にクリエーターが
Nscripter作品をアップロードできるようにするのはよいのかも。
で、そこから新しいコミュニティサイトの方へユーザーとかクリエーターを引っ張る
導線とする。

分析

コンテンツ系のwebサービスの運営というのは本当に難しいと思う。お金がないと
なおのこと難しい。それを踏まえて今開発中のコミュサイトも失敗に終わる公算が非常に高いと思っている。

今回このJapanMangaというサービスについて思ったことを残して置きたいと思う。
http://jpmanga.jp/

Japanmangaを知ったのは12月頭くらいの某社社長の講演会でたまたまJapanmangaの
代表含む二人に会って話した時。なんでも二人とも東大生らしい。

このサービスでは翻訳料７8００円払えば他の言語１つに翻訳してiphoneで配信してくれるようだ。有料配信した場合作者の取り分は35%-50%。

で、このサービス10月半ばから完全に頓挫しているっぽい。2011年7月から有料配信するとかいてあるが実際には行われていない。2011年10月から新しい作品が配信されていない。
2011年内に100本以上の作品を配信予定だったらしいけど未だ20本以下。

http://www.venturenow.jp/news/2011/08/24/2205_014002.html

なぜか代表が10月あたりで変わっている。サービス公式twitterも10月から停止している。
以上により完全に頓挫したと考えられる。

このサービス何がいけないのか？
サイトを見るとかなりデザインもしっかりしていてしっかりしている。配信先のiphoneアプリもデザイン機能ともにかなりしっかり作られている。どの作品もページ数少ないのに
ダウンロードしながら閲覧できるという無駄に高機能。デザインもいいと思う。
twitterやfacebookでもかなりフォローされているし様々な情報サイトが記事にしていて
露出も少なくない。さらに東京都もいろんな形で支援していたようだ。
ビジネスコンテンツ的なものでも入賞したりどこかの団体が支援しているようで
周りからもビジネスとしてお墨付きをもらっていたようだ。

つまり我々より確実に有利な状況にあったと思う。なのに頓挫した。
なぜか。

おそらく一番の理由はコンテンツが集まらなかったという事だと思う。
いくつかコンテンツが集まらない理由を書き出してみた。

1. 実際に課金販売をやっていないっぽい
2. 無料配信するにしても翻訳料7800円取られる(クリエーターは何のために配信するのかすごく謎)
3. 配信してもダウンロード数がわかるようなコンソール画面が用意されていないっぽい
4. 仮に有料配信できたとしてもクリエーターの取り分が低すぎる

こんなところかな。当然これらは我々のサービスでは解決する。
まあたぶん、これらを解決しただけじゃあダメなんだろう。
必要条件

なにか最近ステマが流行りみたいだからそういうこともやった方がいいのかも。
てかやる。 申し訳ないけどやる。

隠し機能だったもの

隠し機能にするつもりだったけど、エディタに入れてしまった。
タグを直接記述できる。
アルティメットだ。

タグで直接自前の広告はるもよし、リンクをぺたぺたはるもよし
なんでもできる。

文字送りのバグ

どうも連打しているときのロックが効かない問題だけど、 画像切り替えの方のロックは想定通り動いているっぽい。 文字送りの方のロックが正しく動いてないっぽい。どこでどのようにして正しく動かなくなってるのかは まだわからない。 今日Uターンするけど、とりあえず胃腸炎がとんでもなくひどくてまともに正月料理を食べれなかった。健康に は気をつけようと思った。とりあえず以下の事を厳守したいと思う。 1. 午前1時までにはふとんに入る。 2. 11:30以降は仕事をしてはならない。 3. 毎日筋トレする 4. 濃厚つけめん・カレーうどんは絶対に食べない これとは別に部屋を片付けようと思う。 事務所で作業して自宅は寝るだけと割り切っていたのでかなり荒れ放題になってるけど おそらく心にゆとりがなくなる原因だと思う。

Cycle プラグイン

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

javascript

だーーめだ。。。完全にCやJavaのプログラミングにやられてる。 Javascriptにはクラスがないからうまくプログラミングできない。。。 javascriptはとっつきやすいけど、奥が深くて難しい・・・・。

Paasがすごすぎる

元同僚のツイートからすばらしいサービスの情報を得る事ができた。
PaaS（Platform as a Service)というらしいけど、なんでもwebサービスをやる上で
サーバー側にインフラとして求められる要件一括で提供してくれてさらにサービス開始後
もスケーラブルに拡張できるようだ。
これまでリポジトリとサイトは別サーバーだったんだけどこのPaasで一元管理できて
ソースコードをリポジトリにコミットしたら直ちにサイトに反映してくれるようだ。
更にロードバランサーで負荷分散やDBの堅牢性をあげたりphp実行の最適化を
うまいうようにやってくれるらしい。
ここらへんは未知の領域だったのですごくありがたい。

PHP Fogというものがあるっぽい。
https://phpfog.com/


ただ、この格安VPSもパーフェクトプランならロードバランスとかあるし、
PHP Fogだとハードディスクの追加オプションがないようだけど
ここなら10GB 105円/monthでふやせるみたい。

やはりここがいいかな。。。
http://dream.jp/vps/

利用者が少なければそうそう障害はおきないから安いプランにしといて
あとで利用者がふえてやばそうになってきたらパーフェクトプランに乗り換えを
検討中。

仮に490円のプランを使うとして広告費でこれをまかなう場合
クリック率0.4% クリック単価10円とした場合必要となるアクセス数は

490(yen/month) / 10(yen/click) / 0.004(click/access) = 12250(access/month)

月12250アクセスを一番始めの目標とすることになるな。
なにげに結構な数字だよな。。。

追記：
上記は誤りだ。クリック率はアクセス数に対しての割合ではなく。広告表示数に対しての割合だ。従って
コンテンツが多くなればアクセスあたりの表示数も増えることになる。初めはとりあえず1アクセスあたり3回表示とする。
すると先の値から3で割ればいいから1ヶ月の必要アクセス数は

4083(access/month)ということになる

エディタ

これにいろいろ重要なことが書かれてるので
いまやってるエディタの修正にこの本から得られたノウハウを注入する。
この本にもっと早くに出会えてたらと思うと悔しいぐらい素晴らしい。
割とオライリーにしては薄いんだけど、完全に入門者お断りで親切な説明は一切ない。
でも内容はかなり濃い。

とにかく今はちょっとでも前へ。
正月なんて祝ってられん。あと数歩で崖っぷちである。

とりあえず胃腸炎でお腹がまじで痛い。もう限界。横になる。