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

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

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

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

**104** · 01/12/07 03:46

>PSO
ボタン配置はすごい考えたんじゃないかなぁ。アクション苦手なウチが
あれだけのボタンと機能を無理なく使えたのはスゴいなと思いました。
あとは >>124 さんと同じ感想もちましたね。
ダメな点はネットゲー板にいくらでも書いてあるからやめときます(笑)

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

このスレでいう、『インターフェース』は入力系オンリー？
出力系はスレ違いかな？ナムコのO.R.B.S.がなんか凄そうなんだけど…。

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

>122
シンプル1500のギャルゲーを見て思ったけど、
ノベルゲーで文字が動きながら登場するアニメが入ってるのは、
はっきりいって読んでいて苦痛だった。

小説読んでて、文字が動いて踊っていたり、自分が読むペースと関係なしに
行が順番に光っていたりしたら、そんな本焼いて捨てるぞ俺は。

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

>>126
微妙だけど、PCカテゴリである以上外部装置に関しては違うのかも。
たとえばボタンの割り振りや入力後の反応を語るのはスレの趣旨にも
合ってるけど、コントローラの形状を語るのは別問題という感じがする。
いや、語ってもらってもいいけど。

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

ロード画面の待ち演出に関する話題もここで良いでしょうか？

この辺って設計下手で苦痛なゲームほど記憶に残って、快適なゲームの
ロード時間を感じさせない演出、読込みタイミングとかの工夫が意外と
気付きにくかったりする。

覚えてる奴だとベイグランドストーリーのＯＰのロードタイミングは
かなりうまいと思った。

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

良質スレなのでageます

数値表示を全てゲージで表示するといい気がスル。
感覚的に理解する事に慣れたら効率が上がる。

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

>>130
お金もゲージで表示するのはどうか？
つーか、通貨の概念を無くしてしまえば・・・

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

>>130
現在／最大ＨＰを円グラフで表示したりとかもあると
減る時に強さを実感できそうだね。

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

>>132
円グラフは面白そうだけど、レイアウト難しそうだよな。
画面を圧迫する。

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

>>133
円グラフの大きさを変えて、複数重ねてみるとか。
内側の赤い円グラフはＨＰ、外側の青い円グラフはＭＰといった具合。

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

数字でいいよ

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

格闘ゲームのHP表示と同じにすれば良いんじゃない？
というか>130はそのつもりで言ったのでは？
>131 お金はコインとか札束が積み重なったのにするとか。

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

ファイアーエンブレムの体力をあらわす目盛りのゲージはよかった。
ダメージを与えたときの減り具合がよく感じられた。

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

数値表現を全てなくす方法は、なにもゲージにするだけではない。
魔導物語とか同じ人が作ったゲームは、それを意識してるし。

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

昔、武器の劣化を音で表現する事を考えた
が、効果音を作るのが思ったよりも大変で、挫折した
要するに、剣で殴る音が、ズバからゴスに変化し、
切れ味が鈍くなるワケ

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

>>135
数字は桁数が増えるとリアルタイムだとキツイ。

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

>>139
コレ、ネタとしては面白そうだから、誰か実現シロ！
漏れはやらんケド（ｗ

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

そもそもHPとか敏捷度とか、TRPGでつちかわれた計算量を減らす工夫
なんだから、せっかく早い計算機があるんだから
筋力とか握力とか動体視力とか血流量とか全部計算しろYO!と
鈴村くんが言ってました。

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

>>142　そんなにパラメーターあったらプレイヤーが混乱するだろうが！
隠しで持つ分には良いが、そこまでやる意味があるかも不明。
・・・と鈴村くんに言っとけ！（ｗ

**139=141** · 01/12/14 12:04

>>142は要するに、漏れに対する反論だと思われ

パラメータを単純に増やしても、単に面倒くさくなるだけだが、
パラメータを考えて増やすと、意外とゲームは面白くなる。

WanderWonderや西風の狂想曲には、
武器にＨＰがあり、使いすぎると壊れるが、
壊れる前に鍛冶屋で直すことが出来た。
D+vine[LUV]では武器を鍛える事ができ、
武器のLvを上昇させることで、
同じ武器を長く使う事が出来た。

**139=141** · 01/12/14 12:06

> D+vine[LUV]では武器を鍛える事ができ、
> 武器のLvを上昇させることで、

鍛冶屋で鍛えることで、
武器Lvを上昇させる事が出来る
って意味ね。

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

視認性という観点から俺も話題を出そう。

昔ネオジオの縦シューの製作をしていた時の話だ。
弾をバラ撒くタイプのボスキャラの出す弾の色を橙色にした。
俺は明暗差や暗いものが分からないタイプで目が悪いので、視認性を優先にして
パレットを設定した。

デザイナはそれを見て、「この弾は泡なんだから青にしろ」と言ってきた。
デザイナ＝開発課の課長だったので俺は仕方なくそうした。

その面の背景は真っ青な海だった…(鬱

**146** · 01/12/14 13:31

あと、アクションやシューティングだと
「ボスを倒す手順」もUIの内だと思う。

さすがにリテイクになったが
スロットが回る→数字のパネルがボス後方に並んでいて、
それで出た数字のパネルを正確に撃つ→
→ボスの無敵状態が一定時間解除解除
というのがあった。これ、シューティングのボスキャラの倒し方な(鬱

もちろん間違ったパネルを撃ったり、パネルを撃つ前にボスに弾を
当てたりすると、ボスは無敵状態のままで弾をばらまく。

アーケード(NeoGeo) だったので、これをインストラクションも
説明もなしでやろうとしていた。
独力で正確な倒し方を発見できるプレイヤーはまず出ないだろう。

この時点で俺は、この開発課にシューティングをまともにプレイした
奴はいないと見切った(当時入社三ヶ月目)

この手のゲームのボスキャラはどこから破壊すれば楽だとか点が高い
とかいう要素はプレイヤーに発見させていい。というかむしろそうする
べきだとおもう。

でも、プレイヤーに「ただひとつしかない倒し方」を探させるような
ことはしてはならないとも思うぞ。

あ、俺は元プログラマな。

**139=141** · 01/12/14 15:20

さらに補足

人は、それほど多くの情報を管理できるワケではない。
けれども、情報を階層構造状にして整理しておくと、
意外と沢山の情報を管理できる。

**139=141** · 01/12/14 15:20

例えば、普段プレイヤーは、武器のパラメータを意識せず、
武器のことを、ＰＣの所持品の一つとして、認識している。

しかし、新しい武器を見つけた場合は、
例えば、エクスカリバーを見つけた場合は、
武器のパラメータを比較する。

これは、エクスカリバーという物体を、
エクスカリバーという名前だけではなく、
攻撃力やその他のパラメータも含めて、
エクスカリバーという一つの個体として、
認識しているからである。

**139=141** · 01/12/14 15:23

例えば、普段、会社の社長は、部長の能力を意識せず、
部長のことを、会社員の一人として、認識している。

しかし、新しい部長が就任した場合は、
例えば、田島部長が就任した場合は、
他の部長と能力を比較する。

これは、田島部長という社員を、
田島部長という名前だけではなく、
性格や能力、個性、人望も含めて、
田島部長という一人の人間として、
認識しているからである。

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

>>147
それって、パズルゲームのような……
パズルメインのアクションゲームにすれば、あるいは……

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

質問あげ
昔オホーツク系ADVのキー配置に
・↑↓ = メニュー選択
・→ = 決定
・← = キャンセル(前メニューに戻り)
を用いたゲームがあって、個人的には便利だと思ったのでADVを作る際には
採り入れたいと思ったのですがこのスレをお読みの他の皆さんはどうですか？
片手オンリーで遊べるし、手があちこちに逝かないのでいいなというのが理由です。

あと、XZを決定キャンセルに割り当てられるようにしたいと考えていますが
(あくまでオプション扱いです)
どちらが決定でどちらがキャンセルになるのが自然でしょうか？

**名前は開発中のものです。** · 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
どっちの画面に描画する場合も、
同一番地に書き込みしていた事は、
覚えてる？