ぼちぼちまちま日誌2

カテゴリー「覚書・小ネタ」の検索結果……3件

【結果】PCゲームで基本動作を行うキーのイメージについて

こちらで回答を募集していたアンケートの集計結果(計39件)を公開いたしました。遅くなってしまい申し訳ないです。
zipにいくつかファイルを入れています。ファイルに関しては同梱のtxtファイル、スプレッドシート「このデータについて」をご参照ください。
集計結果:zipファイル(Google ドライブ)
集計結果:Google スプレッドシート
※集計ミスありました(まだ差し替えていません)。申し訳ありません。
分布の「メニューキー」のSpace:(誤)4→(正)3

回答をしてくださった方々ありがとうございました!以降、今回のアンケートの設問の意図や、感想等です。

【このアンケートの作成意図】

そもそもこのアンケートを作った理由としては、「キーコンフィグに困った」というのが一番の理由です。
私としては自分のキーイメージが世間の中央値であると思っていましたが、フォロワーの「決定キー=Space」というツイートを見てから「もしかして私、中央値じゃない……?」と思い始めていました。
そして丁度製作中ゲームのキー周りを整備中でキーに悩んでいたため、よしアンケート取ってみるか~ということでアンケートを取った次第です。

アンケート募集時点で私が気になっていた点は2つあります。「アクションゲームをプレイする人のキーイメージを知りたい」と「ある製作ツールで作られたゲームをプレイする人のキーイメージが知りたい」です。前者についてはよくプレイするゲームにアクションゲームが入っている人の回答結果を見ればいいですが、後者は「よくプレイするゲームの製作ツール」を知る必要があります。
後者に関しては製作ツールに関する設問を設けるのが一番確実になりますが、ゲーム製作者ではないプレイヤーの何人がゲーム製作ツールに意識を向けているか不明であり、もし「製作ツールは知らない」のような回答が増えたとなると、情報の正確性以前に情報量が不足します。

そういうわけで、あえて製作ツールについての質問は外し、代わりに「よく利用するダウンロードサイト」の設問を追加しました。
というのも、「よく利用するダウンロードサイト」と「よくプレイするゲーム」である程度製作ツールを絞れると思ったからです。例えば、ふりーむ・夢現をよく利用する方でコマンドRPG・ADVが多い場合は恐らくはフリゲのツクール、またはウディタ製のゲームを、SteamでアクションならUnity製といったように、大凡の予想はつきます。ただし、よくプレイするゲームが多岐に渡る方や、個人サイトからダウンロードすることが多い方などはこの限りではありませんし、Steamが必ずしもUnityゲー1本という訳でもないため、どうしても予測の域に留まってしまいますが。

以上、(悪い言い方をすれば)結果の不足よりも結果の不確実性を取ったのがこのアンケートになります。正直初めての取り組みであるため設問の立て方に失敗してもいいかなーと思いつつ公開しました。「ここの設問の内容失敗したな」とか「ここもう少し知りたいな」と思ったらまた改めてアンケートを公開しようというような態度です。また、私以外の方が同様の意見を持った場合は適宜アンケートを行なったりしていただければと思います。
何はともあれ、このアンケートで何か前向きなことがアレコレできれば幸いです。また、もし同じようなアンケートを再度行った際は、またお力を貸していただけると助かります。

【感想やちょっとした考察】

【決定キー・キャンセルキーについて】
今回アンケートを行うきっかけとなった決定キーについてですが、Enterキーが一番多いという結果になりました。Enterキーを回答された方の他の結果を見ると、ツクール製ゲームをプレイすると思われる方(ブラゲー、ふりーむを最も利用する)もUnity製ゲームをプレイすると思われる方(Steam)もそれぞれいるため、どのゲームジャンルでもEnterで決定はあるあるなのかなと思いました。
キャンセルキーについて、キャンセルキーでBackSpaceを回答されている方全員決定=Enterであり、Z=決定と回答してる方の殆どはキャンセル=Xと回答していました。やっぱり使用キーは近くなる傾向があるんですかね……。
キャンセル=C、メニュー=Xと回答されている方もいましたが、アクションゲーによってはそういうキーもあるんだなぁ……と。プレイしたゲームでこのキー配置に出会ったことはないんですが、「こういうキー配置もある」と知れただけでも嬉しいです。

【メニューキーは案外ばらける】
こんなメニューキーの種類あるか!?とかなり意外であると同時に、ばらけすぎてて共通性を出すのが難しく、設問設定に反省した点です。
Spaceって何!?Shift!?とか思いながら見ていました。
ただ、ツクール製をプレイされそうな方(ブラウザゲー、DLsite、ふりーむ)をガーーと見てみると、ツクールでキャンセルキーに設定されているキーをメニューキーとしてイメージしている方が多いのかなという印象です。

【ウディタ】デバッグで詰んだ箇所メモ

ウディタ製ゲームのバグ取りの際に何十分も足止め食らった箇所として記憶にあるものの個人的まとめです。
起動条件・イベント移動系のバグがないのは作ってるゲームの仕様上ほとんど使うことがないからです。

【CDB読込み/書込み場所の指定を間違えてる】

20200419170539.PNG
割とやらかす。
下みたいに指定する変数を間違えた例について、単純に変数の指定を間違えた場合ならまだいいんですが、「Cself24で値を取ってCself25に入れて、Cself25を使って違うDBから値を取る……」みたいなことを何回もやって「あれ、これってCself24?Cself26?」ってことになるとバグ取りで大混乱が起こります(実際に起こりました)。DBにアクセスする可能性がある変数が複数存在する場合は名前の付け方に気をつけような……!

【数値代入の変数間違えてる】

20200419170540.PNG
これもまぁやらかす。明らかにおかしい値が出たら多分これ。
バグったらバグ起こった箇所前後を精査することになると思うので、前後のやつに比べるとある程度気づきやすいと思います。

【DB読込んだつもりだったけど読み込んでない】

つい最近こいつで30分詰みました。
条件分岐Aの時にa,bを、条件分岐Bの時にb,cを読み込むとき、条件分岐Bで実はbを読み込んでいなかった みたいな奴です。
前回呼び出した時のbの値が残っており、条件分岐Bで処理したいbの値と偶然一致したりすると上手く動いたりするのでまぁ気づかない。
ちなみにこれについては、「DBを読み込むタイミングを統一する」である程度対策取れます。というかスクリプトの視認性考えても読み込むタイミングを統一したほうが良いかと。
ただ、DB読み込む項目数が極端に多い・文字列を複数読み込む場合などで処理落ちが心配な場合は、とりあえず最初の処理でCself10~Cself99=0入れるのが良いと思います。それで処理おかしくなったらこれが疑わしいかなー。

【ウディタ】描画座標シフトメモ

20200326211151.PNG

ウディタの描画座標シフトとようやく和解できたのでメモも兼ねて。
正直合ってる自信あまりないのでここ違くね?とかあったらツッコミください。

前提の話

20200326211149.gif

上のGIFはX=200で表示している★マークを200pxスライドさせたものですが、これを実行する方法としては以下が挙げられます(他もあったら補足オナシャス)
(1) ピクチャ移動でX=400を指定
(2) ピクチャ移動で相対座標でX=200
(3) 描画座標シフトでX=200シフト
20200326211150.PNG
1の例はともかく2と3ってほぼ同じじゃね?ってところから今に至ります。ってことで2と3の違いをザックリまとめたあと、使い分けについてのメモりながらのまとめです。

てかどう違うんだよ

前提の話であげた例のX=200を2回実行してみます。
(a)ピクチャ移動で相対座標X=200を2回やる
(b)描画座標シフトX=200を2回やる
20200326211151.PNG
aの場合、今★マークがあるのは200(最初の表示場所)+200(相対移動1)+200(相対移動2)=600ですが、bの場合は200(最初の表示場所)+200(シフト分)=400です。まぁつまりそういうことです。

使い分け例

これは前提の話(1)の移動方法も含めてのメモです。多分実例上げたほうが早い。

ケースA : 右キー押すとピクチャを100px動かす
(1) 初期座標+100+100+100……
(2) 押される毎に相対座標100
(3) シフト量 = 100×右キー押された回数または押される毎に+10020200326211152.PNG

もしかしなくても一番簡単なのは(2)。(1)と(3)は手間としては同じですが、変数操作+のピクチャ情報取得で描画座標シフトの値を取ることはできないことを考えると、(1)のほうが管理的には楽なのかなぁと。後で詳しく触れますが、「描画座標シフトした結果描画されている位置≠ピクチャ座標」なのでここ注意。
ちなみに横スクロールゲームを作る際プレイヤーをピクチャとして描画する場合は移動量を相対でプラスしていくよりも下のやり方のほうが安定すると思います。

ケースB : ウィンドウ表示の際、後半がゆっくりになるように表示する
(1)1回目2回目共に同じ座標を設定し、1回目の移動はディレイ0で、2回目の移動は一定ディレイ置いてから実行
(2)何か上手いこと頑張る(スクショ参照)
(3)座標で指定する例と大体同じ。ただ描画座標シフトにはディレイはないのでウェイトで擬似的にディレイっぽくしています。20200326211153.PNG

(2)はちょっと面倒くさい……というか切り替わるタイミングで一瞬止まったりして上手く行かなかった記憶があります。ってことで、(1)と(3)の事例で絞ります。
移動ピクチャが1枚または複数枚で同じ座標の場合は(1)のほうが記述量が少ないので管理しやすそう。(3)が力発揮するのは座標がバラバラの塊を移動する時ですかね。

つまり描画座標シフトって何

ってことで再び本題。最初に「描画座標シフトと相対移動って大体同じだろ」って言いましたが、相対座標が「○○px動かす」を得意とするのに対し、描画座標シフトは「目的地の○○pxまで動かす」を得意としてるのかなーという感じです。言うまでもなく「目的地の○○pxまで」って動かし方を一番得意としているのは座標で指定する動かし方ですが、座標指定は座標指定ゆえに座標がバラバラの複数枚数の位置関係を維持しながら移動させるのは苦手、というか面倒臭いです。20200326213132.PNG

描画座標シフトが生きてくるのは、「それぞれの位置を維持しながら指定位置まで複数ピクチャをずらすとき」なのかなーと思います。例えばRPGゲーム戦闘画面のHPゲージとMPゲージを動かすときとか。座標をガッツリ指定するとなると「HPゲージはxxピクセルでMPゲージはxxピクセル……」と算出する必要がありますが描画座標シフトならピクチャ指定して○○px遷移でOKです。
もちろん相対座標でもできるんですが、使い分け例ケースBで示したように緩急つけるとなるといちいち「何フレームは何px動かして……」と算出しなきゃいけないので面倒臭い。

一方描画座標の欠点は間違いなく「描画座標シフトした結果描画されている位置≠ピクチャ座標」。例えば複数コモンで1枚のピクチャをアレコレしてる場合、コモンAで初めに座標(0,0)でピクチャ表示→コモンBでX200pxシフト→コモンAでピクチャ移動(200,0)みたいな時、予想したピクチャ位置とは当然ずれます。あとピクチャ情報取得で描画座標シフト量は取れないので「変数操作+」のピクチャ座標取得であれこれする場合も当然事故ります。

まぁつまり、ガッツリまとめると描画座標シフトって「複数枚のピクチャを対象に、それぞれの位置を維持したまま何かをスライドする時」に特に強いのかな!と思います。