混用Application.LoadLevel 和 PhotonNetwork.LoadLevel

最近这一周从上周五晚上加完班回家夜里都12点了. 又赶紧送孩子去儿童医院  .. 就肺炎住院了.  真是有啥别有病呢.  悲剧的是我周三夜里陪了一夜后. 转天晚上也发烧了..

周四 周五输了两天液. 这病毒咋这么厉害呢..  这倒霉的空气. pm2.5 xxx  没法活了.  住了8天 一个高配 macbook 进去了. 有时候就想啊, 真是又该归零了.  

所以劝各位, 没买的赶紧买, 转化为生产力. 放着那真不叫钱了.  人家同屋的 虽说是农民大哥, 可花起钱来比咱爽快多了。

donews一直没办法登陆. 更新不了了. 耽误了好几篇blog. 

photon cloud 最近的进展:

1. 实现了房间模式与mmo共存. PhotonUnity3d.dll 用 pun带的那份就好了.

2. 另外实现了给Scene的 Object添加 guid的属性, 稍微结合Photon就可以实现手动绑定 photonview ,从而利用photonnetwork进行数据同步了. 好处是: 不需要重新修改关卡设计. 尤其是已经放好了的怪 不是用Prefab摆的 不是用 Spawner 摆的.  photonview 的 observe 属性可以动态指定. 或者做成预置件.

 仔细想想- 这种方法其实是需求驱动的. 目标明确, 实现起来也容易 没什么障碍. 如果所有工作都是如此, 那当然没什么延期之类的了. 但scaleform 显然用不好的话 就会有性能问题.  越底层 越容易出问题. 做底层的通常和悲催的事联系很多.  越是逻辑的层面多的话, 越容易受控制.

 

几个结论:  PhotonNetwork.LoadLevel 不能实现所有房间内客户端加载统一的场景. 需要在 onJoinedRoom 时 各自自己调用. 或者接受 Master 传递的参数后调用. 

我试验过客户端A上加载一个盒子 随机颜色给 Red. B客户端加载后 该盒子颜色不一定是红色的.  想要保持一致,还需要做数据同步. 或者让盒子变成 sceneobject (最后还得自己做属性同步) 

photon没那么智能.  估计也是为了足够灵活. 没有写死。

用不好的话, photon  缓冲的消息量 会把新进来的 client 刷死.   

PUN 是封装的 Photon API的 Unity 的插件. 也是为了最大保持和 Unity 自带的 Network开发的接口保持一致. (但是要从零再去了解这个的话  似乎和直接用 Photon差不多啊) 

姑且按照他的标准模式先来吧. 

核心就是 RPC 交互. 本地远程都调用 RPC  但是只在真正的Master上 执行. 从而保证数据和逻辑的统一.   

 

PhotonNetwork.InstantiateSceneObject 适合后生成的实体的同步. 还能cache.