Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

タッチ環境でもタッチを無効にするコマンドラインオプションの追加 #196

Open
miahmie opened this issue Mar 4, 2016 · 9 comments

Comments

@miahmie
Copy link
Contributor

miahmie commented Mar 4, 2016

Window.enableTouchはタッチデバイスがある場合においてデフォルトでtrueになる仕様ですが,
吉里吉里2からの移行でonMouse* イベントしか考慮されていないスクリプトにおいて,
この仕様が予期しないバグ(タッチのみの環境で全く操作できない)を発生させる場合があります。
非タッチ環境でしかデバッグできないユーザーも多いので,
この問題に全く気付かずゲームがリリースされてしまう可能性があります。

吉里吉里Zのreadme.txtには一応この件に関する説明が記入されていますが,無効化しない場合の
注意喚起(タッチでまったく操作できなくなる等)の文章を念のため追加した方が良いかもしれません。

そこで,ユーザー側でも何かしらこの問題に対処できるよう,-touchdevice のような
タッチデバイスの有効・無効を設定するオプションを追加することを希望いたします。

  • 従来仕様(タッチデバイスがあればenableTouchの初期値がtrue)
  • enableTouchの初期値を(タッチデバイスがあっても)常にfalseにする
  • 完全にタッチ無効にする(TJSスクリプトでenableTouch=trueにしてもtrueにならない)
    (proc{Register,Unregister}TouchWindowをNULLにしてしまうような挙動)

くらいのパターンを指定できれば十分でしょうか?
ご検討ください。

@jin1016
Copy link
Member

jin1016 commented Mar 6, 2016

「システム互換性関連のオプション」の一種として追加するのが妥当でしょうか。
吉里吉里2互換のタッチ系完全無視と今の吉里吉里Zのどちらかを指定可能なもの。
真ん中の「enableTouchの初期値を(タッチデバイスがあっても)常にfalseにする」は、どういう状況を想定されているのかわからないのですが、必要でしょうか?

@miahmie
Copy link
Contributor Author

miahmie commented Mar 6, 2016

真ん中の「enableTouchの初期値を(タッチデバイスがあっても)常にfalseにする」は、どういう状況を想定されているのかわからないのですが、必要でしょうか?

互換を重視しつつタッチ機能も使いたい場合の使用を想定しています。
例えば, #174 で少し触れたDebug.controllerプラグインを作ったとして,
「吉里吉里2互換重視な吉里吉里Z」を独自にリリースしたいような場合の
オプション値のデフォルトとして使用するといった想定です。

タッチデバイス有効の場合に問答無用でtrueにされるのは,最初に触れたように「気づかない罠」が潜んでおり,
かといってオプションでオフにするとタッチが全く使えなくなるのは,上記のような汎用リリースにおいては少し困るかと思います。
独自リリースなので,プログラムコード側でデフォルト値を変えるという手もありますが,あまり独自変更が重なると管理が面倒になるという一面もありますので,オプションで設定できるならそれにこしたことはないという理由です。

もし真ん中の項目のオプション対応が困難ならコンパイル時のdefineマクロのオプションを追加する方向でも構いません。

@jin1016
Copy link
Member

jin1016 commented Mar 6, 2016

「吉里吉里2互換重視な吉里吉里Z」を独自にリリースしたいような場合のデフォルトと言うのがわかりません。
互換を取ろうとしたら完全互換ではないのでスクリプトに分岐があると思いますが、スクリプトでfalseに設定するのではなく、ここだけオプションとする理由はなんでしょうか?
完全無効をオプションで切り替えるのは救済機能としてわかるのですが、デフォルトをfalseとできる合理的理由が見いだせません。

「タッチデバイス有効の場合に問答無用でtrueにされる」と言うか、そもそも無効な場合はイベント自体発生しないので、trueにする意味がないためfalseになっています。
タッチ操作はタッチイベントが発生して、指定された場合にのみマウスイベントにフォールバックするのが仕様として自然と言う考えから現仕様となっています。

@miahmie
Copy link
Contributor Author

miahmie commented Mar 6, 2016

ここでいう「互換重視」とは,吉里吉里2で動いていたスクリプトに手を加えることなく吉里吉里Zで動かすという意味です。
(先のDebug.controllerやらmenuプラグインはtpmで提供して起動時にオートロードされることを想定しています)
なので,「スクリプトでfalse」にするという選択肢はありません。

個人的に,2からZの移行をスムーズに行えるような環境があってしかるべきと考えており,そのためには吉里吉里Z用に既存のスクリプトに手を加えるのはできるだけ避けたいという要望があります。
もちろんZで廃止された機能を使ったものは動きませんが,よく使われるものはDLLで提供して穴埋めしていきたいという考えです。

じゃあ互換用にタッチを完全無効のオプションをデフォルトにすればいいと思われるかもしれませんが,そうすると移行後に吉里吉里Zのタッチの恩恵を受けるための手間(オプションの変更が必須)が発生して,「2からZの橋渡し」としてそれはどうなんだと思う次第です。真ん中のオプションがあればスムーズな移行ができて実に合理的だと思うわけです。

ちなみに,公開はしていませんが,吉里吉里2向けにZのタッチ機能相当のイベントを提供するkztouch.dll も(実装の都合で完全な互換ではありませんが)作ってあります。

タッチ操作はタッチイベントが発生して、指定された場合にのみマウスイベントにフォールバックするのが仕様として自然と言う考えから現仕様となっています。

現状で吉里吉里Zで提供しているゲームでタッチ操作が全く反応しない作品(体験版ですが)を確認しております。
こういった若干の仕様の違いが2⇒Zの移行の障害になっていると思うわけです。
すべての開発者の環境にタッチデバイスがあるとは限らず,それによってタッチ不具合が見過ごされ,
タッチデバイスのあるユーザー(プレイヤー)が不利益を被る(ここでいう不利益とは主にゲームがプレイできないことを指し,マウスデバイスを用意したり,手動でオプションを変更して問題を回避する手間も含まれることとします)のは
望ましくないのではないか,という話です。

@jin1016
Copy link
Member

jin1016 commented Mar 6, 2016

個人的に,2からZの移行をスムーズに行えるような環境があってしかるべきと考えており,そのためには吉里吉里Z用に既存のスクリプトに手を加えるのはできるだけ避けたいという要望があります。

「2からZの移行をスムーズに行えるような環境があってしかるべき」と言うのは同意ですが、後半の「既存のスクリプトに手を加えるのはできるだけ避けたい」と言う部分については別意見ですね。
新しいものに対応した代替機能を提供して行く方向が良いと思っています。
現状だとKAG3に追加していくか、新しいKAGを提供する方向になると思いますが……

それはともかく、対応は可能なようにオプションとデバッグオプションを追加しました。
まだテストは行っていません。
ce085ae

デフォルト無効とするのはデバッグオプションにしました。
ついでにデバッグオプション一覧を整理するファイルも追加しました。

@wtnbgo
Copy link

wtnbgo commented Mar 7, 2016

個人的には以下がいいなーと思います

  1. Window.enableTouch の初期値はデバイスの有無に関係なく false
  2. 別途タッチデバイスが使えるかどうかを示すプロパティを追加
  3. 新規にタッチ対応するコードを書く人は 2. を使って判定して 1. を設定するようにする

初期値を false にしてしまうと、ではどういう判定で有効にすればよいのか
判断つかないことになるので 2. が必要になります

@miahmie
Copy link
Contributor Author

miahmie commented Mar 7, 2016

別途タッチデバイスが使えるかどうかを示すプロパティを追加

これは既に System.touchDevice がありますね。tdほげほげの論理和が返るようです。
現状,アンドキュメント・・・かな?
System.touchImageとかあるので名前名称が若干紛らわしい感じはします。

@jin1016
Copy link
Member

jin1016 commented Mar 7, 2016

System.touchDevice ドキュメントへの記載忘れてましたね。
タッチ使う時は、判定など気にせず有効にしてしまっても、マウス環境ではタッチイベントが来ないだけで何も影響ないはずです。

Zは確か最初から現在の仕様でしたが、ここで仕様を変更するのはやはり反対です。
理由は――

1.タッチで出来ないマウス操作等

  • 押下しないと移動できないのでホバー系の操作はなくなる。
  • ホイールがない。
  • 右クリックはロングタップで代用。

2.マウスで出来ないタッチ操作

  • マルチタッチ系操作(拡縮、回転等)

1の出来ない操作は致命的に面倒で、ホバー系操作のヒント表示などは説明が見られないのでよくわからないまま進めることになります(もしくはマニュアルを読む)。
ホイールがないのも面倒で履歴などでタッチでのグラブスクロールがないと横のバーでスクロールしないといけなくなります。
右クリックのロングタップも仕方なく長押し待ちで回避できるが、タッチでさっとできるフリック等の操作で代替するのが望ましい。
2はスマフォなどだと当たり前だから、出来るといいよねと言う程度。

2は+αの要素ですが、1はマイナス要因なのでタッチデバイスが普及していることから早期に解決した方が良いと思われるものです。
メニュー削除と共にタッチデバイスを考慮したUIへ進めると言う思想の元の仕様ともなっています。
また、仕様を決める時にAndroid版も視野に入れて互換性を取れることも考慮していました。
Android版で、デフォルトタッチ無効でマウスイベントと言うのは、あんまりな仕様に思いますし、上述の問題があるものが出るのは流石に厳しいと思います。
Android版であればマウス無効は動作確認した瞬間に気付くものでもあります。

現段階では、KAG3にタッチ操作系を取り入れて同梱するのが解決への近道でしょうか。

以上の理由により、現在のままが望ましいと考えていますが、デフォルトfalseの方がより良い点等ありますでしょうか?

@jin1016
Copy link
Member

jin1016 commented Mar 23, 2016

動作確認したのでマージ。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants