いうのってどんなアイテムを持っているのか一つ一つフラグ変数なんかで記憶しているのですかねそれとも文字列なんかで記憶しておくのでしょうか(メニュー画面なんかを開いたときに文字列通りアイテムの名前を並べていく)前者の方法が普通ではないでしょうか。文字列で記憶するとセーブデータの容量が大きいですし、アイテム名を修正したらセーブデータが使えなくなってしまいます。アイテム名を自由に付けられるようなゲームなら、文字列も記憶しているでしょうがそのような場合でも、アイテムは何らかの通し番号で管理していると思います。8年前SQLite等のデータベースにぶっこんどくというのもアリですよね。ソートとか使えて便利ですし。私が今まで作ったRPGは全部番号で管理しています。番号だとテーブルの参照が添え字できるというメリットがありますね。私が書いたRPG講座もよかったら参考にしてください。C言語+DXライブラリです。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。SQLite等のデータベースにぶっこんどくというのもアリですよね。私が今まで作ったRPGは全部番号で管理しています。番号だとテーブルの参照が添え字できるというメリットがありますね。セーブデータの容量といわれると納得のような数値なら一般Widnowsの処理系ならint型で4バイトですが、文字列なら4バイトを確実に超えます。文字列のほうが情報量が多くなる→検索などが遅くなるんです。あと今持っているアイテムをアイテム番号を格納した数値配列で管理できますので、文字列で管理するよりはるかに楽です。これはファミコン時代から行われている手法ですね。テーブル?・・・ですか?素人ですので(業界用語?専門用語?)が分からないのですがよろしければ教えていただけないでしょうか?テーブルは構造体配列のことですね。アイテム番号で直接アイテム情報の入った構造体から情報(名前やら値段やらを)を取り出すことが出来ます。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。数値なら一般Widnowsの処理系ならint型で4バイトですが、文字列なら4バイトを確実に超えます。文字列のほうが情報量が多くなる→検索などが遅くなるんです。環境が明示されていないので何とも言えませんが正規表現ぐらいなんともないコストだと思うんですけどね。RPGなのでアクションゲームのように1フレーム内に処理する必要もありませんし。あと今持っているアイテムをアイテム番号を格納した数値配列で管理できますので、文字列で管理するよりはるかに楽です。これはファミコン時代から行われている手法ですね。文字列で管理する場合、連想配列をつかうと思うんですが操作は一緒ですよね。添字が数値か文字列かというだけで。c++ならstd::mapとかstd::unordered_map(c++11)を使えばいいのでむりにファミコン時代の手法を使う必要はないと思います。Cより高級な言語とか既存のライブラリを活用して楽に作った方がいいんじゃないかと思います。アイテム管理の箇所が速度的にボトルネックだった場合にはじめて高速化するのでないと「早すぎる最適化」になってしまうんではないかと。最適化といっても文字列からintにすればいいという単純な問題ではなくアルゴリズムやデータ構造を見直す必要があると思います。初心者なら小手先の高速化や省メモリにするといった事より優先されるべき事があるはずだと言いたいだけです。早すぎる最適化についてはRubyのまつもとゆきひろさんの言葉から引用します。evil(早すぎる最適化はすべての悪の源)」という諺があります。プログラムの高速化においては努力がいつも報われるとは限りません。むやみな高速化の試みは、かえってプログラムの見通しが悪くなったりする弊害の方が大きいのです。8年前ゲームだと開発途中でアイテム名とかをよく変更したりアイテム名が仮名だったりするので、名前を変え易くすると言う意識が高いんでenumなどの内部名で管理しているってのはありますね。C++だとそれこそ使い勝手考えてアイテムをクラスオブジェクトにした方が良いかもしれません。セーブするときにアイテム情報までセーブされてしまうとバランス調整に支障が出るので単にシリアライズされると困るんですよね。アイテム名かアイテム番号が適切になります。言うことで、終了ど間際で絶対アイテム名を変更しないならアイテム名でセーブしても良いと思いますが、変更する可能性があるならアイテム名は避けたほうが良いと思います。[追記]ここらへんは、開発者のクセってレベルかも知れません。多人数で開発しているときに付いた習性ですね。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。名前なんて変わりやすいものをキーにするなんて自殺行為ですね。した仕様変更でも大量に無駄な労力を払うことになるのが分かり切ってます。プログラムの効率以前の問題です。softyaさんもおっしゃっているように仕様変更が無いと言い切れるならかまいませんけど、そんなことはあり得ないでしょう。開発中に仮の名前を使ってデバッグする際に効率悪いし。デスマーチ仕様は運用後も悪影響を及ぼし続けるのです。高級な言語とか既存のライブラリを活用してもデスマーチ仕様がある限りデスマーチは生まれ続けます。8年前ここらへんはゲーム専業の人と一般アプリの専業の人では感覚が違うんでしょう。ゲームデザイン(ゲームプランナー)担当は最後の最後まで名称とかこだわりますから"うかつ"に名前を固定には出来ません。個人開発者なら違う感覚で開発しているのもいるかも知れませんが。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。ここらへんはゲーム専業の人と一般アプリの専業の人では感覚が違うんでしょう。ゲーム業界の前に、伝票管理とか物流のシステム開発してたことがありますけど、データベースレコード(特にマスターデータ)はレコード固有IDを仕込んで、関連付けは必ず固有IDで行うようにしてましたよ。得意先コードとかユーザーに見えるものは仕様変更を要求される可能性がありますから。経験の少ないSEはそういうの知らなくて、企業の合併や吸収で得意先コードを変えたいと言われて、何日も徹夜でトランザクションデータの更新を見守るハメになったひとがけっこういました。ゲームデザイン(ゲームプランナー)担当は最後の最後まで名称とかこだわりますから"うかつ"に名前を固定には出来ません。個人開発者なら違う感覚で開発しているのもいるかも知れませんが。何かモノを作るときはコードネームとか仮の名を付けたほうがカッコイイと思うのですよ。変更に強い仕様だと、開発中にもいろいろ遊べるんですよね。(追記)おなかを壊す「きのこ」と、体力を回復する「きのこ」、見た目で区別できない同名アイテムを作りたくなったらどうしましょう。あるスキルを身に付けると前者は「どくきのこ」と表示されるようにしたくなったらどうしましょう。連番付けておいたなら何の問題もないですね。8年前なにか誤解なさっているのかもしれませんがマジックナンバーやマジックストリング等の即値をそこら中にちりばめるなんてことは想定していないのでご安心ください。ゲームだと開発途中でアイテム名とかをよく変更したりアイテム名が仮名だったりするので、名前を変え易くすると言う意識が高いんでenumなどの内部名で管理しているってのはありますね。C++だとそれこそ使い勝手考えてアイテムをクラスオブジェクトにした方が良いかもしれません。セーブするときにアイテム情報までセーブされてしまうとバランス調整に支障が出るので単にシリアライズされると困るんですよね。アイテム名かアイテム番号が適切になります。言うことで、終了ど間際で絶対アイテム名を変更しないならアイテム名でセーブしても良いと思いますが、変更する可能性があるならアイテム名は避けたほうが良いと思います。実際のアイテム名との不一致(又は最初から不一致)がおきるとおもいますがそのままSWORD_1とかSWORD_2とかのままなんでしょうか。変える必要もありませんが、もし変える場合はテキストエディタ等で正規表現をつかってチャチャッと置き換えますよね。マジックストリングを使った場合もすぐ正規表現で変換できるのでそれほどの負荷なのかなぁと感じます。言っても自分がRPGを実装するんだっらやはりenum内部名とテーブルで管理すると思いますしその方が一般的だとも思います。本質的出ない部分ははぶいているので擬似コードとしてみてください。myItems[i])でもいいわけです。アイテムを追加するならこんな感じかな。引数はなんとなくですwというコードがあったとして一概にどれが優れているとも断言できないと思うんですよ。速度面ではテーブルの方が有利でしょうし基本テーブルで問題ないと思います。色んな実装方法がありますよね。別にカッコイイとか感覚で決めているわけではありません。名前なんて変わりやすいものをキーにするなんて自殺行為ですね。した仕様変更でも大量に無駄な労力を払うことになるのが分かり切ってます。プログラムの効率以前の問題です。あと今持っているアイテムをアイテム番号を格納した数値配列で管理できますので、文字列で管理するよりはるかに楽です。これはファミコン時代から行われている手法ですね。言ったのに対して所持アイテムを数値配列で管理するのとstd::stringの配列(softyaさんは単に文字列といいましたがstringの配列という理解でよろしいでしょうか?それとももっとプリミティブな文字列でしょうか。文字列で管理する場合、連想配列をつかうと思うんですが操作は一緒ですよね。添字が数値か文字列かというだけで。c++ならstd::mapとかstd::unordered_map(c++11)を使えばいいのでむりにファミコン時代の手法を使う必要はないと思います。実装方法の一つを提示しただけでデスマーチ仕様とまでいわれるのは心外です。これではなにも建設的な議論はできないと思うんです。おなかを壊す「きのこ」と、体力を回復する「きのこ」、見た目で区別できない同名アイテムを作りたくなったらどうしましょう。あるスキルを身に付けると前者は「どくきのこ」と表示されるようにしたくなったらどうしましょう。連番付けておいたなら何の問題もないですね。構造体の方にパラメータを付加させるのではダメなんでしょうか。8年前まず前提が違っていると思いますが、私はC言語でも出来る手法を中心に説明しています。C++の時はワザとC++と明言しています。ラスクさんが環境を明言していないのでもっともプリミティブな環境を想定していました。不一致(又は最初から不一致)がおきるとおもいますがそのままSWORD_1とかSWORD_2とかのままなんでしょうか。大体そのままじゃないでしょうか?いちいち変えていたらキリがないですし、正規表現とは言え置き換えると起きる問題の方が大きい(置き換えるにしても再テストが必要になる)と思いますし、アイテム番号で特殊機能を記述すると煩雑になるのでアイテム番号では無くENCHANT_FIREとか機能名enumを別に持つ管理方法が取られる場合は多いと思います。アイテム名enumではなく機能名enumを中心に使うと思います。実装方法の一つを提示しただけでデスマーチ仕様とまでいわれるのは心外です。これではなにも建設的な議論はできないと思うんです。ISLeさん的には苦い経験があって、そう仰っているものと思います。ISLeさんも私もゲームプログラマ(業界)歴が長いので危険なものは基本的に避けるクセが身に付いているので考え方の違いだとご理解ください。実際のアイテム名との不一致(又は最初から不一致)がおきるとおもいますがそのままSWORD_1とかSWORD_2とかのままなんでしょうか。変える必要もありませんが、もし変える場合はテキストエディタ等で正規表現をつかってチャチャッと置き換えますよね。マジックストリングを使った場合もすぐ正規表現で変換できるのでそれほどの負荷なのかなぁと感じます。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。前提が違っていると思いますが、私はC言語でも出来る手法を中心に説明しています。C++の時はワザとC++と明言しています。ラスクさんが環境を明言していないのでもっともプリミティブな環境を想定していました。自分もラスクさんが環境を明示していないのでc++ならstd::map等と、ことわりをいれています。連想配列を使う場合、C言語だとしてもGnomeのGLibに連想配列はありますし正規表現が使いたかったら鬼車をつかえばいいですし。C言語の場合の代替案を書いておくべきでしたねこの点は申し訳ありません。あと、なにがなんでも連想配列つかえって言ってるわけじゃないですよ...。質問されているのでセーブ前提で私は書いていましたが、hjklさんは違ったのでしょうか?そのセーブについてもstd::stringの配列でアイテムを管理していようとセーブファイル上では数値や暗号化された文字列等で分離しても問題ないとおもうんです。セーブするときにアイテム情報までセーブされてしまうとバランス調整に支障が出るので単にシリアライズされると困るんですよね。アイテム名かアイテム番号が適切になります。言うことで、終了ど間際で絶対アイテム名を変更しないならアイテム名でセーブしても良いと思いますが、変更する可能性があるならアイテム名は避けたほうが良いと思います。ついて得に異論はないと言いました。(ソフト屋)さんのミスリードだとおもいます)アイテム名かアイテム番号で管理するということに異論はないということです。(ソフト屋)さんの方ではアイテム名は避けた方がいいといっているので得に異論はないと言わずにアイテム名をつかうと明言したほうがよかったですね。自分の読解力がたらないだけかもしれませんがラスクさんの質問はアイテム管理の内部的な実装方法,又はアイテム保存時のセーブファイルの仕様またはそれらの複合が考えられました。連想配列を使うといった内部的な実装の話が自分は多かったのでセーブを前提にしていないととられたのかもしれませんね。セーブファイルの仕様についてはアイテム名かアイテム番号で管理するのがシンプルでいいとおもいます。8年前わたしのほうも前提が違ってますね。ここまでわたしは仕様レベルの話をしてて、実装レベルの話はしてなかったのですけどね。実装レベルの話をするなら、プログラムが直接扱うデータを外部データ化する際には番号に変換済みのものにします。メインプログラムはアルゴリズムがシンプルになるのでバグの混入が少なくなると思われるからです。内部でデータテーブルを番号で管理するのはアルゴリズムとデータ構造を見直した結果です。文字列からintにすれば高速化や省メモリになるといった単純な問題ではなく。8年前このフォーラムでは仕様と実装(実装を引き合いにだす事)を完全に分離して論じる必要があるんですね。私の"前提"が間違っていました、すみません。数値なら一般Widnowsの処理系ならint型で4バイトですが、文字列なら4バイトを確実に超えます。文字列のほうが情報量が多くなる→検索などが遅くなるんです。あと今持っているアイテムをアイテム番号を格納した数値配列で管理できますので、文字列で管理するよりはるかに楽です。これはファミコン時代から行われている手法ですね。テーブルは構造体配列のことですね。アイテム番号で直接アイテム情報の入った構造体から情報(名前やら値段やらを)を取り出すことが出来ます。言っているのですがこれは仕様レベルの話なんでしょうか、それとも実装を引き合いにだしているんでしょうか。配列や構造体が特定の言語の言語機能とは関係のない理論や概念の類である場合、仕様レベルの話ということになるでしょうか。文字列で管理する場合、連想配列をつかうと思うんですが操作は一緒ですよね。添字が数値か文字列かというだけで。(ソフト屋)さんと私は同じレベルの話をしている箇所があることがわかります。そのあとに特定の言語で連想配列を使うためのライブラリを紹介しました。c++ならstd::mapとかstd::unordered_map(c++11)を使えばいいのでむりにファミコン時代の手法を使う必要はないと思います。ゲームだと開発途中でアイテム名とかをよく変更したりアイテム名が仮名だったりするので、名前を変え易くすると言う意識が高いんでenumなどの内部名で管理しているってのはありますね。C++だとそれこそ使い勝手考えてアイテムをクラスオブジェクトにした方が良いかもしれません。セーブするときにアイテム情報までセーブされてしまうとバランス調整に支障が出るので単にシリアライズされると困るんですよね。アイテム名かアイテム番号が適切になります。言うことで、終了ど間際で絶対アイテム名を変更しないならアイテム名でセーブしても良いと思いますが、変更する可能性があるならアイテム名は避けたほうが良いと思います。おなかを壊す「きのこ」と、体力を回復する「きのこ」、見た目で区別できない同名アイテムを作りたくなったらどうしましょう。あるスキルを身に付けると前者は「どくきのこ」と表示されるようにしたくなったらどうしましょう。連番付けておいたなら何の問題もないですね。言われたのでenumはstringに、構造体配列を連想配列に置き換えても目的の動作を可能にできるということをご理解なさっておられないと思い、私の方も擬似コードをまじえて説明致しました。これが実装レベルの話とうことになるんでしょうかね。map版(それぞれenumとstringを数値配列、string配列。テーブルとmapを構造配列と連想配列とするべきでしたね)をみていただければ一つの仕様に対して複数の実装、又は目的の動作に対して複数の仕様が存在するということがお分かりいただけたでしょうか。動画や音楽を保存するコーデックにも複数のエンコーダ/デコーダの仕様、それに対する複数の実装が存在するのと同じです。ゲームのように抽象度の高いメディアの場合、目的の動作にたいする仕様、実装は多岐にわたるとおもわれます。ソースコード等は一部の先進的な企業や個人が公開するのみなので仕様や実装に関する議論をアマチュア間(自称ゲーム業界人含む)で行うことは有意義であると考え発言いたしました。この掲示板もそのような趣旨が含まれていると考えていました。「そーゆーとこじゃないよ」というのでしたら"前提"が違いましたね。わたしのほうも前提が違ってますね。ここまでわたしは仕様レベルの話をしてて、実装レベルの話はしてなかったのですけどね。そもそもISLeさんは私の仕様ないし実装にたいしてデスマーチ仕様と決め付けミスリードした発言と職場上の体験談のような事しか発言していない気がするのですが...。ここらへんはゲーム専業の人と一般アプリの専業の人では感覚が違うんでしょう。ゲームデザイン(ゲームプランナー)担当は最後の最後まで名称とかこだわりますから"うかつ"に名前を固定には出来ません。個人開発者なら違う感覚で開発しているのもいるかも知れませんが。何かモノを作るときはコードネームとか仮の名を付けたほうがカッコイイと思うのですよ。変更に強い仕様だと、開発中にもいろいろ遊べるんですよね。(ソフト屋)さんとISLeさんの一連の発言はどういった意図があったんでしょうか。ゲーム専業と一般アプリ専業や個人開発者の感覚の相違があったとしても実装者のレベルは様々なはずです。私は誠に勝手ながら間接的な人格攻撃と受けとらせていただきましたが、すくなくとも本題とまったく関係のない話題でしたので最初はスルー致しましたがやはり言及させていただきます。「ゲーム業界の標準ないし常識」というわけではありませんよね。いや、人格攻撃といった意図はなかったんでしょう。私が勝手にそう受け取っただけです。実装レベルの話をするなら、プログラムが直接扱うデータを外部データ化する際には番号に変換済みのものにします。メインプログラムはアルゴリズムがシンプルになるのでバグの混入が少なくなると思われるからです。内部でデータテーブルを番号で管理するのはアルゴリズムとデータ構造を見直した結果です。文字列からintにすれば高速化や省メモリになるといった単純な問題ではなく。(ソフト屋)さんが文字列で管理する場合の手法には触れず数値配列の方がはるかに楽と言い切ったようにどうもゲーム業界人様は発言に客観性や具体性がないようですね。メインプログラムとは具体的に何を指しているのでしょうか。「メインプログラムはアルゴリズムがシンプルになるので..」(!?)とういうのは外部データ化際の番号への変換をすることで勝手にシンプルになるとうことでしょうか?すばらしい実装ですね。typoしただけでしたらすみません。「内部でデータテーブルを番号で管理するのはアルゴリズムとデータ構造を見直した結果」とはどのような結果だったんでしょうか、他の実装と比較でもしたとうことですか。単純な問題ではないということなので詳細が気になりますがNDA等で発言できないようでしたら結構です。これが実装レベルの話なんでしょうか。自分の意見としましては主観的な意見であっても尊重されるべきでアイテム番号を数値配列で管理する仕様ないし実装がとにかくいいんだという場合でも一つの実装として尊重されるべきで同様にstringの配列で管理することも(もしかしたらenumのない言語でつかえるかもしれない)「そういう方法もあるんだね、あっそ」ぐらいの尊重はされるべきだと思います。SQL構文をそなえたデータベースで管理すればセーブファイルの代替としても使え便利かもしれない。多様な実装が存在するということがご理解いただければ幸です。あと、仕様と実装に関してすばらしい記事があったので引用させていただきます。仕様は,あるべき姿である。実装は,実際の姿である。一つの仕様に対して,複数の実装がありうる。装をするのだが,実装不可能な仕様を決めても意味がないので,実装をまったく考えずに仕様を決めてはいけない。実装が既にあって,そこから,本質的な部分を仕様にするということもある。それは,けっこうイケテル方法である。(管理人)さんへこの「C言語何でも質問掲示板」というフォーラム内コミュニティの排他性や閉鎖性、副管理人の非中立性についてやんわりとでもフォーラムルールに御記載いただければさいわいです排他的なのが悪いとも思いませんし多様性は善ですが新規利用者が困惑することを防げるとおもわれます。ISLeさん的には苦い経験があって、そう仰っているものと思います。ISLeさんも私もゲームプログラマ(業界)歴が長いので危険なものは基本的に避けるクセが身に付いているので考え方の違いだとご理解ください。いうような謎の回答を副管理人の方からなされました。古参ユーザを擁護するほうがコミュニティ的にも円滑に運営できるのかもしれませんが副管理人という立場上、中立的な存在だと勝手に思い込んでいましたのでとても困惑しました。これらは見過ごされるレベルのことなのでしょうか。私の被害妄想でしたらすみません。(管理人)さんへご意見ありがとうございます。思われることは多かったと思いますが、最後まで丁寧な言葉で書いて頂き幸いです。副管理人という立場上、中立的な存在だと勝手に思い込んでいましたのでとても困惑しました。当掲示板を含むコミュニティであるmixC++が出来たのはつい先日のことですが、softyaさんは、それまで当質問掲示板の一般の常連さんでいらっしゃいました。mixC++設立時に、私から個人的に副管理人の担当をお願いしました。副管理人をお願いしたと言っても、管理の側、中立的な立場に変更して頂くことをお願いしたわけではありません。今まで通りご利用頂いている中で、少しだけ、管理の仕事をお願いすることが出来ればと、お願いしました。以上のような事情があることご了承ください。当掲示板は可能な限り自由に利用でき、自由なやり取りが出来ることを目指しています。言え、トラブルが起きないよう管理はしていきます。古参ユーザを擁護するほうがコミュニティ的にも円滑に運営できるのかもしれませんがベテランの方に尊敬の意を払うということはありますが、考えも無しに古参擁護ということではありません。長年経験を積まれているベテランプログラマーのご意見は貴重なことが多いと認識しています。これは一般的な話ですが、プログラマーは多くの苦い経験から、それを思い起こさせるような仕様や考え方を酷く罵る傾向にあるように思います。それが原因で、言い争いになっているスレッド等時々見ることがありますが、それを理解した上で、お互いに最後まで討論をする姿勢を持たれてはいかがでしょう。当掲示板はお互いに、尊重する気持ちを持ちながら、討論できる場になれたらと思っています。今回、トピックと直接関係ない話が出てきたり、質問者さんの質問の範囲を超えた討論になっていることについても、私は特に問題には思っていません。討論の途中でも、質問の内容の続きを投稿すれば、話は戻ると思っています(もしくは2つの話が平行になるかもしれませんが)当時に、討論の途中でも、遠慮なく、トピック主である質問者さんには気軽に投稿して欲しいと思います。最後になりましたが、当サイトの管理体制や、運営方針などは、皆様のご意見を尊重して常に改善していこうと思っています。これからも何か思われることがあればご意見頂ければ幸いです。フォーラムルールについては、副管理人さんを含む4名で検討してみますね。不快な気分にさせてしまったことは申し訳ありません。立場を説明しておきますと、少なくとも副管理人は中立的な立場ではありません。スパムや問題のある書き込み(卑猥な言葉や不健全なサイトへのリンク)の修正などを主な仕事とさせていただいております。ここで細かいことを言っても同様に受け止められると危惧されるので一言だけ。セーブファイルの仕様・実装としてアイテム名等の文字列を使うことはだけ容認できません。今までの経験から、それだけは受け入れがたいので私の個人的意見と受け取ってください。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。8年前#なんか空気読めなくてすみません。このフォーラムでは仕様と実装(実装を引き合いにだす事)を完全に分離して論じる必要があるんですね。私の"前提"が間違っていました、すみません。hjklさんとsoftyaさんは実装レベルの話をしていたわたしは仕様レベルの話をしたそれだけのことではないのでしょうか。そもそもISLeさんは私の仕様ないし実装にたいしてデスマーチ仕様と決め付けミスリードした発言と職場上の体験談のような事しか発言していない気がするのですが...。後半はその通りですが。実装の話をしていないので、hjklさんの実装に対して何かを決め付けたりはしていませんしミスリードするはずもありません。わたしはプログラム以外への悪影響の話をしました。hjklさんはわたしに対しても実装の話をし続けました。わたしはその行為自体が問題だと思っていて返答に困ったのでとりあえず実装の話をして合わせてみようと思いました。メインプログラムとは具体的に何を指しているのでしょうか。ユーザーがゲームをプレイする際に実行されるメインのプログラムです。プログラムと言うだけではスクリプト等も含まれると思ったので。「メインプログラムはアルゴリズムがシンプルになるので..」(!?)とういうのは外部データ化際の番号への変換をすることで勝手にシンプルになるとうことでしょうか?すばらしい実装ですね。typoしただけでしたらすみません。シンプルにできるということですね。外部データ化の際に正規化されたインデックスを使うので、アイテム操作などを行うスクリプトエンジンは添字演算だけで組めます。プロジェクトによってはスクリプトエンジンをフルスクラッチで作ることもありますけど、正規化されたデータ前提ならたいした手間になりません。「内部でデータテーブルを番号で管理するのはアルゴリズムとデータ構造を見直した結果」とはどのような結果だったんでしょうか、他の実装と比較でもしたとうことですか。単純な問題ではないということなので詳細が気になりますがアイテムやモンスターのテーブルデータ、マップなどに埋め込むイベントスクリプト、等々とそれらを作成する担当者のスキル。データの整合性チェックや単体テストや結合テストに掛かるコスト。いったものを総合的に考えて、どこにどういったツールを用意するかやメインプログラムで考慮しなければならないことを決めます。最終的にメインプログラムに渡るデータの構造が決まります。RPGやRPGに近いジャンルのタイトルを手掛けたのは数えられるほどですが、チーム開発では別のスタッフが作成した外部データを読み込んで使うことはふつうにありますから、小規模ながら数百タイトルの経験値があります。改善が続く途中ですが、文字列をキーにしたらデスマーチ確定レベルなのは明らかと経験が言ってます。NDA等で発言できないようでしたら結構です。フリーランスですし汎用部分は建前上趣味で作ったコードを仕事に流用していることにしてますから大丈夫ですよ。これが実装レベルの話なんでしょうか。仕様書には載らない部分なのでわたしはそう判断しました。hjklさんが違うと思うなら無視してください。多様な実装が存在するということがご理解いただければ幸です。わたしは質問文から質問者さんが新しいことを試してみたいという意思を持っているようには読めなかったですし、商業ゲームの中身とまではいかなくとも、実際に作ってみてどんな実装が良かったか知りたいという主旨だと思ったので、自分の体験を元にしてます。hjklさんの投稿に拒否反応を起こしたのはそう考えていたことが理由です。引用というのは、引用した内容に言及している部分が質的量的に主で、引用部分が従でなければいけません。hjklさんがしているのは転載ですから、法的には著作者や出版元の許可が必要ですよ。(管理人)さん回答ありがとうございました。ここで細かいことを言っても同様に受け止められると危惧されるので一言だけ。セーブファイルの仕様・実装としてアイテム名等の文字列を使うことはだけ容認できません。今までの経験から、それだけは受け入れがたいので私の個人的意見と受け取ってください。私はセーブファイルについてアイテム番号でもなんでもケースバイケースで得に受け入れがたい仕様はありません(不必要に難解な仕様だと感じたら疑問を呈すかもしれませんが)例えば所持アイテムをアイテム名で保存した場合に思いつくのはセーブファイルから所持アイテムがユーザーから参照しやすくなりそれをユーザーが自由に書き換えてチートを許す仕様も考えられます。ゲーム側にそれらのオプションを変更するインターフェイスをつけるた方がいいとは思いますがPCゲーマーならコンフィグファイルの書き換え感覚で楽だと思う人もいるかもしれませんね。例えでチートをだしたのは最近じゃシングルプレイでもレベルやゲーム内通貨をリアルマネーで買えるRPG(たしかxboxのテイルズ)もあるくらいなのでチートを意識したRPGもありかなぁと。想像ですし個人的な意見です。自分はどうでもいいような可能性を考えすぎるきらいがあるのかもしれませんね。わたしは質問文から質問者さんが新しいことを試してみたいという意思を持っているようには読めなかったですし、商業ゲームの中身とまではいかなくとも、実際に作ってみてどんな実装が良かったか知りたいという主旨だと思ったので、自分の体験を元にしてますね。hjklさんの投稿に拒否反応を起こしたのはそう考えていたことが理由です。当掲示板は可能な限り自由に利用でき、自由なやり取りが出来ることを目指しています。言え、トラブルが起きないよう管理はしていきます。今回、トピックと直接関係ない話が出てきたり、質問者さんの質問の範囲を超えた討論になっていることについても、私は特に問題には思っていません。討論の途中でも、質問の内容の続きを投稿すれば、話は戻ると思っています(もしくは2つの話が平行になるかもしれませんが)当時に、討論の途中でも、遠慮なく、トピック主である質問者さんには気軽に投稿して欲しいと思います。発言されたのでこのフォーラムでは質問者さんの質問の解釈に、回答者同士に多少の相違があったとしても問題はなく質問に曖昧な箇所があったとしても質問の続きを投稿し質問を明確にしていけばより良い回答に繋がると判断されていると私は受け取ったので他の回答者の投稿に解釈の相違等によって拒否反応を起こすことやそれを表明するのは今後は改善していった方がいいかもしれません。RPGやRPGに近いジャンルのタイトルを手掛けたのは数えられるほどですが、チーム開発では別のスタッフが作成した外部データを読み込んで使うことはふつうにありますから、小規模ながら数百タイトルの経験値があります。改善が続く途中ですが、文字列をキーにしたらデスマーチ確定レベルなのは明らかと経験が言ってます。文字列で管理する場合、連想配列をつかうと思うんですが操作は一緒ですよね。添字が数値か文字列かというだけで。c++ならstd::mapとかstd::unordered_map(c++11)を使えばいいのでむりにファミコン時代の手法を使う必要はないと思います。言った仕様?に対してどこかデスマーチ確定レベルと断定できる部分はあるのでしょうか?文字列をキーにしたらデスマーチ確定レベルというのは無理がありませんか?連想配列といったデータ構造にたいして潜在的なデスマーチ仕様が含まれているのでしょうか。ISLeさんの最初の投稿で仕様変更への耐性について語られていますが文字列をキーにすると外部データの仕様や他のコンポーネントとの連携の仕様が一様に決まるのでしょうか。私がミスリードだと言っているのはこの点です。この際、具体的な説明もいらないので(あってももちろんOKです)「これはデスマーチ確定レベルだよ、自明だよ」とか「デスマーチ確定レベルとはいえない、たぶん」とかでいいので回答していただけるとありがたいです。ミスリードミスリード言ってしまうと逆にミスリードになってしまうので作為的に「前提が違う」という話をsoftya(ソフト屋)さんとISLeさんが言っていなかったのでしたらその点ではすみませんでした。引用というのは、引用した内容に言及している部分が質的量的に主で、引用部分が従でなければいけません。hjklさんがしているのは転載ですから、法的には著作者や出版元の許可が必要ですよ。(管理人)さん、私の発言中の他サイトからの引用箇所が法的またはフォーラムの規約上問題あるばあい当該箇所の削除をしていただきたいです。削除した場合は削除理由を明確にしていただけるとありがたいです。お手数ですが削除対象にならない場合も返信いただけるとありがたいです。それとも文字列なんかで記憶しておくのでしょうか(メニュー画面なんかを開いたときに文字列通りアイテムの名前を並べていく)と書いているので、おそらく文字列をキーにするという発想ではなく、セーブデータの内容をそのまま画面へレンダリングするという考えだったのではないかと思います。そこで質問なのですがRPGにアイテムって付き物ですよね?回復道具や装備品のことですああいうのってどんなアイテムを持っているのか一つ一つフラグ変数なんかで記憶しているのですかねそれとも文字列なんかで記憶しておくのでしょうか(メニュー画面なんかを開いたときに文字列通りアイテムの名前を並べていく)セーブ機能を付けるときに迷ったもんで素人すぎの質問で申し訳ないのですがだいたいのRPGはどんな風に作られているのでしょうか?私は、所持しているアイテムの情報をどうやって内部で保持していて、メニュー表示に使ったり、セーブしたりするのでしょう?って意味に受け取りました。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。8年前デスマーチの条件を私なりに考察してみます。どちらかというとアマの多人数製作・プロの現場的な考察になります。セーブファイルにアイテム名/魔法名/地名などが含まれる場合は、仕様変更や修正の度にセーブファイルが使えなくなりますので、最終調整中時に多大なムダ(頭からプレイし直し)が発生します。これはデスマーチ仕様だと思います。セーブファイルがデータベースで名前をキーに使う仕様も同様の問題を内包します。あとデバッグ担当から上がってきたバグ報告を確認するために、データやソースコードのバージョン戻しを掛ける必要が高い確率で出てくるのも問題点です。次にセーブファイル上はアイテム名/魔法名/地名などは番号管理でプログラム内部に取り込んだ時だけstringあるいは文字列にする場合の考察です。アイテム名やアイテムのパラメータ情報などは別の担当(ゲームプランナー)から受け取る外部ファイル(csv等)だと思いますので、これを参照して文字列に置き換える必要があります。これは内部的には、アイテム番号順のテーブルが必要だと思います。内部で文字列の定数などがあったら担当(ゲームプランナー)の情報を元に定数値を書き換える必要があります。これは無駄に手間のかかる実装だと思います。次にアイテム情報の検索ですが、所持アイテム名の配列からのアイテム情報を得るための検索はハッシュテーブルかデータベースを使えば簡単ですが、実際の所ロード時にアイテム番号からアイテム名の変換とアイテム情報ハッシュの生成あるいはデータベースの生成など手間が掛かる割には効率化出来ていないと言えると思えます。これなら、アイテム番号からアイテム情報やアイテム名をテーブル参照したほうが簡単です。これらの手間や複雑性はデスマーチ仕様になるうると思います。と私なりに考察してみました。思い込みや前提条件の偏りなどがあるかと思いますので精査していただければ幸いです。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。さんが書きました:文字列で管理する場合、連想配列をつかうと思うんですが操作は一緒ですよね。添字が数値か文字列かというだけで。c++ならstd::mapとかstd::unordered_map(c++11)を使えばいいのでむりにファミコン時代の手法を使う必要はないと思います。言った仕様?に対してどこかデスマーチ確定レベルと断定できる部分はあるのでしょうか?文字列をキーにしたらデスマーチ確定レベルというのは無理がありませんか?連想配列といったデータ構造にたいして潜在的なデスマーチ仕様が含まれているのでしょうか。ISLeさんの最初の投稿で仕様変更への耐性について語られていますが文字列をキーにすると外部データの仕様や他のコンポーネントとの連携の仕様が一様に決まるのでしょうか。私がミスリードだと言っているのはこの点です。他の回答者で無くて申し訳ありませんが、わたしがいつ「文字列をキーにしたらデスマーチ確定レベル」と書いたのでしょうか?「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。「キーにする」の主語は『(名前なんて)変わりやすいもの』ですよね。『文字列』がダメと書いてないどころか『文字列』という単語すら出てないですよね。いうのってなんて言うんでしたっけ。#ご本人が自覚しているくらい言われましたからお返ししても良いですよね。いつ気付いてくださるかと思ってましたけど諦めました。#後半の実装の話に"文字列"という単語が混じっているのは申し訳ないです。#ですがきっかけはそこではないので。書いているので、おそらく文字列をキーにするという発想ではなく、セーブデータの内容をそのまま画面へレンダリングするという考えだったのではないかと思います。このトピックで回答するなら解釈のズレがある場合は確認しあったほうがいいのかもしれませんね。私は、所持しているアイテムの情報をどうやって内部で保持していて、メニュー表示に使ったり、セーブしたりするのでしょう?って意味に受け取りました。(ソフト屋)さんと同じ意見です。(ソフト屋)さんの意見と相反するのなら別ですが。自分の読解力がたらないだけかもしれませんがラスクさんの質問はアイテム管理の内部的な実装方法,又はアイテム保存時のセーブファイルの仕様またはそれらの複合が考えられました。私がラスクさんの質問のなかに文字列をキーにする発想が含まれていると解釈、又はそれを推奨していると思っている人がいた時のためにいいますが私がラスクさんに文字列をキーにすることを推奨したのなら話は別ですがSQLiteやC言語より高級な言語や既存のライブラリを活用することしか推奨していませんし、アイテム管理に関わる処理に連想配列や構造体配列等を使った仕様ないし実装について想像し語ったこと等しかありません。どこかラスクさんに文字列をキーにする発想があると解釈している、ラスクさんに文字列をキーにすることを推奨している発言がありましたらご指摘いただけるとさいわいです。と私なりに考察してみました。思い込みや前提条件の偏りなどがあるかと思いますので精査していただければ幸いです。素晴らしい考察だと思います。(ソフト屋)さん自身お分かりいただけたと思います。(ソフト屋)さんが考察したような仕様を私が明らかにした上でISLeさんがデスマーチ仕様かどうか主張されたのなら私も妥当な主張だと受けとります。他の回答者で無くて申し訳ありませんが、わたしがいつ「文字列をキーにしたらデスマーチ確定レベル」と書いたのでしょうか?「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。改善が続く途中ですが、文字列をキーにしたらデスマーチ確定レベルなのは明らかと経験が言ってます。言っているのでそちらの言葉を使いましたがこの投稿箇所がきっかけではないので無効ということですね。「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。」という言葉を今後はつかわせてもらいます。前の投稿の質問を取り消し「文字列をキーにしたらデスマーチ確定レベル」という言葉にかわって「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。」という言葉をつかって再度質問させていただきます。文字列で管理する場合、連想配列をつかうと思うんですが操作は一緒ですよね。添字が数値か文字列かというだけで。c++ならstd::mapとかstd::unordered_map(c++11)を使えばいいのでむりにファミコン時代の手法を使う必要はないと思います。言った発言に対してどこか「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。」と断定できる部分はあるのでしょうか?名前という変わりやすいものをキーにする連想配列といったデータ構造にたいして潜在的な自殺行為、デスマーチ仕様が含まれているのでしょうか?この発言かこの発言をした私の2番目の投稿で「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。」と主張されるのに妥当な仕様を表明していたのでしょうか?この質問に関してはご自身で考案された仕様をデスマーチ仕様か考察されたりゲーム業界歴の長さを考慮したりせずに(発言がゲーム業界歴やベテランプログラマーといったことから独立させて考えるとこが不可能でしたらそれらを考慮してもらっても構いません)「断定できる」や「断定できない」「仕様を表明していた」「仕様を表明していない」等のなるべくわかりやすい回答をしてもらえるとありがたいです。断定的でなくても構いません。回答していただけたなら、なぜそのように判断をされたかの理由も書いてもらえらばありがたいです。(ソフト屋)さんやISLeさんやh2so5さんや他の回答者さん単純な質問だと思います。勇気をもってどうか回答してください。(管理人)さんの判断を仰ぎたいです。私がラスクさんの質問のなかに文字列をキーにする発想が含まれていると解釈、又はそれを推奨していると思っている人がいた時のためにいいますが私がラスクさんに文字列をキーにすることを推奨したのなら話は別ですがSQLiteやC言語より高級な言語や既存のライブラリを活用することしか推奨していませんし、アイテム管理に関わる処理に連想配列や構造体配列等を使った仕様ないし実装について想像し語ったこと等しかありません。どこかラスクさんに文字列をキーにする発想があると解釈している、ラスクさんに文字列をキーにすることを推奨している発言がありましたらご指摘いただけるとさいわいです。hjklさん自身がSQLiteやC言語より高級な言語や既存のライブラリを活用すること(std::mapとかstd::unordered_mapなどを言及されていたと思います)を書かれていますが、これは何のキーやデータを格納することを想定して書かれていたのでしょうか?ラスクさんが言及されているアイテムの扱いについてですね。(ソフト屋)さんと同じ意見です。」と書かれているので、どういう使い方を想定していて最初に書かれたのか内部保持とセーブに分けて説明していただけると助かります。[補記]途中までの書き込みで私が思ったのは、hjklさんは内部保持のキーやセーブデータにアイテム名等の文字列を使うと想定されているんだなってことです。それに基づいた推察で返事を書いております。14で「セーブファイルの仕様についてはアイテム名かアイテム番号で管理するのがシンプルでいいとおもいます。」と書かれておられますのでセーブファイルにアイテム名を使うことを想定したというのは誤解ではないですよね?であれば私の考察においてはデスマーチ仕様だとは思います。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。さんが書きました:文字列で管理する場合、連想配列をつかうと思うんですが操作は一緒ですよね。添字が数値か文字列かというだけで。c++ならstd::mapとかstd::unordered_map(c++11)を使えばいいのでむりにファミコン時代の手法を使う必要はないと思います。言った発言に対してどこか「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。」と断定できる部分はあるのでしょうか?名前という変わりやすいものをキーにする連想配列といったデータ構造にたいして潜在的な自殺行為、デスマーチ仕様が含まれているのでしょうか?この発言かこの発言をした私の2番目の投稿で「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。それとも文字列なんかで記憶しておくのでしょうか(メニュー画面なんかを開いたときに文字列通りアイテムの名前を並べていく)を指していることになるだけじゃないですか。言うことで、終了ど間際で絶対アイテム名を変更しないならアイテム名でセーブしても良いと思いますが、変更する可能性があるならアイテム名は避けたほうが良いと思います。受けて書いたものです。『終了ど間際で』変更したらデスマーチ確定ですよね。法的またはフォーラムの規約上問題あるばあい当該箇所の削除をしていただきたいです。削除した場合は削除理由を明確にしていただけるとありがたいです。お手数ですが削除対象にならない場合も返信いただけるとありがたいです。今までよほどのことが無い限り投稿文を削除したことはありません。特定のサイトから丸ごとコピーしてくると著作権的に問題あるかもしれませんが、今回は著作権保有者から削除依頼が来ない限りはそのままにさせていただこうと思います。単純な質問だと思います。勇気をもってどうか回答してください。(管理人)さんの判断を仰ぎたいです。特定の人と同じ意見になると、中立的な立場ではないことになりそうなので、申し訳ないですが今回は他の方にお任せします。ラスクさんいえいえ、ラスクさんのトピックなので、ラスクさんが一番自由に発言なさって下さい。討論が原因で、質問者さんが発言しにくくなっている現状があるとすると、利用規約を見直さなければなりません。ここでは初心者もベテランも気兼ねなく話が出来る場を目指しています。Dxprintfでしたっけ?printfDxじゃないですかね。printfDxはデバッグ用関数なので、もしゲームに使用するなら、DrawString系の関数をお使いください。html#R17N1また、フォントを使用しないデフォルトの描画だとやすっぽい文字列になりますので、CreateFontToHandleでフォントを作って利用する方法がのぞましいでしょう。8年前ラスクさん、お気になさらずに。分からないことがあれば気軽に質問してくださいね。私の提案の方法だと所持アイテム配列(アイテム番号を格納。このままセーブ対象)↓アイテム情報構造体配列[アイテム番号].アイテム名でアイテム名を取得できます。//価格//効果のタイプや属性などなどパラメータ続きます。ItemTable_t;//アイテム情報テーブル。-1,//持っていない状態。ITEM_EMPTY;}//ここから処理例//アイテムを得る。itemno;}}//アイテムを表示する。//一行分だけしたにずらす。動作確認してないのでエラーが出たらごめんなさい。[追記の追記]アイテム使用時に間が開いてしまうので表示時に間を詰めるように修正。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。8年前hjklさん、softyaさん、ISLeさんでもめているようですね。長く続いていてよくわかりにくいのですが3人の書き込みはこんな印象を受けました。hjklさんセーブデータにアイテム名を書いたっていいじゃありませんか。そりゃsoftyaさんとかISLeさんみたいにプログラムに長く関わったというわけじゃありませんが。頭ごなしに否定するのはやめてほしい。連想配列なんて言葉を使ったのは高級な言語や文法、ライブラリとかそういうのを使いこなすのに憧れているからだし。softyaさん通し番号で管理するのが一般的でよい方法だと考えております。番号が変わるかもしれないのなら内部値をenumで管理します。名前を変更しないならアイテム名を記録するという方法でもいいんじゃないでしょうか。おすすめはできません。万が一変えるとなったら面倒です。ISLeさんアイテム名を記録?ダメダメ、そんなのはほとんど変更されるんですから。完成直前で変更したらものすごく苦労するかもしれないんですよ。そんなの私だったら絶対に嫌ですね。アイテム名を記録するのを認めるような発言も不快です。「通し番号で管理するのはよい方法である」という点では一致しているようです。もめているのは「アイテム名をセーブデータに書き込むことは許されるか」のようです。私自身は「通し番号での管理が一般的で、アイテム名はセーブデータに書き込むべきではないというのならその通りにするのがよいでしょう。完全に個人でつくるならともかく、他の人の協力を得るつもりならより一般的な方法を使っているほうがやりやすくなるはずです。今回のラスクさんの質問は「解決」、と思いましたが「実は、番号で管理するといってもどうすればよいかまだよくわかっていません」とかありませんか?あるのでしたら、書き込んだほうがよいでしょう。私はRPGをつくっていないのでおそらく助けにはなれません。それはそれとして、なんとなく気になったのですがラスクさんは所持アイテムをどういう感じに表示されるつもりなのでしょうか?例として、以下のようなものが思いつきました。3例B.アイテムを一個一個表示。常にソートされた状態。操作を行わなければソートしない。ひのきのぼうやくそうなべのふたどくけしそうかわのぼうしやくそうどくけしそうどくけしそうそれぞれに対応した画像を表示するという手もありますね。hjklさんセーブデータにアイテム名を書いたっていいじゃありませんか。ISLeさんアイテム名を記録するのを認めるような発言も不快です。hjklさんがなぜ怒っているのか分からなかったんですけど、わたしがhjklさんの投稿に対して意見したことになってるんですね。hjklさんが、連想配列で文字列を管理する云々のところは正直何を言っているのか分かりません。技術的なことではなく、何のために何をどうしようとしているのか読み取れないからです。#RPGなのでフレーム関係ないってなんすかね。わたしは、hjklさんがセーブデータにアイテム名を使うと主張しているとは受け取っていません。いうかそこに関してはスルーです。前にも「hjklさんの実装に対して何かを決め付けたりはしていません」と書いてます。思い当たるとすれば「高級な言語とか既存のライブラリを活用」というフレーズを流用したことですが。高級な言語とか既存のライブラリを活用してもデスマーチ仕様がある限りデスマーチは生まれ続けます。楽で便利な開発手法でもデスマーチは避けられないって意味ですけどね。楽で便利な開発手法がデスマーチを生む、というふうには読めないと思うのですけど。デスマーチでメリットも帳消しになってしまうわけで。hjklさんのSQLiteの提案もリンク先のページには「多分実際のゲームでは」なんて書いてあるので実績のない話だと分かるんですが、ここは突っ込んじゃダメだと思ってスルーしたんですよ。わたしのデスマーチ発言は、ラスクさん、h2so5さん、softyaさんの、アイテム名を使う・使わない云々が明記されている投稿の流れを受けて書いたものです。デスマーチ発言前のhjklさんの投稿は、すべてスルーしてるんです。そのはずだったんですが、ついhjklさんの投稿からフレーズを流用してしまった。それでもやっぱり、どうしてhjklさんの投稿を否定したことになるのか分かりません。#なんかほんと質問と関係なくなってしまってすみません。8年前>>ISLeさんNo:33[74145]でわたし(ISLeさん)がhjklさんの投稿に対して意見したことになっているんですね。書かれていますがこれは私(Tatu)に対しての言葉ですね?では、どこを見てそう感じたかというとNo:27[74125]の(hjklさんのhjklさんがNo:7[73955]で示した名前をキーにするやり方のどこにデスマーチ仕様と断定できる要素があるんですかという内容に対し)hjklさんの投稿が関係ないと言うなら、わたしのデスマーチ発言は自動的に最初の質問に書かれている(ラスクさんの最初の文から引用)を指していることになるだけじゃないですか。いう文からhjklさんの投稿に意見していたのだと思いました。「文字列(名前)を記録(キーにする)」というやり方はよくないということになります。ついでにデスマーチ発言に関連している内容としてNo:24[74111]に他の回答者で無くて申し訳ありませんが、わたしがいつ「文字列をキーにしたらデスマーチ確定レベル」と書いたのでしょうか?「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。小規模ながら数百タイトルの経験値があります。改善が続く途中ですが、文字列をキーにしたらデスマーチ確定レベルなのは明らかと経験が言ってます。「高級な言語とか既存のライブラリを活用」というフレーズを流用したからhjklさんは怒っていると書いていますがそんなよくあるフレーズを流用したからって怒るとは思えません。「高級な言語とか既存のライブラリとか無意味」って書いてあるわけではありませんし。それよりは「何で私(hjklさん)の名前をキーにするやり方がデスマーチ仕様なんですか。いろんなやり方があっていいじゃないですか。」という感じだと思いますね。デスマーチだと思うかの説明についてはsoftyaさんのNo.23[74105]で十分だと思います。hjklさんも「素晴らしい考察だ」と評しており、納得しているようです。だいたいセーブデータに文字列を入れるとバージョンアップのたびにセーブデータが使えなくなるのでデスマーチ。プログラム内部のみで文字列をつかうにしても文字列が変わるたびにプログラムをいじらなければならないのでデスマーチ。アイテム番号からアイテム情報やアイテム名をテーブル参照するのが簡単。いう内容のようですね。引用された本人がどういう文脈で書いていたのかが確認しやすくなると思います。8年前hjklさん以外の方がそう書かれたので、わたしがhjklさんに対してデスマーチ発言したとするのが当然の雰囲気になっているのかと思ったんですよね。前にも書きましたけど、わたしが実装の話をしたのはhjklさんに絡まれたあとのことですし、デスマーチ発言に文字列という単語は一回も使われてません。hjklさんがデスマーチ発言で怒る理由にはならないですよね。hjklさんへの拒否反応から脊髄反射的に、softyaさんに被せて前提の話したり、実装の話を持ちだしたりしたのが完全に裏目に出た形ですね。あの時点でもhjklさんが何で絡んでくるのか分かってなかったので、前提の話で無関係を表明したつもりが、実装の話で自分から接近してしまったわけですね。冷静でなかったことは反省しています。(追記)「デスマーチ発言の対象は自動的に最初の質問」は、hjklさんに真っ向から勝手な思い込みですよと言ったら余計に怒らせると思って考えた末の表現です。自分で読み直しても分かりにくいと思います。14で「セーブファイルの仕様についてはアイテム名かアイテム番号で管理するのがシンプルでいいとおもいます。」と書かれておられますのでセーブファイルにアイテム名を使うことを想定したというのは誤解ではないですよね?であれば私の考察においてはデスマーチ仕様だとは思います。私の言葉がまちがっていましたセーブファイルの仕様についてアイテム名かアイテム番号で管理するのがシンプルでいいと言いましたがアイテムを数値か文字列で管理する(保存)といった方が適当でした。これがセーブファイルの仕様について誤解をまねいていたのだとおもいます。(ソフト屋)さんはこのアイテム名というのが変更されやすいものでアイテム番号が変更されずらいものとしていると思います。構造体の方に付与させるアイテムの名前を保存していると推測されていたのでしょう。そのように推測されたとしても妥当だと思います。それに私はたとえキーを文字列で保存するのも構造体の方に付与させるアイテム名を文字列で保存しても受け入れがたい仕様ではないのでチート仕様を例えでだしました。この例えではどちらかとうと構造体の方に付与させるアイテム名を保存する印象を強くさせてしまったのものと思います。最初から正確に書くべきでした。キーを文字列で保存するというのはキーがアイテム番号だったとしてそれを1と保存しようが"1"と保存しようがそれらを暗号化したものでもどれかが受け入れがたかったりそれのみによってデスマーチ仕様だとは思わないということです。(ソフト屋)さんからすればデスマーチ仕様が含まれていますね。私は基本的にデスマーチ仕様というものは存在せず、製作者同士のコミュニケーションが円滑に行われて入れば仕様が悪いまま製作が開始または進行しつづけるという事はおきないと考えています。仕様や製作者同士の連携が著しく悪く、開発が遅延しつづけるという事がデスマーチだと考えています。私の方では「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。文字列をキーにしたときに考えられる連想配列を使った実装について(名前なんて変わりやすいものをキーにするといっている以上セーブファイルの仕様ではなく内部的な実装のはずですから)自殺行為やデスマーチ仕様なのかどうかを重視して発言していたのとその連想配列の実装はセーブファイルの仕様と分離して考えることが可能なのでセーブファイルの仕様について正確性を欠いた発言をしました。そのセーブについてもstd::stringの配列でアイテムを管理していようとセーブファイル上では数値や暗号化された文字列等で分離しても問題ないとおもうんです。この発言でセーブファイルの仕様と内部の構造は分離して問題ないだろうと言ったつもりなのでそのような前提で発言しているとご理解いただけたかと思っていました。分離できないのでしょうか。セーブファイルについて質問されるのでこの辺にもお互い誤解があるのかもしれませんね。言われたのでenumはstringに、構造体配列を連想配列に置き換えても目的の動作を可能にできるということをご理解なさっておられないと思い、私の方も擬似コードをまじえて説明致しました。発言したのはenumのENCHANT_FIREという名前のキーがstringの"ENCHANT_FIRE"とう名前のキーであっても問題はないだろうという趣旨でしたがもっとわかりやすく書くべきでしたね。あと擬似コードの方でもSWORD_1で比較するのに対して"SWORD_1"とするべきでしたね。31の投稿で実際にコードを書かれたのでお聞きしたいのですがもし、あるアイテムが所持アイテムのテーブルに存在するかどうか確認する場合どのような処理になるのでしょうか。そんなことはRPGでは一般的な処理でないので考えたくないということでしたら結構ですし、ラスクさんの質問の意図と違うことを考えたくないという場合でもお答えいただけなくても結構です。セーブファイルの仕様について明示していない質問には答えられないということでしたらその場合も結構です。線形時間かかるものかと思いますが所持アイテムの総数が大きくなるにつれて連想配列の方が速度的に有利に働く場合もかんがえられませんか?構造体配列と連想配列のどちらが優位かとうことではありませんのでお気を悪くなさらないでください。このような場合も考えられませんかとうことです。他のフラグ変数等で管理する場合は連想配列だろうとなんだろうと関係ありませんがとりあえず私の方でこのような推察をしてみました。私はアルゴリズムの実行時間について詳しいわけではないので間違っているかもしれません。#RPGなのでフレーム関係ないってなんなんすかねよくわからないのですが、RPGなのでフレーム関係ないと誰か発言しているのでしょうか。コメントアウトされているのでわかりずらいのですが独り言か管理人さんや副管理人さんに対して発言されているのでしょうか。環境が明示されていないので何とも言えませんが正規表現ぐらいなんともないコストだと思うんですけどね。RPGなのでアクションゲームのように1フレーム内に処理する必要もありませんし。正規表現と決めつけてしまったことに関しては申し訳ありません。hjklさんがなぜ怒っているのか分からなかったんですけど、わたしがhjklさんの投稿に対して意見したことになってるんですね。わたしのデスマーチ発言は、ラスクさん、h2so5さん、softyaさんの、アイテム名を使う・使わない云々が明記されている投稿の流れを受けて書いたものです。デスマーチ発言前のhjklさんの投稿は、すべてスルーしてるんです。そのはずだったんですが、ついhjklさんの投稿からフレーズを流用してしまった。それでもやっぱり、どうしてhjklさんの投稿を否定したことになるのか分かりません。私に対する意見ではないとおもいますが怒っていませんし、否定されたとも認識していませんのでご安心ください。トピック内で行われた発言で、なおかつ自分の発言と関係のある話題について反応するのは自然だと思うのですがこのフォーラムでは推奨されない行いだと思われますので管理人様方、ぜひフォーラムルールに御記載いただきたいです。これについては多くの利用者にとって重要な問題だとおもわれます。(管理人)さんやsoftya(ソフト屋)さんの意見をお聞きしたいです。特定の人と同じ意見になると、中立的な立場ではないことになりそうなので、申し訳ないですが今回は他の方にお任せします。質問に回答いただくための条件に不備があったでしょうか。「この回答によって中立か非中立か決定されることはありません。気楽に回答してください。」とでも付与しなければなりませんでしたか。私の配慮がたりませんでした。あの質問(ある仕様がデスマーチ仕様と断定できるかできないか等)はこのトピックの一連の投稿上、コミュニティの不和を誘発する可能性があるので取り消させていただきます。排他的でないか非中立でないかといったことを有志のユーザーによって管理、運営されているフォーラムに意見したことに関してはお詫びします。人格攻撃があったのでないかという意見も自分の被害妄想ですのでどなたも自分の発言がそうだったのではないかという心配をされなくて結構です。(管理人)さんに質問なんですが、いくら自由なやりとりができる場とはいえ根拠が乏しいのに少し過激な表現(例えば自殺行為、デスマーチ仕様、たとえばです)を使い断定的に発言することや特定のユーザーを揶揄しているともとれる発言を複数人で行うといった事が確認できた場合どのような対応をとられるのでしょうか?このフォーラム内でそのような発言があるとは申していません。特定のユーザーを揶揄しているともとれる発言というのは例えば、(このトピックに偶然そのような発言が含まれてたとしても私はそれを引用しているわけではありません。例え話です)「なにかゲームプランナーのような人がいたとして終盤まで名称にこだわったりするから"うかつ"に名前なんか固定できねーなぁ、あいつらコードネームとかつけんのすきだもんなー、カッコイイとおもってるんかなー」なんて言いつつその後、追記で質問をしますが先の発言が特定のだれかを直接的に揶揄していない風にみせるため独り言のような記述をすることです。こんな事をする人はこのフォーラムに誰ひとりいません。そもそも揶揄というのは性質上これがそうだと断定できるものではありませんしね(断定できないようにするもの)。これがそもそも揶揄なんじゃないかって?そんなこと断定できませんよ(自分からこれは揶揄だと言わない限り)。私はあげあしをとられないように、論点をズラされないように、記述の統合性を保てるように、と細心の注意をはらって書く労力にこれ以上耐えられません(勝手にやっていることですので心配なさらずに)。勇気をだして回答してくださるとさいわいです。8年前せっかく質問に答えてわたしが書いた実装は無視かいな。いやいや独り言ですよ。実績も根拠も要らないなら、ブラジルのツレに電話して内容とアドレスを指定して送って貰った携帯メールをセーブデータにするっていう実装もアリですよねぇ。さんの内容が長すぎて内容が把握できているか自身自信が無いですが分かっている限り書いてみます。私は基本的にデスマーチ仕様というものは存在せず、製作者同士のコミュニケーションが円滑に行われて入れば仕様が悪いまま製作が開始または進行しつづけるという事はおきないと考えています。仕様や製作者同士の連携が著しく悪く、開発が遅延しつづけるという事がデスマーチだと考えています。関しては人間同士のやり取りですので、どんなに円滑にやり取りしているつもりでも誤解やミスは生じます。誤解やミスをしても被害は最小限に留めたいので誤読や打ち間違い率の長い文字列が重要なデータに混入するのを避けるに越したことは無いと思うのです。打ち間違いされても最小限の被害で抑えられる仕様を選択すべきだと思います。23に書きましたとおりアイテム識別文字列の"ENCHANT_FIRE"であろうと"SWORD_1"であろうとセーブファイルに文字列を書きだす手間とか、読み込む手間を掛けるほどのメリットを感じませんので準デスマーチ仕様だと私は思います。31の投稿で実際にコードを書かれたのでお聞きしたいのですがもし、あるアイテムが所持アイテムのテーブルに存在するかどうか確認する場合どのような処理になるのでしょうか。所持アイテム配列をforループで回して該当するアイテム番号の物を探すことになると思います。線形時間かかるものかと思いますが所持アイテムの総数が大きくなるにつれて連想配列の方が速度的に有利に働く場合もかんがえられませんか?構造体配列と連想配列のどちらが優位かとうことではありませんのでお気を悪くなさらないでください。このような場合も考えられませんかとうことです。他のフラグ変数等で管理する場合は連想配列だろうとなんだろうと関係ありませんがとりあえず私の方でこのような推察をしてみました。具体的にその連想配列は何がキーになっているのでしょうか?アイテム名をキーにした場合は要素がアイテム個数って仮定しますが、その場合はアイテム所持袋のアイテムの並びなどの仕様自体が内部構造のため制限を受けるこちになりますよね。ドラクエのように少なくともアイテム入手順には並べられません。比較できないとしか言えません。比較するなら、何百個も所持していたら少々差があるかもしれませんがhjklさんも言われた通りリアルタイム性の無いRPGで気にするほど時間差があるとも思えませんので、連想配列に頼る価値があるのか分かりません。それと時間を気にするならアイテム消費時の削除時の時間コストも気になるところです(たしか無茶苦茶遅かったはず)。ソートに関しては連想配列の場合は逆にアイテム名がキーなら強さ順ソートなどの場合メリットにならないはずです。しても比較したい場合は、とりあえずコードを書いて頂けますか?こちらが誤解を招く可能性があるのは、これまでのやり取りでご理解いただけたと思いますので、その上で比較したいと思います。[追記]便利と言う意味では、Sqliteでメモリ内に展開したデータベースでアイテム所持袋やアイテム情報を内部構造として持つほうが有意義です。ソートが楽ですからね。この方法は不用意なメモリ破壊バグの時に破壊されたメモリ内容の解析が難しくなり原因を追求し辛くなるので土壇場のデスマーチ率が高くなると私は思っています。不可解なバグは、最後にまとめて来ますからね。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。特定のユーザーを揶揄しているともとれる発言を複数人で行うといった事が確認できた場合どのような対応をとられるのでしょうか?上でも述べた通り、プログラマーの性格とでも言いますか、自分の技術を信じるがゆえに断定的な言い方になるのはよく見かけます。重複しますが、不適切な仕様を酷く罵る言動も良く見かけます(「ライブラリの仕様がカス過ぎて使えない」など)私ならそれはそういうものだと思って対応するかと思います。言動が荒かったからと言って過剰に反応しようとは思いません。褒め言葉から得ることより、批判から得ることの方が数段多いです。(例えば「公開されているゲーム面白かったです」と言われることから得ることと、「低スペックPCだと全然遊べなくてクソゲーだった」と言われることから得ることはどちらが多いでしょう)なかなか丁寧な言葉で指摘してくれる親切な人はいません。罵倒されてでも、批判から自分に得る物を私なら探します。・・ということで、批判は貴重な情報源であり、その際の多少の荒い言動は致し方ないものとし、よほどの酷い罵倒、明らかな個人攻撃であると判断出来る事が無い限り、特別な対応はしません。常連の回答者さんは皆良い方ばかりなので、特定ユーザーを非難したり非常識な言動をされる方はいらっしゃいませんでした。言い争いになったことは稀にありましたが、明らかに質問者が不適切な言動をしている場合がほとんどでした。従ってよほど「悪質」だと判断出来るやり取りが無い限り対応はしないつもりです。どれ位が悪質かという基準は特に明記していません。8年前ここのフォーラムを管理している技術管理人の御津凪(みつなぎ)と申します。これはこのトピックの質問・議論に対しての返答ではありませんのでご了承ください。(念のため書いておきます)フォーラムの技術的な話題です。引用された本人がどういう文脈で書いていたのかが確認しやすくなると思います。こちらにつきましては、技術的に拡張可能だと思いますので実装を前提に検討させていただきます。実は、このフォーラムにはオフトピック(本題とは関係の無い文章。独り言や本題とは別の話題など)という表現が搭載されています。[offtopic]テキスト[/offtopic]これはフォーラム当初から機能としてはあったのですが、使用方法(特に初めて使う方)の混乱を招くのではないかという考えから今まで管理人専用(副含む)として一般には表示を隠していました。今回、このトピックの内容を読ませていただき、本題に外れた発言(オフトピック)が多く見受けられ、またそれにより本来必要のない議論が発生していると感じましたので、このタグ(BBコード)の使用の明確化をゲストユーザーまで解放いたします。(オレンジ色のバルーンに「“”」と書かれているアイコンです)これにより、より明確な発言が出来るかと思います。(勿論、使用してくれる方がいないと意味がありませんが)とりあえず、「オフトピックテキスト」では分かり辛いので、後で分かりやすい名前に変更しますね。("独り言"とした方が意味的には扱いやすいかな?)あと、調整してなくてテキストがかなり見辛いのでこれも直しておきます。追記:名前と文字色を変更しました。ミクプラは自由にリンクできます。