Posted On: 2019-03-11
When designing a game, one of the most important aspects to tackle is answering the question "how should players express their intent within the game?" The most fundamental piece to this is the game's input (how the game behaves in response to button presses or mouse movement.) Generally, a character is more likely to feel like an extension of the self when the input for controlling that character is direct (ie. pressing left makes the character walk to the left) rather than indirect (ie. pressing left chooses a location from a menu and then the character automatically walks towards it.) That generality breaks down, however, when analyzing an individual's play experience: in general, the game interpreting player input in an intuitive way is the best way to maintain immersion, but what is considered intuitive is largely based on a player's prior experiences. Pressing left on a keyboard to move left might be the most direct way of controlling a character, but if the player exclusively played point-and-click games, then that form of input will be less intuitive (and therefore a barrier to immersion) compared to clicking the mouse to move to a destination.
As I design what inputs my game supports, I need to weigh all these options in my mind, and try to understand what might be most intuitive for the demographic that I expect will play the game (for any sizable audience, it would impossible to tailor the controls to each individual, as each individual will have their own unique background.) Since I expect that immersion will be important in the final work, I am leaning more towards direct player control. I also expect my players to have at least some experience playing 2D action games on the PC, so this generally means I should support control using a standard X-Input controller. For the keyboard layout, there are, unfortunately, not a lot of good standards around how to handle 2D action: players with a background playing classic US-made games likely will find shift, control, and space to be intuitive buttons to use (these were used in many early games, such as asteroid clones where space shoots and control activates the thruster) while players that have a background playing Japanese-made games will likely favor Z and X as primary input keys. There are likely other control schemes as well, but I am not familiar enough with any of them to emulate them effectively (I've seen some that use WASD for movement paired with the right-hand on the right side of the keyboard for actions- possibly JKL.) While some of the burden of this decision can be alleviated by making the input customizable, nonetheless, many players would rather put a game down than customize it, so I need to be thoughtful when picking the default setup. For now, I am favoring Z and X as primary buttons (ZXCV + ASDF gives me 8 buttons to work with, plus it avoids the Windows "sticky keys" mode which can be triggered by high-frequency inputs using control or shift) but this will be one of the questions I ask of playtesters as I gather feedback.
Beyond the control scheme, there are also many moment-to-moment input systems that I have to decide upon. At present, I am currently confronting a rather interesting problem: when triggering a dialogue with another character, how should I handle input? This decision is not a trivial one, though it will often go unnoticed by most players. Many games immediately seize input from the player as soon as dialogue opens, but this often comes with additional changes, such as pausing the game or making characters invulnerable (a bear mauling a character will always upstage the dialogue, no matter how good the writing is.) Conversely, if input is not taken away immediately, players can continue to move around during the conversation, potentially running away or performing other immersion-breaking activities that the game may need to react to. Additionally, if a decision is required in a dialogue, leaving the player in control of the character means the standard inputs cannot be used to navigate decisions - which is quite unintuitive. Some games solved that issue by designating a dedicated set of inputs for menus (Dark Souls is one example) while others chose to seize control from the player only when a dialogue that contains a choice is started (Chrono Trigger did this - though having instanced combat limited the possible harm from losing control this way.)
Ideally, I think the best fit for the game I am working on would be some form of time-stopping when a dialogue starts. This is reminiscent of how dialogues and/or monologues mid-action are handled in other media (it's a standard stage play convention to freeze time for character asides, and in anime it is similarly standard to stop the action so that characters can argue over their ideals. Even in live-action film it is fairly common slow down the action to give characters enough time to convey their emotions to the audience.) While I generally enjoy games that are able to deliver dialogue while gameplay is happening, it can be easy to miss important details in the heat of combat, which I expect will be particularly harmful given the complexity of the game's theme. All that being said, implementing such a time-stopping mechanism will be non-trivial, so including it in the prototype will be yet another scope increase. (Leaving it out of the prototype is an option, though one of the goals of the prototype is to make sure the combat mechanics enhance the storytelling, so there is risk that I would miss out on that goal if I don't spend time working on this intersection between gameplay and dialogue.)
Hopefully you've enjoyed this window into some design decisions going into making a game. As always, if you have any thoughts or feedback, please let me know.