Level 2 Basic Enemy Poop
Before designing the Level 2 enemy we conducted surveys within our studio group to understand what potential users of the game believe the boss should look like. This information was required to ensure the villain's team, studio group and story team ideas could be collated so that we can derive relevant insights and create the best possible enemy for this game.
From the insights provided above, we can derive that the level 2 enemy needs to portray these characteristics:
- Slimy features - to look disgusting and creepy
- Dirty - so that the character player wants to run away
- Poop structure - to display the dirty theme that is associated with the level 2 enemy
From the insights provided above, we can derive that the level 2 enemy needs to portray a colour scheme which displays these characteristics:
- Dark Green - to show the slimy feeling and texture associated with this enemy
- Brown - to represent a dirty & disgusting persona
- Poo colours - to represent a mixture of a colour scheme from dark green to light brown to display a slimy poo-like enemy
From the insights provided above, we can derive that the level 2 enemy needs to portray these specific themes :
- Disgusting - so that the main character wants to run away
- Dirty - so that it represents the poo structure
- Creepy - This is the main feature which differentiates the level 2 enemy from the other enemies as they are based in physical power and dominance whereas the level 2 enemy is more psychological based on creepiness and disgust
The poop enemies will be the basic enemies of level 2. They will shoot poop sludge at the player.
After the pre-design testing, story team inspirations and team villain discussions we were able to form and present the level 2 enemy.
Utilising the inspirations provided by the story team along with the pre-design testing and team contributions we were able to create the basic enemy design. From the inspirations provided below the design team focused on the features presented in the first example below as it aligned with the insights extracted from the user testing and the design team's vision for the persona. Particularly the structure and the design elements (spots and stripes).
From the post-design testing, we have been able to gather insights for improvement in the next sprint process.
- The survey above confirms that the vision of the design representing a Poop has been conveyed correctly
- The survey above confirms that the current colour scheme of the design correctly matches the requirements of the user
- The survey above confirms that most users are happy with the design and its relevance to the game
- The only improvement suggested to this process would be fixing the structure of the arms, this can be improved upon in the final sprint
- The survey above confirms that most of the prospective users believe that the design represents the scary/disgusting nature required.
The surveys conducted have assisted the current design and development process of the enemy for level 2. It has displayed that we have been able to appropriately construct the prospective enemy required for the game.
Further testing focused on the animation and what can be improved need to be focused on during the next sprint this will help create an understanding on whether features and design elements need to be changed to facilitate the animation process. In addition, in order to obtain a truthful response from the user, some user testing techniques such as Think Aloud or time on task should be conducted. It allows the users to experience the game within the limit to measure how long it would take to complete a certain task. This will illustrate the efficiency of a certain design. As for Think Aloud, this would help to understand their thought on the features of the game such as animation, and projectile tasks, etc.
Through the pre-design, inspirations, design, and post-design process we have been able to map a clear vision for the level 2 enemy. This structured approach has helped inform us through the process to create the correct design choices when creating the enemy. As a result of the post-design process, we have been able to view results that display that the user and designer's vision has been met by the final product created. The next process as described within the future designing section is to conduct user-testing on the animations and to gather an understanding of whether the animations suit the task. whether certain features of the enemy need to be changed as a result? and any other user-designer gaps which need to be addressed. Overall the structure has ensured that our vision for the enemy matches the game and the rest of the studio's vision and we hope to continue that through the next sprint.
before designing the Level 2 enemy weapon we conducted surveys within our studio group to understand what potential users of the game believe the boss should look like. This information was required to ensure the villain's team, studio group and story team ideas could be collated so that we can derive relevant insights and create the best possible enemy for this game.
From the insights provided above, we can derive that the level 2 enemy weapon needs to portray these characteristics:
- It should be structured - strong so it feels like a weapon which hurts
- It should display different textures - so it displays the qualities of poop
From the insights provided above, we can derive that the level 2 enemy weapon needs to portray these colour schemes:
- different shades of brown - so it displays the different structures and strengths within one piece of poop
- slimy green - so it displays the disgusting nature of the weapon, more psychological than physically repealing
From the design inspirations provided below, the design team liked the colour scheme provided by example 2 as it displays the effect a mixture of brown colour shades creates (similar to what the surveys suggested). As well as being inspired by the shape provided by examples 1 and 3 is because the surveys suggested the weapon needs to represent structure as a weapon and these examples display something which could be perceived as an element which an be thrown as a projectile and hurt the main character.
The design of the poop comes from the inspirations presented above. This is because the examples present the correct level of practicality as a weapon, connect with the theme of the game and fit the colour scheme provided from the user testing.
This enemy will attack by shooting poop projectiles at the player.
Projectile functionality is one of the most important parts when implementing a ranged enemy. Unlike melee enemies, ranged enemies need to perform multiple tasks to achieve the shooting required. Hence, we have implemented the ProjectileFactory.java, ProjectileTask.java, and ShootTask.java.
-
ProjectileFactory.javais created to implement the basic component of the projectile within the game in general. It has been simplified so that it could be used for both enemies and players. -
ProjectileTask.javais created to control the behavior of the enemies (possibly players in the future but need some modification) before performing a shoot (for example the player has to be visible and in range of the shooting area). FunctionShootin this class is used to perform the shoot and wait task and is also used from the start() or update(). This is to give a pause between the shooting of the enemies (like a reload). This can also be exploited to adjust the level intensity (a higher level will have a lower wait time between 2 shots). -
ShootTask.javais used to control the behavior of the projectile while it is being shot out. For enemies, it is implemented to chase after the player because this could be one of the features of the game and require players to have more skill to dodge and/or parry the projectile. However, there is a bug associated with the projectile (it cannot be disposed of when hit the target and/or any obstacles).
public void shoot(String projectileType) {
if (projectileType == "poopSludge") {
projectile = createPoopsSludge(target);
}
if (projectileType == "discus") {
projectile = createDiscus(target);
}
if (projectile != null) {
ServiceLocator.getEntityService().register(projectile);
projectile.setPosition(owner.getEntity().getPosition().x, owner.getEntity().getPosition().y);
float xVel = owner.getEntity().getPosition().x - target.getCenterPosition().x;
float yVel = owner.getEntity().getPosition().y - target.getCenterPosition().y;
// SHOOOOOOOOOOOOOTTTTTT;
projectile.getComponent(PhysicsComponent.class).getBody().setLinearVelocity(xVel, yVel);
setTask(taskWait);
}
}