15 replies to this topic

[Yal]

Background: I want to control the head of a First-Person Shooter game so that when you move the mouse around, you assign values to two variables, representing the x and y position of the mouse. Then I take those position values and calculate the angle of the character's head. Also, holding the mouse still near the center of the screen should stop the movement, allowing you to focus in the direction you're walking, aiming properly, and stuff.

Problem: I don't know how to do is in the best way.
What I've Tried: Many examples uses window_mouse_get_x() and window_mouse_set() functions to get the mouse into the center of the screen. However, these affects the mouse position, meaning that you can't click stuff outside the center of the game window. THAT IS REALLY BAD AND I DON'T WANT TO USE THIS METHOD BECAUSE OF THAT. If you have a suggestion how to work around it, that's OK. But I want to have some suggestion of another way to do this, that does not change the mouse position.


What would you recommend? What are you doing in your FPS game?





For your infoes, this game is gonna be similar to Metroid Prime, so there's gonna be no sniper weapons and stuff, aiming won't be very important, and so on; I'd prefer a stable (non-jittery) system over a precise.

Edited by Yal, 27 March 2012 - 05:45 AM.

[norisak]

That is the only way to do it, you just have to turn it off when you pause the game, aka. only use window_mouse_set when you are in-game and need to control the camera.

[Zeddy]

That is the only way to do it

There's never a single way to do something, but I do agree it's the best way.

You could try a similar system to some Wii and NDS games such as The Conduit and Metroid Prime: Hunters. This system is also used in optional control schemes of certain PC games such as X3: Terran Conflict and Amnesia: The Dark Descent

1. Render the mouse pointer
2. Treat the mouse like an analogue stick where having the mouse at the center of the screen is equivalent to leaving the stick untouched. The character turns towards the mouse pointer.
3. You'll want to provide options for deadzone and sensitivity.
4. Weapons and such shoot at the mouse cursor rather than the center of the screen. The cursor may or may not be used to click and interact with the environment.

Note that this system isn't very widely spread for a reason. The traditional, cursor-hiding, forced-mouse-centering system is used because it offers the best in intuitive control, accuracy and speed. Using the mouse-as-joystick approach should be done with good reason, such as in X3 where it's because you control a spaceship and it would be gamebreaking to allow you to turn your giant cruiser around on a dime in an instant but painful to repeatedly move your mouse for half a minute in order to do so. In Amnesia it was used because the cursor itself was used to pick up and move stuff and that was sometimes handier with a 'loose' cursor. In both games the feature can be toggled with the press of a button.

[TheSnidr]

In my level editor I control the camera with the mouse while holding the right muse button. While I'm doing that, the mouse is reset to the middle of the screen every step. When I release it again, I can click on other stuff. Perhaps that's an idea?
Letting the mouse leave the game window while controlling the player is generally not a good idea. If you accidentally click, the window will lose focus

[Yal]

There's never a single way to do something, but I do agree it's the best way.

You could try a similar system to some Wii and NDS games...

Letting the mouse leave the game window while controlling the player is generally not a good idea. If you accidentally click, the window will lose focus

Hmm... I'm not so worried about running the game in windowed mode as I am about e.g. the game crashing and locking the mouse so that controlling the Task Manager gets difficult. Also, I can't just assume my players won't ever run my game with all other applications closed. The first time I test played the game, I accidentally moved focus to a Explorer folder window so that it covered the center of the game screen, and then I couldn't click it to regain focus. I eventually closed it down using the task manager.

Also, I can't run the game in debug mode without mouse freedom either, since you can't Alt-tab to the debug console.




My current idea is something like this:

- I save the previous mouse coordinates each step
- Then I do my calculations using the saved position and the old position
- To avoid the mouse "hitting the ceiling" when at the edge of the screen, I will move the mouse ONE PIXEL towards the center of the screen each step. This speed should allow the player to do other stuff.

[BattleRifle BR55]

What would you do to have the game differentiate between the mouse actually being moved, and it just re-centering? It looks like the camera would always be moving with that approach.

Avoiding a locked mouse during a crash is certainly important in some way, but personally I don't think your focus should be on it so much. When this would happen to me and I didn't want to use the keyboard to kill it via Task Manager, I would just pound the keyboard until the kill message came up.

I think you should just keep it the traditional way - TheSnidr's way is what I would recommend, and then fine-tuned to your need.

[Yal]

What would you do to have the game differentiate between the mouse actually being moved, and it just re-centering?

Can't you figure something that simple out yourself? I would move the previous coordinates the same amount of pixels that I move the mouse, which means that if the mouse is not moved by the player until the next step, its coordinates will be equal to the previous coordinates.

The main issue with the mouse here is not the player; for all that I care, the players doesn't exist at this stage. I'm thinking about me, because if I have a game that messes around with my IO, I get trouble developping it.

Edited by Yal, 01 March 2012 - 11:59 AM.

[BattleRifle BR55]

I don't know what I was thinking.

Going back to what I was saying, what issues do you plan on running into that this is that much of an issue? Surely you don't need a workaround for something that (in my experience) rarely happens? I can't really think of a solution that won't cause any window focus issues and whatnot, while trying to avoid being frozen during a crash.

[Zeddy]

Hmm... I'm not so worried about running the game in windowed mode as I am about e.g. the game crashing and locking the mouse

If the game crashes, won't the step event that moves the mouse stop being called?

[BattleRifle BR55]

Hmm... I'm not so worried about running the game in windowed mode as I am about e.g. the game crashing and locking the mouse

If the game crashes, won't the step event that moves the mouse stop being called?

It's been years since it has happened to me but I recall my mouse getting locked up during crashes. I'd either have to wait until Windows would let me respond, or perform a tricky CTRL-ALT-DEL.

I could be delusional, but I swear I remember that.

[Yal]

Even if the game won't crash very often, setting the mouse coordinates each step would efficently lock me out from being able to use the Debug Mode. And it's really something you can't live without when you start making complex games (especially when stuff start to depend on variables a lot, local or not, being able to monitor arbitrary stuff on a whim is really useful); it's saved me lots of time more than once.

[TheSnidr]

Even if the game won't crash very often, setting the mouse coordinates each step would efficently lock me out from being able to use the Debug Mode. And it's really something you can't live without when you start making complex games (especially when stuff start to depend on variables a lot, local or not, being able to monitor arbitrary stuff on a whim is really useful); it's saved me lots of time more than once.

Did you really only read the last part of my post? Anyway, if you set the game to freeze when the window loses focus, you can simply press ALT to freeze the game and thus free your mouse

Edited by TheSnidr, 01 March 2012 - 02:27 PM.

[Follomania]

I usually just assign a key to toggle on/off the mouse-setting while I'm developing a game. This works well for using the debug window as I just need to press 'M' (or any key I'm not using elsewhere) and my mouse is free. Then I open the messages window and press 'M' again and I'm back to controlling my camera. This along with checking the 'Freeze game when window looses focus' typically ends all of my mouse-sticking woes.

[icuurd12b42]

right. so that would be

headyaw = (window_get_mouse_x()/window_get_width()-.5) * 90;
headpitch = (window_get_mouse_y()/window_get_height()-.5) * 90;

that would make him turn his head left and right relative to the mouse on screen.

but you want to turn towards that...

headyaw += (window_get_mouse_x()/window_get_width()-.5) * maxturnspeed;
headpitch += (window_get_mouse_y()/window_get_height()-.5) * maxturnspeed;

[Yal]

Did you really only read the last part of my post?

No. But since this is the actual gameplay, I sort of found the idea of holding down one button to aim would be too counter-intuitive for your average FPS player to grasp.

I've messed around with my workaround, and I finally ditched it because there was no optimal mouse-reset speed that let you turn properly AND let you move the mouse around "in the background". So I've just introduced one key to turn off mouse checking, and only if the source file is present, making me the only one that can access the feature.


But thanks for the ALT tip! Never thought anout that.

[ean]

If you have played Metroid Prime 3, you can copy the aiming system from that. But you will need to understand how to use 2d to 3d first. Of course, the real reason you are asking for it is so you can access debug mode. In that case all you would need to do is have a toggleable variable, that toggles when a key of your choice is pressed. If the variable is zero then the mouse is not reset, otherwise the mouselook would continue as normal.

Edited by ean, 24 March 2012 - 09:00 PM.