2007/04/27(金) [n年前の日記]
#1 [firefox] _TimeTracker （ブラウザの表示時間を自動カウント）
[ ツッコむ ]
#2 [game] そういやFPSってプレイしたことないな
自分がプレイしたタイトルの中で、それに近いものというと、ガンゲージくらいか…。でもアレってFPSなのかな。シューティングアクション、に分類されそうな感も。
や、とある方からソレに類するサンプルアプリを受け取ってプレイしてたのだけど。とにかくストレスが溜まり、なんだか考え込んでしまって。FPSにもたぶん2種類ありそう。プレイヤーがアバウトに狙って撃ってもガンガン敵に当たるタイプと、じっくり慎重に正確に狙いを定めて撃たないと敵に当たらないタイプと。…まったく詳しくないので他にも種類があるかもですが。
ガンゲージは前者だろうな。照準が画面に出ていて、その照準の範囲内に敵を収めて撃ってさえいれば、とにかく当たる。自機をせっせとあちらこちらに動かして、敵の激しい攻撃を華麗に避けながらプレイする感じなので、正確に慎重に、なんてやってられない。よってその仕様が正解なんだろうと思う。 *1 …が。場面によっては正確に照準を合わせないと美味しい思い(アイテムゲット等)ができないときもあって。そういう場面では、敵の攻撃はまったく無し。そもそも敵を配置しなかったり。ステージ構成、というかマップ作成の段階で、どこを動にして、どこを静にするか、考えられている。のかなと想像したりもする。
後者で ―― 正確に照準を合わせないといけないタイプでは、敵の攻撃の仕方を考える必要がありそう。自分はなかなか上手に狙えないのに、敵はまるでコンピュータのように正確に狙って撃ってくるのでは、ユーザにとってはストレスが溜まり続けるだけ。たちまちクソゲーの烙印を押されてしまう。となると、対策としては…敵に手心を加えておくとかそのへんかしら。敵の攻撃間隔を伸ばす・攻撃回数を減らしておくか、あるいは、敵もバンバン撃ってるんだけど狙いが定まってない・攻撃ミスを頻繁にするように作る。とか。
攻撃ミスをする場合、敵はガンガン撃ってきてるという情報を、明確に、ユーザに伝える必要がありそう。それを伝えておかないと、ユーザはプレイ中に危機感を持たないので。実際はそうそう当たらないのだけど、早く反撃しないとヤバイ、と焦らせるよう、あの手この手で感じさせる必要が。現実世界のソレでは、銃の発射音がするぐらいでも結構危機感を持つだろうけど。ゲームの場合、視界の狭さ・不自由さや、BGMや他のSEに発射音が埋もれてしまうことを考えると、もうちょっと過剰に情報を伝えたほうがヨサゲかも。例えば、周囲のモノがバンバン壊れるとか、Matrix や STAR WARS よろしく、銃弾の軌道を視覚化するとか。…周囲のモノが壊れるアプローチは、その壊したオブジェクトをその後どう扱うのか、全て壊したらその後提供すべき視覚情報はどうするんだ等々、プログラム的にも仕様的にも問題が起きそうだから、銃弾の軌道視覚化のほうがいいのかしら。…考えてみれば、一般的なアクションゲーム・シューティングゲームでは、敵弾は視覚化され、プレイヤーが回避できる程度の速度で飛んでくるようになってるのだな。逆に考えると、銃弾の軌道視覚化をしてしまうと、いかにもゲームらしい抽象化を画面から感じてしまうので、リアルっぽい感じのゲームにしたい場合は、別の手段を模索したほうがヨサゲだったりするのかしら。
てなことをもやもやと考えてしまったりしたのでありました。まあ、件のサンプルは、まだ動作確認・実装テストの段階だろうから、「ゲームとして成立させるには」てなところを考える必要はないのですけど。いや、考えておいて損はないんだけど。最終的にはそこらへんに到達せざるを得ないわけだし。いやいや、あまり先のほうまで考えると作業量の多さが見えてきて辟易して制作意欲が減退するかもしれないので、あえて考えないのもアリか。お仕事じゃない場合は、制作のモチベーション(?)維持もなかなか大変なわけだし。いや、お仕事も、エンジンのキーを回すまでがアレなんだけど。
や、とある方からソレに類するサンプルアプリを受け取ってプレイしてたのだけど。とにかくストレスが溜まり、なんだか考え込んでしまって。FPSにもたぶん2種類ありそう。プレイヤーがアバウトに狙って撃ってもガンガン敵に当たるタイプと、じっくり慎重に正確に狙いを定めて撃たないと敵に当たらないタイプと。…まったく詳しくないので他にも種類があるかもですが。
ガンゲージは前者だろうな。照準が画面に出ていて、その照準の範囲内に敵を収めて撃ってさえいれば、とにかく当たる。自機をせっせとあちらこちらに動かして、敵の激しい攻撃を華麗に避けながらプレイする感じなので、正確に慎重に、なんてやってられない。よってその仕様が正解なんだろうと思う。 *1 …が。場面によっては正確に照準を合わせないと美味しい思い(アイテムゲット等)ができないときもあって。そういう場面では、敵の攻撃はまったく無し。そもそも敵を配置しなかったり。ステージ構成、というかマップ作成の段階で、どこを動にして、どこを静にするか、考えられている。のかなと想像したりもする。
後者で ―― 正確に照準を合わせないといけないタイプでは、敵の攻撃の仕方を考える必要がありそう。自分はなかなか上手に狙えないのに、敵はまるでコンピュータのように正確に狙って撃ってくるのでは、ユーザにとってはストレスが溜まり続けるだけ。たちまちクソゲーの烙印を押されてしまう。となると、対策としては…敵に手心を加えておくとかそのへんかしら。敵の攻撃間隔を伸ばす・攻撃回数を減らしておくか、あるいは、敵もバンバン撃ってるんだけど狙いが定まってない・攻撃ミスを頻繁にするように作る。とか。
攻撃ミスをする場合、敵はガンガン撃ってきてるという情報を、明確に、ユーザに伝える必要がありそう。それを伝えておかないと、ユーザはプレイ中に危機感を持たないので。実際はそうそう当たらないのだけど、早く反撃しないとヤバイ、と焦らせるよう、あの手この手で感じさせる必要が。現実世界のソレでは、銃の発射音がするぐらいでも結構危機感を持つだろうけど。ゲームの場合、視界の狭さ・不自由さや、BGMや他のSEに発射音が埋もれてしまうことを考えると、もうちょっと過剰に情報を伝えたほうがヨサゲかも。例えば、周囲のモノがバンバン壊れるとか、Matrix や STAR WARS よろしく、銃弾の軌道を視覚化するとか。…周囲のモノが壊れるアプローチは、その壊したオブジェクトをその後どう扱うのか、全て壊したらその後提供すべき視覚情報はどうするんだ等々、プログラム的にも仕様的にも問題が起きそうだから、銃弾の軌道視覚化のほうがいいのかしら。…考えてみれば、一般的なアクションゲーム・シューティングゲームでは、敵弾は視覚化され、プレイヤーが回避できる程度の速度で飛んでくるようになってるのだな。逆に考えると、銃弾の軌道視覚化をしてしまうと、いかにもゲームらしい抽象化を画面から感じてしまうので、リアルっぽい感じのゲームにしたい場合は、別の手段を模索したほうがヨサゲだったりするのかしら。
てなことをもやもやと考えてしまったりしたのでありました。まあ、件のサンプルは、まだ動作確認・実装テストの段階だろうから、「ゲームとして成立させるには」てなところを考える必要はないのですけど。いや、考えておいて損はないんだけど。最終的にはそこらへんに到達せざるを得ないわけだし。いやいや、あまり先のほうまで考えると作業量の多さが見えてきて辟易して制作意欲が減退するかもしれないので、あえて考えないのもアリか。お仕事じゃない場合は、制作のモチベーション(?)維持もなかなか大変なわけだし。いや、お仕事も、エンジンのキーを回すまでがアレなんだけど。
*1: もしかすると、内部的には2次元で当たり判定をしてるのかもしれない。透視変換後の敵の位置と照準の矩形領域で当たり判定をしてる、とか。いや、勝手な想像だけど。…敵との間に、壁や別オブジェクトがあったらどうなるんだろう。などと考えると、やはり3次元で当たり判定しないといけないところがあるような気もしてきた。うーむ。
[ ツッコむ ]
#3 [xyzzy] _対応括弧自動挿入(しょぼしょぼすくりぷと xyzzy)
メモ。
[ ツッコむ ]
#4 [prog][iappli] gif画像の総ドット数を求めるperlスクリプトを作成
iアプリで、瞬間的に持てる画像総ドット数を超えてないかチェックしないといけないなと思ったので作成。
_getdotsize.pl
こんな感じで結果を出力。
もっとも、FOMAではどこまで持てるのか、その情報がないんだけど。mova、505i あたりでは 240 x 240 x 6 dot ぐらいで怪しくなり始めるという話を聞いてるわけですが。90xi はともかく、70xi あたりは 505i と似たところもあるのかしら。だとしたら、現在作成中のアプリはマズイな…。オーバーしてる…。一応こまめに、画像をロード・廃棄しておくか…。
_getdotsize.pl
こんな感じで結果を出力。
C:\hoge\temp_wk>getdotsize.pl ../dotsizecalc_test bg_title0.gif : 240 x 240 = 57600 bg_title1.gif : 240 x 240 = 57600 bg_title2.gif : 240 x 240 = 57600 bg_title3.gif : 240 x 240 = 57600 bg_title4.gif : 240 x 240 = 57600 bg_title5.gif : 240 x 240 = 57600 logo_title_gamestart.gif : 96 x 16 = 1536 ---------------------------------------- All Dot Size = 347136 Limit Dot Size = 345600 !!! Over 1536 dot ( = 240 x 6 )
もっとも、FOMAではどこまで持てるのか、その情報がないんだけど。mova、505i あたりでは 240 x 240 x 6 dot ぐらいで怪しくなり始めるという話を聞いてるわけですが。90xi はともかく、70xi あたりは 505i と似たところもあるのかしら。だとしたら、現在作成中のアプリはマズイな…。オーバーしてる…。一応こまめに、画像をロード・廃棄しておくか…。
[ ツッコむ ]
#5 [tv][movie] スパイダーマン2を見た
TVをつけたら流れてた。作業しながら鑑賞。
参っちゃうな。やっぱりアチラは凄い。アクションシーンのほとんどはCGアニメとして見るべきかもしれないのだけど。アニメだとしても、日本じゃたぶんコンテすら描けないのでは。映像化なんて夢また夢。これは単に市場の大きさや予算の違い故に勝てないのか。それとも発想レベルで勝てないのか。とかそんなことをもやもやと考えてしまうぐらい凄い出来。参った。
参っちゃうな。やっぱりアチラは凄い。アクションシーンのほとんどはCGアニメとして見るべきかもしれないのだけど。アニメだとしても、日本じゃたぶんコンテすら描けないのでは。映像化なんて夢また夢。これは単に市場の大きさや予算の違い故に勝てないのか。それとも発想レベルで勝てないのか。とかそんなことをもやもやと考えてしまうぐらい凄い出来。参った。
[ ツッコむ ]
#6 [iappli] タイトル画面やメニュー関係を変更
演出追加要求をこなしてたら容量がヤバイことに。
プログラム容量を削減すべく作業。サブルーチンコールをなくすと40byte前後節約できる感じだが、そうそう無くせるものでもなく。if ( ) { } else if ( ) { } を if ( ) { } if ( ) { } にしてみたけれど、それだとかえって容量が増える場面も。switch - case も if 文にしてみたが、もしかするとこのへんコンパイラで最適化されて容量的にはあまり変わらないのかしら。よく判らん。
最適化ツールを通したり、最後に 7zip で圧縮し直してるので、手を入れたことが全て容量削減の効果として見えてくるわけでもなく。作業すべき内容が把握しづらい。…一番効果があるのはやはり文字列データをスクラッチパッドに逃がすことなんだろうか。しかしそれをやってしまうと(以下略。
プログラム容量を削減すべく作業。サブルーチンコールをなくすと40byte前後節約できる感じだが、そうそう無くせるものでもなく。if ( ) { } else if ( ) { } を if ( ) { } if ( ) { } にしてみたけれど、それだとかえって容量が増える場面も。switch - case も if 文にしてみたが、もしかするとこのへんコンパイラで最適化されて容量的にはあまり変わらないのかしら。よく判らん。
最適化ツールを通したり、最後に 7zip で圧縮し直してるので、手を入れたことが全て容量削減の効果として見えてくるわけでもなく。作業すべき内容が把握しづらい。…一番効果があるのはやはり文字列データをスクラッチパッドに逃がすことなんだろうか。しかしそれをやってしまうと(以下略。
[ ツッコむ ]
以上、1 日分です。