感觉游戏后端开发要比 web 后端开发难上不少

SignalR 考虑一下

3 我感觉这部分应该是客户端做的

其实这些服务端引擎都帮你封好了，GamePlay 只需要考虑属性同步、RPC 调用、持久化数据就好了。。。

做游戏开发还是游戏引擎开发，区别大得很。

写框架和写业务逻辑 难度差很多

本机内存上……那也得分客户端和服务端开发吧……

看时期，预研，研发期的游戏比互联网难太多了，等上线之后，玩法框架一稳定，后端就挺闲了，量产大多都是客户端美术的事情

有没有可能是你做的 web 业务太简单了。。。。

@lsk569937453 web 方面 传统 crm 业务做过 ，互联网需求也做过 写过实时性较高的股票报价业务，聊天室、也做过类似竞猜游戏的偏复杂的业务，微服务、主流的数据库和中间间都用过，感觉还算是比较全面吧

有没有可能是你的 web 后端太简单了。。。。


1.协议还分简单和容易吗？再说 web 协议不止 http/websocket 。
redis 协议(访问 redis)，mysql 协议(访问 mysql 会用到)，grpc 协议( http+json 性能不够了怎么办？只有加机器这一个选择吗？)无非是你现在用的都是在巨人的肩膀上做的，很多人帮你封装好了 http 协议。游戏里面的协议也是封装好的，你不会以为游戏里直接读 tcp 的流，来拆分结构把。

2.性能方面。相比 web 后端，接口的速度优化大部分只是从业务逻辑上下手，而游戏后端却要通信协议方面和业务逻辑优化兼顾。

上面我已经说了一部分，web 性能不够的时候也可以换 grpc 协议，你不用不代表别人都不用。其次，如果对性能优化感兴趣，可以读一读 https://github.com/donnemartin/system-design-primer 系统设计。看一下从数据流到数据库这一条链路上究竟有多少可以优化的地方。

3.业务复杂度。游戏既要处理复杂业务的同时还要追求性能，为了避免 io 阻塞和网络容差性，往往都是在本机内存上处理数据
那么我这里有几个现成的问题苦恼我好久了,希望楼主能给我点拨一下。
a.50 亿的单表数据。现在分成 100 个分表，如何快速的迁移数据(非停机迁移)。
b.我现在对数据库的读写比例是 8:2,每秒有 1W 的数据写入数据库，我该使用何种数据库类型。
c.现在各个公司都在走双中心的架构，各个组件(mysql/hbase/redis/postgresql)如何实现双中心架构？单个中心内的架构又如何部署？
d.你现在公司的网站的访问流量突然增大了 1000 倍，你该如何重新设计你的接口，让你的网站能抗住这么大的流量？该不会是加机器吧。

4.数据安全性。
建议楼主用爬虫去爬一下美团/携程的酒店和淘宝指定商品的列表，去感受一下互联网最前沿的反爬技术。如果楼主能开发一个稳定爬虫，我愿付费购买。爬美团/携程 APP 的酒店价格，连续运行 30 天就行，一个月我愿意付 3W(每天抓 1W 家酒店价格)。一个月 3W ，楼主如果感觉这钱好赚就可以开动起来了。

5.我实在想不通不同领域的两个方向还能比较的。文无第一，武无第二啊。
------------- 一个即将毕业的 web 老码农

两边都做过，都是做业务的情况下，大差不差。你说的这几点，WEB 服务不需要考虑的吗？

web 前端和游戏客户端没人讨论下？

对后端来说，只有针对方向上些许不同，深广难度大差不差，不过，游戏的客户端就是我们常说的前端水就深了，各种渲染呀图像优化就很麻烦了

@zuosiruan 游戏客户端，如果是 UI 部分，那么和 web 前端差不多。只是游戏客户端的 UI 没有 web 前端那么重的历史包袱，但大部分在线游戏的功能就是堆 UI ，改 UI ，所以工作量也不小。
游戏客户端涉及图形和渲染，那么水就比较深了。

是你的业务面向高级抽象，才会有这种错觉。

@zuosiruan 我来。我主业 web 开发，业余写游戏。这么说吧。。我的感受是：没得比。。写游戏因为工作量太大，导致难度瞬间升高

4399 游戏呢

如果我说出页游两个字，你应该能顿悟。

我转到游戏服务端两年多了， 游戏服务端需要的技能偏向不太一样， 正经游戏服务端开发的话对网络协议都需要比较了解。编程思想都是通用的，然后就是各种网游类型对开发要求也不一定。极端一点的例子，fps 网游实际游戏数据只有 udp 。

确实有一定难度，但是如果设计好模型，也会简单一些
简单说，web 下 rpc 维护的是一份全量数据；游戏更多是增量以及状态变化