《炉石传说》架构设计赏析(5):卡牌&技能的静态数据组织

经过前面几次的尝试,我们对炉石的代码已经不陌生了。除了网络机制还没有了解以外,本机的逻辑已经比较熟悉了。

接下来继续向暴雪最NB的技能系统进发,我们的目标是:

  • 分析技能的静态数据描述;
  • 分析技能的运行时数据、逻辑组织;

这篇笔记主要记录对其分析静态数据。

静态数据组织

卡牌数据

  • 卡牌的基本数据对于的AssetFamily为:AssetFamily.CardXML;
  • 数据对于的资源包为“cardxml0.unity3d”;
  • 资源包中的资源类型为:TextAsset;
  • 资源加载使用的接口为:AssetLoader:LoadCardXml();
  • 运行时对应的数据类型为:EntityDef;
  • xml文件中保存有多个Entity对象数据,具体数据例如:
<Entity version="2" CardID="CS1_042">
    <Tag name="CardName" enumID="185" type="String">闪金镇步兵</Tag>
    <Tag name="CardSet" enumID="183" type="CardSet" value="2" />
    <Tag name="CardType" enumID="202" type="CardType" value="4" />
    <Tag name="Faction" enumID="201" type="Faction" value="2" />
    <Tag name="Rarity" enumID="203" type="Rarity" value="1" />
    <Tag name="Cost" enumID="48" type="Number" value="1" />
    <Tag name="Atk" enumID="47" type="Number" value="1" />
    <Tag name="Health" enumID="45" type="Number" value="2" />
    <Tag name="AttackVisualType" enumID="251" type="AttackVisualType" value="1" />
    <Tag name="CardTextInHand" enumID="184" type="String"><b>嘲讽</b></Tag>
    <Tag name="DevState" enumID="268" type="DevState" value="2" />
    <Tag name="Collectible" enumID="321" type="Bool" value="1" />
    <Tag name="EnchantmentBirthVisual" enumID="330" type="EnchantmentVisualType" value="0" />
    <Tag name="EnchantmentIdleVisual" enumID="331" type="EnchantmentVisualType" value="0" />
    <Tag name="ArtistName" enumID="342" type="String">Donato Giancola</Tag>
    <Tag name="HowToGetThisGoldCard" enumID="365" type="String">圣骑士达到57级后解锁。</Tag>
    <Tag name="FlavorText" enumID="351" type="String">如果闪金镇都是由1/2的步兵把守的话,那它早在多年以前就被毁了。</Tag>
    <Tag name="Taunt" enumID="190" type="Bool" value="1" />
    <Power definition="54e57583-ce5c-46e3-899a-39bd2181468d" />
  </Entity>

卡牌实体

  • 卡牌实体对象对应的AssetFamily为:AssetFamily.CardPrefab;
  • 数据对应的资源包为“cards?.unity3d”,目前共有4个;
  • 资源包中的资源类型为:Prefab;
  • 资源加载对应的接口为:AssetLoader:LoadCardPrefab();
  • 卡牌资源使用CardID进行索引,例如“闪金镇步兵”对应“CardID="CS1_042"”;
  • Prefab中的GameObject主要包含:Transform、Material、CardDef,这三个Component;
  • CardDef有很多CustomEditField,主要分为以下几类:
    • EditType.SOUND_PREFAB;
    • Material,主要是Portrait--头像;
    • EditType.SPELL,其实是string类型,保存的是Spell对象的资源路径;

技能对象

  • 技能对象对应的AssetFamily为:AssetFamily.Spell;
  • 数据对应的资源包为“spells?.unity3d”,目前共有3个;
  • 资源包中的资源类型为:Prefab;
  • 资源加载对应的接口为:AssetLoader:LoadSpell();
  • 卡牌通过CardDef中指定相关技能资源的路径;
  • Prefab中的GameObject主要包含:AudioClip、AudioSource、Material、ParticleSystem、ParticleSystemRenderer、Transform等组件;
  • 涉及到的脚本主要有:PlayerMaker相关的类,Spell及其派生类、SoundDef;

    我们看到Spell有很多的派生类,这里用到了一个小技巧:GetComponent()是可以把基类作为参数来获得子类对象的。例如,一个对象绑定了ArmorSpell对象,而ArmorSpell是Spell的派生类,那么gameObject.GetComponent<Spell>()是可以获得这个ArmorSpell对象的。

总结一下:

卡牌和技能相关的数据主要包括以上三种,其中EntityDef是使用“策划填表”或者类似的方式,而且卡牌和技能资源,则使用Unity编辑成Pefab。技能对象中用到了PlayerMaker插件。

本次分析涉及到的类,请详见下图。

时间: 2024-10-11 12:20:16

《炉石传说》架构设计赏析(5):卡牌&技能的静态数据组织的相关文章

《炉石传说》架构设计赏析(6):卡牌&amp;技能数据的运行时组织

前一篇文章我们看到了<炉石传说>的核心卡牌数据的存储,今天我们继续探索卡牌&技能. 主要的类 通过之前的分析,卡牌&技能涉及到几个类体系:Entity,Actor,Card,Spell,令人十分困惑,特别是前两者.在这里先略带武断的说一下这几个类的基本定位: Entity主要用来做网络数据同步用的: Actor主要处理客户端的渲染对象的控制,作为Component挂载在资源对象上: Spell是技能Prefab挂载的脚本: Card是卡牌Prefab挂载的脚本,在运行时处于中心

炉石传说 C# 设计文档(序)

经过3个月的开发,有很多感触. 以前一直以为技术是开发成败的第一因素,现在发现,等到你代码写的时间够长,经验够丰富,什么功能都能随手完成,对于业务的分析能力变成了第一位. 炉石山寨版的BS版本用到的HTML5的SVG,我看了一个下午的教程,借鉴以前GUI+和HTML的经验,很快就能写点东西出来了. WebSocket,Github上找了一个开源的C#项目,通讯这块也是几个小时就搞定了.Javascript不是很熟悉,当时闭包这样的一些概念也算听说过,Js也是无障碍就写成了. 整个项目的技术壁垒其

《炉石传说》架构设计赏析(4):Asset管理

欢迎转载,请注明作者[燕良@游戏开发]及原文地址:http://blog.csdn.net/neil3d/article/details/39580197 另外,欢迎大家来我的QQ群交流各种游戏引擎相关的技术:游戏引擎能吃吗(264656505) 话说,经过这段时间的学习和摸索,对于Unity3D的开发思路已经基本清晰了.唯独还剩下一个AssetBundle机制还没有搞透,这个涉及到前期项目的资源规划.资源管理代码的写法,以及自动更新机制的实现. 所以,还是想先把游戏逻辑的进一步分析押后,先来看

《炉石传说》架构设计赏析(1):游戏启动流程

前些天看新闻,Unity Awards两项大奖颁给了暴雪的<炉石传说>,这真是对Unity一个再好不过的宣传了--你看,暴雪都开始用Unity了.大家都知道,目前Unity发布的游戏大多都没有对程序集进行混淆.加密,所以作为一个炉石的玩家&Unity的初学者,自然不能错过这个机会.让我们好好看一下暴雪的代码吧. 炉石传说的游戏内容的非常丰富多彩,所以我花了一些时间分析了其程序集,将一些设计思路记录下来,与大家分析.欢迎各路高手拍砖,欢迎转载,请注明出处:燕良@游戏开发,http://b

cocos2d-x 3.3 之卡牌设计 NO.3 卡牌移动

上次说了如何播放卡牌翻转的动画,卡牌翻到正面后,就需要让玩家将卡牌拖拽至出场区域或者墓地区域了. 这里重复一下之前的内容: 1.重载触控函数: virtual bool onTouchBegan(Touch* touch, Event* event); virtual void onTouchMoved(Touch* touch, Event* event); virtual void onTouchEnded(Touch* touch, Event* event); 2.在init里添加: /

《炉石传说》架构设计赏析(3):Gameplay初探

经过前面两篇文章的分析,我们对炉石的代码已经不陌生了,接下来我初步尝试分析其游戏逻辑代码. 欢迎转载,请注明作者[燕良@游戏开发]及原文地址:http://blog.csdn.net/neil3d/article/details/39453291 经过前面的分析,我们已经找到了两个关键的类Gameplay和GameState(当然还有我最感兴趣的Spell和SpellController,这两个还要在后面分析). 首先我们看一下Gameplay这个类的Awake方法,它完成的主要工作是: 调用"

《炉石传说》架构设计赏析(2):Scene管理

上篇文章我们分析到SceneMgr处理了Scene的加载工作,今天我们主要分析一下炉石这款游戏中一共有哪些Scene,他们各自负责什么,以及它内部的逻辑.UI的处理方式. 在正式开始之前,我来对前文中提到的Scene切换再做一些补充分析.前文中我们看到SceneMgr是调用了" Application.LoadLevelAdditiveAsync(this.sceneName);",那内存中的东西岂不是越搞越多吗?我们再仔细看一下SceneMgr:SwitchMode()函数,它是一个

《炉石传说》架构设计赏析(7):使用Google.ProtocolBuffers处理网络消息

这段时间琢磨了一下Unity3D网络游戏开发中的网络消息处理.网络游戏的服务端一般都是自主开发的,所以对应的网络消息处理也要自己开发.客户端/服务端之间的消息传到目前使用JSON和Google.ProtocolBuffers是两种常见的做法.打开炉石的代码看了看它的处理方式,感觉代码写的还是很好的,把它的思路分析一下,与大家分享. 整体机制描述 我们想要达到的目标大概是这样的: 有N个网络消息,每个消息对应一个Proto中的message描述: 每个消息对应一个数字ID: 底层在收到消息是,将其

TCG卡牌游戏研究:《炉石战记:魔兽英雄传》所做的改变

转自:http://www.gameres.com/665306.html TCG演进史 说到卡牌游戏,大家会联想到什么呢? 是历史悠久的扑克牌.风靡全球的<MTG 魔法风云会>与<游戏王>.结合数位与现实的<三国志大战>.或是在手机上掀起收集热潮的<龙族拼图>和<百万亚瑟王>? 卡牌游戏这个统称,其内容可以跟各式各样的玩法结合,而暴风雪新推出的<炉石战记>(以下简称炉石)所选择的玩法,是让玩家自行组牌.进行对战的「集换式卡牌游戏」(