Original link: https://blog.codingnow.com/2023/06/mobile_ui.html
This one is a continuation of last year’s ideas . These ideas are currently being refined for a mobile game we’re working on on an Alien Factory.
Our game engine is developed on PC, but we want to use it exclusively on mobile. Although I hope that daily game development will be carried out on the real machine, the engine has also made a lot of efforts for it. But the reality is not so smooth. The main reason is that the engine and the core C part of the game are still changing frequently. After all, debugging on a real machine is not as convenient as on a PC. Fortunately, it has gradually stabilized recently, and there are more and more opportunities to use real phones in development, so more consideration is given to interaction issues on mobile phones.
The first problem I realized is that the simulated version on the PC cannot experience the interaction experience on the mobile phone. If you want to do a good job of the interaction on the mobile phone, you must always experience it on the mobile phone.
The original interactive interface of our engine is based on mouse messages, and touch screen messages are just simulations of mouse messages. This is wrong. After realizing the problem, we first removed the mouse message from the engine, changed the touch screen gesture message to first class, and the mouse message was simulated by gesture message in turn.
There are actually four basic gestures: click, long press, drag, and zoom. Among them, in different occasions, dragging can be replaced by sweeping, but the two cannot coexist.
Playing construction games, touch screen interaction and mouse interaction seem to be similar, but the actual difference is very big.
The click surface of the touch screen is actually a circular area, while the mouse is a point. It’s easier to pinpoint a click with a mouse than it is with a touchscreen.
The mouse has move and hover messages, which are very useful in similar games, but the touch screen does not have hover events.
When the finger clicks on the object, the finger will block the clicked point. If you drag further in the mouse mode, the dragged object will be blocked all the time, which will lead to a very bad interactive experience.
So, after thinking about the above issues, I adopted the following solution:
First, we need to define an operation that focuses on objects in the game scene. This operation is similar to hovering the mouse, indicating that the interaction focus is on an object. Since touch screens do not have hover events, it is appropriate to use tap as the equivalent behavior.
When the player clicks a certain position on the screen, we think that he actually wants to move the interaction focus to the object under the finger. Finger clicks are difficult to be precise, so we can poll for objects near the click. When objects are squeezed together, they can be selected with multiple clicks. For selected objects, there should be a clear visual representation, such as a stroke on the object.
Since clicking is only focusing (similar to mouseover), not interacting with the object, misclicking is never an issue. This is like using the mouse to quickly sweep over several objects, and finally stop precisely on the object you want to select. It doesn’t matter if you have scanned irrelevant objects before.
Then, each click can immediately respond to events that should be triggered by mouseover: such as the tips window showing the object. But it should not trigger the interaction event that the original mouse clicked on the object.
Then, we put the interaction with the focused object on the most comfortable virtual button for the thumb in the lower right corner. That is, pressing the main button (the big button in the lower right corner) is regarded as the mouse clicking on that object and interacting with it. If it is a mouse operation, there are usually two interactive behaviors: left-click and right-click. This happens to be mapped as a tap on the home button and a long button press.
In our game, interacting with objects usually calls out the interaction menu. If it is a mouse operation, the interaction menu will generally be placed next to the interactive object. This is because the mouse moves the shortest distance, the most comfortable operation, and can prompt the position of the operation object.
But during finger operation, the interaction is achieved by pressing the bottom right button. The interactive menu can naturally make a fan around the main button. This is also very comfortable. In particular, it does not allow the finger to obscure the manipulated object.
If it is a construction menu, it can be regarded as interacting with the scene floor, that is, clicking the main button when there is no focused object. At this time, select the building to be built in the pop-up secondary menu, and it will be displayed in the center of the screen. Positioning can be done by dragging gestures to move the scene. That is, the finger moves the scene instead of the building, and the building is always in the center of the screen. This is much better than holding and dragging the building to be repaired on the screen (mouse logic). Because players don’t have to worry about moving the scene while dragging objects, and don’t have to worry about fingers covering the area to be constructed.
On mobile screens, all information should be concise, avoiding too small fonts and dense layouts. This is easy to say, but easy to ignore in practice. The main reason is that development is often done on a PC monitor, using the familiar logic of the desktop interface.
On a mobile phone, we usually don’t switch our attention between multiple windows at the same time. But this is very common in the desktop environment: the window is only a small part of the screen, and the attention is easy to focus on one area of the screen. On mobile phones, we need the information currently displayed to be in the comfortable reading area in the center of the screen as much as possible, so that the content can be seen at a glance (without the need to scan back and forth).
I designed the tips window of the object according to the above logic. When the player counts the focused object on the screen, the tips window is displayed on the left side of the screen, taking up about 1/3 of the screen. Switch the focused object, and the contents of the tips window will switch immediately.
The info window is only used for information about the temporary object and does not set any further interaction buttons. This is the same logic as the tips window. This information window should contain as little information as possible to avoid fatigue for players to distinguish dense information. Because there are no further interaction buttons on this window, we can set each area of the clicked information window as a secondary information window to display some more detailed information in the center of the screen.
This is equivalent to dividing the information to be displayed into two levels. The overview is placed in the first level window and hung on the left side of the screen. The first-level window is divided into three to four areas, corresponding to three or four second-level information panels, and players can see them in the center of the screen by touching these areas.
The home screen is clean enough I hope. It is enough to put one or two more permanent buttons, which can be placed comfortably in the four corners of the screen. The main operation of the player is to drag and zoom the scene with fingers, tap the objects in the scene to focus, and press the lower right main button to interact with the focused objects.
If more interactive menus are needed, many mobile games will put them in a row at the bottom left of the screen. I don’t like this design. Therefore, the entry of more interactive menus is designed as a long press on the center of the screen to pop up a full-screen operation panel. It is equivalent to the main menu popped up by pressing the esc key on a PC.
This design will make the main screen of the game look much cleaner.
This article is transferred from: https://blog.codingnow.com/2023/06/mobile_ui.html
This site is only for collection, and the copyright belongs to the original author.