「ステップ」の編集履歴(バックアップ)一覧はこちら

ステップ」(2012/04/25 (水) 03:26:57) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

*ステップ &ref(http://www38.atwiki.jp/cw-hint?cmd=upload&act=open&pageid=58&file=Palette3-StepChange.png) **ステップとは -カードワースには2つの変数がある。一つは[[フラグ]]と呼ばれるものであり、もう一つはこの[[ステップ]]である。 -[[フラグ]]が状態の管理だけでなくメニューカードやエネミーカードの表示/非表示を管理できるのに対し、[[ステップ]]は純粋に状態の管理のみに使われる。 -ステップの大きな特徴は0~9までの値(デフォルトではStep-0~Step-9)を変数内部に持っていることにより、十進数で条件判定、計算(出力)などの処理を行えるということである。 -10以上の数を管理する場合は、2つ以上のステップを各桁数として組み合わせ、増加・減少のイベントを組む必要がある。 ***条件管理の概念として イベント発生条件の管理としてはフラグでほぼ代用できるが、「あるイベントをX回繰り返すと発生するイベント」といった「回数」が発生条件に含まれるときには効果を発揮する。 例として、看板を4回攻撃すると壊れてしまう、というイベントを考える。表現としては、メニューカード「看板」を4回攻撃するとカードが非表示になる。この場合、フラグを使うとツリーは フラグ1―false―フラグ1をtrueに【変更】      └true――フラグ2―false―フラグ2をtrueに【変更】                └true――フラグ3―false―フラグ3をtrueに【変更】                         └true――メニューカード「看板」を非表示 になる。フラグは3つ必要になるだろう。 比較してステップを使った場合 ステップ1―Step-0―ステップ1の値を【増加】       ―Step-1―ステップ1の値を【増加】       ―Step-2―ステップ1の値を【増加】       ―Step-3―メニューカード「看板」を非表示 と簡明なツリーを作ることができる。これは「4回」という数が十進数の範囲にある数だからである。 ***出力管理の概念として 変数の値はメッセージコンテントおよびセリフコンテント内で「$」を利用することにより参照することができる。ステップは10個の値を格納できるので、フラグよりも汎用性がある。例えば、冒険者の一人称を設定するシステムを考えてみる。 シナリオ開始時にPCごとに一人称を選択し、それにあわせたクーポンを配布する。  ↓ PCが喋るたび、人称クーポンを判定する。  「_人称:私」を持っているならばステップ1の値を「私」に【変更】する。  「_人称:僕」を持っているならばステップ1の値を「僕」に【変更】する。  「_人称:俺」を持っているならばステップ1の値を「俺」に【変更】する。 などの処理を行う。  ↓ ステップ1の値を参照し、セリフに出力する。 選択PC:「$ステップ1$としては不満なんだけどな……」 という流れになるだろう。 このとき、ステップの仕事をフラグで行おうとすると長大なイベントツリーになることは明白に思われる。 また、数の表記もステップを使うと簡明である。8回層あるダンジョン。冒険者が何階層にいるかを表現したいとき、フラグを使うと少なくとも3つのフラグが必要になる。システムも難解だ。しかしステップならば1つで済む。 ステップの利点とは、数を扱うときフラグよりも直感的であるということに他ならない。 ***ステップを使ったテクニック -汎用ステップ:一連の処理やシーンを終了すると、以降は状態の記憶が必要の無い場合に用いる使い回し用のステップ。バグの原因になりやすく、汎用フラグと比べてメリットが少ないため、シナリオ製作に慣れない内は無理をしてまで使う技術ではない。
*ステップ &ref(http://www38.atwiki.jp/cw-hint?cmd=upload&act=open&pageid=58&file=Palette3-StepChange.png) **ステップとは -カードワースには2つの変数がある。一つは[[フラグ]]と呼ばれるものであり、もう一つはこの[[ステップ]]である。 -[[フラグ]]が状態の管理だけでなくメニューカードやエネミーカードの表示/非表示を管理できるのに対し、[[ステップ]]は純粋に状態の管理のみに使われる。 -ステップの大きな特徴は0~9までの値(デフォルトではStep-0~Step-9)を変数内部に持っていることにより、十進数で条件判定、計算(出力)などの処理を行えるということである。 -11以上の数を管理する場合は、2つ以上のステップを各桁数として組み合わせ、増加・減少のイベントを組む必要がある。 ***条件管理の概念として イベント発生条件の管理としてはフラグでほぼ代用できるが、「あるイベントをX回繰り返すと発生するイベント」といった「回数」が発生条件に含まれるときには効果を発揮する。 例として、看板を4回攻撃すると壊れてしまう、というイベントを考える。表現としては、メニューカード「看板」を4回攻撃するとカードが非表示になる。この場合、フラグを使うとツリーは フラグ1―false―フラグ1をtrueに【変更】      └true――フラグ2―false―フラグ2をtrueに【変更】                └true――フラグ3―false―フラグ3をtrueに【変更】                         └true――メニューカード「看板」を非表示 になる。フラグは3つ必要になるだろう。 比較してステップを使った場合 ステップ1―Step-0―ステップ1の値を【増加】       ―Step-1―ステップ1の値を【増加】       ―Step-2―ステップ1の値を【増加】       ―Step-3―メニューカード「看板」を非表示 と簡明なツリーを作ることができる。これは「4回」という数が十進数の範囲にある数だからである。 ***出力管理の概念として 変数の値はメッセージコンテントおよびセリフコンテント内で「$」を利用することにより参照することができる。ステップは10個の値を格納できるので、フラグよりも汎用性がある。例えば、冒険者の一人称を設定するシステムを考えてみる。 シナリオ開始時にPCごとに一人称を選択し、それにあわせたクーポンを配布する。  ↓ PCが喋るたび、人称クーポンを判定する。  「_人称:私」を持っているならばステップ1の値を「私」に【変更】する。  「_人称:僕」を持っているならばステップ1の値を「僕」に【変更】する。  「_人称:俺」を持っているならばステップ1の値を「俺」に【変更】する。 などの処理を行う。  ↓ ステップ1の値を参照し、セリフに出力する。 選択PC:「$ステップ1$としては不満なんだけどな……」 という流れになるだろう。 このとき、ステップの仕事をフラグで行おうとすると長大なイベントツリーになることは明白に思われる。 また、数の表記もステップを使うと簡明である。8回層あるダンジョン。冒険者が何階層にいるかを表現したいとき、フラグを使うと少なくとも3つのフラグが必要になる。システムも難解だ。しかしステップならば1つで済む。 ステップの利点とは、数を扱うときフラグよりも直感的であるということに他ならない。 ***ステップを使ったテクニック -汎用ステップ:一連の処理やシーンを終了すると、以降は状態の記憶が必要の無い場合に用いる使い回し用のステップ。バグの原因になりやすく、汎用フラグと比べてメリットが少ないため、シナリオ製作に慣れない内は無理をしてまで使う技術ではない。

表示オプション

横に並べて表示:
変化行の前後のみ表示: