我有一些关于游戏编程抽象的问题,请高手中的高手来解答下?

1、cocos2dx 3.x的事件分发系统能否支持大量数据、密集的事件分发?有没有效率上的瓶颈?极限是多少?

产生这个问题是因为我最近看了《星际2》的银河编辑器里“演算体(Actor)”的概念,我在想这种密集的信息分发,如果用cocos2dx的事件分发系统实现,感觉会出现效率上的问题。

这应该称之为全局分发器。

2、一个集合内部如何实现小范围的事件分发?

省事的办法就是利用cocos2dx自带的eventDiapather,集合的每个元素都保有这个分发器。但是还是感觉太“大”了点,要么用简化的观察者模式自己做个分发器。

这应该叫做局部分发器。

3、有没有更优雅的事件分发器实现,我总是感觉cocos2dx 3.x的分发器传递数据有点不太“优雅”,void*

4、我最近想实现rpg游戏的技能系统,就研究了下银河编辑器,想通过数据驱动的方式实现技能配置组合,我感觉这个演算体就是非常重要的概念,能控制一个技能从释放、到播放动画、再到伤害计算(伤害计算都可以抽象成一个behavior)。我也参考了网上的一些设计,硬伤就是硬编码、耦合。我对“演算体的抽象”在理解上有没有什么错误和误解,有研究过的朋友帮我解答一下?

我找不到比较合适的论坛,就找个地方发一下,能有同好互相交流一下。

有点像逆向工程的味道了。我找到了一篇文章,银河编辑器Actor

这个Actor是组件的想法设计的。假如里面包含了各种其它节点的引用。就不用考虑效率问题了。用空间换时间。剩下的就是写反射配置。

为啥我还会疑惑?主要还是效率问题,像《星际2》这种,每一个单位都有一系列Actor的副本。如果用cocos事件分发的方式来做,肯定会出效率问题。这个Actor肯定有其它密集算法来控制的,而且我查阅一些资料Actor的出现是为了减少网络数据传输。所以我不懂啊,就想问问,有没有经验的大神点播下,给个文献博客参考下也好。

根本的疑惑就是Actor里的“消息传递”机制,我想用cocos2dx 3.x的事件分发来做,能省很多事,但是大概率会有效率问题。

Actor可以抽象为一系列trigger的集合,每个trigger侦听一个event,当event发生时检查condition,符合condition就执行behavior,这个behavior也是个抽象,可以是调用controller播放动画、伤害计算,也可以是dispatchEvent。Actor就是一个消息的集合体,可以通过配置文件解决代码链接问题,就像一个“桥”一样,我只要写反射读取xml文件就成。

很简单,对吧,平时设计游戏的时候,不用抽象成Actor,直接用cocos2dx的事件侦听就解决了。但是这是《星际2》,每个单位都有好几Actor,每个单位身上还有一些附加单位,这些附加单位也有Actor,一场对战有400个单位,那这个消息传递,怎么做?再考虑网络对战呢?(我不懂网络方面的知识)

Description

Actors are the the nerve-cells of the StarCraft II engine. They can operate alone or be attached to each other. When you open the Actors tab in the data editor you will see a list of all the objects (visuals, sounds, etc.) that can be displayed on the map.

The StarCraft II engine is component based, as opposed to class based. Actors are one of the most basic components in this system. As a result they are a bit abstract. An example of a class based engine is Unreal Engine, while Unity is an example of a component based engine. Most modern game engines are component based.

Hints

  • Actors are used to attach models to each other.
  • Actors regulate how entities move around, rotates and flies.
  • Actors recieve and send death messages.
  • Actors can be made to listen to surrounding events in the game.
  • Actors can be ignorant about what is going on in the rest of the game.
  • Actors decide which animation the models should be playing.
  • Actors can be very simple or very complex.
  • Actors can destroy themselves.
  • Actors decide how the units attached to it should respond to physics.
  • Actors decide how large the footprint of the doodad should be.
  • Doodads, units, missiles, decals and beams are all actors with different properties and models attached to them.
  • Actors have similar capabilities as triggers, since they have events that trigger actions in responses to the event.

知识面不广,我这两天找到可能的解决方式:

1、星际2的Actor应该是“Actor编程模型”,解决高并发分布式系统出现的。
2、关于邻近单位的事件分发,可能是用十字链表,灯塔(或者叫空间分区)等AOI算法,又或者蜂群算法(当然我都没实现过:grin:)。这样一个单位分发临近事件的时候只要遍历邻近单位就行了。比注册灵活多了。又或者根据Actor编程模型,实现了一个支持多线程的线程池的事件分发系统。

我只是简单思考一下星际2的一些设计思路。望大佬轻喷,等我实现了,我就给你们点color see see。

也许事件分发效率没你想象的低,你可以写个简单的demo试试呀。每帧发送N个事件给N个实体对象,看看有没有瓶颈。

多写代码。。。再思考
暴雪的代码科技含量比国内领先好多年,你没相当的开发经验,根本理解不了。国内也没有相关的项目给你练手
但是这个和星际1比没什么高大上的,只是换了个设计模式。随便用什么设计模式写,400个单位都是小儿科,主要瓶颈是团体AI,动态寻路和渲染。这方面国内经验少,国内只有通用的氪金游戏编程,JPS寻路。D*的资料都搜不到