Desigeon blog

再移転テストのお知らせ

2010-06-02T23:43:00.004+09:00

Desigeon blogを以下に移行してみます。

http://d.hatena.ne.jp/desigeon/

こちらの記事は大部分を移転したつもりですが、コメントは反映されません。

移行の理由は、はてなダイアリーの編集が少し安定してきたことと、更新のしやすさです。

試しで始めてみたGoogle bloggerの利用は短命でした。こちらの利点としては、コメント欄の管理機能が細かいことと、閲覧者への即応性の高さがあります。あとメンテの都合によって閲覧できない時間帯がほとんどありません。

Visual C++ 2010 Express Editionの所感

2010-05-25T02:06:00.018+09:00

先日、マイクロソフトのVisualStudio2010無償版(Express Edition)の紹介をしましたが、その中のVisual C++をちょっとだけ試してみました。

無償版はDesigeon的にはまったく使えませんが、有償版(Standard Edition)への将来的な移行という意味では面白いと思いました。まずDesigeonがWindows2000で動かなくなるという部分に面食らいましたが、覚悟はしていました。

素人向けの結論を言えば、VC++Expressはゲームを作るのにストイックな環境で、ゲーム制作全般の学習には向きません。たぶんC#やJavaの方がいいと思います。ゲームプログラミングとしてのC++ではなく、シンプルにCやC++を学ぶ気なら使えるかもしれません。

以下のサイトでVC++ Expressの特徴をまとめていましたのでご紹介します。

Visual C++ Express の使い方

まず大きな特徴として、作成できるアプリケーションはWindows2000で動きません。ゲームに限らず、世の多くのソフトウェアがVC++で開発されることを考えると、今後への影響が大きそうです。Windows2000対応のソフト開発はVC++2008が最後ということになります。おそらくWindowsXPも時間の問題で、２年後にはXP切り捨ての話が出始めるのかもしれません。

C++自身も進化しています。C++という言語はどんどん仕様が拡張されていて、次バージョンとして提唱されているC++0xバージョンの一部の機能を、VC++2010は取り入れているそうです。

無償版には、ウィンドウのメニューを編集するためのリソースエディタがありません。窓のメニューをGUIでデザインできないというのはハンデです（テキスト編集ならできます）。これはフリーウェアで代替えが効くのですが、知識のない人がWindowsアプリ開発環境として、わざわざVC++Expressを選ぶ必要はないと感じました。

それとMSの伝統的なライブラリであるMFCとWTLがついておらず、Desigeon的にはこれが致命的です。
買いなさいということなんでしょうね。

日本語専用ごめんなさい

2010-05-16T01:30:00.010+09:00

「Sorry, Japanese Only」とは昔のウェブサイトでよく見かけた言葉ですが。
残念ながらDesigeonも日本語専用です。

とあるウィザードリィ動画のコメント欄に、「Desigeonを見つけたって？翻訳すれば面白そうなソフトなんだけどなー」という感じのやりとりがありました。

http://www.youtube.com/watch?v=jYvVAz4Zocg

この点、DarkHallやElonaは素晴らしい。多国語を意識するくらいの覚悟がなくちゃフリーウェアの世界でメジャーにはなれないのかもしれませんな。メジャーになる必要があるかはそれぞれでしょうけれども。

ううむ、しかし、申し訳ない。気持ちの上では英訳したいでやんす。

新計算手順のメッセージ表示テスト

2010-05-13T22:17:00.007+09:00

やー、なんとも地味なテストでありますが。

新計算手順の命令の中にメッセージ表示命令を作って、以下のように引数を指定できるようにしてみました。

メッセージの中に二つの値を埋め込むつもりなら、命令＋値データ×２ということで、合計３つの命令を置くことになります。置換記号として使っている「%.1f」とかいう部分の書式はC言語のprintf()に準じます。

構造上、ひとつの命令に際限なくデータを持たせることは原理に反するので、ひとつの命令に多数の設定を置くことは避けています。多数のパラメータを指定すべき命令では、命令に続けて値データを置くことで、引数として拾わせていきます。

上の例ではメッセージを表示していますが、例えば将来、画像を表示する位置を指定したり（四辺の位置を指定）、メニューを作れるように（メニュー項目をリスト指定）したりする場合には、同じような方針をとるかもしれません。

「ブルーバレット」より操作の誘導、戦闘行動順リスト

2010-05-08T12:22:00.017+09:00

さば缶さんが「ブルーバレット」という3DダンジョンRPGを作成、公開しています。

http://sabakan.cc/rpg/blog/archives/3229
http://petitrare.com/blog/?p=62

いくつかの理由で興味深いです。

序盤の操作の誘導
キャラクタの行動順をリストする機能
RPGツクールVXで3DダンジョンRPGを作成

まず、序盤のプレイヤーに対する操作の誘導です。プレイヤーの操作に追従しながら説明する手。プレイヤーアクションをイベントプログラムによって捕捉し、その都度説明を挟むという手間のかかる仕込みが必要ですが、私はこれが、一般向けに作るゲームほど必要だと思っています。

戦闘ルールは、「使うコマンドごとに、次に回ってくる順が視覚的に分かる」という仕組みをとっています。これもDesigeonでやりたいことのひとつ。ピンポイントで機能を実装するだけならすぐにできるのですが、Desigeonの場合はツール化しなければならないので、実用化の目処が立っていません。イベントでできる水準まで持っていくのか、今の戦闘のように直接的に実装するのか、不透明です。（私の場合、元ネタは戦国ランスです。戦国ランスだと行動リストが横向きでした。ブルーバレットは縦向きですが実質的に同じ機能です。実は画面デザインが大きな課題になっています）

最後に、RPGツクールを利用すればいろいろなことができます。こう言ってはなんですが、ツールを本気で使い込む気があるならDesigeonに出番はありません。現時点ではDesigeonのみならず、2D/疑似3D表現のRPG制作ツールは、特別な思い入れでも無い限りRPGツクール一択のような気がします。

メッセージ等、文字列の指示方法

2010-05-05T23:42:00.002+09:00

このGW中、ツイッターが不安定で手短に発言する場所がないです。あと、暑いと作業がはかどりませんねぇ。今日はアイスを食べつつ、こんなことを書いて気を紛らわせています。

文字列の表現。詳細イベントにはメッセージ表示命令を含めます。そうしないとイベントで何か起こしても、プレイヤーに何も伝えられないじゃないか。

ところが厄介な問題があるのです。文字列の話なので、能力値みたいに値の桁を指定するだけでは動かない。たとえば以下の一文です。

「￥１は￥２に￥３のダメージを与えた！」

これまでは上のように書いていればコマンドの表現が機能しました。というのも、￥１と￥２に割り当てる文字列は決まっています。￥３も能力値の設定を引っ張ってくれば表示すべき桁数が分かります。ダメージを与える先のHPが整数なら、整数に丸めればシナリオ作者の意図通り動きます。

でもイベントの中では、数値の意味とメッセージの意味が結びついていません。単に演算命令があって、一方では単にメッセージ表示命令があるだけです。だから￥１も￥２も￥３も、それが何者なのか知っているのはシナリオ作者だけです。そこで文字列や数値が何者であるか、指示する必要が出てきます。

「%sは%sに%8.2fのダメージを与えた！」

最初の %s → 追加でキャラクタの名前を指示
二番目の %s → 追加でキャラクタの名前を指示
三番目の %8.2f → 追加でグローバル変数等を指示

という感じで、メッセージの中には書式を指示して、それぞれを置き換える文字列や値を追加で指示します。

%sとか%8.2fとかいうのは、C言語等では一般的な文字列フォーマットの書式です。これはほとんどそのまま採用しようかと思っています。むしろ使わないとメッセージを指示できない、ということになります。

イベントの分岐命令があって、キャラクタの更新命令があって、メッセージ命令があれば、とりあえずそれらしいイベントを設置するところまではできるはず。過去の記事ではこのすべてについて触れてきました。

今回述べた文字列がらみが詳細イベント基礎部分における最後の課題ということになります。すべてに共通する課題は「使いにくさの克服」になってます。克服しきれる問題ではないので、だいたい覚悟しておきたいと思います。

新計算手順の更新命令に関する値の範囲

2010-05-05T00:24:00.015+09:00

皆さんゴールデンウィークは仕事ですよね？([Y]/y)

最近はあまり開発が進まないんですが、次バージョンではなんとか、新計算手順（イベント詳細命令）の更新命令を入れたいなという気持ちを持ってます。これは、能力値の現在値や成長値を書き替えたり、ステートを着脱したり、所属を転向するなどの命令を含んでいます。

ところが問題がありまして、指定した値をどういう理屈で適用するかが難しいです。

能力値は下限が曖昧です。ここがひとつ問題になっています。

能力値の成長値: 能力値の成長値には上限があって下限がありません。上限値の計算方法は複雑です。
能力値の一時値: 一時値には上限も下限もありません。
変動能力値の現在値: 変動能力値の現在値については下限が能力値自身の最小値と同じです。でも上限は能力値の最大値ではなく最終値です。最小値と最大値はセットで指定するのに、変動現在値の範囲に適用しているのは最小値、下限のみなんです。一貫してません。
段階能力値の各段の現在値: 段階能力値は各段の現在値をマイナスに設定できるようになっています。これは意味がありませんのでゼロを下限にしようと思っています。

以上のようになった経緯については割愛します。

それで、能力値の各値を更新した際、どのような値に丸めるのかが重要な問題で、その詳細を定義し、説明して学習してもらうことが適切なのかどうか。

いっそ現在値を管理している「変動能力値の現在値」「段階能力値の現在値」の二つを除いて、値の範囲を取っ払ってしまおうかなあ、と考えてます。やるなら仕変になります（成長値を弄る旧シナリオの動作が変わるかもしれない）。

値の更新はもう一つ厄介な問題を含んでます。こちらは解決済み、というか妥協することにしました。

それは値の代入・加算・減算といった演算加工です。

例えばイベントの中で、HPに30%ずつダメージを与えるにはどうしたらいいでしょう。まず30%の定義とは？以前の簡易イベントのルールでは、「上限－下限」を100%としています。HPに-100～+100の範囲があるなら、30%は60になります。しかしここ、いま見るとバグっていて割合計算時の下限はゼロという認識で動いています。HPの最大値が100ならおそらく30%は30です。この問題は別に置いておきます。

細分化した命令体系を使う場合、すべて自前計算になります。更新命令には値の代入しかありません。15を指定したらHPが15になるのです。パーティ全員に30%ダメージを与えたいなら、一人一人計算してHPの値を決定しなければなりません。

これまでの経験から、全員にダメージを与えるという処理はことのほか複雑であると感じています。例えばダメージを与える際、メッセージ・画像エフェクト・効果音を同時に発するとしたらどうでしょう。そこは単一の加減算命令を置く場所ではなく、表現の手順をプログラミングすべきところです。30%を加減算する命令だけあっても、「12ポイントのダメージを受けた」というメッセージは作れません。12という文字列を指定するには結局12という値を計算しなくてはいけない。自動計算でやっても意味がない。だから値の更新自体はシンプルな代入に徹する、という考え方です。

この辺が詳細イベント命令の使いにくい部分になりますが、そういうことを書いているうちに、他所のスクリプトを使えるエンジンがだんだん羨ましくなってきました。隣の芝が青く見えるのは昔からなのでやりません（開発力の面でデメリットが大きいのです）が、時折浮気したくなります。

詳細イベント命令について、私がやりたいのは能力値やコマンドの育成を、キャラクタ判別しながらやること、です。条件を満たした魔法使いに、ある場所で特殊な魔法を覚えさせるとかです。それとキャラクタを抽出して転向することです。戦士を丸ごと忍者に変えるような、そういう感じの。

全体としては、最終的にどんな形になるのか自分でも楽しみです。

公開を開始したVisual Studio 2010 Express

2010-04-30T00:47:00.016+09:00

マイクロソフトのVisual Studio 2010 Expressが無償公開されています。

具体的にはVisual C++, Basic, C#の開発環境のことで、今年発売の新製品に先駆けて、開発や学習に必要な最小限のモジュールを無償配布しています。

Microsoft Visual Studio 2010 Express

Windows ネイティブなアプリケーションやおよび 3D の 2D ゲーム開発を支援します

マイクロソフト、無償の開発環境“Visual Studio 2010 Express”シリーズを公開(窓の杜の記事)

有償版は来月です。コンパイラの質は有償版と同じなので、個人でゲームを作るだけなら無償版で十分だと思います。開発マシンが古い場合、スペックにはご注意下さい。

なんか日本語コメント部分（引用部）が変ですな。3Dおよび2Dのゲーム開発を支援、が正しいのだと思います。

Desigeonは、理屈の上ではVC++を最新版に差し替えてリコンパイルするだけで、処理速度が向上するはずです。しかし私の個人的な環境および時間のためにそれができません（誰か開発用マシンを恵んで下さい）。

本気で2005～2006年あたりのPCを誰かに貰ってこようかしらと思案中。でもコンタクトをとる段階で時間的な壁が厳しいことが予想されるので、今回もパスかなあ。いつになるか分からないけど、本格的に環境を再構築し直すそのときまで。まあコンパイラは逃げませんから。

機能評価を目的とした個人のシナリオ設計

2010-04-24T22:50:00.017+09:00

イベント機能を作ったり、画面の定義方法を考えたりすることについては、遅々として進めてはいるものの出せるところに持っていくには自身が無いので、同時に自作のシナリオ制作についても考えています。

私自身が作品作りを進めれば、イベント編集に必要な感覚とか、画面の操作に必要な感覚とかが掴めるのかなあと。作品ができあがるところまで確認できれば納得がいきますが、そこまでできずとも、これは出す価値アリと思えるような手応えが欲しいです。

最近、夕食の献立を決めかねるのと似たような状況が、Desigeon制作にも起きています。「夕食は何がいい？」と尋ねて一番困る答えが「何でもいい」というものです。現実的な作品計画を元にリアリティのある要望が挙がってこない環境は、ソフト制作にとって利点でもあり欠点でもあるんだなと思いました。

これが例えばメーカーでは、特定のゲームプロジェクトの進行に応じてツールを開発したり、営業の思惑が画面に影響を与えたりするわけですが、そういった欲求がないことがやりやすくある一方で、自由すぎてなかなか決められないという状況に繋がります。

そこで私自身の手で、適当に遊べそうなシナリオを設計しようとしているのですが、これがまた大変で。ツールの許容範囲でやろうとすると理想的な設計をすることが難しい。かゆいところには手が届かないことを知りつつ、それでも既存の機能を使って面白そうなところに持っていかねばなりません。

それでちょっと思ったのですが、さまざまな機能を同時に使うのではなく、一部の機能にスポットを当てて、浅く狭いゲームをイメージするとDesigeonに向くかもしれないと思いました。

追記。課題というか、シナリオを考えていて今一歩と感じた既存の機能が以下です。

成長ポイント。イベントやアイテムによって成長ポイントを与える手段が欲しいです
アイテムレベルの経験値。同様にアイテム経験値を増やす手段がもっと欲しいです。また、アイテム個別に経験値を増やしたいです
キャラクタの増減管理と切り替え。以前どこかで語った大人数パーティの一部です。ダンジョン内で、あるいは戦闘直前や戦闘中に、参加メンバーを指示できるというものです。同時に、あらかじめシナリオ側によるキャラクタ定義も必要です。プレイヤーに30人ものキャラクタを作ってもらうわけにはいきません

成長ポイントもアイテムレベル経験値も、増やす対象物を絞る手段が欲しくなります。例えば前衛のPCにのみ経験値を与えるとか、武器にのみ経験値を振り込む、といった条件つきの切り分け方です。

対象物件を絞って処理したり、キャラクタの管理を行うには、やはり現在進行中のイベント実装が欠かせないこと、シナリオ作者側にプログラミングの意識が必要になることから、シナリオ制作がいかに面倒くさいものか（あるいは知的なおもちゃとして楽しいものであるか）考えさせられます。

3D迷路表示の工夫

2010-04-15T01:22:00.016+09:00

本日の記事は、表示環境が暗いと分かりにくいです。

3D迷路の表示について、以下の機能を考えています。

視界外の記録済みブロックを表示
未記録ブロックにマーカーを表示
迷路を縞模様で表示
視覚記号・視覚画像の相対表示位置を指定
遠近感をもたらす明るさ調整

線画のテスト

変更前

以下は現在の画面です。視界の設定はウィザードリィのロミルワ相当ですが、画面には左手に壁があるだけです。

変更後

以下は上に挙げた項目のうち、明るさ調整以外の機能を組み込んで、同じ場所を表示したときのスクリーンショットです。表示環境が暗いと縞模様は見えません。

テストでは記録済みのブロックに限り、視界を超えた場所まで表示しています。クエスチョンマークは未踏破ブロックを表し、主人公がそこに行くと取り除かれます。クエスチョンマークは上ぎみに表示してみました。

これらは、すべてのシナリオに適合する機能ではないので、オプションにするつもりです。

迷路画像との組み合わせについては一部非対応にするかもしれません。おそらく視界外ブロックは専用画像を用意した場合のみ対応、縞模様は非対応、というあたりが妥結点かなと。

遠近感をもたらす明るさ調整

これは実現の可能性という点で未知数ですが、迷路の奥を暗く、という処理を入れたいと思っています。以下はユノアシルンさんのアフターレジェンド(http://www.geocities.jp/y_u_n_o_a/)でテストしたときの表示結果です。

現在の表示

現在は以下のように表示しています。

明るさ調整後の表示

明るさを調整したあとの表示です。全体的に暗いので注意です。

……と、今回の調整はちょっと暗すぎました。実際の明るさは調整しなければなりません。が、この機能を入れても今より明るくなることはないので、プレイヤー的には雰囲気が出るけど見づらくなる、が直感的な感想になると思います。

シナリオ側では、遠くが暗くなることを想定して、明るめの画像を準備しておくことも必要になってきます。

課題

明るさの調整については、実現したとしても綺麗になるか分からないこと、処理速度面でのデメリットが大きいことから、まだ思案の段階です。

他の機能は入れても害がなさそうなので、順次入れていきたいと思っています。縞模様については現在でもシナリオ作者がその気になれば指定できますね。

試し中の戦闘エフェクトが気持ちいい

2010-04-07T22:19:00.010+09:00

戦闘エフェクトのテンポがよくて動きが気持ちよくて、早く実用化してみたいなあという気持ちです。

私が試したものはたまたまそうなったのですが、爽快感を重視したシューティングゲームや、他のテンポのいいアクションゲームを作りたがる人の気持ちが、ややもすると理解できる内容でした。

とはいえ、エフェクト自体はファミコンレベルですから、洗練された表現は何一つありません。無骨なフラッシュです。

アニメーションのテンポというのは、時間の絶対量では決まらないんだと知りました。これが大きいです。

よく、戦闘のテンポが悪いとか、もっさりしているとか言いますよね。私はダンジョンクルセイダーズ２の遅さを反面教師にして試したのですが(※1)、それが功を奏した感じです。綺麗なグラフィックを使っていてもこういう場面で遅くちゃねえ、という部分を解消したらどれほど良くなるのか、と思い試したら実にスピーディになりました。きちんとした画像でエフェクトをかけたらもっと爽快になれると思いますが、残念ながらエディタとしてはこの辺で妥協ですね。

テキストとの比較も重要でした。マシン処理的にはテキストの方が軽くても、「プレイヤーが読むリズム」で戦闘が進めば遅くなります。

フラッシュと数字の羅列で表現すると、プレイヤー側の認識速度が向上します。読むのではなく把握するという感じです。昔のドラゴンクエストシリーズとファイナルファンタジーシリーズの違いですね。

結果、テキストよりも体感的に早い感じがします。トータルの戦闘時間は長くなるはずなので、慣れてくればどうなるか分かりませんが、初見では胸がすっとしました。

Desigeonの戦闘の参加エネミー数は、他の多くのRPGに比べて多い傾向がありますので、プレイヤーの視覚認識速度を上げておくことには意味がありそうです。

早く課題を解決したくてもどかしい。

※1 「ダンジョンクルセイダーズ２」というのは3DダンジョンRPG(18禁)です。ゲーム自体は面白かったのですが戦闘での作業性が全般、いまいちに感じていました

計算手順（イベント手順）機能の実装経過

2010-04-02T21:42:00.007+09:00

以前より、新しい計算手順（イベント手順）機能を開発中です。

手順の分岐と、キャラクタの抽出命令を入力できるようになりました。編集する部分には試みにRPGツクールのテイストを入れていますが、まだどういうものになるか分かりません。

この他、キャラクタの更新命令とメッセージ表示命令を用意すれば、新しいイベント機能の体裁は整うかなあという感じです。

現時点でこの手の機能が恩恵を受けるのは、Diseardryのように、キャラクタ育成をストーリー進行に合わせて細かく調整したい場合くらいです。複雑なことをしてもゲーム側の表現がついていかないので、画面まわりの機能が追加されないと、素人プレイヤーに分かりやすいイベントを提供することは難しいと思います。

あと、この機能を現在の計算手順に適用するのは先のことになります。先に実験台にする他の機能に適用していきます。

これ自体には大した機能がありませんが、私としては基礎部分ができてきたのでいい感じです。

ちょっと触れてみたのですが、複雑な条件分岐をさせようとするとシナリオ編集が相応に複雑になります。従来の簡易イベント機能に比べると命令が細分化されていて、機能を削いだプログラミング言語という印象です。

いい画面定義方法はないか

2010-03-30T20:51:00.005+09:00

画面構造を指示する方法を考えてます。ここは作品のキャッチが絡むので大切なところです。キャッチという意味ではイベントよりはるかに重要です。

いつしか掲示板でも悩んでいましたが、いい方法はないかなあと。

以前、熊恭太郎雑記では、グラフィカルな戦闘画面や迷路画面を紹介してきましたが、ああいった画面を作ること自体は、ゲーム側については簡単なのです。

面倒なのが、シナリオ作者がどうやったらアレを指示できるかなのです。HPを表示するのにも書式がありますよね。横棒グラフを表示したいかもしれないし。顔グラフィックの横幅はどれほどなんでしょう。メッセージの表示位置をどこに置きましょうか。何行まで表示するんでしょう。

すべて数値が決まれば解決です。問題はその数値がシナリオ作者側の頭にあり、私が決めることではないということなのです。

ということで、画面編集の方法について、何かご意見があればよろしくお願いします。

専門知識は操作しながら学習させたい

2010-03-28T12:16:00.023+09:00

Desigeonを使うと多くの場合、キャラクタの能力値を活用するゲームができあがります。

数値に対するプレイヤーの興味は、その価値を意識させたときに生まれるのだと思います。言葉で説明したり、ゲーム的アクションが起こる前に表示しても価値が見えません。価値が見えないうちはゴミ情報ですから、見れば見るほど眠くなる、興味を無くす恐れがあります。

数値への興味がないところから始まる

ツールと向き合うシナリオ作者の目の前には、編集項目がありますから、値の設定を考えることにエネルギー注ぎます。そのことに疑問を抱きません。私はここが気になります。

思ったのは、能力値というのは数値であって、それ自体にはゲームプレイヤー側が興味を持っていないということです。シナリオ作者とは入り口が違います。

例えばジャンケンゲームに「勝率」というパラメータを作るとします。これが何を表すかは分かりますでしょうか。私は二つの意味を想像しました。

「勝率」パラメータの意味

ジャンケンに勝つ確率
ジャンケンに勝った確率

同じ勝率という名前のパラメータでも、上の二つの意味は違います。前者は今後の勝率に影響し、後者は実績を表すのみで今後の勝率には関係ありません。

Desigeonでは身近に設定項目があり、すぐに設定できますから、こういったことを考えて入力するだけで終わってしまいます。

ですが私は、勝率というパラメータを上のどちらの意味として使ったとしても、ジャンケンをするときのプレイヤーはそれについて興味を持たないと思います。特にゲーム開始直後はそういう傾向がありそうです。

興味を持ってもらえないことを序盤に提示して、プレイヤーにいい影響を及ぼすとは考えにくいです(※1)。

プレイヤーは操作することに興味がある

ジャンケンをするときのプレイヤーは、武器であるグー・チョキ・パーいずれを出すかを考えます。このとき、グー・チョキ・パーという情報に比べて、単なる「勝率」という数値は相対的にどうでもいいはずです。

では実際にジャンケンをするとき、以下のように表示されていたらどうでしょう。

チョキ：６０％
グー：８５％
パー：２５％

今度はパーセント値を表示しました。

ですが注意です。ここでは「それが何の数値であるか」を伝えていません。

数値の意味は示していませんが、グーチョキパーを選ぶ際にこれが表示されていたら、プレイヤーとしては意味が気になりませんか？

数値の意味が気になったら、プレイヤーは自ら意味を調べるか、試行錯誤して数値の意味を理解しようとするはずです。興味を持ってもらえるなら、数値を表示する意味があるし、数値の詳細を作者が定義する価値が出てきます。

操作に必要な数値であるか

私が思うに、能力値というものは「操作に必要な（有用な）情報であるか」という見地が欠けると、プレイヤー向けの大事な目的を見失うのではないかと。

ゲームを象る「前提情報」として実装すると、あまり役に立たないのだと思います。

例えば、操作が絡まず失敗しやすそうな動機づけが以下の例です。

定義の時点で「操作」を意識しておらず、これだけ考えても失敗しそう

戦士は筋力が高い
盗賊は器用が高い
魔法使いは知力が高い

戦士の筋力が高いことは、その通りなんでしょう。そう設定すればいいのだと思います。

ただ、戦士の筋力が高いことを伝えること自体は目的ではないですよね。作者の脳内世界を伝える場所はゲーム全体であって、事前のマニュアルやキャラクタ情報シートの中ではないと思います。

プレイヤーが戦士という駒を使って操作するとき、筋力の価値を実感させることができれば、「戦士＝筋力」の印象が定着して、筋力を見たり育てたりすることが目的になりうるのです。

プレイヤーは操作に興味がある

ゲームを遊ぶ際にプレイヤーが興味があるのは、操作の概念だと思います。入り口に立ったプレイヤーの頭には、数値の価値にも育成にも興味がありません。

ゲームのどこかに「筋力」と表示されていることは知っていても、それが弓矢のダメージに影響があることを認識するのは、操作に慣れてからです。

まして、筋力５がどれほど大事な数値なのか、３じゃダメなのか、６あればゲームをクリアできるのか、学ぶことは不毛ですし無理です。

同じことは、固有名詞を割り当てるアイテムやコマンドにも言えると思います。剣がないと殴れないから、剣を買うわけです。ファイアボルトを撃たないと勝てないから、撃つわけです。剣やファイアボルトの存在を伝えること自体は、目的ではないわけですから、事前に伝える情報としては慎重になるべきだと思います。

ゲーム側の分かりやすいリード

おそらく、Desigeonのような数値論理ゲームにおいて、分かりやすいリードの仕方は以下のような感じになると思います。

オークが現れた！

行動を選んで下さい：「攻撃(筋力５)」「ファイアボルト(知力３)」「ポーション」
- 「攻撃」を選びます
攻撃するには武器が必要です。どれを装備しますか？「剣（威力３）」「斧（威力４）」
- 「剣」を選びます
オークを剣で殴った。３ポイントのダメージを与えた！

何が言いたいのかというと、能力値も武器もコマンドも、操作ほど重要ではないということです。

ご覧の通り、筋力５はコマンドを選ぶときに知ることができれば充分です。武器も攻撃するときに選べればいいのです。事前に店で選んでもらう場合よりも、簡単に興味を持ってもらえそうです。

まとめ

専門性が高い能力値の仕様やコマンドの仕様は、操作しながら学習する形を選べるようにすべきだと思いました。プレイヤーが理解する前に表示すると、つまらなくなって眠気を誘う恐れがあります。

学習というのは、単にテキストを置いておくというだけのものではないのだと思います。必要なときに必要な情報を表示することを指すのだろうと。

プレイヤーが慣れてくれば、それ以降はアイテム収集やキャラクタ育成を能動的にやってくれるはずです。そこから先は、シナリオ作者の皆さんが趣向を凝らすダンジョン探索ゲームの本領が発揮されるんじゃないかと思います。

※1 私はツールを使って能力値の設定を考えるだけでも楽しいですし、データを弄ることを楽しむこともDesigeonの目的の一つです。ですがツールとして欲しいものは編集の娯楽性だけではないので、今回はプレイヤーに向けた表現という観点で能力値の位置づけについて考えてみました

Version 1.74の予定

2010-03-22T08:53:00.002+09:00

以前からアナウンスしていた、計算手順の新仕様を何らかの形でスタートさせることを目標にしています。

一度にたくさん進めることができないので、いつできるかわかりませんが、全体としてやりたいことを詰めていくと、結局はこの辺の需要に行き着いてしまい、他にやれる機能があまりありません。

もうちょっと具体的に、どんなことを考えているかは2010年3月13日の記事「詳細イベント機能の開発」に書いたことがあります。

はじめは、その計算手順を実行できる箇所が少なく、それほど役に立たないのですが、これはイベント定義への基礎をなす部分なので、まずは動かしてみたいと思います。

いずれは以下の変化を見込んでいます。

迷路イベントで細かい指示を出せるようになる
迷路エリアの各率を計算手順化
コマンドの各要素を計算手順化
コマンドの各条件を計算手順化
コマンドの実行内容をイベント化
戦闘の各場面でイベントを挟む
街でイベントを実行する
施設でイベントを実行する

新計算手順を実行できれば、上の要素について、既存の設定から置き換えていく作業は順調に行くはずです。

イベント命令自体の充実についてはまた別の課題があります。特に、メニューや画像に関する命令にどんなものを用意したらいいのかという点が課題です。

それに先だって、メッセージの表示形態も決めねばなりません。現在のようにプレーンテキストを固定サイズで表示するのみでは格好良く飾れないので、どんな風に画面指示すべきかと頭を抱えています。

他にも、ここ一年ちょっとのバージョンアップでなおざりになっていた編集ツール画面の見直し等も少しやりたいと思っています。機能を強化すると、その分、インターフェースも慎重に整理しないとかえって使いづらくしてしまいますね。

Version 1.73

2010-03-20T04:33:00.009+09:00

コマンド習得条件の設定に関する変更

コマンド編集項目のうち、習得条件の設定の方法を変更しました。コマンド編集画面の習得条件ボタンを押すと、ダイアログボックスが起動するようになっています。

使い勝手が変わりましたが、機能はほとんど同じです。

また、これまで成長画面にあった習得条件の「他コマンドレベル」は、今回設けた習得条件のダイアログボックス側に移動しています。成長画面側にも残してありますが、古い方を使うメリットは特にありません。

コマンドの習得条件には、排他コマンドを指定できるようになっています。これを使うと、Aを覚えたときにBやCを忘却させることができます。

改修

マップ編集画面のイベント条件「19.アイテムを持っている(荷物＆装備)」のアイテム数判定を正しく行わない
宝箱の出現アイテム2設定に設定したアイテムについて、ゲームでは未鑑定で出現するはずのアイテムが鑑定済みで出現する
宝箱の出現アイテム2に設定したアイテム候補が、ゲームではすべて出現する（本来はいずれか一つをランダムで選ぶ）

その他

最近、内部的にいろいろ変更しているので何か悪い影響が出ているかもしれません。試してみて気づいたことがありましたら、遠慮無く掲示板・メール等でレポートお願いします。

作り中の機能については少しずつ出していきたいのですが、動作検証が不足していて、設定をあえてマスクしているという状況です。どこかで出していきたいとは思っていますが、はっきりと予定を示すことが出できません。

さまざまな変更は、内部的にはだいぶ適用されています。それが既存の機能に影響を与えていないか、動作確認をすることも前進になるので、もし余力がありましたらいろいろお試し下さい。

メッセージをWebブラウザで表示するテスト

2010-03-18T01:07:00.007+09:00

ゲームメッセージをWebブラウザで読んだらどうなるんだろう、という試みです。

ゲーム中に出てくる「説明」等の長文メッセージを、きれいなスタイルに置き換える一つの手になるかもしれません。以下はトラップ画面。

ここで「説明」を実行すると本来は「helptrap.txt」を表示しますが、かわりに「helptrap.html」を置いておき、それを表示してみました。中身は普通のHTML系文書です。

こんな風に、埋め込まれたIEがレンダリングします。IEの内包機能はほとんど使えるはずです。

フォントサイズや色設定をどう反映させるか、一発目の起動が遅い、といった課題はありますが、少ない仕事量でブラウザの表現力をそのまま利用できることには意味があるかもしれません。

プレイヤーに、ブラウザでマニュアルを開いてもらう手もありますが、フルスクリーンなら埋め込み式の方が使いやすいと思います。

どうにもならない問題として、プレイヤー環境におけるIEの設定をそのまま引き継ぐ点があります。カスタマイズしまくりのIEが入っていると、シナリオ作者が考えた通りに表示されないことがあります。

使えるかなあこの手。

つぶやき環境はTwitterの方向で

2010-03-17T00:03:00.007+09:00

さほど重要ではない、短いコメントを垂れる場所としてはやはり、Twitterがいいかなあと。Desigeon専用のアカウントでやろうかなと。

Twitterは扱いづらい問題も含んでいるのですが、ユーザー数が多いことが選びやすい理由です。すでにアカウントをお持ちの方もいらっしゃると思います。

といっても読むだけならTwitterアカウントは必要なくて、最新の内容は公式サイトのトップにリレーして、埋め込みブログ的な使い方をしてみます。ですからTwitter側のブックマークは不要です。

今後、小さい発言はTwitterに回そうかなと。アカウント公開のおりには公式サイトで通知します。

Desigeonアカウント側が皆さんのつぶやきを受け取るかという点については未定にしています。Desigeonユーザーが多いわけでもないのでどちらでも良さそうな感じですが、既存のアカウント(kumakyotaroアカウント)で受信する手もありますし、あとで考えようかと。

候補としては他に、はてなハイク、Timelogなどがありました。

掲示板は引き続き必要です。意志のやりとりは主にそちらでやりたいと思います。メールでもOKです。

Twitterは聞き流せる程度の呟きとか、生存表明とかに向きますが、積極的なコミュニケーションには向かないので、そこは掲示板でやりたいと思います。

長い論述や、資料的な投稿は当ブログでやっていきます。

Version 1.72.01の予定

2010-03-15T21:37:00.003+09:00

今考えている新機能（計算手順やイベント）については、何日か時間をかけたところで終わるようなものではないので、先に不具合を片づけて、次バージョンは新機能なしで行こうと思います。

イベント等はもともと、年単位で狙いを定めるつもりだったので、焦っても仕方がないかなあと。暇さえあれば作るぜ！の連続でできるようなものじゃないですな。

ここ何日か、新機能の仕様検討を行ったり、Diseardryのチェックをしたり、幼児の世話をしたり、方々にアカウントを作って各サービスを試したり、料理をしたり、ウェブサイトのページデザイン調整をしたりしていました。ろくにやれていないのが掃除と仕事です（ダメじゃん）。

あとネット関係ですが、ブログの次は、Twitter風のつぶやきorメモサービスの選定に入ろうと思っています。

Desigeonのキャッチーな紹介を考える

2010-03-13T21:30:00.004+09:00

Desigeonの紹介キャッチを考えています。だいたい以下の要点を押さえつつ。

紹介はわずかな画像とわずかなテキストで形成
分かりやすくツボを得やすそうな紹介（主文において曖昧な言葉を避ける）
すべての特徴を語る必要はない

いい案ないかなあ。

能力値を計算しよう

能力値を増やしたり計算できることが強味みたいなので、その辺をちらっと見せる案。

コマンドのスペシャリスト

キャラクタには職業設けることができて、それぞれに専用のコマンドを割り当てるところ。

ばらまくアイテム

迷路のアイテムとかを定期的に入れ替えできるので、そのことを。

その他

あと、モンスターの思考と、迷路の簡便エディットについて言及するのがいいかなと思っているんですが、いい言葉が浮かばなくて。

詳細イベント機能の開発

2010-03-13T03:26:00.001+09:00

イベント命令の体系を整理しようとしているんですが、いやはや、凄まじい分量ですのう。

方針を決めて作り始めると早い気はするのですが、どんな命令を用意すべきか考えるだけで相当な時間を食われるので、決めるまでが長そうです。

とりあえず、分類を大きく二つに分けて、実装段階も分けようと思っています。

OSリソースが関わらない命令（条件分岐、キャラクタデータ更新など）
OSリソースが関わる命令（画像表示、メニュー表示，BGMなど）

要は、画面とファイルが関係しないところから、命令を揃えていこうかなと。

テキストメッセージについては画面が絡みますが、これだけはないと何もできないに等しいので、さしあたり現在のメッセージと同じ形で、単行および長文の二通りは表示できるようにしたいと思います。課題は書式かなあ。メッセージ中に変数を埋め込めないと。

イベントプログラミングはフォーム入力で

イベントプログラミングはフォーム入力でやる形を考えています。

外部スクリプトと内部スクリプトも検討しましたが、シナリオ作者のデバッグの関係で、利用者的にもツール的にも荷が重いと感じています。

このあたりのことはアンケート結果も参考にさせていただきました。

ループと配列を避ける構造

ループと配列を意識しなくて済む仕様を目指しています。ということは、これらを使いたくても使えないことになります。

オブジェクト集団に対する処理は、選択と更新という二つの命令群でやるつもりです。例に挙げると、次のような感じです。

選択命令：荷物からすべての“盾”アイテムを選ぶ
更新命令：選んだものを荷物から消す

選択命令によって選び、更新命令によって反映させるという形をとります。

ループと配列がありませんので、あまり複雑なことはできません。例えばパーティ（キャラクタ配列）や荷物（アイテム配列）に対する反復処理ができないということです。「ア」という文字を名前に含むアイテムがいくつあるか、カウントできないわけです。

選択命令に用意されている方法以外の形では選べません。

迷路の自動生成をやりたかったり

個人的には迷路の自動生成をやりたいのですが、これをやるには外部スクリプトの力がいります。そこに辿り着く頃には老人になっているかも。

一人で作品を作るだけなら簡単なんですが、ここまで複雑化したDesigeonで外部IFを定義するのは作業量の都合で現実的ではなさそうです。やるなら新システムですね。

最後に、構造体を公開してDLLコールする手は残されています。これはC/C++を書くのと変わりませんが、実は開発環境を持っている人にとって一番安全・確実であったりします。IDE側のデバッガを使えるのが大きい。

迷路の自動生成なんて欲しがるのは私だけかもしれないし、自分専用でやってみようかとか。

独自のグラフィクス・システムを実現できる可能性が高いのもDLLですね。戦闘や迷路のレンダリング担当がDesigeonである必要はないわけで。まぁ、.NET Frameworkの時代に今さらという気もしますが。現実的な実現手段ではあると思います。

コマンド習得に関する仕様変更の予定

2010-03-12T02:15:00.006+09:00

コマンドの習得を判定するタイミングに関する仕様変更の話です。

コマンドの習得タイミングは現在、ゲームロード時、キャラクタ作成時、成長ポイント割り振り時、レベル変化時、転向時、能力値やステートが変化した時に判定するようにしています。

能力値の変化時にコマンドの習得判定をせず、各ターンの最後で判定する

能力値やステートが変化した際に習得判定している部分については、判定を無くそうと考えています。

かわりに、各ターンの最後で判定を入れようと思います。

このように変更する主な理由は、動作パフォーマンスによるものです。今のままではHPを1減らすだけでも全コマンドの習得条件をチェックしなければならず、とても動作効率が悪いのです。今の動作水準を維持できるなら問題ないのですが、将来的に判定機能を強化することができません。イベントを複雑化できないことになります。

この結果、判定する箇所は以下の通りになります。

ゲームロード時
キャラクタ作成時
成長ポイント割り振り時
レベル変化時
転向時
各ターンの最後（ステートの影響後）

この変更によって、既存シナリオの中ではDiseardryに微妙に影響が出るかもしれません。イベントでの能力値の変化によって習得判定しているため、若干、習得メッセージが表示されるタイミングがずれる可能性があります。

コマンドの習得を計算手順で判定

上の件とは別に、コマンドの習得は計算手順の計算結果によっても判定できるようにします。計算手順で判定することができれば、必要能力値の制限数が問題にならなくなったり、標準値以外の能力値（例えば最終値。ステート込みの能力値など）で習得を判定できるようになります。

計算手順のような動作コストへの影響が想定できない判定をするとなると、現状の動作パフォーマンスが問題になります。だから前述の対応を入れることになりました。

いずれ、詳細なイベントを指示できるようになった際に、「コマンドの習得を判定する」命令を盛り込もうと思っています。

コマンドの排他機能

ステートの排他機能と同様、コマンド習得時に他のコマンドを忘れる機能を足します。

今でもコマンド習得条件に「他のコマンドレベル必要値」を指定できるようになっていて、そのとき条件にしているコマンドを忘却させる機能があります。これを使うと、コマンドの世代交代（アップグレード）ができます。

現在は２世代までしか対応できないアップグレードですが、この機能をコマンド全体に広げるような感じです。条件の有無に関係なく、Aを習得するとBやCを忘れるような設定ができるようになります。

Version 1.73の予定

2010-03-10T22:59:00.002+09:00

v1.73では、いくつかの問題対処の他、コマンド習得条件を編集画面から分離したいと思います。

現在、コマンド編集画面に貼り付けることができるWindowsボタンの数はあと１個です。コマンド編集画面の外に設定を追い出さないとどうにもならないので、整理を始めることにしました。

コマンド編集画面の整理は、客観的なメリットがほとんどない割に、私の作業量的には大きいのですが、どうにもならないコマンドの現状をなんとかするためは必要になってきます。

現在の想定では、この対応によってWindowsコントロールの空きが14個程度できるはずです。
14個空いても、追加できる機能はたかが知れてるんですが、やらないよりはいいかなと。

空いたら、その後のバージョンで、一部のコマンド設定に計算手順を足していこうと思っています。

速度
実行回数
消費能力値量
消費アイテム量
威力B
自動起動の発動率
射程
遅延時間

14個空いただけではとても無理。時間がかかりそうです。

この他、新計算手順仕様を発進させるかもしれません。埋め込む場所はアイテム称号の出現規則と、エリアの生成物件のところが候補で、まだ絞れていません。

外道な思いつき

2010-03-10T01:14:00.005+09:00

以下は過去に、さまざまな経緯で思いついた機能です。欲しいなとは思いつつ、機能番外編という感じの存在で、作っている機能ではありません。

それぞれは面白そうなニオイはするんですが、汎用機能として入れるには特徴が出過ぎていると思いました。こういうものをカスタマイズできるスクリプトシステムとか、イベントシステムなりが備われば、作ってみたいです。

キャラクタのアイテム封印

エネミー等のキャラクタをアイテムに変換する、もしくはアイテムに封印する機能です。使い道は以下のような感じです。

あとで使うと、封じてあったモンスターが仲間になる
コレクターズアイテム。ドラゴンのカードやスライムのカードなど
使うと、封じされているモンスターに応じて効果が変わる
仲間を一時的にアイテムにして持ち歩く

細かく検討したことはありませんが、何かをアイテムに封印する行為自体はそんなに難しくないのだと思います。封印したエネミーの名をアイテム名に反映したり、価格や重量に反映する仕様を考えれば、すぐにでもできそうな感じです。

ただ、問題はアイテムに封印したあとの使い道です。上の用途はどれも、アイテム個体とは関係のないところで難しい都合を抱えていそうです。

かなり外道な使い道ですが、最後の用途だけは作るのが簡単そうです。

アイテムの時限変化

時間が経つとアイテムが別のアイテムに変わる機能です。機能としては、アイテムが別の存在に切り替わるというだけのシンプルな内容ですが、使い道はたくさんありそうでした。

食べ物が腐る（アイテムの使い惜しみ防止）
植木鉢から芽が出て、やがて実がなる（重くても辛抱強く持ち歩いた者勝ち）
時間と共に強くなったり弱くなったりする武器（昼の顔、夜の顔）
一時的にゴミに切り替わって、捨てて良いものか分からなくなる意地悪なアイテム
時間が経つと装備者に吸収され、ステートになる

これはわりと良いところまで実装を考えたんですが、Desigeon的には、アイテムの寿命開始時期を厳密に定める取り組みが難しいので未定になっています。これは、床のアイテムや宝箱の中身はいつ作るのが正しいのかという問題です。対策として、店販売アイテムおよびモンスタードロップアイテム専用の機能にするなど、制限付きの機能にする手もあったんですがぱっとしないなあと。

装備アイテムへのステート付与削除

店やコマンドを通じて、装備アイテム側の提供ステートを増減することを考えました。

装備アイテムは現在、装備者にステートを提供することができます。これをあとから付け外しできないかなあと。

ステートは、キャラクタ（ＰＣまたはエネミー）の体に付与する要素ということにしてあります。キャラクタ以外に付与する使い方を始めると説明が難しくなるので、アイテム搭載ステートはアイテム内には存在せず、装備中だけ主人の体内に作っておくというイメージで機能を作ってきました。

もし、ゲーム内の聖職者や鍛冶職人が、武器や防具にステートを封入したり剥がしたりできてしまうと、ステートの役割が曖昧になり、初見の利用者に対する説明が難しくなる恐れがあります。また、ステートの機能を流用すると、アイテム評価額や重量については加工することができず、使い道がかなり限定されます。そうした理由から避けてきました。

今後も、アイテム側のステート着脱は避けようと考えています。アイテムにはアイテム専用の加工方法を考えていきたいなあと思っています。

宿屋と病院の切り離し

宿屋病院などという、曖昧な名が付けられている施設がありますね。

私は以前から、ドラゴンクエスト型の簡易治療施設がないことが気になっていました。その内容は、ゲーム中に、施設を利用するかしないかを二択で決めて、それ以外の使い方をせず、利用した場合は一定の効果が出るというものです。

現在の宿屋病院は、ウィザードリィのカント寺院をモデルにしています。カント寺院をDesigeonのルールに照らして作るなら、ああいう風にするしかないと思いました。ただ、今のものは機能が複雑に感じます。

そこで、宿屋と病院を切り離して、病院は今の宿屋病院を引き継ぎ、宿屋というただ泊まるだけの施設を追加できればなあと思っています。

施設の増設は勇気が要ります。画面をデザインするのが面倒でのう……。

壁を壊す、壁を作る

壁を壊したり作ったりする機能です。できてもいいだろうなと。

でもDesigeonの迷路は一度壊すと、戻すメソッドを用意しない限り一生壊れたままです。つまり壊す一方だと、いつか壊す対象そのものが枯渇してしまうのです。

そこで最生成のファクターを提案する必要が出てきます。壊す機能を作るのは簡単ですが、迷路の最生成を指示する機能は大仕事になります。

壊す方も作る方も、作品としては過去に作ったことがあるので難しくはないのですが、そのときは迷路を自動生成するゲームでしたので問題にはなりませんでした。

売却アイテムを店に残す

店に売ったアイテムを店の商品として残すか、という話です。元ネタはウィザードリィです。

これは機能として考えたというより、機能に存在価値を見いだそうとした感じです。

剣や薬草を店に売って、それを陳列しっぱなしにしておくメリットにはどんなものがあるだろう、と。アイテムコレクションが目的なら、コレクション専用の機能を考えていった方が楽しいんじゃないか、とか。

そんなことを考えていたら、結局、売却品を店に在庫として残し続ける決定的な理由が見つかりませんでした。

ローグライクのElonaというゲームでは、売却したアイテムが店に陳列されますが、時間が経つと消えます。時間が経つと消えるからこそ、陳列する機能を実装した感じがします。Elonaでは実際にプレイヤーの私が買い戻すことはほとんどありませんでした。

時間が経つことで戦闘開始、あるいは定期的にエネミー来襲

持っているアイテムや持っているステートが、時間切れでエネミーパーティに変わり襲って来るというものです。

使い方としては、上で述べたアイテムの時限変化や、現在あるステートの時限変化を利用することになります。

時限変化を利用するため定期的に実行することもできるので、対処をしない限り何度でも主人公を襲うようなこともできるはずです。

この案は、戦闘中に発動した場合の仕様が課題になるのですが、その先を考えていません。

レベルアップ遅延と成長ポイント割り振り先のカテゴライズ

2010-03-08T23:09:00.005+09:00

掲示板からの抜粋記録です。

細かいやりとりは手元のメモで済ませていますが、広い範囲をカバーする内容のときはメモとしての維持が難しくなるので、そのまま保存した方がいいかなあと。

No. 1184 - Re: v1.64をアップ
投稿者 : Tawres

更新お疲れ様です。報告などを。
成長ポイント割り当てを制限すると、プレイ中の成長ポイント割り当て画面にその項目が表示されません。バグかもです。

あと結構重大なことに気づきました。LVアップ時のボーナスポイントを制限できるようになったのはいいのですが、LVアップしたときに割り振らなかった分を後のLVアップで補填できてしまいますね。

例えばLVアップ時のボーナスポイントが10、制限値が5の状態だとします。戦士キャラなので「力」と「生命力」に毎回5ずつ割り振るような成長戦略を選択していたけど、意外と「素早さ」が重要だとあとから気づいた。などというときに次のLVアップで10ポイント全てを「素早さ」に割り振ってしまうことができます。これだとキャラ作成初期に成長の方向性を意図する動機付けが薄れてしまいます。

その時点での能力の上限値＝LV×制限した値、という仕様のようですね。毎回「制限した値以上には割り振れない」という風にはできないでしょうか。

こんなこと気にしてるのはぼくくらいかもしれませんが、検討してみてください。お願いします。

書き込み日時：2009/11/30(Mon) 22:44:06

No. 1187 - 成長ポイントの割り当て制限機能
管理人 : 熊恭太郎

こんばんは。お試しいただけたようで嬉しいです。

成長ポイントの割り当て制限機能については、基本能力値ボーナスのものとほぼ同じにしてあります。これはレベルアップごとに制限値を増やしていく(割り振っていない分は累積する)機能です。

あくまで低レベルキャラクタの能力値を一部に集中させないための機能ですので、高レベルになればどの能力値にもたくさん割り振れるということにはなっています。

あとでツールの中でも補足したいと思います。

> 成長ポイント割り当てを制限すると、プレイ中の成長ポイント割り当て画面にその項目が表示されません。バグかもです。

既存のセーブデータについては、すでに成長ポイントの余りを持っている場合でも、制限している項目に対する割り当て可能数はゼロです。一度レベルアップを果たして下さいませ。

キャラクタのレベルアップはデバッグメニューからできます。

そしてバグについても気づきました。キャラクタ作成直後のキャラクタには、制限付きの項目に成長ポイントを割り振れません……。この問題については、レベルアップ時と同じ制限値を適用してみます。上のご指摘はこちらの問題かもしれません。

> その時点での能力の上限値＝LV×制限した値、という仕様のようですね。毎回「制限した値以上には割り振れない」という風にはできないでしょうか。

分かりました、オプションで用意することを考えてみます。この件は解釈が二つあるのですが、以下のうちどちらになりますでしょうか。

1. キャラクタ作成直後およびレベルアップごとに最大Nポイントの割り振りを可能とする
2. キャラクタの生涯を通じて合計Nポイントの割り振りを可能とする

前者については、レベルアップごとに制限値にリセットをかける機能になります。

これを採用した場合、ゲームで成長ポイントの割り振りを先延ばしすると、プレイヤーに不利が生じることになります。

そしてポイントの割り振りを先延ばししすぎると、ポイントが余って割り振り先がなくなる恐れも出てきます。
レベルアップしたら忘れないうちに振っておかないとなあトカ(^^;
経験値を貰いすぎて、一気に１０レベルとか上がってしまう場合は……ご愁傷様です(笑

後者については能力値自体に上限を設定できますので、必要性はあまりないかもしれません。上限に達した能力値やコマンドは、自動的に割り振りができなくなります。

成長ポイントだけで成長させる能力値については、能力値側で上限を設定する方が便利だと思います。
しかしアイテム・イベント・コマンドによる成長値アップダウン（いわゆるドーピング等）も同時採用する場合は有効、ということになると思います。

書き込み日時：2009/12/1(Tue) 21:11:07

No. 1188 - Re: 成長ポイントの割り当て制限機能
投稿者 : Tawres

> 既存のセーブデータについては、すでに成長ポイントの余りを持っている場合でも、制限している項目に対する割り当て可能数はゼロです。一度レベルアップを果たして下さいませ。

おお、データリセットしてレベルアップしたらできました。ありがとうございます。

> そしてバグについても気づきました。キャラクタ作成直後のキャラクタには、制限付きの項目に成長ポイントを割り振れません……。この問題については、レベルアップ時と同じ制限値を適用してみます。

なるほど、了解です。

> > その時点での能力の上限値＝LV×制限した値、という仕様のようですね。毎回「制限した値以上には割り振れない」という風にはできないでしょうか。
> 分かりました、オプションで用意することを考えてみます。この件は解釈が二つあるのですが、以下のうちどちらになりますでしょうか。
> 1. キャラクタ作成直後およびレベルアップごとに最大Nポイントの割り振りを可能とする
> 2. キャラクタの生涯を通じて合計Nポイントの割り振りを可能とする

2はおっしゃるとおり、能力の上限値の設定で可能ですね。ぼくが想定していたのは1です。それで

> これを採用した場合、ゲームで成長ポイントの割り振りを先延ばしすると、プレイヤーに不利が生じることになります。

これは「先延ばしはダメよ」と説明に書けばいいかと思ってたのですが

> 経験値を貰いすぎて、一気に１０レベルとか上がってしまう場合は……ご愁傷様です(笑

これはシャレにならないですねえ（笑）。一応理想を言うと「現在の上限値＝割り振り作業をしなかったレベルアップ回数×制限値」ということなんですが…。1ポイントだけ使って、残りボーナスを残した場合とかを考えると、ちょっとややこしいですよね。

で、ぼくが理想とするWiz8を久しぶりにプレイして思い出しました。Wiz8ではレベルアップ作業自体が「一回ずつ」なのです。一定経験値に達したら「能力値を上げる画面→スキルを上げる画面」という流れを「レベルアップボタン」をクリックすることで一つずつ行うという。二回分の経験値がたまってたら二回連続でレベルアップ作業を行うだけなので、制限値の問題は発生しないわけです。また、ボーナスポイントを残すと割り振り画面から出れません。Desigeonとはずいぶん違う仕様なのに、またワガママ考えてたもんです；

個人的には「絶対的」制限機能は欲しい、けど大量経験値で何度もLVアップ、というのもRPGの華だと思う。うーん…さすがに優先度が高いのは後者のような気がします…。

一応「ボーナスポイントに手をつけたかどうか」を判定することができたら、上記の「現在の上限値＝割り振り作業をしなかったレベルアップ回数×制限値」が可能かもしれませんが。ややこしいハナシなので見送ってくださっても構いません。

書き込み日時：2009/12/2(Wed) 01:30:34

No. 1189 - Re: 成長ポイントの割り当て制限機能
管理人 : 熊恭太郎

> 一定経験値に達したら「能力値を上げる画面→スキルを上げる画面」という流れを「レベルアップボタン」をクリックすることで一つずつ行う

それならこれをそっくりそのまま、あるいは類似の機能を作るというのはいかがしょう。

今は成長ポイント割り振りのメニューが出ているところを、「レベルアップ」とかに変えればいいんですよね。

成長ポイントという概念はプレイヤーに示す必要はなくて、単に成長させる項目が示されて、選んでもらって、それを終えたら成長ポイントは残らない。繰り越しはなし。

経験値が１０レベル分溜まっていたら、１０回レベルアップの作業をしてもらえばいい、ということで。

手動でレベルアップ判定するなら経験値が溜まっていることを何らかの方法で、プレイヤーに伝える機能を考えたいところですね。

そういえば旧ウィザードリィではそこの所、あまり考えられていませんでしたが、宿屋に泊まるという誰でもやる行為の中にレベルアップ判定を組み込んで、ある程度解決を図ったんですよね。

書き込み日時：2009/12/2(Wed) 22:27:16

No. 1191 - Re: 成長ポイントの割り当て制限機能
投稿者 : Tawres

> それならこれをそっくりそのまま、あるいは類似の機能を作るというのはいかがしょう。
> 今は成長ポイント割り振りのメニューが出ているところを、「レベルアップ」とかに変えればいいんですよね。
> 成長ポイントという概念はプレイヤーに示す必要はなくて、単に成長させる項目が示されて、選んでもらって、それを終えたら成長ポイントは残らない。繰り越しはなし。
> 経験値が１０レベル分溜まっていたら、１０回レベルアップの作業をしてもらえばいい、ということで。

すごい、可能なら希望通りです。基本能力値グループのボーナスと、手動成長値のボーナス、いずれにもその作業ができればもはや言うことはありません。ただぼくの求めているものは少数派だと思うので、Desigeonのデフォルトにするのはマズイですよね。その仕様をスイッチできるようにするのは大変じゃないでしょうか。

> 手動でレベルアップ判定するなら経験値が溜まっていることを何らかの方法で、プレイヤーに伝える機能を考えたいところですね。

Wiz8では戦闘後に「レベルが上昇した」というメッセージが出て、ステータス画面のキャラの顔の端っこに＋マークのアイコンが表示されるようになり、それをクリックするとレベルアップ作業画面に入るようになってます。Wiz6、7も似たような感じだったかな。
> そういえば旧ウィザードリィではそこの所、あまり考えられていませんでしたが、宿屋に泊まるという誰でもやる行為の中にレベルアップ判定を組み込んで、ある程度解決を図ったんですよね。

なんで馬小屋でレベルアップしなきゃなんないんだよ、とかも思ったもんですが、制作者の都合が伝統になった一例ですよね。でも肉体関係の能力値は超回復の概念にピッタリな気もします。

書き込み日時：2009/12/2(Wed) 23:55:03

No. 1194 - Re: 成長ポイントの割り当て制限機能
管理人 : 熊恭太郎

機能はオプション設定で考えています。既存の動きは阻害しないです。

レベルアップ時の動きについては意識あわせをしておきたいです。

レベルを上昇させるタイミングと、能力値アップの作業をするタイミングに違いがあるなら、違うことを決めておかねばなりません。

【A案】
1. 経験値が必要値ぶん溜まれば自動でレベルが上昇し、各種処理をする
2. ボタンを押すことで成長ポイント割り振りの作業をする（レベルアップ処理は1で済んでいる）

【B案】
1. 経験値が必要値ぶん溜まっても自動でレベルは上昇しない
2. ボタンを押すことでレベルを上昇させ、各種処理を走らせ、その続きで成長ポイント割り振りの作業をする

Desigeonからみると、両案に違いがあります。レベルだけ先に上がるなら、成長ポイントを割り振る以外の所にレベル変化の影響が現れます。

話を伺う限りWiz8はA案のような印象ですが、話を伺う前に私が考えていたのはB案でした。

「レベルアップ」ボタンというのは、その名の通りレベルアップさせるボタンのつもりでした。でも現在のように自動でレベルが上がってしまうなら、あとから押すボタンの方は概念の異なる機能になると思います。

いかがでしょう。

書き込み日時：2009/12/4(Fri) 00:50:43

No. 1197 - Re: 成長ポイントの割り当て制限機能
投稿者 : Tawres

なるほど、あまり気にしてなかったので説明が中途半端でした。確認したらWiz8はB案の方でした。「レベルアップした！」というメッセージが出るのですがレベル表記は変化せず、＋印のアイコンを押すとHPなどの自動成長する値が上がっているのを確認できました。

ぼくの想定しているものではA案とB案でさほどの違いはありません。そもそも気にしてなかったのは自動成長と、LVを参照する手法を使ってないせいだと今気がつきました。

個人的な好みではB案ですね。メッセージは「レベルアップ可能になった」とかにすればいいですし。

書き込み日時：2009/12/4(Fri) 20:44:30

No. 1195 - 基本能力値グループのレベルアップ作業
管理人 : 熊恭太郎

今のところ基本能力値グループのレベルアップボーナスについては、一連の話の対象からは外させてもらっています。

現在、基本能力値グループのレベルアップボーナスと、成長ポイントの設定は同時採用できるようになっています。

ですが、シナリオ側が同時に採用して、プレイヤーが両者を同じように操作することは想定していません。

基本能力値グループのレベルアップボーナスは、過去の互換性のために残している機能で、機能的には成長ポイントで賄えるので、成長ポイントと同じように拡張していくことは避けています。

拡張が必要なら基本能力値グループではなく、成長ポイントの仕組みを拡張するか、あるいは新しい機能の追加を考えていきたいと思います。

もしその機能が複雑になりそうなら、拡張はやめて、イベント編集機能に流そうと思っています。

書き込み日時：2009/12/4(Fri) 00:52:29

No. 1198 - Re: 基本能力値グループのレベルアップ作業
投稿者 : Tawres

こちらの方も説明が不十分だったようで申し訳ない。Wiz6以降では基本能力値の上昇に使うボーナスと、技能値の上昇に使うボーナスを別枠でもらえるのです。それをやりたかったので、今のDesigeonの仕様が気に入っていたのです。ポイント割り振りによる上昇制限の一連の話は、基本能力値グループと手動成長（こちらをいわゆる技能値に使う）と、どちらにも欲しい要素だったのです。書き方がマズかったと思います、ほんとすみません；

まだ思考中ですが、かならずしも別枠にこだわることもないかとも思ってます。制限のシステムが理想どおりになれば、基本能力値と技能値のボーナスを統一しても問題ないかも、と。ですのでとりあえず手動成長のレベルアップ画面機能が追加されれば非常にありがたいです。

書き込み日時：2009/12/4(Fri) 20:50:13

No. 1233 - レベルアップ遅延と成長ポイント割り振り先のカテゴライズについて
管理人 : 熊恭太郎

まだできるかは分かりませんが、面白い機能だし、黙ってこっそりやるのも今さらという気がしますので、今の考えを示してみたいと思います。

関連して、表示に関するいろいろな機能が充実する話でもあるので、結構前向きに思ってます。

さて以前お話ししたとおり、基本能力値ボーナスと成長ポイントの機能は、同時に採用して同じように運用することは想定していません。成長ポイントの機能だけ一人歩きしていきます。

この他、レベルアップの判定をいつやるかというお話がありましたが、そちらの機能と合わせて考えてみました。

1. レベルアップ作業遅延 → 後述
2. 成長ポイント → カテゴリわけを求められる

ということで、両者はセットでできるようにする必要があると思います。

レベルアップ遅延については以下の通りです。

1. 経験値が溜まるとレベルアップボタンを押せるようになる
2. ボタンを押した瞬間、成長ポイント以外のレベルアップ機能が通常通り動く
3. その場で成長ポイント割り振り作業を行う。ポイントの余りは失効

経験値が溜まったことをプレイヤーに通知するメッセージを設定することになります。

これらは面白い機能だと思いますが、両者はセットで考えなければならないことと、カテゴリ分けをできるようにすることで、キャラクタ情報が複雑になり、表示に関する新たな課題を生みます。

能力値やステートの枠が不足する問題もさらに強まりそうです。

書き込み日時：2009/12/20(Sun) 14:55:28

No. 1234 - 実現までにやりそうなこと
管理人 : 熊恭太郎

ということで、やるならまず、外堀を埋めてからにしたいと思います。
具体的には以下の通りです。

・ステートに分類を設ける(※1)
・能力値に分類を設ける(※1)
・コマンドに分類を設ける(※1)
・ステートに単行説明を追加
・能力値に単行説明を追加
・成長の対象にステートをサポート
・成長の対象にキャラクタ変数をサポート
・【重要】独立したカスタム計算手順を搭載(※2)
・【重要】キャラクタ情報をページ分けして表示できるようにする(※3)
・【重要】コマンド編集画面重量化の対策
・【目的】レベルアップ遅延機能を付ける
・【目的】手動成長のカテゴリ分けを設ける

これらは、実装する順序はどうでもいいのですが、育成の機能を多機能化すればどのみち必要になります。

成長ポイントの分類ができても能力値の枠がないとか、表示スペースがショボイとかそういう話になることが目に見えてます(^^;

重要なポイントは示したとおり三点あります。

おのおのは独立して使える機能なので、ゆっくりやっていきたいと思います。

※1. 要素名の頭に、アイテムと同じような分類名を挿入するだけです
※2. 計算手順を能力値とは別に定義できるようにして、能力値の需要を減らします
※3. 多くのキャラクタ情報をシナリオ作者が指定して表示できるようにします