Engine and Builder

引擎: 可以看作是若干常用的代码的组合. 或者是一些核心模块和API
Builder: 更接近于游戏内容. 比如GameMaker这种. 所以以后可以讲, Builder可以是万能的.
游戏的核心玩法和交互以及整体设计还是值得探查的, 无论是大是小, 都不可缺少, 所以从回报讲,可能投资者更喜欢大制作. 而独立游戏开发者,则喜欢小制作, 但是味道很足.
很多人一直都可能有这个误区, 四处寻找引擎, 但不得不承认即使有了引擎,还欠缺游戏设计制作这门课. 实作GamePlay才 真的是写游戏了.
这阵子在折腾socket, 仿佛又回到了从前, 不过这次用python. 但想想整体的思路还是一样的, 不过这次可以选epoll 因为是在linux上跑, 如果系统的数据量和并发量并不是很大的话, select 也凑活.
只是最后业务层在接收数据包之后开了线程,发送部分是通过 socket event 触发的, 请求者只需要把数据包压入队列.
同步还是异步? 显然必须要异步,不然要给每个连接的client 开线程. 那样的话就无法享受到oS提供的高效率了. 以便可以处理大的并发数量和数据包.  (事实上因为这个服务器比较特殊,不会处理数据库查询之类的请求,所以没有额外的开启工作线程池,一般如果涉及到耗时的逻辑时,需要开启线程池,专门从请求队列中提取请求 处理后返回结果放入发送队列 吞吐能力则要仰仗CPU以及内存甚至是Network )

Read More

写程序其实不是写

此话题适用于持续变化的和多人协作的Project. 是的,从常规的分析角度讲,可以仔细的Review code, 但我要说的不是这些, 只是说某种程度上, 找不同会占据不小的比例的时间. 原因是: 变更才会产生bug. 无论是代码还是数据. 即使过去一直没有出现的bug也不意味着代码是完美的. 当堆积到一定程度之后, 项目中会有很大一部分时间被用来修bug. 就算是用一个新系统去代替老的系统, 也仅仅是掩盖了一些问题, 当然可以理解成不断提高. 但过了一段时间后, 肯定还会有一些问题被发现. 所以,除了找不同以外, 还有一部分时间就是用来做标记, 以便能在未来某个时间很清晰的定位到某个模块. 这也是很必要的.

不赞同的使用 try: 尤其是try之后 不提示任何信息. 不赞同 只处理 if 不处理 else 没准哪一天, else 的分支就发生了.
如何避免产生新的bug 又可以添加更多的新功能, 这真是个经常遇到的问题. 如果你觉得有些发愁, 那其实是个好事, 最起码你会有意识的去思考,最终某个时间点,你会处理的比较好。遗憾的是,很多人都不会考虑太多。到处充满了hard code
移除一些太常见到的重复代码,把他们变成函数, 有一天你会体会到只修改一行代码, 就完成了一个很重要的功能的美妙感觉.
人无意识的会陷入一宗怪圈, 我理解是人的一种缺陷, 就如同 洋 = 三点水 + 羊 件 = 牛? 尤其是程序员每天必然压力都会比较大, 所以需要一些科学的方法来规避, 比如流程图, 比如逻辑组合

Read More