「えっ」
っていいたいのこっちだよ。通常原作完結していなくてもそれなりの終わらせ方するものだと思うけど、そのまま放置で中身がほとんどないので最終回とかどんだけ手を抜いたんだよと。
ディケイドのほうが映画で完結するだけましに思えてきた。
http://homepage3.nifty.com/TAKU64/rank2009.htm
ミリオンの数と本数、50位くらいの本数を見ると12月を除いていてこれだから、不況ってなんだろうと思った。
異常だった2006年、2007年を除くと別に大きく下がってないよね。マリオWiiとFF13控えてるんでむしろ多いほうかも?
10万本クラスが弱くなってる気がしないでもないけど、ゲームソフトに限らずほとんどの商品は多様化して、少量多品種が当たり前になってきてる。
そう考えると今までと同じく開発に2年くらいかけて(少人数であればまぁ黒字かな)10万本を狙うよりも1年で5万本狙う方が現実的だよね。ゲームソフトだけが特殊だと考えるほうが間違ってると思う。
価格も横並びじゃなくてもっといろんなものがあっていいと思う。どうしても価格維持したいならおいらだったらスーパーとかみたいにより取り見取り販売でもやるかな。4本で4000円とか。単品2000円で。
これは極端な考えかもしれないけど、WiiWareくらいの小粒なものを集めてパッケージ化できないかというのは考えてる。ネットつながらない人は予想以上にすごくたくさんいるし(だからショップでつなげれるDSは強い)、店頭ならばパッケージを手にとって見てもらえれる。かといって単品売りだと500円とか1000円とかいう価格ではやっていけない。だからセット販売。
これくらい変態的なことはおいらはいつも考えてるんだが、それでもこの業界には宮本茂とか岩田聡というド変態がいるんだけれども、彼らに少しも追いついている気がしない。
いろいろと試行錯誤していたけど、個人的なベストはFormPanelを使うのが一番いいっぽい。それぞれの通信方式はメリットはたくさんあるのだが、デメリットもそれなりに大きくて、これがデメリットが一番無いということでカスタマイズやバグがあった場合の対応とかで融通が利くと思う。
フォームのサブミット先のターゲットが非表示のIFrameになっていて、そこに結果がレンダリングされる。送信元、つまり画面上はどこも変更されない。
つまり、送信時は通常のフォームのサブミット。受信がおわるとonSubmitCompleteイベント呼ばれ、結果をStringで受け取ることが出来るので、それをJSONとして認識させたりXMLとして処理したり独自フォーマットだったりそこは自由だ。この通信をフレームワーク化させて独自色を出してもいいと思う。
通常の階層の無いフラットなフォーム送信ということでフレームワークも一般的なアクションベースでよい。Strutsでもよいわけだ。サーバーサイドのフレームワークはStrutsでAjaxフレームワークとしてGWTをという提案をすると通りやすくなる…かもしれない。
利点としてはサーバーサイドの技術に縛られないこと。せっかくサーバーの技術から離れることが出来るGWTなのにそこに依存しているのはよくない。また、シンプルな通信方式だと逆にサーバーサイドはそのままでクライアントをJavaFXやFlexなどにするといったこともすぐに出来る。
たとえばクライアントのインストールが管理できる場合はJavaや.NET等のリッチなものでもいいと思う。
一般的なものはブラウザベースのGWT。アニメーション重視や携帯はFlashとかJavaFXとか。
サーバーはJavaでもいいし.NETでもいいしPHPでもいいってのはなんだかんだで便利かと。PHPやRubyが使えるレンタルサーバーは多いし。開発時にはGWTのプロジェクトに通信のモックとして静的なJSON(もしくはXML)ファイルをおいておけばそれだけで大概事足りる。
せっかくのサーバーサイドとクライアントサイドの分離技術なので思い切ってプロジェクトも分けたほうが効率よく開発できる感じ。