Discussion Possible fixes for combining FP FreeLook Camera and UI Interaction?

So my game uses a first person camera setup, where the mouse movement directly translates to rotation of the player body and the camera's up down view, as a FPS would.

My game isnt a shooter, but thats besides the point. Its a first-person game.

The problem or issue that I encounter is that the player cannot use his mouse to access his inventory, swap items around, equip a sword, etc. Ofcourse this is obvious as the mouse needs to be hidden and locked for FreeLook to work correctly.

One possible solution is to use an Input Key, that needs to be held down, in order to unlock and show the cursor.
While this Key is being held down, FreeLook will be disabled, so the player cannot look around. But the mouse will be unlocked and can be used for any type of UI interaction.

Another solution would be to use a Toggle Key instead, so it does not need to be held down all the time...

Is there any other solutions that you know of, or have experienced in other games? I unfortunately havent.

Any input appreciated, as always!

Thanks!

 

I haven't heard of other primary ways either... on a whim I dragged your question into ChatGPT4, just to see what comes up. Here is what Chat said:

https://chat.openai.com/share/2b04e5c5-476d-430f-8db0-d7dfc770c8c3

Chat is often fun to bounce ideas off...obviously it's only got so much to go on, and I can already see some of its solutions wouldn't apply in your case. But... AI is coming! AI is here!

 

Thanks Kurt, I apreciate your the AI's input. Even though it doesnt really say anything useful except for patting me on the back for finding the two only existing and useful solutions already (as far as we know).

...Voice Commands... lmao.. AI is coming, but voice recognition is atleast a decade old and still sucks...
Same goes for train automation btw, those things are on freaking tracks, and still AI cant manage/control them...

 

Amen. And it is getting worse. My 2014 Android google speech-to-text worked WAY better than the one in my phone does today. So much for AI.

In related news we test-integrated an OEM voice recognition card into Star Trek 25th Anniversary back in 1993 at Interplay Productions... our main QA guy had a very gruff voice and it simply ignored him, which simply made him more and more mad.

"Fire."
"FIRE!"
"Fire phasors."
"FIRE PHASORS!!!"

Good times, good times. Sorry I don't have any other ideas for your modal input needs.

 

I personally use enums as states, so say a state of "InGame" would run different code as a state of "InMenu", for mouse or keyboard Inputs, etc...

But any other way than that? I'm sure there are some, but I can't think of any.

 

Enums for trivial state machines is fine and dandy, I use 'em all the time. Here's the weapon states for my ATGM game:

Code (csharp):

1. public enum WeaponStateType
2. {
3.     INVALID,
4.     LOADED,
5.     SPINUP,
6.     FLIGHT,
7.     IMPACT,
8.     TERMINATE,
9. }

But enums break down if you want to serialize them.

Enums enums are bad in Unity3D if you intend them to be serialized:

https://forum.unity.com/threads/bes...if-not-do-something-else.972093/#post-6323361

https://forum.unity.com/threads/unity-card-game-structure.1006826/#post-6529526

It is much better to use ScriptableObjects for many enumerative uses. You can even define additional associated data with each one of them, and drag them into other parts of your game (scenes, prefabs, other ScriptableObjects) however you like. References remain rock solid even if you rename them, reorder them, reorganize them, etc. They are always connected via the meta file GUID.

Collections / groups of ScriptableObjects can also be loaded en-masse with calls such as

Resources.LoadAll<T>().

Best of all, Unity already gives you a built-in filterable picker when you click on the little target dot to the right side of a field of any given type... bonus!

My ATGM game, which uses both regular enums and ScriptableObjects, depending:



Appstore: https://itunes.apple.com/us/app/atgm/id1135587120
GooglePlay: https://play.google.com/store/apps/details?id=com.plbm.atgm
Android TV: https://play.google.com/store/apps/details?id=com.plbm.atgmtv

Itch.io: https://kurtdekker.itch.io/atgm

 

You do the same thing I do with leaving a comma on the last enum, lmao!

I don't know why I do that, I guess since I might always be adding a new state, and found there's no errors with leaving the comma there... That gave me a good laugh, thanks

Well I particularly mean with gameState, as I do certain background tasks whether splash screen, main menu, option menu, pause menu, etc... Mainly because of the way I have things setup, it's just way easier to check against(and faster for some reason).

But I'm sure I have old habits that need to die out, lol, but enum's are a common staple for me. So I'll still love them, until they fail me.

 

English is my second language and I have a thick Hungarian accent. Go figure. I threw my phone a couple of times when the "assistant" couldn't recognize what I wanted to say and there was no other way to make my choice. I hate this with fiery passion and it is a serious accessibility disaster. Given that my English is fairly okay, now imagine some people who don't even have that.

To the original question.... we usually pause the game when the pause menu, the quest log or the full-blown inventory shows up. It makes it easy to toggle the cursor and possible interactions. In the new input system it was made easy with

InputActionMap

s, you have separate map for game play and for the pause menu / UI interactions so just disable one and enable the other depending on going in and out of pause menu / inventory / etc.

 

Thats ok for a pause menu or a full screen UI/Inventory panel. However my game has many small panels that can be dragged across the screen like windows... I like having a mini representation at hand if the player wants it...
This is a small selection of the UI:



And some old prototypes:

 

The best way to do that (I think) either:
- have shortcuts for the displayed items from the inventory (like 0-9, like ability toolbars usually have, and in the full-blown inventory somehow you allow the player to elevate certain items onto this toolbar)
- or have a - and a + and an activate shortcut so you scroll items in and out of your small panel and you can equip/select with the activate shortcut (similar to the weapon switch in classic FPS games, like mouse scroll weapon switch)

The important thing is: think about how the game feels if you pause the free look and the player needs it for some reason (the game isn't paused). If it feels wrong to pause the freelook in any action the player can take to allow them to select stuff on the GUI, then you need alternative. Like toolbar or indicator icons stuff.

And do the window dragging on Pause time not in action.

 

Ohh, so you mean you want a "first person mouse move camera", and also have windows/tabs that can be moved around on screen? Or is there no "first person camera move"?

Just re-read the title... duh.. lol, sorry.

Yeah in that case I could think of "right clicking" mouse to stop camera movement, and allow you to move tabs at will, then "left clicking" on play screen will bring back FP mode

 

There is definitely first person mouse move camera, also known as freelook. But at certain times, the player wants to swap items in his mini inventory panel, so he wants to use the mouse in first person mode, basically the only solution so far is either a Toggle or a Hold key...

 

Can you not use mouse "right click"? as like a cancel(or B button for gamepad), for FP view. Left click on tabs to move them, then left click on the main view screen to go back into FP view mode?

This is of course assuming your free look doesn't need left or right click for major functions.

 

I am always irritated that the JSON standard does not tolerate that extra comma.

It's almost like the JSON people never even heard about computer-generated data!!

 

Nope cant do that unfortunately, as both LMB and RMB are used for input aswell in FreeLook mode.

I actually need several different Input states, or rather LockStates..
This is what I came up with now...

    public void SetCursorLock(LockMode lockMode)

    {

        if (CursorLock == lockMode) return;



        CursorLock = lockMode;

        switch (CursorLock)

        {

            case LockMode.Unlocked:

                Cursor.lockState = CursorLockMode.None;

                return;



            case LockMode.FreeLookLock:

                Cursor.lockState = CursorLockMode.Locked;

                return;



            case LockMode.CastingLock:

                Cursor.lockState = CursorLockMode.Locked;

                return;

        }

    }

 

Screen borders. Right before xb360/ps3 era, every game has to be 3d. And previously 2D isometric RPGs played with mouse has to deal with camera rotation. So, screen borders it was.
Easily can be done for 1st person view if game not that heavy on action, but obviously not applicable for consoles. Yet, if you insist on mouse centered GUI, you probably don't plan console release.

Example:

Mouse lock goes out of the window tho. So, it looks like everything pushes you to not engineering but gamedesign solution. Either make combat/interaction non-shootery, i.e. without locking mouse. Or make two control systems for combat/non-combat situation, so players will naturaly swap 'em, by putting out weapon.