![个人头像照片](https://ucc.alicdn.com/avatar/avatar3.jpg)
暂无个人介绍
今年在公司重构(写)了一个老项目,踩了无数的坑。 中间好几次遇到问题,甚至感觉项目可能要失败了,好在最后终于成功上线了。 虽然被坑的不要不要的,但也从中领悟到了不少东西,在这里记录一下,顺便分享给大家乐呵乐呵。 先简单介绍下项目,一个面向C端用户的服务,主要提供包括动态、评论、圈子、好友、关注、Feed等常见的社区功能,另外还有其他一些个性化的功能。 日活比较高,整个服务QPS上万。高频业务,单个接口QPS上千。单项业务数据量过亿,比如评论。
本文主要介绍已经使用spring-security的项目集成spring-session时的一些问题及解决方案。
hessian方法重载导致报错
单机游戏:瘟疫公司 Plague Inc:Evolved 开发工具:VisualStudio 2017 其他工具:Cheat Engine 6.4 项目目标: 通过修改DNA点数,让瘟疫更快进化,从而赢得游戏。
概述 在MongoDB实例上开启访问权限控制,意味着强制要求用户输入账号密码进行授权认证。在开启了访问权限控制的MongoDB实例上,用户能进行的操作取决于登陆账号的角色(roles)。 MongoDB支持多种授权认证机制。下面将介绍如何使用MongoDB默认的机制开启访问权限控制。
道具系统是游戏的核心系统之一,常见的业务功能包括 “角色背包”, “道具商店”, “怪物掉落” 等,都依赖道具系统。 在实现这些功能之前,首先要解决的问题就是要定义我们的游戏世界中,到底会有哪些道具, 以及这些道具是如何分类的? 这就是我们这期要做的“道具字典“。首先必须要有一个“字典”来说明这个道具是什么,接下来才能有“背包”系统,来表示角色的背包里有些什么道具,数量有多少。
今天项目不忙,想搞一下shardingJDBC分库分表看看,主要想实现以下几点: 舍弃xml配置,使用.yml或者.properties文件+java的方式配置spring。 使用 Druid 作为数据库连接池,同时开启监控界面,并支持监控多数据源。 不依赖 com.dangdang 的 sharding-jdbc-core 包。此包过于古老,最后一次更新在2016年。目测只是封装了一层,意义不大。感觉如果不是dangdang公司内部开发,没必要用这个包。(且本人实测不能和最新的Druid包一起用,insert语句报错)
本章初步实现游戏的核心功能——战斗逻辑。 战斗系统牵涉的范围非常广,比如前期人物的属性、怪物的配置等,都是在为战斗做铺垫。 战斗中,人物可以施放魔法、技能,需要技能系统支持。 战斗胜利后,进行经验、掉落结算。又需要背包、装备系统支持。装备系统又需要随机词缀附魔系统。 可以说是本游戏最硬核的系统。 因为目前技能、背包、装备系统都还没有实现。我们先初步设计实现一个简易战斗逻辑。 战斗动作仅包括普通攻击,有可能产生未命中、闪避和暴击。
上一节添加了websocket组件,实现了前后端通信。后面我们只需要根据游戏的业务逻辑,逐步实现各种功能即可。 另外,在实现具体业务逻辑时,发现上一章设计的消息对象有些不合理,由于粒度过粗,导致可以复用的部分很少,且这里的通信模型并不是一个请求对应一个响应的模式。比如:玩家a从地图A移动到地图B。此时,a发送移动请求。服务器返回B地图的信息和在线列表给A。同时还要发送最新的在线列表给地图B的其他玩家b,c,d....这里其他玩家并没有发送请求,但收到了响应消息。因此,将消息类型重构成由客户端发出的消息和由服务端发出的消息两类,分别以"3000"和"6000"开头。
前两张,我们已经实现了登陆界面和游戏的主界面。不过游戏主界面的数据都是在前端写死的文本,本章我们给game模块添加websocket组件,实现前后端通信,这样,前端的数据就可以从后端动态获取到了。
本章主要实现注册登陆功能和游戏的主界面。有了游戏的界面,大家能有更直观的认识。 本章我们主要开发的是idlewow-game模块,其实就是游戏的客户端展示层。因为是放置游戏,为了方便,主要使用spring-mvc来开发,整个游戏形式是类似web端的文字mud游戏,会稍带一些图形图片。当然,游戏的客户端可以是多种多样的,也可以使用U3D开发成移动端或者C++/flash/silver light,开发成PC端、网页端、微端等等形式,但需要更多的美术资源。
前面实现RMS系统时,我们让其直接访问底层数据库。后面我们在idlewow-game模块实现游戏逻辑时,将不再直接访问底层数据,而是通过hessian服务暴露接口给表现层。 本章,我们先把hessian服务搭好,并做一个简单的测试,这里以用户注册接口为例。 先简单介绍下,实现hessian接口,只需要在facade模块暴露接口,然后在core模块实现接口,最后在hessain模块配置好接口路由,将其启动即可。
前面做了地图怪物的添加,删除,查询等功能。但添加怪物的时候,需要选择怪物所在地图。前几张的源代码中,我忘了把这部分改回去,所以如果想要成功添加,需要自己改一下html界面,手动填写怪物所在地图的ID。然而,我们配置的时候,地图ID并不是固定的,而是数据库自增的。所以这里最好做成一个弹窗,点击后弹出一个地图列表,让我们手动选择怪物所在地图。 本章我们就实现这样一个弹窗控件,实现对地图的选择。后面如果有选择怪物,选择装备等需求,都可照猫画虎。
前几张,我们主要实现了升级经验、人物等级属性、地图、地图怪物,这四种配置的增删查改以及Excel导入功能。我们主要以地图怪物为例,因此在文章末尾提供的源代码中只实现了地图怪物这部分的逻辑功能。 如果你照猫画虎,把4种配置功能的逻辑全部实现的话,就会发现,增删查改的代码基本相同,除了SQL语句和模型对象不同,其他地方变化不大。 本章我们利用泛型模板,对整个系统就行重构。在重构结束后,你就会发现写代码简直就是特喵的艺术!
前面几章实现了在RMS系统中进行数据的增删查改以及通过Excel批量导入。但仍有遗留的问题,比如在新增或编辑时,怪物的生命值、护甲等数据我们可以输入负值,这种数据是不合理且没有意义的。本章我们就实现服务端对参数的校验。
前面我们已经实现了在后台管理系统中,对配置数据的增删查改。但每次添加只能添加一条数据,实际生产中,大量数据通过手工一条一条添加不太现实。本章我们就实现通过Excel导入配置数据的功能。这里我们还是以地图数据为例,其他配置项可参照此例。
上一章,我们初步实现了后台管理系统的增删查改功能。然而还有很多功能不完善。这一章,我们先把系统日志搭建起来,不管是生产问题排查,还是方便开发调试,日志都是必不可少的核心功能。所谓切面日志,比如说,我们想把每个方法的入参都记录日志,那需要在每个方法里都写一行记录参数的语句,非常繁琐。所以需要提取出切面“方法执行前”,“方法执行后”等等,然后在这个切面里进行编程,记录入参的语句只需要写一次。
上一章我们将RMS后台管理系统搭建完毕,本章我们就在这个系统上实现录入游戏配置的功能。目前我们需要配置四项,每个等级的人物属性,每个等级的升级经验,游戏地图,地图中的怪物。下面我们以游戏地图配置为例子,实现对它的增删查改功能。
上一章已经把整体的代码框架搭建完毕。然而整个游戏的功能非常的多,这就要求我们必须思路清晰,把所有功能依次分解开,逐步实现。
上一篇,我们讲解了游戏的大概背景,知道了要做什么内容。现在已经可以开始搭建游戏的代码框架。
想要做一款成功的游戏,离不开优秀的策划,设计,玩法,美术,等等等等。这其中需要学习的东西太多。然而多想无益,这些东西越学越多,只有先尽快做出成品,然后不断迭代,才能更加深入了了解。因此,这里我们直接参考已有的成功案例,并加入一些我们自己的理解,适当改良。
现在呆的公司使用的数据库几乎都是MySQL。编程方式DatabaseFirst。即先写数据库设计,表设计按照规范好的文档写进EXCEL里,然后用公司的宏,生成建表脚本和实体类文件。 之前就见识过T4模板生成SQL实体类文件,但还没自己实践过,这次正好实现一下生成MySQL的实体类。
一个星期前,也就是3月20日,微软发布了Asp.Net Identity 2.0 RTM。功能更加强大,也更加稳定。Identity这个东西现在版本还比较低,每次发布新版本都会有较多改动。
Agile Is Dead (Long Live Agility) ( Agile已死,Agility长存)
最近做一个Web平台系统,系统包含3个角色,“管理员, 企业用户, 评审专家”, 分别有不同的功能。一直以来都是使用微软封装好的Microsoft.AspNet.Identity.dll程序集来进行身份验证和角色控制。
一般写完代码时,我们通常会启动调试运行一下看看是否正确,启动运行的方式无非是F5-- Start Debugging 或 Ctrl+F5-- Start Withour Debugging(注:不同版本或系统环境不同时,快捷键或有所变化),如下图1。不用说大家都能感觉到,使用Ctrl+F5调试时程序从启动到运行通常比使用F5快得多。使用Ctrl+F5时通常是想快速运行一遍,以便检查程序运行的结果是否符合预期。使用F5时通常是想查看代码内部的运行情况,以便检查到底是哪一步出了问题,或者所有参数是否都正确。
TDD(Test-Driven Development) 测试驱动开发是敏捷开发中的一项核心实践和技术,也是一种设计方法论。TDD的原理是在开发功能代码之前,先编写单元测试用例代码,测试代码确定需要编写什么产品代码。单元测试是最基本的测试步骤。位于整个产品开发流程V模型的最底部。