但是你要考虑一下自身的条件:
2.主机配置跟得上不,如果是古董级的,那就免了。毕竟外部连接一上来,CPU和内存都处理不过来了。卡都卡死。
3.网络稳定吗?一般ADSL的就不好搭建服务器,速度和带宽都跟不上,建议起码是LAN的用户。
4.一旦用于服务器以后,电脑主机就要专门用于游戏运行,而无法他用。管理员在服务器上打牌,打开网页什么的,都造成卡机的情况,会让游戏很不顺畅。
5.技术方面能解决吗?例如IP如何固定,端口的安全设置,服务器的搭建,游戏服务器端的安装和修改之类的。
如果解决不了以上5个方面的问题,建议还是不要考虑了。
首先要知道游戏类型是什么,然后知道承载人数是多少,以及开发周期多少。需要根据这些来决定游戏架构和技术选型。
对于gameplay来说,本身就是个大循环,一定频率进行tick,接收来客户端或者其他服务器的rpc,处理逻辑,然后数据落地以及发送数据给客户端或者其他服务器,一般gameplay来说在同一个进程里都是同步的方式去编写,同步的实现大多数是单线程的,或者使用coroutine来实现actor这种模式。大部分游戏交互都是比较多,所以不论service和service之间的交互还是玩家和玩家之间的交互,如果考虑多线程的同步的问题,会非常复杂以及很容易做错,所以一个service内同一个时刻都是在一个线程中执行的。
针对mmo或者一些竞技类游戏往往有场景管理的概念,就是游戏AOI,比如一个玩家移动,需要告诉周围所有的玩家,复杂度在n*n,如果减少这个n,就有了AOI算法,比如九宫格,十字链表等,如果刚开服的时候很多人挤到一个主城中,就算采用九宫格和十字链表等AOI等算法,往往同屏内玩家数量还是很大,客户端渲染的单位数量比服务器少一个数量级的,所以场景管理这里还可以有个分线的做法,玩家多的时候,不同线不可见,玩家少的时候进行合并。
如果做帧同步一些关键点为表现要和逻辑分离,随机算法和随机种子的一致性,数学库浮点换定点,三角函数采用泰勒展开或者查表法,需要保序的容器,timer不能基于钟表时间而需要帧timer,以及防作弊(一般都是投票法,或者服务器跑个验证端)
现在很多游戏在线更新bug甚至不停服更新慢慢变成一种强需求了,实现这种方式主要使用脚本热更新,热重启+逻辑内存以及ab服切换来实现。
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)