インターフェイス・操作系

**名無しさん＠お腹いっぱい。** · 01/11/09 01:11

ゲーム自体の面白さを追求するのも大事だけど、快適に遊んでもらう
ための工夫をするのもまた大事というわけで。

画面レイアウト、メニューのデザイン、キーやパッドの処理
etc…遊びごこち向上のための話題をどうぞ。

**名前は開発中のものです。** · 01/12/27 01:03

個人的にゲームを作る時は、
Z＝ファミコンで言うAボタン＝決定
X＝ファミコンで言うBボタン＝キャンセル
という風にしてるんだけど、逆の人も結構いるんだよねえ…。

**名前は開発中のものです。** · 01/12/27 01:16

キーコンフィグができれば問題なし

**名前は開発中のものです。** · 01/12/27 01:21

デフォルトから変更しない人は多い

**名前は開発中のものです。** · 01/12/27 01:29

クライテーーーン！！！

**156** · 01/12/27 01:29

ゴメン、誤爆・・・

**名前は開発中のものです。** · 01/12/27 01:36

ﾜﾗﾀ

**名前は開発中のものです。** · 01/12/28 05:14

>>152
パッド操作でメニュー内の操作をさせるのは便利そうだけど、
メニュー内にサブメニューがいくつもあってしかもその数が不確定
＃見る→机の上→灰皿とか見る→周りとか
な場合、決定するつもりがなくて選択することがあったりするので
左上（人差し指部分）にボタンがあるならそれを最終決定ボタンに
して欲しいかな。

**名前は開発中のものです。** · 01/12/28 11:56

ほんとなら、専用コントローラー作ってこそだと思うけど
現実味がないのでヨシとしてるだけ。だよね。

あとプレイヤーにキーコンフィグしなきゃダメと思わせた時点で、
モノづくりする人間としてダメダメのような。
やっぱデフォの設定が一番しっくりするってのがホントでしょ。むじいけど。

**名前は開発中のものです。** · 01/12/28 13:57

禿同。
可能ならコントローラーから入りたい。

コンフィグは仕方なくつけるけど、説明書にはこの配置でって指定をつける。
正直、PC系でパッド前提なら、キーボード、マウスは使用不可にしたいくらい。

**名前は開発中のものです。** · 01/12/28 13:59

＞コンフィグは仕方なくつけるけど、
PC系だから仕方なくつけるけど、

**名前は開発中のものです。** · 01/12/31 14:57

コミケ逝ってきた。同人STGをいくつか買ってきた。
どれも高水準（特にグラフィック）だったけど、なにか物足りなかった。
ひとつは自機の動きが遅くすぎて敵地を蹂躙する快感が得られなかった。
ひとつは自機の動きが速くすぎて弾避けするつもりが隣の弾まで移動してあぼ－ん。
たったこれだけなんだけど減点しちゃうんだよな…。ちなみに、もうひとつは
カスリを売りにしながら敵弾がカスリに適さない散弾でシステムを活かせてなかった。

**名前は開発中のものです。** · 02/01/02 01:30

>キーボードのキー割り当て
決定：スペース
取消：アルファベットキー（最下段）全部
っつーのはどうよ。

#キーコンフィグに頼らずとも、手のポジションを
#変えられる配置が理想と思われ。
#↑は一例。改善の余地多々あり。
#とりあえず左右両利き、ノートPC対応が必要か。

**名前は開発中のものです。** · 02/01/10 19:50

ゲームのバリアフリーを考えると、片手だけで操作できるインタフェィスは
今以上に追求されるべきだと思うがどうだろうか？

**名前は開発中のものです。** · 02/01/10 22:22

ショットボタン無しで勝手にフルオートのシューティングはどう？
たばこ吸いながら出来るからヤキソバン喜びそう

**名前は開発中のものです。** · 02/01/10 23:13

>>166
「親父王」がそう。
有名なソフトなんで検索すれ（手に入ったとしても98用だから環境が無いかもしれんが）

**名前は開発中のものです。** · 02/01/10 23:14

携帯ゲームでなきゃ片手で操作できる必要も感じななったが
他のことをしながら遊べるから結構便利かも知れない。

身体障害者対応の意味なら片腕だけ考えても無意味だろうな。。

**名前は開発中のものです。** · 02/01/10 23:20

Palm版のザナックとスターソルジャーはオート弾出に
対応してた。
片手で遊ぶためと言うよりも、人によっては自機の移動だけで両手
が塞がるからなんだろうけど。

**名前は開発中のものです。** · 02/01/10 23:21

ムービーに字幕入れるようにしたって誰か言ってたな。

**名前は開発中のものです。** · 02/01/10 23:33

>>166
「永々王」もそうだったような。
しかも敵に近づくと自動敵に武装がパワーアップする。

**名前は開発中のものです。** · 02/01/13 04:38

ゲームのバリアフリーを考えると、ってすげー偽善的に聞こえるな。

その場合、少なくとも、両手を使うよりも片手の方が使いやすいって
いうシステムじゃなきゃ却下だな。

普通の人間がやって、なんでこのゲームは片手しか使わないんだ？って
疑問に思うようなものはだめってことで。

前にwarpが音だけの作ったけど、あれって別に視覚障害者対応で
ああしたわけじゃないでしょ。それと同じこと。効果的ならよし。

**名前は開発中のものです。** · 02/01/13 04:40

ViaVoice

**名前は開発中のものです。** · 02/01/13 04:42

偽善も善のうち

**名前は開発中のものです。** · 02/01/13 06:24

RPGはADVたいてい片手で出来る。健常者だが楽だね、あれは。
俺は片手コントローラを作った奴が偉いと思う。

**名前は開発中のものです。** · 02/01/13 12:26

魔導物語なんかはテンキーだけでさくさくすすめて気持ち良かった
まぁ、マウスオンリーのゲームを片手と考えればたっぷりあるんだが…。

マウス、シビアな動作が出来ないのがきついね…。

**名前は開発中のものです。** · 02/01/19 11:34

http://game.2ch.net/test/read.cgi/gamedev/1005148751/
の254-296あたりから移動っと。

>4方向ですらまだまだ価値はあるだろおに、と

デジタル４方向（あるいは２方向）には８方向に含まれる問題はないと思う。
上下左右、東西南北と感覚的に普通だから。
例えば、ゼビウスでトーロイド相手に間合いを取るのは
８方向ゲーマーの特殊技術だという認識は必要かも、と思う。

>マウスで誘導する、んだとなんか客観してしまうんだよな。

あ、それはナイスなポイント。
ワタシもRPGなんかでは「このキャラをどこに動かすか」じゃなくて
「自分がどう動くか」のほうが好みかな。

**名前は開発中のものです。** · 02/01/19 13:46

平面上の自由移動を、8方向デジタル移動に脳内で変換するスキルって感じかな。

**名前は開発中のものです。** · 02/01/19 14:58

えー、私も>>177スレで８方向(ﾟ∀ﾟ)ｲｲ!!派だったものですが…

ではパッド使用が一般的ではない*PC*において、「客観的マウス誘導」を
避け、主体的で良さげな操作を実現するには、どうすれば良いと思いますか？

もちろん従来の、テンキーによる８方向やマス目移動の採用は
とても有効だと思いますが、正直そろそろ時代遅れの感は否めないと思います。
マウスオンリーのソフトユーザーにはちと辛いですからね。テンキー。

**名前は開発中のものです。** · 02/01/19 15:12

>179
マウス誘導以外は難しそう。
マウスはレバーみたいに倒しっぱなしって状態がないし、
転がしつづけるとしても物理的な広さも問題になる。
相対移動量をそのままキャラクタの移動量にした場合、
マウスを頻繁に動かさないといけないし。
（これはトラックボールだったら若干楽。肉体的には相当疲れそう）

それでも無理にやるなら、前回の相対移動量を足しつづけることも考えられる。
完全に止まることを考えてある程度の遊び（というか閾値）を設ければよさそう。
ただ、マウスを動かしていないのに動きっぱなしになるので、ここで賛否が出そう。

**名前は開発中のものです。** · 02/01/19 15:36

＞相対移動量
これ調整が難しいね。
感覚的には8方向操作に慣性をつけたような感じになる。
人間って「きっちり同じ量元に戻す」みたいことが瞬時にしにくいみたい。

**180** · 02/01/20 01:35

>181
うーむ。難しいね。
例えば移動量が0～255まで取れるとしたら、
8で割って32段階とかの移動量にすれば良さそうだけど、
今度は微妙な操作ができなくなるし、境界値の問題も出てくるね。
感覚的には1段階だけマウス動かしたつもりが、数値の上では2段階で動かしていた、とかの。

**名前は開発中のものです。** · 02/01/20 14:30

少し前、こーゆー操作を試した事がある。
マウス表示は矢印状。マウスを動かした方向に矢印が向く(八方向)。
左ボタンを押してる間は、矢印の方向にキャラが移動する。

**183** · 02/01/20 15:29

static BYTE gbMouseKey;
BYTE GetMouseKey()
{
return gbMouseKey;
}

#define MOUSE_MOVE 8
#define MOUSE_MOVE_BK 3

#define GET_KEY_UP 0x01
#define GET_KEY_DOWN 0x02
#define GET_KEY_RIGHT 0x04
#define GET_KEY_LEFT 0x08
#define GET_KEY_MOVE 0x0f

void OnMouseMove(HWND hWnd,WPARAM wParam,LPARAM lParam)
{
BYTE key=0;
int i;
static lParamBk[ MOUSE_MOVE_BK ];
WORD xPos,yPos,xPosBk,yPosBk;
xPos = LOWORD( lParam );
yPos = HIWORD( lParam );
xPosBk = LOWORD( lParamBk[ MOUSE_MOVE_BK - 1 ] );
yPosBk = HIWORD( lParamBk[ MOUSE_MOVE_BK - 1 ] );
i = MOUSE_MOVE_BK;
while(--i)
{
lParamBk[ i ] = lParamBk[ i - 1 ];
}lParamBk[0] = lParam;
if( yPos + MOUSE_MOVE < yPosBk) key = GET_KEY_UP;
if( yPos - MOUSE_MOVE > yPosBk) key = GET_KEY_DOWN;
if( xPos + MOUSE_MOVE < xPosBk) key |= GET_KEY_LEFT;
if( xPos - MOUSE_MOVE > xPosBk) key |= GET_KEY_RIGHT;
if( key )gbMouseKey = key;
}
ソースの作成日時を見たら、1998/ 8/17だった……鬱

**名前は開発中のものです。** · 02/01/20 18:10

>183
それモロにUltimaOnline

**183** · 02/01/20 18:12

うグゥ・・・

**183** · 02/01/20 18:15

しかもよく考えると、atan2を使えば・・・
過去のコードなんて、出すモンじゃないな。

**名前は開発中のものです。** · 02/01/21 18:12

>>179
これはどうだろ？

画面の一部が円形の操作板になっていて、
操作板の中でマウスボタンを押すと、
中心点からの位置と距離で、
キャラの移動方向と速度が決まる。

**名前は開発中のものです。** · 02/01/21 18:48

>>188
なかなか良いと思うが、それだと操作円ばかりに目が行ってしまうので、
キャラを操作しているという感覚が少なくなるよな、きっと。
円の中心＝操作対象キャラの立ち位置ならば、問題無いけど。
つーか、それが一般的に採用されている方式だな。逝ってくる。

**名前は開発中のものです。** · 02/01/21 19:02

>188
コンソールパネル上は絶対量で移動する
（画面上に視覚的な「中心」がある）のに
マウス自体は相対的に移動するもの
（その時点でのマウスの場所が「中心」）だから
感覚を掴めるまでかなり時間がかかると思うぞ
ジョイスティックなら手を放せば「中心」でわかりやすいんだがな

更に移動のためだけに「操作円へマウスカーソルを合わせる」
というステップが増えるのは
ユーザーに対して優しくない設計ではないか？

**名前は開発中のものです。** · 02/01/21 20:09

話聞いてるとマーブルマッドネスの事を思い出した。でもあれやった事無いんだよなぁ

**190** · 02/01/21 20:31

今読み返してみると変だな・・・

たぶん漏れが危惧しているのは
　キャラクター＜－＞入力デバイス
というプロセスでさえ、「直感的でない」と不満を言う人がいるのに
　キャラクター＜－＞コンソールパネル＜－＞入力デバイス
となると余計複雑になりはしないのか？という事だろう

元々あんまり頭良くないの　御免ね

**名前は開発中のものです。** · 02/01/21 21:42

>>192
いや分かる分かる。思考とキャラ動作を、いかに結合できるかが肝だよね。
例えば「アンニュイな表情をしつつ爪先立ちで前進」と、頭で思った瞬間
キャラがそう動くのが理想ですよねぇ。しかし現状ではそれは不可能なわけで…。

そこで第１に単純化を図るわけです。上記の例で言うと、アンニュイな辺りを泣く泣く諦め
単に「前進」にしたり。これをやるほど自由度が下がる代わりに、思考との結びつけが容易になります。

そして第２に、思考からキャラへの伝達が、なるべく直結するようにインターフェイスを考える、と。
>>192さんの言う通り、ここが煩雑なほど、プレイヤーがもどかしく感じるわけです。

**193** · 02/01/21 21:43

この見地に立つと…
>>180さんのアイデアは、32段階の自由度が或る（0か1かの動作に比べ複雑）
そして伝達直結度は、「思考→マウス移動」

>>183さんのは、理解しやすい１段階（しかし不自由）
伝達直結度は、「思考→マウス移動→マウスクリック」

>>188さんのは、非常に自由度が高い（その代わり複雑）
そして「思考→コンソールパネル視認→マウス移動→マウスクリック」

**名前は開発中のものです。** · 02/01/22 12:37

マウスでキャラクターを操作するのは、そもそもマウスカーソルが画面に表示されている時点で
すでにダイレクト操作感が無いな。
やはりNintendo64～のアナログスティックがいいかと。
アナログスティックは、そもそもPC用が元祖であり本家であるのだし。

アナログスティックを持ってない場合はマウスで代用。
右クリックを押している間はマウスカーソルを消し、マウスの移動をアナログスティック操作の
ように扱う、というのはどう？

**名前は開発中のものです。** · 02/01/22 13:54

>195
操作感悪くてストレスたまると思われ。

アナログ必須にするか、デジタル入力＋shift（ボタンでもいい）で移動量が変わるとかした方がしっくりくる。

**名前は開発中のものです。** · 02/01/22 17:46

>>195
マウス操作でマウスが見えないとなると、チト問題がね。
ゴムボールマウスだと、マウス移動量と、
マウスカーソルの移動量が、等価にならんのよ。
まあ、マウスは消耗品だから、１、２年も我慢すれば、
光学マウスが主流になるかもしれんケド・・・

**名前は開発中のものです。** · 02/01/22 17:48

>>193
そだね。
ＡＶＧよりＲＰＧがウケる理由も、これで説明できる。
メニューで移動先を選択する方が操作としては楽なのに、
わざわざキャラを動かして別の場所に移動する方が、
感覚的にはプレイヤーとキャラの距離が近い。

**名前は開発中のものです。** · 02/01/22 19:05

マウスとキーボードの双方に対応する場合、苦労が多いですね。

キーボードの場合は「フォーカス」が当たっている物を
カーソルが指し示しているなり枠が光るなりしなくちゃなんないけど、
マウスの場合はかえってうざい場合もある。

あと、キーボードの場合はキーを押した後に「やっぱりやめた」は
原理的にできないですけど、マウスの場合はそれも可能ですし
（ドラッグして押したボタンの上からカーソル移動させる）。

自分の作ったゲームでは、最初面倒くさいんでキーボードだけに
対応してみたんですけど、ユーザーからの要望が多くてマウスに
対応させました。そうすると右クリックメニューを充実させたり
しなくちゃいけなくて、結構辛かった…

**名前は開発中のものです。** · 02/01/22 19:07

マウス以外の、タッチパッドやトラックポイントやトラックボール操作を
考慮してないゲームも弱りまくり。

「パッド前提の設計は不可だが、マウス完全前提の設計は許される」
との考えはお願いだから改めて欲しいな。お願いです。
どうせゲームの為に外付けするなら、パッドやSideWinder DualStrike
の方がいいし。

**名前は開発中のものです。** · 02/01/22 19:41

>200
マウスは○でタッチパッドetcがダメな設計とはいかに？
結構気になってみたり。

**名前は開発中のものです。** · 02/01/22 19:41

ダメな設計→ダメなゲーム

**200** · 02/01/22 21:43

>>201
>マウスは○でタッチパッドetcがダメな設計とはいかに？
ドット単位の細かい操作が必要なゲーム、
リアルタイム系でスムーズに素早く操作しないとついていけないゲーム、
アクションゲーム、シューティングゲーム、
そんなとこです。
そういうゲームはすぐ辞めるので具体名は記憶に残りませんが、、、

**名前は開発中のものです。** · 02/01/22 22:18

タッチパッドでドット単位の操作はフォトショで慣れてるなぁｗ
ｲﾊﾟｰﾝユーザーにそれを要求するのは間違っているだろうけど…

**188** · 02/01/23 14:19

>>193
ふーむ、
窓のスクロールバーを動かす時、
メイン画面を見て動かせますか？
って問題っぽいな。

**名前は開発中のものです。** · 02/01/23 14:20

そういえばPCゲーの場合は、枠で囲って、
枠の中でゲームを遊ぶパターンが多いね。

コンシューマだとあんまし無いケド、つーか、
コンシューマの解像度でやると、悲惨な事に・・・

**名前は開発中のものです。** · 02/01/23 19:27

>>206
具体例キボンヌ

**名前は開発中のものです。** · 02/01/23 22:39

MMORPGとかで
.＿＿＿＿＿＿＿＿＿＿＿＿＿____
|＿＿＿＿＿＿＿＿＿____________区||
|┌────────────┐|
|│　　　　　　　　　　　　　　　　　 │|
|│　　　 you are dead. 　　　 │|
|│　　　　　　　　　　　　　　　　　 │|
|│　　　　　　　　　　　　　　,.──┘|
|│　　　　　　　　　　　　／　　　　　|
|└────────'~　　　　　 |
| HP |-------　　□□□□┌─┐|
| MP l=====-- 　 □□□□└─┘|
￣￣￣￣￣￣￣￣￣￣￣￣￣￣
↑こういう風になってるヤツの事じゃない？

**名前は開発中のものです。** · 02/01/23 23:10

>>206
コンシューマだとファミコン時代に
よくあったかな。ハイドライドとか。
最近のコンシューマは解像度に飢えてるかのように
画面いっぱいでデザインしてるものが多い。
テレビによっては画面端が表示されない。

>>208
ﾜﾗﾀ。このレスの為に作ったの？コピペ？

**名前は開発中のものです。** · 02/01/23 23:16

枠になぜか彫刻とかあるやつか。
あれ画面ちっちゃくて迫力ないから嫌だな。
横長になりやすくて見難いし。

**208** · 02/01/23 23:22

>209
文章力ないからAA描いた方が的確に伝わると思って・・・

>210
そういう意味ではUOのビッグウィンドウシステムは秀逸だったな
ウィンドウモードで起動した場合に、ゲーム画面は広がらず
黒いの余白が広がって、そこへステータスバーとか置いておけるアレ

・・・やっぱUOてスゲーや

**名前は開発中のものです。** · 02/01/23 23:31

画面に出す情報を少なくした方がユーザーにとって対処しやすい事もあるかも。
…具体例全然思いうかばんけど

**名前は開発中のものです。** · 02/01/23 23:43

ウチは、解像度が細かければ(640×400以上)、
枠があってもあんまし気にならないなぁ。

**名前は開発中のものです。** · 02/01/23 23:48

PCは800ｘ600が標準になりつつあるしね。
小さい文字でもクッキリ見えるし。

**名前は開発中のものです。** · 02/01/24 00:14

800x600かぁ、ドット打ちが大変そう・・・

**名前は開発中のものです。** · 02/01/24 00:16

厨房な質問だけど、昔のゲームの枠って、
背景スクロール時のクリッピング処理を端折って、
マスクだけして高速化してる、とかではないの？

説明下手でスマム・・・

**名前は開発中のものです。** · 02/01/24 00:39

>>216
単に描画エリアを狭くしたいだけじゃないかなぁ？
昔のゲームは全部8ドット単位だったわけで、クリッピングは関係ないっぽいかも。
あと、必要な情報は全て画面上に表示されていたほうがインタフェース的にはいいと思う。
画面のダイナミックさにはかけるけどね。だからソーサリアンは全画面なのかなぁ？

**名前は開発中のものです。** · 02/01/24 00:47

>>217
パックドピクセル方式とカラープレーン方式のフレームバッファとか言っても分かる人はもう少ないとか？
昔のゲーム(88とか98あたり)はダブルバッファリングすらしてないはず。
キャラクタ同士の重ね合わせがウリになった時代があったわけだからねぇ。

**名前は開発中のものです。** · 02/01/24 02:07

>218
98はまだしも、88にゃバックバッファ作るメモリなんかなかったしねぇ。
98は２画面もってたから事実上ハードでダブルバッファが可能だった。CPUパワー的に実用的かどうかは置いといて。

**名前は開発中のものです。** · 02/01/24 09:49

>>219
98で2画面持ってるのは、低解像度モードのみじゃなかったっけ？
もううろ覚え。

**名前は開発中のものです。** · 02/01/24 10:30

>218
andとorでの重ね合わせだからねぇ・・・

**名前は開発中のものです。** · 02/01/24 10:51

>単に描画エリアを狭くしたいだけじゃないかなぁ？
スクロールって言ったら、ハードウェアスクロールではない差分書き換え
だったからねぇ。
ソーサリアンとか差分を極小化するように配置されたマップだったよな…

**名前は開発中のものです。** · 02/01/24 10:58

>>220
640x400/16色でも２面使えたはず。
640x200だと、１面をさらに上下分割して４面だったかな

**名前は開発中のものです。** · 02/01/24 11:08

>220
どっちの画面に描画する場合も、
同一番地に書き込みしていた事は、
覚えてる？

**名前は開発中のものです。** · 02/01/24 11:26

>222
98でハードウェアスクロールなゲームというと、
ファーランドストーリーぐらいしか覚えてない。

**名前は開発中のものです。** · 02/01/24 11:41

>>223
>640x400/16色でも２面使えたはず。
VMはVRAM増設が必要だったか。
VMより前は(U含む)1画面分しかVRAM持ってなかったような。

>>225
98だと、ハードウェアの縦スクロールは1dot単位なので、そんなのはゴマンとあった。
縦シューは大抵使っていたのでは。
横の表示開始アドレス変更は16dot単位？なので表裏で8dotずつずらして8dot単位の
ハードウェアスクロール。

そんなことより、ジジイはジジイスレを立てたほうが良いと思われ＞ｵﾚﾓﾅｰ

**名前は開発中のものです。** · 02/01/24 12:07

　N88スレの不人気ぶり見てもわかるように、この板はあんまり
ジジィに優しくないな。
　長老さんたちはさっさとi4004板に隠居しろってことか。

**名前は開発中のものです。** · 02/01/24 13:14

「レトロ・ゲーの技術について語るスレ」でも建てるか？

**219** · 02/01/24 13:18

20台前半なんだが、もうジジイか・・・逝って来るYO。

**名前は開発中のものです。** · 02/01/24 14:41

俺も充分20代前半の話題だと思ってるけど。ただスレ違い…？(w

**名前は開発中のものです。** · 02/01/24 17:32

スレ建てました

「レトロ技術を語るスレ」
http://game.2ch.net/test/read.cgi/gamedev/1011861036/l50

02/01/24 17:42

中央高等学院の従業員「西部」が女子トイレに闖入し
汚物入れを物色して女子生徒の使用済みタンポン・ナプキン等を
個人的に収集しているというのは事実。

中央高等学院では
生徒及びその保護者の個人情報を名簿図書館等に売却しています。
中央高等学院 http://chs-f.com/index.html 中央高等学院福岡校
http://www.chuo-school.ac/

**名前は開発中のものです。** · 02/02/07 14:20

あげ

**名前は開発中のものです。** · 02/02/08 05:00

ロストワールドのインターフェイスで
ＳＤガンダム・ガチャポン戦記が遊べたら面白そう。

**名前は開発中のものです。** · 02/02/17 12:04

メニュー系の操作性を良くするにはどうするのが良いだろう？
あんまり階層を深くしないようにしたいんだけどたくさんいれる
必要があるからなぁ。
FFXIβはメニュー多すぎてわけわからなかったし。

**名前は開発中のものです。** · 02/02/17 16:35

>235
ゲームのシステム自体を複雑にしなければ、メニューも複雑にならないと思われ。

**名前は開発中のものです。** · 02/02/17 17:40

>236

そうなんだけどネットワークゲームとかだとどうしてもシステムが
複雑になりがち…。PCはキーボードあるから良いけどね。

**名前は開発中のものです。** · 02/02/20 21:54

PCの場合、アクション性(リアルタイム性)が高いものが多いのもあって、
1機能を1キーに割り当てる傾向があるよね。
覚えたら速いからいいんだけど、さすがにパッドじゃ出来ないよな

**名前は開発中のものです。** · 02/02/20 23:18

個人的に各キーに細かく機能を割り当てているゲームは苦手。
覚えりゃいい、慣れりゃいいってもんじゃないと思うんだ。

そりゃ、慣れたら速いのはわかるけどさ…。

**名前は開発中のものです。** · 02/02/21 06:26

キー数の階乗だけ割り当てられるじゃねーの？

**名前は開発中のものです。** · 02/02/23 05:11

更に押す長さや連射などで…とか。無理だっつーの

**名前は開発中のものです。** · 02/02/23 15:11

>>236
そうとも限らん。
例えばFC版DQ1はシリーズ中で1番シンプルなシステムのクセに、
操作は一番複雑。

# 話す→東西南北とか。

**名前は開発中のものです。** · 02/02/23 19:44

>>242
それは冗長なのを複雑だと言ってるだけ

**名前は開発中のものです。** · 02/02/23 20:54

>242
揚げ足取って楽しいかい？

**名前は開発中のものです。** · 02/02/23 21:46

ドラクエってシリーズ通して同じシステムじゃん
インターフェースに関しては洗練されていってると思うよ

**名前は開発中のものです。** · 02/02/23 22:45

そうは思わんな。
メニューの「話す」とか「調べる」とか、
冗長な部分は大分残ってる。

**名前は開発中のものです。** · 02/02/23 22:54

>>246
そんなもんつかわねーよ
むしろメニューださねー

**名前は開発中のものです。** · 02/02/23 23:25

>>246
ゲーム初心者にも分かりやすいが、ともすれば冗長なインターフェイスと
初めてだと分かりづらい代わりに、便利なインターフェイス。

洗練されたインターフェイスを目指すなら、この２通りは必ず用意するべきだろう。
ドラクエとて、冗長な部分は「残ってる」のではない、残してるのだろうて…。

**名前は開発中のものです。** · 02/02/27 16:58

なるほど。それはいえてる

**名前は開発中のものです。** · 02/03/09 10:13

話すと調べるが無いと、メニューが淋しいからでは？（ｗ
つーか、メニューの選択子って、多いと重要そうだが面倒だし、
少ないと簡単だが重要っぽく見えないし。

**名前は開発中のものです。** · 02/04/12 16:23

メニューを増やしてプレイ時間を稼ぐのは、どうか。

**名前は開発中のものです。** · 02/04/17 00:09

そういや、メニューやメッセージボードを開く時、
エフェクトを加える事で0.25秒ほど稼げるね。