ゲーム製作メモ
×
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
「過ぎた玩具は必要ない」を
HSPでのセーブを学びがてらいじっていたのだが、
やけにセーブデータが煩雑になってしまった。
セーブについてはもう少し調査が必要のようだ。
調査後、アストラガロマンシーに成長・セーブ要素を追加する予定。
企画倉庫->玩具
http://mangetsu.himegimi.jp/kikaku/ganngu/index.htm
HSPでのセーブを学びがてらいじっていたのだが、
やけにセーブデータが煩雑になってしまった。
セーブについてはもう少し調査が必要のようだ。
調査後、アストラガロマンシーに成長・セーブ要素を追加する予定。
企画倉庫->玩具
http://mangetsu.himegimi.jp/kikaku/ganngu/index.htm
PR
この記事にコメントする
無題
どうも、ななよんさん事１４スレ目の７４です。
失礼ながらソースコードも拝見しました。
ド素人から”ド”が外れかかってるレベルの自分が言うのも差し出がましく思えますが、
各値毎に書き出すファイルを分けるのは流石にちょっと非効率的ですよね。
ファイル数も多くなって見た目もちょっとアレな感じですし・・。
これはあくまで憶測なので実現できるかどうかは分かりませんが、
セーブしておきたい各値のサイズが固定されていて
その数もあまり多くない場合、
繰り返し構文をつかってこんな感じで読み込んだり書き込んだりする事ができそうな気がします。
１．ファイルの先頭からカウンタｘ変数１つのサイズ分だけ飛ばした所から
変数１つ分のサイズ読み込む
２．カウンタの値を＋１する
３．読み込みたい変数の個数分繰り返す
問題点として、まず読み書きに使う変数は配列にしておかないと
繰り返し構文を組み立てる時に面倒な点がありますね。
読み込んだ配列をそのまま使うのであれば特に問題もありませんが、
値毎に変数を分けてプログラミングしたいのであれば
読み込みに使った配列から各変数に値をコピーするか、
繰り返し構文を使わず片っ端から変数に読み込んでいく事になりますね。
Ｃ言語ならば動的に変数が取れる命令文があったはずなので、
読み書き用の一時的な配列を作って必要なくなったら
消去する事でメモリ消費量を抑える事もできるのですが・・。
また、あくまでできそうだという憶測なので
実現できるかどうかは分からないのも問題点です。（－－；
人のプログラムに彼是言ってる暇あるなら自分のをやれと言われたらぐうの音も出ません。（＾＾；
１４スレ目の７４でした。
失礼ながらソースコードも拝見しました。
ド素人から”ド”が外れかかってるレベルの自分が言うのも差し出がましく思えますが、
各値毎に書き出すファイルを分けるのは流石にちょっと非効率的ですよね。
ファイル数も多くなって見た目もちょっとアレな感じですし・・。
これはあくまで憶測なので実現できるかどうかは分かりませんが、
セーブしておきたい各値のサイズが固定されていて
その数もあまり多くない場合、
繰り返し構文をつかってこんな感じで読み込んだり書き込んだりする事ができそうな気がします。
１．ファイルの先頭からカウンタｘ変数１つのサイズ分だけ飛ばした所から
変数１つ分のサイズ読み込む
２．カウンタの値を＋１する
３．読み込みたい変数の個数分繰り返す
問題点として、まず読み書きに使う変数は配列にしておかないと
繰り返し構文を組み立てる時に面倒な点がありますね。
読み込んだ配列をそのまま使うのであれば特に問題もありませんが、
値毎に変数を分けてプログラミングしたいのであれば
読み込みに使った配列から各変数に値をコピーするか、
繰り返し構文を使わず片っ端から変数に読み込んでいく事になりますね。
Ｃ言語ならば動的に変数が取れる命令文があったはずなので、
読み書き用の一時的な配列を作って必要なくなったら
消去する事でメモリ消費量を抑える事もできるのですが・・。
また、あくまでできそうだという憶測なので
実現できるかどうかは分からないのも問題点です。（－－；
人のプログラムに彼是言ってる暇あるなら自分のをやれと言われたらぐうの音も出ません。（＾＾；
１４スレ目の７４でした。
配列を使えば行けそうですね
82です。
ななよんさんコメントありがとうございます。
私のプログラムは、
動けば良いという感じのスパゲティコードなので、
ソースコードを見られるのは凄く恥ずかしいですねw
でも、こういう具体的な意見をもらえたり
バックアップ代わりになるので今後もソースは残し続けようと思います。
配列を使えばとりあえずファイルはまとめられそうですね。
アスロマのセーブデータは
saveフォルダの中を4つにまとめて
autosave(CG・回想の保存)
savedata1(保存箇所１)
savedata2(保存箇所２)
savedata3(保存箇所３)
という形でまとめるつもりです。
ななよんさんのおっしゃるように、
本当は変数型ごとにサイズをきちんととるのが良いのですが、
まずは上記のようにセーブできることを目指して行こうと思います。
ご意見ありがとうございました。
具体的な意見が聞けるのはありがたいです。
それでは。
ななよんさんコメントありがとうございます。
私のプログラムは、
動けば良いという感じのスパゲティコードなので、
ソースコードを見られるのは凄く恥ずかしいですねw
でも、こういう具体的な意見をもらえたり
バックアップ代わりになるので今後もソースは残し続けようと思います。
配列を使えばとりあえずファイルはまとめられそうですね。
アスロマのセーブデータは
saveフォルダの中を4つにまとめて
autosave(CG・回想の保存)
savedata1(保存箇所１)
savedata2(保存箇所２)
savedata3(保存箇所３)
という形でまとめるつもりです。
ななよんさんのおっしゃるように、
本当は変数型ごとにサイズをきちんととるのが良いのですが、
まずは上記のようにセーブできることを目指して行こうと思います。
ご意見ありがとうございました。
具体的な意見が聞けるのはありがたいです。
それでは。
配列使ってまとめてみました
ななよんさんに届け！
玩具v008
セーブデータのみ変更版です。
変数で保存していたのを
配列で保存するように変更してみました。
企画倉庫->玩具
http://mangetsu.himegimi.jp/kikaku/ganngu/index.htm
中身は据え置きですが煩雑さは緩和されました。
二次元配列を使えばセーブ1～3もできそうですね。
参考になりましたー。
ななよんさんありがとう。
玩具v008
セーブデータのみ変更版です。
変数で保存していたのを
配列で保存するように変更してみました。
企画倉庫->玩具
http://mangetsu.himegimi.jp/kikaku/ganngu/index.htm
中身は据え置きですが煩雑さは緩和されました。
二次元配列を使えばセーブ1～3もできそうですね。
参考になりましたー。
ななよんさんありがとう。
知っていたらごめんなさい。
ＣＧとか回想の回収有無をセーブしておく方式として、
１ビット単位（２進数）でＯＮ／ＯＦＦスイッチを再現してしまうという手があります。
たとえば、４つ分のＣＧの回収有無を管理しようと考えた場合、
１ビット目が１ならばＣＧ１は回収済み
２ビット目が１ならばＣＧ２は回収済み
３ビット目が１ならばＣＧ３は回収済み
４ビット目が１ならばＣＧ４は回収済み
という感じに予め自分の中でルールを決めておきます。
このとき、ＣＧ１とＣＧ３だけ回収したとしたら
１・・・ＣＧ１（１ビット目）
０・・・ＣＧ２（２ビット目）
１・・・ＣＧ３（３ビット目）
０・・・ＣＧ４（４ビット目）
となり、ＣＧの回収状態を表す変数には２進数で”０１０１”という値が入る事に。
ただ、多くのプログラムだと普通は１０進数で扱われるはずなので、
０１０１→５と変数には入る事になると思いますし、
セーブデータ上に書き出す時も５と記録されるかと思います。
こうすると一見、本当にＣＧ４つ分の回収有無の管理が出来ているのか怪しいですが
ＣＧの回収状態を表す変数の値が５となるのは
２進数の特徴上「ＣＧ１とＣＧ３だけ回収している」時だけなので、
結果的にはＣＧ１つ毎に変数を割り振って
その変数の値が０か１かを１つ１つ見ていくのと同じ事になります。
一応、今回の例で全パターンを書き出すと・・
２進数→１０進数→状態
００００→０→ＣＧ１～４未回収
０００１→１→ＣＧ１のみ
００１０→２→ＣＧ２のみ
００１１→３→ＣＧ１と２のみ
０１００→４→ＣＧ３のみ
０１０１→５→ＣＧ１と３のみ
０１１０→６→ＣＧ２と３のみ
０１１１→７→ＣＧ１と２と３のみ
１０００→８→ＣＧ４のみ
１００１→９→ＣＧ１と４のみ
１０１０→１０→ＣＧ２と４のみ
１０１１→１１→ＣＧ１と２と４のみ
１１００→１２→ＣＧ３と４のみ
１１０１→１３→ＣＧ１と３と４のみ
１１１０→１４→ＣＧ１と２と３のみ
１１１１→１５→ＣＧ１～４コンプ済み
実はこの考え方は黎明期のＲＰＧとかＳＬＧとかの頃から既に商用ゲームで使われていて、
今でも多くのＲＰＧやＳＬＧで使われてたりします。（＾＾；
やたら長くなってすみませんでした。
セーブデータ周りはゲームプログラミングで必ず頭を抱える部分だと思いますが、
マッタリマイペースで制作がんばってください。
１４スレ目の７４でした。
１ビット単位（２進数）でＯＮ／ＯＦＦスイッチを再現してしまうという手があります。
たとえば、４つ分のＣＧの回収有無を管理しようと考えた場合、
１ビット目が１ならばＣＧ１は回収済み
２ビット目が１ならばＣＧ２は回収済み
３ビット目が１ならばＣＧ３は回収済み
４ビット目が１ならばＣＧ４は回収済み
という感じに予め自分の中でルールを決めておきます。
このとき、ＣＧ１とＣＧ３だけ回収したとしたら
１・・・ＣＧ１（１ビット目）
０・・・ＣＧ２（２ビット目）
１・・・ＣＧ３（３ビット目）
０・・・ＣＧ４（４ビット目）
となり、ＣＧの回収状態を表す変数には２進数で”０１０１”という値が入る事に。
ただ、多くのプログラムだと普通は１０進数で扱われるはずなので、
０１０１→５と変数には入る事になると思いますし、
セーブデータ上に書き出す時も５と記録されるかと思います。
こうすると一見、本当にＣＧ４つ分の回収有無の管理が出来ているのか怪しいですが
ＣＧの回収状態を表す変数の値が５となるのは
２進数の特徴上「ＣＧ１とＣＧ３だけ回収している」時だけなので、
結果的にはＣＧ１つ毎に変数を割り振って
その変数の値が０か１かを１つ１つ見ていくのと同じ事になります。
一応、今回の例で全パターンを書き出すと・・
２進数→１０進数→状態
００００→０→ＣＧ１～４未回収
０００１→１→ＣＧ１のみ
００１０→２→ＣＧ２のみ
００１１→３→ＣＧ１と２のみ
０１００→４→ＣＧ３のみ
０１０１→５→ＣＧ１と３のみ
０１１０→６→ＣＧ２と３のみ
０１１１→７→ＣＧ１と２と３のみ
１０００→８→ＣＧ４のみ
１００１→９→ＣＧ１と４のみ
１０１０→１０→ＣＧ２と４のみ
１０１１→１１→ＣＧ１と２と４のみ
１１００→１２→ＣＧ３と４のみ
１１０１→１３→ＣＧ１と３と４のみ
１１１０→１４→ＣＧ１と２と３のみ
１１１１→１５→ＣＧ１～４コンプ済み
実はこの考え方は黎明期のＲＰＧとかＳＬＧとかの頃から既に商用ゲームで使われていて、
今でも多くのＲＰＧやＳＬＧで使われてたりします。（＾＾；
やたら長くなってすみませんでした。
セーブデータ周りはゲームプログラミングで必ず頭を抱える部分だと思いますが、
マッタリマイペースで制作がんばってください。
１４スレ目の７４でした。
理解しました
ななよんさんこんにちはー。
製作スレでこの手(プログラム)の話題が中々できないので、
嬉しいです。
1ビット単位でのオンオフスイッチの再現は一応理解しました。
この方式のメリットは変数を減らせるということですよね。
CG等に関しては
多少効率が悪くても配列を使って
int cg[20];(C言語風、中身は0か1でスイッチ扱い)
とやろうと考えています。
要はスイッチ一つで配列の一つを使おうっていう
豪快なやりかたです。
多少効率は悪いでしょうが、
自分が理解しやすいほうが
後々ミスを引き起こさないと思いますので。
ビット単位方式で保存するメリットが
ほかにもあれば教えてください。
メリットによっては再検討も必要かもしれません。
ななよんさんありがとうございました。
またこの手の話を振ってくれたら飛びつきます。
ではではー。
製作スレでこの手(プログラム)の話題が中々できないので、
嬉しいです。
1ビット単位でのオンオフスイッチの再現は一応理解しました。
この方式のメリットは変数を減らせるということですよね。
CG等に関しては
多少効率が悪くても配列を使って
int cg[20];(C言語風、中身は0か1でスイッチ扱い)
とやろうと考えています。
要はスイッチ一つで配列の一つを使おうっていう
豪快なやりかたです。
多少効率は悪いでしょうが、
自分が理解しやすいほうが
後々ミスを引き起こさないと思いますので。
ビット単位方式で保存するメリットが
ほかにもあれば教えてください。
メリットによっては再検討も必要かもしれません。
ななよんさんありがとうございました。
またこの手の話を振ってくれたら飛びつきます。
ではではー。
先にも言ったとおり・・
セーブデータ周りに関してはプログラマーさんが悩む所の１つであり、
読み書きに用いる方法１つ、取捨したデータ１つで
プログラムにかなり大きな影響がでます。
まぁつまり、効率どうこう以上に自分のやりたい方法で行く方がいいって事です。
ビット単位でスイッチ状態を管理する方法は
沢山のスイッチの状態を少ない容量で保存できる特徴はあれど、
ソースコードの可読性を下げる要因にもなりますので、
保存するスイッチ量次第では使わないのも手です。
（四半世紀前のマシンならいざ知らず、今や容量なんて腐るほどありますしねｗ）
ある程度データの秘匿性も確保出来るとはいえ、
今や有名な保存方式の１つなのでちょっとでも
セーブデータ改造経験のある人間には即バレます。（＾＾；
こんな自分が言うのもアレですが、
数あるデータの保存方法の１つとして覚えておいて損はないかなと思います。
拘りだすとキリがないのがデータ管理。
程々にしないといけないのについ拘ってしまう。
１４スレ目の７４でした。
追伸
プログラムそっちのけで妄想があっちこっちに飛んでいます。
下手すると別企画をうｐしたりしなかったりしてしまうかも？ｗ
・・・いかんいかん、とりあえずバトロワに集中しまっす。（´ω｀；）
読み書きに用いる方法１つ、取捨したデータ１つで
プログラムにかなり大きな影響がでます。
まぁつまり、効率どうこう以上に自分のやりたい方法で行く方がいいって事です。
ビット単位でスイッチ状態を管理する方法は
沢山のスイッチの状態を少ない容量で保存できる特徴はあれど、
ソースコードの可読性を下げる要因にもなりますので、
保存するスイッチ量次第では使わないのも手です。
（四半世紀前のマシンならいざ知らず、今や容量なんて腐るほどありますしねｗ）
ある程度データの秘匿性も確保出来るとはいえ、
今や有名な保存方式の１つなのでちょっとでも
セーブデータ改造経験のある人間には即バレます。（＾＾；
こんな自分が言うのもアレですが、
数あるデータの保存方法の１つとして覚えておいて損はないかなと思います。
拘りだすとキリがないのがデータ管理。
程々にしないといけないのについ拘ってしまう。
１４スレ目の７４でした。
追伸
プログラムそっちのけで妄想があっちこっちに飛んでいます。
下手すると別企画をうｐしたりしなかったりしてしまうかも？ｗ
・・・いかんいかん、とりあえずバトロワに集中しまっす。（´ω｀；）
私は逆にこだわりがなさ過ぎるのが欠点です
アスロマです。ななよんさんコメントありがとー。
私はななよんさんと逆で
「こだわりがなさ過ぎる」のが欠点ですね。
「動けば良い」と考えすぎて、技術の進歩が遅いのです。
セーブに関しては「そういう方法もある」と記憶に留めつつ、
自分のやり方でやろうと思います。
【追伸への返信】
何かを作っているときに
別の企画が浮かぶのは良くあることですね。
共同制作をしているときには、別企画を立ち上げることは
他のメンバーに不安を与えるので良くないのですが(玩具も練習とはいえ本当は良くない)、
今のところななよんさんは単独なので立ち上げても良い気がします。
でも個人的には、ななよんさんには
実際にゲームを作って欲しいです。
作り始めると自分の企画に
「何が足りなかったのか」と、「何が売りなのか」が見えてきますし、
他の人に協力を求めるときの目安になりますので。
1キャラ1ステージ棒人間で良いので見てみたいです。
私はななよんさんの文章が好きなので、
ノベルゲームでも行ける気がします。
それと、ななよんさんのwikiで
なぞちゃんがでる話があることを知ったので、
今週末には読ませて頂こうと思っています。
どうやら「馬鹿可愛い」らしいので期待！
ではでは、ありがとうございましたー。
私はななよんさんと逆で
「こだわりがなさ過ぎる」のが欠点ですね。
「動けば良い」と考えすぎて、技術の進歩が遅いのです。
セーブに関しては「そういう方法もある」と記憶に留めつつ、
自分のやり方でやろうと思います。
【追伸への返信】
何かを作っているときに
別の企画が浮かぶのは良くあることですね。
共同制作をしているときには、別企画を立ち上げることは
他のメンバーに不安を与えるので良くないのですが(玩具も練習とはいえ本当は良くない)、
今のところななよんさんは単独なので立ち上げても良い気がします。
でも個人的には、ななよんさんには
実際にゲームを作って欲しいです。
作り始めると自分の企画に
「何が足りなかったのか」と、「何が売りなのか」が見えてきますし、
他の人に協力を求めるときの目安になりますので。
1キャラ1ステージ棒人間で良いので見てみたいです。
私はななよんさんの文章が好きなので、
ノベルゲームでも行ける気がします。
それと、ななよんさんのwikiで
なぞちゃんがでる話があることを知ったので、
今週末には読ませて頂こうと思っています。
どうやら「馬鹿可愛い」らしいので期待！
ではでは、ありがとうございましたー。