FMP Limbs of the Sneaky Dead Pt.6: Testing UI/Gameplay and Researching Aesthetics

The game had been tested at externally with the total amount of 4 concurrent controllers. Issues were found and amended and again tested with a different group. The second test revealed that there were issues that may concern the visual aesthetics and communication as solutions.

First playtest (8/10/21)

This playtest was conducted externally. This was the first time the game was tested with four controllers which revealed the most prominent issue, that is how players join a game. Ther were also 4 individual playtesters to test the game.

Playtesting results

UI issues

  • Player joining was able to detect all 4 player devices. However, there were complications with starting the game. Not all 4 players could play concurrently due to issues with the selection prcoess of the colours and limbs.
  • Some UI colour selections could be undone in the menu by other players, this does not reassign UI colours but affects individual player colour panels.

Physics

  • Laughter and enjoyment at how the zombie body controls, the movement of the limbs and physics bugs where limbs uncontrollably spasm.
  • Limbs spasm when respawning.
  • Grabbed objects cannot be ungrabbed and can stick to the grabbing arm.
  • Legs clip through walls and get stuck.

Gameplay

  • Playtesters expressed difficulty in grabbing objects while moving a limb.
  • Playtesters expressed difficulty with moving limbs. “I’m trying to push this way but it’s not exactly moving in that direction.”
  • Notable tension when players are controlling a leg and arm (2 players).
  • Players communicate with each other, checking if they’re inputting the correct controls.
  • One playtester was confused on how leg limbs are activated/used.
  • It became evident that controlling the arms did not have much purpose other than to move obstacles away, which was already being done by the legs kicking obstacles away.
  • Control layout needs rethinking. Limb “ability” activation needs to be constrained to trigger possibly or thumbstick click.
  • Playtesters also discovered that both legs could be activated, doing so would float the zombie body away.
  • Testers found difficulty activating leg limbs, pressing grab and using both thumbsticks, as such one thumb could focus on purely controlling which direction the limb moves towards.

Playtester suggestions and comments

  • Zombies in space? – tester suggested that because zombie body floats away, zero-g environment with sticky/magenetic boots could work as a base context/visual aesthetic.
  • Tester commented how triggers to activate legs feel opposite to what they should be, release to clamp the feet to surfaces. – This would change the challenge of the game to one where players need to navigate a zero gravity environemnt.
  • Lean in to zero g capability when both legs are activated. – This bug, while unintended, results in positive emotional responses and players find it enjoyable to see. As such this could be expressed as a different limb type.
  • Single thumbstick input have different physical mechanic outputs e.g thumbstick moving left/right rotates a leg limb at the hip, up/down moves the leg/foot forward/backward. – This would solve the above issue.
  • Use of different surfaces that can/cannot be stuck to. – This could add another type of challenge as different surfaces could interact with limbs in a different way. For example a slippery surface could introduce friction challenges, sliding the zombie body around the environment.
  • Possibility of the body being ripped apart: limbs detaching, torso split open. – This could be used as a fail state, that is upon a limb being torn off, or the body being destroyed, the game respawns the zombie body at at a previous checkpoint.
  • Separate the physics body from the visual. Add in buffers for updating body behaviour. – This would be useful for protecting against the flailing limbs of the zombie and any other physics related issues.

Playtesting fixes

Evidently there are many areas that require changing. These could be separated into the following UI, Physics and Gameplay issues. The following solutions could be applied.

  • UI Menu fixes – The issue most likely lies with each player menu not being updated correctly, as such it requires investigating. This is important as not every player was able to play and had to sit out early in the game. Soon the ability to choose different limb types needs to be implemented as well.
  • UI control advice/tips – When a player selects a limb to play as or a type of limb, then there may beed to be text description to communicate how the player would use that limb.
  • PHYSICS Reduce limb spasming – The limbs and how their joints funciton need to be revisited again as they behave uncotrollably. The player is not able to reset or control the limbs when this happens.
  • PHYSICS Object grabbing – Currently a temporary joint is applied to the grabbed object and that joint joins to the limb, this is not behaving as intended as the joint does not let go.
  • GAMEPLAY Limb thumbstick output – The way thumbsticks move limbs is that it requires both thumbsticks to get the full range of motion between the cardinal directions. However, the forces acting on the limbs make it difficult to control, accurate movement of the limbs is not possible if both limbs are being used.
  • GAMEPLAY Generating obstacles to utlize limbs – Every limb will need to have some obstacle generated for it to engage with, doing so ensures that the player using this limb would have a chance to make use of the limb. As such unique obstacles or obstacles that can be similarly solved must be generated for each limb choice made.
  • GAMEPLAY Communicate player inputs – A possible way to resolve tension between players and to communicate controls to the players are on-screen UI images of the necessary controller buttons. This would be a case of perfect information for all players, this could resolve such tensions but also exasperate it. It is dependent on players clearly knowing what the controls are.
  • GAMEPLAY Limb ability activation button – Different buttons for limb (grabbing) activation need to be tested, right now it is the “Square” button that activates the ability and players cannot use both thumbsticks to do so.

Second Playtest (13/10/2021)

The second playtest was conducted with a different group, they had not tested the game before. There were only some fixes implemented at this point, these mostly addressed the physics issues with the limbs and a new UI menu that allows players to select a different limb type. This new limb type being a tentacle for the arms. The playtest session was conducted with a full amount of players.

Playtesting results

UI Issues

  • Testers attempted to navigate the menus with the D-pad.
  • The confirm button needs to be pressed in order to register limb type selection. Otherwise the limbs do not spawn.
  • The new UI limb type selection caused complications with the game, resulting in a tester leaving and giving up on playing.

Physics

  • Performance issue with arms. This specifcally happens with regular arms when they are moved with the thumbsticks. At this time, not replicable.
  • Limb clipping through surfaces still happens.
  • Tentacle arms are found to be significantly more heavy than regular arms, as such they pull the torso to the side should there be a regular arm and a tentacle arm on the body.

Gameplay

  • Genuine fun and laughter, players were entertained when the body collided with the boxes and struggled to get over obstacles.
  • Grabbing of objects functions as intended.
  • When both leg activation buttons are pressed, the zombie body floats upwards.
  • Extremely notable that one player, who only controlled arms, had very little to do during gameplay.
  • Players not sure what they need to do or where to go.

Playtester suggestions

  • One playtester suggested that there could be an option to split the total four players into two competing teams, tasked with completing the same objective. This would be an extremely different direction but could invite a lot of competitive play, players would be able to mix-and-match different limb types, as such granting different interactions between players and teams. However, this would require extending the menu and player joining system. As well as reconfiguring the camera and general game loops. This idea is worth considering but outside the scope of this project for now.

Playtesting fixes

  • UI DPad menu navigation – Menu navigation now allows for the use of the D-Pad buttons, however this may be misleading as the rest limb movement only works with thumbsticks.
  • UI Limb choice fixes – Player joining system now adds in limbs without the player needing to confirm their selection.
  • PHYSICS Limb clipping – Limb rigidbody, collider and joint settings need readjusting as they still shiver slightly and clip through other objects.
  • PHYSICS Body mass weight system – The weight and the constant upright force of the body are causes of the body floating, the lop-sidedness of the zombie body with different limb types. As such a system to calculate and change limb and body weight may be needed to adjust the body to account for the physical changes of each zombie.
  • GAMEPLAY Use more obstacles – Players responded well to the difficulty of the zombie body interacting with the obstacles. More challenges could be implemented by introducing different types of obstacle course objects.
  • GAMEPLAY Limb generated obstacles – As planned in the previous entries, limb choices will generate different challenges based on each limb, that would require their use in some way.

The above fixes need to be implemented/tested. The next step is to implement a system that generates the necessary obstacles that challenge each limb type, this will be at first a simple system that creates a certain type of obstacle for each limb type. However, after this the aesethetics of the game need addressing. I believe this will aid in informing players what they need to do, that is by using signposting as well as reinforcing the hilarious and silly mood intended for this game.

As such a case study will be conducted to generate a general visual style for the game. This will also affect and involve the overall narrative to some extent. Currently the player(s) control the limbs of the zombie to navigate the path towards the exit, once they do the zombie starts dancing. The reason for doing so is that the zombie wants to escape, however there is no motivation for the zombie to escape. Then context is needed. So I will conduct a case study to both acquire an overall visual aesthetic and a narrative.

Visual Aesthetic case study

For this case study I will look at some games and how they use certain visual elements. I will pay particular attention to how colours are used as sign posting or to communicate certain moods. As well as taking inspiration for art direction for the game world. Generally I would like to explore aesthetics of earlier 3D games from the 2000s. This is because games like Octodad that have focus on physics puzzles and hilarity have a certain visual style, this being a softer, cartoonish style that reflects the ridiculous nature of the in-game activities. As such I would focus on 3D video games that do have a cartoonish look, preferably those from the earlier 2000s.

The Simpsons: Hit & Run (Radical Entertainment, 2003)

Use of Colour

In The Simpsons: Hit & Run, colour is used in for highlighting many elements of the game. There are specific colours for different gameplay elements. For example, blue is used for highlighting doors, objectives and interactable objects and NPCs. Green is used for waypoints.

Interactable NPCs are surrounded by a blue aura and a red exclamation mark as goal related NPCs. (2002nik, 2016)

However, not one colour completely denotes a specific element of gameplay. For example, different coloured particle effects follow the collection of different collectibles and indicators for goals are based on the nature of the goal.

What can be seen is that different types of UI or visual elements use colours to denote different uses. For example, the arrow indicators point to cars/objects, different colours means the player must use different approaches to achieve that goal. The visual effects that are generated when collectibles are collected use the same colour scheme as the collectible itself. Then it can be seen that not one colour is used to denote a specific gameplay element. Instead, each colour has different meanings depending on what UI/Visual element that colour is being used for. However, blue is an exception, it is foremost used for indicating goals and this is consistent for other instances. This makes sense as achieving goals can be considered to be the player’s highest priority, then it is used consistently throughout the game.

Graphical conventions

Upon close inspection, in-game meshes have a low number of polys. This was a graphical compromise at the time, however it better mimics the source material that the game is based on. It also imparts a cartoonish and relaxed atmosphere that reflects the gameplay and context. The mesh is particularly noticeable when examining the edges of the meshes.

Textures have a small amount of detail and use distinct colour schemes. This has the benefit of making game objects very clear and different from each other, the textures themselves are simple and functional while also reflecting the cartoonish look of the character meshes. Environmental objects like bushes, trees, grass and flowers are composed of 2D textures.

Lighting and shadows are extremely basic and barebones. Only characters and vehicles in the game cast dynamic shadows. This highlights their importance and possibly is a method to highlight NPCs/objects that are non-static. As well as subtle shadows on the characters themselves. The lighting does not affect static environments, everything is evenly lighted.

Stubbs the Zombie in Rebel Without a Pulse (Wideload Games and Aspyr, 2005)

Use of Colour

Textures, UI and lighting all share the same level of fidelity. Shading takes more prominence in how it affects other visual elements, making everything seem slightly darker as well as emphasising the mesh edges of the models.

However, the use of filters is prominent. Different colour filters are used for different game states. This has the benefit of clearly communicating to the player what mode of gameplay they are currently engaging with. For example, a strong red filter appears when the avatar takes damage from enemy players. A grayscale filter is used when the player is controlling an independent limb of the avatar.

Graphical conventions

Textures are low-fidelity and use tiling in some instances for objects like floors or walls. However, some textures have a reflective quality to them. Some textures have a level of translucence like glass. Despite this there is still an emphasis on the cartoonish style similar to the Simpsons Hit & Run. Again it also reflects the casual and playful nature of the game’s narrative and gameplay mechanics. Another part of the visual aesthetic is the use of a film Scratch filter.

This filter serves to reflect and reference zombie films and the pulp novel aesthetic from the 1950’s. This reinforces the aesthetic of the game and highlights the non-serious tone of the game.

What can be used

  • Dedicated UI colours to represent gameplay elements.
  • Simple colour schemes for different objects.
  • 2D plane textures for leafy objects like plants, flowers and leaves.
  • Simple and colourful textures.
  • Sparingly used shading and shadows.
  • Dynamic shadows only for characters and non-static objects.
  • Use filters to indicate different game states.
  • Tiling textures for large surfaces like floors and walls.

References

  • Radical Entertainment, 2003. The Simpsons: Hit & Run. [Video game] GameCube, Playstation 2, Xbox, Microsoft Windows. Fox Interactive, Vivendi Universal Games, Sierra Entertainment.
  • Wideload Games, Aspyr, 2005. Stubbs the Zombie in Rebel Without a Pulse. [Video game] Xbox, Mac OS X, Microsoft Windows, Nintendo Switch, PlayStation 4, PlayStation 5, Xbox One, Xbox Series X/S. Aspyr, Buka Entertainment.
  • 2002nik, 2016. Simpsons Hit & Run Longplay. [Online Video]. Youtube. Available at: <https://youtu.be/1ubF6be_Fmc>. [Accessed: 30/09/2021]
  • Global Gaming, 2019. Stubbs the Zombie【FULL GAME】| Longplay. [Online Video]. Youtube. Available at: <https://youtu.be/IMfqJM-ho2o>. [Accessed: 01/10/2021].

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.