プログラマ専用SNS ミクプラ

はじめまして　分からないところがあったので質問させていただきます

かなり前ですが趣味で模擬３ＤＲＰＧ（バードビュー、斜め見下ろし）をつくったのですが
今回はＲＰＧなんか作りたいなぁと久しぶりに思いまして1年ぶりにＣを触ります

そこで質問なのですがＲＰＧにアイテムって付き物ですよね？回復道具や装備品のことです
ああいうのってどんなアイテムを持っているのか一つ一つフラグ変数なんかで記憶しているのですかね
それとも文字列なんかで記憶しておくのでしょうか（メニュー画面なんかを開いたときに
文字列通りアイテムの名前を並べていく）
セーブ機能を付けるときに迷ったもんで素人すぎの質問で申し訳ないのですが
だいたいのＲＰＧはどんな風に作られているのでしょうか？

今は便利になったものでＤＸライブラリを使っております（最近、プログラミング館も見ました）

ラスクさんが書きました: ああいうのってどんなアイテムを持っているのか一つ一つフラグ変数なんかで記憶しているのですかね
それとも文字列なんかで記憶しておくのでしょうか（メニュー画面なんかを開いたときに
文字列通りアイテムの名前を並べていく）

前者の方法が普通ではないでしょうか。
文字列で記憶するとセーブデータの容量が大きいですし、
アイテム名を修正したらセーブデータが使えなくなってしまいます。

アイテム名を自由に付けられるようなゲームなら、文字列も記憶しているでしょうが
そのような場合でも、アイテムは何らかの通し番号で管理していると思います。

SQLite等のデータベースにぶっこんどくというのもアリですよね。ソートとか使えて便利ですし。
その４ SQLiteでRPGのアイテムを管理してみよう

私が今まで作ったＲＰＧは全部番号で管理しています。
番号だとテーブルの参照が添え字できるというメリットがありますね。

私が書いたＲＰＧ講座もよかったら参考にしてください。Ｃ言語+ＤＸライブラリです。
http://dixq.net/forum/blog.php?u=114&sd=a&c=2

〉〉ｈ２so５さん
通し番号ですか！　番号にすると数が多くなってしまい、処理が重くなるという素人の考えだったのですが
文字列のほうが重いのでしょうか　まぁセーブデータの容量といわれると納得のような

hjkl さんが書きました:SQLite等のデータベースにぶっこんどくというのもアリですよね。ソートとか使えて便利ですし

データベースというのもあるのですか！？新しいのにがっつきにくいという私の特性もあるのですが
後でじっくり読んでみようと思います

softya（ソフト屋) さんが書きました:私が今まで作ったＲＰＧは全部番号で管理しています。
番号だとテーブルの参照が添え字できるというメリットがありますね。

テーブル？・・・ですか？素人ですので（業界用語？専門用語？）が分からないのですが
よろしければ教えていただけないでしょうか？

番号がいいようなのでＲＰＧのアイテム管理は番号で管理しますね

ラスクさんが書きました:通し番号ですか！　番号にすると数が多くなってしまい、処理が重くなるという素人の考えだったのですが
文字列のほうが重いのでしょうか　まぁセーブデータの容量といわれると納得のような

数値なら一般Widnowsの処理系ならint型で４バイトですが、文字列なら４バイトを確実に超えます。
つまり文字列のほうが情報量が多くなる→検索などが遅くなるんです。

あと今持っているアイテムをアイテム番号を格納した数値配列で管理できますので、文字列で管理するよりはるかに楽です。
これはファミコン時代から行われている手法ですね。

ラスクさんが書きました:テーブル？・・・ですか？素人ですので（業界用語？専門用語？）が分からないのですが
よろしければ教えていただけないでしょうか？

テーブルは構造体配列のことですね。
アイテム番号で直接アイテム情報の入った構造体から情報（名前やら値段やらを）を取り出すことが出来ます。

softya (ソフト屋) さんが書きました:数値なら一般Widnowsの処理系ならint型で４バイトですが、文字列なら４バイトを確実に超えます。
つまり文字列のほうが情報量が多くなる→検索などが遅くなるんです。

環境が明示されていないので何とも言えませんが正規表現ぐらいなんともないコストだと思うんですけどね。
RPGなのでアクションゲームのように1フレーム内に処理する必要もありませんし。

softya (ソフト屋) さんが書きました:あと今持っているアイテムをアイテム番号を格納した数値配列で管理できますので、文字列で管理するよりはるかに楽です。
これはファミコン時代から行われている手法ですね。

文字列で管理する場合、連想配列をつかうと思うんですが操作は一緒ですよね。添字が数値か文字列かというだけで。
c++ならstd::mapとかstd::unordered_map(c++11)を使えばいいのでむりにファミコン時代の手法を使う必要はないと思います。

まずはCより高級な言語とか既存のライブラリを活用して楽に作った方がいいんじゃないかと思います。
んでアイテム管理の箇所が速度的にボトルネックだった場合にはじめて高速化するのでないと「早すぎる最適化」になってしまうんではないかと。
そして最適化といっても文字列からintにすればいいという単純な問題ではなくアルゴリズムやデータ構造を見直す必要があると思います。
初心者なら小手先の高速化や省メモリにするといった事より優先されるべき事があるはずだと言いたいだけです。

早すぎる最適化についてはRubyのまつもとゆきひろさんの言葉から引用します。

ソフトウェア業界には、昔から「premature optimization is source of all evil（早すぎる最適化はすべての悪の源）」という諺があります。
プログラムの高速化においては努力がいつも報われるとは限りません。むやみな高速化の試みは、かえってプログラムの見通しが悪くなったりする弊害の方が大きいのです。

まつもとゆきひろのハッカーズライフ：第9回　測定狂時代

ゲームだと開発途中でアイテム名とかをよく変更したりアイテム名が仮名だったりするので、名前を変え易くすると言う意識が高いんでenumなどの内部名で管理しているってのはありますね。
Ｃ++だとそれこそ使い勝手考えてアイテムをクラスオブジェクトにした方が良いかもしれません。
ただセーブするときにアイテム情報までセーブされてしまうとバランス調整に支障が出るので単にシリアライズされると困るんですよね。なので、やはりアイテム名かアイテム番号が適切になります。
と言うことで、終了ど間際で絶対アイテム名を変更しないならアイテム名でセーブしても良いと思いますが、変更する可能性があるならアイテム名は避けたほうが良いと思います。

[追記]
ここらへんは、開発者のクセってレベルかも知れません。
多人数で開発しているときに付いた習性ですね。

名前なんて変わりやすいものをキーにするなんて自殺行為ですね。
ちょっとした仕様変更でも大量に無駄な労力を払うことになるのが分かり切ってます。
デスマーチ仕様です。
プログラムの効率以前の問題です。

softyaさんもおっしゃっているように仕様変更が無いと言い切れるならかまいませんけど、そんなことはあり得ないでしょう。
開発中に仮の名前を使ってデバッグする際に効率悪いし。
デスマーチ仕様は運用後も悪影響を及ぼし続けるのです。

高級な言語とか既存のライブラリを活用してもデスマーチ仕様がある限りデスマーチは生まれ続けます。

ここらへんはゲーム専業の人と一般アプリの専業の人では感覚が違うんでしょう。
ゲームデザイン（ゲームプランナー）担当は最後の最後まで名称とかこだわりますから"うかつ"に名前を固定には出来ません。
ただ、個人開発者なら違う感覚で開発しているのもいるかも知れませんが。

softya（ソフト屋) さんが書きました:ここらへんはゲーム専業の人と一般アプリの専業の人では感覚が違うんでしょう。

ゲーム業界の前に、伝票管理とか物流のシステム開発してたことがありますけど、データベースレコード(特にマスターデータ)はレコード固有IDを仕込んで、関連付けは必ず固有IDで行うようにしてましたよ。
得意先コードとかユーザーに見えるものは仕様変更を要求される可能性がありますから。
経験の少ないSEはそういうの知らなくて、企業の合併や吸収で得意先コードを変えたいと言われて、何日も徹夜でトランザクションデータの更新を見守るハメになったひとがけっこういました。

softya（ソフト屋) さんが書きました:ゲームデザイン（ゲームプランナー）担当は最後の最後まで名称とかこだわりますから"うかつ"に名前を固定には出来ません。
ただ、個人開発者なら違う感覚で開発しているのもいるかも知れませんが。

何かモノを作るときはコードネームとか仮の名を付けたほうがカッコイイと思うのですよ。
変更に強い仕様だと、開発中にもいろいろ遊べるんですよね。

(追記)
おなかを壊す「きのこ」と、体力を回復する「きのこ」、見た目で区別できない同名アイテムを作りたくなったらどうしましょう。
さらに、あるスキルを身に付けると前者は「どくきのこ」と表示されるようにしたくなったらどうしましょう。
連番付けておいたなら何の問題もないですね。

なにか誤解なさっているのかもしれませんが
マジックナンバーやマジックストリング等の即値をそこら中にちりばめる
なんてことは想定していないのでご安心ください。

softya (ソフト屋) さんが書きました:ゲームだと開発途中でアイテム名とかをよく変更したりアイテム名が仮名だったりするので、名前を変え易くすると言う意識が高いんでenumなどの内部名で管理しているってのはありますね。
Ｃ++だとそれこそ使い勝手考えてアイテムをクラスオブジェクトにした方が良いかもしれません。
ただセーブするときにアイテム情報までセーブされてしまうとバランス調整に支障が出るので単にシリアライズされると困るんですよね。なので、やはりアイテム名かアイテム番号が適切になります。
と言うことで、終了ど間際で絶対アイテム名を変更しないならアイテム名でセーブしても良いと思いますが、変更する可能性があるならアイテム名は避けたほうが良いと思います。

セーブに関しては得に異論はありませんが
enumで内部名を使う場合、仕様変更後等に実際のアイテム名
との不一致(又は最初から不一致)がおきるとおもいますがそのままSWORD_1とかSWORD_2とかのままなんでしょうか。
もちろん変える必要もありませんが、もし変える場合はテキストエディタ等で
正規表現をつかってチャチャッと置き換えますよね。
マジックストリングを使った場合もすぐ正規表現で変換できるのでそれほどの負荷なのかなぁと感じます。

っと言っても自分がRPGを実装するんだっらやはり
enum内部名とテーブルで管理すると思いますしその方が一般的だとも思います。
でも内部名とかマジックストリングが使われる箇所ってそれほど多くないですよね
ifやswitch(std::stringでswitch使えないのはデメリット)で場合わけするときに

コード:

// playerが仕様武器等を選択する処理ってこんな感じでしょうか?
// アイテムを持ってない場合も想定している部分とかあったり変なコードかもしれませんが
// まぁこういう武器orアイテムを持っていた場合の処理を決めるっていう方が近い?
// 本質的出ない部分ははぶいているので擬似コードとしてみてください。

// enum + テーブル版
type = myItems[i];
switch (type) {
case SWORD_1:
   player.weapon = item_list[type];
   ...

// string + map版 utf-8を想定
// ここではマジックストリングを使っていますが
// if (name == myItems[i])でもいいわけです。
if ("こんぼう" == myItems[i]) // myItemsから取り出してからifった方が効率的だけどあえて
  player.weapon = item_list[myItems[i]];
//又はmyItemsをmapにするのもアリかな
auto itr = myItems.find("こんぼう")
if (itr != myItems.end())
  player.weapon = itr->second;
else 
  myItems["こんぼう"] = Item::createItem("こんぼう", true, "毒"); // もしアイテムを追加するならこんな感じかな。引数はなんとなくですw

というコードがあったとして一概にどれが優れているとも断言できないと思うんですよ。
速度面ではテーブルの方が有利でしょうし基本テーブルで問題ないと思います。
色んな実装方法がありますよね。
別にカッコイイとか感覚で決めているわけではありません。

ISLe さんが書きました:名前なんて変わりやすいものをキーにするなんて自殺行為ですね。
ちょっとした仕様変更でも大量に無駄な労力を払うことになるのが分かり切ってます。
デスマーチ仕様です。
プログラムの効率以前の問題です。

自分はsoftya (ソフト屋)さんが

softya (ソフト屋) さんが書きました:あと今持っているアイテムをアイテム番号を格納した数値配列で管理できますので、文字列で管理するよりはるかに楽です。
これはファミコン時代から行われている手法ですね。

と言ったのに対して
所持アイテムを数値配列で管理するのとstd::stringの配列(softyaさんは単に文字列といいましたが
stringの配列という理解でよろしいでしょうか?それとももっとプリミティブな文字列でしょうか。だとしたらあまりフェアな比較ではないような...)
で管理するのとで数値配列の方がはるかに楽というのがあまり具体的ではなかったので腑に落ちず

hjkl さんが書きました:文字列で管理する場合、連想配列をつかうと思うんですが操作は一緒ですよね。添字が数値か文字列かというだけで。
c++ならstd::mapとかstd::unordered_map(c++11)を使えばいいのでむりにファミコン時代の手法を使う必要はないと思います。

といったわけです。

実装方法の一つを提示しただけでデスマーチ仕様とまでいわれるのは心外です。
これではなにも建設的な議論はできないと思うんです。

ISLe さんが書きました:おなかを壊す「きのこ」と、体力を回復する「きのこ」、見た目で区別できない同名アイテムを作りたくなったらどうしましょう。
さらに、あるスキルを身に付けると前者は「どくきのこ」と表示されるようにしたくなったらどうしましょう。
連番付けておいたなら何の問題もないですね。

構造体の方にパラメータを付加させるのではダメなんでしょうか。

コード:

Item *a = new Mushroom(STATUS::POISON)

まず前提が違っていると思いますが、私はＣ言語でも出来る手法を中心に説明しています。
なので、Ｃ++の時はワザとＣ++と明言しています。
ラスクさんが環境を明言していないのでもっともプリミティブな環境を想定していました。

hjkl さんが書きました:との不一致(又は最初から不一致)がおきるとおもいますがそのままSWORD_1とかSWORD_2とかのままなんでしょうか。

大体そのままじゃないでしょうか？いちいち変えていたらキリがないですし、正規表現とは言え置き換えると起きる問題の方が大きい(置き換えるにしても再テストが必要になる)と思いますし、アイテム番号で特殊機能を記述すると煩雑になるのでアイテム番号では無くENCHANT_FIREとか機能名enumを別に持つ管理方法が取られる場合は多いと思います。つまり、アイテム名 or アイテム名enumではなく機能名enumを中心に使うと思います。

hjkl さんが書きました: 実装方法の一つを提示しただけでデスマーチ仕様とまでいわれるのは心外です。
これではなにも建設的な議論はできないと思うんです。

ISLeさん的には苦い経験があって、そう仰っているものと思います。
ISLeさんも私もゲームプログラマ（業界）歴が長いので危険なものは基本的に避けるクセが身に付いているので考え方の違いだとご理解ください。

hjkl さんが書きました: セーブに関しては得に異論はありませんが
enumで内部名を使う場合、仕様変更後等に実際のアイテム名
との不一致(又は最初から不一致)がおきるとおもいますがそのままSWORD_1とかSWORD_2とかのままなんでしょうか。
もちろん変える必要もありませんが、もし変える場合はテキストエディタ等で
正規表現をつかってチャチャッと置き換えますよね。
マジックストリングを使った場合もすぐ正規表現で変換できるのでそれほどの負荷なのかなぁと感じます。

これに関しては、

ラスクさんが書きました:そこで質問なのですがＲＰＧにアイテムって付き物ですよね？回復道具や装備品のことです
ああいうのってどんなアイテムを持っているのか一つ一つフラグ変数なんかで記憶しているのですかね
それとも文字列なんかで記憶しておくのでしょうか（メニュー画面なんかを開いたときに
文字列通りアイテムの名前を並べていく）
セーブ機能を付けるときに迷ったもんで素人すぎの質問で申し訳ないのですが
だいたいのＲＰＧはどんな風に作られているのでしょうか？

と質問されているのでセーブ前提で私は書いていましたが、hjklさんは違ったのでしょうか？

softya (ソフト屋) さんが書きました:まず前提が違っていると思いますが、私はＣ言語でも出来る手法を中心に説明しています。
なので、Ｃ++の時はワザとＣ++と明言しています。
ラスクさんが環境を明言していないのでもっともプリミティブな環境を想定していました。

自分もラスクさんが環境を明示していないのでc++ならstd::map等と、ことわりをいれています。
連想配列を使う場合、C言語だとしてもGnomeのGLibに連想配列はありますし
正規表現が使いたかったら鬼車をつかえばいいですし。
でもC言語の場合の代替案を書いておくべきでしたね
この点は申し訳ありません。

あと、なにがなんでも連想配列つかえって言ってるわけじゃないですよ...。

softya (ソフト屋) さんが書きました:と質問されているのでセーブ前提で私は書いていましたが、hjklさんは違ったのでしょうか？

そのセーブについてもstd::stringの配列でアイテムを管理していようと
セーブファイル上では数値や暗号化された文字列等で分離しても問題ないとおもうんです。
ただこれだと不必要に複雑化したりそのままアイテム番号 + テーブルの方がシンプルで速ぇーじゃんと
いうことになるのでsoftya (ソフト屋)さんがいうようなセーブファイルの仕様

softya (ソフト屋) さんが書きました:ただセーブするときにアイテム情報までセーブされてしまうとバランス調整に支障が出るので単にシリアライズされると困るんですよね。なので、やはりアイテム名かアイテム番号が適切になります。
と言うことで、終了ど間際で絶対アイテム名を変更しないならアイテム名でセーブしても良いと思いますが、変更する可能性があるならアイテム名は避けたほうが良いと思います。

について
得に異論はないと言いました。

構造体をシリアライズしたものをそのまま保存するといった発想もなかったので(アイテム情報をセーブするというのはsoftya (ソフト屋)さんのミスリードだとおもいます)
アイテム名かアイテム番号で管理するということに異論はないということです。
softya (ソフト屋)さんの方ではアイテム名は避けた方がいいといっているので
得に異論はないと言わずにアイテム名をつかうと明言したほうがよかったですね。すみません。

自分の読解力がたらないだけかもしれませんがラスクさんの質問は
アイテム管理の内部的な実装方法,又はアイテム保存時のセーブファイルの仕様
またはそれらの複合が考えられました。

連想配列を使うといった内部的な実装の話が自分は多かったので
セーブを前提にしていないととられたのかもしれませんね。
セーブファイルの仕様についてはアイテム名かアイテム番号で管理するのが
シンプルでいいとおもいます。

わたしのほうも前提が違ってますね。
ここまでわたしは仕様レベルの話をしてて、実装レベルの話はしてなかったのですけどね。

実装レベルの話をするなら、プログラムが直接扱うデータを外部データ化する際には番号に変換済みのものにします。
メインプログラムはアルゴリズムがシンプルになるのでバグの混入が少なくなると思われるからです。
内部でデータテーブルを番号で管理するのはアルゴリズムとデータ構造を見直した結果です。
文字列からintにすれば高速化や省メモリになるといった単純な問題ではなく。

このフォーラムでは仕様と実装(実装を引き合いにだす事)を
完全に分離して論じる必要があるんですね。私の"前提"が間違っていました、すみません。

softya (ソフト屋) さんが書きました: 数値なら一般Widnowsの処理系ならint型で４バイトですが、文字列なら４バイトを確実に超えます。
つまり文字列のほうが情報量が多くなる→検索などが遅くなるんです。

あと今持っているアイテムをアイテム番号を格納した数値配列で管理できますので、文字列で管理するよりはるかに楽です。
これはファミコン時代から行われている手法ですね。

softya (ソフト屋) さんが書きました: テーブルは構造体配列のことですね。
アイテム番号で直接アイテム情報の入った構造体から情報（名前やら値段やらを）を取り出すことが出来ます。

と言っているのですがこれは仕様レベルの話なんでしょうか、それとも実装を引き合いにだしているんでしょうか。
配列や構造体が特定の言語の言語機能とは関係のない理論や概念の類である場合、仕様レベルの話ということになるでしょうか。

私の方も

hjkl さんが書きました: 文字列で管理する場合、連想配列をつかうと思うんですが操作は一緒ですよね。添字が数値か文字列かというだけで。

という発言をしましたがこれも特定の言語機能については言及していないので仕様レベルの話ということでいいでしょうか?
これらが仕様レベルでも実装レベルでもsoftya (ソフト屋)さんと私は同じレベルの話をしている箇所があることがわかります。
そのあとに特定の言語で連想配列を使うためのライブラリを紹介しました。

hjkl さんが書きました: c++ならstd::mapとかstd::unordered_map(c++11)を使えばいいのでむりにファミコン時代の手法を使う必要はないと思います。

その後softya (ソフト屋)さんが

softya (ソフト屋) さんが書きました: ゲームだと開発途中でアイテム名とかをよく変更したりアイテム名が仮名だったりするので、名前を変え易くすると言う意識が高いんでenumなどの内部名で管理しているってのはありますね。
Ｃ++だとそれこそ使い勝手考えてアイテムをクラスオブジェクトにした方が良いかもしれません。
ただセーブするときにアイテム情報までセーブされてしまうとバランス調整に支障が出るので単にシリアライズされると困るんですよね。なので、やはりアイテム名かアイテム番号が適切になります。
と言うことで、終了ど間際で絶対アイテム名を変更しないならアイテム名でセーブしても良いと思いますが、変更する可能性があるならアイテム名は避けたほうが良いと思います。

enumやクラス等、特定の言語機能(pythonやrubyではenumはありません、C言語を使うことを想定しているんだということでしたら
私の方もC言語で代替可能な話をしています)をまじえて説明をしたのと
ISLeさんが

ISLe さんが書きました: おなかを壊す「きのこ」と、体力を回復する「きのこ」、見た目で区別できない同名アイテムを作りたくなったらどうしましょう。
さらに、あるスキルを身に付けると前者は「どくきのこ」と表示されるようにしたくなったらどうしましょう。
連番付けておいたなら何の問題もないですね。

と言われたのでenumはstringに、構造体配列を連想配列に置き換えても目的の動作を可能にできるということを
ご理解なさっておられないと思い、私の方も擬似コードをまじえて説明致しました。
これが実装レベルの話とうことになるんでしょうかね。
enum + テーブル版とstring + map版(それぞれenumとstringを数値配列、string配列。テーブルとmapを構造配列と連想配列とするべきでしたね)
をみていただければ一つの仕様に対して複数の実装、又は目的の動作に対して複数の仕様が存在するということがお分かりいただけたでしょうか。

動画や音楽を保存するコーデックにも複数のエンコーダ/デコーダの仕様、それに対する複数の実装が存在するのと同じです。
ゲームのように抽象度の高いメディアの場合、目的の動作にたいする仕様、実装は多岐にわたるとおもわれます。
ソースコード等は一部の先進的な企業や個人が公開するのみなので仕様や実装に関する議論を
アマチュア間(自称ゲーム業界人含む)で行うことは有意義であると考え発言いたしました。またこの掲示板もそのような趣旨が含まれていると考えていました。
「そーゆーとこじゃないよ」というのでしたら"前提"が違いましたね。すみません。

ISLe さんが書きました:わたしのほうも前提が違ってますね。
ここまでわたしは仕様レベルの話をしてて、実装レベルの話はしてなかったのですけどね。

そもそもISLeさんは私の仕様ないし実装にたいしてデスマーチ仕様と決め付けミスリードした発言と
職場上の体験談のような事しか発言していない気がするのですが...。

softya (ソフト屋) さんが書きました: ここらへんはゲーム専業の人と一般アプリの専業の人では感覚が違うんでしょう。
ゲームデザイン（ゲームプランナー）担当は最後の最後まで名称とかこだわりますから"うかつ"に名前を固定には出来ません。
ただ、個人開発者なら違う感覚で開発しているのもいるかも知れませんが。

ISLe さんが書きました: 何かモノを作るときはコードネームとか仮の名を付けたほうがカッコイイと思うのですよ。
変更に強い仕様だと、開発中にもいろいろ遊べるんですよね。

これは本題とは関係ないんですが
このsoftya (ソフト屋)さんとISLeさんの一連の発言はどういった意図があったんでしょうか。
ゲーム専業と一般アプリ専業や個人開発者の感覚の相違があったとしても実装者のレベルは様々なはずです。
私は誠に勝手ながら間接的な人格攻撃と受けとらせていただきましたが、すくなくとも本題とまったく関係のない話題でしたので
最初はスルー致しましたがやはり言及させていただきます。
「あなた方の環境(職場の人材やローカルルール)」 = 「ゲーム業界の標準ないし常識」というわけではありませんよね。
いや、人格攻撃といった意図はなかったんでしょう。私が勝手にそう受け取っただけです。

ISLe さんが書きました: 実装レベルの話をするなら、プログラムが直接扱うデータを外部データ化する際には番号に変換済みのものにします。
メインプログラムはアルゴリズムがシンプルになるのでバグの混入が少なくなると思われるからです。
内部でデータテーブルを番号で管理するのはアルゴリズムとデータ構造を見直した結果です。
文字列からintにすれば高速化や省メモリになるといった単純な問題ではなく。

softya (ソフト屋)さんが文字列で管理する場合の手法には触れず数値配列の方がはるかに楽と言い切ったように
どうもゲーム業界人様は発言に客観性や具体性がないようですね。

まずメインプログラムとは具体的に何を指しているのでしょうか。
「メインプログラムはアルゴリズムがシンプルになるので..」(!?)とういうのは
外部データ化際の番号への変換をすることで勝手にシンプルになるとうことでしょうか?
すばらしい実装ですね。単にtypoしただけでしたらすみません。
「内部でデータテーブルを番号で管理するのはアルゴリズムとデータ構造を見直した結果」とは
どのような結果だったんでしょうか、他の実装と比較でもしたとうことですか。
単純な問題ではないということなので詳細が気になりますが
NDA等で発言できないようでしたら結構です。
はたしてこれが実装レベルの話なんでしょうか。

自分の意見としましては
主観的な意見であっても尊重されるべきでアイテム番号を数値配列で管理する仕様ないし実装が
とにかくいいんだという場合でも一つの実装として尊重されるべきで
同様にstringの配列で管理することも(もしかしたらenumのない言語でつかえるかもしれない)
「そういう方法もあるんだね、あっそ」ぐらいの尊重はされるべきだと思います。
例えばSQL構文をそなえたデータベースで管理すればセーブファイルの代替としても使え便利かもしれない。

多様な実装が存在するということがご理解いただければ幸です。

あと、仕様と実装に関してすばらしい記事があったので引用させていただきます。

仕様は，あるべき姿である。実装は，実際の
姿である。一つの仕様に対して，複数の実装
がありうる。通常は，仕様が決まってから実
装をするのだが，実装不可能な仕様を決めて
も意味がないので，実装をまったく考えずに
仕様を決めてはいけない。実装が既にあっ
て，そこから，本質的な部分を仕様にすると
いうこともある。それは，けっこうイケテル
方法である。

仕様と実装: H2's Log

最後にご覧になるかわかりませんが Dixq (管理人)さんへ

この「C言語何でも質問掲示板」というフォーラム内コミュニティの
排他性や閉鎖性、副管理人の非中立性についてやんわりとでもフォーラムルールに御記載いただければさいわいです
排他的なのが悪いとも思いませんし多様性は善ですが
新規利用者が困惑することを防げるとおもわれます。

なぜこのような意見をだすかというと、副管理人さんとISLeさんのミスリード(仕様が明確でないのに勝手なデスマーチ仕様と呼ぶ、無視できる又はお互いが歩み寄ることが可能なレベルの差異を前提が違うことにする等)
やトピックと関係のない話題を話す(ギョーカイ人だったらうんたらかんたら)他、ISLeさんにデスマーチ仕様と言われた事に対して意見したところ

softya (ソフト屋) さんが書きました: ISLeさん的には苦い経験があって、そう仰っているものと思います。
ISLeさんも私もゲームプログラマ（業界）歴が長いので危険なものは基本的に避けるクセが身に付いているので考え方の違いだとご理解ください。

というような謎の回答を副管理人の方からなされました。
古参ユーザを擁護するほうがコミュニティ的にも円滑に運営できるのかもしれませんが
副管理人という立場上、中立的な存在だと勝手に思い込んでいましたのでとても困惑しました。
これらは見過ごされるレベルのことなのでしょうか。私の被害妄想でしたらすみません。

以上です。

> hjklさん
> 最後にご覧になるかわかりませんが Dixq (管理人)さんへ

ご意見ありがとうございます。
色々思われることは多かったと思いますが、最後まで丁寧な言葉で書いて頂き幸いです。

> 副管理人という立場上、中立的な存在だと勝手に思い込んでいましたのでとても困惑しました。

当掲示板を含むコミュニティであるmixC++が出来たのはつい先日のことですが、softyaさんは、それまで当質問掲示板の一般の常連さんでいらっしゃいました。
そして、mixC++設立時に、私から個人的に副管理人の担当をお願いしました。
副管理人をお願いしたと言っても、管理の側、中立的な立場に変更して頂くことをお願いしたわけではありません。
今まで通りご利用頂いている中で、少しだけ、管理の仕事をお願いすることが出来ればと、お願いしました。
以上のような事情があることご了承ください。

当掲示板は可能な限り自由に利用でき、自由なやり取りが出来ることを目指しています。
とは言え、トラブルが起きないよう管理はしていきます。

> 古参ユーザを擁護するほうがコミュニティ的にも円滑に運営できるのかもしれませんが

ベテランの方に尊敬の意を払うということはありますが、考えも無しに古参擁護ということではありません。
ただやはり長年経験を積まれているベテランプログラマーのご意見は貴重なことが多いと認識しています。

これは一般的な話ですが、プログラマーは多くの苦い経験から、それを思い起こさせるような仕様や考え方を酷く罵る傾向にあるように思います。
それが原因で、言い争いになっているスレッド等時々見ることがありますが、それを理解した上で、お互いに最後まで討論をする姿勢を持たれてはいかがでしょう。
当掲示板はお互いに、尊重する気持ちを持ちながら、討論できる場になれたらと思っています。

また、今回、トピックと直接関係ない話が出てきたり、質問者さんの質問の範囲を超えた討論になっていることについても、私は特に問題には思っていません。
回答者の方は質問者さんの意思を優先して下さると思っていますので、
討論の途中でも、質問の内容の続きを投稿すれば、話は戻ると思っています(もしくは2つの話が平行になるかもしれませんが)
当時に、討論の途中でも、遠慮なく、トピック主である質問者さんには気軽に投稿して欲しいと思います。

最後になりましたが、当サイトの管理体制や、運営方針などは、皆様のご意見を尊重して常に改善していこうと思っています。
これからも何か思われることがあればご意見頂ければ幸いです。

# フォーラムルールについては、副管理人さんを含む4名で検討してみますね。

不快な気分にさせてしまったことは申し訳ありません。
立場を説明しておきますと、少なくとも副管理人は中立的な立場ではありません。
スパムや問題のある書き込み（卑猥な言葉や不健全なサイトへのリンク）の修正などを主な仕事とさせていただいております。

ここで細かいことを言っても同様に受け止められると危惧されるので一言だけ。
セーブファイルの仕様・実装としてアイテム名等の文字列を使うことはだけ容認できません。
今までの経験から、それだけは受け入れがたいので私の個人的意見と受け取ってください。

以上です。

#なんか空気読めなくてすみません。

hjkl さんが書きました:このフォーラムでは仕様と実装(実装を引き合いにだす事)を
完全に分離して論じる必要があるんですね。私の"前提"が間違っていました、すみません。

hjklさんとsoftyaさんは実装レベルの話をしていた
わたしは仕様レベルの話をした
それだけのことではないのでしょうか。

hjkl さんが書きました:そもそもISLeさんは私の仕様ないし実装にたいしてデスマーチ仕様と決め付けミスリードした発言と
職場上の体験談のような事しか発言していない気がするのですが...。

後半はその通りですが。
実装の話をしていないので、hjklさんの実装に対して何かを決め付けたりはしていませんしミスリードするはずもありません。

わたしはプログラム以外への悪影響の話をしました。
hjklさんはわたしに対しても実装の話をし続けました。
わたしはその行為自体が問題だと思っていて返答に困ったのでとりあえず実装の話をして合わせてみようと思いました。

hjkl さんが書きました:まずメインプログラムとは具体的に何を指しているのでしょうか。

ユーザーがゲームをプレイする際に実行されるメインのプログラムです。
プログラムと言うだけではスクリプト等も含まれると思ったので。

hjkl さんが書きました:「メインプログラムはアルゴリズムがシンプルになるので..」(!?)とういうのは
外部データ化際の番号への変換をすることで勝手にシンプルになるとうことでしょうか?
すばらしい実装ですね。単にtypoしただけでしたらすみません。

シンプルにできるということですね。
外部データ化の際に正規化されたインデックスを使うので、アイテム操作などを行うスクリプトエンジンは添字演算だけで組めます。
プロジェクトによってはスクリプトエンジンをフルスクラッチで作ることもありますけど、正規化されたデータ前提ならたいした手間になりません。

hjkl さんが書きました:「内部でデータテーブルを番号で管理するのはアルゴリズムとデータ構造を見直した結果」とは
どのような結果だったんでしょうか、他の実装と比較でもしたとうことですか。
単純な問題ではないということなので詳細が気になりますが

アイテムやモンスターのテーブルデータ、マップなどに埋め込むイベントスクリプト、等々とそれらを作成する担当者のスキル。
データの整合性チェックや単体テストや結合テストに掛かるコスト。
そういったものを総合的に考えて、どこにどういったツールを用意するかやメインプログラムで考慮しなければならないことを決めます。
そして最終的にメインプログラムに渡るデータの構造が決まります。

RPGやRPGに近いジャンルのタイトルを手掛けたのは数えられるほどですが、チーム開発では別のスタッフが作成した外部データを読み込んで使うことはふつうにありますから、小規模ながら数百タイトルの経験値があります。
もちろんいまだ改善が続く途中ですが、文字列をキーにしたらデスマーチ確定レベルなのは明らかと経験が言ってます。

hjkl さんが書きました:NDA等で発言できないようでしたら結構です。

フリーランスですし汎用部分は建前上趣味で作ったコードを仕事に流用していることにしてますから大丈夫ですよ。

hjkl さんが書きました:はたしてこれが実装レベルの話なんでしょうか。

仕様書には載らない部分なのでわたしはそう判断しました。
hjklさんが違うと思うなら無視してください。

hjkl さんが書きました:多様な実装が存在するということがご理解いただければ幸です。

わたしは質問文から質問者さんが新しいことを試してみたいという意思を持っているようには読めなかったですし、商業ゲームの中身とまではいかなくとも、実際に作ってみてどんな実装が良かったか知りたいという主旨だと思ったので、自分の体験を元にしてます。
hjklさんの投稿に拒否反応を起こしたのはそう考えていたことが理由です。

引用というのは、引用した内容に言及している部分が質的量的に主で、引用部分が従でなければいけません。
hjklさんがしているのは転載ですから、法的には著作者や出版元の許可が必要ですよ。

Dixq (管理人)さん回答ありがとうございました。

softya (ソフト屋) さんが書きました: ここで細かいことを言っても同様に受け止められると危惧されるので一言だけ。
セーブファイルの仕様・実装としてアイテム名等の文字列を使うことはだけ容認できません。
今までの経験から、それだけは受け入れがたいので私の個人的意見と受け取ってください。

わかりました。

私はセーブファイルについてアイテム番号でもなんでもケースバイケースで
得に受け入れがたい仕様はありません(不必要に難解な仕様だと感じたら疑問を呈すかもしれませんが)
例えば所持アイテムをアイテム名で保存した場合に思いつくのは
セーブファイルから所持アイテムがユーザーから参照しやすくなり
それをユーザーが自由に書き換えてチートを許す仕様も考えられます。
ゲーム側にそれらのオプションを変更するインターフェイス
をつけるた方がいいとは思いますがPCゲーマーならコンフィグファイルの書き換え感覚で楽だと思う人もいるかもしれませんね。
例えでチートをだしたのは
最近じゃシングルプレイでもレベルやゲーム内通貨をリアルマネーで買えるRPG(たしかxboxのテイルズ)もあるくらいなので
チートを意識したRPGもありかなぁと。まぁ想像ですし個人的な意見です。
ただ自分はどうでもいいような可能性を考えすぎるきらいがあるのかもしれませんね。

ISLe さんが書きました: わたしは質問文から質問者さんが新しいことを試してみたいという意思を持っているようには読めなかったですし、商業ゲームの中身とまではいかなくとも、実際に作ってみてどんな実装が良かったか知りたいという主旨だと思ったので、自分の体験を元にしてますね。
hjklさんの投稿に拒否反応を起こしたのはそう考えていたことが理由です。

これについてはDixq (管理人)さんが

Dixq (管理人) さんが書きました: 当掲示板は可能な限り自由に利用でき、自由なやり取りが出来ることを目指しています。
とは言え、トラブルが起きないよう管理はしていきます。

Dixq (管理人) さんが書きました: また、今回、トピックと直接関係ない話が出てきたり、質問者さんの質問の範囲を超えた討論になっていることについても、私は特に問題には思っていません。
回答者の方は質問者さんの意思を優先して下さると思っていますので、
討論の途中でも、質問の内容の続きを投稿すれば、話は戻ると思っています(もしくは2つの話が平行になるかもしれませんが)
当時に、討論の途中でも、遠慮なく、トピック主である質問者さんには気軽に投稿して欲しいと思います。

と発言されたのでこのフォーラムでは質問者さんの質問の解釈に、回答者同士に多少の相違があったとしても問題はなく
質問に曖昧な箇所があったとしても質問の続きを投稿し質問を明確にしていけばより良い回答に繋がる
と判断されていると私は受け取ったので
他の回答者の投稿に解釈の相違等によって拒否反応を起こすことやそれを表明するのは今後は改善していった方がいいかもしれません。

ISLe さんが書きました: RPGやRPGに近いジャンルのタイトルを手掛けたのは数えられるほどですが、チーム開発では別のスタッフが作成した外部データを読み込んで使うことはふつうにありますから、小規模ながら数百タイトルの経験値があります。
もちろんいまだ改善が続く途中ですが、文字列をキーにしたらデスマーチ確定レベルなのは明らかと経験が言ってます。

私も連想配列の信奉者というわけではないので(現に最初の回答ではsqlite推し)
他の回答者さん達(Dixqさんやsoftyaさんやそれ以外の方もお願いします)にお聞きしたいのですが

hjkl さんが書きました: 文字列で管理する場合、連想配列をつかうと思うんですが操作は一緒ですよね。添字が数値か文字列かというだけで。
c++ならstd::mapとかstd::unordered_map(c++11)を使えばいいのでむりにファミコン時代の手法を使う必要はないと思います。

と言った仕様?に対してどこかデスマーチ確定レベルと断定できる部分はあるのでしょうか?
文字列をキーにしたらデスマーチ確定レベルというのは無理がありませんか?
連想配列といったデータ構造にたいして潜在的なデスマーチ仕様が含まれているのでしょうか。
ISLeさんの最初の投稿で仕様変更への耐性について語られていますが文字列をキーにすると
外部データの仕様や他のコンポーネントとの連携の仕様が一様に決まるのでしょうか。
私がミスリードだと言っているのはこの点です。

この際、具体的な説明もいらないので(あってももちろんOKです)「これはデスマーチ確定レベルだよ、自明だよ」とか
「デスマーチ確定レベルとはいえない、たぶん」とかでいいので回答していただけるとありがたいです。

あまりミスリードミスリード言ってしまうと逆にミスリードになってしまうので
作為的に「前提が違う」という話をsoftya(ソフト屋)さんとISLeさんが言っていなかったのでしたら
その点ではすみませんでした。

ISLe さんが書きました: 引用というのは、引用した内容に言及している部分が質的量的に主で、引用部分が従でなければいけません。
hjklさんがしているのは転載ですから、法的には著作者や出版元の許可が必要ですよ。

Dixq (管理人)さん、私の発言中の他サイトからの引用箇所が
法的またはフォーラムの規約上問題あるばあい当該箇所の削除をしていただきたいです。
削除した場合は削除理由を明確にしていただけるとありがたいです。
またお手数ですが削除対象にならない場合も返信いただけるとありがたいです。

今更という感じなんですが、ラスクさんは最初

ラスクさんが書きました: それとも文字列なんかで記憶しておくのでしょうか（メニュー画面なんかを開いたときに
文字列通りアイテムの名前を並べていく）

と書いているので、おそらく文字列をキーにするという発想ではなく、
セーブデータの内容をそのまま画面へレンダリングするという考えだったのではないかと思います。

そこの部分ですが、

ラスクさんが書きました: そこで質問なのですがＲＰＧにアイテムって付き物ですよね？回復道具や装備品のことです
ああいうのってどんなアイテムを持っているのか一つ一つフラグ変数なんかで記憶しているのですかね
それとも文字列なんかで記憶しておくのでしょうか（メニュー画面なんかを開いたときに
文字列通りアイテムの名前を並べていく）
セーブ機能を付けるときに迷ったもんで素人すぎの質問で申し訳ないのですが
だいたいのＲＰＧはどんな風に作られているのでしょうか？

私は、所持しているアイテムの情報をどうやって内部で保持していて、メニュー表示に使ったり、セーブしたりするのでしょう？って意味に受け取りました。

デスマーチの条件を私なりに考察してみます。
どちらかというとアマの多人数製作・プロの現場的な考察になります。

まず、セーブファイルにアイテム名/魔法名/地名などが含まれる場合は、仕様変更や修正の度にセーブファイルが使えなくなりますので、最終調整中時に多大なムダ（頭からプレイし直し）が発生します。これはデスマーチ仕様だと思います。なので、セーブファイルがデータベースで名前をキーに使う仕様も同様の問題を内包します。
あとデバッグ担当から上がってきたバグ報告を確認するために、データやソースコードのバージョン戻しを掛ける必要が高い確率で出てくるのも問題点です。

次にセーブファイル上はアイテム名/魔法名/地名などは番号管理でプログラム内部に取り込んだ時だけstringあるいは文字列にする場合の考察です。
アイテム名やアイテムのパラメータ情報などは別の担当(ゲームプランナー)から受け取る外部ファイル(csv等)だと思いますので、これを参照して文字列に置き換える必要があります。これは内部的には、アイテム番号順のテーブルが必要だと思います。で、内部で文字列の定数などがあったら担当(ゲームプランナー)の情報を元に定数値を書き換える必要があります。これは無駄に手間のかかる実装だと思います。
次にアイテム情報の検索ですが、所持アイテム名の配列からのアイテム情報を得るための検索はハッシュテーブルかデータベースを使えば簡単ですが、実際の所ロード時にアイテム番号からアイテム名の変換とアイテム情報ハッシュの生成あるいはデータベースの生成など手間が掛かる割には効率化出来ていないと言えると思えます。これなら、アイテム番号からアイテム情報やアイテム名をテーブル参照したほうが簡単です。
これらの手間や複雑性はデスマーチ仕様になるうると思います。

と私なりに考察してみました。思い込みや前提条件の偏りなどがあるかと思いますので精査していただければ幸いです。

hjkl さんが書きました:
文字列で管理する場合、連想配列をつかうと思うんですが操作は一緒ですよね。添字が数値か文字列かというだけで。
c++ならstd::mapとかstd::unordered_map(c++11)を使えばいいのでむりにファミコン時代の手法を使う必要はないと思います。
と言った仕様?に対してどこかデスマーチ確定レベルと断定できる部分はあるのでしょうか?
文字列をキーにしたらデスマーチ確定レベルというのは無理がありませんか?
連想配列といったデータ構造にたいして潜在的なデスマーチ仕様が含まれているのでしょうか。
ISLeさんの最初の投稿で仕様変更への耐性について語られていますが文字列をキーにすると
外部データの仕様や他のコンポーネントとの連携の仕様が一様に決まるのでしょうか。
私がミスリードだと言っているのはこの点です。

他の回答者で無くて申し訳ありませんが、わたしがいつ「文字列をキーにしたらデスマーチ確定レベル」と書いたのでしょうか？
「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。」とは書きました。

「キーにする」の主語は『(名前なんて)変わりやすいもの』ですよね。
『文字列』がダメと書いてないどころか『文字列』という単語すら出てないですよね。

こういうのってなんて言うんでしたっけ。
#ご本人が自覚しているくらい言われましたからお返ししても良いですよね。

いつ気付いてくださるかと思ってましたけど諦めました。

#後半の実装の話に"文字列"という単語が混じっているのは申し訳ないです。
#ですがきっかけはそこではないので。

h2so5 さんが書きました: と書いているので、おそらく文字列をキーにするという発想ではなく、
セーブデータの内容をそのまま画面へレンダリングするという考えだったのではないかと思います。

そうですね、このトピックで回答するなら解釈のズレがある場合は確認しあったほうがいいのかもしれませんね。
そこの部分ですが、

softya (ソフト屋) さんが書きました: 私は、所持しているアイテムの情報をどうやって内部で保持していて、メニュー表示に使ったり、セーブしたりするのでしょう？って意味に受け取りました。

私は上記のsoftya (ソフト屋)さんと同じ意見です。

以下の私の過去の発言がsoftya (ソフト屋)さんの意見と相反するのなら別ですが。

hjkl さんが書きました: 自分の読解力がたらないだけかもしれませんがラスクさんの質問は
アイテム管理の内部的な実装方法,又はアイテム保存時のセーブファイルの仕様
またはそれらの複合が考えられました。

私がラスクさんの質問のなかに文字列をキーにする発想が含まれていると解釈、又はそれを推奨していると思っている人がいた時のためにいいますが
私がラスクさんに文字列をキーにすることを推奨したのなら話は別ですがSQLiteやC言語より高級な言語や既存のライブラリを活用すること
しか推奨していませんし、アイテム管理に関わる処理に連想配列や構造体配列等を使った仕様ないし実装について想像し語ったこと等しかありません。
どこかラスクさんに文字列をキーにする発想があると解釈している、ラスクさんに文字列をキーにすることを推奨している発言がありましたらご指摘いただけるとさいわいです。

softya (ソフト屋) さんが書きました: と私なりに考察してみました。思い込みや前提条件の偏りなどがあるかと思いますので精査していただければ幸いです。

素晴らしい考察だと思います。
softya (ソフト屋)さんが二つの考えられうる仕様にたいして考察されていることからわかるとおり
仕様が一様に決定されることなどありえないことがsoftya (ソフト屋)さん自身お分かりいただけたと思います。
softya (ソフト屋)さんが考察したような仕様を私が明らかにした上でISLeさんがデスマーチ仕様かどうか主張されたのなら
私も妥当な主張だと受けとります。しかし私がなにかそのような仕様を表明したと
Dixq (管理人)さんやsoftya (ソフト屋)さんやISLeさんやh2so5さんや他の回答者さんはお考えなんでしょうか?

ISLe さんが書きました: 他の回答者で無くて申し訳ありませんが、わたしがいつ「文字列をキーにしたらデスマーチ確定レベル」と書いたのでしょうか？
「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。」とは書きました。

このトピック内のName: ISLe [URL] 熟練のプログラマー(68,456 ポイント) Date: 2011年8月23日(火) 02:50 No: 19
という投稿で

ISLe さんが書きました: もちろんいまだ改善が続く途中ですが、文字列をキーにしたらデスマーチ確定レベルなのは明らかと経験が言ってます。

と言っているのでそちらの言葉を使いましたがこの投稿箇所がきっかけではないので無効ということですね。
では「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。」
という言葉を今後はつかわせてもらいます。

では前の投稿の質問を取り消し「文字列をキーにしたらデスマーチ確定レベル」という言葉にかわって
「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。」
という言葉をつかって再度質問させていただきます。

hjkl さんが書きました: 文字列で管理する場合、連想配列をつかうと思うんですが操作は一緒ですよね。添字が数値か文字列かというだけで。
c++ならstd::mapとかstd::unordered_map(c++11)を使えばいいのでむりにファミコン時代の手法を使う必要はないと思います。

と言った発言に対してどこか
「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。」
と断定できる部分はあるのでしょうか?
名前という変わりやすいものをキーにする連想配列といったデータ構造にたいして潜在的な自殺行為、デスマーチ仕様が含まれているのでしょうか?
この発言かこの発言をした私の2番目の投稿で
「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。」
と主張されるのに妥当な仕様を表明していたのでしょうか?

この質問に関してはご自身で考案された仕様をデスマーチ仕様か考察されたり
ゲーム業界歴の長さを考慮したりせずに(発言がゲーム業界歴やベテランプログラマーといったことから独立させて考えるとこが不可能でしたらそれらを考慮してもらっても構いません)
「断定できる」や「断定できない」「仕様を表明していた」「仕様を表明していない」等の
なるべくわかりやすい回答をしてもらえるとありがたいです。断定的でなくても構いません。
しかし回答していただけたなら、なぜそのように判断をされたかの理由も書いてもらえらばありがたいです。

Dixq (管理人)さんやsoftya (ソフト屋)さんやISLeさんやh2so5さんや他の回答者さん
単純な質問だと思います。勇気をもってどうか回答してください。おねがいします。
得にDixq (管理人)さんの判断を仰ぎたいです。

素朴な疑問ですが、hjklさんは

hjkl さんが書きました:私がラスクさんの質問のなかに文字列をキーにする発想が含まれていると解釈、又はそれを推奨していると思っている人がいた時のためにいいますが
私がラスクさんに文字列をキーにすることを推奨したのなら話は別ですがSQLiteやC言語より高級な言語や既存のライブラリを活用すること
しか推奨していませんし、アイテム管理に関わる処理に連想配列や構造体配列等を使った仕様ないし実装について想像し語ったこと等しかありません。
どこかラスクさんに文字列をキーにする発想があると解釈している、ラスクさんに文字列をキーにすることを推奨している発言がありましたらご指摘いただけるとさいわいです。

hjklさん自身がSQLiteやC言語より高級な言語や既存のライブラリを活用すること（std::mapとかstd::unordered_mapなどを言及されていたと思います）を書かれていますが、これは何のキーやデータを格納することを想定して書かれていたのでしょうか？ラスクさんが言及されているアイテムの扱いについてですね。

「所持しているアイテムの情報をどうやって内部で保持していて、メニュー表示に使ったり、セーブしたりするのでしょう？って意味に受け取りました」で「私は上記のsoftya (ソフト屋)さんと同じ意見です。」と書かれているので、どういう使い方を想定していて最初に書かれたのか内部保持とセーブに分けて説明していただけると助かります。

[補記]途中までの書き込みで私が思ったのは、hjklさんは内部保持のキーやセーブデータにアイテム名等の文字列を使うと想定されているんだなってことです。それに基づいた推察で返事を書いております。
それに付いてはhjklさん自身がNo: 14で「セーブファイルの仕様についてはアイテム名かアイテム番号で管理するのがシンプルでいいとおもいます。」と書かれておられますのでセーブファイルにアイテム名を使うことを想定したというのは誤解ではないですよね？であれば私の考察においてはデスマーチ仕様だとは思います。

hjkl さんが書きました:
文字列で管理する場合、連想配列をつかうと思うんですが操作は一緒ですよね。添字が数値か文字列かというだけで。
c++ならstd::mapとかstd::unordered_map(c++11)を使えばいいのでむりにファミコン時代の手法を使う必要はないと思います。
と言った発言に対してどこか
「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。」
と断定できる部分はあるのでしょうか?
名前という変わりやすいものをキーにする連想配列といったデータ構造にたいして潜在的な自殺行為、デスマーチ仕様が含まれているのでしょうか?
この発言かこの発言をした私の2番目の投稿で
「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。」
と主張されるのに妥当な仕様を表明していたのでしょうか?

hjklさんの投稿が関係ないと言うなら、わたしのデスマーチ発言は自動的に最初の質問に書かれている

ラスクさんが書きました:それとも文字列なんかで記憶しておくのでしょうか（メニュー画面なんかを開いたときに
文字列通りアイテムの名前を並べていく）

を指していることになるだけじゃないですか。

だいたいわたしの投稿はsoftyaさんの、

softya（ソフト屋) さんが書きました: と言うことで、終了ど間際で絶対アイテム名を変更しないならアイテム名でセーブしても良いと思いますが、変更する可能性があるならアイテム名は避けたほうが良いと思います。

を受けて書いたものです。
『終了ど間際で』変更したらデスマーチ確定ですよね。違いますか？

いま気付いたんですが、もしかして「高級な言語とか既存のライブラリを活用」というフレーズを流用したことを怒っているんですか？

> Dixq (管理人)さん、私の発言中の他サイトからの引用箇所が
> 法的またはフォーラムの規約上問題あるばあい当該箇所の削除をしていただきたいです。
> 削除した場合は削除理由を明確にしていただけるとありがたいです。
> またお手数ですが削除対象にならない場合も返信いただけるとありがたいです。

今までよほどのことが無い限り投稿文を削除したことはありません。
特定のサイトから丸ごとコピーしてくると著作権的に問題あるかもしれませんが、今回は著作権保有者から削除依頼が来ない限りはそのままにさせていただこうと思います。

> Dixq (管理人)さんやsoftya (ソフト屋)さんやISLeさんやh2so5さんや他の回答者さん
> 単純な質問だと思います。勇気をもってどうか回答してください。おねがいします。
> 得にDixq (管理人)さんの判断を仰ぎたいです。

特定の人と同じ意見になると、中立的な立場ではないことになりそうなので、申し訳ないですが今回は他の方にお任せします。

自分で建てたトピックがすごいことになっていました；
議論の中、空気読めないかもしれませんがお礼だけ入っておかなければと思い、書き込んでいます
教えてくださった　皆様、ありがとうございました

何について話しているのかは初心者なので分かりませんが短めの文だけ読んだので返信しときます

Dixq (管理人) さんが書きました:セーブデータの内容をそのまま画面へレンダリングするという考えだったのではないかと

はい、このような考え方です　Dxprintfでしたっけ？なんか文字を書く関数でそのまんま
画面にぺたぺた貼っていくような感覚の処理にしようとしてました
まぁ、今更感がありますし、だからどうしたってことですよね

議論の中、初心者が書き込みすいませんでした
解決ボタン押していいのか分からないのでとりあえず放っておきます　ごめんなさい

> ラスクさん

いえいえ、ラスクさんのトピックなので、ラスクさんが一番自由に発言なさって下さい。
もし、討論が原因で、質問者さんが発言しにくくなっている現状があるとすると、利用規約を見直さなければなりません。
ここでは初心者もベテランも気兼ねなく話が出来る場を目指しています。気軽にお話下さい。

> Dxprintfでしたっけ？

printfDxじゃないですかね。
printfDxはデバッグ用関数なので、もしゲームに使用するなら、
DrawString系の関数をお使いください。
http://homepage2.nifty.com/natupaji/DxL ... html#R17N1

また、フォントを使用しないデフォルトの描画だとやすっぽい文字列になりますので、
CreateFontToHandleでフォントを作って利用する方法がのぞましいでしょう。

ラスクさん、お気になさらずに。
分からないことがあれば気軽に質問してくださいね。

私の提案の方法だと

所持アイテム配列（アイテム番号を格納。このままセーブ対象)
　↓
アイテム情報構造体配列[アイテム番号].アイテム名

でアイテム名を取得できます。

Ｃ言語で書くと

コード:

#define ITEM_BAG_MAX 10
//	アイテム所持袋
int ItemBag[ITEM_BAG_MAX];


//	アイテム情報構造体
typedef strcut {
	char *itemName;//名前
	int money;     //価格
	//	効果のタイプや属性などなどパラメータ続きます。
} ItemTable_t;

//	アイテム情報テーブル。直接初期値を入れた場合。
ItemTable_t ItemTeble[] = {
	{ "ポーション", 100 },
	{ "エリクサー", 1000 },
};

//	アイテムenum
enum {
	ITEM_EMPTY = -1,	//持っていない状態。
	ITEM_HEAL1,			//回復アイテム1
	ITEM_HEAL2,			//回復アイテム2
};

//	ここから初期化

	//	初期化
	for( int i=0 ; i<ITEM_BAG_MAX ; i++ ) {
		ItemBag[i] = ITEM_EMPTY;
	}

//	ここから処理例

	//	アイテムを得る。
	int itemno = ITEM_HEAL1;
	for( int i=0 ; i<ITEM_BAG_MAX ; i++ ) {
		if( ItemBag[i] == ITEM_EMPTY ) {
			ItemBag[i] = itemno;
		}
	}

	//	アイテムを表示する。
	int drawy = 16;//スタートＹ座標
	for( int i=0 ; i<ITEM_BAG_MAX ; i++ ) {
		int itemno = DrawItemBag[i];
		if( itemno != ITEM_EMPTY ) {
			DrawFormatString(100,drawy,"%s",ItemTeble[itemno].itemName);
			drawy+=16; //一行分だけしたにずらす。 
		}
	}

って感じです。動作確認してないのでエラーが出たらごめんなさい。
[追記]バグ修正。
[追記の追記]アイテム使用時に間が開いてしまうので表示時に間を詰めるように修正。

hjklさん、softyaさん、ISLeさんでもめているようですね。
長く続いていてよくわかりにくいのですが
3人の書き込みはこんな印象を受けました。

hjklさん
セーブデータにアイテム名を書いたっていいじゃありませんか。
そりゃsoftyaさんとかISLeさんみたいに
プログラムに長く関わったというわけじゃありませんが。
だからって頭ごなしに否定するのはやめてほしい。
連想配列なんて言葉を使ったのは
高級な言語や文法、ライブラリとかそういうのを使いこなすのに憧れているからだし。

softyaさん
通し番号で管理するのが一般的でよい方法だと考えております。
番号が変わるかもしれないのなら内部値をenumで管理します。
まあ、名前を変更しないならアイテム名を記録するという方法でもいいんじゃないでしょうか。
しかし、おすすめはできません。万が一変えるとなったら面倒です。

ISLeさん
アイテム名を記録？ダメダメ、そんなのはほとんど変更されるんですから。
もし、完成直前で変更したらものすごく苦労するかもしれないんですよ。
そんなの私だったら絶対に嫌ですね。だからダメです。
アイテム名を記録するのを認めるような発言も不快です。

「通し番号で管理するのはよい方法である」という点では一致しているようです。
もめているのは「アイテム名をセーブデータに書き込むことは許されるか」のようです。

私自身は
「通し番号での管理が一般的で、アイテム名はセーブデータに書き込むべきではない
というのならその通りにするのがよいでしょう。
完全に個人でつくるならともかく、他の人の協力を得るつもりなら
より一般的な方法を使っているほうがやりやすくなるはずです。」
と考えています。

とりあえず、ラスクさんの書き込みを見る限り、
今回のラスクさんの質問は「解決」、
と思いましたが「実は、番号で管理するといってもどうすればよいか
まだよくわかっていません」とかありませんか？
あるのでしたら、書き込んだほうがよいでしょう。
しかし、私はRPGをつくっていないのでおそらく助けにはなれません。

それはそれとして、なんとなく気になったのですがラスクさんは
所持アイテムをどういう感じに表示されるつもりなのでしょうか？
例として、以下のようなものが思いつきました。

例A.アイテム個数を並べて表示
ひのきのぼう
なべのふた
かわのぼうし
やくそう 2
どくけしそう 3

例B.アイテムを一個一個表示。常にソートされた状態。
ひのきのぼう
なべのふた
かわのぼうし
やくそう
やくそう
どくけしそう
どくけしそう
どくけしそう

例C.アイテムを一個一個表示。特定の操作を行わなければソートしない。
ひのきのぼう
やくそう
なべのふた
どくけしそう
かわのぼうし
やくそう
どくけしそう
どくけしそう

それぞれに対応した画像を表示するという手もありますね。

Tatu さんが書きました:hjklさん
セーブデータにアイテム名を書いたっていいじゃありませんか。

ISLeさん
アイテム名を記録するのを認めるような発言も不快です。

hjklさんがなぜ怒っているのか分からなかったんですけど、わたしがhjklさんの投稿に対して意見したことになってるんですね。

どうしてなんでしょう。

hjklさんが、連想配列で文字列を管理する云々のところは正直何を言っているのか分かりません。
技術的なことではなく、何のために何をどうしようとしているのか読み取れないからです。
#RPGなのでフレーム関係ないってなんすかね。

なので、わたしは、hjklさんがセーブデータにアイテム名を使うと主張しているとは受け取っていません。
というかそこに関してはスルーです。
前にも「hjklさんの実装に対して何かを決め付けたりはしていません」と書いてます。

思い当たるとすれば「高級な言語とか既存のライブラリを活用」というフレーズを流用したことですが。

高級な言語とか既存のライブラリを活用してもデスマーチ仕様がある限りデスマーチは生まれ続けます。

楽で便利な開発手法でもデスマーチは避けられないって意味ですけどね。
楽で便利な開発手法がデスマーチを生む、というふうには読めないと思うのですけど。
デスマーチでメリットも帳消しになってしまうわけで。

hjklさんのSQLiteの提案もリンク先のページには「多分実際のゲームでは」なんて書いてあるので実績のない話だと分かるんですが、ここは突っ込んじゃダメだと思ってスルーしたんですよ。

わたしのデスマーチ発言は、ラスクさん、h2so5さん、softyaさんの、アイテム名を使う・使わない云々が明記されている投稿の流れを受けて書いたものです。
デスマーチ発言前のhjklさんの投稿は、すべてスルーしてるんです。
そのはずだったんですが、ついhjklさんの投稿からフレーズを流用してしまった。

あれ？おかしいです。
それでもやっぱり、どうしてhjklさんの投稿を否定したことになるのか分かりません。

#なんかほんと質問と関係なくなってしまってすみません。

>>ISLeさん

No:33[74145]で
わたし(ISLeさん)がhjklさんの投稿に対して意見したことになっているんですね。
どうしてなんでしょう。

と書かれていますがこれは私(Tatu)に対しての言葉ですね？
では、どこを見てそう感じたかというと

No:27[74125]の
(hjklさんのhjklさんがNo:7[73955]で示した名前をキーにするやり方のどこに
デスマーチ仕様と断定できる要素があるんですかという内容に対し)
hjklさんの投稿が関係ないと言うなら、わたしのデスマーチ発言は自動的に最初の質問に書かれている
(ラスクさんの最初の文から引用)
を指していることになるだけじゃないですか。

という文からhjklさんの投稿に意見していたのだと思いました。
それに、デスマーチ発言がhjklさんかラスクさんのどちらに対するものだったとしても、
「文字列(名前)を記録(キーにする)」というやり方はよくないということになります。

ついでにデスマーチ発言に関連している内容として
No:24[74111]に

他の回答者で無くて申し訳ありませんが、わたしがいつ「文字列をキーにしたらデスマーチ確定レベル」と書いたのでしょうか？
「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。」とは書きました。

とありますがこれについてはNo:19[74071]で

RPGやRPGに近いジャンルのタイトルを手掛けたのは数えられるほどですが、
チーム開発では別のスタッフが作成した外部データを読み込んで使うことはふつうにありますから、
小規模ながら数百タイトルの経験値があります。
もちろんいまだ改善が続く途中ですが、文字列をキーにしたらデスマーチ確定レベルなのは明らかと経験が言ってます。

と書いておられます。

>フレーズの流用
「高級な言語とか既存のライブラリを活用」というフレーズを流用したから
hjklさんは怒っていると書いていますがそんなよくあるフレーズを流用したからって怒るとは思えません。
「高級な言語とか既存のライブラリとか無意味」って書いてあるわけではありませんし。
それよりは「何で私(hjklさん)の名前をキーにするやり方がデスマーチ仕様なんですか。
言いすぎです。いろんなやり方があっていいじゃないですか。説明してください。」という感じだと思いますね。

デスマーチだと思うかの説明についてはsoftyaさんのNo.23[74105]で十分だと思います。
hjklさんも「素晴らしい考察だ」と評しており、納得しているようです。
だいたい

セーブデータに文字列を入れると
バージョンアップのたびにセーブデータが使えなくなるのでデスマーチ。
プログラム内部のみで文字列をつかうにしても文字列が変わるたびに
プログラムをいじらなければならないのでデスマーチ。
やっぱりアイテム番号からアイテム情報やアイテム名をテーブル参照するのが簡単。

という内容のようですね。

管理人さん達へ
このレスを書いていて思ったのですが、引用時に記事番号(可能ならリンクや引用前に最後に編集された時刻も)が
つくようにできませんか？どのへんでの意見だったか、
引用された本人がどういう文脈で書いていたのかが確認しやすくなると思います。

hjklさん以外の方がそう書かれたので、わたしがhjklさんに対してデスマーチ発言したとするのが当然の雰囲気になっているのかと思ったんですよね。
前にも書きましたけど、わたしが実装の話をしたのはhjklさんに絡まれたあとのことですし、デスマーチ発言に文字列という単語は一回も使われてません。
hjklさんがデスマーチ発言で怒る理由にはならないですよね。

hjklさんへの拒否反応から脊髄反射的に、softyaさんに被せて前提の話したり、実装の話を持ちだしたりしたのが完全に裏目に出た形ですね。
もちろんあの時点でもhjklさんが何で絡んでくるのか分かってなかったので、前提の話で無関係を表明したつもりが、実装の話で自分から接近してしまったわけですね。
冷静でなかったことは反省しています。

(追記)
「デスマーチ発言の対象は自動的に最初の質問」は、hjklさんに真っ向から勝手な思い込みですよと言ったら余計に怒らせると思って考えた末の表現です。
自分で読み直しても分かりにくいと思います。すみません。

No: 26

softya (ソフト屋) さんが書きました: それに付いてはhjklさん自身がNo: 14で「セーブファイルの仕様についてはアイテム名かアイテム番号で管理するのがシンプルでいいとおもいます。」と書かれておられますのでセーブファイルにアイテム名を使うことを想定したというのは誤解ではないですよね？であれば私の考察においてはデスマーチ仕様だとは思います。

すみません。私の言葉がまちがっていました
セーブファイルの仕様について
アイテム名かアイテム番号で管理するのがシンプルでいいと言いましたが
アイテムを数値か文字列で管理する(保存)といった方が適当でした。
これがセーブファイルの仕様について誤解をまねいていたのだとおもいます。

おそらくsoftya (ソフト屋)さんはこのアイテム名というのが変更されやすいもので
アイテム番号が変更されずらいものとしていると思います。

構造体の方に付与させるアイテムの名前を保存していると推測されていたのでしょう。
もちろんそのように推測されたとしても妥当だと思います。

それに私はたとえキーを文字列で保存するのも構造体の方に付与させるアイテム名を文字列で保存しても
受け入れがたい仕様ではないのでチート仕様を例えでだしました。
ただこの例えではどちらかとうと構造体の方に付与させるアイテム名を保存する印象を強くさせてしまった
のものと思います。最初から正確に書くべきでした。

キーを文字列で保存するというのはキーがアイテム番号だったとしてそれを1と保存しようが"1"と保存しようが
それらを暗号化したものでも
どれかが受け入れがたかったりそれのみによってデスマーチ仕様だとは思わないということです。
まぁどちらにせよsoftya (ソフト屋)さんからすればデスマーチ仕様が含まれていますね。

私は基本的にデスマーチ仕様というものは存在せず、製作者同士のコミュニケーションが円滑に行われて入れば
仕様が悪いまま製作が開始または進行しつづけるという事はおきないと考えています。
仕様や製作者同士の連携が著しく悪く、開発が遅延しつづけるという事がデスマーチだと考えています。

私の方では
「名前なんて変わりやすいものをキーにするなんて自殺行為ですね。(略)デスマーチ仕様です。」
の発言以降、
文字列をキーにしたときに考えられる連想配列を使った実装について(名前なんて変わりやすいものをキーにするといっている以上セーブファイルの仕様ではなく内部的な実装のはずですから)
自殺行為やデスマーチ仕様なのかどうかを重視して発言していたのとその連想配列の実装はセーブファイルの仕様と
分離して考えることが可能なのでセーブファイルの仕様について正確性を欠いた発言をしました。

しかし、
No: 14

hjkl さんが書きました: そのセーブについてもstd::stringの配列でアイテムを管理していようと
セーブファイル上では数値や暗号化された文字列等で分離しても問題ないとおもうんです。

この発言でセーブファイルの仕様と内部の構造は分離して問題ないだろうと言ったつもりなので
そのような前提で発言しているとご理解いただけたかと思っていました。分離できないのでしょうか。
未だにセーブファイルについて質問されるのでこの辺にもお互い誤解があるのかもしれませんね。

さらに私の方で、
No: 16

hjkl さんが書きました: と言われたのでenumはstringに、構造体配列を連想配列に置き換えても目的の動作を可能にできるということを
ご理解なさっておられないと思い、私の方も擬似コードをまじえて説明致しました。

と発言したのはenumのENCHANT_FIREという名前のキーがstringの"ENCHANT_FIRE"とう名前のキーであっても問題はないだろうという
趣旨でしたがもっとわかりやすく書くべきでしたね。
あと擬似コードの方でもSWORD_1で比較するのに対して"SWORD_1"とするべきでしたね。

softya (ソフト屋)さんのNo: 31の投稿で実際にコードを書かれたのでお聞きしたいのですが
もし、あるアイテムが所持アイテムのテーブルに存在するかどうか確認する場合どのような処理に
なるのでしょうか。

そんなことはRPGでは一般的な処理でないので考えたくないということでしたら結構ですし、
ラスクさんの質問の意図と違うことを考えたくないという場合でもお答えいただけなくても結構です。
またセーブファイルの仕様について明示していない質問には答えられないということでしたらその場合も結構です。

もしforループでテーブルをenumで定義された名前をキーにして比較する処理の場合
線形時間かかるものかと思いますが所持アイテムの総数が大きくなるにつれて連想配列の方が
速度的に有利に働く場合もかんがえられませんか?
構造体配列と連想配列のどちらが優位かとうことではありませんのでお気を悪くなさらないでください。このような場合も考えられませんかとうことです。
他のフラグ変数等で管理する場合は連想配列だろうとなんだろうと関係ありませんが
とりあえず私の方でこのような推察をしてみました。

私はアルゴリズムの実行時間について詳しいわけではないので間違っているかもしれません。

ISLe さんが書きました: #RPGなのでフレーム関係ないってなんなんすかね

よくわからないのですが、RPGなのでフレーム関係ないと誰か発言しているのでしょうか。
コメントアウトされているのでわかりずらいのですが独り言か管理人さんや副管理人さんに対して発言されているのでしょうか。

おそらく私がNo: 7の投稿で、

hjkl さんが書きました: 環境が明示されていないので何とも言えませんが正規表現ぐらいなんともないコストだと思うんですけどね。
RPGなのでアクションゲームのように1フレーム内に処理する必要もありませんし。

と意見したことに触れているのだと思いますが(それ以外にフレームという言葉が使用された箇所はありませんから)
アクションゲームのような速度が求められやすいゲームに対して相対的に重い実装をしても
RPGでは問題にならないケースが多いだろうという意図での発言だったんですが
softya (ソフト屋)さんも「RPGなのでフレーム関係ない」と受け取られたでしょうか?
文字列の検索 = 正規表現と決めつけてしまったことに関しては申し訳ありません。

No: 33

ISLe さんが書きました: hjklさんがなぜ怒っているのか分からなかったんですけど、わたしがhjklさんの投稿に対して意見したことになってるんですね。

No: 33

ISLe さんが書きました: わたしのデスマーチ発言は、ラスクさん、h2so5さん、softyaさんの、アイテム名を使う・使わない云々が明記されている投稿の流れを受けて書いたものです。
デスマーチ発言前のhjklさんの投稿は、すべてスルーしてるんです。
そのはずだったんですが、ついhjklさんの投稿からフレーズを流用してしまった。

あれ？おかしいです。
それでもやっぱり、どうしてhjklさんの投稿を否定したことになるのか分かりません。

私に対する意見ではないとおもいますが
怒っていませんし、否定されたとも認識していませんのでご安心ください。

トピック内で行われた発言で、なおかつ自分の発言と関係のある話題について反応するのは自然だと思うのですが
このフォーラムでは推奨されない行いだと思われますので管理人様方、ぜひフォーラムルールに御記載いただきたいです。
これについては多くの利用者にとって重要な問題だとおもわれます。
ゲストユーザーの私にはわからない問題ですのでぜひ中立、非中立関係なくDixq (管理人)さんやsoftya(ソフト屋)さんの意見をお聞きしたいです。

No: 28

Dixq (管理人) さんが書きました: 特定の人と同じ意見になると、中立的な立場ではないことになりそうなので、申し訳ないですが今回は他の方にお任せします。

まだ質問に回答いただくための条件に不備があったでしょうか。
「この回答によって中立か非中立か決定されることはありません。どうぞ気楽に回答してください。」とでも付与しなければなりませんでしたか。
私の配慮がたりませんでした。
あの質問(ある仕様がデスマーチ仕様と断定できるかできないか等)はこのトピックの一連の投稿上、コミュニティの不和を誘発する可能性があるので取り消させていただきます。

排他的でないか非中立でないかといったことを
有志のユーザーによって管理、運営されているフォーラムに意見したことに関してはお詫びします。
人格攻撃があったのでないかという意見も自分の被害妄想ですので
どなたも自分の発言がそうだったのではないかという心配をされなくて結構です。

そこでDixq (管理人)さんに質問なんですが、いくら自由なやりとりができる場とはいえ
根拠が乏しいのに少し過激な表現(例えば自殺行為、デスマーチ仕様、たとえばです)を使い断定的に発言することや
特定のユーザーを揶揄しているともとれる発言を複数人で行うといった事が確認できた場合
どのような対応をとられるのでしょうか?

このフォーラム内でそのような発言があるとは申していません。

特定のユーザーを揶揄しているともとれる発言というのは例えば、(このトピックに偶然そのような発言が含まれてたとしても私はそれを引用しているわけではありません。あくまで例え話です)
「なにかゲームプランナーのような人がいたとして終盤まで名称にこだわったりするから"うかつ"に名前なんか固定できねーなぁ、
あいつらコードネームとかつけんのすきだもんなー、カッコイイとおもってるんかなー」なんて言いつつ
その後、追記で質問をしますが
先の発言が特定のだれかを直接的に揶揄していない風にみせるため独り言のような記述をすることです。例えばの話です。

こんな事をする人はこのフォーラムに誰ひとりいません。ご安心ください。
そもそも揶揄というのは性質上これがそうだと断定できるものではありませんしね(断定できないようにするもの)。
これがそもそも揶揄なんじゃないかって?そんなこと断定できませんよ(自分からこれは揶揄だと言わない限り)。

私はあげあしをとられないように、論点をズラされないように、記述の統合性を保てるように、
と細心の注意をはらって書く労力にこれ以上耐えられません(勝手にやっていることですので心配なさらずに)。
どうか勇気をだして回答してくださるとさいわいです。

せっかく質問に答えてわたしが書いた実装は無視かいな。

いやいや独り言ですよ。

実績も根拠も要らないなら、
ブラジルのツレに電話して内容とアドレスを指定して送って貰った携帯メールをセーブデータにする
っていう実装もアリですよねぇ。

えーとですね。hjkl さんの内容が長すぎて内容が把握できているか自身自信が無いですが分かっている限り書いてみます。
まず、Tatuさんが書かれている第三者の目でみてもアイテム名をセーブファイルに使うと思われてもしかたのない書き方をされていたって事ではよろしいのですね？
で、

hjkl さんが書きました:私は基本的にデスマーチ仕様というものは存在せず、製作者同士のコミュニケーションが円滑に行われて入れば
仕様が悪いまま製作が開始または進行しつづけるという事はおきないと考えています。
仕様や製作者同士の連携が著しく悪く、開発が遅延しつづけるという事がデスマーチだと考えています。

に関しては人間同士のやり取りですので、どんなに円滑にやり取りしているつもりでも誤解やミスは生じます。これは避けれません。
なので誤解やミスをしても被害は最小限に留めたいので誤読や打ち間違い率の長い文字列が重要なデータに混入するのを避けるに越したことは無いと思うのです。あるいは打ち間違いされても最小限の被害で抑えられる仕様を選択すべきだと思います。

あとは、No: 23に書きましたとおりアイテム識別文字列の"ENCHANT_FIRE"であろうと"SWORD_1"であろうとセーブファイルに文字列を書きだす手間とか、読み込む手間を掛けるほどのメリットを感じませんので準デスマーチ仕様だと私は思います。

hjkl さんが書きました: softya (ソフト屋)さんのNo: 31の投稿で実際にコードを書かれたのでお聞きしたいのですが
もし、あるアイテムが所持アイテムのテーブルに存在するかどうか確認する場合どのような処理に
なるのでしょうか。

単に所持アイテム配列をforループで回して該当するアイテム番号の物を探すことになると思います。
で

hjkl さんが書きました: もしforループでテーブルをenumで定義された名前をキーにして比較する処理の場合
線形時間かかるものかと思いますが所持アイテムの総数が大きくなるにつれて連想配列の方が
速度的に有利に働く場合もかんがえられませんか?
構造体配列と連想配列のどちらが優位かとうことではありませんのでお気を悪くなさらないでください。このような場合も考えられませんかとうことです。
他のフラグ変数等で管理する場合は連想配列だろうとなんだろうと関係ありませんが
とりあえず私の方でこのような推察をしてみました。

具体的にその連想配列は何がキーになっているのでしょうか？
アイテム名をキーにした場合は要素がアイテム個数って仮定しますが、その場合はアイテム所持袋のアイテムの並びなどの仕様自体が内部構造のため制限を受けるこちになりますよね。
ドラクエのように少なくともアイテム入手順には並べられません。なので、比較できないとしか言えません。
無理やり比較するなら、何百個も所持していたら少々差があるかもしれませんがhjklさんも言われた通りリアルタイム性の無いＲＰＧで気にするほど時間差があるとも思えませんので、連想配列に頼る価値があるのか分かりません。それと時間を気にするならアイテム消費時の削除時の時間コストも気になるところです（たしか無茶苦茶遅かったはず）。ソートに関しては連想配列の場合は逆にアイテム名がキーなら強さ順ソートなどの場合メリットにならないはずです。
どうしても比較したい場合は、とりあえずコードを書いて頂けますか？
こちらが誤解を招く可能性があるのは、これまでのやり取りでご理解いただけたと思いますので、その上で比較したいと思います。

[追記]
便利と言う意味では、Sqliteでメモリ内に展開したデータベースでアイテム所持袋やアイテム情報を内部構造として持つほうが有意義です。ソートが楽ですからね。
ただ、この方法は不用意なメモリ破壊バグの時に破壊されたメモリ内容の解析が難しくなり原因を追求し辛くなるので土壇場のデスマーチ率が高くなると私は思っています。
不可解なバグは、最後にまとめて来ますからね。

> そこでDixq (管理人)さんに質問なんですが、いくら自由なやりとりができる場とはいえ
> 根拠が乏しいのに少し過激な表現(例えば自殺行為、デスマーチ仕様、たとえばです)を使い断定的に発言することや
> 特定のユーザーを揶揄しているともとれる発言を複数人で行うといった事が確認できた場合どのような対応をとられるのでしょうか?

上でも述べた通り、プログラマーの性格とでも言いますか、自分の技術を信じるがゆえに断定的な言い方になるのはよく見かけます。
また、重複しますが、不適切な仕様を酷く罵る言動も良く見かけます(「ライブラリの仕様がカス過ぎて使えない」など)
私ならそれはそういうものだと思って対応するかと思います。特に言動が荒かったからと言って過剰に反応しようとは思いません。
褒め言葉から得ることより、批判から得ることの方が数段多いです。
(例えば「公開されているゲーム面白かったです」と言われることから得ることと、「低スペックPCだと全然遊べなくてクソゲーだった」と言われることから得ることはどちらが多いでしょう)
なかなか丁寧な言葉で指摘してくれる親切な人はいません。罵倒されてでも、批判から自分に得る物を私なら探します。

・・ということで、批判は貴重な情報源であり、その際の多少の荒い言動は致し方ないものとし、
よほどの酷い罵倒、明らかな個人攻撃であると判断出来る事が無い限り、特別な対応はしません。

集団で特定ユーザーを攻撃するような言動があったらどうするかということについてですが、
本掲示板にはコミュニティになる以前から数えたら相当な数の投稿数がありますが、
常連の回答者さんは皆良い方ばかりなので、特定ユーザーを非難したり非常識な言動をされる方はいらっしゃいませんでした。
言い争いになったことは稀にありましたが、明らかに質問者が不適切な言動をしている場合がほとんどでした。

従ってよほど「悪質」だと判断出来るやり取りが無い限り対応はしないつもりです。どれ位が悪質かという基準は特に明記していません。

ここのフォーラムを管理している技術管理人の御津凪(みつなぎ)と申します。

これはこのトピックの質問・議論に対しての返答ではありませんのでご了承ください。（念のため書いておきます）
フォーラムの技術的な話題です。
（なお、これは他の管理人さん方と相談して決めたわけではなく、独自で決めた、個人的な発言です）

オフトピック

Tatu さんが書きました:管理人さん達へ
このレスを書いていて思ったのですが、引用時に記事番号(可能ならリンクや引用前に最後に編集された時刻も)が
つくようにできませんか？どのへんでの意見だったか、
引用された本人がどういう文脈で書いていたのかが確認しやすくなると思います。

こちらにつきましては、技術的に拡張可能だと思いますので実装を前提に検討させていただきます。

実は、このフォーラムにはオフトピック（本題とは関係の無い文章。独り言や本題とは別の話題など）という表現が搭載されています。（上の囲いのことです）

構文はこちら: [offtopic]テキスト[/offtopic]

これはフォーラム当初から機能としてはあったのですが、使用方法（特に初めて使う方）の混乱を招くのではないかという考えから
今まで管理人専用（副含む）として一般には表示を隠していました。

今回、このトピックの内容を読ませていただき、本題に外れた発言（オフトピック）が多く見受けられ、またそれにより本来必要のない議論が発生していると感じましたので、
このタグ(BBコード)の使用の明確化をゲストユーザーまで解放いたします。（オレンジ色のバルーンに「“”」と書かれているアイコンです）

これにより、より明確な発言が出来るかと思います。
（勿論、使用してくれる方がいないと意味がありませんが）

とりあえず、「オフトピックテキスト」では分かり辛いので、後で分かりやすい名前に変更しますね。（"独り言"とした方が意味的には扱いやすいかな？）
あと、調整してなくてテキストがかなり見辛いのでこれも直しておきます。

追記：
名前と文字色を変更しました。

プログラマ専用SNS ミクプラ

ＲＰＧのアイテムの記憶とか

ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか

Re: ＲＰＧのアイテムの記憶とか