对于团队大作业分工(服务端)的理解:
这次大作业一经出炉,还是感觉很有意思的,虽然之前老师已经提及会出这么一个大作业来训练我们的能力,但是真的看到作业的出现,还是很惊喜的。 团队作业的分工,我负责服务端这块,下面开始讲讲我的理解过程(心路历程): 一开始被安排写服务端,我一度以为是试玩(先前并没有接触过游戏服务端的书写),后来与队长交流后又以为我的工作是这样的:队友完成的类(英雄,小兵,塔)由我接手,然后写一个main.cpp
把类串起来,最后交由客户端的同学,实现可视化界面的种种。当时在想,那我不就是个写过程的么?那不是很简单么?但是我还是觉得这样理解不可靠(因为没有接触,不能这样主观臆断),于是乎进行了资料搜索,个人觉得下面两篇博客讲得不错,看了之后对于服务端有了比较正确的理解,下面附上学习博客: 1、 2、 服务端,其实核心就是用户体验,在策划将需求告知之后,把后台的进程编码完毕,交由测试方寻找bug。而其解决问题可描述为:1、建立了玩家到服务器,服务器到玩家,服务器到服务器之间的消息连接;2、描述了游戏世界中状态的维护方式。而现在的服务端编码,可以采用脚本自行编码,即脚本会自己把需要的编码跑出来(个人的理解是脚本需要自行编写?)而至于如何提高用户体验(多人同屏、玩家交互),我认为需要多进程的加入。因为只要是游戏,玩家们肯定会有交互的需求(聊天、工会……),而为了使这些需求达到满足,并且较好地解决这些需求,自然需要引入进程。而如何引入多进程(多场景进程+协调进程)?玩家该如何与服务器建立连接?O(1)的进程简洁、环保,但是如何知道玩家当前与哪个进程相连接?O(n)的进程非但不环保,拓展性还差,也不可能是我们的选择。(答案在学习博客2中有提及) 以上就是当我看完学习博客2后的一些理解,之后我便去看了学习博客1.
学习博客1讲的是服务端的架构,学习之后有种感觉:难道我们这次真的要用到这么专业的东西么?然后加上学习博客2所说,看来我们这次的作业可以完成得十分高大上?后来我告诉自己冷静一下,团队作业,游戏,我们是要当成真的游戏项目来写,但是在很多方面的完成必然与真正的游戏相比是降了不少档次的,于是乎我要解决的问题就是——如何在展示周,让我们队伍的游戏跑起来,没有失误地跑起来,并且用户体验还不差。可以说是任重而道远,至于服务端编写语言的采用,决定先采用c++(因为其它语言如果需要学习,要投入时间,而我们团队作业服务端的编码,个人感觉c++完全可以胜任),过程肯定是在队友把类写完之后,像个裁缝缝缝补补把它们串起来,加上团队中讨论出来的逻辑,让这款游戏运作起来。
PS:从没想过这么早会接触到游戏的编程,还是要设计逻辑的服务端,虽然预感到做出来可能不会说多么的高端,但是毕竟也是自己一个一个字母码出来的游戏,还是非常兴奋和期待了。