Unit Selection Working continued on Sprint 2
In Sprint 1, we successfully implemented unit selection, unit information extraction and plural selection. It can be said that these work laid the foundation for the improvement of infobox in sprint 2.
In this sprint, we are leaning more towards intuitive interaction design. They are functions that can give players feedback in real time, and can also cooperate with more units to improve the player's overall gaming experience.
Our Sprint 2's new features/functionalities include:
-
Semi-selection: VFX for individual units. Lightly effect will appear for the functionality.
-
Multiple selection box: A visual tool to aid selection that appears when multiple units are selected with the mouse.
-
Display Adjustment: Optimized adjustment to the display effect of Infobox according to the feedback of our user testing.
Semi-selection usually represents the preceding process before the unit is selected. It will show some obvious but not overwhelming special effects to remind users of what's going on in this game. For the current progress, it specifically refers to "what units will be selected to operate".
Generally speaking, the semi-selection function will be triggered for every complete unit selection process, because:
- The hovering and clicking of the mouse are the only conditions for triggering semi-selection, and the hovering of the mouse also happens to be the necessary condition for clicking on the object/make multiple selection box.
We use this logic to ensure that it works correctly until the unit(s) selected:
package com.deco2800.game.rendering;
import com.badlogic.gdx.graphics.Texture;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;
import com.badlogic.gdx.math.Vector2;
import com.badlogic.gdx.utils.Array;
import com.deco2800.game.components.friendlyunits.SelectableComponent;
import com.deco2800.game.entities.Entity;
import com.deco2800.game.services.ServiceLocator;
public class HighlightedTextureRenderComponent extends RenderComponent {
private Texture texture;
public HighlightedTextureRenderComponent(String texturePath) {
this(ServiceLocator.getResourceService().getAsset(texturePath, Texture.class));
}
public HighlightedTextureRenderComponent(Texture texture) {
this.texture = texture;
}
@Override
protected void draw(SpriteBatch batch) {
for (Entity entity: ServiceLocator.getEntityService().getEntities()) {
TextureRenderComponent TRC = entity.getComponent(TextureRenderComponent.class);
if (TRC != null){
SelectableComponent selectedComponent = entity.getComponent(SelectableComponent.class);
if (selectedComponent != null && selectedComponent.isSelected()) {
TRC.setTexture(texture);
}
else {
TRC.setTexture(TRC.getTextureOG());
}
}
}
}
}
And the visual effect of this function and design iteration will listed below.
- The semi-selected friendly-units( This feature was tested by using boxboy because the real friendly units for the game have not been added to the game before the end of sprint 2 to be tested.):
- The semi-selected building:
In the past, we were inspired by the yellow border generated when LOL's towers and soilders were selected, and blindly designed this as a standard. Actually, it is not feasible due to the following factors:
-
The main color tone and overall background of our game are quite different from other games (mainly light and cool colors), and we need to reconsider the color distribution to ensure the player's gaming experience.
-
In other games, the total number of units is limited. However, the essence of RTS games is to continuously train and generate units, which means that we need to consider special effects when there are too many units.
-
The art design of the entire game is divided into different teams, the design styles such as borders and gradients are more blooming. As a more compatible color, white is more suitable as a general special effect for this game.
However, a pure white border is not ideal. In units of different resolutions, it sometimes even obscures the material and texture of the object itself. This is not what we expected. So we discovered the outer glow effect to emphasize the presence of white.
Since the processing of the outer glow is adjusted by the degree of divergence and luminescence size, we still need to calculate and optimize the images of different resolutions one by one. Through continuous friendly discussion with other teams (especially friendly-units), we finally got a consistent agreement on specular effects and showed it as a finished product in the game.
In the unit selection function of sprint 1, even though we have implemented the multiple unit selection, it is still difficult to be visually detected.
This time, we designed a multiple selection box to serve players. Whenever the player drags the selection with the left mouse button pressed, a translucent rectangle with the same area and location as the selection will be generated.
The following code shows what we spawn this rectangle:
package com.deco2800.game.components.friendlyunits;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.GL20;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;
import com.badlogic.gdx.graphics.glutils.ShapeRenderer;
import com.deco2800.game.components.Component;
import com.deco2800.game.ui.UIComponent;
import java.awt.*;
public class GestureDisplay extends UIComponent {
ShapeRenderer shapeRenderer;
int xPos;
int yPos;
int width;
int height;
@Override
public void create() {
super.create();
shapeRenderer = new ShapeRenderer();
entity.getEvents().addListener("updateBox", this::updateBox);
entity.getEvents().addListener("stopBox", this::stopBox);
}
@Override
protected void draw(SpriteBatch batch) {
Gdx.gl.glEnable(GL20.GL_BLEND);
shapeRenderer.begin(ShapeRenderer.ShapeType.Filled);
shapeRenderer.setColor(0.5f, 0.5f, 0.5f, 0.5f);
shapeRenderer.rect(xPos, yPos, width, height);
shapeRenderer.end();
}
public void updateBox(int oneX, int oneY, int twoX, int twoY) {
width = Math.abs(oneX - twoX);
height = Math.abs(oneY - twoY);
xPos = Math.min(oneX, twoX);
yPos = Math.min(oneY, twoY);
}
public void stopBox() {
width = 0;
height = 0;
}
}
From the user's point of view, this experience similar to "units enclosed by rectangles will be selected" will promote positive feedback from players and improve the overall quality of unit selection.
Through user testing, we realized that appropriately adjusting the timing of the infobox's appearance can increase its presence. Therefore, we adjusted the generation logic of the infobox.
The infobox does not appear when entering the game or when no units are selected.
When the user selects a single/multiple units, the infobox will display the number of units selected.
That's how we implemented the function:
if (!selectedEntities.isEmpty()) {
stage.addActor(backgroundBoxImage);
stage.addActor(pictureTable);
stage.addActor(infoTable);
...
...
else {
pictureTable.remove();
infoTable.remove();
backgroundBoxImage.remove();
}
In addition, in the current sprint 2 phase, we learned through cross-team communication that more attributes will be added, namely speed and range.
For more designed unit properties, see here.
Therefore, we designed icons for speed and range, ready to be displayed in the to-do column of the infobox.
Speed:
Range:
The reason why only the selected number is currently displayed:
-
This feature is highly dependent on the work units of other groups. In today's relatively independent development environment, there is room for further compatibility between the work of different groups.
-
Since unit properties float dynamically, we cannot directly display a list of "pre-designed" properties.
-
In sprint 3, we will shift the focus of our work to in-depth communication with other groups to achieve dynamic display of data.
Different from the interview in the previous stage, we use a process that combines user tasks and questionnaire for user-testing this time.
For our Sprint 2's user testing, click here.