前言

最近在捣鼓Unity的各种小轮子，用来扩展自己的框架吧~

这次介绍一下用于Unity的日志增强系统

功能介绍

这个东西想加入现有的项目非常容易，单个cs文件复制即用，在游戏启动时初始化一次即可。

保存的日志文件位于Application.persistentDataPath路径的/GameLog目录中，以日志文件创建时间命名，方便后期查阅。

当然实现的功能暂时也很简单，基本上只有同步输出到文件， 之后会准备一个工具来实时监控这个日志文件

前言

这个项目差不多5月份就已经没有再更新了，6月初正式从公司离职开始专心做独立游戏了。差不多到现在已经一个月了，工作也慢慢进入了正轨，这两天手头暂时闲下来了，也差不多该把这个系列完结掉了，了却我一桩心愿233

服务端主要游戏逻辑

上次说到主要逻辑是由各个具体的Controller来实现的，这个游戏分为两个Controller：UserController和BattleController。

前者主要负责用户的登陆登出等等，逻辑比较简单，我们主要来看BattleController的逻辑

这个Controller只处理一个协议，就是SFRequestMsgUnitSync同步状态协议，里面包含4个参数，移动方向，鼠标朝向和是否释放了技能。

前言

最近一直在思考某些事情，然后就拖更了一个月233

其实代码也一直在写，游戏的主流程也基本上通了，就是一直懒得写博客。

OK我们今天来介绍下游戏的服务端是怎么实现的。

服务端结构

BounceArena的服务端使用node.js开发，这次用了三个进程，分别处理日志（main.js也是程序入口），socket通信（SFSocketHandler.js）和具体的业务逻辑（SFGameServer.js）。

main.js

main.js为程序入口，我们在server/app目录下执行node ./指令就可以了。

这个进程会启动两个子进程SFSocketHandler.js和SFGameServer.js，这两个进程运行过程中产生的日志会通过node的进程通信机制发送给main.js，然后主进程统一处理这些信息，比如格式化输出，另存到文件等等。

前言

距离上一篇又差不多一周多了，果然写代码要比写博客轻松多了orz

经过了漫长的无聊的准备，这次终于开始正式写游戏逻辑相关的内容了，当然，到目前为止的代码可以直接拿来做任意一个游戏，这也算是个好处吧233

断断续续写了一周的代码，到目前为止已经基本实现了：登陆，加入战斗，同步移动。其中同步移动是重点，之前的坑里就是因为这一点导致爆炸，做不下去了233

前言

这真的是最后一篇有关基础框架的文章了！

写到这里已经第七篇了orz之前的其实还是挺枯燥的，都是些基础方面的东西，并看不到什么有趣的内容。可能是我把事情想的太复杂了吧，所有东西都想做到能力范围内的最好，尤其是这些底层框架层次的东西。

不过这些东西真的很重要，小游戏的话可能不会明显，Unity的一大优势便在于可以快速地产出游戏原型来，我这个项目整了这么久就一个TestView，里面居然只有两个按钮！233

我这些东西也是考虑了许多生产环境中遇到过的问题，不敢说是最优，我也还是在学习嘛XD

嘛，等把网络框架也搭起来，我们就能正式开始写游戏相关的逻辑啦~

前言

UI的框架大致搭好了，虽说还有许多控件还没支持，不过其实都大同小异，以后需要用到新的控件的时候再考虑支持新控件好了。

然而现在有个问题，UGUI原生的控件虽然已经很好用了，不过我们有时候还是会想有更多的功能，举个例子，UI.Button组件并没有保存这个按钮下的Text节点，我们不能方便地修改按钮的文本，当然这个是可以理解的，因为不是所有的按钮都需要文本，很多情况它会作为一个图片按钮出现在游戏中。

不过更多的情况按钮还是有包含一个文本的，为了方便地修改按钮的文本，我们需要对其作出一定扩展。

前言

项目这个东西果然还是做起来才会发现坑，尽量早填上好了

View Prefab

上一篇的vwTest这个UI预设体的根节点vwTest是一个Panel控件，内容是个背景框，这个想了下不太妥，应该改一下，包含具体内容的控件不应该在根节点中，现在把根节点改成透明panel，尺寸为整个View的尺寸。背景框相关的放到根节点下边。

前言

UI在任何游戏里都是个重要的东西，作为一个程序员我们暂时先不考虑如何设计UI才好看，优先还是考虑怎么高效地实现功能。

在很多重度UI的游戏中，UI占的比重经常超过核心玩法，UI变多的时候我们需要用编辑器来设计UI，用代码生成工具来生成相关的代码，之后我们只关心如何实现相关的逻辑就行了，Unity的场景文件完全不用修改，因为所有的UI都是代码控制动态添加移除的。

这里使用MVP的架构来实现，Model为主要以单例形式存在的类，用来存储相关的数据；View为根据UI的Prefab生成出来的代码，人工不修改，纯自动生成；Presenter就是我们需要写代码逻辑的地方了。

前言

本来是想接着写UI相关的东西的，不过上一篇提到了SFUtils这个类，干脆就先介绍下有关于日志方面的封装

目的

这个游戏目前的目标平台是PC和Mac，移动平台有网络同步效果方面的顾虑，之后再考虑。

当然这不是主要问题，主要问题是Unity日志实在是太难用了，直接使用Debug.Log()是最常用的方式，然而这样做只会把日志输出到UnityEditor的Console里，实在是有点难看，唯一的好处是双击某一行可以直接跳转到响应的代码行。不过作为外貌协会成员，还是想办法把这个尽量弄的优雅吧。

想法是统一把info，warning，error这些统一为一种日志，全部记录到文件里，这样的话我们翻之前的日志也比较方便，不会丢失。如果配合实时日志查看器的话（之前还开了个坑，不过最近估计没时间填了orz），就简直完美了~

前言

之前一直在用cocos2d-x用c++写代码嘛，所以为了开发方便自己设计了一套事件系统，现在转到unity用c#了，就很自然地把之前那套东西搬过来用了XD

C#自带的event其实就完全可以用，不过功能略显简陋，Unity自带的EventSystem感觉太复杂了，而且我又不太喜欢去操作editor，所以我还是决定自己造轮子，弄一个最适合自己的事件机制

哦对了，本系列的文章仅为我个人的学习记录，大家可以在评论区指出我的错误和误区，绝对不是什么教程哦，当然还是希望大家可以在这里找到一些有价值的东西