Questions tagged «design-patterns»

设计模式是在软件设计中给定上下文中对常见问题的通用可重用解决方案。

2
如何避免编写Manager类?
我似乎一直在读,XxxManager在游戏引擎编程中使用样式类是一个坏主意,但是即使我尝试避免使用样式类,我也总是最终得到可以容纳所有参与者/实体/游戏世界位置并对其进行操作的东西。最终成为Manager另一个名字的if。 这真的是一个不好的模式吗?如果是这样,有哪些替代方案?

3
规则系统的设计模式?
作为一个快速有趣的项目,我尝试编写了单人纸牌游戏。但是在编写规则系统时,我感到很脏,因为我的代码感觉完全是非结构化且不可扩展的,主要是因为我的游戏逻辑是完整的意大利面条式代码。 我以前遇到过这个问题,在编写程序的这一部分时总是感到尴尬,所以我想知道,在定义游戏规则时是否有任何经过实践检验的最佳实践?

2
正确的方法来抽象XBox控制器
我有一个XBox360控制器,我想将其用作应用程序的输入。 我无法解决的是通过接口公开此内容的最佳实践方法。 在幕后,处理控制器的类依赖于轮询按钮状态。 我最初尝试了一些链接: Event ButtonPressed() as ButtonEnum 这里ButtonEnum是ButtonRed,ButtonStart等... 这是有一点限制的,因为它仅支持按钮按下,不支持按住/模式(按两次,等等)。 下一个想法是简单地向应用程序公开按钮状态,例如 Property RedPressed as Boolean Property StartPressed as Boolean Property Thumb1XAxis as Double 这是非常灵活的方法,但实际上它会迫使应用程序投入过多工作,并且需要应用程序进行轮询-如果可能的话,我更喜欢事件驱动。 我考虑添加多个事件,例如: Event ButtonPressed(Button as ButtonEnum) Event ButtonPressedTwice(Button as ButtonEnum) Event ButtonHeldStart(Button as ButtonEnum) Event ButtonHeldEnd(Button as ButtonEnum) 但这似乎有些笨拙,并且在“绑定按钮”屏幕上确实很痛苦。 有人可以给我指出处理控制器输入的“正确”方法。 注意:我在实现接口的类中使用SlimDX。这使我可以非常轻松地读取状态。任何可以解决我的问题的替代方案也将受到赞赏

1
创建健壮的物品系统
我的目标是创建一个模块化/尽可能通用的物料系统,该系统可以处理以下内容: 可升级物品(+6武士刀) Stat修饰符(+15敏捷) 物品修饰符(%X几率造成Y伤害,几率冻结) 充电物品(魔术师使用30次) 套装物品(装备4件X激活Y功能) 稀有度(常见,独特,传奇) 可分解的(分解成一些手工材料) 可制作(可以使用某些材料制作) 消耗(5分钟%X攻击强度,恢复+15 hp) *我能够解决以下设置中加粗的功能。 现在,我尝试添加许多选项以反映我的想法。我不打算添加所有必要的功能,但是我希望能够按照自己的意愿实施它们。这些也应该与库存系统和数据序列化兼容。 我计划完全不使用继承,而是使用实体组件/数据驱动的方法。最初,我想到的系统具有: BaseStat:通用类,可随时随地保存统计信息(也可用于项和字符统计信息) Item:包含数据的类,例如列表,名称,itemtype和与ui,actionName,description等相关的事物。 IWeapon:武器界面。每个武器都有实现IWeapon的自己的类。这将具有Attack(攻击)和对角色统计的引用。装备武器后,它的数据(物品类别的stat)将被注入角色stat(无论拥有什么BaseStat,它都会作为Stat奖励添加到角色类别中)因此,例如,我们想制作一把剑(想产生带有json的物品类),所以剑将对角色属性增加5点攻击。因此,我们有一个BaseStat为(“ Attack”,5)(我们也可以使用enum)。装备时,此属性将作为BonusStat(将是不同的类)添加到角色的“攻击”属性中。因此,名为Sword的类将实现IWeapon,项目类别已创建。因此,我们可以向这把剑注入角色统计数据,并且在攻击时,它可以从角色统计数据中检索总的攻击统计数据,并在Attack方法中造成伤害。 BonusStat:是一种将统计信息添加为奖励而无需触及BaseStat的方法。 IConsumable:与IWeapon相同的逻辑。添加直接属性相当容易(+15 hp),但是我不确定要使用此设置添加临时武器(%x攻击5分钟)。 IUpgradeable:可以使用此设置来实现。我正在考虑将UpgradeLevel作为基本属性,在升级武器时会增加它。升级后,我们可以重新计算武器的BaseStat以匹配其升级级别。 在此之前,我可以看到该系统相当不错。但是对于其他功能,我认为我们还需要其他东西,因为例如,我无法在其中实现Craftable功能,因为我的BaseStat无法处理该功能,这就是我遇到的问题。我可以将所有成分添加为统计信息,但这没有任何意义。 为了使您更轻松地进行此操作,以下一些问题可能会对您有所帮助: 我是否应该继续执行此设置以实现其他功能?没有继承就可能吗? 您有什么办法可以想到,在没有继承的情况下实现所有这些功能? 关于物品修饰符,如何实现?因为它的性质非常通用。 有什么建议可以做些什么来简化构建这种架构的过程? 有没有我可以挖掘的与此问题相关的来源? 我确实尽力避免继承,但是您认为在保持相当可维护性的同时,可以轻松地通过继承解决/实现这些继承吗? 由于我的问题范围很广,因此可以随意回答一个问题,这样我就可以从不同的方面/人那里获得知识。 编辑 遵循@ jjimenezg93的回答,我用C#创建了一个非常基本的系统进行测试,它可以正常工作!看看是否可以添加任何内容: public interface IItem { List<IAttribute> Components { get; set; } void ReceiveMessage<T>(T message); } public interface …

3
我想摆脱我的“制作一切静态和全局”设计模式,但是如何做呢?
我正在太空中制作一个小地牢爬行者,我想听听一些有关如何使引擎后端更好的建议。基本上,当前所有内容都是基于管理人员的: BackgroundManager:具有AddBackground(image, parallax)制作炫酷背景效果的方法。 ConfigManager:读取/制作配置文件,还保存从该配置文件读取的数据。 DrawManager:有Draw(sprite)方法来绘制的东西到屏幕上,事情就是这样SetView(view),GetView()等等。 EntityManager:包含所有活动实体,并具有添加,删除和查找实体的方法。 DungeonManager(实际上称为GridManager,但这是为了简单):有方法,如GenerateDungeon(),PlaceEnemies(),PlaceFinish()等。 现在我什至没有列出所有我的经理,所以我认为这必须改变。我的游戏也基于屏幕,这使它更令人讨厌,因为我不需要经理管理的一半内容,例如主菜单(我的主菜单中不需要物理/实体/地下城) !) 现在,我考虑使管理器不是静态的,并为我的ScreenMainGame提供所有特定于游戏的管理器的实例。但这使打电话给/获取与管理人员有关的任何东西变得一团糟...例如,如果我想从不在的任何地方绘制地牢ScreenMainGame.Draw(),我就必须这样做... ((ScreenMainGame)ScreenManager.CurrentScreen).GridManager.Draw() 真丑。 那么,游戏开发者们,你们有谁知道如何解决这个混乱局面吗?我将不胜感激!

2
将角色的技能和能力作为命令,很好的做法?
我正在设计一款包含具有独特进攻技能和其他能力(例如建造,修理等)的角色的游戏。玩家可以控制多个这样的角色。 我正在考虑将所有这些技能和能力放到单独的命令中。静态控制器会将所有这些命令注册到静态命令列表中。静态列表将包含游戏中所有角色的所有可用技能和能力。因此,当玩家选择一个角色并单击UI上的按钮以投射咒语或执行一项功能时,View会调用静态控制器从列表中获取所需命令并执行该命令。 但是,鉴于我要在Unity中构建游戏,因此我不确定这是否是一个好的设计。我想我可以将所有技能和能力作为独立的组件,然后将其附加到代表游戏角色的GameObjects上。然后,UI将需要保留角色的GameObject,然后执行命令。 对于我正在设计的游戏,什么是更好的设计和实践?

1
执行游戏动作的模式
在游戏中执行各种动作是否存在一种公认的模式?玩家执行动作的方式,以及AI可能执行的动作,例如移动,攻击,自毁等。 我目前有一个抽象的BaseAction,它使用.NET泛型来指定由各种操作返回的不同对象。所有这些都以类似于Command的模式实现,在该模式中,每个动作都对自己负责并完成其所需的全部工作。 我之所以这么抽象,是因为我可以只有一个ActionHandler,并且AI可以将实施baseAction的不同操作排队。而且之所以通用,是因为不同的动作可以返回与该动作相关的结果信息(因为不同的动作在游戏中可能具有完全不同的结果),以及一些常见的beforeAction和afterAction实现。 那么...是否有更可接受的方式来执行此操作,或者听起来还不错吗?

7
游戏中绘画与逻辑的分离
我是一个刚刚开始玩游戏开发的开发人员。我是.NET专家,所以我迷上了XNA,现在正在为iPhone使用Cocos2d。我的问题确实更笼统。 假设我正在构建一个简单的Pong游戏。我要上Ball一Paddle堂课。来自商业世界的发展,我的第一个直觉是在这两个类中的任何一个中都没有任何绘图或输入处理代码。 //pseudo code class Ball { Vector2D position; Vector2D velocity; Color color; void Move(){} } 球类中没有任何东西可以处理输入或处理绘图。然后,我将有另一个班级,Game班级或我的班级Scene.m(在Cocos2d中)将球更新,并且在游戏循环中,它将根据需要操纵球。 事实是,在许多有关XNA和Cocos2d的教程中,我看到了这样的模式: //pseudo code class Ball : SomeUpdatableComponent { Vector2D position; Vector2D velocity; Color color; void Update(){} void Draw(){} void HandleInput(){} } 我的问题是,对吗?这是人们在游戏开发中使用的模式吗?它以某种方式与我习惯的一切背道而驰,让我的Ball类做所有事情。此外,在第二个示例中,我Ball知道如何移动,如何使用Paddle?是否Ball需要了解Paddle?在我的第一个示例中,Game该类将同时引用Ball和和Paddle,然后将这两个都发送给某个CollisionDetection管理器或其他东西,但是如果每个单独的组件自己完成所有工作,那么我该如何处理各种组件的复杂性呢?(我希望我有道理.....)

12
在某些情况下,全局变量/子集在游戏开发中有用吗?[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我知道拥有全局变量或单例类会创建很难测试/管理的案例,而我在代码中使用这些模式的工作已陷入困境,但常常需要交付。 那么在游戏开发中是否存在全局变量或单例实际上有用的情况?

4
游戏设计中的每帧函数调用与事件驱动消息传递
据我所知,传统的游戏设计使用多态和虚拟功能来更新游戏对象的状态。换句话说,在游戏中的每个对象上以规则的间隔(例如,每帧)调用同一组虚拟函数。 最近,我发现,还有另一个- 事件驱动的消息传递系统可用于更新游戏对象的状态。在这里,对象通常不会按帧进行更新。取而代之的是,构建了高效的事件消息传递系统,并且仅在收到有效事件消息之后才更新游戏对象。 事件驱动的游戏体系结构在Mike McShaffry编写的《Game Coding Complete》中有很好的描述。 我可以在以下问题上寻求帮助: 两种方法的优缺点是什么? 哪里比另一个更好? 事件驱动游戏设计在所有领域都通用且更好吗?因此,即使在可移植的平台中,也建议使用它吗? 哪一个更有效,哪个更难开发? 要澄清的是,我的问题不是要从游戏设计中完全消除多态性。我只是希望了解使用事件驱动消息传递与常规(每帧)调用虚拟函数以更新游戏状态的区别和好处。 示例: 这个问题在这里引起了一些争议,因此让我为您提供示例:根据MVC,游戏引擎分为三个主要部分: 应用层(硬件和操作系统通信) 游戏逻辑 游戏画面 在赛车游戏中,“游戏视图”负责以最快的速度(至少30fps)渲染屏幕。Game View也会侦听玩家的输入。现在发生这种情况: 玩家将燃油踏板踩到80% GameView构造一条消息“将Car 2油门踏板压到80%”,并将其发送给Game Logic。 Game Logic会获取消息,评估,计算新车的位置和行为,并为GameView创建以下消息:“绘制2踩下燃油2的燃油踏板”,“ 2声音加速”,“ 2坐标X,Y” .. 。 GameView接收消息并进行相应处理

2
在托管语言中使用粒子池是否值得?
我打算用Java为我的粒子系统实现一个对象池,然后在Wikipedia上找到了它。换句话说,它说不值得在Java和C#等托管语言中使用对象池,因为与非托管语言(如C ++)中的数百种分配相比,分配只需要进行数十次操作。 但是众所周知,每条指令都可能会损害游戏性能。例如,一个MMO中的客户端池:客户端进入和退出池的速度不会太快。但是粒子可能在一秒钟内更新数十次。 问题是:使用对象池来管理语言中的粒子(特别是那些死掉并很快被重新创建的粒子)是否值得?

3
创建实体作为聚合
我最近询问了如何将实体与其行为分开以及与本文相关的主要答案:http : //cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ 这里讨论的最终概念是:作为纯聚集体的对象。 我想知道如何使用C#将游戏实体创建为纯聚合。我还不太了解如何运行的概念。(也许实体是实现特定接口或基本类型的对象的数组?) 我当前的想法仍然涉及为每种实体类型都有一个具体的类,然后实现相关的接口(IMoveable,ICollectable,ISpeakable等)。 我如何才能完全将实体创建为聚合,而又没有该实体的任何具体类型?

4
域驱动设计是否适合游戏?
我刚刚阅读了有关Domain模型的知识,因为我一直在开发一种游戏,该游戏的类仅包含数据(很少的行为/方法),因此它给我带来了启发。我将处理这些类的工作分配给了经理……现在我的经理看起来像是上帝的对象。我应该处理逻辑的游戏对象只是一个贫血领域模型。 我当前的设计模式是在Singleton中,我想进行一些重新编码以将这些内容发布出来。我从未在游戏上看到DDD(到目前为止),但这是一个好方法吗?我只是一个新手程序员(不喜欢游戏开发人员),所以我想在游戏变得过于肿以至于无法重新设计之前,了解有关良好架构的更多信息。

3
有什么方法可以将游戏逻辑与动画和绘制循环分开?
我以前只制作过Flash游戏,使用MovieClips等将动画与游戏逻辑分开。现在,我开始尝试制作适用于Android的游戏,但是围绕这些问题的游戏编程理论仍然让我感到困惑。我来自开发非游戏Web应用程序的背景,因此我精通于更多的MVC之类的模式,并且在我从事游戏编程时一直牢牢记住这种思维方式。 我想做一些类似抽象游戏的事情,例如,通过一个游戏板类,其中包含一个图块网格的数据,每个图块类的实例都包含属性。我可以赋予我的绘制循环访问权,并让它根据游戏板上每个图块的属性来绘制游戏板,但是我不知道确切的动画应该去哪里。据我所知,动画位于抽象的游戏逻辑(模型)和绘制循环(视图)之间。以我的MVC思维方式,尝试确定动画实际上应该去哪里令人沮丧。它会像模型一样具有大量与之关联的数据,但似乎需要与绘制循环紧密结合,以具有诸如帧独立动画之类的功能。 如何摆脱这种思维模式,开始思考对游戏更有意义的模式?

4
像Source这样的Engine如何处理实体?
在Source引擎上(它的前身是goldsrc,quake),游戏对象分为两种:世界和实体。世界是地图的几何形状,实体是播放器,粒子,声音,乐谱等(对于Source Engine)。 每个实体都有一个思考功能,该功能执行该实体的所有逻辑。 因此,如果需要处理的所有内容都来自具有think函数的基类,则游戏引擎可以将所有内容存储在列表中,并在每一帧上循环遍历并调用该函数。 乍一看,这个想法是合理的,但是如果游戏中有很多实体,它可能会占用太多资源。 那么,像Source这样的引擎如何处理(处理,更新,绘制等)游戏对象?

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.