Code Monkey home page Code Monkey logo

Comments (9)

Salvadors-cabin avatar Salvadors-cabin commented on August 19, 2024

#2からの続きです。
例えば、以下のような構文で実現できるとありがたいです。
scene id="29" params="-5MP"
※シーン29に移行後にMPが5減算される。
scene id="30" spells="mNOILA-TEM"
※シーン30に移行後に全ての星-1(NOILA-TEM)が実行される。

魔法実行前に手動で星を減算していた場合は確かに悩ましいですね。
これについては、ボタンを押しても「星が不足しています」のようなトーストが出で、実行されない、が理想かなと思います。(あくまでも理想です)

戦闘の半自動化については、私としては必須ではないと思っています。
各シナリオで戦闘が多様化しているので、今からの統一は難しいような気がするのです。

from stext.

snext1220 avatar snext1220 commented on August 19, 2024

魔法減算について

scene要素で明示的に指定するか、従来の魔法条件ボタンからの移動で無条件に減算するかは、要検討かと。

[魔法確認用(HEAL)](12 "mHEAL")

前者の場合
  • ボタン側と次のシーンと双方で重複した記述が必要
  • 魔法条件ボタンとの不整合が起こる可能性あり(あくまでシナリオ側の責任)。
  • 魔法条件ボタンで減算するものとしないものがわかれる可能性あり
後者の場合
  • 重複/不整合等の問題はなし(実装については要検討)
  • 魔法条件ボタンでの移動では、無条件に減算処理(例外を許容しない)
星不足時の対応

トーストで恐らく問題はないと思います(自由移動ボタンとも同じ挙動なので、システムとして統一がとれているかと)

ステータス

  • 戴いた構文の場合、ダイスは加味しない形となり、用途が限定される?

ダイスを加味することはできるが、初期表示時なので、ダイスの振り直しもできず(あくまで反映は一度だけ)、いきなりページ下部でランダム表示されているダイスの目で、ステータスが増減するのは把握しづらそう

  • #2 でも出ましたがステの自動反映を適用できるのが、ごく限定的な状況になるため、プレイヤーの混乱が心配(慣れと言えば慣れですが…積み重なると、結局、ルールの複雑化を招くので、原則避けたい)
  • 以前からの問題ですが、ステータスが勝手に変動するので、プレイヤーが把握できなくなる可能性あり。結果の表示は要検討(そもそもHP、MPが0以下になった場合?)

半自動化について

上記のような問題を受けての半自動化でした。

こちらでは、明示的にボタンを押してステータスを反映させるので、ルールはある程度まではシナリオ側で自由に変更できます(たとえば複数回押せば、繰り返しダメージを発生させることができます)。
# 基本、新・王杖/ゼロレベルであれば、問題なく対応できるはず

ステータス反映結果の表示方法について要検討なのは、同様です。

from stext.

Salvadors-cabin avatar Salvadors-cabin commented on August 19, 2024

魔法減算について

私の意見としては、「後者」押しです。

ステータス

私の意見としては、「ダイス値は加味しない」です。
ダイスのランダム要素を入れてしまうと、分岐後の状態が不定になるのでシナリオからコントロール不能になってしまうからです。

以前からの問題ですが、ステータスが勝手に変動するので、プレイヤーが把握できなくなる可能性あり。結果の表示は要検討(そもそもHP、MPが0以下になった場合?)

分岐表示にはパラメータの残量条件(例:"oMP4+")を入れられるので、ランダム要素がなければHPやMPが0以下になるかどうかも想定して分岐後のストーリーを作成できると思います。

同じ画面で何度もボタンが押せる「戦闘の半自動化」では、HPやMPが0以下になった場合の表示ができないのでこの問題が発生すると思います。そういう意味で、「分岐後のパラメータ自動変更」だけを要望しています。

あと、ステータスの変更はHP,MPだけでなくFREEも変更したいです。私のシナリオ都合で申し訳ありませんが、FREEをGP(金貨枚数)として転用したいと考えています。(つまり、GPに適用したい、という意味です)

from stext.

snext1220 avatar snext1220 commented on August 19, 2024

HP/MPの自動換算については悩ましいところでして。

固定的なMP10減算などの状況は限られるため、(たとえば)同じようなトラップダメージでも、自動/手動が混在してしまいそうで(要はダイス判定の要否によって対応が割れる);
先述のようにルール混在は避けていきたいので、対応するのであれば半自動で統一化を図っていきたい、という趣旨でした。

HPやMPが0以下になった場合の表示ができないのでこの問題が発生すると思います。

こちらについては、先述の通りでして、
ゼロ問題に関わらず、半自動ボタンクリック時になんらかの結果フィードバック(トースト表示?)が必要になると考えています(意図しない二重押し防止が目的)。

HP/MPがゼロになった場合については、これまで通り、システム側では対応せず、文章中で「戦闘でHPがゼロになった場合は~~~へ移動せよ」のような指示になっていくのかと。

余談

free1、2属性を追加した時に、合わせてstr、int、dex、krmなどの属性も追加しようと思ったのですが、こちらはシナリオ中でもさほど頻度が多くないと思われるため、見合わせました。リクエストがあれば検討したいと思います。

from stext.

RYU-DS avatar RYU-DS commented on August 19, 2024

>enemy要素にdrop属性(ドロップアイテム)を追加
これでテストプレイでも指摘されていた「強い敵を倒す意義」が出せます。

>モンスター一覧のアイコン追加(ときのじさんへ要相談)
私が勝手に攻撃方法を増やしたのが原因かと思いますが、アイコンで統一されるとその攻撃方法しか使えなくなる、という事はありませんでしょうか?その他の攻撃方法も設定可能な柔軟さが欲しいのですが…

>[ステータス反映]ボタンで反映
>ダメージ式の制限強化
これも私の戦闘複雑化が原因で、計算式もそのスレのものを採用していただいておいて何なのですが…
そのスレで現状コレを組み込まれてしまうと、盾防御/回避の判定が出来ず、待機敵からの半減DMだけを手動計算しなければならないという非常に煩雑な事になってしまい、実質戦闘が崩壊してしまいます。
なので自動戦闘を採用するかどうかをシナリオ側で選択できるようにしていただきたいです。
もしくはとりあえず自動で計算し、その結果の数字をさらにプレイヤーが加工してから反映できるようにする、というのはどうでしょうか?

from stext.

snext1220 avatar snext1220 commented on August 19, 2024

ドロップアイテム

こちらは #26 で実装しておりますので、ぜひ活用ください。

その他の攻撃方法も設定可能な柔軟さが~
自動戦闘を採用するかどうかをシナリオ側で選択できるように~

こちらはまさに自動計算の裏表だと思いますが、自動化を進めれば制限は強まると思います。
# 二重化はシステム(主にテスト)の負荷を考えても、プレイヤーの混乱を考えても避けた方が良いと考えています。

また、今のところ、皆さんの反応を拝見してきて、やはりかなり温度差があるのかなという気が。仕様的にも様々な**が絡み合うのは良くないので、条件分岐/戦闘計算の自動化を実装するならば、Ver.1を凍結&別コードでのVer.2という形になるのかなという気がしています。

# おそらく大枠のコードは一からの作り直しになるので、ホントにやる?は要議論ですが^^;

from stext.

RYU-DS avatar RYU-DS commented on August 19, 2024

自分は難解さ複雑さを平気でプレイヤーに押し付けている立場なので、柔軟性が得られるなら情報過多による混乱をあまり問題視していない、というのがそもそも問題なのかなとも思いますが…
ここまでを見た自動化についての意見は「プレイヤーの利便性のために、創作側に大幅に制限がかかるというのは、eとはいえゲームブックであるstextとしては本末転倒ではないだろうか?」というものになります。
「ゲームブックに必要最低限以上の戦闘が必要か?」というのはまた別の議論ということで。

from stext.

snext1220 avatar snext1220 commented on August 19, 2024

はい、もちろん、できるだけの柔軟性を維持していく、が基本スタンスです。

ただ、「情報過多」と「**の乱立」は、システムのわかりにくさにつながり、プレイヤー/開発者双方のハードルを高めるという意味で、避けるべきだと思っています。一見、なんでも受け入れるというと聞こえは良いのですが、大概、**が一貫していないシステムは理解しにくく、不要に難解になっていくので。

#もちろん、異なる**の排除にもなりがちなので、なにが乱立かという判断は難しいのですが;

**、といえるほどにはまとまっていませんが、現時点では以下が、現状システムの基本スタンスにはなるのかなと。

https://sorcerian.hateblo.jp/entries/2018/04/29

勿論、絶対のルールではありませんが、こちらから大きく乖離する機能の追加は、(最初の設計で想定していないという意味で)困難であるか、改訂規模が膨らみがちのため、慎重になりがちとなります。

from stext.

snext1220 avatar snext1220 commented on August 19, 2024

以下、互換性を保ちつつ、半自動化を進める案(仮)です。
本Issueがかなり長くなっているので、後日、こちらは一旦Closeして、もう少しブラッシュアップした案で新Issueを立ち上げる予定です。

1

from stext.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.