Lógica del inventario

Actualmente el inventario funciona con está lógica:

Fantasma:
Controla la lógica que ocurre entre el jugador y el inventario.
Cuando se crea el jugador este usa un fantasma para tener sus habilidades y gestionar la interfaz UI, también replicaciones y datos a fines.
Guarda los datos del jugador (inventario datos).
Cuando el jugador muere o transita el fantasma queda limpio y en el cuerpo queda la copia de los datos.

Jugador:
El jugador se usa como iniciador para crear el fantasma.
El jugador posee en su cuerpo los controladores de inventario y le pasa la referencia al fantasma así como la referencia de si mismo.
Solo el jugador jugable puede tener un fantasma personalizado, todos los demás “enemigos” usan un fantasma genérico.
Solo se guarda los datos cuando se transita o muere.

Control Inventario y Equipamiento:
Controla toda la lógica del inventario de la interfaz de usuario.

Revisando esto veo varios problemas al replicar en multijugador, porque de manera normal en modo single player funciona al 100%,
De manera practica muchas cosas se deben ejecutar en secuencia y se deben pasar de estados de Servidor, Multicast y Notify.
Encontrar el punto justo parece ser una prueba y error a ver con cual configuración funciona bien. Aquí voy a replantear esta mecánica, teniendo en cuenta que transitar es obligaría.

Jugador:
Toda la lógica del fantasma (crear habilidades, crear interfaz, referencias que saltan, lógicas que el fantasma tiene) deben ocurrir en el jugador, es decir llamados a crear interfaz y el control de datos.

Control Inventario y Equipamiento:
El control de inventario debe seguir dentro del cuerpo del jugador.
Toda la logica de la interfaz esta bien.
Toda esta lógica debe funcionar únicamente para el cliente al cual se esta mostrando la ventana.

Fantasma:
Creo que no necesito un fantasma.
Si transito o muero el cuerpo queda con sus datos.
El orbe me permitirá ir a otro cuerpo, este tiene unos datos, datos diferentes y son estos los que actualizaran la interfaz.
Si el enemigo esta en pie al ser derrotado debe soltar los items.
Si el enemigo esta caído, solo se puede absorber (lo que también soltara los items.

Fuera del problema de la lógica de intercambiar entre versiones, antes al morir el cuerpo y el fantasma hacían cruces de datos lo que obligaba a tener variables repetidas y con nombres como temporales.

Ejemplo practico:
Jugador (Jugador, vivo, datos lvl 6) al avanzar por una zona se enfrenta a Jugador (Enemigo, vivo, datos lvl 15) y muere pasando a estado Jugador(Enemigo, muerto, datos lvl 6). El jugador ahora poseer al orbe y buscara otro cuerpo, lo encuentra Jugador(Enemigo, Caído, datos lvl 15) al acercarse encuentra el enemigo lvl 15 y a su anterior cuerpo lvl 6, este al detectar un Jugador (jugador revive quedando así Jugador(Enemigo, vivo, datos lvl 6).
El jugador con el nuevo cuerpo debe vencer a los dos, primero al lvl 15 y luego al lvl 6.
Al derrotarlos, estos caen al suelo y pueden ser poseídos o consumido, porque el jugador necesita recuperar el cuerpo que tenia.

Estados:

• Jugador (Jugador, vivo, lvl 6)
  El personaje es el que controla el jugador con todas sus características.
• Jugador (Enemigo, muerto, lvl 6)
  Fue un jugador o es un enemigo que ahora es un enemigo, parece que esta muerto inerte en el piso pero al acercarse un jugador vivo, se activa un estado en el que pasa a ser vivo para enfrentarse al jugador vivo.
• Jugador (Enemigo, Caído, lvl 6)
  Fue un jugador o es un enemigo que ahora es un enemigo, que fue derrotado, permite ser poseído o consumido (al consumir el cuerpo desaparece).
• Jugador (Enemigo, vivo, lvl 6)
  Fue un jugador o es un enemigo que ahora es un enemigo, que tiene estado de vivo y atacara a cualquier jugador con estado jugador.