2012年1月8日
说明一下 monkeyispig.com 是本人自己的blog,发在cppblog只为增加人气 :)所以没有全文转载,转个引子请大家点击一下:
原文地址:
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
写在翻译之前
在遇见Unity3D之前我对物件/组件模型知之甚少,接触了Unity3D之后便对这种模式带来的优势所深深吸引,后来自己项目组也开始渐渐引入这种开发模式,自己也很想对此有所总结有所积累。在自己行文之前很怕自己考虑不够,所以先翻译一篇这方面非常有价值的博文。
本文中作者称【物件】为【实体】,它【Entity】与Unity3D中的【GameObject】几乎是等价的概念。为了保持一致性,我也在翻译时采用此种译法,读者切勿见怪。:)
本文非常值得游戏开发者阅读,也非常值得仍然深信“继承”是银弹的人阅读
posted @
2012-01-08 22:35 Charlie 侯杰 阅读(1727) |
评论 (0) |
编辑 收藏
2010年7月20日
摘要: 新手在刚接触一些实际项目的遗留代码时会觉得很迷茫(比如我)。相信过来人都知道这种感受——代码量大、注释少、难读懂。这只是最肤浅的认识,随着接手任务需要在代码上做添加和修改的时候那就真的是更难以下手了。一方面是对代码不熟悉,另一方面则是代码已经被修修补补得十分混乱了。
阅读全文
posted @
2010-07-20 22:35 Charlie 侯杰 阅读(1874) |
评论 (4) |
编辑 收藏
2010年7月7日
摘要: 场景管理是游戏中非常重要和基础的部分,初次接触场景管理是使用了Ogre中的场景管理器(SceneManager)。其中的场景节点(SceneNode)便是非常好用的一套用于表示场景位置关系的抽象。纵观Ogre的实现,SceneNode是继承与Node类,Node类则主要实现了空间位置关系的操作。
在2D游戏中,同样需要一套犹如SceneNode的场景管理节点,那么如何实现和设计一套用于2D的节点来调整空间关系呢?
阅读全文
posted @
2010-07-07 00:34 Charlie 侯杰 阅读(1481) |
评论 (1) |
编辑 收藏
2010年5月21日
摘要: 蛮喜欢这句话的,当生活中总是充满了各种抱怨的时候,这句话总是让人耳目一新。
当我们抱怨的时候,为什么不动手去改变它呢?有人说太迟了,what's done is done!
反过来思考这个问题,很多事情都已经成了定局才让我们抱怨和后悔,那之前做这些事的时候,或许就没有用正确的方式来做才造成了现在的样子。
阅读全文
posted @
2010-05-21 10:29 Charlie 侯杰 阅读(1908) |
评论 (6) |
编辑 收藏
2009年8月25日
摘要: 游戏主循环是每个游戏的心跳,输送着整个游戏需要的养分。不幸的是没有任何一篇好的文章来指导一个菜鸟游戏程序员如何为自己的程序供养。不过不用担心,因为你刚好不小心看到了这篇,也是唯一一篇给予这个话题足够重视的文章。
由于我身为游戏程序员,我见过许许多多的手机小游戏的代码。这些代码给我展示了五彩缤纷的游戏主循环实现方法。你可能要问:“这么简单的一个小玩意还能做到千奇百怪?” 事实就是这样,我就会在此文中讨论一些主流实现的优缺点,并且给你介绍在我看来最好的输送养分的解决方案。
阅读全文
posted @
2009-08-25 21:59 Charlie 侯杰 阅读(4614) |
评论 (9) |
编辑 收藏
2009年5月13日
问题是这样的,这个“项目”经历了种种变更,目前需求定格在3D动作类游戏上。
在游戏引擎制作的过程中遇见了现在这样的问题:
某从业人员即一位有经验的XNA开发者告诉我们小型游戏利用XNA来做会比较有效率(相对后一种方案)。
不过现在问题出在对.Net,XNA都不是十分熟悉,去使用XNA必然又比较大的学习代价。
后一种方案:使用OGRE+各种游戏引擎中还需要的其他类库来做自己的游戏引擎
相对于.NET C# XNA,C++应该在语言的熟悉程度上更好一些
OGRE也接触了一些,不算熟悉,但是也能了解基本运用
也就是后者可能在整合的方面会遇见一些更实际的问题,但是大体还熟悉
而前者XNA是一个不错的游戏开发框架,但是却需要付出学习代价
后者的问题…… 其实我也只是听同学提到一个很模糊的说法:“在后期会遇见一些麻烦”
这个说法也是前文中的那位从业人员给我同学的说法。
而实际上,我更倾向于的是后面这种解决方案~
因为从自己的知识层面和项目组成员的知识层面上来说,C++还是比C#要熟悉一些
OGRE对于一个基本完全未知的XNA药熟悉一些。
希望有相关开发经验的大大能够来帮忙解决下心中的疑惑!到底是用XNA+.NET还是OGRE+C++
游戏规模是中小型,平台现在由于各种原因限制在Windows上
这两套解决方案到底孰优孰劣?好又好在什么地方,缺点又有一些什么?
实际应用上,会出现很棘手的麻烦么?
我自己也深知在这种解决方案上去徘徊远不如静下心选定一个方案去解决现实世界的问题来得实际。
不过我自己心中有一个“潜选择”,我怕前者真的是一套好的方案却被放弃掉
希望各位大大支招,谢谢了~!
posted @
2009-05-13 14:10 Charlie 侯杰 阅读(2684) |
评论 (21) |
编辑 收藏
2009年3月26日
写了几天代码,怕自己没头没脑一直写下去
还是乖乖的跑去图书馆看书
下面都是一些片段,都是自己觉得有意思的地方,所以还是记下来比较好
TC++PL 15.4.5
Object过于一般,因为它并不对应于应用领域中的任何抽象,还迫使应用程序员去使用一个实现层的抽象。解决这类问题的更好方式是使用容器模板,在其中只保存某一类指针……
TC++PL 15.5
然而,一个指向成员的指针并不像指向一个变量或者指向一个函数的指针,它并不是一个指向一块内存的指针。这种指针更像是一个结构里的偏移量,或者到一个数组里的下标。
这也很好的解释了
typedef (Class::*mem_fun_ptr)(argus..);
的mem_fun_ptr要和一个class的实体结合使用…… 就像把这个 偏移量 施加在这个 结构体 上
mem_fun_ptr mfptr = &Class::one_mem_fun;
Class *p = new Class;
Class instance;
(p->*mfptr)();
TC++PL 18.4.4.1
注释中的 Curring化 正是OwnWaterloo学长正在做的callback_curring ..
f(x,y) 看作 f(x)(y)
TC++PL 17.4.1末尾
std::map::inserat(val)返回std::pair<iterator,bool>
如果val被实际插入(可能由于已经存在的key不能插入)那么bool为true。迭代器引用的是map中的一个元素,
它保存着val的关键吗val.first。
TC++PL 17.4.2
关于multimap中查找某key得到的返回值
void print_numbers(const multimap<string,int>& phone_book)
{
typedef multimap<string,int>::const_iterator I;
pair<I,I> result = phone_book.equal_range("name");
for (I i = result.first; i!=b.second; ++i) cout<<i->second<<endl;
}
关于tri的hash_map,boost是一个好东西
相对于utility pack来升级支持tr1使用boost反而有更好的移植性
#include <boost/tr1/unordered_map.hpp>
std::tr1::unordered_map<key_type,val_type> hashmap;
TC++PL 17章忠告中第10条
尽量使用最小的操作集合,以取得最大的灵活性
------------------------
标准库容器中的元素必须可以复制
在使用 noncopyable 的时候应该注意这一点
posted @
2009-03-26 22:50 Charlie 侯杰 阅读(1787) |
评论 (4) |
编辑 收藏
by Charlie