TIGSource Forums

This is just a game prototype, so I'm posting there rather than feedback...

I'm having some issue with my mouse controls in this game, where the mouse controls the velocity of the player entity.  The idea is to collect all the green objects.  Because I loose all mouse info when it leaves Flash, it's easy to loose control, especially if you try and whip the player across the screen.  I've got a couple of solutions you can toggle in the demo. 

Does this control work at all or is it completely annoying?

http://www.mechascientific.com/velocity/Main.html

[UPDATE]
mouse visibility toggle added

[UPDATE]
new controls
http://www.mechascientific.com/velocity/Main2.html

The basic idea with velocity movement is good and I think you have the makings of a good mechanics, but I'm sorry to say that the current implementation is atrocious. The worst offender is that there's no sense of association between the mouse and the entity; and though you learn how it works over time that the positions of the entity and the cursor are unrelated but the mouse movement affects the entity if confusing at best, and annoying at all other times. An alternative interface that doesn't suffer from the cursor position problem would be that the mouse f.i. stretches an arrow the base of which is attached to the centre of the screen and which returns to the centre when the mouse isn't moved.

You might also try making the mouse invisible and re-centering it each frame. That way it doesn't distract from the red ball, and it doesn't ever leave the screen.

good point, I originally had the cursor hidden, and started to show it because I realized I could manage my mouse movement better if I knew when my cursor was getting close to leaving the flash app.  I've updated the app to toggle mouse visibility.

ideally, I would reposition the mouse to the center after calculating velocity changes, but you can't move the mouse programmatically in Flash. 

Ouch, then you have a nasty problem, since your interface requirements seems to conflict with what Flash allows you to do.
/me gives ninjascience a hankie

I moved to an approach where the player entity follows the mouse rather than the mouse affecting it's velocity.  The control is a little tighter, which is not what I want, but doesn't suffer from the same usability problems in flash.

I also added bullets on mouse click.  The bullets base their direction and velocity off of the player movement.

http://www.mechascientific.com/velocity/Main2.html

In one way I like this interface and believe that it would work well in some games. On the other hand I feel it is less special and interesting than the potential in your previous ones - this new version is basically a normal mouse cursor with deceleration.

I criticised the previous version for disassociating the mouse movements from the player entity, but I think this version, quite on the opposite, has too *little* distance, since to me that the flavour you seek seems to revolve around a certain indirectness of control.

I couldn't agree more.  I just don't think it's practical to implement the other idea in flash except in full screen, single monitor mode.  Ideally I could detect mouse movement (as opposed to cursor movement) in Flash, even if the flash swf doesn't have focus.  Then even if the cursor moves to the screen bounds, if the physical mouse is still moving, I can control the player.  Either that or set the mouse position programmatically as mentioned earlier, but that seems like it's own usability nightmare in any kind of program.

The new control scheme is less compelling, maybe because it's easier, but perhaps I can tweak the variables to give it the less direct control feeling of the original scheme.

The best solution to this that I can think of is making a circular area in the center, that acts as a trackball for the cursor. It's the same as before, except that the player would have room to maneuver the cursor outside of this circle.

good but


please NO

@adj

so the player only moves when the cursor is inside the circle?

@eclipse

I see how this way adds some difficulty, but that was my goal.  me bad?  :epileptic:

I think this actually might work, but you need a very good model/sprite so that the direction of fire is obvious.

No, there would be some inertia at play as well, I imagine. Just like a proper trackball with some weight and nice ball bearings.