`
17studio
  • 浏览: 193602 次
  • 性别: Icon_minigender_1
  • 来自: 广州
社区版块
存档分类
最新评论
文章列表
使用cocos2dx,首先是从action入手,表示各种绑定对象的执行。 action+对象,组成了类似script + object的结构,action需要和object绑定在一起 1.基本动作InstantAction   放置 – Place   隐藏 – Hide   显示 – Show   可见切换 – ToggleVisibility 2.延时动作   移动到 – CCMoveTo   移动– CCMoveBy   跳跃到 – CCJumpTo   跳跃 – CCJumpBy     贝塞尔 – CCBezierBy    放大到 – CCScaleTo   设置放大倍数 ...
首先定义webgame项目: 1、webgame 2、有核心玩法和数值成长体系 3、围绕核心玩法有若干子系统 4、运营工具支持 整理webgame项目开发相关阶段如下: 1、游戏引擎阶段:参考开发用时,一个月 2、核心玩法开发:参考开发用时,两个月 3、相关子系统开发:参考开发用时,两个月 4、程序调试及数据测试:参考开发用时,一个月 5、细节调整完善:参考开发用时,一个月 6、后台制作及上线准备:参考开发用时,一个月 上述开发效率建立在团队及技术积累成熟的前提下,如果团队成员搭配合理,开发阶段可以并行如下: 1、游戏引擎开发及整体设计(1周起) 2、核心玩法和相关子系统开发(两个月) 3 ...
1. 制作人 + 执行    成本最低,对制作人要求高 2. 主策/主程/主美 + 执行    成本较低,需要有较为民主的气氛,且至少有一人具备项目组织能力 3. 制作人 + 主策/主程/主美 + 执行    成本偏高,对制作人要求可以降低 从上面的几种模式来看,提高技能,改善团队的氛围,可以降低成本。 但是业界较为成功的游戏,大都是1/2这两种模式研发出来的,可见游戏依赖核心人物的水平。
我认为良好的代码设计,在于以下几个标准: 1、能够满足需求的实现 (这个是基本,连需求都无法满足,就谈不上其他了) 2、简单,越精简越好,越直观越好,其他人接手的学习曲线越低越好 3、扩展业务功能方便容易 4、具有业务的弹性,可以适应需求的变化(这一点往往容易和第二点产生冲突) 5、稳健可靠,利于做性能的优化和错误检查 看过许多代码设计往往做不到第二点,或者把3和4优先于第二点,导致了项目达到一定复杂度后的难以维护,加速了项目代码的灭亡,这是需要警惕的!
如果让我给团队成员一个层次,我会按以下情况进行区分: 90. 框架开发能力       -- 底层研发,根据公司战略方向提供底层技术 80. 设计能力             -- 应对业务中各种需求,做出正确合理的设计 70. 业务开发能力       -- 能够在开发框架的基础上,根据业务需求完成功能开发 60. 完成基本工作       -- 在指导下完成安排的工作 最近人事浮动,我觉得,深层次的原因,我认为是在管理上,没能区分好具有设计能力和业务开发能力的人员,并给予合理对待。 公司因为发展的压力,常常希望员工付出过倍的努力,如果管理人员本身又缺乏技术识别能力的话,那么就会导致懂得 ...
从网上找到的几个js engine, 记录如下: 1. silbygamelib 一个老牌的引擎,已经停止更新了http://www.sean.co.uk/a/webdesign/javascript_gamelib/javascript_gamelib.shtm 2. GMP http://freshmeat.net/projects/gmp-javascript-game-engine 3. http://jsge.athlabs.com/ 4. http://www.effectgames.com/effect/ 看起来像是面向商业的 5. http://www.renderengine ...
一直关注的comet已经陆续出现了很多解决方案,自己也收集了一些资料,对其中的一些问题进行了思考,特做一个简单的总结。 1、comet的价值 早期的comet,仅仅考虑的是解决客户端不断轮询带来的压力问题,逐渐发展到今天, ...
前提: 1、hibernate对象(即本身是需要可以存储的) 2、接口实现需要状态 方法总结如下: 1、对原有的对象扩展字段 2、对扩展属性建立新表,把hibernate对象和新表做关联,hibernate对象负责管理属性 3、对扩展属性建立新表,使 ...
简化交互关系:命令模式、观察者模式 增强交互的信息包含量:解释器模式 管理交互的参与对象:责任链、mediator 管理交互前后的状态:memo 管理交互时的处理方法:state、strategy
把以前学习分布式数据库时候的一点理论通俗化一下。 以下三者不可兼得: 1、可用性 2、可分布 3、数据一致 用在系统的设计里面,就是: 1、可扩展 2、可分布 3、状态同步(可交互) 三者不可兼得,只能考虑两者 所以大都分布方案的设计,都是把计算和数据分离,做到: 1、计算      a、可扩展      b、可分布 2、数据      a、可交互      b、可扩展
创建型模式常用的是factory、builder和prototype,用于抽象和简化 singleton模式用于管理有限资源(有限资源常常需要解决并发问题,实现时需要注意)
从简化角度出发: 1. 减少对象数目(adaptor) 2. 简化对象关系(facade) <- 这可以和mediator比较一下 从不破坏原有代码基础上,增加功能: 1. bridge 2. decorator 3. proxy 类的组织模式: 1. composite 2. flyweight
C++开发,VC2005 SP1+WINXP环境, OGRE+NXOGRE(物理引擎)+Raknet(网络引擎)+3DSMAX+OFUSION(场景建模)+FMOD(声音引擎)
$! 最近一次的错误信息 $@ 错误产生的位置 $_ gets最近读的字符串 $. 解释器最近读的行数(line number) $& 最近一次与正则表达式匹配的字符串 $~ 作为子表达式组的最近一次匹配 $n 最近匹配的第n个子表达式(和$~[n]一样) $= 是否区别大小写的标志 $/ 输入记录分隔符 $\ 输出记录分隔符 $0 Ruby脚本的文件名 $* 命令行参数 $$ 解释器进程ID $? 最近一次执行的子进程退出状态
一种是顺其自然,制定游戏规则,利用人的本性来推动组织自我发展 一种是精细化管理,通过命令的制定与执行,强调执行效率 各有利弊,在不同场合选择不同的方法,下面是精细化管理的一些技巧: 为了让一个整体更好协作(精细化科学管理),需要建立: 1. 更好的监督 (指标) 2. 效率工资   (高薪养廉) 3. 延期支付   (奖金、期权)
Global site tag (gtag.js) - Google Analytics