The Unicode Consortium Discussion Forum (CLOSED)

The Unicode Consortium Discussion Forum (CLOSED)

The forum has been closed, but prior postings are accessible for reading.
 Forum Home  Unicode Home Page Code Charts Technical Reports FAQ Pages 
It is currently Thu Nov 23, 2017 2:39 am

All times are UTC - 6 hours [ DST ]

Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 
Author Message
 Post subject: Game input symbols
PostPosted: Wed Oct 22, 2014 2:12 pm 

Joined: Mon Oct 20, 2014 12:02 pm
Posts: 1
I have noticed that videogames have a tendency to treat controller buttons as symbols in text. They often include pictographs of the button in running text, indicating to the player either which button is used to perform an action or to prompt the player to actively perform an action.

The same applies for other input controls such as joysticks, d-pads, foot pedals and so on.

As such, I believe that there is a wide use case for these symbols.
I have seen the existence of the COMBINING ENCLOSING KEYCAP character point, but I do not think that it is sufficient to solve the issue. The most obvious reason why it would be a solution is that using it with normal letter would allow purpose made fonts to show the required glyphs. However, there are several issues there.

The first one is a technical problem with the character; it does not support keys with names longer than one character. This makes it fail at its originally intended purpose, since it is unable to encode concepts such as “the control key” and so forth. Some dedicated characters exist for common keys like “print screen”, but that is not a general solution to the problem. The use of joining characters is a proper solution, but I am unsure if combining marks and joining characters work together.

The second issue is that it suggests that the key is square. I am aware that Unicode does not mandate glyph forms, and fonts are fully allowed to use other shapes.

The third issue follows from the second issue. It might be that the shape of a “keyboard key” is carrying semantic information that conflicts with the use I propose here. Specifically, players may think of the keyboard as “special”, not considering it a normal game input device. This in particular applies to systems that both have normal keyboards and dedicated game controllers.

The simple ability to note the identity of the control is not enough for more complex devices. There are four main concerns in addition to the basic matter of noting which input control to use.

The first one is analog controls. Joysticks, pedals and such support many positions. Text often wants to indicate a specific position on the control. Enumerating all possible positions is neither possible nor useful, but a small selection of key positions both easy and useful. A minimal list includes neutral, positive max and negative max positions. A problem arises with multi dimensional controllers such as joysticks. The direction is just as important as the magnitude of the input, if not more so.

This also applies to a lesser extent to binary controls such as plain buttons, being able to note that a button is being pressed is important too.

The second concern is the motion of the input. Game inputs are often produced over time and as such text often needs to indicate input over a brief amount of time. Examples here include taping a button once, rapid tapping of a button and quick joystick movements. These symbols are often, but not always, animated to clearly illustrate the expected motion.

The third concern is a relatively recent problem, motion controls. Moving the entire controller is becoming an increasingly important input action in video games. Practically infinite possibilities exist, but several core elements exists that can be meaningfully enumerated.
Examples include moving along a single axis, turning the controller and shaking the controller.

The final and fourth concern is screen controls. Screens have a unique situation where it can be important to refer to areas on the screen easily. Pen and mouse based systems add the concern of indicating motions following various paths in addition to the above mentioned motions. It is obviously unrealistic to expect symbols for every single possible path, since there are an infinite number of them. I am unsure if there are any common enough motions to justify standardized symbols for them.

Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 1 post ] 

All times are UTC - 6 hours [ DST ]

Who is online

Users browsing this forum: No registered users and 1 guest

Quick-mod tools:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Template made by