パスワードを忘れた? アカウント作成
340327 journal

akiraaniの日記: TRPGルールブック用電子書籍フォーマットメモ 3

日記 by akiraani

SQL Liteにselect文の実行結果をhtmlのテーブルタグ形式で出力するオプションがあるらしい。いや、むしろないRDBの方がまれなんだろうけど。
いつぞやの仕様でマスターデータを作って、各チャート表示に必要なビューを定義してやれば、あとはそいつをselectしてやるだけでtableタグ形式の出力データが得られる。

テーブル構成の仕様としては

・マスターデータテーブル
・タイプデータテーブル
・タイプごとのビュー

を定義する。
ビューの定義はタイプデータに格納するので、インポート/エクスポートではマスターデータテーブルとタイプデータテーブルのみを入出力する。

各テーブル詳細
・マスターデータテーブル
 各データの詳細内容を格納する。
 →例えば、武器データの場合であれば命中修正、ダメージ修正、価格など、魔法データなら対象、効果範囲、消費MPなど

 テーブル構成は以下のとおり
  ・Name(string)
   →データの名前。null不許可。プライマリキー(※)。
  ・Type(string)
   →データの種別(武器、防具、魔法など)。null不許可。プライマリキー(※)。
  ・Parameter1~10(string)
   →各種パラメータの値。それぞれの番号のパラメータが何を示すのかはタイプテーブルで定義する。null許可。
  ・Cost1~5(string)
   →価格や消費リソースなどのコストに分類されるパラメータ。それぞれの番号のコストが何を示すのかはタイプテーブルで定義する。null許可。
  ・FilterKeyword(string)
   →サブカテゴリなどフィルタリングに使うメタキーワード。null許可。
  ・Detail(text)
   →データとして記載する詳細な説明文。null許可。
  ・Image(file)
   →画像ファイル。null許可。

 ※NameとTypeは複合キーなので組み合わせはuniq

・タイプデータテーブル
 データのタイプごとのパラメータ定義、ビューの定義を格納する

 テーブル構成は以下の通り。
  ・Type(string)
   →データのタイプ。マスターデータテーブルのものと同じ。null不許可、uniq、プライマリキー。
  ・Parameter1~10(string)
   →マスターデータテーブルのそれぞれの番号のパラメータが何を示すのかを定義する。未使用の場合はnull
  ・Cost1~5(string)
   →同上
  ・TypeView(string)
   →タイプ別のViewを定義するCreateView文。null不許可
  ・DetailWindow(string)
   →個別のデータのウィンドウ表示用のtableタグフォーマット。null不許可
  ・ExtendView(string)
   →タイプ別とは別に一覧表示フォーマットがある場合にテーブルタグを定義する。null許可。

追加
  ・Detail(text)
   →各項目の説明や記載記号の意味などの詳細な説明文。null許可。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 同名同タイプであるがデータが異なるデータ。

    #思いつく範囲だと、女神転生だと同名のレベル違いの悪魔のデータがあるのをどうするかとか
    #ガンドッグ・ゼロのカスタマイズの類のように「同名で性能が微妙に違う。どっちのデータを採用するかはGMの裁量に任せます」的なものとか。

    エラッタが当たった時に「以前はどうだったのか」が分からないのもなんか微妙違和感がある(どこがどう変わったのか比較できない)ので、多分リビジョンも込みでキーにせんといかんのではないかと。稀に「エラッタの当たる前のデータ」をネタにしたりもするので。

    • それはもう、名前変えてもらうしかないねw>同名のレベル違い
      別にDB的には内部にuniqなID持ってもいいわけだけど、プレイヤーやGMが区別に使うキーはあくまで「名前」なので、山賊(1LV)、山賊(2LV)みたいな名前をつけて分けてもらう方が建設的かと。
      #というか、名前同じでデータ違うってのは、ルール解釈的にはバグでしかない。そーゆーのをなくすことができるというのも利点の一つ。
      #どーしても同じ名前にしたければ、Parameterで名前を定義するようにして、Nameはuniqを確保するためのIDだとと割り切ってしまえばいい。Type別のVIEWにName列を含めなければいけないなんて制約はないし、表示に使わければ記載上は問題ないはず。

      あと、データ部分はあくまでstringなので、たとえば両手持ちと片手持ちの両方がありの武器とかはデータを/で区切ってデータを併記することができる。なので、同じアイテムが複数の形態を持つような場合は好きに併記すればいい。

      むしろ困るのは、ルーン文字やらのテキスト化できないデータを持つ場合ですな。

      エラッタは古いデータとdiffとればいいだけなので変更履歴自体は残すのは簡単。バージョン管理はDBファイルのタイムスタンプでも十分のはず。

      --
      しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
      親コメント
      • by Anonymous Coward

        ルーン文字ならU+16A0あたりに入ってます。
        ゲーム独自の創作文字のほうが厄介なのでは。たとえば指輪物語RPGでテングワールやキアスが必要になるかもしれませんが、Unicodeには収録されていませんね。スタートレックRPGでピカッドが必要になるかもしれませんが、こちらは明確に収録を拒絶されています。星界の紋章RPGでアーヴ文字が必要になるかもしれませんが、TRONコードにしか収録されたことがありません。
        まあラテン文字や仮名文字と一対一対応するような安直な奴はラテン文字/仮名文字転写を採用すればいいでしょうけど。

typodupeerror

海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs

読み込み中...