MA Games design dev log

Project Outcome

The outcome of the project had achieved the aims as outlined in the Development log part 5: https://collaborative.myblog.arts.ac.uk/2021/09/24/fmp-limbs-of-the-sneaky-dead-pt-5-prototypes-for-menus-coop-joining-and-input-system/. The GDPs were implemented, however this could have been improved. Specifically concerning both the Emergent Customization Challenges and Customization Generated Components GDPs. I would change my approach to playtesting as a cooperative game proved to be a challenge to playtest. There were also instances where the project had to be reduced in scope, this was due to implementing new systems and features. Overall, the game produced still achieved my aims to an extent and it does provide a cooperative experience where customization has meaningful consequences.

Video playthrough of FMP

UI and menus

The inital menus work well enough to communicate what the player is customizing as well as what the other player’s choices are. This was possible because the game was developed as a local cooperative game where all players look at the same screen, as such various UI and visual elements were implemented to clarify which player was controlling which set of options, as well as responding with feedback upon selection.

• 

• 

Prototyping the menus proved to be crucial in identifying any confusing language, unclear visual elements like button selection. This was improved upon over time by receiving and playtesting the menus. However, some of the elements of the final menu can still be confusing. Red is used as a possible colour to represent a player, green is used for general menu text as shown above. This is an accessibility issue which should be considered in future projects, this would certainly need to be replaced with a colour that is distinct enough for those affected by Protonopia.

This also highlights a crucial element that is missing from the menu, another addition that could be made is adding an options menu where players can adjust the settings of the game. Some playtesters have commented that the font used could be unclear to some players. Players have also commented how sound effects and music can be loud, there is no way to adjust volume or mute sounds. These issues could be solved with such an options menu to adjust settings.

The thesis research helped inform the requirements of these menus and the UI. It was crucial that players understood what the other’s customization choices were, as such, separate menus for each player were implemented to clarify each player choice. This also fulfilled the Customization Choice Provision GDP, as it communicates to all other players what each individual player choices are.

In a future approach to implementing menus, I would consider creating a menu with modularity. This meaning a menu system that can be easily modified and compensate for different options and layouts. This is because throughout development, scope was reduced and different options were put in place. This meant a lot of time was spent rearranging and adding different options to the menu.

Tutorialisation

Before a playtesting session began, playtesters needed to be instructed on how the controls worked as it was not intuitive nor were there any in-game explanations for controls. As such a tutorial was necessary. My previous research in fighting game tutorials highligthed how clear instructions were useful for novel game controls such as the limb controls for the FMP as well as making use of feedback to confirm successful attempts. The tutorial was made with these requirements in mind. However, the tutorial was left as one of the later elements to implement as different controls and mechanics were still being tested and used. Then the tutorial suffered as there was not much time to playtest the tutorial. Then a future approach would involve playtesting the tutorial much earlier or to create a prototype that can still be changed.

The tutorial was effetive as it explains exactly what players need to do, this was achieved by using spoken voice lines, unique font colours to distinguish actions and feedback. In this sense, the tutorial worked well as it communicated all the different possible controls that the player needs to use, it also grants context for some controls. For example, when asking players to press shoulder buttons to magnetise objects, two magnetic objects are spawned next to the player to engage that mechanic. The tutorial also took place in an area that was locked off from the rest of the level. This was a practical decision to ensure players attempted the different controls.

• 

• 

However, there are some mechanics that are not made explicit to the player, for example, the arms are able to grab on to some surfaces and objects. This was excluded as none of the challenges require this mechanic to be used. What is most crucial to the tutorial is a chance for players to practice controls, this was partly implemented with the magnets being spawned for one instruction. However, this could be improved further by adding additional objects or gameplay elements in the tutorial area that allows the player to practice their controls like smashing arms or manipulating the limbs. The nature of the controls themselves could be better explained as well as they are overall non-inutitive.

Controls

While being non-intuitive, the controls were suitable for the project as playtesters were able to complete the game. However, because it was non-inutitive, the tutorial had to resort to using text instructions which for some players found to be tedious and compromised the overall experience.

Sound effects and on screen UI elements are used to reflect which limb and action are being performed at the time.

• 

• 

The controls could be improved by adding additional feedback elements, like subtle particle effects.

Further options for development would also include efforts to allow players to customise the controls and button mapping. This is because multiple playtesters had commented on how they feel that certain buttons should be somewhere else or that they felt other buttons would be more comfortable for certain actions.

The GDP Emergent Customization Challenges, can be considered to be implemented here due to the fact that one or two players can play, then the controls needed to support these different cases. While the one player can control all limbs separately, two players need to coordinate in order to overcome some gameplay challenges. As such this provided unique challenges based on their different abilities associated with each limb.

The implementation of these controls was difficult, Unity’s new input System was used to handle multiple player inputs. This was necessary for local cooperative gameplay, however the Input System was still quite new and not a lot of resources for it were available yet and there were still some bugs with it. As such in future projects, alternatives may need to be researched before comitting to one system. This is especially true for games that feature local cooperative capability,

Cooperative gameplay

The Cooperative aspects of the game, while implemented well, is unbalanced. That is the player controlling the legs has more to do during gameplay as they are tasked with navigating the level and moving the entire body, while the player controlling the arms needs to wait for the player to arrive at the necessary objects to interact with. This could be fixed in the future by allowing extensive options, like changing the limbs they wish to use. Currently players can either choose to play as either arms, legs or both. Playtesters have offered different ideas, where players can choose to play one arm and leg each, if this were the case it would solve the above problem.

However, this would change the manner of obstacles, as they were designed around how the cooperative gameplay and controls work. This meaning that certain obstacles would be extremely difficult for such a split approach. As such, in future projects similar to this, an approach where the obstacles are first considered may be worthy to attempt, instead of building the obstacles around the controls. This would add constraints to the customization choices, which was later found to be necessary as time was spent in developing and prototyping different types of limbs, but the existing obstacles were not designed for such limb types, so they were removed from the project (Different limb types can be found here: https://collaborative.myblog.arts.ac.uk/2021/09/24/fmp-limbs-of-the-sneaky-dead-pt-5-prototypes-for-menus-coop-joining-and-input-system/).

Visual and aural direction

The overall aesthetics of the game was well implemented, this was because a case study (found here: https://collaborative.myblog.arts.ac.uk/2021/09/29/fmp-limbs-of-the-sneaky-dead-pt-6-testing-ui-gameplay-and-researching-aesthetics/) was conducted to inform such decisions. The textures and colours used in the in-game objects and UI, made it clear what was happening during gameplay, there were also used to as instances for feedback adn feedforward. For example, magnetic objects that were in-range, glowing particle effects on the closest hand. This showed clearly if they player could magnetise such objects.

However, lighting could be improved. Because of the overall visual direction of the game was inspired by classic pulpy horro films, as such there was an emphasis on shadows and darkening the overall look of the game. This led to issues where players found it difficult to distinguish some surfaces. Some lighting was introduced to remedy this, but the Unity’s Universal Render Pipeline was used which limited lights on surfaces. This created some lighting issues. Therefore, in future projects, pipelines and other graphical components should be considered first before comitting to one for the rest of the project.

A lot of the visual and aural elements were self-produced, this ensured an overall cohesive aesthetic. However, because some systems and mechanics were left out of the final build, some textures and models that were already produced were not used because of these changes. Then in future projects, the visuals may need to be implemented after the main mechanics and features are implemented.

Conclusion

The project satisfied the aims outlined, the GDPs were implemented in such a cooperative game. However, there is still room to add additional features to enforce these GDPs. The cooperative gameplay, while functional, could be better balanced as stated before. This did help achieve my second aim in exploring cooperative gameplay, The mechanics and controls are novel enough to be engaging themselves , multiple playtesters have expressed engagement and joy when simply moving the body and limbs.

Some elements could be implemented in the future like addtional limb types as originally intended. Doing so would require unique obstacles to challenge those limb types, and so would further the Unique Challenges GDP. My main change to my approach to this project would be to examine and compare solutions to game design problems encountered, this would give me a better understanding of the solutions implemented and a chance to consider how they would affect the other elements of the game.

Many new additions had been made to the game, these include a new weight system that accounts for different limb type behaviours and weights. Simple content generation has also been introduced depending on player choice of limbs. Additional visual elements have been introduced for both the UI and textures and objects.

New Visual Elements

Results from the Visual Aesthetics case study found here. The implemented elements include changes to the UI, materials, textures and lighting.

UI Elements

Bright Colours used for large text, this was done to contrast with the dark background. All text throughout the game uses the same font as well as the same colour, this was done to maintain consistency, however there may be room to change this since this font can be difficult to read at smaller sizes. Other font colours have been used to emphasise text when appropriate. E.g buttons and button text reflect the UI colour choice when players are choosing their player colour.

Previously, players have expressed slight confusion with the menu UI. They especially found it difficult to tell which button was currently selected. To remedy this, UI image pointers and button colour transitions were used to highlight which button is selected by the player.

Colours were also adjusted to vibrant hues to contrast from the background.

Textures

• 

• 

• 

Textures of objects are kept simple and cartoonish. They use 512×512 texture maps without bump/normal maps to maintain the desired aesthetic.

Skybox

• 

• 

• 

• 

• 

• 

The Skybox was produced with dark blue colours and soft edges to emphasise the immediate in-game surroundings. However there are some issues with the skybox, the edges of each side do not blend together so well. This is a small issue as the in-game camera angle looks down towards the ground and follows the zombie body.

All the above elements were produced with a cartoonish style identified in the previous case study. Upon reflection, the sprites and images used for textures, while bright, did not necessarily fit the tone and general atmosphere I wanted to get across. As such some post-processing effects were added to darken shadows and draw emphasis on lights.

Gameplay

Content obstacle generation

Previously playtesters expressed that playing the Arm limbs would be boring and that they had nothing to do when playing as the arms. This was addressed by producing obstacles that challenge both players controlling both legs and limbs. These challenges are expressed as obstacle type courses that players must navigate.

These obstacle courses are presented in different sections which can be generated depending on what the player’s limb choices are.

Player count reduction

Maximum player count has now been reduced to two players. It was found that more than two players can be too difficult for players to manage, which caused tension during some playtests. This is because limbs need to coordinate in order to move effectively. For example walking with the legs requires timing skills, this was shown to be difficult should 2 players control a leg each.

Part of the reduction was to also lock choices for limbs. That is players can now choose only both legs, only both arms or every limb to control exclusively. This could possibly relieve some of the tensions and make it easier for players to control the limbs as they can solely focus on those limb actions.

New Limb system

Too many bugs and issues were found from playtesting (zombie body floating away, limbs getting stuck in objetcs), as well as some general gameplay issues where players expressed slight frustration at how the zombie limbs acted. This lead to reconsideration on how the zombie body forces are handled and how other limbs work. As such a new Limb System was developed that would aggregate masses of every limb part and torso, this was then used to adjust the upward standing forces on the body to keep the zombie body upright. This was a better approach as it could react to different limbs and possilby support additional customization of limbs, for example part of the original plans of the game were to allow players to customize the limbs they control by changing the length, number of limbs or even how it would function. The below steps were taken to implement this new system:

• Limbs were reweighted with the following percentages: https://exrx.net/Kinesiology/Segments. The system takes checks the masses of every part of the zombie body.
• Upward standing forces are adjusted to use the correct amount of force based on the combined total mass of the body.
• Regular type foot behaviour was modified. Before, large mass was applied for each foot when not active/used by the player. This force was so large it disrupted the behaviour of the torso and other objects like the obstacle course objects, resulting in physics bugs like spasms and stretching meshes.
• Thumbsticks now control the corresponding limbs on their sides. That is the left thumbstick controls the left side limbs, and vice versa. This was done to further simplify the controls and to resolve any confusion. However, this has now taken away the ability to rotate the arms over and under the shoulders. So limbs can only move on a horizontal plane. This is not too much of an issue as none of the obstacles and challenges require this ability. However, this does limit the possible challenges that could be produced, then this new addition must be kept in mind when producing additional obstacles.
• Now limbs “grab” objects by creating temporary joints between them, this seems to simulate stepping well enough. Possibly reducing frustration and confusion with the limbs.

With these new adjustments made, playtesting was conducted.

Playtesting

The following playtests were conducted with playtesters who already had experience with previous builds. These were conducted in-person. Afterwards playtesters were questioned with a focus on the above changes.

03/11/2021

UI

• Playtesters found the colours used to be clear.
• One playtester expressed some concern with accessbility for colour-blindness. Specifically when players are choosing their UI colours, the choices are between Blue and Red. Red is difficult to differentiate from green for those affected by Colour Vision Deficiency (which composes a majority of text colours)
• Players found it clear which button is currently selected.
• Players did not express any issue with each menu.
• It was still not clear to single playtesters that the both the legs and arms are selectable.
• UI and overall aesthetics impress players of a “retro but modern feel”, one playtester said “it reminds them of early 2000s games.” This is great as it is the intended efffect.

Physics

• Limbs can become stuck to surrounding objects.
• Zombie body head becomes stuck inside the torso.
• New approach for leg behaviour works well, however floating is still possible though not as drastic.
• Bug occurs where grabbed objects cannot be dropped.
• Similarly legs can become stuck to objects when “stepping”.

Gameplay

• Playtesters expressed slight frustration when the zombie body is behind various obstacles as it is obscured.
• Triggers for leg activation can be prevented if players push thumbsticks then press triggers.
• Players still need to be told how to control the zombie body and it’s limbs.
• Grabbable objects cannot be easily grabbed. Especially the hammer for breaking brick walls, this can be easily pushed down and away. It is difficult to reach afterwards.
• Obstacles are still visible and well lit with the new post-processing and lighting settings.

Player suggestions

• A magnetic mechanism, that lets players attract and float grabbable objects to the grabbing limbs.
• Change text in limb choice to explicitly communicate both limbs can be chosen.

Playtesting fixes

• UI Explicit limb choice – Make it clear to players that both limb sets can be chosen.
• PHYSICS Sticky limbs – Current limb behaviour involves limbs generating temporary joints, this can sometimes generate an additional joint that cannot be destroyed as intended. As such a management and check system for the joints may be approrpriate. This would apply for arm grabbing objects.
• PHYSICS Floating check – A similar system like the one above could implemented where the zombie body is brought back down should the lower half not be in contact with ground type objects.
• GAMEPLAY Dithering visual effect – Another system may be needed for detecting when the zombie body is obscured by objects and changing the opacity of the materials of the obscuring objects.
• GAMEPLAY Tutorialisation – A possible short section of the game may be needed where players are shown how to use their respective controls, this may be similar to the original plans where players must use their respective controls to burst out and move in a small space like a coffin. The purpose of this would be to demonstrate the player’s different controls for the different limbs.
• GAMEPLAY On-screen UI – Onscreen UI Images could be used to show player input of the limb buttons.

A Different approach to Customization

One large issue is the different limb types. So far all obstacles and challenges have been designed with the regular type limbs in mind. Other limb types have been produced that are selectable and functioning, however they incur their own bugs and issues. Furthermore, unique challenges and obstacles need to be developed to challenge these specific limb types. This would require a lot of time to produce sufficient amounts of obstacles for each different limb type. As such I have decided to remove the limb types, and instead implement the ability for players to customize the regular limb.

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.

• 

• 

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].

A prototype menu for detecting multiple controllers had been produced. Beforehand the controllers were randomly assigned to each limb, there was no way to direct which controller controlled which limb. After spending time with the new Unity Input system and creating a menu that handles multiple player inputs, it’s now possible to assign controller devices to specific limbs.

Start menu and controller joining

Menus currently use placeholders. The start screen and all other menus cannot be interacted with the mouse and keyboard, instead a controller must be used to interact with the menu. This was done to make it clear to the player that contorllers are required. Text is also used to communicate this.

The next menu is a controller device join screen, a maximum of four (one for each limb) slots are shown. The goal of this menu is to detect if specific controllers work and then add that device as a player. After detecting the device a game object is instantiated that handles all inputs from that specific controller. This can then be used for every other instance of input.

Players are then asked to choose a colour to represent themselves in UI and during gameplay. This is so that players can distinguish themselves from other players.

Once colours are chosen players are then asked to choose a limb they wish to control. Then the game scene is loaded.

Players can select the same limb to play as, which has hilarious consequences. This is however not intended.

Here the limbs that players have chosen to play are coloured in the colours they chose in the previous menu.

Initial issues and possible improvements

Initial testing has revealed several issues with the menu and it’s implementation:

• Players are able to choose the same colour depending on when they join their controllers.
• Total of 4 players have not been tested yet.
• Limb selection is limited to left and right arm.
• Players can select the same limb to play.
• Cannot select different limb types to play as yet.

These issues will be resolved next and then needs to be externally tested. Once this has been done, I feel I need to move on and consider the next steps for the project and how the game works overall. This would include:

• General approach for level design.
• Visual aesthetics.
• Obstacles to overcome.
• Limb types to choose from.

Level design

How the camera is currently implemented is that it is fixed from a certain distance “behind” the zombie body while following it as the body moves in it’s respective cardinal directions. This has several positives to it:

• Zombie body and limbs are clearly visible at all times, save for when limbs are wrapped behind the zombie body from the camera view.
• Direction of thumbstick movements are kept consistent with camera view. That is the directions of the thumbstick are not affected by the zombie body direction, instead pushing “forward” on thumbsticks moves limbs “forward” away from the camera.
• Camera provides clear view of the surrounding environment with the zombie body within the centre camera view.

This informed how the approach for level design, that is a lane composed of “rooms” that holds different obstacles and paths for the player to navigate. At the end of this lane is the end/exit point that the zombie body must reach.

Implementing Avatar Customization Game Design Patterns

From my Thesis on Avatar Customization, I had produced 3 different Game Design Patterns:

• Customization Choice Provision – Individual player’s avatar customization decisions are communicated to other players in the same team.
• Emergent Customization Challenges – Unique gameplay challenges that arise from privileged abilities granted by avatar customization options.
• Customization Generated Components – Unique game components are generated by player choices in avatar customization.

Customization Choice Provision has already been implemented in some manner as shown above in the menus, that is by allowing players to concurrently make their choices. Then players can see each others make decisions. However, there is still some room to customize the individual limbs themselves, this has not been implemented yet.

Generate levels based on limb choice

This is the Customization Generated Components pattern, this case would involve level generation. Taking experience and inspiration from the Post Mortem game, I plan to use a grid based approach where different prefabricated “rooms” are generated based on player choices.

Generate levels

This will follow what the Customization Generated Components GDP, for this game I plan to generate unique environments that would utilise the customization choices players make. For example, should a player select a tentacle then far reaching objects or platforms that only the tentacle can reach. For now this won’t be a procedurally generated process, instead pre-produced cells of platforms would be

What limbs to use?

The following possible limb types were composed from playtesting, tester suggestions and the bugs and issues that arised from development.

Piston

Two section limbs that fire out an extended third section with a large force that pushes the zombie towards the other direction. Upon impacting a surface it will push the zombie or push the non-static object.

Pressing limb action fires the piston once, and it shrinks in after some time. Ready to be fired again.

Issues

Could cause the zombie to fly away really far and cause chaos, which is good, hard to control.

Jet

Press and hold to engage jet engine, forward thrust on the engine. Limited and rechargeable fuel.

Issues

Can be difficult to control due to the body. One engine will require another to balance the other.

Wheel

A rotating wheel that pulls the body along, this only happens when the wheel is in contact with a surface. Two different buttons for accelerating and deccelerating.

Issues

Difficult to produce, hard to control with just one wheel as well.

Detachable

Limbs can detach, move and do things independent from the rest of the body.

Issues

Detaching will affect the balance of the rest of the body. A different approahc for controls of the limbs will be need to be developed that would allow for single limb movement.

Inflatable

An limb that inflates and allows the zombie to float. More inflatable limbs means a higher float height.

Issues

Limb may become difficult to control if floating as there needs to be a way to steer the rest of the body. The upward force of one limb needs to produce the right amount of force without pulling the body to higher heights.

Cannon

A cannon as a limb that fires a ball that destroys destructible walls and moves objects out of the way. As well as adding a force for recoil, possibly as a way of moving the zombie body.

Issues

Accurate control over aiming will be difficult to maintain as body is constantly moving.

Forever stretching limb

A limb that can extend and stretch for a long distance (virtually infinite). The limb will extend and add additional joints.

Issues

The camera cannot allow that player to follow where the arm would go, as such the player will not be able tojudge accurately where the limb ends up.

Next Steps

Before these different limb types can be implemented, the menus for selecting limbs and their different types will still need to be developed.

Some fixes and new additions had been added. More importantly camera placement has been implemented where the body is tracked and multiple controller inputs were implemented.

New additions

Texture placeholder

New zombie body texture was made. This was done to make it visually clear which direction the zombie was facing.

However, upon testing, it was found that the position of the camera made these textures less prominent. There may need to be additional visual aids to indicate the direction of the zombie. This became extremely necessary when different controllers are designated to control different limbs, the zombie can rotate a lot so it is easy to lose track of which controller controls which limb.

Leg floating resolved

Floating issue was resolved, ensuring that only one leg can be controlled at a time. This same approach was applied to every other limb. That is before, the thumbsticks would control both arm and leg.

Now they each controller controls only one limb at a time.

New camera system

The new camera was implemented with the cinemachine, this is placed directly behind and follows the zombie around.

The motivation for this is so that the player(s) are able to see the whole body as well as the space around the body, as such a clear view of the action is visible. The shadows of the body and other objects help with judging distances between objects, however there may be room to add additional visual aids to clarify the position of the zombie.

Multiple controller devices

The Unity Input system had been added, now multiple controller devices can be used to control different arms.

However, there is still a need to allow the player to choose which controller controls which limb. Some kind of system to handle this would be useful, this would also be useful in allowing the player(s) to manage and choose different limb types for each limb part.

Limb Management System

I believe the next step for the project is to implement a customization system for the limbs. This will be presented as a menu before gameplay begins. This is also a chance to implement visual aids to clarify which player is controlling which limb. A case study will be conducted to identify how other games approach multiple controller/player management.

Octodad (Young Horses, 2010)

Has a separate menu that lets players designate which controller controls which limb. This has the benefit of letting one single controller control additional limbs as well as disabling an arm, this is possible as only one arm is necessary for gameplay.

There is also a roulette mode that randomises the designated limbs.

More importantly, Octodad makes use of a visual effect to highlight which limb is being controlled by giving players a colour.

Note also how the body is translucent while the tips of the limbs are still clearly visible. This helps with interacting and visually tracking objects through the Octodad body as well as making it clear which limbs are being used.

Mount Your Friends (Stegersaurus Software Inc., 2014)

Mount Your Friends approach to cooperative gameplay is turn-based, this reflects their process of adding additional players for cooperative games. That is additional players are able to enter their own name as well as choose a team.

• 

• 

Once additional players have entered their name they can choose a team to play as. Teams are composed of different characters that can be cosmetically customized. Doing so allows the player to add additional cosmetic artifacts and colours. Within this team customization menu, additional team characters can be customized and added to the team.

This customization can be used to differentiate teams, although the player is free to customize teams how they wish.

• 

• 

• 

See also how individual limbs, when manipulated are highlighted in red and have glowing aura around it. This makes it clear which limb is being controlled.

Mario Kart 8 Deluxe (Nintendo, 2017)

Mario Kart 8 allows up to 4 players in a cooperative play setting. Upon selecting the chosen amount, players are then asked to connect their controllers by pressing both bumper buttons at once.

This an effective way of handling and establishing which player controls which device. Doing so also readies every player for the selecting an avatar. This is a simple process where each player concurrently selects a unique avatar to play as.

Each character is visually distinct from one another. Players are also assigned a colour to be associated with.

Players are then able to customize the kart their avatar will be riding, this offers both cosmetic changes and ability related changes. Helping players to further differentiate their avatars. However, this is not a major problem for local cooperative play as it uses split-screens for such games, assuming players can identify their assigned screen.

What can be used

• Menu system that let’s players designate which controller controls which limb.
• Use of visual aids to identify each player (e.g unique colour).
• Cosmetic options to visually differentiate players.
• Visually highlight active limbs.
• Button inputs to connect/affirm which player is controlling which device.

Next Steps

A menu and system is required to manage multiple players and the limbs they wish to control. For the game this may be composed of two menus. One for detecting/declaring which device is controlled by which player and another to handle which player controls which limb and to customize each limb.

The prototype shows players the whole body. Each limb slot will have Player numbers and Name of slot displayed. Players will also be able to swap between different limb types.

As such the following menus will be made to implement this system:

• A menu for choosing the number of players and to detect/connect controller devices and assigning which limb for each player to use. Here each player will be assigned a colour.
• A menu for customizing each limb, as shown above.

References

• iMore, 2020. How to Select your Controllers. [image] Available at: <https://www.imore.com/how-set-multiplayer-races-mario-kart-8-deluxe> [Accessed 31 August 2021].
• iMore, 2020. How to set up a local race. [image] Available at: <https://www.imore.com/how-set-multiplayer-races-mario-kart-8-deluxe> [Accessed 31 August 2021].
• Nintendo, Nintendo Entertainment Analysis & Development, 2017. Mario Kart 8 Deluxe. [Video game] Nintendo Switch, Wii U. Nintendo.
• Stegersaurus Software Inc., 2014. Mount your Friends. [Video Game] Microsoft Windows, Xbox 360. Stegersaurus Software Inc.
• Young Horses, 2010. Octodad: Dadliest Catch. [Video Game] Android, iOS, Linux, Microsoft Windows, Nintendo Switch, OS X, Playstation 4, PlayStation Vita, tvOS, Wii U, Xbox One. Young Horses.

New additions to the game were controller input, grabbing action with a limb type and an approach to moving the body had been implemented.

Controller Input and Stepping

Controller input was implemented first. This was done because the desired outcome of this project would be played with controllers. As such implementing Controller inputs will influence the overall approach to how the body and the limbs will be controlled. For the purposes of this project, the main approach to controlling limbs, that is rotating them in their respective anchor points, is done by manipulating the two thumbsticks. For now, both thumbsticks upon being pushed will move the limbs along a plane defined by 2 local axes.

This has been used to control the legs of the zombie.

This follows Octodad’s approach by linking the trigger buttons to the respective leg limbs. So pressing and holding the left trigger results in two things. 1. The left foot’s mass is reduced. 2. Both thumbsticks now move the foot and apply forces to move the foot.

So while the trigger is held down, the left leg can be moved. Right trigger enables the right foot.

However an interesting bug had arised, when both triggers are pressed and thumbsticks pushed. The Zombie is able to propel itself upwards.

This bug may be due to the body having a constant upward force applied to keep it standing, this force does not change. So when the feet triggers are pressed together, the overall body mass is significantly lighter and the body floats. Moving the legs propel it somewhat. However, this could be used for a different mechanic of some kind.

Separate thumbstick axis

Another addition that is shown above and below is the use of both thumbsticks to move a limb around different axes.

This should offer more control over limb movement. Moving the arm under and over head is controlled by the right thumbstick.

Object interactions

With the new dual thumbstick controls added it was time to interact with some objects. A grabbing mechanic had bene implemented where a non-static object can be grabbed. In this case the hand of the limb touches the box and the player press and holds the grab button, the object will then be connected to the hand by a joint.

It is possible to grab, pick up and throw the box, however there is no accurate way of throwing this box.

Interacting with non-static objects was simple enough. However, the desired result is for the player to be able to pull the zombie towards the box.

The above was replicated at height and gravity applied.

While the box could be grabbed, disastrous conseuqences followed when the limb became overly stretched. I wondered if it had something to do with the static nature of the blue box or the colliders of the body and arm. So a rope was implemented that was non-static and consisted of multiple smaller bodies.

This too resulted in the disastrous effects. I believe this may be an issue with the joints, the colliders and how I implemented them, which may take some additional research to find a solution.

Playtesting

The controller input, general arm movement and stepping had been externally tested by a playtester, they were instructed to think-aloud voicing their thoughts. Their emotions and reactions were also examined. The purpose of this test was to determine if the controls were intuitive and easy to use. What the general feel of the controls were and if they were at all fun to use.

Playtesting results

Follwing issues were found :

1. Thumbstick drections are not clear, that is they do not align with player intention. “Feel like it’s opposite to what the directions feel like.” Playtester was not able to move the arm in the direction they wished. This comment was made with some frustration. Playtester was then instructed to control the feet by using the triggers. They also made the same comment about the thumbsticks. “Joysticks move in opposite directions.”
2. While moving controlling the feet, playtester discovered the floating bug. However, expressed a large amount of joy and laughed aloud. “This is how a person walks!” said playtester regarding the moment of floating. “Then he comes back down!” said Playtester laughing as the zombie body gently float downwards.
3. Limb joint spasming as seen from the above gifs.

Playtesting fixes

The results of this indicate that the current controller inputs for direction are not intuitive and may need to be redone. I suggest the following fixes:

• Camera centreing – Playtest was conducted within Unity (same view as gifs above), two camera views of different direction could contribute to confusion of resulting movement of the thumbsticks. Then a camera system should be implemented that clearly represents direction of zombie.
• Zombie face placeholder – Another contribution to the confusion of directions could be to do with the blank zombie body. This is because the visual elements of the zombie (the model and texture) do not inform the player which way it is facing, this can only be discerned by the direction of the feet. Then implementing a texture placeholder that indicates the forward facing direction of the body may aid in limb movement.
• Change limb movement – The direction of the limb movement is not behaving as desired, then it may require more adjustments. This may even require a different approach to the limb movement overall. Current approach is to apply a force at limb tip towards a direction. There may be a better appraoch that may require more research.
• Change joint settings – There is an issue where joints can be stretched too far where they then begin to spasm out of control.
• Floating is fun – The floating bug resulted in positive feedback from the playtester. As such this bug could be implemented as a different limb type to be chosen by the player. This will need some further analysis as to why and how it works. Then this could be implemented as a separate limb type as I had said before.
• Adapting different controllers – Upon reflection, I realised that the controller could also have affects on the game. This is because Internal testing had been carried out with a different controller. The External playtest used a different controller. Note that both are PS Dualshock4 Controllers. Then controller mappings and implementation need to be reconsidered as well.

Next steps

• Implement above fixes.
• Plan and prototype a multiplayer management system.

In this log I show how the prototypes were developed for limb behaviour and structure, these began with a standard arm composed of an upper and lower arm as well as a hand. Then a tentacle type arm was developed as well as a torso to test for stability and to get a general feel for the manner of limb movement. A case study was then conducted to examine how other games handle limb movement.

Two limbs and two methods of control

Two different limb types were developed, each of which had two different methods of control. One was a limb that functions by adding forces to the upper limb to close and rotate with limitations. This would be a traditional way to manipulate an upper human arm.

So in this case the player moves the upper arm towards the cardinal directions. The upper arm pivots from the connecting body, shown above the connected body is a cube. The lower arm and hand are not affected by the controls and aimlessly flop around, this does produce the desired comical effect however. The results of this intial test, while promising does not grant accurate control of the limb. At best this maybe used as a way to swipe at objects, then it could be used for a different limb type.

The second limb was made without distinct joints, eventually becoming a tentacle. It is controlled by manipulating the tip of the tentacle, the rest of the tentacle is linked between the body and this tip.

These first two limb prototypes are controlled by keybaord which is not the targetted controlling device. In that case I believe enabling a controller device would be the next step.

The first iteration of these limbs were attached to a static box, which the limb is attached to. This was found to cause some issues with the joints in each limb. As such a torso was developed to attach the limbs to.

Torso to tie it together

This torso showed how the limbs would interact with each other and the environment. An interesting result was that the limbs produced enough force to pull the torso away and onto the floor.

This is undesirable so a constant upward force was applied to the torso to keep an upright stance. With the addition of this torso came legs too, next steps would be to add controls for the legs too.

During the implementation of the legs it was found that the legs would simply be dragged along the floor and not have any affect on the rest of the body. A simple solution in Octodad was to increase the mass of the feet to ground the Octodad feet, the same has been done here and there is evidently more stability. However this will be temporary as the legs are not affected by inputs.

The next step would be to implement an input system for controller devices, specifically the PS4 controller or Xbox controllers. This would affect the way a player would interact with the limbs, so the method of input would need to be considred and reasearched in other games.

Limb control case study

This case study will be focused on how input is approached in both Human: Fall Flat (2016) and Octodad: Dadliest Catch (2010). I will specifcally look at how:

• button mapping for controllers
• what character actions are possible to accomplish
• how the player character interacts with the rest of the game world

Human: Fall flat limbs

Human: fall flat’s controller layout is quite simple. One thumbstick is used to move the player character, the other controls the camera view. The two shoulder/trigger buttons are used for manipulating the hands of the player avatar. One button makes the avatar jump and another is ‘Play dead’ where the avatar enters a rag doll mode where the avatar’s body goes limp and cannot move.

This layout is quite intuitve as there are dedicated buttons for both limbs, these being the left trigger/shoulder button that controls the left hand and the right trigger/shoulder button that controls the right hand. The other input mappings follow traditional controller button mappings (left thumbstick for moving, right thumbstick for looking and the X or A button for jumping). The actions these buttons can achieve are fairly conventional.

The thumbstick for movement simply moves the avatar in the desired direction, accompanied by animation of the avatar legs (used to comical effect). The left and right trigger buttons move the hands outwards and are directed along the direction of the camera view, then if the camera is looking up the hands would be reaching upwards too.

• 

• 

These hands interact with the rest of the environment in specific ways. Once hands are extended, any surface that the hands come in contact with becomes stuck to the hand. This has different effects depending on the surface.

If it is a static part of the environment, the avatars hands are anchored to this surface and the avatar cannot be separated from it unless the player stops pressing the corresponding trigger buttons. This allows players to manoeuvre the avatar over ledges by sticking hands onto ledges and then moving the camera view downwards, which also rotates the arms and places the avatar over the ledge. For non-static parts of the environment, these being objects that can be pushed or moved by the player and other forces like gravity, the avatars hands can stick on to these objects and then be manipulated by the avatar.

• 

• 

Avatar climbing over a ledge.

• 

• 

Using objects to break glass.

Using the hands to attach to the oars, the player can move the avatar forward and backward to move the oars that will then move the boat forward.

Octodad: Dadliest Catch

Octodad has a unique approach to controlling limbs, that is the thumbsticks are used to maneouvre the limbs by moving them across planes as defined by cardinal directions. So for example, a limb is controlled by moving the position of the tip of the limb. It can be moved up and down and from side to side with one thumb stick, and forward and backward and around with the other. One other button is used to grab non-static objects that can be pushed around by a single button.

• 

• 

• 

• 

The button mappings for movement of limbs is mapped to the axes of the thumbsticks. The following directions are in relation to the camera viewpoint. So players can move the limb left and right with both sticks by moving the thumbstick left and right. In the above mapping, up and down is tied to the left thumbstick. The right thumbstick moves the limb forward and backward from the viewpoint of the camera. This method allows for precise controls for each limb.

• 

• 

• 

• 

• 

• 

Manipulation of the legs is slightly different from the arms, the default mappings have trigger buttons that lift the legs. They also change the thumbstick controls to affect the legs instead of the arms. Moving any limb far enough would result in pulling the avatar towards that direction. However, the feet have high mass when not active so the avatar can only stretch so far.

• 

• 

When moving the leg, the thumbsticks only move teh legs forward, backward, left and right. This lack of vertical control results in less control over the leg, however this seems to make sense as it reinforces the leg as a form of traversal and reinforces the arms as a form of interaction with objects.

• 

• 

Multiple objects can be grabbed by the player with the tip of the limb with a dedicated button press. These can be used to accomplish objectives. For example, one objective was to cook burgers on a grill, this involved picking up and placing the burgers onto the grilland picking them up and serving them again after it has cooked for some time. Another objective was navigate through freezers to acquire a pizza, this required manipulating the avatar through small spaces by leading the body with the limbs.

The avatar can also push and move objects simply by colliding with them, this usually results in chaos as objects fly around the level. There are also some moving objects like platforms that can move the avatar around.

What can be used

• Thumbsticks for precise limb controls. Octodad’s use of thumbsticks allows intuitive and precise controls of the limbs, this would be useful for grabbing and dropping objects.
• Grabbing mechanic. Grabbing is found to be one of the most important mechanics in both games and allows the player to interact with other parts of the game.
• Static and non-static objects interacted with the grab action. Human: Fall Flat’s environment can be interacted with the grab actions, either to grab and move an object or to stick the avatars hands to the surface.
• Object interactions via avatar movement. In both games objects are used to accomplish certain goals and actions. Human: fall flat allows the player to row a boat via grabbing both oars and moving the avatar forward and backward to row the boat. In Octodad a Segway can controlled with both arms to accelerate the Segway backward or forward.
• Stepping mechanics. Octodad focuses buttons for controlling specific legs to move the avatar forward.

Next Steps

The above will be implemented with the current prototype. These additions will then be tested internally and externally to see if these controls are accurate and without too much difficulty. More importantly controller input will be implemented with the game.

References

• No Brakes Games, Code Glue, d3t, Lab42, 2016. Human: Fall Flat. [Video Game] Windows, Linux, MacOS, Playstation 4, Xbox One, Nintendo Switch, Android, iOS, Xbox Series X/S, Playstation 5, Curve Digital, 505 Games.
• Young Horses, 2010. Octodad: Dadliest Catch. [Video Game] Android, iOS, Linux, Microsoft Windows, Nintendo Switch, OS X, Playstation 4, PlayStation Vita, tvOS, Wii U, Xbox One. Young Horses.

FMP Initial concept and ideas

For this project I wish to create a cooperative platform that puts players in the control of a zombie’s limbs. Players have to work together to escape the graveyard where they have risen from the dead! The desired effects of the game are moments of chaos and hilarity, this would be well represented through the implementation of 3D phsyics and cooperative play.

Aims and Objectives

The FMP will put into practice the output of my Thesis, these being the Game Design Patterns for cooperative games. A consequence of this project will be to also explore cooperative gameplay and design.

• Implement GDPs from thesis – The GDPs from my thesis focus on player customization and how these choices can result in meaningful consequences that affect the game.
• Cooperative gameplay – The GDPs specifically focus on player customization in cooperative games, as such this project will also involve the implementation of a cooperative system that allows for cooperative play.
• Physics based game with Limbs – For this project I will also want to explore physics based gameplay, this would involve featuring mechanics that involve rigidbodies and forces. As well as designing obstacles that would challenge such mechanics.

Features

• 2-4 Player coop. Each player controlling one unique limb.
• Split screen output, each screen focusing on one limb.
• Physics based movement.
• Platformer style-obstacles, requiring cooperative action to overcome.
• Each limb can be customized by the controlling player.
• Customization options include abilities, length and size of hand.
• Limb choice will influence the obstacles spawned in the map.
• Graveyard keeper will be patrol the graveyard to capture the zombie.

Gamplay loop

1. Players choose a limb position (Left Arm, Right Arm, Left Leg, Right Leg).
2. Players choose what type of limb: Skeleton, bloated, boneless…
3. Players customize limb properties: Length, Size…
4. Level begins with Zombie in the coffin, all players move their limbs to bust out of the coffin.
5. Players must navigate around the map and find the exit.
6. Identify the obstacles blocking the exit.
7. Players work cooperatively to manoeuvre the entire Zombie body towards the exit.
8. Reaching the exit ends the Level.

Games to Case study

• Human: Fall Flat (2016): has limb based mechanics to manipulate the arms of the player avatar. The limbs are used to overcome physics based obstacles. This game also features a limited set of customization options for player avatar models. There is also a split-screen coop mode.
• Octodad: Dadliest Catch (2010): again the main mechanic is controlling the limbs of the avatar. The player is able to pick up and throw objects found in the environment to solve various objectives. The player must also avoid causing too much chaos in front of NPCs to keep their Octopus identity secret. There is also a multiplayer cooperative mode where players can control separate limbs.
• Tom Clancy’s Rainbow Six Siege (2015): features limited choices in customization that affects a players approach to the game in many ways.
• Screencheat (2016): has unique approach to split screen output. Where players watch other screens to acquire information on the other players location to eliminate the respective player. This approach is required as every player is invisible in Screencheat.
• WWE 2K19 (2018): In-depth limb and body customization. Allows players to create different types of wrestlers based on choices.

PREVIS

This is a previsual for what the split screen layout may look like. David had commented on how this split screen layout may compromise the player’s view of the central zombie body, this may need additional consideration.

Approach to limb movement mechanics

Cursory research into games like Human: Fall Flat and Octodad make use of ragdoll physics. In a Post-mortem for Octodad: Dadliest Catch (2015), Kevin Geisler explains that the Octodad body was:

• Composed of hard segments that was controlled by forces with no Inverse Kinematics applied.
• Smaller forces were applied to the rest of the body to keep the body stable.
• The feet were made to be extremely heavy when not in use this was done to simulate stepping.
• This was mixed with stretchable limbs to allow more freedom of movement.
• Use of XML file to handle multiple input devices to handle button mapping.
• Limb movement is done in two axis planes in relation to the camera view with two corresponding movement input buttons. For example, with a ps4 controller, a limb can be moved along the X-Y plane using one thumbstick, the other moves the stick along the Y-Z plane.
• End of arm limbs can also grab objects

Human: Fall flat makes use of an active ragdoll body that blends animations and Inverse Kinematics. This is applied to a rigged body with armatures, and joints for the different body parts. The control of the limbs is composed of the following:

• One button controls one arm, e.g left mouse button controls left arm, right mouse button controls right arm.
• Mouse buttons engage the arms, they extend outwards reaching in front of the body, should the end of the arms collide with an object it is picked up by the body. If it is a wall then the arms stick to the wall.
• Top torso’s facing direction follows camera direction. That is if the camera looks up, the top half of the body faces up, if it faces down the body bends over at the hip facing down.

What can be used:

• The limbs being composed of multiple small bodies that can be controlled by the player.
• The controls needed to mappable to multiple controller devices.
• Various small forces to stabilise the entire body.
• Grab and hold abilites for limbs.
• An active ragdoll body.

Ragdoll prototype

Working with ragdolls is fairly new to me, as such a prototype for the ragdoll had been developed. This body is able to somewhat stablilise itself with simple animation, however manipulation of the limbs resulted in disastrous results. This had been developed with the following tutorial: https://www.youtube.com/watch?v=-pX-PobRLzk&t=567s (Jasony, 2021). The issue was likely with the manipulation of the limbs, the transform of which were oddly affected by the method of rotation.

This made it clear that the easier approach would be to implement limbs separately from the body. That is the limbs should be a separate object and mesh from the body. Therefore the next step for the project would be to implement a prototype of single limbs and test different approaches on how the limbs would be controlled.

Two limb control approaches

Approach 1

• 

Dedicated inputs for controlling the rotation of the shoulder joint, these are designed for the thumbsticks in mind.

Approach 2

Player controls the direction of the end of the limb, another input controls hand movement along this direction.

References

• Geisler, K., 2015. Octodad: Dadliest Catch Post-Mortem Pt. 4: Tech. [Blog] Octodad: Dadliest Catch Post-Mortem, Available at: <https://www.gamasutra.com/blogs/KevinGeisler/20150330/240000/Octodad_Dadliest_Catch_PostMortem_Pt_4_Tech.php> [Accessed 20 July 2021].
• Jasony (2021). How to Create Gang Beast Character in Unity (Active Ragdoll Tutorial). [Online Video]. Available at: <https://www.youtube.com/watch?v=-pX-PobRLzk&t=567s>. [Accessed 20 July 2021].
• No Brakes Games, Code Glue, d3t, Lab42, 2016. Human: Fall Flat. [Video Game] Windows, Linux, MacOS, Playstation 4, Xbox One, Nintendo Switch, Android, iOS, Xbox Series X/S, Playstation 5, Curve Digital, 505 Games.
• Samurai Punk, 2016. Screencheat. [Video Game] Microsoft Windows, Linux, OS X, Playstation 4, Xbox One, Nintendo Switch. Surprise Attack.
• Ubisoft Montreal, 2015. Tom Clancy’s Rainbow Six Siege. [Video Game] Windows, Linux, MacOS, Playstation 4, Xbox One, Nintendo Switch, Android, iOS, Xbox Series X/S, Playstation 5. Ubisoft.
• Young Horses, 2010. Octodad: Dadliest Catch. [Video Game] Android, iOS, Linux, Microsoft Windows, Nintendo Switch, OS X, Playstation 4, PlayStation Vita, tvOS, Wii U, Xbox One. Young Horses.
• Yuke’s, 2018. WWE 2K19. [Video Game] Microsoft Windows, Playstation 4, Xbox One. 2K Sports.