Hi there. Here’s something you might like to use as a starting point.
Attach Playerscript.js to your Player prefab, which also should have the standard CharacterController, CharacterMotor, FPSInputController and a NetworkView (sync off, only used for RPC). Make sure the CharacterController is set to use Update rather than FixedUpdate (use the checkbox in the editor view).
Here are the initial comments in Playerscript:
// This is a networked FPS controller for use with a server which is authoritative
// when it comes to position and rotation of players. All movement is calculated by
// the server: the players simply submit their desired 3D travel vector, and the
// server updates the position and rotation using RPC calls. Smoothing is employed
// on the player machines by default. Tilt (looking up and down) is handled specially:
// each player is authoritative for the Y rotation axis, the server is authoritative
// for the other rotation axes.
//
// At the moment, simple capsules are used to represent each player. This script
// will be extended to support standard animated characters. The end goal is a
// character controller which will be able to switch between the 1st and 3rd person
// perspective. Sound will also be incorporated, to support footstep sounds that vary
// automatically with the floor material (snow, sand, grass, metal, concrete, etc).
//
// The Spawnscript takes care of spawning the players. It can be configured to run
// the server headlessly, which simply means that no player - and no camera - are
// spawned on the server. This is essential for any larger application, as an
// authoritative server shouldn’t be bothered with rendering graphics. Running
// PhysX physics calculations alone is not very heavy - but rendering the results is.
// Running in headless mode often results in a server frame rate increase of at
// least 100x, which means that multi-user setups become much more viable.
//
// Another important point is that programming an environment where code must
// run with identical results on both the clients and the server is a complex
// and sometimes confusing task. Your code will be much, much easier to maintain,
// extend, and understand, if you keep a strict separation between the two. However,
// this player controller is written to run both client-side and server-side,
// since peer-to-peer networking is common in the Unity world.
//
// Creating an MMORPG is quite another ballgame though. It can be done, and this
// character controller is very suitable as a starting point for such an endeavour,
// but if you have the know-how to create an MMORPG, then you also know that you
// need a dedicated server cluster solution, such as SmartFox2X, ElectroServer5,
// Badumna, etc. There is no way you will be able to rely only on the built-in
// networking.
//
// A few notes on the architecture and the rendering process:
//
// Updates: many, many. Once every frame.
// Good on the client side (and on the server for any local player,
// though servers should ideally run headless) to do smoothing.
// Where local client player input (whether on the client or the
// server side) should be converted into a direction (by CharacterMotor).
// NB: the CharacterMotor should be set to run during Update, as we take
// care to notify the server only where things actually change.
//
// LateUpdates: just as many as the Updates. Run after all Updates in a frame have run.
// Used in the same situations and places as Update, typically to modify
// a transform before the physics engine can change it.
// This is where we transmit changes only if there are any to the server
// using RPC (and a duplicate local call, in the case of the server, due to
// a bug in RPC).
//
// FixedUpdates: more seldom.
// This is where we apply forces to rigidbodies. We don’t use FixedUpdates
// for communication, since they are much less granular.
//
You also need Spawnscript.js. Attach to any world object. The spawnscript is basically a very slightly modified version of the same script from M2M’s Networking Tutorial, Example 3 (thanks, Mike Hergaarden!), but with a boolean added to control running headlessly.
454352–15900–$Playerscript.js (11.3 KB)
454352–15901–$Spawnscript.js (2.56 KB)
I unchecked “Fixed Update”.