ゲームプログラムなら俺に聞け33©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
メモってたら変なこと書いたわ
気にしないで
>>324 >>323
角運動量の方の求め方おかしくない?
半径ベクトル radius と外積させるのはタダの運動量 momentum じゃなくて、
その momentum の半径方向と直交する成分のベクトルじゃないか? >>323
すまん、>>326 は無視してくれ。
momentum と外積すれば、sin によって直交方向の成分が(適切な割合で)使われるね。 >>323は剛体のある1点に運動量が与えられた時
剛体の並進運動量にどの程度反映させるかについて
剛体の中心方向(半径ベクトルと垂直)の成分のみ反映させるようにしており
これは正しい形に見える
ただ、以下の状況を考えたときに正しく動かない気がする
・半径1の球があり原点に配置されている
・球は拘束によりY軸のみ移動出来る、回転は出来ない
・球の側面(1,0,0)にスプリングを取り付け
(0,1,0)方向の運動量が常に与えられるようにする
>>323だと球の側面(1,0,0)の(0,1,0)方向の運動量は
垂直成分がゼロになる為、回転分が100%になり並進分はゼロになる
すると上の状況だと球はいつまでも動かず静止を維持することになる
しかし現実では球は上に移動するよね
この違いが説明出来ないの 現実でも上には移動はしないのかな?
上に移動するメカニズムが説明出来ないし >>329
運動を制限するということは、制限された方向に運動しようとすると、
そこから逆向きの力、つまり反作用を受けると言うことだ。
だから、考慮しなきゃならないベクトルが増える。
例えばそれは、滑らかな床の上に立方体のブロックを静止させておき、
ブロックの重心からブロックの上面に下ろした垂線の足に対して、
床と平行な方向に力を加えた際のブロックの運動を剛体力学的にはどう説明するか、
という問いと本質的に同じだよ。
ただ、これはもうゲームプログラムの問題ではなく、純粋に物理学の問題だ。
あっちの板(スレ)で訊いた方が適切なアドバイスが得られると思う。 そうします
つき合ってくれて
ありがとうございました 物理もいいけど、一通り物理式理解したら戻っておいで
何故って?
本当の物理計算じゃリアル感が出ないからさ。 リアル感云々より
処理の重さが課題
レンガを5x5で積んだだけで
ガクガクになる
有名ライブラリとか
中身どうしてんだろう
割と絶望的 >>334
有名というと、BulletとかODEとか?
参考までに教えてください https://codepen.io/anon/pen/OxBpWW?editors=0010
↑テストコード(ChromeとFirefoxで確認)
画面の幅(width)や高さ(height)やカメラの画角(fov)が変わっても
panel(一辺の長さがwidthまたはheightの短い方と同じ)が
画面からはみ出さないぎりぎりに収まるカメラのポジションの
計算式を教えてください
カメラの位置は正面斜め45度(x=0, y=z)です
↓関係ありそうだけど理解できなかったページ
https://qiita.com/mizar/items/2cf06ffd49248d9bee63 unityは知らんので
一般的なdirect3dの射影変換で説明すると
カメラの視推台のwidthとheightは
以下の式で求まる
width/2 = depth * tan(fov_x軸/2)
height/2 = depth * tan(fov_y軸/2)
今回はwidthまたはheightが決まっており
depth(カメラから対象オブジェまでの距離)
を求めたいとのことなので
上の式からdepthについて求めればいい
depth = (width/2) / tan(fov_x軸/2)
または
depth = (height/2) / tan(fov_y軸/2)
答えるにあたり↓を参照した
https://msdn.microsoft.com/ja-jp/library/bb206341(v=vs.85).aspx >>296
gitでオナニーしててもなんにもいいことないけど頭大丈夫? なんで過疎ったんだろうな
スマホスレとか賑わってんのか ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が3分の2を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ 3次元空間中に、赤い点がN個、青い点がM個、存在しています。
ある赤い点から見て半径ε(>0)の球の中に、青い点が1つでも存在するような、赤い点の数を数えることを考えます。
N>>Mのように一方が他方に比べて十分多いのであれば、
多い方の点でKdツリーを作って、少ない方で半径εのクエリしていけばいいと思います。
一方で、NとMが同数程度の場合、上のやり方では時間が掛かってしまいます。
一方だけでKdツリーを作るのではなく、両方のKdツリーを作って (Kdツリーでなくても、なにか適切な空間構造を作って)
2つのツリーを比較しながら、一度に全ての点をクエリすることができれば速くなるのかなと思っていますが、
具体的にどうやるかはわかっておりません。
どなたかご存知の方、教えて頂けないでしょうか。
ヒントやこういう単語で検索してみたらどうかなど、なんでもいいのでお願い致します。 >>345
ありがとうございます。
ちょっとむずかしそうですが、頑張ってみます。 いきなり3次元のヒットチェックは実装が難しいから、
まず2次元のヒットチェックを理解してからの方がいいと思う おまいら高校の数学どれくらい覚えている?
今見返してみると微分・積分、指数対数、結構難しいぜ 確率統計は大学入試に出なかったので授業ではやらなかったけど、
教科書はあったので自学した。それを一番憶えてるかなw こんなことを聞くのはバカかもしれないが、ゲームに全く関係ない仕事してるがまともなブラウザゲー作れるかな。
ゲームやっぱ楽しい まともってのがどの程度を指すかによる
絵が一切出てこないノベルゲーで分岐一つだけとかなら一瞬で作れるようになるよ ブラウザゲーも昔のCGIからすると随分進歩したしな 351
無理でしょ。
作れるようになるのは質問するよりも先に Google で
ブラウザゲーム ソースコード
とか検索する奴。
かつ、「どのサイトがお勧めですか?」とか聞かずにとりあえず何か試してみるヤツ。 福島県白河市のビーチバスケットボール大会
1位 白男川温斗 シラオカワハルト
2位 白羽根公浩 シラハネキミヒロ
3位 焼谷好晴 ヤキタニコハル
4位 働凪々子 ハタラキナナコ
5位 黒駒架音 クロコマカノン
6位 黒明恵夢 クロアケエム
7位 神宮寺隼杜 シングウジハヤト
8位 波須田音 ハスダオン
9位 進司長月 シンジナツキ
10位 建島花成 タテシマカナリ
11位 榛川木音 ハイカワコトネ
12位 八朝小菜実 ヤトモコナミ
13位 新梅 シンウメ
14位 新広多夏子 シンヒロタカコ
15位 黒米初逢人 クロヨネハアト
16位 羽実春陽 ハジツハル
17位 白窪藍玖 シラクボアイク
18位 倉林醜人 クラバヤシシュウト
19位 矢佐間周介 ヤザマシュウスケ
20位 羽塚木江路 ハヅカキコウジ
21位 八野田椛澄 ハチノダカスミ
22位 安川恵羅 ヤスカワケイラ
23位 橋羽早介 ハシバサスケ
24位 仁香暖 ジンコハル
25位 久村恵都子 クムラエツコ
26位 八重岳夏花 ヤエダケナツカ
27位 長田聖康 ナガタキヨヤス
28位 武名市 タケナイチ
29位 畑石杏乃 ハタイシキョウノ
30位 泰丘環樹 ヤスオカタマキ 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
5548W 303です。
お礼忘れてました。回答ありがとうございました。
正直directX触れるほど自学進んでいないのですが、エンジン使わずにゲーム作れるようになろうと頑張っています。 ドラクエ10のプレイヤーから質問。
ドラクエ10でアイテム収集(キラキラマラソン)していると、古いバージョンのゴミアイテムが沢山出てきて、
いちいち捨てるのも面倒なくらいです。ゲーム内の不要な情報は削除整理できないのでしょうか。
>つき [KA360-785]
>2018/09/29 09:17
>[通報する]
>提案から来ました。
>調査することによってどれだけのメリットがあるのですか?
>持ち物整理は個人の自由ですよね?
>あなたの言う調査にどれだけ手間がかかるか考えただけで分かるのにそれを運営にやらせるのですか?
オンラインゲームでの、『全プレイヤーの道具と装備の使用率と投棄率』を調査するのは困難ですか? >>362
億単位の投資資金とゲーム会社へのコネがあれば超簡単だよ >>362
>オンラインゲームでの、
>『全プレイヤーの道具と装備の使用率と投棄率』
>を調査するのは困難ですか?
技術的には可能だけど
運営側にコストを掛けて
実装するメリットがあるかどうかの問題 コストっていうほどのもんでもないだろw
使用率も投棄率もデータベースから簡単に引っ張ってこれる 個人で作ってるスマホゲームならコストもたかが知れてるかもしれないけど
それなりの規模だと部外者にコストの見積りは難しい
データベースから引っ張ることしか考えてないような奴には到底不可能だ 何言ってんだか・・・
ゲーム上のすべてのデータはデータベース上に乗っかってんだよ
つまりゲーム通さなくてもデータベース参照して様々な統計資料を作れる
データベースが分かればだれでも可能なレベル データベースが理解できなくて
マスターIDが増えるたびにプログラム直してコンパイラし直してるアホを思い出した コスパはコストだけじゃなくて
パフォーマンスとの比だからな
いくら実装コスト小さくても
「俺が知りたい」っていう
ユーザひとりのためだけに絶対やらんだろ ユーザがデータベースにアクセス出来るようにAPI提供してるゲームメーカーもあるよね
でもDQ10の話は質問者も回答者もDQNだと思うw DQ10くらいの規模でデータベースから全ユーザーの統計取るようなアクセス許すなんて有り得ないと思うが
あ、自虐ネタか >>371
>いくら実装コスト小さくても
>「俺が知りたい」っていう
>ユーザひとりのためだけに絶対やらんだろ
このゲームすぐ持ち物いっぱいになるな
http://egg.5ch.net/test/read.cgi/dqo/1539336435/ 下記のようなメッセージシステムはどう実装しているでしょうか?
ttps://www.youtube.com/watch?v=Tx5xS9uTaqk >>362
DQは長期的に展開していきたい(集金していきたい)ぽいから、
不便に感じているなら、運営に問い合わせてみたら?
ヘビーユーザー(ゲームに貢いでくれる人)の意見が多ければ、対応して貰えると思うよ >>362
このあいだ出た「ドラゴンクエストXを支える技術」を読むと参考になるかもしれない
といってもその質問の直接の回答があるわけじゃないけど。
読んだ結果ふつうのシステムなので、質問の全ユーザのインベントリ調査は
ふつうに出来ると思う
もちろん開発・運営側ならだけど >>362
>オンラインゲームでの、『全プレイヤーの道具と装備の使用率と投棄率』を調査するのは困難ですか?
実際に調査しているらしいが?
冒険中に荷物がいっぱいになりづらいように種類を減らしたり、貰ってよりうれしいアイテムを増やしたりと、全体的に報酬を見直しました。
https://hiroba.dqx.jp/sc/topics/detail/05a70454516ecd9194c293b0e415777f/ 長文失礼します
3D描画エンジンを利用したゲームを作ってみたいのですが基礎的な部分を説明しているWebサイトや本ってありませんかね?
現状考えているゲームは
・3Dで描画するがUIは2D
一般的に言われるポリゴンモデルを描画してアニメーションさせたりするわけではない。あくまでスプライト+α程度を想定
・プラットフォームはPSP、PS3,PC(OpenGL)
前者2つの開発環境はLinux等のUNIX系OSになりそうなのでPCの支援ツール類はOpenGL系になるはず
・リアルタイム処理
質問者は
・MMDやBlenderの使用経験は少しある
頂点、面、法線、テクスチャUV座標くらいは一応判っているつもり
・ゲームや3DCGアプリケーションの開発経験はほぼない
・プログラミングは必要があれば趣味でやる程度
ググると
・高次元の情報ばかり出てくる
Unityで始めるゲーム開発みたいな記事や3Dアプリケーションの使用に関する記事はいっぱい出てくるけど
低次元の情報を見つけられない
・汎用的な記事が見つからない
「リアルタイムの3D表示とは」みたいな記事があるとありがたいけど特定のAPIのみを使用する記事ばかり出てくる
特定のAPIに依存した理解は移植時に障害となりうるので出来るだけ避けたい
頂点や面、描画までの基本的な処理の流れはどれも大差なさそうに思うのですが
ゲームの開発に限らず最近は基礎や論理を解説している記事が見つけられずに困ることが多くて・・・ githubにいっぱい転がってるから
ソースコード読めばいいんじゃないかな?
自分もショボいゲームエンジンのコードひっそり上げてる >>381
君はゲームを作りたいんじゃなくて、エンジンが作りたいんだと思うよ(´・ω・`)
ゲームが作りたいなら、とっくにunityで作ってるはず。スプライトの表示なんてunityならコード書く必要すらないんだから・・・ >>383
ソースコードを読み解くにも3Dプログラミングの知識が必要だと思うのですが
自分が知りたいのはその部分です。APIの使い方とかはマニュアルなりサンプルソースを見れば判るでしょうし
こういう基礎的なところをだろう理解で実装し始めると、ある程度進んでから大規模に書き直しみたいな事になりかねず
出来ればそういう事態は避けたいです(ゲームじゃないけど過去に経験あり)
>>384
Unityのページを見たらPS3もPSPもなかったからそれ以上調べていなかったけど
PS3に対応したUnity for PlayStationつーのがあるのか。PSPは非対応?とか
非正規の開発で使えるのかとかよくわからなかったです >>385
大規模な修正なんてあって然りさ。私は○o○o○o関連企業のSEでしたが、cobolではやっていけなくなりjavaで全てのコードを
3年がかりで移し替えた経験あります。プログラマ何百人といる大企業ですらこの有様。
ゲームは特に動かしたもの勝ちでっせ。1人制作ならコードの巧拙なんか二の次次。
どーしてもってなら「ゲームプログラマ覚えておきたい技術」。
この本の一番いいとこは、第一章でいきなり読者に倉庫番をコンソールで作れと強要するとこ。
こんな本他にはないし、この学び方が正しいと思う。 改めて調べていたらPS3は無改造で野良アプリケーションのは起動出来ないのか。だとすると優先度下がるなぁ
PS3担当予定だった部分は処理の破綻覚悟でWin/Linuxあたりでフォローするしかないのか
Unityについてもググっているけど
・使用条件がよくわからない
・動作環境がはっきりしない
・リアルタイム処理の見積もり方が出てこない
公式の製品ページ見てもライセンスなんてアンカーは見あたらないしみんな気にしないのかな
>>386
それって時代にそぐわなくなった古いシステムの更新ですよね?
個人の新規開発プロジェクトでしょっちゅう全面書き直しをしていたら破綻まっしぐらでは
ちなみにネットに転がっているソースコードで勉強するというのも罠があったりするから気をつける必要があって
根本からおかしい不適切なコードも転がっているし、理解が不十分な状態でそれを見破るのはかなり大変です
>ゲームプログラマ覚えておきたい技術
良いお値段のようですがおもしろそうなので探してみます PS3やPSPを含める意味ってなんだろ?OSが変われば使うべきSDKも変わるべ。また、PS3やPSPに他のOSを入れた場合の開発には、Unityは間違いなく対応してないぞ。
使用条件に関しては書いてあったと思うけど……ある程度の収益があればライセンスの購入が必要、そうでなければ無料でも使える(ただしロゴや機能等制限が生まれる)
処理の見積もり方は、各プロジェクトでやるしかないよなあ。
for PlayStationもSIEのライセンシーにならなきゃ使えないはず
ゲームプログラマになる前に覚えておきたい技術は、2Dまでに関しては基礎から表現のされ方を学べるな。3Dになると、紙面が足りないから独自のライブラリどうぞになるけど。
というか、ポリゴンやらテクスチャの概念が分かってればその後は、特定のライブラリを使用するしかなくなるのが当然なのだが。 ひとまずOpenGLやPSP開発関係のサンプル等を眺めています
>>388
PSPに期待するところは
・リアルタイム性を確保しやすい
・動作保証がしやすい
・ボタン類が標準装備
・実機を容易に入手可能
・ファームウェアをハックしないでも動かせる
あたりです。上3つをPCやスマホで実現するのは困難だと思いますし
収益性はないのでお金を払うのはよほどのメリットがない限り厳しいです
>処理の見積もり方は、各プロジェクトでやるしかないよなあ。
えぇぇ・・・プロファイラ自体はあるらしいけどそういうのを観察するには向かないのかよ
最近はリアルタイム処理とか重要視されないんかな。確かにスマホでリアルタイム処理とか現実的ではないとは思うけど >>389
各プロジェクトでやるしか無いと言ったのは、プロファイルを取れたとしても、それぞれのリソースをどれだけどこに割くか、どういう区切りで分類するかは各プロジェクト毎に変わるから。
ゲームであり、かつPSPのスペックで事足りる程度の事であれば、リアルタイム性や動作保証はPCやスマホでも充分かなー?
実機を容易に入手可能ってのは……たまたま近くにあるっていうなら分かるけど、俺の周りだと見付からないんだよなあ(故に同意し辛いし、生産を終えてるハードを入手可能と言うのには二の足を踏む)。
どうしてもPSPで動かしたいにしても、一旦はPC(OpenGLとは言っていない)で動かす事だけを考えたらどうだろう?
PSPなら過去のハードと違って、既に直接各ピクセルへ設定し描画するアーキテクチャだし
ポリゴンや現代的な画面への描画への造詣が深くなれば生かせる。
そもそもOpenGLに依存せずに(内部は別として)PCで自身の設計で作っておけば、PSPでもほぼ同じコードで動かせるようになるだろ >>391
そういう話なら判ります
PCやスマホ上で動かすとなるとすぐに思いつくところでも
・コントローラをどうするのか
各コントローラでばらつきがある。物理的なデザインはもちろんレイテンシも
・汎用OS故にバックグラウンドプロセスの影響を排除できない
極端な話、プレイ中にアンチウィルスソフトの定時スキャンが走ってもリアルタイム処理を維持できるのか?
・グラフィックス性能の評価が出来ない
HDとフルHDでは大分違う
・ディスプレイの影響も評価出来ない
システムは肥大化&複雑化しているにもかかわらずユーザーのスキルは昔より下がっているように感じます
「余計な物は動かないようにしておけ!」などと注意書きを書いたところであまり期待できなそうですし
カスタムLinux的な物を用意して「それでブートして遊んでね」みたいな方法も考えられますが
やはりユーザーのスキルの低さが壁になりそうです。USBメモリからブートさせられる人がどれだけいるのか
試作はPCでやる予定です。いきなりPSPに実装するのは無駄が多いと思いますし
一部の機能はPSPの画素数だと窮屈なので高画素のディスプレイは欲しい都合もあります ブラウザゲームのアイギスが、クライアント方式のオンゲに回帰しようとしてますが
ブラウザゲーと言ったって結局winとMacOSの2種類しか対応してないからだと思います。
クライアント方式に作るとして、ブラゲーのディスクキャッシュシステムのように
プレイヤーの進行度によって必要最小限のデータしかDLさせない作り方って
難易度が高いんでしょうか?
今はUnityとかツール使ってしか実装しない時代では、そういう根幹部分はお手上げ状態なのでしょうか? 準廃プレイヤー(職業プログラマー)の愚痴が酷すぎ!
ドラクエは元々ソロゲーだし、バトルゲームではなくてストーリーゲームだ!
そしてドラゴンクエストのストーリーを考えるためのスクエニコミックガンガンな!
DQXの敗因はまともなDがいなかった事
https://egg.2ch.net/test/read.cgi/dqo/1553655304/
135 その名前は774人います (ワッチョイ ab55-r4m/) sage 2019/03/30(土) 22:02:49.50 ID:s9M0K5iF0
ドラ10の敗因は、運営がFF11やり込んで自分で経験しなかった事
これに尽きる なんで、そんなに意地になって嫌ったのか
運営自身がネトゲやり込んだ経験あれば、もっとちゃんとした物が提供できたはず
コンテンツ参加するのに耐性装備に何千万使って
毎度報酬ゴミじゃ盛り上がる訳が無い
オフゲストーリーなんてオフゲでやってろ
全員初心者スタートのFF11、自分も10年見てたけど
誰一人ストーリーやりたいなんて聞いた事無い
みんなでPT組んで色んなエリア行ってワイワイ遊ぶのがネトゲ
それで報酬もらってキャラ強化、その強化キャラで遊ぶのが楽しいネトゲ
長年育てたキャラだから引退者が少なく続くのも一因としてあるでしょ VisualStudioでGLFWを使えるようにした ^.^
さて遊ぶぞー このスレでこの質問はいいのか分かりませんが、失礼します
クロスプラットフォームなゲームを作れるおすすめのゲームエンジン、もしくはフレームワークはありますか?
ゲーム製作は完全初心者で、マイコンのプログラムと作業効率化アプリを趣味でチョロッと作ってるレベルの者です
ゲームエンジンを調べても無限にあってどれを選べばいいか分からなくなったので、知恵を借りに来ました
自分の考えは下記の通りで、出来るだけこれを満たしたいと思ってます
・個人製作
・不思議のダンジョンみたいなのを作りたい
・初めてなので、1ダンジョン+何か追加要素程度のクオリティで作りたい
・スマホ、PCに限らずプレイ出来るゲームにしたい
・今は2Dで作る予定
・ゲームの作り方の基礎(描画の仕方やキャラの動作法等)を学びながら、作品を作りたい
・配布もできるようにしたい
・当分はクライアントゲームアプリで、 将来的にwebゲームアプリを作りたい(修正、拡張、変更がしやすいかと思って)
よろしくお願いします >>397
> ・スマホ、PCに限らずプレイ出来るゲームにしたい
そこまでのクロスプラットホームを目指しているなら
フレームワークは自作するしかないだろう まぁUnityが無難だな
スマホ、PC、ブラウザOKだ
Web上で参考文献も多いしな
昔はゲーム製作はDXライブラリも多かったが、それで問題無く製品をリリースしていたものも
多くがUnityに移行している
それだけメリットがあるんだろうな >>398-400
ありがとうございます
自作かUnity ですね
2DでもPCのスペックはそれなりに必要なんですかね?
Unity も調べてみたのですが、自分でも良さそうに見えました ただ…
半年後くらいに開発用に買い替えるつもりですが、現状低スペックPCで、自分で試したところUnity 自体もそこそこ重くて開発の後半で詰みそうな気がしたので気になりました…
書くのを忘れていてすみません
そこまでの繋ぎで簡単なものをつくろうと考えてました
メモリは4GB、CPUの性能は下から数えた方が早いです >>402
ありがとうございます!
いいですねこれ
デモを少し弄ってエクスポートまで試してみたら、めちゃくちゃスイスイ動いてそこそこのゲームも作れそうだったので、とりあえずこれでやってみることにしました
デモだけど、きちんと動いてることに感動しましたw 長いゲームプログラム組んでると
どんどん混沌化して
どこで何してるのかわからなくなります
またここ何してるかもわからなくなります
どうすりゃいいのこれ あとで弄らなくていいよういにコーディングする。
それは難しくとも後で思い出しやすいようにコーディングする。
思い出せなくなったらそこでゲーム終了。 >>405
分かるわ
俺がハマるパターンは
1.なるべくモジュール化して見通し良くしようと思うんだけど、モジュール同士が密結合になってワケわからんなる
2.必要な機能が後から分かってデータ構造も変更しなきゃとかになるとデータベースからクラス継承の切り分けから全部変えなきゃいけなくなってハマる
3.スレッドを扱う際に再現性が低く検出困難なバグに見舞われる
4.必要な素材を後から供給しようと思って始めるがクオリティが維持できない
こんな感じ プログラム自体に目次がつけれればいいのにな
長いプログラムになると目的地を探すのがまず大変 昔書いたコードが難しくて
さっぱり理解出来んとかならある
ちゃんとコメントはつけるべきやった、、 >>397
>>399
今はもうUnityだろうな
シェアが違うからな >>405
一言でいうと設計の問題だが
問題の切り分けが大事になる
具体的にはライブラリ化が有効 ドラゴンボールの界王星のような球面座標系を勉強してるのですが
https://ja.m.wikipedia.org/wiki/球面座標系
Wikiの左手座標系を右手座標系にしたいのですが
x = r sinθ cosφ
y = r sinθ sinφ
z = r cosθ
https://wikimedia.org/api/rest_v1/media/math/render/svg/a294d61f57f642049b32b947f48ddc72e0da23da
はzが上なのでzを手前にするのをどうすれば良いのでしょうか? >>413
作りたいものを言えよ
わかってて球面やりたいってなら止めないけど
ドラゴンボールの界王様のとこだったら普通の3Dで十分だろ
マリオギャラクシーでもそういう面たくさんあるよね Wikipediaのページにイラストあるよね。それ右手系に見えるんだが。
ttps://ja.wikipedia.org/wiki/%E5%8F%B3%E6%89%8B%E7%B3%BB >>414
ああそれそれそんなやつマリオギャラクシーみたいなのね
キャラクターを動かすのではなくて
球体のほうを動かす方が楽って事かな?
でも引力の計算どうすんの?って思ってしまいました。
https://threejs.org/
three.jsのkaiopua
http://collinhover.github.com/kaiopua/
>>415
数学や物理学で習ったのは左手座標系だけど
three.jsや一般的な3Dモデラーは右手座標系なので
θとφを入れ替えたらいいのかyとzを入れ替えたら良いのかよくわからなくて
x = r sinθ cosφ
y = r sinθ sinφ
z = r cosθ
x = r sinφ cosθ
y = r sinφ sinθ
z = r cosφ
x = r sinθ cosφ
y = r cosθ
z = r sinθ sinφ
球面とのコリジョン衝突計算しないと
わけわからん方向にめり込んだり宇宙に飛んで行ったりするから 普通に半径Rの球の方程式でいいじゃん
中心からキャラへのローカル座標出して
A.球の中心-キャラの直線
B.半径Rの球の方程式
C.AとBの交差点:地面座標
Cまで出したら後は重力でも足場でも好きに判定したらいいじゃない >>417-419
ありがとうございます
玉転がしの場合には
https://i.imgur.com/45fECzA.gif
例えばロボキャラがその場でジャンプとかなら問題ないんだけど
ロケットパンチ見たいな飛び道具の弾道だと
おっしゃるような楕円関数になるんですかね? >>420
だから何がしたいんだよ
マリオギャラクシーだか、オデッセイじゃなかったのかよ
弾道計算なんかどう飛ばしたいのかによるよ
ただ、制御の効きにくい楕円関数はこの場合は俺だったら避ける
絶対その軌道以外取らないって確定してたら軌道だけは使う
動かすときは線形補間
そうしないとおそらく速度が一定にならないから >>421
このthree.jsで対戦格闘が作りたいんじゃ 球体上を自由に動き回って、任意の方向にロケットパンチ撃ちたいんでしょ?
球面座標系でθ/フレーム、φ/フレームを算出したとしても球の極に向かって飛んでいくと思うよ。 ■ このスレッドは過去ログ倉庫に格納されています