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.