For now, we are going to proceed with the built-in Unity Networking. Its model more appropriately fits our needs, and is easy enough to use. This decision may change as we continue to work on networking this next week. We were able to get a local server set up, and connect clients to it, and have players move around.
All players are created with the input script, movement scripts, and even the cameras. However we disable all of these by default, only enabling them for the given client's player.
We immediately noticed the issue of using rigidbodies to control our players. When players collide, the physics engine will begin fighting against the NetworkPlayer script that updates the player's location. This is a serious issue, as the physics engine is still currently crucially important to how we will interact with the other game objects. However, now that we have started to work with networking and physics together, we may need to reassess how we are controlling the player.
Goals for tomorrow:
- Write a Movement Script with the Character Controller (as opposed to a rigidbody) and see its effect on network movement
- Write a super class for both of these scripts, that defines an interface to move the player and rotate them
- Write a Platform Manager that will create all the platforms at the beginning of a game (for the server), and tell all the clients where to create the platforms
- Write a Platform script, that defines some basic platform information (this is mostly placeholder for stuff later)
- Discuss how player interaction should work
- What happens when players collide with each other? Going fast? Going slow?
- What happens when players collide with a platform?