[戻る]
FGS操作感想その２
name：@rpg_tkr 2018/10/22 07：50：05 https://twitter.com/rpg_tkr
動作環境：windows8、SSDにOS搭載、Core-i7(4790)、GTX970、メモリ8GB
・選択肢１から↑キーで選択肢３に飛ばない。選択肢３から↓キーで選択肢１に飛ばないのが気になった。
・スクロール終わった時にZキー押しっぱなしにしていると再度スクロールが始まってしまう。
・濃度の表記は「透過度」にした方が理解しやすい気がする。
・【保存】はCtrl+sキーで実行されるようにした方がいい。（【戻る】がCtrl+zで出来るなら尚更）
・デバッグ開始はボタンワンクリックで始まるようにした方がいい。
【ファーストインプレッション】
テストプレイを通して、XP時代にプレイしてきたフリーゲームのような雰囲気を感じた。
ターゲット層はRPGツクール2000やウディタが出てくる以前の、
PCレトロゲーマーが狙い目に感じます。（最近のツールと差別化するのであれば）
マップエディットに関してはレイヤー構造を理解すれば難なく作れるが、
デフォルトでRPGの王道戦闘システムくらいはあった方がいいように感じる。
自作しようと思えば作れるのだろうが、最低限のモノはあった方がいいと思った。
（自作戦闘を作るだけで如何に時間が取られるかを知っているので尚更）
name：fuku@管理人 2018/10/22 14：10：18
フィードバックありがとうございます。
>・選択肢１から↑キーで選択肢３に飛ばない。選択肢３から↓キーで選択肢１に飛ばないのが気になった。
内部的には実装済み(オプション扱い)なのでデフォルト有効とするか検討します。
>・スクロール終わった時にZキー押しっぱなしにしていると再度スクロールが始まってしまう。
状況を確認できませんでした。
詳細を教えていただければ幸いです。
(サンプルデータのスクロールメッセージの表示は背景の明るさや色などを変更しつつ
3回流れるようになっていますがそれと関係ありますか？)
>・濃度の表記は「透過度」にした方が理解しやすい気がする。
濃度(透過度、透明度、不透明度)の表記はどれも一長一短で悩んでいる部分なので、
ある程度の票数があれば、ということにさせていただきます。
ちなみに仕様など技術資料側では基本的に「透過度」表記になっています。
●長所
濃度：一般で使われる言葉である、値の大小と効果が明確、字数が少なく表示領域を取らない。
透過度：CG系の知識があれば多分通じる。
透明度：CG系の知識があれば多分通じる。
不透明度：値の説明として明確。
●短所
濃度：この手のツールではあまり使われない。
透過度：値の大小関係が逆(大きいほど透過する)に取れてしまう。
透明度：値の大小関係が逆(大きいほど透明になる)に取れてしまう。
不透明度：字数が多く表示領域に困ることがある。
>・【保存】はCtrl+sキーで実行されるようにした方がいい。（【戻る】がCtrl+zで出来るなら尚更）
他のキー割り当てとの関係を含め検討します。
>・デバッグ開始はボタンワンクリックで始まるようにした方がいい。
検討します。
>テストプレイを通して、XP時代にプレイしてきたフリーゲームのような雰囲気を感じた。
>ターゲット層はRPGツクール2000やウディタが出てくる以前の、
>PCレトロゲーマーが狙い目に感じます。（最近のツールと差別化するのであれば）
添付素材がその辺りに近い質感なのでそのように感じられたのかもしれませんね。
素材を取り込むとかなり印象が変わります。
(ツールで素材として使用する形の再配布を認める素材屋さんは把握していないので、
ライセンス上、基本的に素材は各自で集めていただくしかないのです)
>マップエディットに関してはレイヤー構造を理解すれば難なく作れるが、
>デフォルトでRPGの王道戦闘システムくらいはあった方がいいように感じる。
戦闘関連はRPGモジュールが担当する予定なのですが、
戦闘関連の要求仕様はかなり幅広く、
拡張性を優先するか、簡易性を優先するか等、両立困難な項目が割と出ていて、
仕様の策定に難儀している状況です。
ひとつのゲーム用として実装するならどうとでもなるのですが、
汎用的に使える形というのはなかなか難しいです・・・。
貴重なご意見、ありがとうございました。
もしよろしければ、継続してご協力頂ければ幸いです。
name：@rpg_tkr 2018/10/22 16：06：05
>(サンプルデータのスクロールメッセージの表示は背景の明るさや色などを変更しつつ
>3回流れるようになっていますがそれと関係ありますか？)
あ〜多分これですね。勘違いして申し訳ないです。
>添付素材がその辺りに近い質感なのでそのように感じられたのかもしれませんね。
>素材を取り込むとかなり印象が変わります。
そのかなり印象が変わる、という点を試しにサンプルでも作って
大々的にアピールした方がいいかと存じ上げます。
（私は流石に作る時間がありません。申し訳ないです）
>戦闘関連はRPGモジュールが担当する予定なのですが、
>戦闘関連の要求仕様はかなり幅広く、
>拡張性を優先するか、簡易性を優先するか等、両立困難な項目が割と出ていて、
>仕様の策定に難儀している状況です。
>ひとつのゲーム用として実装するならどうとでもなるのですが、
>汎用的に使える形というのはなかなか難しいです・・・。
私が経験したことのあるツールは
RPGツクールシリーズ、ウディタ、スマイルゲームビルダーズの３つですが、
どれもデフォルトでフロントビュー戦闘が組み込まれていましたね。
ツクールMVではプラグインによって大きく拡張できますが、
逆にスマイルゲームビルダーズはお手軽重視なのか拡張性は低めですね。
（初期の頃の話なので今どうなってるのか把握していないので分かりませんが）
ウディタも自分でスクリプトを弄ることで拡張できてた気がします。
フロントビュー＋ターン制のデフォ戦はゲーム制作ツールとして鉄板、というツール間での暗黙の了解を感じます。ドラクエの影響が強すぎる…
name：fuku@管理人 2018/10/22 18：35：13
返信ありがとうございます。
>そのかなり印象が変わる、という点を試しにサンプルでも作って
>大々的にアピールした方がいいかと存じ上げます。
その点は理解しているのですが、
どうせ作るなら内部データを見たり改造できる形にしたいという欲が出てしまって。
(これだと完全に再配布になるため、外部素材が使えないのです)
恐らくは割り切って普通のゲームとして1本リリースしたほうが良いのでしょうね・・・。
>フロントビュー＋ターン制のデフォ戦はゲーム制作ツールとして鉄板、というツール間での暗黙の了解を感じます。ドラクエの影響が強すぎる…
フロントビュー+ターン制は比較的難度が低いという点もあるのでしょうね。
RPGモジュール用として半分ぐらい実装しているものもそれですし。
貴重なご意見、ありがとうございました。
もしよろしければ、継続してご協力頂ければ幸いです。