ゲーム用のインタプリタ言語を作ったのですが、
普通、実行ファイルの他にスクリプトファイルを用意しますよね、
それをEXEファイルに埋め込んでEXEファイル単体で動作させたいのですが
どのようなコードを書けばいいのでしょうか。
アドベンチャーゲーム作成ツールなどにある
EXE作成機能を作りたいと思っています。
EXEファイル自体にスクリプトや画像ファイルを埋め込んで、
実行時に自分から取り出して使うという手順は、なんとなくわかります。
でも、実際にプログラムにしたときのコードがわかりません。
いろいろ探し回りましたがそれらしき情報は非常に少ないです。
どなたかご教授お願いします。
ここはアプリケーション作成講座ではありません
Ｃ・Ｃ＋＋ ＶＣ等について何が困っているのか具体的かつ、ソース提示ご
簡潔に、お問い合わせください
なお自分の努力結果を示さない場合、非難されるだけですのでご注意ください
最低限、ご質問するに当たり、ご自分の用意できている環境を提示するのは
回答者への礼儀と心得てください
すみませんでした。
自分の努力が足りませんでした。
（少しショック...;_;）
以後質問するときは必ず開発環境を書きます。
この方法はなにか高度な技術を使っているんじゃないかなぁ
と思って手が出せないでいました。
自分でなんとか考えて実現させたいと思います。
カスタムリソースなどで取り込むとか。
ただ……その場合、EXEのファイルサイズがスゴいことになりませんか？
実行ファイルがあまりに大きくなると９X系での動作が難しくなるとか
色々出てきそうなので、大丈夫かなと言う気がしますね。
サイズが大きくなれば、結局複数ファイルに分けていてもいなくても
ダウンロード等に時間がかかるのは必至ですからダウンロード時間対策
で考えると意味無いと思いますし。
一つの実行ファイルにする目的がはっきりすれば、別のアプローチを
アドバイスしてもらえるかもしれません。
現行のアプリがとっている方法が必ずしも最良の方法と言うわけでは
無いと思いますので。
> 逆に一つのファイルにまとめるメリットって…ちょっと思いつきません。どんなのがありま
す？
別ファイルだった場合のデメリットのいくつかがメリットに変わるのではないかと。
例えば……
・必要なファイルが存在しないという状況があり得ない(エラー処理が省ける？)
・削除時に１ファイルのみで済む(セーブデータとかあったらそっちも削除必要ですが)
パッと思いつくのは上記くらいでしょうか。
# 会社の別のチームが作ったヤツで、DLLが26Mとかゆ～のがあったような………
# コンパイルにン時間？？
むかーしむかし・・・まだメモリが640kbとかのころ・・・
巨大化してしまったプログラムを使用するとき、
必要に応じてプログラムをメモリにロードして実行するってのがあったとききました。
# ちょっと前のGBとかN64の開発でもそうらしいです。
# セグメントとか言う概念だったかな？
アプリケーション内の固定番地からデータを読み込むようにしてアプリケーションをつくり、
実行中にそのアドレスからデータをロードすれば比較的簡単に作れると思います。
その場合、リンクツールを書く必要があるかもですが・・・
# アプリケーションのお尻にダミー付けて、適当に固定アドレスを埋めておいて、
# その後ろにデータを貼り付ければいいからそんなたいしたリンクツールではないですけどね
# ちなみに、私は・・・Windows環境でそんなことした経験はないので、動くかどうかが
# 正直断言できないのが悲しいです(涙
# DOSアプリなら問題なく動いてたので、たぶん大丈夫でしょう(無責任？ｗ
> ・必要なファイルが存在しないという状況があり得ない(エラー処理が省ける？)
> ・削除時に１ファイルのみで済む(セーブデータとかあったらそっちも削除必要
> ですが)
> パッと思いつくのは上記くらいでしょうか。
必要なファイルの存在をあらかじめチェックしてエラーを出すのも、
必要なファイルが無くて土壇場でエラーが出るのも、大した違いではないような。
結局、再インストールしてもダメなら開発元に連絡、しか手段は無いですし。
削除は…まぁおっしゃるとおりですが。
個人的に見て、ファイルを分けるメリット ＞ まとめるメリット に思えます。
あくまで個人的見解に過ぎませんけどね。
> その場合、リンクツールを書く必要があるかもですが・・・
> # アプリケーションのお尻にダミー付けて、適当に固定アドレスを埋めておいて、
> # その後ろにデータを貼り付ければいいからそんなたいしたリンクツールでは
> # ないですけどね
リンクツールは MS 謹製。
copy /b hogehoge.exe + hogehoge.dat
でおっけーです。
DOS の頃は、オーバレイマネージャが....。もう忘れましたけど。
># アプリケーションのお尻にダミー付けて、適当に固定アドレスを埋めておいて、
># その後ろにデータを貼り付ければいいからそんなたいしたリンクツールではないですけどね
今へたにこれをやるとウィルス警告が出て、利用者に不信感を持たれたりしそうな気が...。
> 個人的に見て、ファイルを分けるメリット ＞ まとめるメリット に思えます。
> あくまで個人的見解に過ぎませんけどね。
私も分ける方が好きですね。
変更しやすいし、再利用しやすいし、バージョンアップしやすいし・・・（ぇ
DLLをたくさん作っちゃう方なので・・・ｗ
> リンクツールは MS 謹製。
> copy /b hogehoge.exe + hogehoge.dat
> でおっけーです。
あれ？アライメントとらなくても大丈夫でしたっけ？
コピーでくっつけると・・・プログラムのちょっとした変更でアドレス変わっちゃうから、
私ならツール書きますねぇ・・・て、感じ？
スクリプトファイルがテキストだった場合、バイナリ変換も考慮して少しでも
データ量を減らしてからリンクするとか、スクリプト作成用ツールと実行用
アプリケーションをわけて、スクリプト作成用ツールにリンカ機能を盛り込むとか
方法はいくらでもあるので、好みの問題かもですがｗ
# ツール書く前提で書いちゃってる私・・・（汗
> あれ？アライメントとらなくても大丈夫でしたっけ？
無知でごめんなさい。アライメントって何です？
いや、言葉の意味は知っています。けど、このケースではどうするのかわかりません。
> コピーでくっつけると・・・プログラムのちょっとした変更でアドレス変わっちゃう
> から、私ならツール書きますねぇ・・・て、感じ？
まぁ、プログラム中に固定アドレスを書くならそうなりますね。
詳しくはありませんが、例えばアーカイバの自己解凍スタブなどでは、EXE の後に
単に copy コマンドで書庫ファイルをくっつけるだけでも動作するものがあります。
また、別の掲示板でお聞きした話によると、EXE は自ファイルを走査して
書庫ファイルの開始位置を探し、そこからデータを取り出すらしいです（あくまで実装
の一つの手段に過ぎません。全てこうというわけではありません）。
>> あれ？アライメントとらなくても大丈夫でしたっけ？
> 無知でごめんなさい。アライメントって何です？
> いや、言葉の意味は知っています。けど、このケースではどうするのかわかりません。
私も昔の記憶なので曖昧なのですが、実行ファイルのサイズを８バイトだったかでアライメント
しないとだめだったような記憶が・・・。
# VC++6にはその指定があったようななかったような・・・
Copyでくっつけるだけなら、たぶんデータの方をアライメントとってあげればいいとは思うの
ですが・・・。
で、心配になったのでちょっと調べてみると・・・
特に気にしなくてもいいっぽいようです(照
# どうも、PC以外の環境と頭がごっちゃになってるようで・・・申し訳ないです(涙
>> コピーでくっつけると・・・プログラムのちょっとした変更でアドレス変わっちゃう
>> から、私ならツール書きますねぇ・・・て、感じ？
> まぁ、プログラム中に固定アドレスを書くならそうなりますね。
> 詳しくはありませんが、例えばアーカイバの自己解凍スタブなどでは、EXE の後に
> 単に copy コマンドで書庫ファイルをくっつけるだけでも動作するものがあります。
その実行部分のサイズがもう変化ないですよって状態になってればどうとでも
できちゃうのでそういうのもありですね～
ただ、開発段階でのその余計な変更がちょっと・・・って思ってしまうのが私なので(照
> また、別の掲示板でお聞きした話によると、EXE は自ファイルを走査して
> 書庫ファイルの開始位置を探し、そこからデータを取り出すらしいです（あくまで実装
> の一つの手段に過ぎません。全てこうというわけではありません）。
たしか、セクションだかそんな概念だかがあって、そういう書き方をすると
プログラム中では変数参照できるようなことを聞いた事はあります。
間違って覚えてるかもですが・・・(汗
# この方法が本当につかえるなら、この方がいいと思います。
# ELFとかその辺りのドキュメントにあったようななかったような・・・
# 自分で書いておいてなんですが・・・頭の中が腐り掛けてきてるようで・・・(涙
# 曖昧な表現ばかりで申し訳ないですm(__
皆様ご意見ありがとうございます。
確かに一つの実行ファイルにまとめるとサイズが大きくなりますが、
ファイルが分散するのを防ぐことができます。
>必要なファイルが存在しないという状況があり得ない
おっしゃるとおりそれも利点ですね。
例えばゲームに必要なファイルを、
遊ぶユーザーが間違って消してしまう、ということもなくなります。
その他には、スクリプトや画像を簡単に見られなくなる
というのも大きな利点です。
それならば暗号化をすればいいと思われるかも知れませんが
私個人としてはこちらの方法がバグもそんなに発生せず、
暗号化よりは簡単そうだと思ったからです。
（ホントに個人的な意見ですが、エレガント？だと思いませんか？^^;）
私が考えているのはスクリプトエンジン（実行ファイル）と、
スクリプトエンジンとスクリプトファイルや画像ファイルを結合する
実行ファイルを作ってこの二つの実行ファイルを公開することです。
この方法ですと再度コンパイルしなくても大丈夫だと思います。
ユーザーに、最後にEXEファイル化してもらえれば
配布も簡単だと考えたからです。
実際にこのような仕組みを使われているソフトはいくつかあります。
実行ファイルに追加書き込みして試してみましたが問題なく動作しました。
これで、実行ファイルのプログラム部分のサイズを調べて、
その位置から後のデータを取り出せばできそうな気がしてきました。
この実行ファイルのプログラム部分のサイズの取得は、今はわかりませんが
調べてなんとかやってみようと思っています。
暗号化までしなくても単純に各データのサイズを管理する仕組みを作って
その管理部の後ろにバイナリイメージでデータをどかどか繋げるだけでも
十分かなと言う気もします。
まあ、独自のtarファイルみたいな物ですけどね。
引っこ抜いてでも見ようと言うような人なら実行ファイルにくっ付けても
バイナリで解析して見るでしょうしね。
ここから先は私も調べていないので疑問点なんですが、
仮に実行ファイルの後ろにデータファイルを単純に繋げた場合、
ロードモジュールとしてロードされるときに後ろの余計な部分まで
読み込まれたりしないんですかねぇ。
EXE側で自分のサイズを管理しているのであれば、実行時に必要な部分しか
メモリに展開されないと思うので実行ファイルそのものがいくら大きくなっても
問題ないような気がするんですが、
仮に実行ファイル全体を全て読み込んでしまうような作りだったとすると
実行ファイルのサイズがあまりに大きいと環境によっては実行できないというような
状況も考えられると思います。
スクリプトやら画像ファイルはゲームの作成者が用意しますから
どのくらいのサイズになるかは皆目わかりませんし、下手するとサイズが大きすぎて
特定の環境では実行できないなんてこともあるのではと思うのです。
あと実行ファイルが大きいとアプリの立ち上がりが遅いと言うのもありますね。
これも後付の部分が実行時のロードで読み込まれないのであれば、問題ないとは
思うんですけれどね。
まあ、アプリの用途にもよると思うのですけれど、
最近の開発の流れはどちらかと言うとモジュール化して組み合わせ自由。
状況に応じて機能を増やせるし、必要なければ最小構成でも動作可能と言うのが
多いと思います。
一つにまとめてしまうとその辺のメリットを生かす構成が出来なくなるので
私的にはあまりお勧めしないです。
ゲームの開発側まで巻き込んでしまって、
エンジン部分は一つ入れておいて必要なゲームの情報をtarのように一つのファイルに
まとめておいて、それをダウンロードして特定の場所に置けば、いろいろなゲームが
楽しめると言う構成もまた魅力的だと私は思います。
返信する
最新の投稿: お久しぶりです、いかがお過ごしでしょうか。 最新のメンバー: gantez 最近の投稿 未読の投稿
