作者存档: 朱坤乾 - 第6页

游戏可能用到的一些第三方工具

1、腾讯开源的行为树组件  http://tencentopen.github.io/behaviac/

1)需要找下 饥荒 源码中的行为树lua代码组件

2、unity中的聊天图文混排插件 emoji_extension 、hypertext

3、游戏开发好网站:

http://aigamedev.com/premium/interview/dont-starve/

 

脚本手动可执行,但crontab执行失败

运维同事遇到的问题。

开始感觉很奇怪,脚本正确,手动可以执行正确。但是在crontab中执行就不正确。

查到后来发现crontab中的PATH变量只有最基础的:PATH:/usr/bin:/bin

手动输出下PATH:

[root@GiangMa_Login2_Payment router-log]# echo $PATH

/data/service/jdk1.8.0_45/bin:/usr/java/jdk1.7.0_80//bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/mysql-5.5.44/bin:/home/monitor/bin

好了,原因找到了,在脚本中直接export PATH=$PATH:/data/service/jdk1.8.0_45/bin:/usr/java/jdk1.7.0_80//bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/mysql-5.5.44/bin:/home/monitor/bin

问题顺利解决掉。

 

 

sublime text3 开发unity

找到几篇文章,学习如何配置sublime开发unity。

1、http://blog.zephyr-ware.com/unity-and-sublime/

2、http://www.radjor.com/blog/p/65

实测OK,也挺好用。

convert

1、关闭alpha通道:

convert source.png -alpha off dest.png

2、生成遮罩图:

convert moon.png  -alpha extract    alpha_extract.png

 

测试:

1、原始, 195.997M
2、一个png转为两个png,其中一个大图未选择压缩,max size4096。 198.270M
3、一个png转为两个png,选择压缩,max size4096。 194.509M
4、一个png转为两个png,选择压缩,max size修改为2048。 没有任何变化,连生成的大小都是相同的。
5、两个png使用pngquant压缩后再试。max size 2048。   194.522M 晕,竟然还变大了。
6、两个jpg。使用tinyjpg压缩。我CAAAAAAAAAAAAAO,竟然是201.184,竟然还变大了。(发现,自动选择的是true color,没有选择compress)
7、两个jpg。使用tinyjpg压缩。都选择上compress。194.798M。

最好的方式应该是不压缩的png选择compress。估计unity内部自己也有优化。



pngquant压缩后大小和tinypng压缩后大小差不多。
tinyjpg也很有用。压缩比也很高。

安装perforce

之前了解过,开发游戏项目,客户端使用svn,git管理并不合适,因为图形资源过多,而他们对二进制文件管理比较差,国外项目组用的比较多的是perforce,这里记录下创建perforce服务器的过程,以后如果有需要可以翻出来查看。

1、添加repo源:

安装pubkey:

sudo rpm --import http://package.perforce.com/perforce.pubkey

编辑: /etc/yum.repo.d/perforce.repo

[perforce]
name=Perforce
baseurl=http://package.perforce.com/yum/rhel/6/x86_64
enabled=1
gpgcheck=1

2、yum search perforce,可以看到所有相关的安装包。

安装服务端:

yum install perforce-server

3、运行p4d服务器端

p4d

如果不指定-r参数,则默认p4的根目录为执行命令的目录。

4、第一个连接的用户为superuser,我们修改默认用户的密码

1) 使用 p4 -p 127.0.0.1:1666 protect,第一次连进去后会默认生成一个权限配置文件。

2) 退出后,使用 p4 -p 127.0.0.1:1666 passwd 修改当前superuser的密码

5、p4默认用户在第一次连接时会自动创建,我们设置禁止自动创建用户

6、禁止自动创建用户后,使用以下方式创建用户及设置用户密码(别忘记了先使用p4 login进行登陆,因为上一步修改了当前用户的密码)

1) p4 -p 127.0.0.1:1666 user -f username

2) p4 -p 127.0.0.1:1666 passwd username

7、设置服务器的安全等级:

这里至少要修改为安全级别为2(或更高)

8、给用户分配权限。这里使用权限组进行管理。

使用命令:p4 -p 127.0.0.1:1666 protect,修改权限分配。

9、将用户添加至用户组:

使用命令:p4 -p 127.0.0.1:1666 group groupname,修改User那一行。

10、创建p4client,注:client与workspace是同一概念。

这里特别注意是创建的是view,指定了自己本地的工作目录与p4 server上目录的对应关系。如果写错误或权限不足,会有log提示。我在这里卡了半天时间。

 

 

 

记今天域名和GWF的问题

2015年8月31日晚上8点整,GM反馈有海外玩家无法登陆游戏了。

最终排查后的结果:

域名被GWF给墙了 -.-!!

客户端中只使用了域名取一个配置文件,配置文件中存有各个服务器的真实IP之类的数据。

这个域名无法访问后,直接导致客户端在第一步直接卡掉进不去。

暂时的临时解决方法是使用dns智能解析,将海外用户dns解析至一台海外服务器上,暂时避免掉这个问题,但不保证100%解决所有海外用户的问题,因为dns智能解析也会误判一些用户。

这里想了一下以后的对策:

1、客户端首先应该使用ip进行获得,ip比域名少了解析的一步,要快。

2、如果IP读取失败,则使用域名再进行访问,这样可以避免掉如果IP出现问题后,玩家无法正常玩游戏。

3、如果有条件,在第一步时可以准备两个IP,基本一个IP备用。最多2个IP一个域名基本上能100%的解决掉所有问题。

后记:2015.09.02 突然想起来:可以直接使用一个主IP,一个备用IP,还有域名,三个连接同时去访问,最早返回的并且成功的数据取过来用。这样也可以实现起来更简单一些,而且比上面串行的被动等超时,要好很多。唯一需要确认的是:手机是否支持同时发出多条http请求。

springloaded开发过程中节省大量时间

之前开发中如果要修改代码,不需要重启直接生效,需要在eclipse中的debug模式下。

但是依旧受到很多限制,不能增加/删除/修改方法和属性等。

今天上spring.io,又看到了springloaded,感觉这东西经过一年应该很完善了,试了一下,惊为神器啊。

如下图:springloaded包放在工程中。

然后配置环境:

在debug环境加,方法可以随意添加,新添加的方法中设置断点也不会出问题,和原来增加一个方法就要重启一遍相比,太强大了。

记一次redis数据修复

运维同学一不小心将redis数据清空了。

redis中大部分数据都不重要,只有一个排行榜数据,需要按排行榜名次发放奖励。

记下这次修复的方案:

grep 限时 moon30001-gold_2015-08-21.log | awk -F ' ' '{print $3}' | awk -F '(' '{print $1}' | sort | uniq -c | sort -n | awk -F ' ' '{print $1*20,$2}'

从log中取出所有分数及角色id.

redis-cli -p 7000 EVAL "local a=redis.call('zscore','shenJiang.score.20150821','506027'); if not a  then return redis.call('zadd','shenJiang.score.20150821','201440149466188','506027') end;return a" 0

使用lua脚本恢复排行榜数据。

关于游戏的登陆

今天有一个玩家提到,每次游戏断线后,再进入都需要重新输入帐号名和密码。非常麻烦。

这里我想到了一个关于玩家体验的问题:

玩家希望是的流畅的玩游戏,包含在开始游戏时,可以快速的进入。

断线后能不退游戏最好。如果实在不行,要走登陆流程,至少也要避免掉玩家输入帐号名和密码。

 

 

如何检测apk的签名是否正确

apk渠道众多,有的渠道会对签名进行二次签名。

这里就可能出现一个隐患,打出来的包可能因为不小心使用了错误的签名,会导致提交时被渠道打回。

针对这种情况我们可以在每次出包后,使用keytool查看一下签名指纹,指纹相同,签名也一定会相同。

可以做成工具来进行自动检查。


Warning: Use of undefined constant XML - assumed 'XML' (this will throw an Error in a future version of PHP) in /opt/wordpress/wp-content/plugins/wp-syntaxhighlighter/wp-syntaxhighlighter.php on line 1048