- 浏览: 1061874 次
- 性别:
- 来自: 杭州
文章分类
- 全部博客 (695)
- 心情日记 (14)
- AS开发工具 (12)
- 文章转载 (99)
- AIR (5)
- 问题总结 (46)
- SWF格式 (7)
- 测试总结 (10)
- 外文资料 (9)
- 算法技术 (33)
- AS3常用开源库 (43)
- 源码范例 (102)
- FLEX (72)
- FLASH 优化 (33)
- 游戏开发 (49)
- 开发技术 (11)
- 工作应用 (34)
- AS3收集 (140)
- WebBase (0)
- 开发构想 (4)
- 设计模式 (2)
- 框架和框架范例 (19)
- RED5 (3)
- java开发 (3)
- JAVA (1)
- FLASH-3D (23)
- 3D (6)
- 书籍 (10)
- 业界信息资料 (3)
- C# (1)
- JavaScript (12)
- HTML5 (6)
- Flixel (1)
- D5Power RPG网页游戏引擎 (0)
- ColorMatrixFilter - 获得相应颜色的色调 函数 (0)
- Starling (0)
最新评论
-
老顽童203:
字体
水果忍者鼠标跟随特效制作[转载] -
hairball00:
[转] 放出超多的Flash组件源代码 -
he74552775:
flash AS3 RegExp简单功能用法(转) -
hanshuai1232000:
第四点,有利也有弊,等你做了大型的aprg,你就知道了
[转]位图数据内存优化 -
yangfantao:
太感谢
[转] 放出超多的Flash组件源代码
http://uh.9ria.com/space-12147-do-blog-id-2140.html
最近MVC框架炒得沸沸扬扬的。我并不是说游戏中就不该使用MVC框架,而是说,比起MVC框架,游戏里还有很多可以明显提高效率和质量的地方。MVC框架本身对于游戏来说帮助不大,由于成本还可能有反效果。
但我光这样说,显然没什么说服力。因此,在这里贡献一个游戏的架构思路出来。好坏则由大家判断。
//**准备**//
首先,第一步就应当分为通用和不通用两部分。通用部分就是大家所说的游戏引擎。这部分暂且不提,但对于一个长期开发的团队,不应该只以一个游戏作为目标。所以,应该在开发过程中尽可能通用部分移出。这部分和游戏的框架结构是相同的。
但,如果的确没有精力,这部分可以无视。
其实这部分任何项目都有的,因为有一个必要的部分必须放在这:UI框架。
//**开始**//
应用架构说起来很简单,就是一棵树。
树的根节点就是主程序,负责所有和后台的交互操作,模块间通讯,资源加载,以及提供其他一些通用服务。在这个地方,可以根据规模来进行细节,MVC框架也未尝不可。但这部分代码占总代码量的份额并不会太多,各个子模块分得也很清楚。虽然不难做,但做了也没什么用。
这里需要注意一点,不管内部是怎样开发的,这部分公开的接口应当简单清晰,因为它会被非常频繁的调用,所有的模块都会去引用他。如果使得其他开发者使用困难的话,会降低整个项目的开发效率,影响范围很大。
包括的内容可能是:
View:场景切换,公共UI(指的是提示框,小图标一类)。
Command:后台交互,跨模块通讯。
Model:系统公共数据(全局设置,玩家数据等)以及所有Model的引用,后台代理。
//**第二步**//
这个节点往下,会由于游戏类型不同具有不同的分支。一般可分为四大类:屏幕,容器,容器内的对象,UI。
屏幕:简单的说,就是游戏的各个场景。它是一个直接显示出来的东西,具体的逻辑代码全在里面,控制人物走动,调出资源。如果是小游戏的话,它就是整个游戏的全部。之所以叫屏幕,是因为有切换屏幕的操作(比如从开始界面进入到游戏内),每次切换自然是销毁上一个,然后重新生成下一个。如果说模块可能更容易理解。换场景也是如此,这样才能保证游戏的内容可以简单的进行横向扩展,新的场景?继承了加一个屏幕就可以了。一个场景里有特殊的功能,必须编码实现?继承了当原来那样用就是。多态特性要多多利用。分屏?两个屏幕同时存在就可以了。
容器和容器内的对象:这是密切结合的两个部分。就像FLEX的容器和UI对象一样。考虑到效率以及易用性,他们之间相互联系的代码需要封装在他们内部——或者容器内,或者对象内。而且为了避免误解,不允许在容器内加入其他的显示对象。这种强耦是必要的,否则复杂度会急剧上升。如果有意见,请先向现在所有的UI框架提意见。
这里有一个逻辑分配的原则:凡是单个对象和容器之间交互的代码,应当放在对象内。因为对象的种类肯定比容器多,这样分支会写的比较少,添加新的对象也比较容易。而多个对象和容器的交互,则只能写在容器内了。这是一般的想法就不用解释了。总之,代码应该尽量写在数量居多的一方。
虽然这样说,低成本的解耦依然是必要的。这是一个比对的过程,怎样才能既能保证效率(编码以及运行效率),也不至于太伤害到之后的扩展性和可维护性?作为架构者必须考虑这个问题。如果这样的问题不需要考虑的话,如果架构就是照搬一个完美的标准然后执行,电脑比你干得更好。
UI:UI属于一个相对比较独立的部分,而且通用性很高。如果UI比较复杂的话(诸如策略游戏),也可以使用MVC,就像一般的企业应用那样操作。但如果游戏内的UI比较简单的话,而且不可能复杂化(诸如动作游戏),就没有那个必要。
屏幕作为一个模块的主体,作为一个真正意义的容器,已经不适合再向下细分了。UI作为独立的一部分,则不在讨论范围内。容器分无可分,最麻烦的,就是容器里的对象。而它的种类,数量,以及逻辑也是最多的。
//**第三步**//
这个东西,应当在逻辑上分为三层。
第一层:类型和数据
类型:仅仅靠Class,是不可能表述游戏里千奇百怪的内容的。Class只能用来分大类,比如人物,建筑,地图,如此分开。但每个人物,建筑,地图都可能各有不同,而同时又有相同的部分。因此,需要一种对象,来专门表述类型。
比如:一棵树。它首先可以分在物品Class里。然后,它是一颗树,所以它的类型就是树。这个世界上有很多树,都必须由这个类型来生成。但这个类型往往不光是保存“树”这样一个字符,需要保存树的特性,树是不同的,但树是植物的一种,因此树有阻挡特性,树可以被烧掉。树的各个状态有不同的显示,和树交互时的会发生什么。这些都是“树”这种东西共有的特性,是所有树肯定都有的东西。
这就是一个类型。类型一般需要保存在前台脚本里,因为他是不变的。有一点可能容易忽略,就是人物(包括玩家人物),也算类型的一种。
类型也可能分层,分大类,分小类。但细分是必要的。游戏的扩展,很大程度就是物品的功能,数量增加。
数据:数据是可以重新生成对象的最小内容。因此,正常情况下他都是直接被用来进行数据传输的。人物的数据,就是用户名,人物形象,拥有的物品一类。物品的数据,则是他的位置,他的当前状态。当然,切不可少的就是它的类型。
数据是一个世界上的物品的唯一存在。因此,它不应当拥有clone方法,应当保证这个数据所生成的所有对象都能访问到这个唯一实例。真实的物质世界,是没有复制法术的,游戏里最好也不要有。一定要复制,也应该像AS3里的一样,重新实例化一个类型,“New”,然后给它相应的内容。这能有效避免混乱。
数据是唯一的。所以所有对象都能找到自己唯一的数据。但反过来并不是这样。一个数据可能对应着多个对象的副本。因此,不能作为对象之间交互的桥梁。它只是一个保证确定性的基准。某种程度上,和类型相似。
第二层:逻辑对象
它的基类是一个Object,或者EventDispatcher。存在最主要的目的不是为了层次清晰,而是为了性能。
逻辑对象和显示对象实际上,是一个完全的一对一关系。一个逻辑对象只能生成一个显示对象,一个显示对象也包含唯一的一个逻辑对象。显示对象的初始化时间和内存占用远大于逻辑对象,分出这样一个的东西,你就可以放心将所有数据生成对象,并保存起来,直接操作他们的属性,而不用理会他们是否在屏幕中显示,理会创建需要的时间,以及占用的大量内存。
应该在不涉及显示对象的同时,尽可能将逻辑归入这里。对象之间的交互,应当尽可能只通过逻辑对象完成,而不要去涉及显示对象。
逻辑对象应当具有clone方法,因为显示对象和他是处于一对一的关系的,而显示对象的clone很难做。一个图形,可能会在界面里显示,也可能同时在状态栏里显示,或者在提示中显示,因此是有复制对象的需求的。
逻辑对象并不是桥梁,它才是主体。
第三层:显示对象
显示对象是逻辑对象根据自己的数据,生成的一个用于显示的对象,主要的目的就是让他能被addChild。它是依附于逻辑对象的,很多属性都要从对应的逻辑对象取,许多操作也需要借助逻辑对象完成。但他本身的逻辑依然不少,即使只和显示有关。诸如行走动画,高亮显示,景深排序,输入设备控制,碰撞,非常多的功能都必须在这里实现。正常来讲,会比逻辑对象内容更多。
他应当只包括必须依赖现实对象才能控制的逻辑,诸如在屏幕里的坐标,用户操作。而它也是实际放在容器和屏幕里的东西,与他们会有千丝万缕的关系,所以不可能把代码都移走。
如果不分层的话,它就是全部的内容。本身也的确就是最复杂的部分。所以的确很需要减减负。换句话说,至少不要再随便给它增加东西了。在他的内部增加代码,应当是最后的选择。虽然,“最后的选择”只有显示对象,也是很常见的事情。
以简单的纸牌游戏为例,类型是纸牌(规定了背景和颜色),数据是A12345KQ,逻辑对象一次性会被全部生成,出牌等操作归逻辑对象管,然后由逻辑对象动态生成显示对象,计算,并触发他们的动画,显示以及销毁。容器辅助显示内容,显示牌之外的部分,屏幕管理游戏流程,控制大厅和游戏界面的切换,主程序则负责通信以及控制全局。
//**结束**//
这只是一个简单的思路,真做的时候有很多东西需要复合进去,诸如资源加载,数据解析,AI。开发过程则是将各个部分分给不同的人,先从简单类做起,之后再慢慢通过继承和复合增加功能,但从一开始就应当拥有这个结构。强藕的部分在不同的人手里,要尽可能协调,力图将影响减少到最低。
MVC是个很好的东西,但它用在这种满篇继承复合接口,交叉引用频繁,仅仅为了解耦成本过高。是没有办法的事情。我个人还是只建议在UI部分使用MVC框架。当然,用不用还是你自己的自由。
最近MVC框架炒得沸沸扬扬的。我并不是说游戏中就不该使用MVC框架,而是说,比起MVC框架,游戏里还有很多可以明显提高效率和质量的地方。MVC框架本身对于游戏来说帮助不大,由于成本还可能有反效果。
但我光这样说,显然没什么说服力。因此,在这里贡献一个游戏的架构思路出来。好坏则由大家判断。
//**准备**//
首先,第一步就应当分为通用和不通用两部分。通用部分就是大家所说的游戏引擎。这部分暂且不提,但对于一个长期开发的团队,不应该只以一个游戏作为目标。所以,应该在开发过程中尽可能通用部分移出。这部分和游戏的框架结构是相同的。
但,如果的确没有精力,这部分可以无视。
其实这部分任何项目都有的,因为有一个必要的部分必须放在这:UI框架。
//**开始**//
应用架构说起来很简单,就是一棵树。
树的根节点就是主程序,负责所有和后台的交互操作,模块间通讯,资源加载,以及提供其他一些通用服务。在这个地方,可以根据规模来进行细节,MVC框架也未尝不可。但这部分代码占总代码量的份额并不会太多,各个子模块分得也很清楚。虽然不难做,但做了也没什么用。
这里需要注意一点,不管内部是怎样开发的,这部分公开的接口应当简单清晰,因为它会被非常频繁的调用,所有的模块都会去引用他。如果使得其他开发者使用困难的话,会降低整个项目的开发效率,影响范围很大。
包括的内容可能是:
View:场景切换,公共UI(指的是提示框,小图标一类)。
Command:后台交互,跨模块通讯。
Model:系统公共数据(全局设置,玩家数据等)以及所有Model的引用,后台代理。
//**第二步**//
这个节点往下,会由于游戏类型不同具有不同的分支。一般可分为四大类:屏幕,容器,容器内的对象,UI。
屏幕:简单的说,就是游戏的各个场景。它是一个直接显示出来的东西,具体的逻辑代码全在里面,控制人物走动,调出资源。如果是小游戏的话,它就是整个游戏的全部。之所以叫屏幕,是因为有切换屏幕的操作(比如从开始界面进入到游戏内),每次切换自然是销毁上一个,然后重新生成下一个。如果说模块可能更容易理解。换场景也是如此,这样才能保证游戏的内容可以简单的进行横向扩展,新的场景?继承了加一个屏幕就可以了。一个场景里有特殊的功能,必须编码实现?继承了当原来那样用就是。多态特性要多多利用。分屏?两个屏幕同时存在就可以了。
容器和容器内的对象:这是密切结合的两个部分。就像FLEX的容器和UI对象一样。考虑到效率以及易用性,他们之间相互联系的代码需要封装在他们内部——或者容器内,或者对象内。而且为了避免误解,不允许在容器内加入其他的显示对象。这种强耦是必要的,否则复杂度会急剧上升。如果有意见,请先向现在所有的UI框架提意见。
这里有一个逻辑分配的原则:凡是单个对象和容器之间交互的代码,应当放在对象内。因为对象的种类肯定比容器多,这样分支会写的比较少,添加新的对象也比较容易。而多个对象和容器的交互,则只能写在容器内了。这是一般的想法就不用解释了。总之,代码应该尽量写在数量居多的一方。
虽然这样说,低成本的解耦依然是必要的。这是一个比对的过程,怎样才能既能保证效率(编码以及运行效率),也不至于太伤害到之后的扩展性和可维护性?作为架构者必须考虑这个问题。如果这样的问题不需要考虑的话,如果架构就是照搬一个完美的标准然后执行,电脑比你干得更好。
UI:UI属于一个相对比较独立的部分,而且通用性很高。如果UI比较复杂的话(诸如策略游戏),也可以使用MVC,就像一般的企业应用那样操作。但如果游戏内的UI比较简单的话,而且不可能复杂化(诸如动作游戏),就没有那个必要。
屏幕作为一个模块的主体,作为一个真正意义的容器,已经不适合再向下细分了。UI作为独立的一部分,则不在讨论范围内。容器分无可分,最麻烦的,就是容器里的对象。而它的种类,数量,以及逻辑也是最多的。
//**第三步**//
这个东西,应当在逻辑上分为三层。
第一层:类型和数据
类型:仅仅靠Class,是不可能表述游戏里千奇百怪的内容的。Class只能用来分大类,比如人物,建筑,地图,如此分开。但每个人物,建筑,地图都可能各有不同,而同时又有相同的部分。因此,需要一种对象,来专门表述类型。
比如:一棵树。它首先可以分在物品Class里。然后,它是一颗树,所以它的类型就是树。这个世界上有很多树,都必须由这个类型来生成。但这个类型往往不光是保存“树”这样一个字符,需要保存树的特性,树是不同的,但树是植物的一种,因此树有阻挡特性,树可以被烧掉。树的各个状态有不同的显示,和树交互时的会发生什么。这些都是“树”这种东西共有的特性,是所有树肯定都有的东西。
这就是一个类型。类型一般需要保存在前台脚本里,因为他是不变的。有一点可能容易忽略,就是人物(包括玩家人物),也算类型的一种。
类型也可能分层,分大类,分小类。但细分是必要的。游戏的扩展,很大程度就是物品的功能,数量增加。
数据:数据是可以重新生成对象的最小内容。因此,正常情况下他都是直接被用来进行数据传输的。人物的数据,就是用户名,人物形象,拥有的物品一类。物品的数据,则是他的位置,他的当前状态。当然,切不可少的就是它的类型。
数据是一个世界上的物品的唯一存在。因此,它不应当拥有clone方法,应当保证这个数据所生成的所有对象都能访问到这个唯一实例。真实的物质世界,是没有复制法术的,游戏里最好也不要有。一定要复制,也应该像AS3里的一样,重新实例化一个类型,“New”,然后给它相应的内容。这能有效避免混乱。
数据是唯一的。所以所有对象都能找到自己唯一的数据。但反过来并不是这样。一个数据可能对应着多个对象的副本。因此,不能作为对象之间交互的桥梁。它只是一个保证确定性的基准。某种程度上,和类型相似。
第二层:逻辑对象
它的基类是一个Object,或者EventDispatcher。存在最主要的目的不是为了层次清晰,而是为了性能。
逻辑对象和显示对象实际上,是一个完全的一对一关系。一个逻辑对象只能生成一个显示对象,一个显示对象也包含唯一的一个逻辑对象。显示对象的初始化时间和内存占用远大于逻辑对象,分出这样一个的东西,你就可以放心将所有数据生成对象,并保存起来,直接操作他们的属性,而不用理会他们是否在屏幕中显示,理会创建需要的时间,以及占用的大量内存。
应该在不涉及显示对象的同时,尽可能将逻辑归入这里。对象之间的交互,应当尽可能只通过逻辑对象完成,而不要去涉及显示对象。
逻辑对象应当具有clone方法,因为显示对象和他是处于一对一的关系的,而显示对象的clone很难做。一个图形,可能会在界面里显示,也可能同时在状态栏里显示,或者在提示中显示,因此是有复制对象的需求的。
逻辑对象并不是桥梁,它才是主体。
第三层:显示对象
显示对象是逻辑对象根据自己的数据,生成的一个用于显示的对象,主要的目的就是让他能被addChild。它是依附于逻辑对象的,很多属性都要从对应的逻辑对象取,许多操作也需要借助逻辑对象完成。但他本身的逻辑依然不少,即使只和显示有关。诸如行走动画,高亮显示,景深排序,输入设备控制,碰撞,非常多的功能都必须在这里实现。正常来讲,会比逻辑对象内容更多。
他应当只包括必须依赖现实对象才能控制的逻辑,诸如在屏幕里的坐标,用户操作。而它也是实际放在容器和屏幕里的东西,与他们会有千丝万缕的关系,所以不可能把代码都移走。
如果不分层的话,它就是全部的内容。本身也的确就是最复杂的部分。所以的确很需要减减负。换句话说,至少不要再随便给它增加东西了。在他的内部增加代码,应当是最后的选择。虽然,“最后的选择”只有显示对象,也是很常见的事情。
以简单的纸牌游戏为例,类型是纸牌(规定了背景和颜色),数据是A12345KQ,逻辑对象一次性会被全部生成,出牌等操作归逻辑对象管,然后由逻辑对象动态生成显示对象,计算,并触发他们的动画,显示以及销毁。容器辅助显示内容,显示牌之外的部分,屏幕管理游戏流程,控制大厅和游戏界面的切换,主程序则负责通信以及控制全局。
//**结束**//
这只是一个简单的思路,真做的时候有很多东西需要复合进去,诸如资源加载,数据解析,AI。开发过程则是将各个部分分给不同的人,先从简单类做起,之后再慢慢通过继承和复合增加功能,但从一开始就应当拥有这个结构。强藕的部分在不同的人手里,要尽可能协调,力图将影响减少到最低。
MVC是个很好的东西,但它用在这种满篇继承复合接口,交叉引用频繁,仅仅为了解耦成本过高。是没有办法的事情。我个人还是只建议在UI部分使用MVC框架。当然,用不用还是你自己的自由。
发表评论
-
设计模式(23种设计模式.AS3实现)
2011-10-13 02:04 0设计模式(23种设计模式.AS3实现) -
CutLoad 库 UI库
2011-08-22 22:17 0CutLoad 库 UI库 http://www.mk ... -
Alternativa3D资料
2011-08-15 18:52 0Alternativa3D资料 Alternativa3D资 ... -
[转]一个Collision类,其中的block方法可以实现两个物体之间的碰撞检测。
2011-07-30 02:35 1323第二个是书中的源代码给出了一个Collision类,其中 ... -
[转] 关于动态嵌入字体
2011-07-26 23:38 1462http://bbs.9ria.com/viewthre ... -
文字如何缩放?
2011-07-26 23:20 1200做个文件打印的东东,需要预览,就是把保存的Sprite类缩小再 ... -
大航海通信信息解析工具 --- 大航海通信信息解析工具梁冀南,吴亮-大航海 通信VO解析用的工具和类, 实用-- 需要配合DOKU 需要对CLASS 进行全路径
2011-07-25 22:51 0大航海通信信息解析工 ... -
FLASH CS3-4所带的 组件 打包SWC 其中带了 另附 YAHOO组件
2011-07-14 21:17 0FLASH CS3-4所带的 组件 打包SWC 其中带 ... -
Transform Tool 2 更新
2011-06-22 01:59 0本帖最后由 sun11086 于 2011-6-9 1 ... -
[转] 放出超多的Flash组件源代码
2011-06-21 21:45 3059奋战了2周,其实我本来 ... -
[新闻资讯] [Flash/Flex] ActionScript 3多线程框架-CMVC框架
2011-05-17 20:44 2001http://bbs.9ria.com/viewthread. ... -
(Robotlegs五子棋)HelloRobotlegs
2011-05-17 00:41 753(Robotlegs五子棋)HelloRobotlegs -
[转] 老板让俺总结的puremvc学习笔记
2011-04-10 05:48 1565http://bbs.9ria.com/viewthread. ... -
ASWING BETA2.0
2011-03-22 21:17 0ASWING BETA2.0 -
[转]http://www.uml.org.cn/softwareprocess/rjgc6.htm
2011-03-08 15:48 843http://www.uml.org.cn/softwa ... -
[转]XP 极限编程
2011-03-08 15:47 724http://blog.csdn.net/bluesmile9 ... -
一款简易的flash UI组件
2011-03-04 19:31 1140http://code.google.com/p/librau ... -
WeeMVC
2011-03-02 16:57 770http://weemvc.org/ API:-- htt ... -
[转]浅谈三层结构与MVC模式的区别
2011-02-28 12:03 1028有朋友谈到三层与MVC的 ... -
[转]三层架构总结
2011-02-28 11:59 11961、开发人员可以只关注 ...
相关推荐
分布式系统架构设计思路分布式系统架构设计思路分布式系统架构设计思路分布式系统架构设计思路分布式系统架构设计思路
游戏引擎架构 游戏引擎架构 游戏引擎架构 游戏引擎架构
《游戏引擎架构》为一个大学程度的游戏编程课程而编写,但也适合软件工程师、业余爱好者、自学游戏程序员,以及游戏产业的从业人员。通过阅读《游戏引擎架构》,资历较浅的游戏工程师可以巩固他们所学的游戏技术及...
游戏引擎架构2
基于数据驱动的数字化转型架构思路.pptx
网络多人游戏架构与编程.pdf &源码
游戏架构设计与策划基础.pdf
《游戏架构设计与策划基础》以当前游戏公司实际游戏策划设计方案为教学实例,介绍游戏策划设计的基本理论。把重点放在提高学员各种游戏的设计能力上。通过对游戏开发中的概念设计、原型设计、规则设计、情节设计、...
数字化转型中的大数据治理架构设计思路.pptx
仙剑奇侠传四游戏架构分析,从各方面角度分析仙剑四游戏
此文档提供架构设计的思路,并不是标准的格式的文档,其中的考虑点,架构设计方式可以参考,希望有所帮助,谢谢,支持
游戏引擎架构 .pdf游戏引擎架构 .pdf游戏引擎架构 .pdf
同时,还介绍了SDN中最重要的系统一SDN控制器实现架构和原理;随后,介绍了SDN而临的各种挑战和可能的应对措施;最后,介绍了如何从现有网络架构演进到SDN架构 本书为华为3位顶级架构师的心血之作,是学习SDN的必备书籍 ...
《游戏引擎架构》为一个大学程度的游戏编程课程而编写,但也适合软件工程师、业余爱好者、自学游戏程序员,以及游戏产业的从业人员。通过阅读《游戏引擎架构》,资历较浅的游戏工程师可以巩固他们所学的游戏技术及...
施工企业数字化转型建设方案顶层架构设计思路.pptx
游戏引擎架构 PDF电子书带书签目录 完整版 PDF 分两部分,需要一起解压
自己制作的整个游戏的架构图
游戏公司组成架构和游戏开发流程简述 很全面,对于不了解游戏开发的人很有帮助。
阿里云:企业大数据平台数仓架构建设思路
清晰描述一个游戏需要的功能及搭建的架构图,值得收藏!