关于炉石传说的NGUI问题

前几天，将炉石传说的开场动画搬了上去。看实现界面。

感觉这个人物还是很性感的==！！

播放动画之后便是切换到主界面

1、在NGUI插件下打开prefabs Toolsbar.

2、将prefabs Toolsbar的background添加

3、删除backgroundController

4、找到背景图片之后右键NGUI，创建图集制作

5、在hierarchy面板中选定UIroot之后在scene中右键创建精灵。

6、在图集的预制体上update/add logo的图片。

注释：sprite图集里面的图片有很多，要在属性面板里面找到自己想要的图片。。单击sprite图片进行选择

7、logo的变化右键logo TweenScale在两者变化之间存在非活性离子剂（曲线调节 addkey）

8、实现添加文字（UIRoot中createLable Alpha透明度的动画（文字））

9、logo结束之后又onfinished监听器，在logo动画结束之后播放点击开始notify通告通知（通知什么时候开始）

10、在movie结束后播放logo

总结：详见NGUI的制作

时间： 2024-10-07 05:28:24

关于炉石传说的NGUI问题的相关文章

炉石传说JJC英雄简评 && JJC combo收集：Ver 1.0

? 1 2 3 4 5 6 7 /*----------------------------------------------------------------------------- * author:Rainboy and his GL 南柯CHY * wirte date:2014-04-29 * # LastUpdated: 2014-04-29 15:42 * ? Copyright 2014 Rainboy and his GL 南柯CHY. All Rights

CCF - 201609-3 - 炉石传说

问题描述试题编号: 201609-3 试题名称: 炉石传说时间限制: 1.0s 内存限制: 256.0MB 问题描述: 问题描述 <炉石传说:魔兽英雄传>(Hearthstone: Heroes of Warcraft,简称炉石传说)是暴雪娱乐开发的一款集换式卡牌游戏(如下图所示).游戏在一个战斗棋盘上进行,由两名玩家轮流进行操作,本题所使用的炉石传说游戏的简化规则如下: * 玩家会控制一些角色,每个角色有自己的生命值和攻击力.当生命值小于等于 0 时,该角色死亡.角色分为英雄和随从. *

CCF2016093炉石传说（C语言版）

问题描述 <炉石传说:魔兽英雄传>(Hearthstone: Heroes of Warcraft,简称炉石传说)是暴雪娱乐开发的一款集换式卡牌游戏(如下图所示).游戏在一个战斗棋盘上进行,由两名玩家轮流进行操作,本题所使用的炉石传说游戏的简化规则如下: * 玩家会控制一些角色,每个角色有自己的生命值和攻击力.当生命值小于等于 0 时,该角色死亡.角色分为英雄和随从. * 玩家各控制一个英雄,游戏开始时,英雄的生命值为 30,攻击力为 0.当英雄死亡时,游戏结束,英雄未死亡的一方获胜. * 玩

《炉石传说》建筑设计欣赏(6)：卡&amp;在执行数据时，组织能力

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

借鉴炉石传说的战棋游戏《DarkWar》

<炉石传说>是现在很火的休闲对战游戏,本人也非常喜欢玩,玩的时候经常想能不能把炉石的这些元素融入到战棋类游戏中,于是思索良久,又恰逢游戏蛮牛开展第三届蛮牛杯游戏开发大赛,于是用Unity3D制作了这款游戏. 至于为什么叫DarkWar,那是因为一开始准备做成暗黑风格的,残酷的现实告诉我我不适合谈风格……游戏没有完全做好,素材还都是东拼西凑的,音效也就寥寥数个,因为要参加比赛只好先发出来了,正好有喜欢的玩家可以一起探讨下,欢迎加群:330838373.安卓版apk下载地址:http://yun.

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

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

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

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

关于炉石传说AI

一直想做一个炉石传说自动出牌AI,感谢yangyuan在GITHUB上分享的hearthrock(https://github.com/yangyuan/hearthrock),让我不至于毫无头绪.目前,hearthrock(近两年前的项目,作者已不更新)的ai部分代码已经基本读完,该AI智能程度较低,基本就是有什么牌出什么牌,基本达不到要求.苦思冥想之余下载了德国人制作的Hearthbuddy,意外发现程序文件夹中带有AI功能源码且是C#的!量很大,得慢慢吃.

炉石传说 C# 开发笔记（续）

炉石传说山寨的工作一直在进行着,在开发过程中深深体会到,对于业务的理解和整个程序的架构的整理远比开发难得多. 在开发过程中,如果你的模型不合理,不准确,很有可能造成代码的混乱,冗余,难以维护和扩展性比较差等问题. 当然,除去领域专家之外,很少人对于一个新的事物可以在一开始就把握住整个核心业务. 接下来讲讲整个程序的构造: Card类库:将整个业务逻辑封装在里面,包括了服务器和客户端的通信逻辑.通信协议的编码和解码.现在是为了炉石定制的,以后想改写成更加通用的. CardHelper:一个辅助程序