TK11235

Results 17 comments of TK11235

反応が遅くなりました。 提案ありがとうございます。 簡易ダイスボット機能を実装することには、今のところ積極的な理由がないかなと感じています。 根拠としては以下の2つです。 - 簡易ダイスボット表による自動化がルール処理の効率化に貢献する状況を想像できない。 =「処理の効率化が目的」ではなく「自動化するという行為が目的」になってしまうという危惧。 - "意識的に活用しないと活用できない機能"になるようであれば、現時点では優先度は低い。

反応が遅くなりました。 想定される利用状況についての説明ありがとうございます。 どのような場面で必要になるか把握できました。 間が開いてしまったので細かい説明を飛ばして結論だけ述べてしまうのですが、 v1.10.0以降のリリースで実装を検討しようと思います。 具体的な仕様は未定ですが、多分どどんとふに近い形になると思います。 このIssueは実装完了までOpenで維持してください。

提案ありがとうございます。 > ユドナリウムに入るたび参加者全員「ダイスボット指定なし」から「特定のダイスボット」の項目を選ぶのは煩雑に感じることが多々あります。 確かにその通りですね。 これから何を遊ぶのか分かりきっているのに毎回選択するというのは面倒です。 具体的な機能としては以下のように動作すれば解決するでしょうか。 - ルーム全体のデフォルトダイスボットを指定する機能 - デフォルト変更時に、参加者全員のダイスボット選択も合わせて変更する - デフォルト変更時以外は、参加者が各自でダイスボットを選択してもよい

把握しました。 実装完了までIssueはOpenのまま維持してください。 実装の目途はv1.9.0頃になりそうなので、少し時間がかかるかもしれません。

返信が遅くなりました。 提案ありがとうございます。 少し考えてみたのですが今のところの開発方針としては、そこまで複雑な機能を作る予定はない、という状態です。 理由はいくつかあるのですが、主なものを説明すると - ボードゲームのルールは、複雑すぎるとゲームが進行できなくなるので、ほとんどの場合、人間の手で無難に処理できるように設計されている筈です。 処理を自動化できると便利ですが、自動化しなければどうにもならない、というような必然性は無いだろうと思います。 - 技術的には、CardWirthのエディタやQuestNotesのような物を作れば実現可能だと考えています。 しかし、色々なゲームルールを任意に定義して自動処理させる機能というのは、ほとんどのユーザにとって複雑すぎる機能になるだろうと思います。 (※ルール処理のためのプログラミングを行うことになってしまう) - 計算結果を求めるだけなら、チャットパレットの文字列代入を前提としたルール処理用のダイスボットを作った方が早いかもしれません。 というような理由から、積極的に実装したいとは考えていません。 --- カウンターリモコンそのものが不要だと考えている訳ではなく - パラメータ操作のショートカット - パラメータ操作のログ記録 のような機能は何かしら存在する方が良いだろうと思っています。 --- > チャットパレットでも色々なキャラクターのデータを参照したい 他のキャラクターのデータ項目を参照できる仕組みは手軽で便利そうですね。 対象を選択するUIをどうするか、という問題はありますが、`自分の攻撃力-対象の防御力`の計算処理は解決できそうです。

> チャットパレットの中に1d6+{攻撃}-{相手:防御}のような書き方をしておいて、相手を選択すれば実行される、というような…… 「最後にクリックしたキャラクターが対象(相手)になる」とかでしょうか。 インベントリ画面の太字枠線で似たようなことを行っています。 > 相手が防御パラメータを持っていなかった場合のエラー処理が問題になりそうですが、チャットパレットパネルにエラーメッセージを表示するような形でしょうか。 現在のチャットパレットの仕様「存在しない`{パラメータ}`項目は空文字で置換する」のままで良いかなと思います。 「チャットパレットで上手く処理できるキャラクターシートを作るのはユーザの作業」として割り切ってしまう方がシンプルで良い予感がします。 > ただ、(どどんとふにおける)カウンターリモコン操作ログは、頻度が高いと流れが早すぎましたの、ログ記録用に専用タブを用意する……というのはありうるでしょうか。 必要と考えつつも、カウンターリモコン系統の機能をまだ実装していない理由がそれです。 時系列管理の為にも操作ログはチャットログとセットになるべきだと考えていますが、今のチャットUIにそのまま操作ログを表示すると邪魔になるのでデザインか何かを考えないといけません。

返信が遅くなりました。 > このように、操作ログ記録専用の削除不可タブを作り、そこに流していく……というのを想像していました。 これでは技術的・方針的によくないでしょうか。 ありがとうございます。 確かにその方針で良い気がしますね。 返信までに間を空けてしまいましたのでざっとまとめます。 機能実装の方針としては以下の機能が必要になりそうな感じでしょうか。 - パラメータ操作のショートカット操作 - チャットパレットから他キャラクターのデータを参照 - 操作ログ出力

提案ありがとうございます。 接続時・切断時の通知機能が存在しないと困るのはその通りですね。 > ①20-30秒おきに接続人数を監視して、「突然、接続人数が半分以下になった」ときに警告を表示 ②誰かの接続が切れたときに、メインチャットに「xxが退室しました」のチャットログを表示 ③現在のチャット新規通知に近い形で、メニューの「接続」右下に現在接続している人数を表示 提案してもらっている内容をベースに、通知音やチャット(システム通知専用のチャットタブを用意する予定)等で通知を行う実装を検討してみます。 早ければv1.9.0で実装できると思います。 実装までこのIssueはOpenのまま維持して下さい。 --- #### 情報収集:切断時の状況 > セッション中、「接続断が発生したことに気づかない」場面が多く困っているので、改善を希望いたします。 一度は接続に成功したメンバがその後切断してしまう、という認識で合っているでしょうか。 そうであれば、切断時の状況について質問したいことがあります。 Issueで言及されている通り「絶対に切断しない」と断言することは当然できません。 その対策として、Web RTCとブラウザ自体の機能に自動再接続機能が用意されており、これによりネットワークが不安定でも瞬間的な切断であれば接続の復旧が可能です。 "基本的には"、一度接続に成功した後は滅多に切断しない状態になります。(誤ってブラウザを閉じた等の状況は除く) そのため、報告して頂いているような頻度で切断が発生する(=再接続に失敗する)環境は珍しいと感じ、@NktAts さんの経験は貴重な情報になるのでは、と考えています。 分かる範囲で良いので、以下の質問に回答して頂くことは可能でしょうか。 今後の開発の助けになります。 1. 切断するメンバは常に同じ人か、それとも誰でも切断する可能性があるか。 2. 切断してしまうメンバが固定の場合、そのメンバの通信環境は何か。(自宅の固定回線、ポケットWiFi、スマホ回線、等) 3. 切断してしまったメンバは他のメンバから孤立した状態になるのか。メンバ全体が2つのグループに分断されるよう切断は発生するか。...

回答ありがとうございます。 ネットワーク環境に起因する問題は情報収集が難しいのでとても助かります。 >日付ごとに、特定の人が何度も落ちる事例が多いです。 日付が変わると、前回頻繁に落ちていた人が全く落ちなかったりします。 >予測はできません。特定の状況で発生する、というものではありませんでした。 上記の回答から想像すると、PCの設定やユドナリウムの問題というよりは、家の外のネットワーク回線上で何かが起きて切断しているのではないかと感じました。 原因の予想としては、 - 切断してしまうメンバの地理的状況 - ISPのP2P規制 など、個人ですぐに対応するのが難しそうな要素が挙げられそうです。 今のところは、定期的に切断するものと妥協して切断通知機能でお茶を濁すしかないですね。 --- "全く手の施しようがない"という訳ではない筈なので、将来的には通信の問題にも対応しなければと考えています。 あまり期待せずに気長にお待ち頂ければと思います。

反応が遅くなりました。 提案ありがとうございます。 #### UI全般について >今後立ち絵機能も実装されること、魅力的な3D表現を鑑みると画面の窓占有率は低い方が見栄えも、使い勝手も良いのではないか?と思いました。 窓UIが画面を占有して邪魔になる、画面占有率は低い方が良い、というのは指摘の通りだと思います。 さらにこれはチャットパレットに限った話ではなく、ユドナリウム全体の問題として現在のUIの問題点だと認識しています。 そのため、今後の作業としてv1.9.0以降の更新でUIを改善していく予定です。 具体的にどのようなUIにするかはほぼ未定で検討中の状態です。 このIssueのように、UIに関する提案や問題指摘を送って貰えるととても助かります。 ※ UIの使い勝手の悪さは開発効率(=とりあえず最低限動く状態)を優先させた結果です。#23 や #25 などで同様の指摘を受けています。 #### チャットパレットUIについて チャットパレットの改善については言えば、大きく2つの選択肢があるだろうと考えています。 - 「同じ機能のために複数の窓を生成するのは良くない」として、タブ形式で窓UIの省スペース化を図る。(提案して頂いている方法) - 「チャット入力欄がチャットパレットとチャットウィンドウで別々に存在することが良くない」とし、チャットウィンドウに全てのチャット入力機能を集約する。 上記のどちらか、または組み合わせで改善できないか検討中です。 --- 改善されるまでIssueはOpenのまま維持します。