- ベストアンサー
プログラミングのコード量に関する素朴な疑問
- ゲーム開発におけるコード量について疑問を持っています。例えば、ファイナルファンタジーやドラクエなどのゲームは、どのくらいのコードを書いているのでしょうか? ExcelのVBAを使ってプログラムをしている際に、ひとつのモジュールでは約3万文字のコードを書いていましたが、プロのゲーム開発者はどれくらいの行数や文字数でゲームを作成しているのでしょうか?
- また、プログラムの書き方や繰り返し処理の設定、Excelなどの特定のツールを使う場合などによって、コード量は異なると思いますが、プロの人たちはどんな制限容量の中でゲームを作っているのでしょうか? どれくらいの行数や文字数が必要なのでしょうか? それに関する逸話や興味深い事例を教えていただけると幸いです。
- さらに、素数を生成するプログラムなどの簡単なプログラムでも、多種多様な解法が存在します。同じ結果が出るのにも関わらず、コードの長さはまちまちです。昔のファミコンなどの制限の中で、どんなにコードを工夫してゲームが作られていたのか気になります。ファミコン時代のゲーム制作に関する知識も教えていただけると嬉しいです。
- みんなの回答 (5)
- 専門家の回答
質問者が選んだベストアンサー
VBAバカにされたと聞いて飛んできたヽ(`Д´#)ノ 「VBはインタプリタだから遅い」は過去の話、今はコンパイルも可能、速度も改善されていると聞きます。そもそも、そんな高速処理ばかり必要ではないので、インタプリタでも十分です。セルへのアクセスを減らす、配列は大きくしすぎない、この辺がネックになりやすく、簡単に100倍速になります。よく知ることが大事! Excel VBAは、入出力の容易さ・改変しやすさから生産性が高く、業務の効率化に向きます。入門言語としてだけでなく、スキルとして十二分に通用しますよ。 …満足したところで、以下本題に沿って。 コード量は、目安として1人1ヶ月間で1500行の設計~テスト(半分はテスト)。難易度で倍増も半減もしますが、プログラマが生活するにはそれなりの規模が必要です。 モノによるけど、1機能1~2万行もざら。今時は容量制限なんて関係ないぜ!と作った巨大dll(たしか30万行)は、OSにメモリ制限があってダイエットを命じられましたけどね。デバッグ用の機能削って、以後修正のたびサイズ確認が面倒でした。 FC版ドラクエならExcelで再現可能かと。 データは配列にぶちこんで処理から切り離し、操作待ちループから状態遷移と描画を繰り返す。プログラム自体は多分2000行くらい。挑戦してみては?
その他の回答 (4)
- bajutsu
- ベストアンサー率20% (139/693)
>違いが判ればVBAでも速い処理ができるプログラムが組める可能性がある!ってことですよね??? ExcelVBAって時点で、インタプリタなの。 だから、違いがわかったところで、ExcelVBAを使っている限り 速い処理ができるプログラムは書けません。 wikiで調べたのなら分かると思うけど、インタプリタ型というのは 人間が読める「プログラミング言語」の状態から、実行する時にCPUが理解できる「機械語」に 変換しながら処理をしていくわけで、 例えるなら、日本人とアメリカ人が通訳を挟んで会話している状態だから どうしても「通訳」というロスタイムが発生する。 ゲームだと、既に機械語に翻訳された状態(実行モジュール)の形になっているから 通訳というロスタイムは発生しない。 上の例で言うと、会話に必要な部分だけ英語を丸暗記して、通訳が要らない状態にしてあるってことかな? いわゆる最近の高級言語と呼ばれるもの(VBAとかもそう)は、 “いくつかの処理をまとめた”API群とかがあって、それらの力を借りて 書くコード数は少なくても、いろんなことができるようになってはいるが それらAPI群にはある程度汎用性とか安全性を求めて作られているため 機械語とかにした場合には、要らない処理とかも入ってたりする。 (型のチェックとか、サイズのチェックとか、内容が「決め打ち」なら厳密でなくてもよい) API化した際に、関数の入れ子が多段階に渡ることもある。 「関数呼び出し」って、CPUの処理的にはちょっと重い処理なのだが 単純な処理をするのに、関数を呼んで呼んで~で、結局、基本的な関数を呼んでるだけだったり というようなことも、高級言語のAPIでは多々ありますが 低級な言語を敢えて使うことで、それらの無駄を省いた処理を書くこともできます。 変な話、for文で、10回ループする処理を書くなら 10回分ベタで書いた方が、終了判定や、カウントをアップする処理が要らないくなりますよね? これだとコードの量は増えますが、処理効率はちょっとだけUPします。 まぁ、他はだいたいAno2さんと同意です。 過去の資産がたくさんあるのもそうだし、新規プログラムと言っても、 その過去の資産から、似たようなものを探してきて、土台にしたり… ここでいう、過去の遺産とは、プログラム、作る人、方法論などなど。 あらゆるノウハウは蓄積されているし、これからも蓄積していくでしょう。 とにもかくにも、興味を持たれたのなら、一度VBAから離れてみることをオススメしますが。
お礼
ご回答ありがとうございます。 EXCEL VBA を始めてから、まだ間もないので、もう少しVBAで慣れたら他の言語にも挑戦してみたいと思います。 いろいろとEXCELの技法を紹介しているページをみましたが、 ループをするよりも、同じコードを書いたほうが処理効率が上がるってことは知りませんでした! それと、たしかに、いまでも、型が合わないだの、インデックスの範囲外だのって、よく怒られながらEXCEL VBAとケンカしーのプログラムを組んでいますw 叱ってくれるのがインタプリタ型だからなんですよね。 わかりやすい例えで、まだなんとなしですが、これからが楽しくなりました。 怒られなくなったら次の言語に進んでみたくなるご回答でした。 ありがとうございます!
http://www.amazon.co.jp/exec/obidos/ASIN/4844326864/gengengen-22/ref=nosim これでも買って勉強しなおしてください。
お礼
再度ありがとうございます。 この本買ってみたいと思います! ご紹介ありがとうございました。
- imogasi
- ベストアンサー率27% (4737/17069)
エクセルVBAしかやってなくて、云々するのはおかしいと思う(井の中の蛙)。所詮スクリプトを書いていては、色々いえない。 C++ぐらい使って、さらにAPIなども作るとか、ぐらいのレベルになったら、そのとき考え直したら。 ゲーム製作は特別な分野で、ビジネスデータ処理のエクセルなどと、違う面が多い。 ゲームでなくても、エクセルなどを見て想像しても、開発は大変だなと、質問とおなじようなことは感じる。 私も経験者で無いから詳細言えないが (1)過去からの開発の蓄積が違う。ツールのようなものも出来上がっている。開発方式も経験を積んでいる。 部分で使う技術(プログラム)は既に出来上がっているとおもう。 (2)全世界の開発用の優秀ソフトも使っている。 (3)組織で開発している。下請けも使っているだろう。開発も分業でなされている。 (4)優秀な人が多数従事して開発している (5)資本(金、予算、先行投資となる開発費)もかけている(完成までの長期の人の労働、ソフトや機器の購入)。 結局ゲーム製作に限らず、ロケット開発でも共通する点で、普通の個人には難しいという点の要素(原因)は同じだろう。 質問者が経験することは一生無いと思うし、ゲーム製作の製作現場の人が、こんな質問コーナーに(回答には時間かかるが初心者の質問が多く、回答者の勉強になる場ではないから)付き合っていたらおかしい(ここにある1カテを登録したら1日数十のメイルを見ないと、答えられるテーマかどうかわからず、答えるとなると1問に数十分もかかるのだ。若い優秀な現役がそんなことをしていたら国家・会社・自分の損失)。 ここであまり良い回答は期待せぬが良かろう。
お礼
ご回答ありがとうございます。 たしかにプログラムを生活の糧にしている方などは、このような質問は勉強不足と叱咤なさると思いました。 最近勉強し始めて、ふと思った疑問だったので、つい問いかけてしまったのですが、それでも、得られた情報でもっと勉強したくなりました! ありがとうございました!
インタープリンタ型の言語はあえてそんなものですが? サブルーチン多用すれば何とかなるかもですけど。 大体大きなプログラムは、機械語にコンバートしています。 この違いが判らないと、VBAでプログラム組むととてつもなく遅いプログラムが出来上がるでしょうね。
お礼
さっそくの回答ありがとうございます。 インタープリンタ型をwikiってみました。この言葉初めて知りました。 (wikiでは[インタプリタ型]としてヒットしましたが同じことですよね??) 違いが判ればVBAでも速い処理ができるプログラムが組める可能性がある!ってことですよね??? ここで、また疑問なのですが、「機械語にコンバートする」ってことと、Excelで「配列で処理する」ってことは、また別の意味合いなんですよね?? なんとも、プログラミングを初めてしがないものなので、どうぞご指南のほどよろしくお願いします。
お礼
興味深いご回答ありがとうございます! 私はEXCEL VBAをはじめてからまだ間もないのですが、セルとのアクセスには非常に時間がかかる。配列を使えば速くなるようなことがサイトに載っていたので、それをためしてみて、 およそ500行*30列くらいの配列を10個くらい作って、その一個一個の格納値が他の配列のなかの格納値の一個一個とどのくらい重複しているか?みたいなコードを書いてみました。 ワークシート関数のCOUNTIF(範囲,検索値)みたいなものですね。 配列内ではApplication.CountIfみたいなものが使えないのがわかりました。配列内では、範囲を設定できないんですね…。たぶん。(範囲を設定できないと書くと少し語弊があるかもしれませんが、ワークシート関数みたいな設定の仕方って意味です) んで、For文やEach文を使って一個一個を検索していくのですが、意外と速いのにびっくりしました。 実はこれと似たようなことをシート状でCOUNTIF関数(やら、この関数を交えたやっかいな入れ子関数)を使い実行したら、OS(なのかな?)に「メモリ不足」って怒られてしまったことが発端でEXCEL VBAに手をつけたんですw COUNTIF関数やMAX関数やSUM関数みたいなシート上では範囲を簡単に設定できる処理を、配列を使ってFor文などで表現するのに、苦労しましたが、ワークシート関数使用時のあの再計算処理の苦痛から逃れられたのがとても嬉しい!と感激しました。 他の言語に行く前に、VBAで、もうちょっと頑張ってみようと思わされるご回答、本当にありがとうございました!!