ゲームプログラムなら俺に聞け28
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2013/04/21(日) 15:41:16.06なんでも聞いてちょ
【前スレ】
ゲームプログラムなら俺に聞け27
http://toro.2ch.net/test/read.cgi/tech/1356617503/
次スレは>>950が立てること。
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
0153デフォルトの名無しさん
2013/05/21(火) 12:48:00.74そういうのは経験積むしかないよね？
0154デフォルトの名無しさん
2013/05/21(火) 13:51:38.03それもだし、環境と制限による
0155デフォルトの名無しさん
2013/05/22(水) 10:04:23.87関係するし必要条件だと私は思うのですが
どう考えたら関係ないと思えるんでしょうか？
0156デフォルトの名無しさん
2013/05/22(水) 19:40:26.96質問者が抱えている問題は下記の2つ。
これらが意図したようにプログラムされていないために問題が現れている。
・当たったかどうかをどのように判定しているか
・当たっていた（めり込んでいた）場合、どのように解消するか
これらはなにもアクションゲームに特有の問題ではい。
シューティングでもRPGでもパズルでも、いろいろなゲームで根幹の問題だ。
初心者が「地面の上をただジャンプするだけのもの」を作る場合、
キャラが画面の縦軸座標のある値よりも下には行かないようにプログラムする。
このようなキャラと地面との当たり判定とその解消方法は、
ジャンプした時のキャラとブロックとのそれらとは根本的に異なる。
（経験と知識を積めば、一般化して、地面に対しても同じ処理で解決しようとするだろうが、
それはブロックとの当たりについて知識や経験を得た後だ）
方法が異なるので、「地面の上をただジャンプするだけのもの」を作ることで得た知識や経験は、
質問者が今現在抱えている問題を解決しない。
よって、「地面の上をただジャンプするだけのもの」が作れるかどうかを問うことに大した意味はない。
それと、そもそも質問者はジャンプなどをすることはプログラムできているはずだ。
ジャンプしてブロックに当たった時の処理で問題が起きているのだから。
ジャンプするからには、普通は地面が用意されていると思う。
「地面の上をただジャンプするだけのもの」は既にプログラムできていると思わないか？
0157デフォルトの名無しさん
2013/05/22(水) 22:04:43.020158デフォルトの名無しさん
2013/05/22(水) 22:14:28.04この長さが必要だったかどうかは、私にはわからん。
もっと短くても >>155 が私の考え方がどういうものか理解してくれたのなら（納得はしないだろうが）、
この長さは不必要だったかもしれん。
もしかしたら、>>155 が理解するにはこの長さが適切だったかもしれん。
私は >>155 の返答から、やや丁寧に書いた方が良いだろうと判断した。
本当にこの長さが必要だったかどうかは >>156 に聞いてくれ。
0159デフォルトの名無しさん
2013/05/22(水) 22:15:42.72自分に聞いてどうするよ・・・orz
本当にこの長さが必要だったかどうかは >>155 に聞いてくれ。
0160デフォルトの名無しさん
2013/05/22(水) 23:50:38.600161デフォルトの名無しさん
2013/05/23(木) 09:22:32.29>方法が異なるので、「地面の上をただジャンプするだけのもの」を作ることで得た知識や経験は、
>質問者が今現在抱えている問題を解決しない。
本当にそうでしょうか？
>「地面の上をただジャンプするだけのもの」は既にプログラムできていると思わないか？
思わないです。
0162デフォルトの名無しさん
2013/05/23(木) 12:49:52.69> 本当にそうでしょうか？
本当にそうです。
それでは解決しません。
解決すると言うのなら、それをはっきりと質問者 >>116 に言うべきです。
「地面の上をただジャンプするだけのもの」を作る時に＊＊という処理を使うが、
それを〜〜のように改良すれば今回の問題は解決する、など。
> 思わないです。
矛盾しています。
あなたは >>151 で作れたかどうかを訊いている。
プログラムできていないと思っているのなら、>>151 の質問は無駄です。
質問者にわかりきった無駄な逆質問をするより、上記のようなアドバイスを
はっきりと示した方が質問者にとって良いこととは思いませんか。
0163デフォルトの名無しさん
2013/05/23(木) 13:03:54.21>本当にそうです。
>それでは解決しません。
必要条件と必要十分条件を取り違えていませんか？
それ「だけ」では解決しないのは私も分かっています。
>矛盾しています。
何が矛盾なのですか？
必要条件である「ブロックも段差もない平坦な2Dアクション作れる」
を満たしているかどうかを確認するのは絶対に無駄なのでしょうか？
0164デフォルトの名無しさん
2013/05/23(木) 15:54:19.190165デフォルトの名無しさん
2013/05/23(木) 16:24:39.560166デフォルトの名無しさん
2013/05/23(木) 17:41:50.93何ひとつとして有用な情報がないｗ
0167デフォルトの名無しさん
2013/05/23(木) 17:52:45.960168デフォルトの名無しさん
2013/05/23(木) 18:01:28.69「地面の上をただジャンプするだけのもの」を作れなくても、
たとえばシューティングゲームで当たり判定の処理をプログラムしたことがあれば十分。
シューティングゲームを作ったことなくても、他のものでもいい。
ゲームでなくても、GUIのツールを作る過程で本質的に同様の処理をする場合もある。
よって、>>116 を解決するのに「地面の上をただジャンプするだけのものが作れる」は
必ずしも必要ではない。
>を満たしているかどうかを確認するのは絶対に無駄なのでしょうか？
あなたは「地面の上をただジャンプするだけのもの」は既にプログラムできているとは思わないと
>>161 で言っている。
まだプログラムできていないと思っているのなら、確認の必要はない。
これは既にプログラムできているという前提で、
さっさと「地面の上をただジャンプするだけのもの」を作ることで
問題がどう解決するのかを提示すべき。
既にプログラムできているかどうかあなたの中で判断できないのなら、確認には意味がある。
0169デフォルトの名無しさん
2013/05/23(木) 19:36:44.730170デフォルトの名無しさん
2013/05/23(木) 20:19:37.65その周辺の他の人のアドバイスと合わせれば、解決の糸口が見えて来るのではないかと思っている。
しかし、>>151 が「地面の上をただジャンプするだけのもの」を作れることが
解決に繋がると考えているのなら、それをもっと詳細に説明してあげた方が良いと俺は思うぞ。
俺は、質問者は既に「地面の上をただジャンプするだけのもの」はプログラムできていると思っている。
それが解決に繋がるのなら、質問者はぜひ知りたいと思っているのではないかな。
>>169
そう思われるのは心外なので、>>151 に対するレスはもうしない。
0171デフォルトの名無しさん
2013/05/23(木) 20:27:48.94そもそもマリオでブロックの角に当たったら滑って登るって普通だったろ。
0172デフォルトの名無しさん
2013/05/23(木) 20:31:27.27バカには無理なんだから金でもつかわんとなんも出来んぞ
0173デフォルトの名無しさん
2013/05/23(木) 20:41:31.43質問者の>>116がただサイトからコピペしただけで
「ブロックも段差もない平坦な2Dアクション」の部分すら理解してない
という可能性を>>151は示唆してるというだけなんじゃないの？
0174デフォルトの名無しさん
2013/05/23(木) 20:51:27.93学校のテストで点をとるためだけに勉強してた奴はこの辺りで引っかかりはじめる
3D行くと三角関数使うようになるし
数学苦手な奴にはもう無理
0175デフォルトの名無しさん
2013/05/23(木) 21:01:07.39これがもし本当にできるのであれば
キャラが画面の縦軸座標のある値よりも上には行かないようにプログラムすれば天井ができ
キャラが画面の横軸座標のある値よりも右には行かないようにプログラムすれば壁ができ
キャラが画面のある座標には行かないようにプログラムすればブロックできるじゃんやったな
0176デフォルトの名無しさん
2013/05/23(木) 21:12:38.79一度は実際に検証してみてからレスした方がいいと思う
0177デフォルトの名無しさん
2013/05/23(木) 21:20:03.21いや、だからそういうところから質問者が自分で試してみろってことだよ
何で下は上手く行くのに上がダメなのか考えればいつか自ずと答えが出るだろ
それが理解するってことだろ、答えだけ知ろうとするなよ
って俺は思うんですけど厳しいですかねｗｗｗｗｗ
0178デフォルトの名無しさん
2013/05/23(木) 21:42:20.52> 質問者が自分で試してみろ
いや、そういう考えなら、俺も同感だ。
別に笑うことでもない。
でも、そういう事を「最初に」はっきりと質問者に向かって言わないと、
遠回しな言い方では伝わらないよ。
ただ、それは回答者の方も一度は検証してからレスした方が良いというのと別問題だとは思う。
0179デフォルトの名無しさん
2013/05/23(木) 21:45:29.39いくら考えて上等な反論並べたところで
誰も認めやしねーよ。うざいガキと思われるだけ。
0180デフォルトの名無しさん
2013/05/23(木) 21:49:42.21お前は誰と戦ってるんだよ
0181デフォルトの名無しさん
2013/05/23(木) 22:08:29.73つまり貴方様は既に検証済みということですよね？
参考にそのプログラムを見せていただけませんか？
0182デフォルトの名無しさん
2013/05/24(金) 02:01:56.77いや、いいけどさ過疎だし
0183デフォルトの名無しさん
2013/05/24(金) 07:52:18.24入社して研修を受けてた頃からさんざんやってるから、いろんなことを検証してきた。
俺のアドバイス >>146 の「接する方向を考慮すること」もすぐにやらされるから検証済み。
君だってアクションゲームを作ったことがあるのなら、同じ事を一度はやってるはずだ。
それに例えば「アクションゲーム 当たり判定 ブロック」などでググれば、
俺（や、その周辺の人）のアドバイスの実例や、もっと詳細な解説はいくらでも見つかる。
あらためて俺が自分のプログラムを公開する必要性がない（面倒だし）。
俺のプログラムでなければ参考にならない、なんてことはないだろう。
それに、これくらいのキーワードは誰にでもすぐに思いつくはずだ。
君だって思いついただろう（この程度も思いつかないなんて言うなよ）。
なのに何故ググろうとしない？
>>175 のように、「これより右には行けない」、「これより下にはいけない」、
「これより右にはいけない」、「これより左にはいけない」と処理することで
ひとつのブロックを表現しようとすることも研修中にやっている。
そして、これではうまく処理できないこと経験している。
キャラの移動速度の関係でブロックにめり込んでしまった（しまう）場合、
そのキャラをどこに移動させればいいのか判断できないからだ。
ブロックの上側に強制的に移動させればいいのか？
それとも左側に強制的に移動させればいいのか？
結局、接する方向を考慮する必要がある。
「これより下にはいけない」これひとつだけなら問題ない、上側に移動させればいい。
>>175 は「できる」と言っているが、俺は研修中できなかった。
まぁ >>175 も「できた」とは言っていないが。
0184デフォルトの名無しさん
2013/05/24(金) 08:43:46.08実りないしよそでやれよ
0185デフォルトの名無しさん
2013/05/24(金) 09:52:26.39要約すると
「昔に検証したことだから今は手元にソースない」
ってことですね分かりました
0186デフォルトの名無しさん
2013/05/24(金) 10:30:23.29>入社して研修を受けて
入社を始点に物事語ってる時点でお前様の程度が知れる
お前様を採用して会社も（お前を育てるのに）さぞ苦労したろうな
0187デフォルトの名無しさん
2013/05/24(金) 12:36:28.35そう。
現時点で示せるコードは何一つ手元にないし、これから >>181 のために書くのも面倒だ。
学びたいのなら、ネット上にもっと良いコード片や資料はいくらである。
そちらを参考にしてくれ。
>>186
研修云々を話してしまったのは俺のミスだ。
このスレにはどうでもいい関係ないことだった、申し訳ない。
忘れてくれ。
0188デフォルトの名無しさん
2013/05/24(金) 13:55:25.18何言ってんの
0189デフォルトの名無しさん
2013/05/24(金) 15:06:31.340190デフォルトの名無しさん
2013/05/24(金) 17:01:29.710191デフォルトの名無しさん
2013/05/24(金) 18:54:53.83全然関係ないけど、人を育てるのはどの会社、どの分野でもそうとう大変だよ
今ちょうど俺が新入社員相手に四苦八苦してるところ
ゲーム全く関係なくて、エクステリア関係の小さな問屋だけど
0192デフォルトの名無しさん
2013/05/24(金) 19:08:56.150193デフォルトの名無しさん
2013/05/24(金) 19:12:11.60ごめんなさい、がんばる
0194デフォルトの名無しさん
2013/05/24(金) 19:19:53.460195デフォルトの名無しさん
2013/05/24(金) 19:26:48.18つか学生上がったばかりで即戦力の実力あるなら起業するし
0196デフォルトの名無しさん
2013/05/24(金) 19:33:50.900197デフォルトの名無しさん
2013/05/24(金) 20:45:42.66正直うらやましい
0198デフォルトの名無しさん
2013/05/24(金) 21:54:36.72見栄張ってごめんなさい
0199デフォルトの名無しさん
2013/05/31(金) 06:07:49.35ゲームって、オブジェクトAがオブジェクトBを参照する必要が出てくる事がよくありますよね。
これを単純に、親への参照を持つ事によって解決しようとすると循環参照となり、
インターフェイスが多くなりがちだし、良い設計とは言えません。
何かうまい方法はないのでしょうか？
class Manager{
public:
vector<Object> getObjects() { return objects_; }
private:
vector<Object> objects_;
}
class Object{
void hoge(){
vector<Objects> objects = pManager_->getObjects();
...
}
private:
Manager* pManager_;
}
0200デフォルトの名無しさん
2013/05/31(金) 06:47:43.640201デフォルトの名無しさん
2013/05/31(金) 08:31:43.200202デフォルトの名無しさん
2013/05/31(金) 08:42:10.410203デフォルトの名無しさん
2013/05/31(金) 08:46:47.83FacadeというよりMediatorになる気がしますね。
Mediatorは、メソッドをたくさん持った何でも屋みたいになるのが嫌なんですけど、この場合はこれがベストなんですかね。
>>200もMediatorみたいな事になるのかな。
0204202
2013/05/31(金) 09:23:11.41たしかにMediatorは肥大するな
>>200はMediatorっていうよりプロトコルオブジェクトな気がする
なぜ参照するのかを考えて、そこに必要なデータを別のクラスに持たせて引数で扱うとかか
なんにせよ間に緩衝材となるクラスが無いと不便ね
0205デフォルトの名無しさん
2013/06/08(土) 17:04:37.73例えば同じモンスターが複数出てくる場合、テクスチャも同じなわけだからモンスターの数だけテクスチャをロードするのはリソースの無駄だ。
サウンドに関しても同様。
しかし、俺は今回そういったモンスターなど動きのあるものも必要なパラメーター以外を使い回すという仕組みを思いつき、実装した。
どういうことかというと、例えば2Dゲームで同じ姿形のモンスターがそれぞれ任意のタイミングでAという動作をする場合、
モンスターごとにAの動きの定義を持たず、Aという単一の定義に対してフレームなどの状態を渡して描画するという仕組みだ。
0206デフォルトの名無しさん
2013/06/08(土) 17:21:20.190207デフォルトの名無しさん
2013/06/08(土) 17:21:43.37例えばモンスターに必要な情報は以下の通りだとする。
テクスチャ、サウンド、フレームや状態ごとの描画やサウンド再生定義、基本値(最大HPなど)、個々の値(現在HP、フレーム、状態)
室町時代には仕組み自体が確立されていなかったから、モンスターごとにこの全情報を持っていた。
しかし明治に入ると西洋の画期的な仕組みが取り入れられ、テクスチャやサウンドは同一のものなら使い回すようになった。
しかし今回俺は、フレームや状態ごとの描画やサウンド再生定義をも使い回すような仕組みを編み出したわけだ。
今はさらにその先の基本値まで使い回す仕組みを編み出そうとしている。
もしこれが完成すれば変化する値以外を完全に抽象化できるから大きなリソースの節約になる。
0208デフォルトの名無しさん
2013/06/08(土) 17:27:29.340209デフォルトの名無しさん
2013/06/08(土) 17:37:22.570210デフォルトの名無しさん
2013/06/08(土) 17:40:57.33Translateかな
0211デフォルトの名無しさん
2013/06/08(土) 17:54:50.80へんに口語を使わず、真面目に論文に起こしてくれ
そうすれば馬鹿な俺でも何を言ってるのか、何が画期的なのか理解できると思う
0212デフォルトの名無しさん
2013/06/08(土) 18:23:47.510213デフォルトの名無しさん
2013/06/08(土) 18:46:49.00キャラクタデータクラスの中に出てくるキャラごとの基本パラメーターとして
レベルごとのステータス
状態(立ち、必殺攻撃、よろけ)ごとのモーションのパラメーターのセット
(何秒硬直するか、どの攻撃判定を出すか、使うテクスチャ、当たり判定のサイズ、移動スピードなど)
攻撃判定のパラメーターのセット
(ダメージ基本値、ステータス補正の大きさ、当たり判定のサイズ、移動スピード、ガード可能か、消滅までの時間、消費MPなど)
などを格納
キャラクタクラスには
使うキャラクタデータクラスの番号
今のHP、MP
今の座標
今の状態
今の状態になってからの経過時間
などを格納
キャラクタデータクラスはマップ変更で出てくるキャラクタが変わらない限り変更ないから固定値
キャラクタクラスはキャラクタごとに座標とかの変更されるパラメーターを入れる
こんなの基本とまでは言わないけど
Androidみたいハード性能が低いもので作ってたら
自然にたどり着くレベル
0214デフォルトの名無しさん
2013/06/08(土) 18:48:48.52これだから素人は困る
最低限基本情報はクリアしてから言語始めろよ
0215デフォルトの名無しさん
2013/06/09(日) 01:29:30.980216デフォルトの名無しさん
2013/06/09(日) 03:44:27.650217デフォルトの名無しさん
2013/06/09(日) 07:20:49.840218デフォルトの名無しさん
2013/06/09(日) 09:57:52.98オブジェクト指向言語なのに
0219デフォルトの名無しさん
2013/06/09(日) 10:00:06.510220デフォルトの名無しさん
2013/06/09(日) 10:35:46.49オブジェクト指向設計を念頭においた仕様を備えた言語を使っているのに
と言い換えれば伝わりますか
0221デフォルトの名無しさん
2013/06/09(日) 10:45:56.43javaで手続き指向を書けるしCでオブジェクト指向を書ける
言語のサポートは書くのが楽かどうかというだけで
オブジェクト指向的な考え方が出来るかとか使うかは別の問題だ
概念と実装手段の切り分けが出来てないよ
0222デフォルトの名無しさん
2013/06/09(日) 11:09:36.40「せっかくの」 オブジェクト指向言語なのに
と言えば良かったと思うよ
0223デフォルトの名無しさん
2013/06/09(日) 15:42:42.280224デフォルトの名無しさん
2013/06/10(月) 03:00:14.98ってSmalltalk使いがゆってた
0225デフォルトの名無しさん
2013/06/10(月) 09:12:20.55そら本物やな
0226デフォルトの名無しさん
2013/06/15(土) 00:21:06.90動的型宣言もいまいち冴えてませんねえ
0227デフォルトの名無しさん
2013/06/15(土) 01:28:19.62C++=キリスト教
java=イスラム教
0228デフォルトの名無しさん
2013/06/15(土) 09:30:35.700229デフォルトの名無しさん
2013/06/15(土) 09:45:09.760230デフォルトの名無しさん
2013/06/15(土) 10:55:05.03なにこれ？
0231デフォルトの名無しさん
2013/06/15(土) 11:06:49.180232デフォルトの名無しさん
2013/06/16(日) 01:38:09.48おいObjective-C忘れんな
0233デフォルトの名無しさん
2013/06/16(日) 04:21:25.25あのとき、Begin〜end間で描画のために別の関数を呼び出した場合、
pSprite->Draw()に渡すアドレスの変数がローカルだと上手く描画されないと書きましたが、
今回はその状態でないにも関わらず描画されないという不可解な現象が発生しました。
今回は簡単な描画テストのため、Begin〜End間に自作関数を含んでいませんでした。
timebuf = timeGetTime();
Draw();
BOOL Draw()
{
D3DXVECTOR3 pos, center;
RECT rc;
クリア〜Begin〜End〜Present
return TRUE;
}
これだとクリア時の塗りつぶしは指定した色が反映されるのですが、テクスチャが全く描画されないのです。
ちなみにtimebuf = timeGetTime();をコメントアウトすると描画されるのです。
何度も確認しましたがこの一行でテクスチャが描画されたりされなかったりするのです。
結果的に、Draw()関数内の全ての変数にstaticを付けることで解決しましたが、どうにも不可解です。
ただそれでも何とか希望通りの動作をするようになったのは皆さんの惜しみ無いお力添えのお蔭です。
ありがとうございました。
0234デフォルトの名無しさん
2013/06/20(木) 00:25:46.50例えばキーリピート間隔2フレームの場合、
カーソルの右キーと左キーが1(mod 2)フレーム差で押されたとき
1フレーム毎に左右のキーが押されたものと等価になるので
カーソルキーに連動して動かすキャラが振動してしまいます
通常キーリピートを実装する際はどんなやりかたでこの問題を解決しているのでしょうか
ちょっと重いですが排他関係にあるキーが同時推しされている場合、キーリピートでキーのアップダウンイベントを
発行するのを抑制するくらいしか思いつきませんでした
0235デフォルトの名無しさん
2013/06/20(木) 06:56:02.69１．解決せず仕様としてしまう
→←＿＿＿→←→←→……
２．最後に押されたキーのみキーリピートの対象にする
→←＿＿＿←←←……
３．キーの状態が一箇所でも変化したらキーリピート状態をすべてのキーに対してクリアする
→(←+→)＿＿＿(←+→)(←+→)(←+→)……
のうち好きなのを採用すればいいんじゃないかと思ったが
もしかしたらそれじゃまずいのかもしれんな
0236デフォルトの名無しさん
2013/06/20(木) 07:29:26.14普通WindowsやLinuxなどでは >>235 の2番の仕様だよ。
他の OS や環境は知らんが。
あるキーXが押され、リピート開始までの時間に他のキーが押されたら、
そのXのリピート開始をキャンセルする。
リピート開始できるキーは一度にひとつだけ。
もし俺が作るなら、タスクシステムにして、あるキーXが押されたら、
リピートタスクをそのキーXのキーコードで初期化して再生する。
そのキーXが離されたり、他のキーが押されたら、再生中のリピートタスクを破棄する。
0237デフォルトの名無しさん
2013/06/20(木) 10:47:00.171フレームで2入力受け入れてるくせに
なんで結果の処理は2つ同時にやらねーんだよ？
プラマイ0でキャラ移動処理やらないのがスジだろ
0238デフォルトの名無しさん
2013/06/20(木) 10:47:08.92一度にひとつだけならタスクにする必要無い気がするけど
俺ならキャラを動かすところでキーダウンで調べて排他にして
その上でキーリピートで動かすみたいな処理にするな。楽だから。
0239デフォルトの名無しさん
2013/06/20(木) 10:51:21.30キャラ移動処理する前に
今回の入力の累積取って
それから移動処理させれば済む話
たまたま正反対のキー操作の例だけど
他に弾発射だの独立したキーリピートが複数あっても
粛々とやればよいだけ
排他とかいじってると、独立系キーとかの区分けがシッチャカメッチャカになるぞ
0240デフォルトの名無しさん
2013/06/20(木) 11:12:05.91俺が画面内のキャラを操作する場合、
アップイベントがあればフラグ立てて、ダウンイベントがあればフラグを下ろす。
フラグが立っている間は決められたインターバルごとにその行為を実行する。
0241デフォルトの名無しさん
2013/06/20(木) 12:41:18.05> 一度にひとつだけならタスクにする必要無い気がするけど
すまん、言葉が足りなかった。
他の処理もタスクでやってるのなら、リピートの処理も、という意味。
俺の場合は、アニメーションやサウンドなどほとんどのものをタスクで処理してる。
質問者もすでにタスクシステムを構築しているのなら、リピートもそれに組み込んだ方が楽だ。
0242234
2013/06/21(金) 00:34:32.08そいつにキャラクラスに飛んでくるキーアップとダウンのイベントリスナーを登録させることで
決められたリピート間隔でアップダウンイベントをキャラに投げさせることで
擬似的にキーボードが連打されている状況を作り出すことで実現しています。
>>235-236
2番だと移動しながらの弾丸フルバーストができぬのです
>>238, ...All
自キャラを出来るだけ単純化したいため
ゲーム自体に関係のない作りこみ部分のフラグ・変数等は極力減らしたいのです
そのため処理キーリピート処理はカプセル化したいというのが動機でして
ライブラリ部分で苦労しておいて実際のゲーム作りは楽したい
>>237
タイミングによってフレーム毎に
[↑D][↑U↓D][↑U↓D]… // U=Up, D=Down
というイベントが飛んでくることになるので、
1フレームに注目した場合↑↓一方のキーが押されているということになるので
エスパーしないと無理ということに
こういう処理をどうしてるのかわかるような
小さなソースコードないでしょうか・・
0243デフォルトの名無しさん
2013/06/21(金) 01:06:17.550244デフォルトの名無しさん
2013/06/21(金) 01:34:05.73十字キーで1つ
ABCDボタンで1つ
のみ連射が有効じゃダメなの？
ボタンのグループを作ってそのなかで一つのみ有効とか
0245デフォルトの名無しさん
2013/06/21(金) 02:26:59.08というかキャラの移動がリピート処理って珍しいと思う。弾丸ってことはシューティングなのかな？
0246デフォルトの名無しさん
2013/06/22(土) 23:19:35.70あり得ないんだけど。押しっぱなしでリピートトリガーにするなら
少なくとも10〜20フレームぐらいは取らないとだめでしょ。
20フレームウェイトしたって0.3秒だから現実的だと思うけど。
0247デフォルトの名無しさん
2013/06/23(日) 10:09:39.71質問者は「例えば」と言っているのだが。
開始時刻をずらして並進する２つのキーリピートによる問題を
わかりやすく説明しただけだと思う。
0248デフォルトの名無しさん
2013/06/23(日) 16:22:03.600249248
2013/06/23(日) 16:22:40.010250デフォルトの名無しさん
2013/06/24(月) 01:16:38.190251デフォルトの名無しさん
2013/06/24(月) 01:51:23.420252デフォルトの名無しさん
2013/06/27(木) 00:47:44.18それに関連して、リソースをどの段階で読み込めばいいか分からなくなってきた。
具体的には2DRPGでメニュー出したときにマップが透けて見えてるような状態。
マップを描画しなきゃならないからメニューもマップで管理するの？
メニューで使うアイコンとかのリソースってメニューを表示するたびに読み込むの？
それともゲーム開始時に全部読み込むんですか？
■ このスレッドは過去ログ倉庫に格納されています