接简单地设想,仔细思考可行性

头脑风暴到底靠不靠谱

首先,确实是希望能上线一个给玩家体验的产品,哪怕自娱自乐。

其次,9-春节有4个月左右的时间,每天最多2小时,时间非常少。

定这么短时间,是出于只想做一个原型的考虑。不过原型下面的冰山是非常巨大,需要仔细考量。

NetworkCode

从开发简单和开发效率来说,理应选择“帧同步”的方式(科学地说是固定频率的指令同步),它的好处了可以简化服务器的开发,仅仅转发即可;客户端开发所见即所得。缺点也是显而易见的:弱网络条件的robust比较差;真的要做到商业级别的严谨程序,需要统计和控制浮点数不确定的情况;AI的逻辑不好放在服务器等等;开发确定性的一切功能:基于定点数的物理、状态机和等等等等

所以个人不是很想用这种方式,本来就是个娱乐的工程,当然是按照自己的喜好high起来,所以还是躺一下C/S状态同步的坑。

那么在NetworkCode方面,需要从无到有搭建哪些东西呢?

服务器代码风格和支持

  • 对于客户端来说,Unity本身遵循Enity-Component的范式。为了逻辑上的统一,服务器逻辑代码自然也期望能通过相应的范式进行
    • 服务器端的反射
    • 服务器端的EC(ECS)系统
    • 客户端的组件导出到服务器的方式
      • pb作为数据格式

可靠UDP

  • 几个通道是必须的
    • 可靠
    • 不可靠保序
    • 不可靠不保序

对应的客户端网络层

基于业务的第三方库接入

  • Physx:物理运算
  • RecastNavigation:导航

BOT的AI

结论

  • 寥寥数语,其实是个大工程

美术

暂时没法估计工作量

客户端GamePlay

由于游戏本身比较简单,可以预估的是

技能系统

三C相关

  • Character
  • Camera
  • Controller

资源管理

结论

  • 也不是个小工程

最终结论

所估计时间不靠谱,解决途径

  • 是否真要使用“帧同步”,降低服务器端开发量
  • 美术部分是否可以找一个队友

你可能感兴趣的:(接简单地设想,仔细思考可行性)