Match Controller Component

Requirements

• Keep track of rounds in a match.
  • Every match has multiple rounds
  • The player with 3 rounds won, wins the entire match
  • The round is a free for all
  • Round win condition is last person standing
  • First round is played with basic starting weapon (No bidding)
• Chips (Currency for bidding)
  • You get 2 chips for winning a round
  • 1 chip as base each round
  • 1 chip for each player you killed during a round
  • Later in development you will get ~4 chips for selling a leg (as an example)
• Integrate bidding into match system
• Send players back to menu after match completion

Because its currently ugly

• Music that persists between scenes
  • for the menu
• Layers of synchronized tracks
• Seamless transition between layers

Turn players into ragdolls or something on death, prevent them from having any control over their characters.

When returned to the Menu scene, PlayerInputs will be transfered back to the scene, but are unable to interact with the UI despite having their input action remapped back to "Menu".

This seems to be a problem with how the Unity UI natively subscribes to the first (And only the absolute first) newly joined playerInput and nothing else, but I've yet to 100% confirm this.

Creation of a simple map that players can spawn, run around in, shoot in and hide.

• Player "wallet"
• Items - for now represented as scriptableobjects (simple objects with attributes such as name, description - this is what we extend with UnityEvent/delegates later on)
• Timer for when a deal closes

• #40
  • Add guns to players
  • Let players shoot guns
• #41
  • Add hitbox/health controllers to players
  • Make bullets know source player and pass this to victim
• Separate first-person and scene guns

• Create a "physical" bidding scene
• Create a new inputMap specifically for bidding scene
• #44
• Implement PlayerInventory directly into PlayerManager
• Integrate biddingRound to MatchManager
  • Round redirects to bidding
  • Bidding redirects to round
• Implement viewable gunstats for each augment at auction
• Countdown timer HUD
• Viewable chip amount (over players heads?)

Generate gun names based on the hidden name(s) of each gun part

• #48
• Round counter
• Remaining players counter
  • This should be easy to see from the other players' screens. We could show who killed a player there as well.

Singletons currently in the project are somewhat unsafe, considering they can be disabled. They also don't follow any standard on "when" they're initialised, leading to potentially unpredictable/unwanted behaviour.

Safety:
A singleton script should consider the scenario where either the component itself or the game object it is attached to is disabled.
As the singleton instance can be accessed from anywhere at any time, we should handle the (likely unwanted) scenario where a singleton component is being disabled (either through the game object being disabled or the component itself being explicitly disabled).

• Solution: do something in OnDisable in any singleton scripts - whether that be a warning log entry or otherwise, do something!

Initialisation:
As a singleton instance-field initialisation relies solely on itself, there is no reason - as I see it - for why any and all singletons should not be initialised in OnEnable, rather than in any of the later component messages. This may aid in reducing future annoyances in script execution order.

• Solution: move static field initialisation (singleton) to OnEnable

Model and textures associated with the auction scene

A list of augments for the bare minimum variety.
Additional descriptions can be found for each augment at the milanote page.

Bodies (Verb)

• "Pump"-action (hopp)
• #119
• #112
• #175
• bullet Pachinko/labyrinth

Barrels (Subjektiv)

• #79
• #83
• #180
• #173
• #174
• #190

Extensions (Adjektiv)

• #130
• #85
• #84
• #251

Sound sources with varying pitch and volume, and randomizable clip selection.

To use Player Input Manager's built in split screen functionality, one needs to assign cameras to each playerinput prefab.

My suggested solutions is to update the playerInput prefab to hold some specific values and components (Camera, color tied to player, player ID, etc.), then declare a Set-able refference property to this player input in the matching player prefab.

This way the player prefab can easily access the playerInput and the necessary components it holds, while avoiding the playerInput to be destroyed with the player prefab. (In case the game wants to destroy the player)

Our current file hierarchy is bit bad, in my opinion.

• Unity already has built in quick searches for file types (prefabs, materials, scripts, etc.)
• Having to navigate between many different folders when working on a single gameobject just because it has different types of components is annoying
• Naming conventions are harder to follow (and often not even used!)

We should rather sort files by

• Deciding on and following a good naming convention, to provide ease of access thorugh the asset search bar.
• Organize folders and package according to features rather than file type.

As Sondre said, it needs more omph.

Player characters tend to rubber-band after movement controls are released. They snap back to a previous position after a button is released

Items should have a field for flavor text and/or description of what they accomplish (e.g. "Stuns on hit").

Weapon is remembered from the previous bidding round.
Players can shoot and kill each other
Last man standing wins, and we move to the next round

To test out the practical development side of the new augment system, it was decided that someone other than @SondreHus should try to implement some augments. (The game need more augments too, ofc)

• Augment of each type (Alex)
  • Body augment
  • Barrel augment
  • Extension augment
• Augment of each type (Thomas)
  • Body augment
  • Barrel augment
  • Extension augment

Options menu accessible from main menu, with the following implementations:

• Sound control
• Screen resolution
• Custom button mapping

Desert arena with Western-style houses

• Terrain
• #295
• Props
• #235
• Functional level props

Hva den gjør:

• Skyter fort
• Skyter med en stor "spread" hence navnet dispenser

To-do:

• Modellere ferdig

Remodel AuctionDrivers to be per podium in the auction room.

• Pick an item from a stage
• ...

Promote manager functionality and data management into a manager class (possibly singleton object?)

• Who's in the auction still
• ...

Two visual effect systems:

• One for bullet path that controls the trail
• One for the bullet trails, displaying a limited amount of bullet trails following the bullets

Decide on the theme and artstyle of the game.

The current theme suggestion(s) are:

• Robot western (Robot cattlepunk)

The current artstyle suggestion(s) are:

• "Toony TF2"-like
• Rusty scrapheap vibes
• Steampunk-like

Operating system related editor preference files are not gitignored, specifically:

• ProjectSettings/Packages/com.unity.testtools.codecoverage/Settings.json
• ProjectSettings/ShaderGraphSettings.asset

Might potentially be more, but haven't found others yet.

Creation of the main menu.
Players join by moving their controller
All players can press buttons (see Smash bros)
Players can move between ui elements

Contains
Start game / Quit Game

A barrel that converts bullets to hats that are placed on the heads of your enemies.

• Model
• Materials
• Animation
• Implementation

Hva den gjør:

• Endrer size på bullets til store bullets
• Skyter en bullet om gangen
• Skyter bullets sakte?

To-do:

• Modellere

Death screen that is displayed when a player is dead.
No need to display how many players are left when we're doing splitscreen!

• Should indicate that the player is dead very clearly
  • Dark background (transparent overlay?)
  • Robot skull?
• Should show who killed this player

Every single SetPlayerInput function wishes to do something with the InputManager.

The InputManager script already holds a public refference to the playerInput it's tied to, and should thus itself be argument wich we pass to the various SetPlayerInput functions instead of the PlayerInput component.