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