oops framework + tsrpc 全栈解决方案

oops framework + tsrpc 全栈解决方案

此产品实现了MOBA类游戏网络层基础功能,可用于二次开发扩展协议实现自定义逻辑或学习全栈游戏开发。

产品前后端全采用TypeScript语言实现,同时业务代码使用同一套ECS框架设计,前后端代码风格接近,便于理解学习。

前端框架采用 oops framework 做为业务框架。

后端框架采用 tsrpc 框架,使用这套框架前后端通讯协议就不需要在学习其它中间协议语言,全自动工具生成协议代码,底层二进制传输数据,可把精力关注到游戏业务逻辑设计上,提高开发效率。(感谢 tsrpc 作者提供优秀的技术资源)

DEMO 体验地址传送门

产品价值

  • 有一套成形的解决方案提高学习效率
  • 在框架的支持下,学习前后端开发更容易
  • 学习如何让代码更容易复用、扩展、维护、易读
  • 添加自定义玩法,直接可商用项目开发

功能介绍

  • 玩法功能
    • 创建房间
    • 随机匹配加入一个房间
    • 获取当前在线房间列表,可加入个人数未满的房间
    • 玩家加入房间
    • 玩家退出房间
    • 摇杆控制角色移动同步
    • 触摸地图目标点控制移动同步
    • 弱网移动同步策略
    • 基础战斗同步逻辑
  • 客户端功能模块
    • 游戏公共模块
    • 游戏初始化模块
    • 摄像机管理模块
      • 轨道摄影机
      • PC平台鼠标滚轮调整镜头距离
    • 地图管理模块
    • 房间管理模块
    • 角色管理模块
      • MOBA类攻击前摇后摇,实现走A效果,手机上遥感方便操作出来
      • 移动、攻击、死亡、复活
    • 技能系统模块
      • 弓箭类技能
  • 服务端功能模块
    • 支持 HTTPS、WSS
    • 匹配服务器
      • 服务器初始化
      • 房间服务器加入并进入工作状态
      • 获取在线的游戏房间列表
      • 创建一个房间
        • 在人数所少房间服务器创建
      • 匹配一个房间,如果在超时前没匹配到则创建一个新房间进入
    • 房间服务器
      • 服务管理模块
        • 服务器初始化
        • 申请加入匹配服务器,等待授权进入工作状态
        • 登录权限验证
        • 断线逻辑
          • 玩家断线自动离开房间
          • 与匹配服务器断线,无限尝试连接匹配服务器直到恢复正常后继续提供服务
        • 空房回收策略
        • 聊天业务处理
        • 加入房间业务处理
        • 离开房间业务处理
      • 房间管理模块
        • 房间数据状态管理
        • 房间内玩家状态广播
      • 玩家管理模块
        • 玩家数据状态管理
        • 玩家玩法协议代码分离设计
        • 玩家移动状态同步
        • 玩家移动广播
        • 玩家攻击广播
        • 玩家离开房间广播

学习交流 QQ 群:798575969 与扫码加入

9赞

https://store.cocos.com/app/detail/3766
你这个和人家这个有啥区别,我之前已经买了这个

区别应该就是用了另外一个前端框架 多实现了一些功能

区别是产品前后端全采用TypeScript语言实现,同时业务代码使用同一套ECS框架设计,前后端代码风格接近,便于理解学习。

应该是前后端业务设计层面的不同,前端框架的不同,功能多一点。

mmark

mark一下.
看看.

首先tsrpc作者的demo做得很好,我用了他的开源服务器框架。上层逻辑用自己的风格实现了一套房间类游戏的demo。我设计这套DEMO有以下二个考虑:

第一个目标是希望两套技术框架结合时,代码风格接近,希望降低全栈开发难度,有一套标准使初次接触的同学理解起来更新容易。这样工作中更容易推广给其它同学来提高开发效率。

第二个目标是用oops-framework出一套网络游戏DEMO,便于使用的同学理解框架设计层面的内容。

Demo的设计时考虑的重点
1、客户端的同步流畅度表现上有我自己的理解与优化
2、对于代码易读性、扩展性、复用性的设计方面考虑比较多,希望能快速复用到项目中。

希望能解答你的疑问。

1赞

https://store.cocos.com/app/detail/3766
https://store.cocos.com/app/detail/3218
你是这两个demo融合到了一起,确实买你这个更划算。

啥都好,就是这个后端框架选择动态语言性能拉胯,

每个工具存在都有他存在的意义,脚本语言开发有他性能方面的弱势,也有他开发效率高的优势。

如果我们的项目并没有很高的并发性能要求,其实用更低成本的方式去做自己的项目,先验证项目的商业价值,才是最重要的。

早些年网易开源的pomelo也是node.js做的,用到游戏项目中其实也没太大问题。毕竟不是所有游戏都能做到几万在线的,就算在线多了不还有分布式扩容去解决吗。tsrpc作者鹅厂出来的,必然验证过高并发的项目。所以还是看这套框架的优点。像现在中小型游戏开发商我认为还是很适合的。

Mark!!!

鹅厂。。。:sweat:,我觉得鹅厂技术不咋地。。啊哈哈

1赞

爆赞~~

性能,性能肯定比不上 C++,但是能加机器解决的问题就是不是问题。

说不定综合成本,Node 反而会更低一些。毕竟,人工比机器贵多了~~

Issues · heroiclabs/nakama (github.com)
拿走不谢,外国维护项目,go后端高并发,碾压鹅肠吧。。。
先进的游戏服务器,可以使用 Go、TypeScript/JavaScript 和 Lua 进行完全扩展,以创建服务器权威游戏逻辑和高级功能,并在需要时更好地控制权限、存储引擎和直接数据库访问。
image

而tsrpc的代码量如下图,相信对比之下,哪个功能更加完善和性能高,一览无余,简直就是按在地上摩擦:

确实全面,做得早就先发优势。国内的技术还需要时间发展,优势就是沟通方便一点。学习成本也是个要考虑的点。

Unreal 也很完善,C++ 性能也更高,但 Cocos 也有不可替代之处。

TSRPC 有 2 点经过验证:

  1. 纯前端,后端小白,1 天上手,2 周转型全栈(学个 mongodb 就能应付大多数非极限性能需求的场景)
  2. 通过合理的分布式架构,简单加机器也能撑千万 DAU、数十万 QPS 没问题

成本,是个综合账,1 个人力可能比 10 台服务器更贵。
性能不是技术选型唯一的考量,否则 PHP 早就消失了。

言之有理,存在即合理。
cocos主要是支持导出h5,而其他的unity和unreal几乎等于不支持,国内恰好小游戏这块比较好做,所以cocos虽然性能不高,但是由于支持其他引擎的短板,所以国内比较吃香

大佬 ,阅读了你关于在线帧同步和状态同步的文章.很棒. 感谢分享.

我连小白都不如~ :3:

1 天上手,2 周转型全栈。啊这,我给大家拖后腿了