ゲーム開発会社がゲーム製作技術を伝授するスレ
■ このスレッドは過去ログ倉庫に格納されています
ワールドワイドソフトウェアという開発会社の者です。\n 社員がゲーム開発の質問に可能な限りお答えします。\n http://www.wwsft.com/ \n 長年RPGを中心に開発していますが、シミュレーション、アクション、スポーツ、ペット育成、麻雀など多くのジャンルの開発経験があります。 >>631 ありがとうございます。 tone.jsとかあるんですね。 サウンド担当者はどうやって採用に至るのでしょうか?どういった点を見られるのですか? 作曲は社内で行うのでしょうか? ちょっと考えれば分かるような技術的な質問より (ってかちょっとは考えろよ的な)、 こういう質問のほうがいいな。 音作成というとドンブラを弾いているイメージ(SHROBAKO脳) >>632 DTMの掲示板を見てると、難聴や耳鳴などの症状に悩まされてる人が多いみたいだけど、 正規雇用している会社では、労災責任問われないように就業規則を徹底してるのかな 治癒不可の難聴・耳鳴を患わせてしまったら取り返しの付かない十字架になるが、一方で、頭のおかしい生産性ゼロの被雇用者に仮病でたかられたらたまったもんじゃないからな しかし個人差もあるだろうから、難聴や耳鳴などの労災回避を保証する科学的根拠・基準なんて、設定しようがない >>632 サウンドは現在、主に外注で作っています。 必要な時にホームページでサウンドクリエイターを募集 ↓ 応募して下った方のサンプル曲を視聴 ↓ 弊社のカラーに合う曲を作れる方を採用 という感じです。 過去に作って下さったクリエイターさんにまたお願いすることもあります。 >>635 意外と専属で雇っているわけじゃない場合もあるんですね。参考になります。 素材がどうのこうの言ってた人です。 外注メインなんですね。 応募しようと思ってたのに。 作例は、プログラム初学者にシンプルでわかりやすいコードに書かれてありありがたいです。 ジャンプの実際の横アクションでは、左右移動しながらジャンプすると斜めジャンプになるのと、カーソルが左右に入ったまま着地した後そのまま移動できると思うので、実装の際はどうすればよいか等ワンポイントヒントがあれば尚良いと思いました。 なんかもう初心者の都合の良い回答マシンにさせられちゃってるな 肝の部分は提示されてるんだからワンポイントヒントのところは自分で試行錯誤できないもんかね 1が不満言っていない以上、他がとやかくいうでない。ほんといちいち難癖つけたがる奴はいるもんだな。 黙って仕事する人ほど突然辞めるし、不満を言う人ほど長く続く >>638 >>639 >>640 >>641 638さん 仰るようにプログラミング初心者向けに、できるだけシンプルなコードで書いていますので、 同時キー入力は省いていたのですが、今後のサンプルには必要そうなコメントを書いておくように致します。 639さん、640さん、641さん 639さんの仰るように、ご自身で調べられることがプログラミング力の向上につながりますが、 初心者の方は何を書けばよいか全く判らない方もおられると思いますので、できる限り回答します。 同時キー入力は需要があると思うので、サンプルを用意しました。 http://www.wwsft.com/sp/ このスレをご覧になっている方の中にはシューティングやアクションゲームを 作りたいと考える方が多いのではと思い、STGを想定したサンプルも用意しました。 プログラミングのご質問を下さる皆さん、よろしければご確認ください。 >>642 おまえもそれを散々いわれてきたんだろw 同時押しの考え方は非常に参考になりました。 シューティングの実例はプログラミングの習得のモチベーション上がりますし ゲーム制作の取っ掛かりになりますね。 ありがとうございました。 モチベーションがあがる?? 製作の取っ掛かりになる??? 3軸を持つ、つまり奥行きと左右以外に空中の概念がある ベルトスクロールアクション(特に判定)はどのように作成したらよいでしょうか? 折を見て検索したり、書籍を探してはいるのですが、まずベルトスクロールの作例自体がほとんどなく、 稀に合っても2軸(プラスせいぜいが空中フラグをboolで持つ程度)ばかりです 中身は3Dそのもので見た目を2Dに見せるように作っていますが、 古くはくにおくんなども2Dで実現しているゲームもあり、効率が悪いのではないかと常に疑心暗鬼で身が入りません 最近はスマホゲームなどでも2Dベルトスクロールがありますが、どのように作っているのでしょう >>649 649さん ベルトスクロールのサンプルを用意しました。 http://www.wwsft.com/sp/ 3次元座標(X,Y,Z)をベルトスクロールする画面(2次元座標)に変換するところがポイントです。 ※変換の計算は各ゲームの画面構成に応じ調整します、今回はやや上から見下ろした感じにしています ジャンプ中のbool(trueかfalseか)だけでは(既にご理解頂いておりますように)接触判定がうまくいきません。 ジャンプ中の高さをZ軸で管理し、Zの値(及びX,Yの値)を使えば、空中での接触判定も問題なくできます。 (補足) 古いアクションゲームでは座標変換しないものもあるようですが、今回の方法であれば様々な画面構成に応用できます。 奥行への動きは別に勝手に斜め移動しなくてもいいような。 ファイナルファイトやダブルドラゴンはこんな動きしないですよね。 >>651 651さん 斜め移動させない場合は function beltX(x, y, z) { return parseInt(x-y/2); } ↓ function beltX(x, y, z) { return parseInt(x); } とすればよろしいです。 ただ画面構成を判りやすくするために表示しているラインもまっすぐになります。 説明にも書きましたが、皆さんが作られるゲームの画面構成によって座標変換の式は変えて頂くわけです。 >>652 ありがとうございます。この動きはこれはこれで参考になるのでありがたいです。 >>650 ありがとうございます、考えてもいない解決法で目から鱗が落ちました しゅごい FOR-NEXT 10億回ループまとめw追加&補正 Linux版Firefox60.0.2更新記念編 JavaScript(Core i7 8700K、IE11)....................................... 1.271秒 [Win10p64] + (*3) JavaScript(Pentium Gold G5400、Firefox60.0.2) ..... 1.308秒 [Linux....64] # New ! (*1) JavaScript(Core i7 8700K、edge)........................................1.329秒 [Win10p64] + (*4) JavaScript(Core i7 4770K、IE11)....................................... 1.581秒 [Win10. 64] + JavaScript(Pentium Gold G5400、IE11)......................... 1.589秒 [Win10. 64] JavaScript(Pentium Gold G5400、edge)..........................1.613秒 [Win10. 64] JavaScript(Core i7 4770K、edge)........................................2.102秒 [Win10. 64] + JavaScript(Celeron G1820、IE11) .................................... 2.272秒 [Win10. 64] JavaScript(Celeron G1820、edge)..................................... 2.992秒 [Win10. 64] JavaScript(Atom x5-z8300、IE11) ................................... 8.372秒 [Win10. 64] (*2) JavaScript(Atom x5-z8300、edge).................................... 9.070秒 [Win10. 64] (*2) JavaScript(Tegra3 1.3GHz、Chrome).............................36.480秒 [Nexus7.....] JavaScript(Cortex-A9 800MHz、Safari).......................36.521秒 [iPhone4S] JavaScript(PS4Slim、Netfront) .................................... 130.0. . 秒 [PS4 .] (*5) # クリーンインストールによる再計測、10秒未満の項目については10回計測の平均値 + 8700K、4770Kはturbo boostあり (*1) Linux Mint 18.3 Cinnamon 64bit版 (*2) ドンキ2in1 (*3) IE11 - Internet Explorer 11 (*4) edge - Microsoft Edge (*5) PlayStation4、CPUリソース割り当てが極端に少ないか、サブCPU担当と予想される [Win10p64] Windows10pro 64bit版 [Win10. 64] Windows10 64bit版 [Linux....64] Linux Mint 18.3 Cinnamon 64bit版 [PS4 .] PlayStation4 [Nexus7.....] Nexus7-2012 [iPhone4S] iPhone4S ファミコンドラクエ3の旅の扉に入ったときの画面効果はどうやっているのでしょうか? だからスクショとか参考URLとか貼れって どんだけスボラだよ >>657 657さん 弊社はファミコン開発は行ったことがございませんが、あの画面演出は有名でして、 あれはファミコンというハードに備わった機能で実現しています。 ちなみに同じ任天堂ハードのスーファミやゲームボーイアドバンスでも同様の演出ができます。 現在のハードではソフトウェアの工夫で似たような演出ができますので、 ソースコードを書く時間があれば公開したいと思います。 それからみなさん、このドラクエの画面演出は判りましたが、 中には調べないと画像が見つからないものもあると思います。 658さんの仰るように参考URLなどがあると助かりますので、 そのようにお願いできればと思います。 しらないが、ソフトウェアで可能だろ。 ハードでしかできないとかしょぼ過ぎる性能だ いま実物は確認してない ラスタースクロールかな?懐かしい。 シェーダ使えば簡単にできるけど 使わない場合はどうするのか期待 >>657 >>659 >>660 >>661 ラスタースクロール(風の演出)を「ゲーム プログラミング テクニック」にアップしました。 http://www.wwsft.com/sp/ 宣伝になりますが、使っているRPGの画像は、RPGの制作過程を完全公開する企画 「 One Hour Quest 」のものです。 RPG開発に興味のある方はこちらもご覧頂けると幸いです。 http://www.wwsft.com/ohq/ (補足) ファミコンというハードに備わっていると書きましたが、改めて調べたところ、 ファミコンの場合は“完全に備わっているというわけではなく、ある程度工夫して実現”していたようです。 詳しくはwikiに解説がありましたので、そちらもご確認ください。 このスレの趣旨に沿うのかわかりませんが、 曲がるビームの見た目(例えばレイストームのような)はどのように作るのでしょう 弾の進む方向を途中で変化させることはできますが、グラフィックに悩んでます。 昔は直線状のグラフィックのエフェクトをいくつも繋げたり、板ポリを角度を変えていったりしていたようですが 昨今は継ぎ目も見えず綺麗にくねくねするビームをよく見ます 毎秒いくつのパーティクルでは弾速のあるものは生成数が少ないと途切れますし、多いと処理が重すぎるのでは、と不思議です >>656 PS4のjsエンジン遅すぎワロタwwとバカにしてるそこの豚! Switch内蔵ブラウザもNetfront製だからな!ザマァwwwww >>662 ギザギザじゃねーか!(とりあえずツッコミ) ソースを見たところ、y+=8やその他の8を1に変えればスムーズな波になりそう(重そうですが) それより、一枚絵を千切りにしてずらして表示してるんですね。 つまり、ゲームに実装する場合は、画面キャプチャーして一枚絵を作ってから、この処理ですね。 >>668 え? 一枚絵表示するときに処理すればいいんじゃね? なんでキャプチャがいるの? >>668 668さん 現行の全てのハード(ゲーム機、パソコン、スマートフォン)及び(多くの)開発環境で、 画面に描いたグラフィックを1枚絵のデータとして処理できます。 やり方はそれぞれの開発環境によって違うため、ここで簡単に解説はできませんが、 669さんの仰るとおりで処理できるわけです。 また表示をスムーズにするには仰るように1ドットずつ処理すればよく、 各環境でハードの処理速度が許す範囲で、細かく描画すればよいわけです。 JavaScriptは基本的に重いので、とりあえず8ドットにしています。 あくまでプログラミング初心者が理解しやすいソースコードにしておりますので、 みなさんが作られるゲーム内容や開発環境に合わせて改良してみてください。 俺も似たようなことよくやってたけど、旅の扉はHブランク割り込み使って各ライン毎にBGの座標レジスタを書き換えてるんだよね んで、F-ZEROはさらにアフィン変換パラメーターも弄って奥行きを表現してる DSまでは結構普通に使ってた技術なんだよね >>670 なるほど、ありがとうございます! 自分の環境はDirect3Dで描画しているので、同じようなことをしようとすると 遅延シェーディング(は知識がない)またはテクスチャにレンダリングしてから 改めて画面にレンダリングする(こちらなら多分できる)ので、 テクスチャに落とす部分をキャプチャと表現していました。 最近のゲーム機は、もっと手軽に、画面に表示した画像相当のデータを 一枚絵として手に入れられるということなのですね。 itch.toとSteamで販売した場合の売上差ってどのくらいか誰か分かりませんか? >>1 とても勉強になる回答ばかりで読んでて楽しいです。 時折心貧しき人間が心無いレスしておりますが、 稀に見る珍しいほど有意義で建設的な意見が多いスレですので 初心者のためにも>>1 さんによるスレ継続を希望します。 (たとえば広場で美味しい料理を子供達に配っていれば、 どこからかハエもたかってくるもんです) で、質問です。 >>1 さんのサイトのコンテンツはどれも非常に魅力的なんですが(特にRPG作るやつ、 個人的にはソースコードはJavaScriptよりもC#で記述してほしいと思っています。 近年猛威を振っているUnity開発上でもJavaScriptは廃止となった様ですし、、 CやC++の流れを組んだC#で書いてくれた方がこれからゲーム開発しようとする万人向けというか 喜ぶ人は多いと思うんですが、、今後も確実にUnity人口は増えると思いますし。 それでもJavaScriptにこだわり、推奨する理由とか>>1 さんにはあるのでしょうか 横レスで申し訳ないが、 さすがに既に例があるのだから、ご自分で移植するのが勉強では? itch.ioはフリーゲーム(フリームみたいなもの)目当てだから 利益はあまり出ない。itch<<<<<DLSITE<<<<<Steamな感じ >>662 ありがとうございます。 今回は最初から1枚絵ですが、 >>668 の言うように、描画したものを1枚絵として確保するのに、 環境によって知識が要りそうですね。 >>675 Webならその場で誰でも動作確認できてソースもわかりやすいからでは? C#だとVisualStudioないと確認できないし。 >>664 664さん レイストームをYoutubeで検索し、たぶんこれのことではというビームの表現方法を作ってみました。 http://www.wwsft.com/sp/ ↑ページの真ん中くらいにあります 弾の軌道は計算できており、描画面でお悩みとのことですが、 ・3Dでしたら板ポリ(板ポリなら数百枚表示しても一般的に処理はさほど重くなりません) ・2Dでしたらpng画像、テクスチャからの切り出し表示、あるいは線を引くなどの描画命令 で十分綺麗なレーザーが描けると思います。 今回のサンプルはJavaScriptですので2Dで単純に線を引く命令で実現しています。 >>675 675さん ありがとうございます。今後ともよろしくお願い致します。 JavaScriptで公開している理由は、678さんの仰るようにまさに「誰もが確認でき」「ソースが判りやすい」ためです。 弊社HPのコンテンツはパソコンだけでなく、iPhoneでもAndroidでも(それらのOSを搭載したタブレットでも) 確認できるようになっておりまして、より多くの方にご覧頂ければと願っております。 それからJavaScriptに力を入れるもう一つの理由は、 Google、Apple、MicroSoftというコンピュータ産業のトップ3社は ブラウザ開発(つまりJavaScriptを含めた技術)でもしのぎを削っており、 JavaScriptの普及には目を見張るものがあります。つまりJSは今後も将来性のある技術のためです。 >>675 >>680 補足となります。 弊社HPでは今後C系言語の技術、Javaの技術、そしてPythonの技術も公開する計画があります。 弊社は小さな会社ですので、マンパワーの問題で、それらを順に行っていく予定でして、 今期はPythonの解説をスタートします。 JavaScriptでいいと思います。 基本や考え方は変わらないし。 JSじゃなくC#でかけやゴルァって・・何もわかってないわな 解説やるなら、動画でやってほしい 学習効率が段違いなんで Pythonいいですね!期待してます! R言語はやりませんか?(やりませんw) Pythonはマニアックすぎるでしょー なかなか古い言語ですが当時解説も英語ばかりで 日本ではそれほど浸透せず、ハッキリ言うと廃れた言語です。 しかもゲーム制作ならpygameになりますし、 そのパイガメすら閑古鳥状態のはず。 そんな言語の解説に時間かけるの勿体無いですよ 喜ぶのは極少数の人だけです。 スペースハリアーの地面の市松模様のスクロールはどうやっているのでしょうか? ハリアー(自機)が上に移動するとちゃんと地形も上からの見おろし角度に変わるんですよね。 ポリゴンでもないのに。 YouTubeでプレイ動画はいくらでもあります。 検索までさせるのは不親切じゃない? あるならurl一個くらい書けばいいのに >>688 >>689 >>690 Pythonに関するコメントありがとうございます。 690さんの仰るようにPythonはここ何年か人気が高まり、学びたい方が増えている言語です。 基本的なソースコードの書き方は C系言語/Java/JavaScriptより簡単で、 プログラミング初心者の方が学びやすい言語であると言われています。 >>691 691さん アーケード版の動画を確認しまして、これは 662 のラスタースクロールと呼ばれる手法と思います。 当時のハードには3D描画機能はありませんでしたが、モニタの走査線と画面表示タイミングの技法で 擬似的に3Dっぽく見せることが行われていました。 ラスタースクロールはwikiに解説がありますので、よろしければご確認下さい。 スペハリのアーケード版=業務用ハードなので、基盤自体にこのような画面効果のできる機能が 標準装備されていた可能性もあります。 詳しい方がいらっしゃいましたら、コメント頂ければ幸いです。 >>695 水平同期と垂直同期をハード的にいじったものです。 xy軸の縮尺を軸毎にハード的に弄ってます。 それによって目論んだのは、投影変換無しで良いから前に倒したプレーンが欲しかった事に起因してます。それとは別レイヤーのゲームを合成して目的を達成してます。 この機能が出来ないコンシューマ機は、地形のアニメーションや、カラーマップのアニメーションで対応してました。 アニメーションなので動的な変化の少ないチープな物でしたが、当時の努力は伺い知れません。 今やるなら3dプレーンを前に倒すのが一番簡単で、ラインスクロールに習ってライン毎に縮尺を変えるのは逆に大変かと思います。 ロックマン8がグラフィックの正統進化だったんだから単にその続きでいいんじゃないの? >>697 意味が分かりません。 691さんも含め、どう言う技術?と言う問いへのアンサーかと思われます。 それに、ロックマン8は96年の作品です。 スペハリ、アフターバーナーやエンデューロレーサーと言ったゲームは86年ら辺のゲームです。 ご指摘のロックマンむしろは退化と言えるのではないでしょうか? 時系列を考えれば分かりますよ >>696 696さん、情報ありがとうございます。 弊社技術者達は90年代以降の開発者でして80年代ハードの経験がございません。 参考になりました。 今後ともよろしくお願い致します。 >>695 >>696 ありがとうございます。 ハードウェア機能の技術なんで現在の環境でやろうとすると疑似でやるかやっても処理が遅くなったりという感じなんですね。 今ならシェーダーで同じこともそれ以上のことできるからね >>702 ラスタースクロールや疑似3Dなんて、昔は3D描画のコストが高かったから仕方なくやったものであって、 いまなら息をするように3D描画できるから、わざわざラスタースクロールする必要がない。 なお、ラスタースクロール程度なら>>661 ,703も言ってる通り、シェーダーでほぼノーコストでできる。 やってきましたマウンターw 自分のスレ立ててやれってw WebGLならシェーダ使えるけど WWSさんはやらないんですかね? >>706 706さん 将来的にWebGLもやる予定になっておりますが、 今のところはスペックの低いスマホなどでも確認したり、遊ぶことができるように、 2D描画(及び処理速度)を優先しています。 会社の方針の一つで「より多くの方にご覧頂けるように」という意味です。 ファミコンのスーパーマリオ1-2など、ブロックが大量にある面でブロックは背景だと思うのですが、 そこをチビマリオで叩くと、1ブロック分だけボヨンボヨンと上下動するのはどうやっているのでしょうか? >>708 708さん 弊社はファミコン開発の経験はございませんが、 ファミコンのあのような表現は、細かく動かしたい部分だけスプライトで表示しているはずです。 マリオが叩く前=BG ↓ マリオが叩く=BGのブロックを消し、一旦、動くブロックをスプライトで表現 ↓ 再びBGに戻す >>709 なるほど細かく切り替えればいいんですね。ありがとうございます。 >>514 読んで思ったんですけど、スマホ対応で画面の設計が16:9じゃないのって理由があるんでしょうか? iPhoneはじめ、現行のほとんどのスマホは16:9だと思うのですが 5:3で設計する理由を教えてもらいたいです よろしくお願いします スマホって言っても最近はタブレットも多いからそれかな。 5:3ってことは15:9か、横が少し短いのね。 以前16:10のモニターは使ってたけど15:9なんてあるんだ。 下の▽○□の部分かな?(適当) >>711 >>712 711さん 514に書いた方法は、712さんの仰るようにタブレット等も含め、より多くの機種に対応させる方法です。 またスマホ全てが16:9ではございません。 例えば最新機種を調べてみましたが Xperia最新機種はFull HD+(1080×2160) Galaxy最新機種はQuad HD+(1440×2960) となっていました。 iOS系も端末の番号ごと(iPhone*)によって違います。 ちなみにスマホ業界で最新機種は(全てではありませんが)2:1に近づく傾向があります。 法人の場合は最新機種や一部の機種だけでなく、Android、iOS、スマホ、タブレットと より多くの端末(理想を言えば現行機種全て)に対応する必要がございます。 ただ個人開発者の方は、そこまでシビアに考える必要は無く、 16:9の設計でもよろしいかと思います。 >>714 711です ネットで拾えるスマホの画面アスペクト比の一覧表を眺めると 16:9が圧倒的多数派のように見えたので何故って思ったんですが 違うのも結構あるんですね 最新のは2:1に近づいてるなんて全く知りませんでした なるべく多くの機種に対応したいと思うので 5:3を基本にして考えていこうと思います ありがとうございます サムネイル画像とか見ると最高解像度よりも細かいドットを表示しているように見える事あるんだけど、グラフィックソフトの補完性能とかのせいですか? それとも俺の気のせいかな これはひどい。 サンプルをググることすらできねぇ… >>716 716さん サムネイル画像は2パタンあり、 1.大きな画像をソフトが自動的に縮小し表示してくれる 2.実際の画像とは別にサムネイル画像が数パタン(サイズ違い)が用意されている 716さんがどちらのサムネイルを仰っているのか判らないのですが、 1、2ともにソフトウェア技術の発達とハードの高解像化で 多くのサムネイル画像が綺麗に見えるようになっています。 ですので「コンピュータ関連技術の急激な発達のせい」と思います。 ファミコンドラクエ2から始まった?街や洞窟などでドアをくぐった時に自分のいるエリアが段階的に見えるようになって、 他が段階的に隠れる処理はどうやるのでしょうか? https://www.youtube.com/watch?v=vPquPFHMkvA 15:30あたり 懐かしい〜w DQ2ってまだ背景とキャラスプライトの重ね合わせも無かったんだね 背景パネルを外側と内側からグルっと配置する処理を作って、室内外のフラグが切り替わったらスクロールさせてる画面データを書き換えてるだけに見えるな、素人目には >>719 719さん 2DRPGなどで屋外←→屋内の表示を切り替えるサンプルを用意しました。 http://www.wwsft.com/sp/ いくつかの方法があると思いますが、プログラミング初心者の方に判りやすいよう、なるべくシンプルに書いたコードです。 ドラクエと若干演出が違いますが、だいたいこんな感じで実現できます。 それとみなさん、今週から来週は新規プロジェクトの立ち上げ等で忙しく、サンプルを用意できない可能性があります。 サンプルを用意できない時は言葉だけで簡潔に説明しますので、なにとぞご了承ください。 他人の作ったゲームエンジン弄ってるより、レトロゲーのアルゴリズム考えてた方が楽しい事もあるでしょ プロが初心者問わず質問に答えてくれる折角の良スレなのに、他人の質問にいちいちケチ付ける奴って何なんだ? マジうぜーから消えろよ >>721 最新ゲームエンジンに乗っかった見栄え優先のゲーム作りが多い中で、 シンプルなゲームの基本の作り方を教えてくれるこのスレは大変貴重。 これからも続けてくださいまし。 >>727 排他的というのはどういう所なんだ? 別に他の板やネット掲示板と変わらんしむしろここはネチケット基準が相当ゆるい 敢えて率直に言えば、アホスレの乱立を見ても分かる通り技術水準も意識もかなり低い ここの殆どの主張や作法は先端を行っているプロの現場では全く通用しないだろう >>729 ゲームを作るスレで完成したの見たことないしな 妄想が形になってるだけまだなろうの方がマシかも 排他的というのは技術的会話ができないやつは仲間に入れないってことだろ すぐ調べろとかいって突き離す ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.0 2024/04/24 Walang Kapalit ★ | Donguri System Team 5ちゃんねる