Skip to content

Sprint 3 User Testing Enemy Animation and AI (team 1)

JZ1890 edited this page Oct 5, 2022 · 10 revisions

Background

In this sprint, the main work of our team is to design enemies, through user testing and iteration, we ensure that high-quality enemies are put into the game.

Therefore, after all the enemy images were confirmed, we further made the animation and AI of each enemy, and put them into the game for testing

The main purpose of this test is to test the animation quality and whether the enemy's AI matches their identity, therefore, through this test, we will have the opportunity to find inspiration for further improving our feature.

Introduction

This test will focus on the AI of the enemies and quality of the animations as the main test goal, this will be measured by user satisfaction and opinions.

Test Plan

Interview

  1. Introduce in-game enemeis to users (In this step users will have the opportunity to learn about these enemies, including their behavioral preferences and identities)

  2. Show the user the animations and AI of in-game enemies directly (Through this step, the user can more directly evaluate the animation and AI of the enemy)

Collect Feedback

Collect feedback via questionnaire form and interview

Process

The participants in this test are mainly from other classmates and acquaintances, as well as some other members of the same studio. Additionally, all tests are online via zoom due to the conditions required for the test. A total of 10 people participated in the test.

Overall, the process went according to plan, first introducing the user to all current enemies and their identities, and then showing the user how the enemies would animate and behave in the game. After the demo, a questionnaire is provided to the user. After the questionnaire is submitted, we conduct another interview with the user for further feedback.

The link of questionnaire: https://forms.gle/4N7FFNcRibxmMwD3A

Result

image image

Analysis

Q1 reflects that currently the most popular character is knight, followed by bobo, and according to interviews with users, it is found that they are the most popular because of their better appearance. However, although the beauty of character design will inevitably attract players, as an enemy, too much beauty may lead to problems such as confusion, so this aspect needs further consideration.

In Q2, Q3 and Q4, the results show that users are mostly satisfied with the animation of the enemy, however there is some feedback that some other animations are expected to be added, such as attack animations, which should be considered in the next production stage, in addition, some users expressed their desire to further differentiate the attack methods of different enemies. This suggestion is very meaningful. For example, knights can use swords, while robots can use guns for long-range attacks, etc. These can be further considered in the next stage.

In the results of Q5 and Q6, most of the negative comments were concentrated on the fact that some of the enemies' styles were too common and lacked features. This issue is particularly acute with the Slime enemy, the only character to receive a high number of votes for both likes and dislikes, the reason for this situation can be understood because the too classic image causes users to feel friendly and monotonous at the same time.

In addition, there is a more interesting feedback as "Not academic enough." After further interviews, it was found that the user made a typo, and originally wanted to write dynamic.

Summary

Overall, this test reflects that the work we planned at the beginning of this sprint about enemy design has basically been completed, but it has additionally led us to further discover the work that needs to be done in the next sprint, this includes attack animations, richer attack methods, etc., which will be added to our next sprint.

Future Testing/Evaluation

Based on the information gathered in this sprint, we can plan some features that may need to be tested in the next sprint, including:

  • Enemy attack animation
  • Differentiated attack methods

It is necessary to communicate with other teams that these changes may lead to changes in the difficulty of the game and therefore need to be considered more carefully. More respondents from more diverse backgrounds may provide more suggestions for our next test. The difficulty of each task should be assessed in a timely manner to ensure the progress of the work

In addition, since we also undertake the player's simple attack function in this sprint, we will also conduct a relatively simple user test of this function to collect some initial feedback.

Table of Contents

Home

Game Design

User survey

Sprint 4

Eviction Menu and Win/lose Logic: Polishing tasks (Team 7)

Button Sounds and Ending Menu improve (Team 3)

Sound effect and Fixing the clue bug (Team 6)

Improvement of Enemy and Attack (Team 1)

Add Features When The Player Get Attacked and Overall UI Improvement (Team 8)

Sprint 1

Achievement System (Team 2)

Player Eviction Menu (Team 7)

Countdown Clock (Team 4)

Music (Team3)

Map (Team6)

Sprint 2

Player Eviction Menu (Team 7)

Character Design & Animation (Team 1)

Music (Team 3)

Inventory System and Consumables Items (Team 8)

Scenario design

Achievement System(team 2)

Storyline (Team 5)

Countdown Clock (Team 4)

Sprint 3

Ending Menu (Team 3)

NPC interaction (Team 2)

Win/lose Condition (Based on Eviction Menu) (Team 7)

Player Profile (Team 4)

Game Logo (Team 8)

Clue storage (Team 6)

Enemy Design and Attack (Team 1)

Scenario design for village(Team5)

Game design
Entities and Components

Service Locator

Loading Resources

Logging

Unit Testing

Debug Terminal

Input Handling

UI

Animations

Audio

AI

Physics

Game Screens and Areas

Terrain

Concurrency & Threading

Settings

Troubleshooting

MacOS Setup Guide

Clone this wiki locally