Questions tagged «architecture»

代码的结构。有关游戏引擎内部设计的问题。

1
“系统”在基于组件的实体体系结构中的作用是什么?
我阅读了很多有关实体组件和系统的文章,并认为将实体当作ID的想法非常有趣。 但是我不知道这在组件方面或系统方面是如何完全起作用的。组件只是由某些相关系统管理的数据对象。碰撞系统使用某些BoundsComponent以及空间数据结构来确定是否发生了碰撞。 到目前为止一切都很好,但是如果多个系统需要访问同一组件怎么办?数据应该存放在哪里?输入系统可以修改实体BoundsComponent,但是物理系统需要访问与某些渲染系统相同的组件。 另外,实体是如何构造的?我读到的很多优点之一是实体构造的灵活性。系统本质上与组件相关联吗?如果要引入一些新组件,是否还必须引入新系统或修改现有系统? 我经常读到的另一件事是,实体的“类型”由其具有的组件来推断。如果我的实体只是一个id,我怎么知道我的机器人实体需要被某个系统移动或渲染并进行修改? 很抱歉发布了很长的帖子(或者至少从我的手机屏幕看来如此)!

8
为什么在游戏架构中不更多地使用MVC和TDD?[关闭]
首先,我不会看大量的游戏资源,也不会以游戏的方式构建游戏。 但是,由于试图在Web应用程序中采用“企业”编码实践,查看游戏源代码严重伤害了我的头脑:“这种视图逻辑与业务逻辑的关系是什么?这需要重构……重构,重构,重构也是如此吗? ” 这让我很担心,因为我将要开始一个游戏项目,而且我不确定尝试对mvc / tdd的开发过程是否会阻碍我们或为我们提供帮助,因为我看不到很多使用此功能的游戏示例或在社区中推动更好的建筑实践。 以下是一篇有关原型游戏的精彩文章的摘录,尽管对我而言,这似乎正是许多游戏开发人员在编写正式游戏代码时似乎使用的态度: 错误四:构建系统而不是游戏 ...如果您发现自己从事的工作无法直接推动自己前进,请就此停下来。作为程序员,我们倾向于尝试将代码泛化,使其变得优雅并能够处理各种情况。我们发现痒痒非常难,不会刮伤,但是我们需要学习如何做。我花了很多年才意识到,这与代码无关,而与最终发布的游戏有关。 不要编写精美的游戏组件系统,不要完全跳过编辑器,而将状态硬编码到代码中,避免数据驱动,自解析,XML疯狂,而只需编写该死的东西。 ...尽可能快地在屏幕上获取内容。 而且永远不要使用参数“如果我们花一些额外的时间并以正确的方式进行操作,我们可以在游戏中重用它”。永远 是因为游戏(大多)是面向视觉的,所以有意义的是代码将在视图中占很大的比重,因此将内容移到模型/控制器中所获得的任何好处都非常少,所以为什么要打扰? 我听到过这样的论点,即MVC引入了性能开销,但是在我看来这是过早的优化,在担心MVC开销(例如渲染管道,AI算法,数据结构)之前,还有更多重要的性能问题需要解决遍历等)。 关于TDD也是一样。我很少看到游戏使用测试用例,但这可能是由于上述设计问题(混合视图/业务)以及难以测试视觉组件或依赖概率结果的组件(例如,在物理模拟中运行)造成的。 )。 也许我只是看错了源代码,但是为什么我们看不到游戏设计中采用的更多“企业”实践呢?游戏的需求真的有如此大的不同吗?还是人/文化问题(例如,游戏开发者来自不同的背景,因此具有不同的编码习惯)?

3
我应该如何编写主游戏循环?[关闭]
我应该如何编写主游戏循环?您应该在游戏循环中执行哪些操作,以及在游戏循环中不应执行的操作? 我已经写了很多,但我从未真正阅读过游戏循环。我敢肯定我可以大大改善它们,但不确定如何。

9
实体沟通如何工作?
我有两个用户案例: 如何将entity_A发送take-damage消息entity_B? 如何entity_A查询entity_B的HP? 到目前为止,这是我遇到的情况: 消息队列 entity_A创建一条take-damage消息并将其发布到entity_B的消息队列中。 entity_A创建一条query-hp消息并将其发布到entity_B。 entity_B作为回报,创建一条response-hp消息并将其发布到entity_A。 发布/订阅 entity_B订阅take-damage消息(可能具有一些抢先过滤功能,因此仅传递相关消息)。 entity_A产生take-damage引用消息entity_B。 entity_A订阅update-hp消息(可能已过滤)。每个帧都entity_B广播update-hp消息。 信号/插槽 ??? entity_A将update-hp插槽连接到entity_B的update-hp信号。 有更好的东西吗?我对这些通信方案如何与游戏引擎的实体系统联系起来有正确的理解吗?

11
学习游戏架构的好资源?[关闭]
是否有用于学习游戏架构的良好资源?我正在寻找不同体系结构的高级概述。我倾向于找到有关游戏各个部分的信息,例如实体,物理引擎,脚本等,而不是有关如何将所有部分组合在一起的信息。 作为奖励,游戏类型对此有何影响?例如,平台程序和MMO将有所不同。
104 architecture 

8
为什么更多游戏不使用矢量艺术?[关闭]
在我看来,矢量艺术在资源/可扩展性方面更有效;但是,在大多数情况下,我已经看到艺术家使用位图/光栅化的艺术品。这是游戏程序员/设计师对艺术家的限制吗?作为一名程序员,我认为矢量艺术将更为理想,因为它可以扩大分辨率,而无需重新创建艺术作品,创建非常大的图形或使图形变得模糊。 问题:为什么没有更多的人使用SVG / AI来创建2D游戏画面?实际上会被首选吗?(谁更喜欢)?位图图形是一种标准还是一种限制(或者可能两者都不是)? 背景:我正在研究引擎,对基于矢量的图形有一些不错的想法;但是,我不想在以后惹恼艺术家。 我想这更多是围绕实用主义和开发游戏的问题。

11
如何设计重放系统
那么我将如何设计一个重放系统? 您可能从某些游戏(例如《魔兽争霸3》或《星际争霸》)中知道了这一点,您可以在游戏玩完后再次观看。 您最终得到一个相对较小的重播文件。所以我的问题是: 如何保存数据?(自定义格式?)(小文件大小) 应该保存什么? 如何使其具有通用性,使其可以在其他游戏中用于记录时间段(例如,不是完整的比赛记录)? 使前进和后退成为可能(据我记得,WC3无法后退)


8
游戏引擎中事件驱动的通信:是或否?
我正在阅读《游戏编码完成》,作者建议游戏对象和模块之间进行事件驱动通信。 基本上,所有在场的游戏参与者都应通过内部事件消息传递系统与关键模块(物理,AI,游戏逻辑,游戏视图等)进行通信。这意味着必须设计一个高效的事件管理器。设计不良的系统会占用CPU周期,特别是影响移动平台。 这是一种行之有效的推荐方法吗?我应该如何决定是否使用它?

9
如何避免玩家与世界之间的循环依赖?
我正在开发2D游戏,您可以在其中上下左右移动。我基本上有两个游戏逻辑对象: 玩家:相对于世界的位置 世界:绘制地图和玩家 到目前为止,World依赖于Player(即具有对它的引用),需要其位置来确定在何处绘制玩家角色以及要绘制地图的哪一部分。 现在,我想添加碰撞检测,以使玩家无法穿过墙壁。 我能想到的最简单的方法是让玩家询问世界是否可以进行预期的移动。但这会在播放器和世界之间引入循环依赖关系(即,每个都有对另一个的引用),这似乎值得避免。我想出的唯一方法是让World移动Player,但是我发现这有点不直观。 我最好的选择是什么?还是避免循环依赖不值得?

8
如何避免游戏架构中出现很多单例?
我使用cocos2d-x游戏引擎来创建游戏。引擎已经使用了很多单例。如果有人使用过,那么他们应该熟悉其中的一些: Director SimpleAudioEngine SpriteFrameCache TextureCache EventDispatcher (was) ArmatureDataManager FileUtils UserDefault 还有更多内容,总共约16个课程。您可以在此页面上找到类似的列表:Cocos2d-html5 v3.0中的单例对象但是当我要编写游戏时,我需要更多单例: PlayerData (score, lives, ...) PlayerProgress (passed levels, stars) LevelData (parameters per levels and level packs) SocialConnection (Facebook and Twitter login, share, friend list, ...) GameData (you may obtain some data from server to configure the game) IAP (for …

7
如何建立处理成绩的灵活框架?
具体地说,实现足够灵活的成就系统的最佳方法是什么,以处理超越简单的统计驱动的成就,例如“杀死x敌人”。 我正在寻找比基于统计的系统更健壮的东西,以及比“将它们全部硬编码为条件”更井井有条的东西。在基于统计的系统中一些不可能或难以处理的示例:“在草莓之后切西瓜”,“在立于不败之地下水管”等。

10
游戏状态“堆栈”?
我在考虑如何在游戏中实现游戏状态。我想要的主要内容是: 半透明顶部状态-可以通过暂停菜单查看后面的游戏 面向对象的东西,我发现这更易于使用和理解其背后的理论,以及保持组织规范并添加更多内容。 我打算使用链接列表,并将其视为堆栈。这意味着我可以访问下面的状态以获得半透明性。 计划:将状态堆栈作为指向IGameStates的指针的链接列表。顶部状态处理其自己的更新和输入命令,然后具有成员isTransparent来决定是否应绘制下面的状态。 然后我可以做: states.push_back(new MainMenuState()); states.push_back(new OptionsMenuState()); states.pop_front(); 要表示播放器的负载,请依次转到选项和主菜单。 这是个好主意,还是...?我应该看看别的东西吗? 谢谢。

5
如何避免GameManager神物?
我刚刚阅读了有关构建游戏代码的问题的答案。这让我想知道普遍存在的GameManager类,以及它在生产环境中如何经常成为问题。让我描述一下。 首先,有原型。没有人会在乎编写出色的代码,我们只是尝试运行一些东西,以查看游戏玩法是否合计。 然后是一个绿灯,为了清理事物,有人写了一个GameManager。可能真的要抱一堆GameStates,也许要存储一些GameObjects,没什么大不了的。可爱的小经理。 在预生产的和平领域中,游戏的状态很好。编码人员有适当的睡眠时间,并且有很多想法可以使用出色的设计模式来构建事物。 然后开始生产,很快就会有紧要关头。均衡饮食早已一去不复返了,错误跟踪器正在解决问题,人们感到压力很大,游戏必须在昨天发布。 在那个时候,通常,这GameManager是一个很大的混乱(保持礼貌)。 原因很简单。毕竟,编写游戏时,嗯......所有的源代码实际上是在这里管理的游戏。只需在中已添加了GameManager所有其他内容的位置添加此额外功能或错误修正,就很容易了。当时间成为问题时,就无法编写单独的类,也不能将此巨型管理器拆分为子管理器。 当然,这是一个经典的反模式:上帝对象。这是一件坏事,要合并的痛苦,要维持的痛苦,要理解的痛苦,要转变的痛苦。 您有什么建议可以防止这种情况发生? 编辑 我知道怪罪命名。当然,创建一个GameManager类并不是一个好主意。但同样的事情可以发生在一个干净的GameApplication或者GameStateMachine或GameSystem那最终被管道胶带喜爱的一个项目的结束。不管命名如何,您都可以在游戏代码中的某个位置找到该类,但现在它只是一个雏形:您还不知道它将变成什么样的怪物。所以我不期待“怪罪命名”的答案。我想要一种防止这种情况发生的方法,一种编码架构和/或一个团队可以遵循的流程,因为他们知道这将在生产中的某个时刻发生。放弃一个月的错误修正和最新功能真是太糟糕了,因为所有这些现在都在一个庞大的无法维护的经理中。

4
如何避免巨人课程?
游戏中几乎总是有一个玩家等级。玩家通常可以在游戏中做很多事情,这对我而言,这堂课最终变得庞大,需要大量变量来支持玩家可以执行的每项功能。每个部分都很小,但是结合起来,我最终要编写成千上万行代码,找到您需要的内容会很痛苦,而进行更改会让人感到恐惧。基本上是整个游戏的通用控件,如何避免这个问题?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.