Feature/player persistence visuals #356
Conversation
fernando-cortez
added
the
1-Needs Review
fernando-cortez
added
4-On Hold
|
Placed on hold to verify potential refactorings from MLAPI features. |
fernando-cortez
added
1-Needs Review
| { | ||
| // TODO: Re-implement CharSelect preview (GOMPS-550) | ||
| //m_InSceneCharacter.gameObject.SetActive(true); |
There was a problem hiding this comment.
I was wondering when this will be done
pdeschain
added
WIP
|
Had a call with Fernando - we discussed changing PlayerAvatar structure now instead of later, incorporating NetworkAnimator. This way we won't need to deal with another PR that changes structure of how player gameobjects are structured. |
…efactoring, rereferencing
fernando-cortez
added
1-Needs Review
| targetPosition = targetNetworkObj.transform.position; | ||
| } | ||
|
|
||
| if ((m_Parent.transform.position - targetPosition).sqrMagnitude < (padRange * padRange)) |
There was a problem hiding this comment.
On a stylistic note - I would much rather prefer this boolean value to be captured into a variable with an explicit name VS having a comment. Has to do with comments being fragile code smells almost in all cases.
There was a problem hiding this comment.
It's not a request to change anything - more so a general observation about our codebase. We have these comments that describe what's happening in the logic, where a properly placed and named variable would do a better job in the readability and maintainability department.
There was a problem hiding this comment.
Agree on this. Best to just be explicit.
Part 3/3 of Player Persistence. Jira here.
This PR fixes any visuals that were omitted from Part 2. This re-introduces names/health/portrait to
PartyHud, and re-introduces the world-space displayed name for a player avatar.Notable changes:
CharSelectscene.GameStateRelayhas been removed, as character select data can be passed toPersistentPlayer. A late-joiner gets assigned a random avatar class.NetworkGameStateNetworkObject is spawned alongside the host. This keeps track of the win state. Server sets this component's win state, and clients read from this state value when presenting win/loss screen.PartyHudrefactor to initialize state as avatars are spawned inside BossRoom scene. This removed a fair amount of hard referencing inside ofClientCharacterVisualization. Systems are decoupled.