Dev Log Updates 2024-03-04

devlogs/synthicate/2024-03-02.md

@@ -2,7 +2,7 @@
 layout: default
 ---
 
-# March 2, 2024
+# March 2nd, 2024
 This week in Synthicate I was able to add multiplayer remote procedure calls (RPCs) and configure the ability for players to join a game lobby and send their custom names. In the recent set of pushes from Friday, I fixed some functionality that updates the number of players that show up in the lobby (oshears/Synthicate@b3735cb). 
 
 One main issue that I ran into trying to implement this was attempting to initiate ClientRPC calls before the clients were fully configured. Apparently in Unity it takes the clients a moment to fully get setup, event after the server successfully connects with them. Thus, if the server sends out a ClientRPCs, but the client is not ready, then it will not receive the RPC successfully. This form post helped me to identify the issue, however I am still looking for a method or event that is trigger once the client is fully setup and ready to receive RPCs from the server.

devlogs/synthicate/2024-03-04.md

@@ -0,0 +1,12 @@
+---
+layout: default
+---
+
+## March 4th, 2024
+These past 12 hours I’ve done a deep dive into the Unity documents on scriptable objects. One of the main issues I was running into with my previous development was the overwhelming number of events in the scriptable objects that just kept increasing as I added even more of them. I learned from the Unity documents that they typically create a scriptable object base class to describe events, then instantiate that base class and make one scriptable object instance per event. I also noticed that they did employ the technique of invoking events when data inside of a scriptable object was changed. This might be true if data inside of a MonoBehaviour instance was changed too, but I don’t recall seeing any examples of this.
+
+I also read a little bit more into doing proper networking and multiplayer management. I reviewed two examples provided by Unity on this topic: Boss Room and Galactic Kittens. One of the main questions driving me was merging the state machine game design pattern with Unity’s Netcode framework for multiplayer. In the past, I created C# classes to implement the state machine and states for certain game managers. Each of these states was instantiated on the fly inside of another state. However, after looking at Unity’s examples, it appears that I should add all of the states to the Game Manager game object in the scene editor / inspector view, then configure attributes about that state using the inspector. By taking this approach, I can have each of the states extend NetworkBehaviour, and thus provide them access to network variables and client / server RPCs. 
+
+Some members of the Unity forums also indicated that mixing client and server code was typically not a good idea because it causes the code to be messy. For this reason, I believe I should consider having two state machines on the host (if necessary): one for the server and one for the host client. This way client logic can be distinctly separated from host logic and reduce the sizes of the Unity script files.
+
+Lastly, I watched a video today talking about party games and how there is a lack of good party games since the Wii era. I think I would like to make it my goal to resolve this and develop some more interesting and sophisticated party games for people to connect over.