K3D開発情報 熊恭太郎 2004/06/08 22:16:04 ├1個エネミーってやっぱ使う人いるのですか... 熊恭太郎 2004/06/08 22:19:15 │└>1個エネミー、4個エネミーなどの少ない... 摘露 2004/06/12 23:17:57 │ ├私は毎日訪れているわけではないので、それ... 熊恭太郎 2004/06/13 21:03:15 │ ├基本となる8能力に絞ってはいけないのでし... 熊恭太郎 2004/06/13 21:04:01 │ ├アイテムリストと商品リストが別に存在する... 熊恭太郎 2004/06/13 21:05:05 │ └キャラクタメイキングの問題 熊恭太郎 2004/06/13 21:05:22 │ └>能力配分 摘露 2004/06/16 22:19:42 │ ├>確かに(8個)能力と技能ポイントを別に... 熊恭太郎 2004/06/18 02:23:18 │ └>処理速度の問題 熊恭太郎 2004/06/18 02:23:48 │ └>能力値配分 摘露 2004/06/20 17:24:33 │ ├モンスターのグループ数 熊恭太郎 2004/06/22 15:32:37 │ └「あるアイテムが必要」というだけであれば... 熊恭太郎 2004/06/22 15:33:08 ├・12個エネミーって実質30個くらいパラ... 熊恭太郎 2004/06/08 22:19:29 └アクセス数急増です。 熊恭太郎 2004/06/25 03:55:58 ├>モンスターのグループ数 摘露 2004/06/25 19:59:47 │├少々、更新している余裕がなかったので(と... 熊恭太郎 2004/07/07 23:35:18 │└例えば、「火炎ダメージ」+「即死効果」の... 熊恭太郎 2004/07/07 23:45:23 │ └お久しぶりです。 摘露 2004/07/09 21:20:32 │ ├PCか飛びました。 熊恭太郎 2004/07/27 21:07:25 │ └>PCか飛びました。 ユノア 2004/08/17 17:57:14 └一応、ここ以外の人たちのために、掲示板を... 熊恭太郎 2004/06/26 00:25:58
K3D開発情報 熊恭太郎 2004/06/08 22:16:04 ツリーへ
| K3D開発情報 |
レスを書く |
| 熊恭太郎 2004/06/08 22:16:04 | |
|
> ところで、カウンターが82まで回ってますけど、他にも誰か見ているのでしょうか? 摘露さんが頑張って押し上げたのかなと思いましたが(笑)、他にも来ている人がいるかも。 私は頻繁に見ていますが、ブラウザのリロード程度ではカウンタは上がらないので、 私の分は一日2くらい、それもトップページは殆どアクセスしていないのでこの数は意外ですね。 http://noelnet.org/kuma/k3d/index.php?TopPage (この掲示板内を除き、リンクはお控え下さい) ここは、このツール計画のスレッドということで。 |
|
├1個エネミーってやっぱ使う人いるのですか... 熊恭太郎 2004/06/08 22:19:15 ツリーへ
| Re: K3D開発情報 |
レスを書く |
| 熊恭太郎 2004/06/08 22:19:15 | |
|
> 1個エネミーってやっぱ使う人いるのですかね?私は雑魚は4個エネミー設定を使用しそと思っています。 基本的に、手抜き設定によるテストプレイが目的ですね。 また、システムそのものも、4個よりもまず1個の機能を実装してテストしていきたいです。 後は・・・、例えば、1000種類くらいモンスターを出したい人などはどうでしょう。 モンスターのコンプリート率で遊ぶゲームなんてのも、面白いかもしれません。 (そういうものが作れるようになるかは不明ですが・・・) > PCと全く同じ精度を持つ、通称:究極エネミーは存在できないのでしょうか? これは、以前あった仲間モンスターなどの話と一緒に考えていくことになると思います。 イベントの検討内容に含めていこうかなと。 |
|
│└>1個エネミー、4個エネミーなどの少ない... 摘露 2004/06/12 23:17:57 ツリーへ
| Re: 1個エネミーってやっぱ使う人いるのですか... |
レスを書く |
| 摘露 2004/06/12 23:17:57 | |
|
>1個エネミー、4個エネミーなどの少ない数のエネミーも、数値を計算式で展開したあとは、細かいパラメーターの修正は可能でしょうか? >CSV上の任意のモンスターデータを、12個〜32個に編集し直せばOKです。 可能なのですね。これを聞いて安心して雑魚も設定できそうです。 >隠蔽は、別に戦闘時専用のフラグを管理します。 >フラグを立てるためのアクションを用意します。 対応してくださりありがとうございます。 >ところで、カウンターが82まで回ってますけど、他にも誰か見ているのでしょうか? >摘露さんが頑張って押し上げたのかなと思いましたが(笑)、他にも来ている人がいるかも。 私は毎日訪れているわけではないので、それほど貢献してないと思いますが・・・ とはいえ、見る日はリンクして、様々な項目を見ますので、気付かないうちにいくつかカウンターを回しているのかも・・・ >店 アイテムリストと商品リストが別に存在する理由はなんですか? >キャラクタメイキング >ボーナスについて(課題) >ボーナス値の割り振りはぜひ行いたいと考えているが、検討事項が多数。 ・どのタイミングで行うべきか 性別選択よりは後で、職業選択よりは先ですね。 デフォルトの設定は決めておいた方が良いと思います。 ・対象能力値の定義方法 基本となる8能力に絞ってはいけないのでしょうか? ・複数に分けられるようにするべきか これは、複数に分けられるようにして欲しいです。 3DRPGCS程度で十分ですので。 >順序の変更(課題) >入力の順序を変更したい場合にも応じられるようにしたい。 >ある程度パターンを用意しておくか、自由定義できるようにするかは不明だが、作るのが簡単そうな設定がいい・・・ 名前入力から荷物選択までの7つ+能力値割り振りの8つに1〜8の番号をふれるようにして、1から順番に処理していくというのは困難ですか? >アクション さすがに複雑ですね。 ぱっと読んだだけでは理解できませんでしたので、今度じっくり読んでみます。 あと、bool 形式の説明よく分かりました。ありがとうございました。 |
|
│ ├私は毎日訪れているわけではないので、それ... 熊恭太郎 2004/06/13 21:03:15 ツリーへ
| Re: >1個エネミー、4個エネミーなどの少ない... |
レスを書く |
| 熊恭太郎 2004/06/13 21:03:15 | |
|
> 私は毎日訪れているわけではないので、それほど貢献してないと思いますが・・・ ありゃー、そうでしたか。 一日あたり、私以外に最低一人くらいは来ているような感じがします。 何にせよ、この掲示板見て来ていただく分には歓迎です。 こうして再掲載するともっと来るかな(笑) http://noelnet.org/kuma/k3d/index.php?TopPage |
|
│ ├基本となる8能力に絞ってはいけないのでし... 熊恭太郎 2004/06/13 21:04:01 ツリーへ
| Re: >1個エネミー、4個エネミーなどの少ない... |
レスを書く |
| 熊恭太郎 2004/06/13 21:04:01 | |
|
> 基本となる8能力に絞ってはいけないのでしょうか? ん〜なるほど、そうですねー。 設計思想を考えると、固定数というのは少し悔しい気がします(苦笑) とはいえ、そう言われてみるとそれが一番楽ですからね。 ボーナス割り振り対象を絞るときに、能力値の構造を考えなければなりませんが、 現状は配列になっています。 能力値 0 …… レベル 能力値 1 …… 体力 (略) 能力値 8 …… 魅力 能力値 9 …… 予約 能力値 10 …… 予約 能力値 11 …… 予約 能力値 12 …… 予約 能力値 13 …… ライフ 能力値 14 …… マナ 能力値 15 …… スタミナ (以下略) ・・・と、デフォルトではなっているので、インデックス 1 〜 N(最大12) に対する編集画面を用意して、そこで編集できるようにする・・・かな? 私のイメージとしては、ボーナスを割り振る作業は一回限りにせず、 能力値をグループに分けてグループ単位で何回か割り振れるように するつもりでした。技能にも別のボーナスを割り振りたかったので。 あと、ライフ(ヒットポイント)・マナ(マジックポイント)・スタミナ にもボーナスが割り振れるような仕組みにするつもりでした。 ボーナス1ポイントあたりの価値を変えて、ボーナス:筋力の変換が 1 : 1 とすると、ボーナス:ライフの変換を 1 : 4 にしたりなど、 配分を工夫できたらいいなぁと思っていました。 ですが、グループ分けにしても変換比率のカスタマイズにしても、プログラムが 負担になるので・・・N個一回だけというのはある意味魅力がありますね。 >・複数に分けられるようにするべきか >これは、複数に分けられるようにして欲しいです。 こいつは私の説明が悪いのですが、分けるというのは能力値のグループを分けて、 別々にボーナスを割り振れるようにするということです。 例えば、基本能力値に10、盗賊系技能に5、という具合に。 前述の仕様で確定すると、グループには分けず、ボーナスは純粋に Wiz と同様 基本能力値に対してのみ割り振る、ということになります。 また後で、サイトの方を修正しておきます。 |
|
│ ├アイテムリストと商品リストが別に存在する... 熊恭太郎 2004/06/13 21:05:05 ツリーへ
| Re: >1個エネミー、4個エネミーなどの少ない... |
レスを書く |
| 熊恭太郎 2004/06/13 21:05:05 | |
|
> アイテムリストと商品リストが別に存在する理由はなんですか? 例えば、店Aと店Bに、同じロングソードを並べることを考えます。 店Aと店Bに、ロングソードの全てのデータを記載することにしても良い のですが、まったく同じ値を書いておかないと、違う性能のロングソード を買えることになってしまいます。 ですので、ロングソードの性能はアイテムリストに、店データには商品イ ンデックスと価格と在庫量だけ設定するわけです。店Aと店Bが一つの性 能データを指せば、同じものを違う価格で購入できるわけです。 同じような場面が他にもあって、例えばモンスターの落とす宝箱の中身を リストするファイルには、店データと同じようにアイテムインデックスを 列挙しなければなりません。 うまい方法を模索中です。一つには、名前によって照らし合わせを行う方 法があります。商品リストにはインデックス値を書くのではなく、識別用 の名前を書いてしまうのです。これならば、チェック処理を入れておくこ とで入力ミスを最小限に留めることができますし、確実に分かりやすくな ります。 欠点は、起動時にチェック用の処理時間がかかることと、入力が面倒に なることです。 特に処理時間は不確定要素なので、「やってみるまで分からない」が正直 なところ。 |
|
│ └キャラクタメイキングの問題 熊恭太郎 2004/06/13 21:05:22 ツリーへ
| Re: >1個エネミー、4個エネミーなどの少ない... |
レスを書く |
| 熊恭太郎 2004/06/13 21:05:22 | |
|
> キャラクタメイキングの問題 > 性別選択よりは後で、職業選択よりは先ですね。 > デフォルトの設定は決めておいた方が良いと思います。 そうですね・・・ ボーナス割り振りは一回だけという仕様に決めて、職業選択の直前という のが妥当ですね。もはや完全に Wiz のイメージですが・・・ > 名前入力から荷物選択までの7つ+能力値割り振りの8つに1〜8の番号をふれるようにして、1から順番に処理していくというのは困難ですか? なるほど。 シンプルな方法思いつきますねー 並べやすさを優先して、「23456871」みたいな設定の仕方がいいでしょうか。 1は名前入力、8はボーナス割り振り・・・と仕様の段階で決めておいて、並び順に処理。 >>アクション > さすがに複雑ですね。 我ながら説明下手で。 後から読みかえしても、自分で意味を理解できないところがあったり(ぉぃ Wiki の編集は手軽すぎて、私の場合は勢いで文章を書くことが殆どなので、 分かりづらい部分も多いです。少しずつ分かりやすくしていければと思います。 HTMLだと、とてもこのペースでは更新できません。 Wikiですと、思いつきで文章が書けるので楽しいです。 その分、手抜きや下手な表現も多いですが。 それだけ、本人が楽しんで書いていると思って下さい(笑) |
|
│ └>能力配分 摘露 2004/06/16 22:19:42 ツリーへ
| Re: キャラクタメイキングの問題 |
レスを書く |
| 摘露 2004/06/16 22:19:42 | |
|
>能力配分 色々なことを想定しているのですね。 確かに(8個)能力と技能ポイントを別に割り振ることができれば、 例えば、盗賊技能でADDにように、シーフに特徴を出せますね。 罠解除が得意なシーフ、不意打ちが得意なシーフみたいに・・・ これは、面白そうです。 最も、DMがそれだけの演出をすることができなければ、無駄になるわけですが・・・ >店 ようやく意味が分かりました。 確かにこの方法の方が合理的です。 3DRPGCSでは、宝箱でこの方法を採用していますね。 2つのテーブルを持つと、かなりの処理時間がかかってしまうのでしょうか? 1つにするなら、店の数を制限して性能の中に店Xの値段・在庫としていく方法しか思いつきませんが・・・ >それだけ、本人が楽しんで書いていると思って下さい(笑) 私も3DRPGCSでシナリオを作成して思ったのですが、そうでなければやってられません。 あと、色々意見を言ってくれる人がいると励みになりますので、 その経験から、私は言いたい放題言わせていただいています。 >CPU は 1GHz 程度で軽快に動くように目指したい 結構処理時間がきついのですね。 私は1.8Gだからまだましな方ですが、それでも、3DRPGCSの再起動にはちょっと時間がかかります。 1Gで快適というののは、かなり高い目標ですね。 私などは、気にいったソフトの動作が遅い場合は、補強するのですが・・・ |
|
│ ├>確かに(8個)能力と技能ポイントを別に... 熊恭太郎 2004/06/18 02:23:18 ツリーへ
| Re: >能力配分 |
レスを書く |
| 熊恭太郎 2004/06/18 02:23:18 | |
|
>確かに(8個)能力と技能ポイントを別に割り振ることができれば、 >例えば、盗賊技能でADDにように、シーフに特徴を出せますね。 >罠解除が得意なシーフ、不意打ちが得意なシーフみたいに・・・ グループ数を制限して、インデックス N〜M の能力値を対象に割り振る 2番目・3番目のボーナスという形で定義すれば、可能かもしれません。 ひとまず今は基本能力値のみに絞って、将来的には、その方向で考えてみます。 >アイテムリストを分ける件 > 1つにするなら、店の数を制限して性能の中に店Xの値段・在庫としていく方法しか思いつきませんが・・・ そうなんです。 店の数を2〜4程度に制限して、性能の隣に在庫量の欄を用意すれば、 店の商品に関しては制限付きながらも解決します。 ただ、結局この問題は、店の定義だけに留まりません。 (宝箱の内容定義や、床に落ちているアイテム定義など) モンスターのデータも同じような問題を抱えています。 モンスターの性能を定義したら、どのような組み合わせと数で登場するかを 定義する場所が必要になってきますので、そのときにモンスターインデックスを 指定するようになると思います。 ということで、もっと根本的な解決方法を模索しています。 >3DRPGCSでは、宝箱でこの方法を採用していますね。 そうですね。基本的にトラップ・モンスター指定・宝物の中身指定等は全部 インデックス指定だと思います。特に変わった方法ではないのですが…… 画面でリスト表示しながらクリックで番号を選べる方が、このインデックス指定の 編集については楽ですね。 ですので、一番ユーザーフレンドリーなのは専用の編集ソフトを作ってしまうこと なのですが、さすがにそれほどのパワーがないので、もう少しうまい方法を考えるか、 補助ツールのようなものを作ろうかなと思っています。 |
|
│ └>処理速度の問題 熊恭太郎 2004/06/18 02:23:48 ツリーへ
| Re: >能力配分 |
レスを書く |
| 熊恭太郎 2004/06/18 02:23:48 | |
|
>処理速度の問題 >1Gで快適というののは、かなり高い目標ですね。 内容を考えると、1GHz が必要ってのは、多くのプレイヤーにとっては驚きのはずです(苦笑) 画像処理がないも同然のシステムですからね……… OS の差こそありますが、十五年前のマシンでも軽快に動けるくらいが望ましい内容です。 とはいえ、そこを押して、なんとか 1〜1.2GHz くらいのラインで我慢してもらう…… という感じです。 画面の広さが 800×600 なのですが、これはこの解像度が主流だった時代のノートPCを 意識して設定した仕様です。ですが、処理速度の問題で当時のノートではマトモに 遊べないと思います………。 (そういえば解像度の課題もありました。サイトに書いておかないと……) K3D は、起動時間がそれなりにかかっても、再起動があまり必要のない仕様にしたいです。 起動時間については、特定の環境で目標をN秒に設定するなど、閾値を決めて解決していく ことになると思いますが、アイコンのダブルクリック直後に一瞬で起動するようなアプリには ならないと思います。むしろ、読み込み時の進捗表示の仕様を検討するようなアプリになるかなと。 >あと、色々意見を言ってくれる人がいると励みになりますので、 >その経験から、私は言いたい放題言わせていただいています。 ん〜、そうですねー。 摘露さんが投稿するとそのたびに思考が練られて次に繋がるので、 是非続けてもらいたいです(笑) そういう意味では、一人ってのは少し寂しいんですけどね(^^;; あまり大々的に喧伝しても後が辛い……… 数名の支援者が最適かなと思いますので、もう少し参加する人が増えてもいいかな…… とはいえ、まだ実際に動くものを見せられなくてアピールできる資料が少ないので、 露出という点では努力していません。 ある程度進んだら、いろいろな方法で宣伝しようと思っていますが、今の ところはひっそりとしています。 |
|
│ └>能力値配分 摘露 2004/06/20 17:24:33 ツリーへ
| Re: >処理速度の問題 |
レスを書く |
| 摘露 2004/06/20 17:24:33 | |
|
>能力値配分 >ひとまず今は基本能力値のみに絞って、将来的には、その方向で考えてみます。 そうですね。 必要に応じてあとから付け加えていけばよいと思います。 >アイテムリスト これも、店もモンスターの宝箱も2テーブルで定義で問題ないと思いますよ。これなら、それなりの自由度と、数を定義できますから。 >モンスターの性能を定義したら、どのような組み合わせと数で登場するか 私がやりたいのはPDと同じ人数のパーティー戦ですね。 とはいえ、WIZ方式から余りに離れてしまうのは作りにくいでしょうから、ウィズ方式の最大6グループのパーティーというのはどうでしょうか? あと、もし可能背あれば、3DRPGCSと違って、共同出現は%で複数のパターンが出るようにして欲しいです。6グループ目まで行けば、線等パターンにかなりのバリエーションが広がると思いますので。 >ある程度進んだら、いろいろな方法で宣伝しようと思っていますが、今のところはひっそりとしています。 そうですか。それが無難かも知れませんね。 まあ、私はその間に自分が使う場合の希望を言いまくっていますが・・・ >転職 ・転職に資金を必要とするような仕組みはどうだろう これは、できるといいですね。 只で、訓練してくれるというのは本来おかしいですし。 ・転職にアイテムの消耗、もしくは破壊を伴う仕組みはどうだろう「あるアイテムが必要」というだけであれば、選択条件式に書いておけば判定できるが、アイテムの消耗処理は不可能 不可能な理由がわからないので、できれば教えていただけないでしょうか? ・転職回数を管理する仕組みはどうだろう (二回目以降、条件が厳しくなったり、価格が高くなるなど) 何回転職したとしても、転職不可能にはしたくないので、価格を上げるとかくらいがいいのではと思います。 ・転職にフラグの変更を伴う仕組みはどうだろう 転職にアイテムが必要なことにできれば、必要ないと思いますが、不可能なら、あってもいいかもしれません。 >能力値の初期化 DMが、能力値の一つ一つ、呪文やMPについて それぞれ、初期値・一定数減少・そのままの3択を選択する方式はいけないのでしょうか? 呪文については、忘れる・忘れないの2択で。 |
|
│ ├モンスターのグループ数 熊恭太郎 2004/06/22 15:32:37 ツリーへ
| Re: >能力値配分 |
レスを書く |
| 熊恭太郎 2004/06/22 15:32:37 | |
|
> モンスターのグループ数 問題の一つは、モンスターパーティの設定方法です。 データ管理的には2グループでも100グループでも同じことなので、画面及び CSV 入力から制限を受けることになると思います。 継続する列のモンスターのインデックスと出現率を指定するやり方は、シンプルで魅力 があるのですが、個人的には欲求を満たしきれません。 ですので、モンスターの性能を定義する一覧 CSV とは別に、モンスターのパーティを 列挙するための CSV を用意しようと考えています。具体的にどうなるかは不明ですが ファイル数が増えすぎると厄介なので、一個の中に沢山のパーティ構成を列挙できる 仕様ができればいいと考えています。(希望) ただしスマートな定義が出来るか・・・はたして不明です。 ----- 一つのパーティ例 ----- 《モンスター構成》 コボルド 3〜6 ゴブリン 2〜4 ダークメイジ 1〜2 《その他情報》 宝物番号 5 汎用経験値A 300 汎用経験値B 0 知名度 500 善悪 −1000 ---------------------------- CSV の特性上、複数行にわたって形の違う情報を入力できないので、一行に無理やり 詰め込むことになるでしょうかね(^_^; データが増えたときが地獄・・・ |
|
│ └「あるアイテムが必要」というだけであれば... 熊恭太郎 2004/06/22 15:33:08 ツリーへ
| Re: >能力値配分 |
レスを書く |
| 熊恭太郎 2004/06/22 15:33:08 | |
|
> 「あるアイテムが必要」というだけであれば、選択条件式に書いておけば判定できるが、アイテムの消耗処理は不可能 > 不可能な理由がわからないので、できれば教えていただけないでしょうか? ・・・あ、これは実現不可能ということではなくて、現在の仕様とプログラムでは 実現できていないということです。消耗処理を含める予定が無かったってことです。 消耗アイテムの仕様そのものがまだ曖昧であるため。 アイテム有無の判定については、実現の目処が立っているということになります。 (動作確認はしていませんが) 転職用の価格・転職回数・フラグ管理については、実はあまり積極的な案ではない ので、今は軽く抑えておく程度に考えています。これらの仕様が無ければ、転職施設 専用の設定ファイルを設置する必要もなくなります。(たぶん) > 能力値の初期化 > それぞれ、初期値・一定数減少・そのままの3択を選択する方式はいけないのでしょうか? そうですね・・・ 初期値が問題です。何をもって初期値とみなすのか。 キャラクタメイキングの工程で、ある瞬間に初期値として保存するよう設定できるよう にしましょうかね・・・。一人一人保存されることになりますね。 > 呪文については、忘れる・忘れないの2択で。 呪文については、忘れる忘れないの管理について考えていませんでした。 使用可能かどうかはあくまでそのときの式で判断する、という方針でしたので・・・ ですが現実的に、転職してレベルが下がったときに条件判定式だけで記憶を判断する のは難しいですね。記憶しているかどうかを判断するフラグは必要そうです。 そうなると今度は、どのタイミングで記憶する判定を行うかが問題になります。 記憶判定を行う式を設けて、どこかでチェックしてフラグを立てなければなりません。 能力値成長のタイミングと合わせて考えていかねば・・・ |
|
├・12個エネミーって実質30個くらいパラ... 熊恭太郎 2004/06/08 22:19:29 ツリーへ
| Re: K3D開発情報 |
レスを書く |
| 熊恭太郎 2004/06/08 22:19:29 | |
|
> ・12個エネミーって実質30個くらいパラメーターを持っているような・・・ > 最初から bool パラメータを必要数分用意するとは、どのような形式でしょうか? 後で、ああしまったと思って書き換えました。 石化や毒の機能の有無は、モンスターのパラメータ設定ではなく搭載する攻撃アクション (登録選択肢)によって決まるので、あの12個の中に設定する必要はありませんでした。 あと、bool というのは、true/false ( 1 か 0 )だけを表現する値の型です。 「boolean」から来ているものと思います。(VB では Boolean です) int 型(integer)がおよそ±21億で事実上代替え可能な表現になっていますので、bool は 不要といえば不要の表現ですね。 0 と 1 以外の情報が不要な設定項目については、true/false の設定であることを明示 するために、好んで bool という単語を使用しています。 より細かい話をしますと、変数で用意したときに、メモリ上の占有サイズが理論上は int より 3 バイト少なくなります。微々たる差ですので、使用するメリットはあまり ありません。bool 型の変数には、100 を代入しても 0.5 を代入しても、0 以外であれば 全て true に変換されます。 これは余談なんですが、昔はメモリを節約するために、int 型のような変数をビット単位で 使用して、例えば毒状態を0ビット目、石化状態を1ビット目、といったように、一個の変数 をシャブリ尽くして使用することが多かったです。(Wiz などはそうしているんじゃないかと) 今はメモリが豊富な時代ですので、たかが 0 と 1 を表現するのに 1〜4 バイトを丸ごと 割り当ててしまう場合が多いです。ビット単位で管理すると、プログラムが分かりづらいものに なることが多いのと、他の情報が大きくなりすぎているので、こんなところで節約してもメリット が生まれないというのが現状でして。 bool(boolean)というのは、そういう経緯で多用されるようになった比較的新しい型です。 昔のC言語にはありませんでした。 |
|
└アクセス数急増です。 熊恭太郎 2004/06/25 03:55:58 ツリーへ
| Re: K3D開発情報 |
レスを書く |
| 熊恭太郎 2004/06/25 03:55:58 | |
|
アクセス数急増です。 Referer が ime.nu からの間接リンクなんで、 どこぞの大手掲示板からリンク張られたかも。 いずれにせよ、リンク元はユノアさんサイトだけではなくなったようです。 まだサイトの内容が地味なので、しばらくしたら沈静化するかもしれませんが…… 悪いことではないのですが、見ている人がここ以外の場所を基盤にしていると、 色々と問題が起きてきますので、状況によっては私の管理できる場所に連絡拠点を 作ろうかと思います。また、周囲の目がネガティブな要素を多分に含むようになって きた場合は、閉鎖もしくはクローズドにします。 リンク許可で外部との接続を積極的に行うには、いろいろと準備が必要なので、 まだ早いなぁと思っていたのですが・・・ まず、掲示板を整備しなければなりませんね。 とりあえず、もう少し様子を見てみます。 変化があるまでは、これまでどおりということで。 |
|
├>モンスターのグループ数 摘露 2004/06/25 19:59:47 ツリーへ
| Re: アクセス数急増です。 |
レスを書く |
| 摘露 2004/06/25 19:59:47 | |
|
>モンスターのグループ数 >一個の中に沢山のパーティ構成を列挙できる仕様ができればいいと考えています。(希望) 全部でモンスターX体に対し、0〜(X−1)までの配列で定義するということでしょうか? 仲間を呼ぶという行為に支障がなければいいのですけど・・・ 確かに、これなら6人パーティーの敵とかも扱いやすいかもしれません。 >転職用の価格・転職回数・フラグ管理については、実はあまり積極的な案ではないので 私も、必要性は低いですね。 最初は、能力値だけの判定だけでも十分かと思います。 >能力値の初期化 >初期値が問題です 安直ですが、キャラクター作成時のボーナスを振る前の基本値を初期値としてはいけないのでしょうか? >アクセス数急増 認知度が増えたのは良いことだと思います。 私以外にも前向きな意見を言ってくださる方が現れるといいですね。 製作頑張ってください。 あと、更新分読ませていただきました。 >アクション 失敗時メッセージも複数欲しいですね。 ○は、「呪文名」を唱えた。しかし、「敵」には効かなかった。 ○は、「呪文名」を唱えた。しかし、「敵」は「呪文名」に耐えた。 ○は、「呪文名」を唱えた。しかし、「敵」は、すばやく身をかわした。 のように設定したい呪文があるからです。 効果によるメッセージ一覧は、CSV形式ではだめですか? >効果を別定義する方針で考えてみる 例えば、「火炎ダメージ」+「即死効果」の呪文について、以下の効果は設定可能でしょうか? 1.無効判定 「敵」は火炎無効を持っている(或いは火炎ダメージ減少率100%である) 「○は、「呪文名」を唱えた。 「敵」には、効かなかった。」 それ以外」2へ進む。 2.耐久判定(あるいは、回避判定・耐久と回避と両方ある場合もあり) 成功:「○は、「呪文名」を唱えた。 「敵」は、攻撃に耐えた。」 失敗:3進む。 3.即死判定 成功:「○は、「呪文名」を唱えた。 永遠の炎が「敵」を焼き尽くす。 「敵」は力尽きた。」 失敗:4へ進む。 4.ダメージ判定 「○は、「呪文名」を唱えた。 「敵」は000のダメージを受けた。」 |
|
│├少々、更新している余裕がなかったので(と... 熊恭太郎 2004/07/07 23:35:18 ツリーへ
| Re: >モンスターのグループ数 |
レスを書く |
| 熊恭太郎 2004/07/07 23:35:18 | |
|
少々、更新している余裕がなかったので(というか、暑い(苦笑))先にレスしておきます。 > モンスターのグループ数 えーと、例にあげたものは CSV に記述する情報を列記したものです。 内部データ構造の仕様は別に考えるので、仲間を呼ぶといった行為は 別途作っていくことになると思います。 単純に6対6の戦いを行う場合は、グループを6に分ければいけると思います。 先の例で行くと、このような感じになるかと思います。 《モンスター構成》 コボルド 1 コボルド 1 コボルド 1 コボルド 1 コボルド 1 コボルド 1 実際は、これを横に並べることになります。 > 初期化(ボーナスを振る前の値にする) ボーナス割り振りは、将来的に割り振れる回数が増える可能性があるので、 結局どのボーナス割り振りの直前を初期値として確定するかを決めなければ なりません。 また、ボーナス割り振りを一切行わない場合もあるので、ボーナスを割り振る タイミングは、あまり意識させなくても良いと思っています。 キャラクタメイキングのステップ 1 〜 N のどこを初期値に採用するかを、 どこかで設定してもらおうかなと。 > アクションの失敗時メッセージ複数 設定できるようにしたいですね。 ただ、メッセージ関係は、少々 CSV 設定を避けたいという気持ちがあります。 実際はどうなるかわからないんですが…… (横長になるのがなんとも辛い) 仰るとおり成功時・失敗時ともに何パターンか設定できるようにしたいので、 より良い方法を考えます。 |
|
│└例えば、「火炎ダメージ」+「即死効果」の... 熊恭太郎 2004/07/07 23:45:23 ツリーへ
| Re: >モンスターのグループ数 |
レスを書く |
| 熊恭太郎 2004/07/07 23:45:23 | |
|
> 例えば、「火炎ダメージ」+「即死効果」の呪文について、以下の効果は設定可能でしょうか? 結論から言うと、できるようにしたいです。 程度の差による場合分けが、一つの大きな目標です。 今回のケースで行くと、デフォルトでは「ダメージ減少率」というパラメータが ありませんので、「炎耐性」の名前を変えて式をいじることでパーセンテージ としての役割を発揮できると思います。 大抵は式をいじるのが面倒なので、既存の判定式に合わせてパラメータを いじることになると思います。(試してみて、不満があったら変えればいいので) あと、 「○○系呪文攻撃を行った場合の標準的なダメージ算出方法」(○○=炎とか氷とか) を考えてみたいですね。これは、具体的なデフォルト設定に繋がっていくと思います。 算出もとの材料に用いる要素としては、例えば以下のものが考えられます。 ● 攻撃側要素: レベル・知性・集中力・呪文技能・○○系呪文・疲労度・ライフ・スタミナ (他、装備品や追加状態による各パラメータの補正あり) ● 防御側要素: レベル・体力・集中力・呪文耐性・○○耐性・疲労度・ライフ・スタミナ (他、装備品や追加状態による各パラメータの補正あり) といった具合に用いる要素を決めて、以下の式を考えてみるわけです。 (1) 命中値を算出する式 (2) 回避値を算出する式 (3) 命中を判定する式 (4) 攻撃値を算出する式 (5) 防御値を算出する式 (6) 実ダメージを算出する式 簡略化すると、どのような攻撃方法をとった場合にも上記6ステップで処理が行われることになるので、 その“標準的な”仕様を考えたいということです。 これを考えていくと、値の絶対的な価値が決まってきます。 例えば、筋力が10の価値とは高いのか低いのか、レベル100というのは最強クラスなのか それとも初心者レベルなのか。 当然、細かくは制作者によって違ってくるわけですが、私としてはそのデフォルトを決める必要があり、 その設定を元に制作者が新たなバランスに修正していくわけです。 |
|
│ └お久しぶりです。 摘露 2004/07/09 21:20:32 ツリーへ
| Re: 例えば、「火炎ダメージ」+「即死効果」の... |
レスを書く |
| 摘露 2004/07/09 21:20:32 | |
|
お久しぶりです。 PCか飛びました。 データが全部消えました。 作成中だったシナリオも全部消えました。 密かに進めていたROSのデータもすべて飛びました。 それとは別に、オフの事情で、 しばらくは、ぜんぜんレスできそうにないです。 (前置き長すぎ) 要望を取り入れていただいてありがとうございます。 炎耐性を名前はそのまま計算式をパーセンテージにして使おうと思います。 6ステップの標準攻撃は、複数サイクル可能なのでしょうか? (1〜3を別の式で2回行うなど。) 前回の私の例で言うと、 命中判定と即死判定と命中率を2段階計算する必要がありますので。 複数サイクル可能であれば、上記6ステップによって何でもできそうな気がします。 |
|
│ ├PCか飛びました。 熊恭太郎 2004/07/27 21:07:25 ツリーへ
| Re: お久しぶりです。 |
レスを書く |
| 熊恭太郎 2004/07/27 21:07:25 | |
|
> PCか飛びました。 大変ですね・・・。 ゲーム作成は、バックアップなしでは怖くてできませぬ(;_;) 私の方は、慢性的なディスク容量不足に悩まされています。 ちょっと空けてはダウンロード、というのを繰り返しているのですが、 これが対処療法にしかならなくて毎日のように容量不足の警告メッセージが表示されています。 サイトのほう、更新が遅れまくっていて自分でも困っています。 ネタや書き溜めたテキストはあるんですがどうにも収拾が付かない量で……… > 6ステップの標準攻撃は、複数サイクル可能なのでしょうか? 現状、できないために結果として多分岐ができません。 つまり、まだ命中失敗の二分岐にしかできないようになっているので、 どうするか悩むところです。 このままでは不本意なので、「計算4個→判定パターン7個」という形を作って みました。 詳しくはこちらなんですが・・・ http://noelnet.org/kuma/k3d/index.php?%A5%A2%A5%AF%A5%B7%A5%E7%A5%F3%2F%B9%B6%B7%E2%B4%D8%B7%B8 下の方に、設定ファイルの例があります。 まだ机上プランですがこんな感じでやってみようかと。 左にある CalcRate0 といったキーワードは設定項目を現します。これらは憶えられる ものではないので、コメントを見ながら設定します。 成功判定式0 〜 メッセージ0 の組み合わせを7まで作れば、最大8パターンまで結果や メッセージを処理できる、ということで。 |
|
│ └>PCか飛びました。 ユノア 2004/08/17 17:57:14 ツリーへ
| Re: お久しぶりです。 |
レスを書く |
| ユノア 2004/08/17 17:57:14 | |
|
>PCか飛びました。 >データが全部消えました。 >作成中だったシナリオも全部消えました。 >密かに進めていたROSのデータもすべて飛びました。 あ、あー、 ご愁傷様です。 ユノアも気をつけないと! |
|
└一応、ここ以外の人たちのために、掲示板を... 熊恭太郎 2004/06/26 00:25:58 ツリーへ
| Re: アクセス数急増です。 |
レスを書く |
| 熊恭太郎 2004/06/26 00:25:58 | |
|
一応、ここ以外の人たちのために、掲示板を用意しています。 http://noelnet.org/kuma/k3dbbs/k3dbbs.cgi ・・・見事に寂れそうな掲示板ですが(苦笑)、一応体裁は整ったってことで。 来訪者の来訪の経緯を考えると、あまり積極的に参加してくれそうな人は 掴めないと考えています。 どうもカウンタ数を見ると、「K3Dの制作」と「キャラクタ情報」のページが人気ですね。 大抵の人は、TopPageから「K3Dの制作」を見て、撤退している感じです。 CG関係が弱いことと、文字ばかりの内容を知った段階で、大半の人は 興味を失うと思うので、まあこんな感じかなと。 ・・・とはいえ、さりげなくリンク元が気になります・・・どこだろ。 何にせよ、時と共に流れるようなページからリンクされている感じなので、 しばらくすれば沈静化していくものと考えています。 |
|