ゲーム開発会社がゲーム製作技術を伝授するスレ
■ このスレッドは過去ログ倉庫に格納されています
ワールドワイドソフトウェアという開発会社の者です。\n
社員がゲーム開発の質問に可能な限りお答えします。\n
http://www.wwsft.com/\n
長年RPGを中心に開発していますが、シミュレーション、アクション、スポーツ、ペット育成、麻雀など多くのジャンルの開発経験があります。 だからスクショとか参考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
ゲームを作るスレで完成したの見たことないしな
妄想が形になってるだけまだなろうの方がマシかも 排他的というのは技術的会話ができないやつは仲間に入れないってことだろ
すぐ調べろとかいって突き離す でもそれは扱う内容の性質上、ある程度は仕方ないんじゃあるまいか。 >>728
再発明楽しいですごめんなさいw
でも正確には、F1タイヤを見て木の車輪を作るようなもので、
再発明とすら言えないぜw 突き放す習慣はこの板この巨大掲示板に限らずネットのデフォだよ
あと率直な書き込みもネットの醍醐味
むしろこの板は理由はよく分からないがどちらかというと全体的に優しい方だよ 2Dシューティングで地形を攻撃したら地形が動くような処理はどうやっているのでしょうか?
MSXグラディウス2 3面です。
https://www.youtube.com/watch?v=ZfyWntot-a8
8:40あたりから そのままやればいいだけじゃないのか。
タマが当たったら地面を変化させれば。
一般的なやり方があれば知りたいってことだとおもうが。
都合があえばどんな方法でもいいんじゃないか。 誰にきいてるんだかわからないが、どう難しいのかがわからん。
常時、動く敵キャラよりも簡単なはずだ。
(巨大な敵キャラが)停止していて、タマ打ったら動き出すってだけだろ? シューティングゲームの基本であるタスクシステムをググった方がいいな
どうやって実現してるのか分からんけど>>738程度であれば敵キャラと同じように動く地形をオブジェクトとして扱ってるだけじゃないのかな 地形を半固定なオブジェクトとして扱うなんて技術じゃなくて発想の問題じゃん。
マップチップ使って背景スクロール実装済みなら考えつきそうなものだろ。 なんぼなんでも、全くゲームプログラムした事無い人間に最初から教えるのは>>1でもキツイんじゃないかと心配してるだけだろw 大きなお世話だよ。
名前だしてるから、それも含めて対応だよ。
>1さんがギブしたら、その時助けてやればいいんだよ。それまでは黙ってなさいな。 >>747
全く書き込むなとは言ってないからね。
前に出てた、どう答えるか参考で楽しみとか、スレを盛り上げるのはいいと思う。ま、これは自論だけど。 >>738
738さん
支えのなくなったブロックが落下するサンプルを制作しました。
http://www.wwsft.com/sp/
744さんの仰るように、BGの動く部分をオブジェクトとする方法もありますが、
今回はBGデータのみでどんな地形にも対応できる汎用プログラムを目指して作ってみました。
ただ弊社は現在忙しい状況でデバッグする時間が限られており、もしかしたらバグがあるかもしれません。
プログラミングの知識をお持ちの方は、サンプルプログラムのmap配列を書き換え、
ブロックを色々な状態に並べ、正しく落下するか試して頂けると助かります。
バグがあれば修正しますので、このスレに書き込んで頂けますでしょうか。
みなさんよろしくお願い致します。 >>729
>ここの殆どの主張や作法は先端を行っているプロの現場では全く通用しないだろう
だからなに?としか。
そもそも質問や回答(手法)の質がどうだろうと>>729には関係ないよね?
和気藹々にスレが続いてることへのやっかみみたいにいちいち邪魔しないでほしい。
気に入らないなら覗くなよ、スレを。
いちいち他人の邪魔する人生ってどうなの?
>>729は自称プロの現場で通用してる人間かしらんけど
>>1や熱心に質問してる住人たちよりも心が貧しい人間なのは確実だよ。 >>752
>1さん以外の横ヤリお節介解説について言ってるんじゃないのかな?
ちがうか? >>751
お忙しい中、BGでのサンプルを作っていただきありがとうございます! ■ このスレッドは過去ログ倉庫に格納されています