ah-ah, is this!

claxo on 2009/09/11 21:37

in this and others pyweeks I noticed that some games with 'move' in keys and 'aim' in mouse feel-ed not so god.
Strange, because I like FPS. 
While testing one of such games in this pyweek, I think I identified what the problem was:
  the move action must propagate to the aim
 
Note to me: test this hypo.

(log in to comment)

Comments

Cosmologicon on 2009/09/11 21:59:

What? Are you saying that when you press the right arrow to move your ship right 10 pixels, the mouse cursor should also move right 10 pixels? So you're controlling the crosshairs with both the mouse and the keyboard simultaneously? That doesn't immediately seem to me like it would be an improvement. But I also have trouble with the mouse + keyboard setup, so I would like to see the results of your test.

claxo on 2009/09/11 22:03:

@Cosmologicon : yea, mouse will provide the angle. Ok, I will do a demo and post a link.

RB[0] on 2009/09/11 22:39:

Erm, so, you point with the mouse, and then moving "up/forward" will move towards mouse?
Or do you mean, like Cos said, moving the mouse "aim" with the same keys you move with?

claxo on 2009/09/12 06:29:

well, here is a simple trial:
http://groups.google.com/group/cocos-discuss/web/aim2D.py

It maintains 3 enemies on the level, movements are WASD(strafe), aim and fire with mouse.
keys 1,2,3 will change between aim modes:
  1 : the one I suspected would be better, player moves propagates to crosshair, crosshair to player distance constrained to a fixed distance
  3 : the standard, crosshair follow the mouse
  2 : an hybrid, moving the player moves the crosshair, but the distance crosshair-player is not constrained.
 
Probably would be best to add some dangerous object to avoid or small passages, but maybe other day. 

To me it feels somehow better as in 1, but not to say 'oh, sow'
Maybe with some complications in the map the difference would be greater ( Im thinking in the eye travel player-crosshair needed to navigate and aim)   
 
Have a try, give your comments

cyhawk on 2009/09/12 15:44:

Very nice prototype! Number 3 feels the best to me, but this may be because I am used to it from the numerous hours spent playing games that use this control scheme. It would be even better if I could keep the button pressed to fire continuously (especially using a touchpad). I see several advantages to this scheme:
  • You can easily "circle strafe" an opponent that needs many hits to be killed.
  • You can move and aim independently — when you fire you usually want to hit something, so it is convenient to just point the mouse at it and fire, while dodging other stuff with your movement.
  • People have used a mouse before and they are used to it working like in scheme 3. The mouse cursor moving on its own is something unexpected.
Control scheme 1 is not unused in games either. But instead of a mouse it is used with a dual control pad. Perhaps it works better for some games (maybe for large waves of enemies that would be difficult to point at one by one).

claxo on 2009/09/12 17:55:

cyhawk, you got a good point with 'circle strafe'
A scheme can be better in one situation, less better in another I suppose.
By example, while chasing ( or chased and back-running) probably 1 or 2 will be better, needing less mouse correction to sustain the  aim.

Obliviously pro-133t-gamers will want to have all and switch on situation :-)