Official Controls

I know this doesn't have very high priority on the todo list, but I have a few suggestions about the controls.
I think, referring to the keyboard control scheme, that we could assign the camera movement to the mouse, so we could use the left mouse button as the attack button. During action moments the player might want to move the camera for better visibility while also being able to attack without having to change the finger position on the keyboard. As for the jump, we could simply assign it to the spacebar.

Also I presume the game will need a button to start a dialogue (I don't know if that's included in the "spacial action" category or not), but in that case the player will probabily not be surrounded by enemies so it could just be assigned to a normal, easy-to-find button as Enter (or we could make the spacebar/south button contextual and making it start a dialogue if close to a character and jump in all the other situations, but I don't really know about this, maybe it will just be more confusing)

 

I totally agree with this!

 

This would be a great default system, and to add to it I'd also like to work on abstracting it in such a way that the player can work with whatever control scheme they prefer. If I get the chance that is. Although I feel like the idea for the gameplay is still a bit vague in that we dont know what game feel we are going for

 

This seems like a strange choice, I have never played a game using this control scheme. How about we use mouse for orbiting?

 

The game will have a control remapping system so there is probably not much to think about as players will be able change the settings according to their preferences,however there will probably be default controls once the game starts (as far as i have read)

 

I tried the game with the current control shame (WASD and TFGH) which is really a strange choice of not using the mouse (and cause discomfort really easily) and I would vote on camera control with the mouse for keyboard input. If for some reason we would prefer to use the keyboard I would propose remapping to the arrow key instead

 

Why is there not a card deck for this request yet? I hate how the current control is, I would like it if we can add an option to switch from precise (mouse) camera control and manual (keyboard) camera control.

 

Everything right now is Subject to change and is completely for testing purposes only (as far as I've read) the input system, settings system and control remapping system is still being made as well.

 

I have made a quick fix for this awkward TFGH mapping. Please merge PR https://github.com/UnityTechnologies/open-project-1/pull/65

 

Left a comment: https://github.com/UnityTechnologies/open-project-1/pull/65#issuecomment-703322506

 

Sorry I haven't replied in a while. In our original idea, the game is either for joypad, or for keyboard.
Adding mouse for camera makes sense, but... what if we have 3 buttons? Jump, attack, interact, maybe a fourth? How would you handle that then? Q and E on the keyboard, for slow actions?

 

Q,E,F,R are some common keys for attack actions

 

Yeah, makes sense. So basically we're looking at:
- Complete set of controls on Gamepad
- Complete set of controls on keyboard (could be good for accessibility)
or
- Most controls on keyboard and some on the mouse (camera, main attack)?

And the player can choose between the three? Could it be?

 

Based on what you said in the Dialogue and Narrative thread on the rating, the fewer total buttons the better. Coz it'd be nice if my 4-year old could play it, right?

 

I think (as a gamer) the main controls such as running or fighting are better on keyboard but some actions like shooting guns are easier on mouse ,looking around or aiming are better on the mouse as well, as mouse is quite easy to handle,i think we should have a vote on this maybe?

 

Btw, I'd encourage to use InputActionReference instead of auto-generated class.
It's super clean, not requires manager and easy to remap at runtime

 

Here are my suggestion on player movement,
1. Use W and S to move forward and backward respectively.
2. Use A and D to rotate character left/right. The character doesn't move just rotates. This eliminates the need to use mouse to control camera. Also this will ensure that players dont feel any difference in the movement between desktop and consoles.
3. Using S moves character back but doesn't turn it around. We can use a separate key to instantly turn the character 180 deg along with the camera(Like in God of War).

Note:- If our character involves aiming and throwing projectiles at enemy or picking up/interacting with objects using mouse then fixing camera movement to mouse does make sense. In that case the above points may not be ideal and we would have to map the camera movement and aiming to the right D-pad in joystick which means we will be using conventional TPS movement system.

 

I would highly suggest to play the game if you haven't already as some controls are already setted up

 

@Megatank58

I did play the game. I just gave suggestions for an alternate approach. Was not aware that the controls were finalized. I went through the code strictly for educational purposes and want to know whether there were any particular reasons for going with inbuilt character controller and not the rigidbody based movement. Was it so because there was simply no requirement for it or does it have anything to do with performance(avoiding navmeshes, agents, dependence on physics etc)?

Thanks in advance.

 

It'd be neat to be able to switch between controller types, for instance, I like using a Switch Pro controller but the axis and button mappings are different from XInput controllers

 

@cirocontinisio
I'd like to start with the "conrol remapping system" ticket (didn't want to start a new thread, topic is the same).
Without rush while architectural decisions about controls scheme are discussed.

 

there's a control remapping system thead.

 

Oh, thanks, didn't notice it

 

I've updated the control card to reflect usage of the mouse. https://open.codecks.io/unity-open-project-1/decks/65/card/14s-controls

By the way I labelled this thread as official, since there's no point in splitting Controls discussion in multiple threads.

 

The control card doesn't make mention of using the mouse to point and click on menu items at all, only WASD/Arrows/Enter/Esc.

I find menu systems a lot snappier if they allow for mouse controls. Is there a specific reason we don't want to have that feature?

 

Hi, I've looked at current InputActions, InputReader and have a couple of questions/suggestions.

1. Why are UnityActions used instead of C# Actions and why aren't they marked as events? Without event keyword anyone can call these actions.
2. Right now one ControlScheme is used for both Keyboard and Gamepad. Wouldn't it be better to split it in two schemes, one for Keyboard/Mouse and another for Gamepad? If game will have In-Game Hints (e.g., in Tutorial) what control it will show for, e.g., Attack, Action - X (Gamepad) or LMB (Keyboard/Mouse)? As I understand it will be difficult to do with only one scheme.
3. Suggestion: Instead of this
   
   Code (CSharp):

   1. if (attackEvent != null
   2.    && context.phase == InputActionPhase.Started)
   3.    attackEvent.Invoke();
   more readable could be this (I would also add curly braces around one-liner, but it's code style):
   
   Code (CSharp):

   1. if (context.started)
   2.    attackEvent?.Invoke();

 

Just because it's complicating things. We can have a menu that doesn't support mouse, but we can't have the opposite (one only for mouse), because some players might be playing with a gamepad.
Let's think about it... for now, let's try to make one for keyboard/gamepad that works as a first step!

 

Good point about the event keyword. Feel free to make a PR correcting that if you want, or I'll add it next time I have a chance. As for why they're UnityActions, just a matter of habit.

Originally the idea was to never use a mouse, only keyboard and gamepad at the same time so you didn't have to switch controls at any time. Now people have asked to orbit the camera and perform some actions through the mouse, so we might have to make this change...

I generally don't find these super shortened syntaxes more readable, they are shorter, yes, but compact several conditions together so as you're trying to debug or understand other people's code, your brain has to do the extra work. Just a matter of personal opinion...

 

I totally understand and respect if this is the way we are going to take it. In my opinion, however, is if we are developing for steam, mouse controls for menu UI is important.

UI systems are a nightmare to navigate with just keyboards. In 2018 steam had 90 million monthly users (Fenlon, 2019) and 30 million of them registered a gamepad (Mott, 2018). If those numbers can be compared and they carry over these past 2 years, then we are alienating 2/3 of steam users.

References

Fenlon, W. (2019, January 14). Steam now has 90 million monthly users. Retrieved October 27, 2020, from https://www.pcgamer.com/steam-now-has-90-million-monthly-users

Mott, N. (2018, September 26). Valve Breaks Down Controller Usage Among PC Gamers. Retrieved October 27, 2020, from https://www.tomshardware.com/news/valve-pc-controller-usage-statistics,37853.html

 

Thanks for looking into it I'm very aware we can't make the game controller-only, we would not only alienate players but impede the same developers to test it, or for example test it on the go (like in a train or something).

I think they are if not made for keyboard/pad. Many PC-first games are (understandably) made mouse-first, and as a result they feel awkward when navigated with a gamepad. I'm looking at you, Darkest Dungeon (and at the Switch port).

But there are literally thousands of games out for consoles that are thought first for gamepad or d-pad, and they work pretty fine. Same for all the PC game which require a gamepad to be played (usually console ports).

Actually one note: I don't think anyone would use the keyboard here, because if we enable the mouse you are either going to use the gamepad (if you have one) or switch directly to the mouse pointer and forget about the keyboard. Am I right in assuming so?
So I think in the end, a good compromise is to build something that can be navigated comfortably with a pad, and it will work for mouse too.

 

If compare the keyboard+mouse similar to gamepad:
It have button (many not only two or three) and Ability to move axes by linear movement
w/o mouse keyboard not very comfort.
And I agree the game must be comfort for any style of management.
And don't forget that the most part of time gamer spend in game, not in menu (but sometimes working in menu may be annoying - it isn't a good, but may be a comprise for Beta Version)

More readable? Are you joking? When the shortage was a more readable? It's only short text and to narrow the circle of people, who can use it (or use it quickly).

I fully agree ...
The first variant I understand fly by eyes, the second I must to think.
And the main - in "code" it will be same. In this case (and many others) very often the shortened code haven't e any pros, but more error-prone - it's a big cons. (we don't talk here about classic ++ and += and so on)

 

This open project is really great, why did I just notice it today！
I downloaded the game resources and experienced it, I have a little suggestion for this.
I think this should belong to the control module: when pig jumps, the angle of view will follow the jump. But as a third-person game, isn't this uncomfortable? I think this method will cause trouble to the player when pig jumps over obstacles. And I think we should modify the CinemachineVirtualCamera follow method so that the angle of view will not follow up when the pig jumps.If my suggestion can play a little role, I will feel very honored.
I would like to witness the great birth, cheers！

 

I'm not too sure what do you mean by this?

Also, you know what we should do, really? Implement a circular shadow, projected downwards, which gives a feedback for the jump. You can see it in many platformers, including Yooka-Laylee for instance (00:23). How does that sound?

In any case, this game won't have need for suuuper precise platforming.

 

• Thanks for your reply! Please excuse my ignorance, I didn't really understand your work. I have watched the video you recommended carefully and it looks really cool. From the perspective of an experiencer, I feel that the current jump feedback makes me a little uncomfortable, especially when I press the space bar hard (maybe it is shaking too much? ). This is just my personal feeling, I hope we can get better and better.
  

 

No need to excuse yourself
And you are right, we definitely need to work on the jump.

 

I think @qqqqqym means this:

Spoiler: Currently Camera follows Protagonist

Spoiler: Another option is for Camera to follow current Ground

 

Hi,

I haven't taken a look at the source code for the input system for this project yet... but I do think the preferred way to check for actions is to check the `performed` phase, not the `started` phase. from my understanding of the docs: https://docs.unity3d.com/Packages/c...html#started-performed-and-canceled-callbacks

started means that an input has been detected, but has not been processed/interpreted. performed is when an input has successfully been processed and is ready for use. Also, all the examples show calbacks using the `performed` phase. Not sure if this will cause bugs or issues, but I will submit a PR to switch to the performed context tonight just in case.

EDIT: Ah, a little more reading and i found: https://docs.unity3d.com/Packages/c...ld-for-04-seconds-before-triggering-an-action

so a functional difference between the started and performed phase would be: certain interactions (such as hold, tap, etc..) require a key to be actuated for x amount of time before 'performing' the action. just check for start fires off the business logic before it should actually be executed.

 

• Thanks a lot, bro. I watched the videos Ciro recommended, and the jump with a little feedback was also good (Sorry, I might be too picky). Maybe we can make the feedback a little smoother. Hope gets better, cheers!

 

That's a great find, @kirbygc00, great that you spotted it.

Maybe we can use the vertical damping on the Cinemachine virtual camera to do that?

EDIT: I just tried and it's a good solution. We could even modulate it for the different heights of the camera by assigning a different damping to the 3 circles on the FreeLook camera.

 

Reading the Controls card I noticed there is no specific button for the game menus. Will the pause also function as the menu button or will there be another button?

Reviving the camera controls matter: a good idea is to keep an alternative camera control on the arrow keys instead of just mouse or, even worse, the TFGH keys. It's a great accessibility feature, it's easy to implement with the new input system and way more comfortable to use than the initial idea.

The next questions are probably closer to UI and advanced controls for the future, but I will let them here so we can keep that in mind for control decisions:

• Will there be multiple big menu options like inventory, equip, quest, etc or will everything be simplified in a single screen?
• Will there be multiple buttons to activate each menu? In this case, will it be interesting to implement a radial menu for easy access to these options? (with the most recent example being Genshin Impact)

I don't think the game will be complex enough to need this type of menu, but is a great example in case we need it.

 

@WagnerGFX, could you provide video or some other reference of this radial menu in Genshin Impact? I've searched but couldn't find this menu.

 

I play the game on PC, so I don't know if this menu exists in any other platform.

I couldn't find any video on it, but here are two images for reference. To see this menu hold TAB on keyboard or the LB on the controller.

Since our game is waaaaay more simple than G.I. it might be better to directly use the controller directional buttons to open the menus. Like the smaller menu on the second screenshot.

 

Good point, I've added the Y (top) button on the gamepad and the E key on the keyboard for that. How does it sound?

I also updated other details in that card. How does it look now?

And also, is somebody going to implement the camera movement on the mouse??
https://open.codecks.io/unity-open-project-1/decks/15/card/17g-implement-camera-rotation-with-mouse
Also: with right mouse button modifier, or at all times?

 

I can take a crack at this tonight if no-one else has this covered, should be a pretty small lift .

I think the requirements are:

1. when the player moves:
   • camera eases it's position to behind the character's shoulder
2. when player stands still:
   • camera stays focusing wherever it is currently pointing towards
3. when player holds RMB they will be able to 'override' this default behaviour and control the camera directly
   • camera x-axis focus will follow the mouse position until RMB is let go
   • camera y-axis will not change
   • Once RMB is let go, camera focus stays at the last mouse + RMB position (???)

I think 1 and 2 are already implemented... so it's just #3
Does this sound correct @cirocontinisio ?

 

Let me know if you are going to try to do it because i want to give it a shoot myself.

 

Haha yeah, i will make a branch tonnight! just wanted to make sure i had the requirements before hacking away

But if you'd really like to do this I can cede it over to you
Also, you are definitely free to make a branch and try this out as well!

 

After digging into our current system, i feel like we should have different control schemes for mouse + keyboard vs game pad. We currently have them bundled together.

Makes it hard for example, to handle mouse + keyboard specific logic (such as the camera movement) since it's all bundled in there with the gamepad stuff. I also see unity take this approach with their sample projects + code.

How do other folk feel? Can I put in a PR to split them up?

 

Hi @RunninglVlan,

I definitely agree with points 2 & 3. It seems like Point 1 was already addressed as well.

One additional thing- instead of all these null checks we could initialize all events to an empty delegate

 

On the gamepad, I think Y for the inventory is not a bad idea, many games implement this way, but if some important action appear later this button might need to change to SELECT or inside the pause menu.
Depending on future usability tests it might be easier to move menus like inventory and map to the d-pad.

On the Keyboard, I don't think using E for menus (specially the inventory) is a good idea. These keys are too close to the WASD, could be pressed by mistake and additional actions might need the keys close to the movement.

My suggestion is to use TAB if the menus are unified, otherwise its better to follow standards with I for the inventory and M for the map.

E or F might be better as an alternative (or even main) key for interacting. While a faraway key like Right CTRL is better for an alternative attack button, since it won't conflict with the movement hand.

At all times seems better since moving the camera will be a constant unless we implement a very good automatic camera.

 

Yes, I also think that the mouse cursor should be hidden during gameplay, otherwise it seems like it serves a purpose. For now the RMB is used as a modifier, but I think we should remove it.

In any case I think if played with mouse/keyboard then the right hand will always be on the mouse, so LMB is attack, RMB something else, and we can't use Right Ctrl.

Aaaaaaah, the pleasures of PC controls!!