微信小游戏

创建于:2017-12-28

创建人: MotionWalk Studios

69 信息 663 成员
关于微信小游戏的内容
寻求有想法的程序或技术,我们是一个美术小团队
jpeng0725 2021-04-21

假如你有团队或者好的想法,而且目前是缺美术这块,可以联系我,我这边有3-5个美术人员,2D和3D模块基本没问题,动作特效也有。我个人是全职,假如你希望我们只是产出,我们可以提供产出,若你想让我们也提一些对项目本身的建议和想法 我们也可以提供,但还是以你为主导,我这边可以远程办公,也可以驻场(上海),只要对项目本身有益的地方,我这边可以尽量满足。我们不是外包,但合作模式偏外包,其实就是一个共享移动美术,愿意结交一些志同道合的朋友,有需要可以留言 qq:362862631

一款已上线的制作中游戏想要找个美术同学帮忙重新设计画面表现
精灵之息 2021-02-28

我自己在制作一款微信小游戏《精灵之息》
目前主体框架和内容已经制作好了,但是目前画面表现不太理想,想找个美术同学帮忙重新设计一下整个游戏的画面表现,合适的话也希望可以长期合作。
联系方式:邮箱1056583020@qq.com

Image title

Image title

Image title









如何10分钟做一个Flappy Bird
stack 2020-12-10

我们来看一个非常简单的游戏,FlappyBird。

Image title

一个当年非常火的游戏,光凭Banner广告就赚了几百万美元。

玩法很简单,这里有一个复刻版

Image title

就是一个小鸟用手指点屏幕控制,穿过一些柱子。

Image title

我们整理下游戏逻辑:

1. 整个场景仅有,背景,小鸟,柱子,分数。其中背景是循环滚动。

2. 小鸟通过点击屏幕可以向上飞,不点击会自由落体。

3. 柱子的间隔和开口都是随机的,以恒定速度向左运动。

4. 每当小鸟通过柱子,会增加分数,且会播放声音。

5. 小鸟飞出屏幕或者撞到柱子则游戏结束。

相当简单,我们来看看如何用小游戏开发工具来实现。完整的项目在这里,已经开源。地址为

https://gamemaker.weixin.qq.com/#/game?game_id=lbODIzZGRjYjAtYjcxNC00MzQwLWE4MzktYmVhM2YyNzAzM2M5

Image title

点改编,可以看见完整源码。

背景

素材大家可以去直接搜索,也有专门的素材网站,我这里的背景是直接百度搜索的。大家也可以换成自己喜欢的背景,注意最好是可以循环的。

Image title

然后需要让这个背景动起来。在层级管理面板直接选中背景

Image title

在右边的图层面板里面,点 编辑背景-》从素材库添加,上传这张背景图,背景就换过来了。再点下管理行为,添加 循环滚动 插件。通过自动移动可以让背景滚动,但为了有更好的可控制性,我们用代码来实现。

Image title

选中背景,添加事件,当场景启动时。

Image title

180度就是向左移动。

通知是一种可以在不同的精灵之间通讯的一种机制,一般游戏都会有 开始,结束,这是一个全局事件,比如很多游戏都会有一个Start按钮,当用户点击这个按钮的时候,很多逻辑才会开始工作。这里先不做Start的逻辑,但还是先发一个事件。

然后是不停的执行移动。效果就是这样的

Image title

小鸟

接下来我们需要找到一只合适的鸟。我在这里找到了一只鸟。一些游戏素材,一个动画并不是一个GIF,而是一堆序列帧,按一定规律命名的一堆文件。现在我们的工具还不能支持直接上传GIF,但支持序列帧,上传以后会生成一个动图。

Image title

小鸟需要有两个逻辑,一个是点击屏幕需要向上飞,一个是不操作的时候会往下掉。这里用物理引擎做最简单,看代码。

Image title

就这么简单,当然你需要在小鸟的属性面板里面先添加“物理”的行为。

点击的这句话,意思是当手指点击屏幕的时候,给这个小鸟一个向上的力。

下面这个逻辑的意思是设置一个默认的重力,大家可以随意修改这里的数值,会有不一样的效果。

柱子

接下来到另一个关键逻辑,柱子。

这种横版的游戏一般就两种方式,一种是场景有长度的,每个地方都是手动摆放的,比如超级玛丽。另一种就是角色没有动,其实是柱子在动。在这个游戏里面,其实就是柱子在动的,因为柱子的速度和背景一样,看起来是鸟在动。

我在这里找到了柱子,导入以后,实际上的场景是这样的:

Image title

其中有点小技巧。这个柱子不是绿色的,我使用了颜色叠加的效果,让柱子变成了绿色,上下两个柱子是因为其中一个使用了镜像。

Image title

柱子还有一个逻辑,就是两个柱子的开口位置是不确定的,随机的。但两个柱子的开口大小是固定的,所以这里又有一个小技巧。我把两个柱子变成了一个Group,这里称为容器,选中两个柱子,点右键,就可以组成一个容器。我只需要调整这个容器的Y 坐标就可以了。看代码

Image title

我们先看最后一个事件,当收到一个 start 的通知的时候。就把这两个管子不断向左运动。而且这个速度比背景大一倍,看起来就会有一个视差的效果。

中间的逻辑是,如果发现自己 X 坐标小于-500,也就是跑出了屏幕的左边,则发一个reset_pip的通知。这里完整的逻辑是,屏幕里面仅会出现一对柱子,每次从右往左移动,离开屏幕以后重新设置自己的Y坐标,这样看起来就是无限且随机高度的柱子了。当收到 reset_pip 通知的时候,这里使用了一个函数。函数在积木面板里面可以新建,创建好以后在资源管理器里面。

Image title

我们看以下函数的具体内容

Image title

首先把自己的X坐标放到500,也就是放屏幕的右边。然后把Y坐标设置到 [-350, 350] 之间。就可以实现随机高度的柱子了。

我们现在来运行下,看看效果。

Image title

分数

游戏肯定需要分数,我们在素材库里面的数字分类下,可以找到一些可用的数字类型。

Image title

数字的逻辑比较简单,就是当小鸟越过柱子的时候,分数加1。我们来看看逻辑

Image title

先看下面,当小鸟的X坐标,大于了容器(柱子)的X坐标,即小鸟飞过了柱子。则把score增加1。注意这里新增了两个变量一个是小鸟自己的私有变量fly_over,一个是全局变量score。

全局变量比较好理解,就是用来计数的,然后设置给文字。这个私有变量fly_over其实是限制这个逻辑仅执行一次的。因为这种判断条件型的事件,是每次都执行的,当小鸟飞过柱子的以后,小鸟的 X 就会一直大于柱子的 X,这个事件会一直触发,但我们只需要这个逻辑执行一次,所以使用一个变量,防止重复执行。然后看第一个事件,当收到 reset_pip 的通知的时候,需要把fly_over重新设置为0,否则第二个柱子就不会继续执行这个逻辑了。我们来看下效果

Image title

到这里,Flappy Bird的基本逻辑就已经完成了。如果要更好的手感,可能需要更细致的逻辑和参数调整。欢迎大家在此基础上进行改编和再创作。

微信小游戏开发工具地址:http://gm.weixin.qq.com

本示例项目的地址:https://gamemaker.weixin.qq.com/#/game?game_id=lbODIzZGRjYjAtYjcxNC00MzQwLWE4MzktYmVhM2YyNzAzM2M5

相关文章:微信小游戏可视化开发工具

(转发自:原日志地址
露易丝佣兵团 安卓 版发布啦

Image title


露易丝佣兵团在微信上得到了一些玩家的反馈,于是自己尝试能不能把它做成安卓版

不过模拟器和浏览器在龙骨上差别非常巨大,所以不得不复制粘贴一份改了好多好多代码,然后加新功能两边同步...(好麻烦鸭)

虽然很折腾,但是游戏里加了很多新内容:

比如,炼金术(顺便恶搞了下英雄无敌的鹰眼术):

Image titleImage title

加了宠物(虽然目前只有猫咪)

Image title


还有试炼关卡

Image title

还增加了魔石和炼金素材,修改了商店的规则,还有佣兵的收藏品:

Image title

还增加了很多新的随机事件.


还有很多的想法还不知道要怎么做,不过我会坚持更新这个游戏的!




(转发自:原日志地址
微信小游戏可视化制作工具想法很棒,而且还是个web,可是适合做复杂的游戏吗?
00700 2020-10-12

这个工具的想法和动机是很棒,看了视频教程就心动了,但用纯可视化工具来做复杂的游戏是否合适呢?

另外,这个工具不禁让我回想起当年 ActionScript2.0 时代的 Flash IDE。AS2的Flash IDE应该是最能让非程序员出身的人可以快速入手把自己的创意实现出来了。AS3由于更偏向于程序员,所以不适合艺术家们创作。AS2的Flash IDE感觉是艺术家和程序员的完美临界结合。

有真实体验过的同学吗?

附链接:小游戏可视化制作工具 https://gamemaker.weixin.qq.com

最佳 Game Jam 游戏之一《消费主义》开发总结!
CocosEngine 2020-09-27

今年由于疫情原因,CiGA Game Jam 改为线上进行,在经过两个月的报名,与两个月的漫长评审期之后,主办方最终从 330 款游戏 DEMO 中选出了 10 款入围今年最佳 Game Jam。Cocos 引擎团队5位同学 Santy、YunHsiao、ArthurWang、jiaxin、gameall3d 自发组队,加一位音乐外援妹子 SHJRI 一起参加了这场极限开发活动,很幸运,作品《消费主义》成功入围!这次我们联系6位成员,针对开发历程进行了专访!

Image titleCiGA Game Jam 是 CiGA 旗下最大的华人游戏圈线下 Game Jam 活动,是对开发者的一种极限挑战,在 48 个小时内放下一切束缚,通过一个周末的时间唤醒游戏的创意理念同时体验游戏的开发过程,包括编程、互动设计、叙事探索、以及美术设计。听起来很疯狂,但是他们做到了!

游戏简介:

《消费主义》游戏原型采用 Cocos Creator 3D 开发,建立消费主义模型,扮演资本家通过价格调控、广告等手段,贩卖产品,榨取消费者利益。当资本家掠夺殆尽,空留一地消费者陷入迷茫。

《消费主义》原版展示视频

思路简介:

这次的思路是希望能让玩家通过第一人称的生产者角度,来理解和体会消费主义背后的商业机器,和每个个体扮演的角色。


专访总结

能向我们的读者介绍一下成员及分工吗?

YunHsiao:Santy 是我们 Cocos Creator 2D 组的,负责资源加载系统等;ArthurWang、jiaxin、gameall3d 和我都是 Cocos Creator 3D 组的,负责编辑器开发、引擎开发等。

Game Jam 中我们其实没有固定的分工,我们都是一起参与,碰撞灵感;到了实现玩法时,引擎都再熟悉不过,任务拆分相对非常自然。每个人都全力参与其中,以模块为单位,比如相机控制、场景生成、抽象逻辑、UI、模型资源对接等,在一个 git 仓库内大家共同协作开发。

团队合照


刚看到题目时是什么感觉呢?

YunHsiao:题目发布时我们还没下班,看着直播放出题图就开始明目张胆地划水,一头雾水有一句没一句地开始解读。

gameall3d:当时真的是好震惊,这个比赛的题目都是这么抽象的吗?不过想想也是,越是抽象的题目,给开发者发挥的空间也就越大,但这么抽象的题确实很难让人在短时间内直接想出一个点子。

图片为 2020 Game Jam 题目

图片为 2020 Game Jam 题目


如何解读题图的呢?

YunHsiao:讨论了许久后有人从满地的快递箱看出了图里讽刺消费主义的味道,我们忽然觉得找到了图的灵魂,所有的细节都有了明确的主题指向(快递是消费品,地面的裂缝是内心的欲望沟壑,墙外的蚂蚁是让人心痒的诱惑等等),开始往这个方向探索,看能做点什么,和这幅画要表达的东西共鸣。

gameall3d:刚开始我们也思考了各种游戏类型,比如地板会塌陷的多人大乱斗游戏、蚂蚁塔防游戏、密室逃脱等等,但觉得都不够理想,经过一晚上的讨论,我们决定做一个展示商人如何通过各种手段极限压榨消费者的游戏。

YunHsiao:与其展示一个个体在整个环境下的挣扎,让玩家去勉强共情,不如直接把屠刀放到玩家手中,真正体会一把收割的角色,从收割过程中去理解资本机器的运作,进而在生活中不再被同样的手段迷惑


48 小时的压力下,时间安排是否会有困难呢?

ArthurWang:队里有多次参加过的老手,所以我们的时间安排其实不算特别紧迫,当然还是没少肝。在题目出了之后我已经记不清我们提出了多少点子和方向了,最后基本确定了这个方向后还在不停论证表现形式和可行性之类的,总算在第一天晚上确定了雏形。


这么多想法碰撞,如何做取舍呢?

gameall3d:在制作过程中其实会有很多新的想法冒出来,但是因为时间问题,我们会收敛着做需求,将我们核心的玩法打磨好,而不是一直扩展系统。

比如周六晚上我想了一些改进,例如把核心玩法改成通过广告手段让一群人的喜好一样,然后他们就可以去团购同一件物品等等,但是这就相当于要抛弃周六一天的部分工作,很有可能得不尝失,所以我们选择在原来的玩法上继续深入。

ArthurWang:Game Jam 能给每个人足够的自由,这是我们共同的作品,每个人都可以把自己的想法加进去,但有时候确实是因为时间原因不得不否掉一些新的想法。

我们在离提交还有 4 个小时的时候还有新的点子,但冷静下来觉着肯定完成不了了,所以只好放弃,但一些小的设计还是尽可能地加到了作品中,包括一些小的不明确展示给玩家的小障碍,也包括我们平衡过的数值,这些都让这个作品略微完整了一些。


能否介绍下《消费主义》最终的玩法设计呢?

gameall3d:游戏的核心玩法是:玩家扮演一个商人,利用手头的资源让整个地图的人都购买你家的商品,你就成功了。商人有初始资金,需要使用它来进货,然后定一个价格来卖出,而商品需要广告才能吸引消费者来购买,可以使用的广告手段有“发传单”、“广告牌”、“飞艇”三种,对应了不同的价格和效果,需要玩家去权衡使用。

游戏广告效果

游戏广告效果


在音乐上是如何考量的呢?

SHJRI:考虑到游戏的机制会因玩家的操作而在画面和数值上加减人数,所以音乐随着游戏的进程,比如人数的递增,加入新的元素。元素来自于画面和内容,比如鼓的部分以 beatbox 来表现,加以动态音乐的形式,增减轨道来丰富玩家反馈。


如何想到将广告作为《消费主义》的核心设计呢?

YunHsiao:前期尝试时我们也陷入了受限的思路,本质上还是没有摸清楚到底什么才是那个不可再分的,消费主义的最小子集。直到后来深入思索一番后,发现从“欲望”入手,一切似乎都可以变得清晰起来。

我们的时代是自由的。自由意味着每个人都可以追求欲望。这意味着一个巨大的市场,掌控了更多人的欲望,就掌控了更多……资本。

这就引入了广告,广告是一个再完美不过的消费主义具象化的落脚点。广告创造欲望,广告引导欲望,广告升级欲望。

它是我们会一个接一个下单取快递的原因,它像被蚂蚁一般无时无刻不在挠得我们心头犯痒想要更多,它是我们明明已经有了那么多盒子可心中的空洞和裂缝还是越来越大的原因。

消费主义不过如此了。


如何确定作品形态的呢?

YunHsiao:结合我们几个的实际情况,我们的长项是逻辑(同时短板是美术),设计一个相对复杂精巧的系统更接近我们的主场,这正符合资本机器冰冷严谨的运作风格。

引擎更是没理由不用自家的狗粮,所以基础设施的长项是骨骼动画(instancing),加上相对合理数量的粒子和物理,所以我们做的东西,更像一个实时策略类游戏了噢。

实时策略游戏的核心正是系统构建,虽然我们都没有真正专业地做过,但这听起来是一个我们可以尝试搞的东西!


酷,如何构建这个游戏呢?

YunHsiao:我们需要一个模型,一个最纯粹又在直觉上能让人亲近的情景,来让玩家“感受”。

我们把基本元素确定为消费者和产品:消费者在这世界中大量随机分布着,每个消费者都有随机数量的“快乐值”、“欲望值”和“剩余价值”等几个基本属性。

玩家作为生产者,拥有固定的初始资本,决定要在哪里投放产品,尽可能榨取最多的“剩余价值”。

所有的游戏性全都围绕广告开展,消费者也只需要一个“购买欲望”的属性。玩家的任务就是在有限的成本下,平衡出货和广告投放。只有货物没有广告是没有人买的,只有广告没有货物也会为产品带来负面口碑,影响更多人的购买欲望。


游戏的核心点似乎是广告,技术上我们如何实现的呢?

Santy:在原型中我们使用了多个特效表达广告效果,基本是使用模型 + 动画 + 粒子的形式来组织的。Cocos Creator 3D 中的粒子系统除了拥有众多模块之外,还支持多种曲线,所以各种特效实现起来相对简单。

Creator 3D 制作粒子效果

Creator 3D 制作粒子效果


使用 Cocos Creator 3D 极限开发体验如何呢?

Santy:首先 Cocos Creator 3D 对资源的支持很全面,包括网格、材质、动画都可以通过 FBX、GLB 等格式快速导入编辑器中,这对于原型开发非常方便。

在游戏设计中,我们希望场景中能同时显示上千个带动画的人物模型,从而模拟出市场的效果,在不启用 GPU Instancing 时,Drawcall 很容易达到 200 以上,造成性能严重下降。

启用 Instancing 前效果图

启用 Instancing 前效果图


而在启用了 instancing 之后,这一问题被非常轻松地解决掉了,Drawcall 数量降到了个位数,在手机浏览器上也能非常流畅地运行,留给了我们更多的空间去做 GamePlay 方面的发挥。

启用 Instancing 后效果图启用 Instancing 后效果图


极限开发的时间压力下,Cocos Creator3D 有什么独特的优势吗?

Santy:Cocos Creator 3D 保持了 Cocos Creator 的调试风格,在修改场景和代码后,你不需要经历漫长的编译过程,就可以非常方便地使用智能设备进行效果测试。只需要扫一扫编辑器上的二维码即可快速预览效果。

这对于快速原型开发是非常重要的,当我们不确定这是否是我们需要的东西时,快速地测试、讨论、形成正向的反馈系统,促进设计不断地改善,最终确定设计,我们不希望开发中大部分时间是在等待游戏编译。

相较于其他作品,我们的游戏原型,更容易让大家玩起来。得益于 web 的快速分发能力,我们可以使用 Cocos Creator 3D 将游戏发布到 web 平台,并使用 iFrame 嵌入到我们想要嵌入的网页中,玩家不需要下载其他内容,即可开玩。这对于一个游戏原型来说,是非常重要的,越容易接入玩家,则意味着开发者能获得更多的反馈,从而调整自己的设计。

另外,版本的更新也是非常方便的,当更新版本后,只需更新服务器上内容,而所有玩家将获得最新的内容。

总体而言,使用 Cocos Creator 3D 开发游戏原型非常方便与快捷,虽然目前还有部分功能还未集成,例如查看运行时节点树等。但 Cocos Creator 3D 将会越来越完善,成为原型开发的高效工具。


听说大家都是挑灯夜战,肝还好吗?

ArthurWang:要说完全不累是假的,周六那天我大概熬到了凌晨 4 点,最后和队友交流都已经不清醒了才去休息,第二天也是强打精神开发。但看到我们的作品被队友很认真地游玩之后还是很高兴。

那天结束之后感觉几个人都已经完全肝废了,Santy 更是吃着饭睡着了,但看到直播中我们的作品得到的反馈又觉得这一切都值了。


对于成品还满意吗?是否有什么遗憾?

ArthurWang:成品是大家思维火花碰撞的结果,经过不停地迭代,最终的成品其实和我们预先设定的想法已经不是严格一致了,在做的时候不停地有新的想法冒出来,作品本身自己会逐渐成长。

gameall3d:这次的队伍没有美术,所以画面上还是有所欠缺,连个像样的封面都没有,但也因此让我们能更加专注在玩法上进行思考,一群人在一起边思考边制作游戏的体验真的很棒。


结语

以上就是本次的专访内容,能够一起做一些真正想做的游戏,抓住一闪而过的灵感,并使之变成现实,这段过程和感觉都值得铭记,相信这也是 Game Jam 迷人的所在。

很高兴引擎组成员的作品《消费主义》游戏原型,成功提名年度最佳 Game Jam 游戏,获得评委认可,也期待团队取得更好的成绩。感兴趣的童鞋可以点击《消费主义》游戏原型体验喔~

(转发自:原日志地址
寻中度游戏制作人\主策划(最好有数值方面的功底)
TakiChen 2020-09-14

团队成立5年(同时具备2D、3D产品的开发能力),经历过高低起伏,现已处于稳定态势,为了寻求突破和发展,近2年成立休闲产品的项目组,也在其中寻找到该团队合适的出路,今年想重新整合了资源,想成立一个中度游戏的开发,寻求新一轮的春天,急需一位制作人\主策划!

我的联系方式——VX:Taki-C 电话:13641737211

工作职责:

     1,制定产品研发立项提案、核心玩法、研发方向和目,并保证最终产品和这个目标相符合;

     2,负责策划游戏主体架构,游戏主体逻辑规则,以及各大主系统功能策划;

     3,参与具体游戏数值设计、系统设计、关卡设计等

     4,与全体开发团队一同制作完善的项目计划,并保证项目计划的时间、质量和成本控制在有效的范围以内;

     5、根据项目决策,合理计划、分配项目内部策划资源;

     6、把握项目设计和发展方向,发现并及时解决问题。

 

任职要求:

     1,热爱游戏制作,做为制作人主导过至少一款成功上线的游戏产品并且是休闲类产品。 

     2,熟悉手游,对海外移动游戏市场有深入的了解和独到的见解,特别是欧美市场。 

     3,深入理解游戏的体验、交互、生命力、用户周期。并且了解游戏产品的运营机制,有成功休闲游戏开发经验者优先;

     4,有志于并有信心创建一流的手游产品,有强烈的责任心、务实的作风、忘我的热情及创业的精神,能够承受高强度的工作压力。

     5,有想象力、有创意,能拿出不一样得东西。

     6,熟练掌握游戏开发及运营流程,对策划、程序、美术、测试、营销的工作有深刻理解; 

     7,精通把握市场及玩家动态, 合理制定产品规划 ; 

     8, 创新思维,成就导向,产品导向。极其热爱游戏事业,具备创业激情;

 工作地点:上海

露易丝佣兵团 游戏发布咯

经过好久的折腾和摸索,我的游戏终于做完了~

由于游戏没什么名气,需要在小程序里搜索才能搜到

我的qq群:1142732961    欢迎大家一起讨论鸭

(转发自:原日志地址
从零开始的小游戏开发之第三篇 Dragonbones龙骨使用多个图集的办法

这篇文章分享一点我制作游戏时的一点小技巧吧:

Dragonbones龙骨如何在cocos creator 里同时使用多个DragonBonesAtlasAsset图集的办法


这是我现在正在做的游戏视频:

https://www.bilibili.com/video/BV1j5411h7ZY/

我的qq群:1142732961 欢迎一起讨论交流啦


1.Dragonbones 龙骨在cocos creator 里使用多个图集

在学习做龙骨动画时,我发现很多组件是重复的,在小游戏里出现大量重复的素材还是很占包体的,所以我尝试着把重复的东东单独放到一个独立的图集里,龙骨动画则会同时加载两个图集的素材


完整没拆图集的角色

Image title


拆出的通用图集,我把角色通用的部位和所有可替换的衣服和武器抽了出来

Image title

角色拆出自己的图集,我这里只抽出了发型和头饰,表情服装这些都用通用图集的

Image title

合并后在游戏里不同角色的样子(这里我偷懒没换衣服,衣服其实是可以换成图集里其他的)

Image title


1.实现方法

我没有改cocos creator原生的代码逻辑,而是纯用ts脚本来实现出来的

当然我写代码比较业余,里面好多东东写的很临时,没有做封装,我就贴出一下重要的代码和步骤吧,当然如果遇到问题可以随时问我的.

首先,我们拿到要公用的图集,如果这个图集没有被用到最好手动init一次,否则是拿不到龙骨图集里的textures的.

我的逻辑是这样写的:

// 初始化公共贴图
initHeroAtlas(dragonAtlasAsset: dragonBones.DragonBonesAtlasAsset) {
    if (this.heroCommonAtlas != undefined) return
    let heroCommonAtlas = {}
    this.heroCommonAtlas = heroCommonAtlas
    let textureAtlasData = dragonAtlasAsset['_textureAtlasData']
    if (!textureAtlasData) {
        dragonAtlasAsset['init'](dragonBones.CCFactory.getInstance())
        textureAtlasData = dragonAtlasAsset['_textureAtlasData']
    }
    if (!textureAtlasData) return
    let textures = textureAtlasData.textures
    let whiteListTexture = this.whiteListTexture
    for (let i = 0; i < whiteListTexture.length; i++) {
        let name = whiteListTexture[i]
        heroCommonAtlas[name] = textures[name]
    }
    let name = 'empty'
    heroCommonAtlas[name] = textures[name]
}

这样我们获得了一个 heroCommonAtlas 的对象结构,存放图集里的texture ,这个可以用来替换.当然,如果你需要两个以上的图集也没关系,把其他的图集里的texture保存起来就可以了

我们生成的角色贴图只有头发和头饰,其他的东东要从 heroCommonAtlas 里找到,当然你可以写逻辑选择合并时具体使用图集里的哪个武器或者哪件衣服

这是我合并两个图集的逻辑:

// 合并佣兵图集
combineHero(ad: dragonBones.ArmatureDisplay) {
    if (ad == undefined) return
    let dragonAsset = ad.dragonAsset
    let dragonAtlasAsset = ad.dragonAtlasAsset
    if (dragonAsset == undefined || dragonAtlasAsset == undefined) return
    let armature = ad.armature()
    if (armature == undefined) return
    let slots = armature['_slots']
    let whiteListSlot = this.whiteListSlot
    for (let i = 0; i < slots.length; i++) {
        let slot = slots[i]
        if (slot == undefined) continue
        if (this.contain(whiteListSlot, slot.name)) {
            let displayDatas = slot['_displayDatas']
            for (let j = 0; j < displayDatas.length; j++) this._replaceDisplay(displayDatas[j])
            if (this._replaceDisplay(slot['_displayData'])) slot['_updateDisplayData']()
        }
    }
}

这里比较重要的是 更新 displayData 以及最后slot的贴图被更换成功后要手动_updateDisplayData的,否则不会立刻生效的.之所以用更新displayData数据的办法是避免龙骨播放其他动画时把插槽里的贴图给还原掉,索性我们就先让它用从公共图集里借来的texture吧

这里还有个地方要小心就是龙骨的回收,如果你做了回收一定要记得把借来的texture还回去哈,不然龙骨的factory会按照当前的atlas全部回收的,当然公共图集的我们肯定不希望被删掉啦.回收的逻辑我后面会贴出代码,这里贴一下 replaceDisplay 的实现吧:

// 使用佣兵公共贴图
_replaceDisplay(display: dragonBones.DisplayData) {
    let whiteListTexture = this.whiteListTexture
    let texture = display['texture']
    if (texture == undefined) return false
    if (this.contain(whiteListTexture, texture.name)) {
        display['texture'] = this.heroCommonAtlas[texture.name]
        return true
    }
    return false
}

这里就用到前面生成的 heroCommonAtlas 了,其实原理还是很简单的,只是换掉了texture,当然摸索的过程可不这么简单,我尝试了好多种办法,最后觉得这个办法是最安全的了

主要的逻辑就是这些接下来说一下回收龙骨时要注意的东东:

我在替换贴图前把老的texture保存下来,存到一个叫revert的字段里,因为回收的时候要把texture换回去,

我的回收逻辑大致是这个样子.龙骨一些逻辑没有做容错,所以这类偷梁换柱的操作一定要保证彻底还原回去,否则问题会非常难查:

let atlasSearch = this.atlasSearch
let res = atlasSearch[k]
let revert = res['revert'] // 是否有回收需要恢复的
if (revert) {
    let textureAtlasData = res['_textureAtlasData']
    if (textureAtlasData) {
        let textures = textureAtlasData.textures
        let empty = [] // 空的key要删掉,不然龙骨会报错
        for (let i in revert) {
            let o = revert[i]
            textures[i] = o // 用回原来的
            if (o == undefined) empty.push(i)
            else {
                let p = o['parent']
                if (p && p['imagePath'] == 'part_tex.png') {
                    console.log('[ERROR]:', o['name'], i, ' in ', k, ' error!')
                    empty.push(i) // 不回收就不回收,总比报错好
                }
            }
        }
        for (let i = 0; i < empty.length; i++)delete textures[empty[i]];
    }
    res['revert'] = undefined
}
atlasSearch[k] = undefined
cc.loader.releaseRes(k, dragonBones.DragonBonesAtlasAsset)


原理虽然挺简单,代码也不多,但是摸索出这些花掉我好多时间,我之前试过很多种办法,换slot,换display,都会在播动画重置时出现各种问题,最后还是觉得从textureAtlasData里抽出texture换掉最稳最简单,这是我自己摸索出来的,或许有更好更专业的办法吧...

(转发自:原日志地址
从零开始的小游戏开发之第二篇

前一篇日志讲了开始准备开发一个小的游戏我所做的准备,这篇总结一下开始使用cocos遇到的一些对新手不太友好的问题和解决办法吧

稍微录了一下自己游戏的视频,里面好多东东可能还需要改.开头的漫画是因为有人反馈进去就打怪太突然了我花两天画的用来过渡的

https://www.bilibili.com/video/BV1j5411h7ZY

我的qq群:1142732961 欢迎一起讨论交流啦


1.cocos 文本立刻 改变大小尺寸,获取cc.Label新size

根据文字的多少改变按钮宽度是个蛮常见的功能,为了实现这个功能我搜了很多诸如 “强制刷新获取高度”  “Label下一帧才刷新大小”  “改变string更新宽度高度”  这类关键词,给的答案一般是:

label._forceUpdateRenderData(true)

然而我在typescript里真正使用它时却是这个样子的:

Image title

显示的错误是 类型“Label”上不存在属性“_forceUpdateRenderData”。ts(2339)

没错, _forceUpdateRenderData 在 2.3中 标红 报错 不能直接用哦,莫非没有_forceUpdateRenderData这个函数?

之所以这样,原因是cocos creator2.3这个接口并没有导出定义,所以才会变成红色.但这并不影响使用,这样写,就能解决问题了:

        console.log(this.label.node.getContentSize())

        this.label.string = '我是啤啤鸭不卖萌'

        this.label['_forceUpdateRenderData'](true)

        console.log(this.label.node.getContentSize())

当然_forceUpdateRenderData并不是无敌的,我在使用 RESIZE_HEIGHT 的模式时遇到过它计算的结果是错误的,我实在想不出解决的办法,只好 scheduleOnce 在下一帧计算高度.当然绝大多数情况下这个还是能解决问题的


2.updateAlignment重新排版把所有的父节点也重新排版了

当界面或窗口大小发生变化时,一般需要重新适配所有的ccWidgets,比如我的游戏里就有面板的展开和收缩的功能.但是调用 updateAlignment 时它的所有父节点也会被全部重新排版,有的时候这不是我们希望的,尤其是一些游戏里不断改变组件大小位置的情况

如果只想改变自己的布局而不想影响它的父节点,可以试试这个办法:


this.widget.enabled = true


上面这句会刷新cc.Widgets的排版,但不是立即刷新,而是下一帧刷新,而 updateAlignment 是当前帧立即刷新,使用哪种办法可以自己来根据情况权衡


3.屏幕适配,根据屏幕比例或父节点适配改变ui大小尺寸,按固定比例百分比改变尺寸

开始我用的办法很蠢,是用cc.winSize获得屏幕的宽度和高度再乘以百分比来计算,如果在一些 Layout 里这样计算会非常麻烦,直到一次偶然我去次饭鼠标无意中对准了一个位置,肥来后我竟然看到了芥个:

Image title

天鸭,居然是可以输入百分比

Image title

居然藏得这么深?我百度搜了好多文章也没找到的东东居然会出现在这里!谁知道这里还会藏着这种操作.

用百分比可以解决很多烦人的问题,至少不需要写那么多 scheduleOnce 了.

好啦.就写到这里吧,有cocos的问题可以问我,虽然我也还是初学者....

(转发自:原日志地址
从零开始的小游戏开发之第一篇

Image title

哈喽哈喽,大家好,我是啤啤鸭,一个还不太会写代码的cocos初学者.不过呢,几个月前我决定开始尝试完全靠自己做出我人生的第一个小游戏,先给大家看看我这几个月肝出来的一点点成果吧.

我的qq群:1142732961 欢迎一起讨论交流啦

Image title


Image title


Image title


其他角色

Image title

Image title


Image title


Image title


Image title


Image title


Image title

画了一些怪物

Image title

Image title


Image title

Image title

虽然是初学者,但是我之前还是有一点点基础的,因为喜欢玩游戏自学过做一些游戏的mod,为了做出好玩的mod也自学了一点代码和绘画.当然尝试自己做游戏靠这些还差远呢!所以,我想把我开始做游戏的过程,遇到的对新手非常不友好的问题以及进度记录下来,希望能对和我一样想尝试做游戏的人有一丢丢帮助.当然,如果哪里描述的不对或者误导了其他人还请多多指正,我会改掉的,毕竟我不是很专业.但是我会在写东西之前多多查阅一些资料,让我记录下的东东尽可能的准确的!

游戏引擎我选择的是cocos,目标是打算发布微信小游戏.之所以这样选择是因为加过的一个群里有位dalao做过微信小游戏,我想至少用cocos遇到我解决不了的问题还是可以找到人问一问,总比自己一个人从头开始摸索会安心一点.

游戏我打算做挂机类游戏,因为我个人猜测这个大概是最好做的游戏类型了,毕竟我还不是很有信心去尝试复杂的游戏类型.虽然是挂机游戏,我会用心思把它做的很好玩的!

好了,说了这么多东东,还是说一些开发的过程和这几个月的心得吧.

首先,第一天,我下载了Cocos Creator,这是它的官网

https://www.cocos.com/creator

我下载的是几个月前的最新版本,现在打开发现出了很多新版本,更新的好快啊.我现在用的是V2.3.3,也就是四月份的版本,当然用新版本也是没关系的.

Cocos Creator安装还是很简单的,我想应该不会难到谁.不过有个注意事项就是安装路径不要带中文,不然安装后会有问题的.

Image title

安装完成之后是上面这个样子,点开新建空的工程里面一片空白,什么都没有.当时我就不知道接下来我要点什么,要怎么开始做游戏.毕竟这和做mod不太一样,代码和画的画是从无到有的.于是我把这个听起来有点蠢的问题问了一位正在开发steam游戏的个人开发,他给我的建议是:

写一篇文档描述清楚你想做的游戏有哪些内容,然后再把这些内容细化成非常详细的步骤.即使你还不知道这些步骤在cocos里要怎么做,你也可以按照自己的理解大胆的写.写完之后再划掉你认为不是最重要或者可以几个月后慢慢做的内容,将剩下的内容和步骤做成一份清单,按照这份清单一点点做,就没问题了

虽然我很想快快用Cocos做东东,但我还是听了他的建议,写了一份非常不专业的功能清单,这个花掉了我两天的时间,写的时候我习惯性的反复修改写好的内容让它描述得更具体.现在想想,这样做对我还是很有帮助的,因为有了这份清单,我可以很明确的知道要做什么,做这些东西要学什么,毕竟Cocos的功能很多,学完所有功能再开始做游戏是很难坚持下来的.明确自己要做什么,有目的的花时间边学边做既可以让自己更好的掌握学到的,又能让游戏每天都有进展,因为每个步骤分的很细致,学习一个步骤用到的知识可能只用不到一个小时的时间,这样边学边做一点点推进游戏进度,会让自己更有信心.

当然,除了上面建议的内容,我还自己尝试瞎画了几个游戏想做出的界面,虽然和现在已经有点不一样了,但是这对当时度过对游戏开发完全陌生的时期是非常有帮助的:

Image title

Image title

最早写的功能清单在我这几个月的开发摸索中被我不断的修改,补充,删掉完成的功能,现在已经面目全非了,我也就不截图给大家看了.但我还记得我当时写出文档的前几步大致这个亚子:

功能1:做出个大致的游戏界面:

步骤1:做出个游戏背景图,随便找个图就行,只要游戏运行时能看到这张图就ok

步骤2:做出个按钮,只要这个按钮能点就行,具体点了怎么关联到代码后面再研究

步骤3:把这些背景和按钮拼成一个和你画出来的差不多的界面

......

功能x:

步骤x:开始试着画主角,画的差不多能在游戏里看到就行

虽然这些描述给专业的人看可能会觉得非常可笑,但我一步步按照这个清单去做,做出来的就会删除掉,实在不会的就剪切到后面的功能里以后再做.每做完一个步骤删掉其中一项会特别有成就感.我想,如果你打开Cocos一时不知道要做什么,又没耐心看Cocos教程,或者觉得做游戏几天毫无进展,不妨试试我这个办法.

先写到这里,后面我会不断总结Cocos小游戏制作中遇到的各种问题,我认为一个人开始制作游戏的过程不仅是对自己的写代码能力和学习能力的考验,也是对自己的精神力的考验,因为做的过程中经常会忍不住去想:不好玩没人玩怎么办,有些东东我做不到怎么办.有人经过考验做出自己的游戏了,我相信我遇到的问题也一定曾困扰过这些人,虽然他们可能已经记不太清当时是怎么坚持下去的了。

我会坚持更新我的文章的,我的qq群:1142732961  欢迎大家加入一起探讨游戏的开发过程和遇到的困难和心得。我希望我记下的东东或许在以后能帮助到和我一样经历过类似困扰的人,当然也欢迎大家多多指教啦!

(转发自:原日志地址
初创休闲模拟建造小游戏团队求美术大大支援!!
bodawu 2020-07-31

大家好,我们是一个三人独立小团队,目前在开发一款3D休闲自由建造+模拟经营的小游戏,项目目前刚刚完成核心玩法demo,由于经验不足,3d资源缺口巨大,跪求有兴趣或者有资源的美术小伙伴+q勾兑48498581,备注天下太平,不介意兼职接活的大大!!美术偏极简风格佛系卡通,救救孩子!

寻找中小型游戏开发团队,资金支持或游戏收购
YMJolyne 2020-07-23

我是广州小云互娱商务助理陈睿,请各游戏开发团队或个人联系我,愿我们合作愉快

从零开始开发一款类卡牌式游戏——滑稽圣杯战争开发日志4
xdx3000 2020-06-25

在经历了“把脑海中的东东开发出来”的一阵操作之后,我开始得以冷静下来,仔细思考自己到底开发了个啥。

坦白说,刚开发的时候我是抱着试试看的想法,想要尝尝鲜的。有一个模糊的想法,但并没有非常严谨的规划。毕竟我对于从头开发一款游戏还是一无所知的。回头看来,虽然实现了自己的一些想法,但是整体没有什么亮点,显得非常平庸。坦白说,抛开题材的噱头,如果是我自己作为一个陌生的玩家,可能也玩不了太久就放弃了。

然后我开始意识到,游戏的设计,不同于之前我做的软件的设计。软件的设计,是为了满足某种较为确定的需求,只要需求可以实现,任务就算完成了。但游戏设计的自由度更大,你并不能确定玩家想要的需求。有时候我只是在“满足我自己的一时的需求”,而不是在设计一个好玩的游戏。

而我这个一时的需求,现在看起来还挺无聊的。要让别人照着我的思路玩下去,太强人所难了。尽管游戏的核心玩法还在思考中,但我觉得自己至少有必要开发一些新的玩法。不至于让人一下子玩穿。

想想我既没有讲好一个故事的规划,也没有对核心玩法的思考,居然就这么开始了,真的是头铁。但我不担心,因为这种先立项再迭代的开发模式,不如说比较符合我自己的节奏。毕竟上一个这样开发出来的玩意儿,也是在我“这东西也会有人用?”的自我怀疑中积累了三百多万的用户。作为一个独立开发者,也算是可以拿来自我吹嘘一下的成就了。

鉴于现在还没有成熟的想法,我还是采用了老办法,从丰富游戏体验的角度先着手,设计了两个机制。

第一,就是出战人数的扩充。这一点类似FGO的Cost机制,但是因为我还没有做出经验值和升级系统,所以打算做成一个任务的形式,即:通过完成一系列任务,来增加可以出战的人数。这样可以让玩家可以有提升的空间。毕竟如当下的游戏模式,出战的人数直接决定了胜率:能够多一个人上场,自然可以在战斗中更有优势。

Image title

第二,就是战斗策略性的提升。之前的战斗,数值的设定只考虑到了致敬原著,而根本没想到策略性。譬如炉石,大家也都是简单的数字,但是一个“随从打随从互相扣血”,一下就丰富出了很多战术。但是本作由于游戏的模式不同,无法使用这样的方法,只能从技能上下手。鉴于剧情中的战斗已经写好,不太可能被人重复玩,我选择从新的“增加出场人数”的关卡开始实验起。例如“快速但是低攻击力的Rider影从者”用“带有神性可以降低伤害的吉尔伽美什”来应对,“有几率无视对方血量秒杀对方的Assassin”用“带战斗续行可以复活的库丘林、尼禄或是赫拉克勒斯”来应对等。但是目前的模式还是太简单了,因为技能的设计也太简单了。

第三,把敌人分成了多个波次。只有一个波次的敌人全部阵亡后,下一个波次的敌人才会出场。避免了连绵不断的敌人带来的压力,同时也让敌人的阵型能够更好地组织,而不是让前排单位傻傻地站在后排发呆。这也是为了能提高一些策略性。

说了这么多,这些都是为了提升游戏的策略性,让它更耐玩,不要那么无聊。但这都还只是一些简单的改动,真正的策略估计需要很大的手术。也许在接下来的小修小补中,能够找到大改的灵感吧。

(转发自:原日志地址
从零开始开发一款类卡牌式游戏——滑稽圣杯战争开发日志3
xdx3000 2020-06-10

游戏的大体框架搭起来之后,后续的制作顺利了许多,于是也迎来了高产的一周。

情节方面,增加了第6章的情节,也就是有决战艾因兹贝伦的部分。最终一行人来到了城堡,对决无敌的巴萨卡赫拉克勒斯。大概是因为第一次写游戏剧情,总觉得不是很顺手。本来我也没有写小说的功底,更遑论游戏了,所以我之前可能是把写游戏情节想得太简单了吧,有些随心所欲了。写的时候感觉还不明显,事后抽身出来一看,很多地方真的是尬得可以。我知道很多独立游戏制作人是想要讲好一个故事,所以开始制作的,像我这样开发已经开始一段时间了还在冥思苦想剧情的大概是个另类。写好之后,看来看去,又把之前的第4和第5章的情节改了很多,总算勉强不那么尬了。但还是不甚满意。但是又暂时灵感枯竭了,只能先止步于此。

游戏性方面,最大的改动是增加了AP系统。一直认为AP(体力)系统是一个伟大的设定,可以有效提高游戏的黏着力,不会让人一通猛玩然后快速陷入枯燥期。尤其是手机游戏不同于电脑或者主机游戏,是可以一直在玩的,很容易快速让玩家失去耐心。但是这个系统并没有想象的简单。在线时要实时更新体力值,离线后又要能恢复,还要考虑到各种关卡的AP消耗量以及提示(AP不足时,显示AP消耗量的数字应当为红色)。开发途中陆陆续续出了各种bug,诸如新玩家的AP可能会变成0之类的。想想自己还是很缺乏那种一口气编对的能力的,叹气。

Image title

然后增加了助战系统。最初我的设想是,随着关卡的推进,所有队员都会逐渐加入队伍。但是后来我否决了,因为这样玩家就可以轻易获得大部分的队员,然后失去探索的乐趣。但是我又希望玩家能在剧情的过程中见识到甚至用到游戏中的大部分队员,算是个试用。于是从FGO的助战系统中得到启发,建立了助战系统,将大部分队员设置为助战。也就是说,只有某个关卡可用。助战人员的卡面底色不同,并且有助战字样标识。真正会永久加入队伍的,暂时只设定为呆毛和美杜莎。

Image title

说到卡面底色不同,我还把出战界面大改了一番。原来的出战界面的人物形象,是现在的战斗界面的人物形象。只有头像、攻击力和生命值,而且看起来不那么齐整,有些凌乱。我把他们都改成了卡片形式,可以看到名字,攻防速属性,技能简称等等。同时还能看到已经出战的人员和出战人数的上限等。

Image title

艺术方面,增加了背景音乐、音效和人物语音。在不同的场景,播放不同的音乐,同时选择出场英雄的时候,会播放相应的语音,使得游戏更加生动一些。

最后就是老大难的载入速度问题,因为分包大小实在是紧张,很多资源还是放在了云端。但是预加载实在是太慢了。毕竟把这一堆素材在游戏的开始阶段一口气全部下载下来并没有必要。但是如果不这么干,万一需要用的时候还没有下载完毕就尴尬了。于是还是决定游戏开始的时候只先预下载马上会用到的关卡对话所需资源,其他资源异步加载;然后包装了一个方法,当需求的资源还未异步载入完毕的时候,就优先同步加载完再进入关卡。

还有就是各种填坑和优化了。毕竟微信小程序束手束脚,限制太多了,需要很努力优化。如果是主机游戏大概就没有这样的烦恼了吧。这一周干了很多的活儿,但是接下来应该会放慢一些节奏。毕竟写故事情节快把我的智慧榨干了。

(转发自:原日志地址
小游戏制作寻求美工
FEIHUGAME 2020-06-04

小游戏制作寻求美工,已经发版了一款小游戏,还有几款在开发中,我们这里都是程序。想找一位美工合作,目前主要是游戏UI修改,ICON,宣传图的美工需求,希望可以和个人长期合作,感兴趣的美工小伙伴可以加微信:1873217295。

腾讯光子 《最强魔斗士》3D 开发优化经验分享 | Cocos 技术派第14期
CocosEngine 2020-05-28

《最强魔斗士》是由腾讯光子游戏工作室采用 Cocos Creator 3D 开发的一款画风精湛、玩法有趣的 3D 小游戏,近日腾讯光子开发团队接受了 Cocos 的专访,从策划、运营和技术多个角度,大方分享了游戏的开发经验,包括关卡设计、动画效果、角色换装、碰撞检测、资源管理和加载、性能优化等,相信能给大家带来新的思考和启发。

Image title



游戏亮点

游戏设计

《最强魔斗士》沿用了当前非常火的弓箭类操作设计,移动虚拟摇杆即可控制角色移动躲避,停下来的时候会自动对敌人进行攻击。角色会发射子弹自动攻击怪物,省去了选择攻击目标、选择技能、进行攻击的步骤。这种允许玩家单手操作的方式,更适合广泛的休闲用户,同时又赋予了玩家一种 「Play to Win」的乐趣。
在玩家成就反馈上,用相对慢速但可永久保存积累的装备+秘籍系统,搭配每局战斗中临时获得的局内等级+技能,让玩家在局内大概 2 秒杀一怪、30 秒清一关、60 秒升一级、10~15 分钟通一关,能在游戏过程中体验到飞速成长的即时满足感。

戳链接查看游戏视频:

https://v.qq.com/x/page/d0968ekcndk.html?pcsharecode=&sf=uri

游戏采用了 2D 场景 + 2D 弹幕 + 3D 怪物和角色的做法:

  • 2D 场景的设计大幅降低了同屏的顶点数,一方面降低运行在 iOS 小游戏平台的性能压力,另一方面也留出足够的性能空间来丰富场景美术。所以我们可以看到和其他弓箭类游戏不同的是,《最强魔斗士》场景细节极其丰富,各种建筑、农田、树木都做得非常细腻。
  • 2D 弹幕则是弓箭类的标准做法,这可以大幅降低碰撞逻辑运算的压力,使得游戏可以承载像「3 连发连弩 + 正向箭 + 斜向箭 + 左右箭 + 子弹折返 + 弹射」这样同屏存在七八十个子弹的轨迹和碰撞计算。  
  • 3D 角色和怪物,则方便做各种技能和换装,特别是换装及其背后的经济系统,这个毋庸多说。

美术品质

毕竟是腾讯光子的大厂作品,《最强魔斗士》里无懈可击的高品质美术令人由衷赞叹。甚至有多个游戏团队看到这种美术品质后,惊叹之余,转身就把自己公司里处于立项早期的弓箭类项目直接砍掉了 —— 不是技术上做不出来,而是真心没法做到这种美术水平。

Image title


细节是魔鬼

《最强魔斗士》除了美术细节之外,在其他方面的细节上同样打磨了很久。


作为 Cocos Creator 3D beta 的第一批内测参与者,腾讯光子在 2019 年 7 月份就已经立该项目,微信小游戏里注册这款游戏名字的时间是 2019 年 8 月 15 日,也就是到现在已经打磨了足足 8 个月。Cocos 团队在保密条件下,也看着这款游戏逐步完善细节到今天的水平。
比如在打击感和操控空间上,不同怪物面对不同武器时的击退计算、不同的受击硬直时间、近战怪物的攻击前摇时间,都非常精妙;在音效上,不同的怪物配置了不同的击中音效,这就可以在怪物超出屏幕范围的时候给予玩家听觉反馈;在关卡设计上,充满了各种让人会心一笑的卡地形、夹角、障碍物缝隙,等着玩家发现和利用。

Image title


在装备-技能搭配的策略空间上,玩家可以自己搭配出不同的打法流派。不同的套装对应不同的打法,可苟可浪。即使在同样装备的情况下,有时欧皇眷顾,局内所有技能不断正向叠加,而有时则非酋附体,始终抽不到对应技能,这两者完全就是全场压制和满地找牙的区别。所以在《最强魔斗士》里,装备强度 + 运气水平 + 操控水准,构成游戏过关三个核心要素之间的数值平衡,其实非常微妙。

顺便提示一下:关卡里随机给予的局内技能,其实并不是完全随机的,所以并不是表面上看起来的那么简单哦。

Image title


专访实录

游戏中丰富的关卡设计是如何提高制作效率的呢?

我们有专门的小组开发关卡编辑器,除了实现传统的刷子等地表编辑功能外,还有一个更上层的抽象-岛屿,通过表格配置以及一定的随机规则,可在工具层自动拼接岛屿生成完整的关卡,这是支撑目前数百上千个关卡制作的重要能力。

游戏中丰富的动画和效果是如何制作的呢?

这部分得益于 Cocos Creator 3D 本身强大的动画系统,我们所有动画都是美术在 Creator 里制作的,粒子系统和时间轴动画系统能满足所有需求,应用到程序里也非常方便。

角色换装是如何制作的呢?

目前产品里的角色是由武器决定外观的,所以换装系统并不复杂,武器决定了主角使用的整个模型和贴图,不过同动作的人物形象是复用骨骼和动画的,这能节省不少资源量。

能否分享下我们在碰撞检测上做了哪些优化策略呢?

复杂情况下有七八十个子弹和 10 个左右同屏的怪物,这个量其实不算很大,不过因为渲染已经消耗了一半的时间,再加上 iOS 下 JavaScript 解释执行的效率有限,所以还是遇到了一定挑战。
碰撞检测我们没有用物理引擎,为了简化运算,整个游戏里仅支持圆形和矩形碰撞体。障碍物首先对相邻的矩形进行合并减少碰撞体数量,然后用四叉树做空间规划,对每个子弹来说,每次参与运算的障碍物只有 0-2 个,所以这个消耗控制得很低。
更主要的消耗在于子弹和怪物的碰撞,这方面除了碰撞算法本身要简化到极致外,更重要的是从上层根据实际业务需求来复用子弹的运行路径和碰撞测试结果,从而达到大量减少运算的效果。

如何缓解同屏子弹和怪物数量较多时的渲染性能压力?

怪物是 3D 模型,引擎的渲染性能已经很不错了,另外我们扩展支持了 GPU Instancing,某些情况下能有一定性能提升,目前在低端 iOS 上怪物渲染占了不到一半的帧时间,算是比较可接受的范围内。
子弹大多数为 2D 精灵,同屏精灵数量最复杂的情况下有数百个之多,在合理安排层级控制 drawcall 在 40 以下之后,引擎本身的渲染效率已经不错。

Image title


不过针对如此大量同屏精灵数的情况,我们还是做了比较多的针对性优化才避免了运算峰值带来的卡顿。

主要的优化方案大致有这些:

  • 很大部分矩阵运算可以简化为坐标求和;
  • 实现轻量的 active 功能以优化大量频繁的节点增删;
  • 用定制的仅支持 Simple 模式的 sprite 渲染减少动态合批的运算量;
  • 用静态合批优化不动的精灵渲染;
  • 用懒渲染模式减少序列帧动画的消耗等。

Cocos 团队:v1.1 已经自带 GPU Instancing 支持,不仅支持静态模型,还支持蒙皮模型的 Instancing 合批。

游戏整体非常流畅,可以为我们分享些小技巧吗?

资源管理和加载方面我们做了深度的定制,在不改动引擎原生实现的情况下,我们进入新手关卡需要下载超过 300 个文件,总体积在 9M 以上。而定制了文件组织形式和下载流程之后,进入新手关卡只需要下载约 15 个文件,总体积不到 2M。资源定制的主要思路是把大量零散的小 json 合并成大 json,然后根据 prefab 的依赖关系把多个文件压缩成一个 zip 包,运行时下载这些 zip 包解压使用。另外在关卡内战斗的时候,我们会利用空闲时间去下载下一关的 zip 包,从而达到更快的切换速度。

对 Cocos Creator 3D 的表现是否满意呢?

目前来看对 Cocos Creator 3D 的性能表现是比较满意的,beta 版本缺乏的一些对性能特别重要的组件也已经陆续支持了,据了解 1.1 版本还会支持 GPU 粒子系统,把性能上留下的一块短板补上,这个是我们特别期待的。至于性能优化方面,对于大型的复杂游戏来说,即使引擎的通用功能性能再好,都避免不了要定制化部分实现,从这个角度来说,希望 Cocos 引擎后续在用户定制与扩展方面提供更好的支持,这样能降低用户直接修改引擎源码的需求和维护成本,变得更加友好。


Cocos 团队:v1.1 的粒子系统开始支持利用 GPU 运算能力进行模拟,大幅度提升运行性能,特别是在不支持 JIT 的 iOS 设备上,可以愉快地增加特效的使用啦。


最终为什么选择 Cocos Creator 3D 来制作呢?

由于微信小游戏平台上的复杂 3D 游戏案例并不多,所以技术选型是我们特别慎重的事情。项目在选型阶段花了接近一个月时间,预研了多个现今市场上支持 3D 渲染的H5引擎,并且分别用 Cocos Creator 2.5D 版本,Cocos Creator 3D beta 以及 LayaBox 2.0 引擎实现了原始 Demo,做了详细性能测试。
对比了开发流程、技术支持和运行性能的各方面因素,发现 Cocos Creator 3D 在前两者有明显优势,性能上也基本持平,所以成为了我们的首选。

是否有计划发布到原生平台呢?

目前我们也构建了安卓 App 版本,运行性能高非常多,不过暂时没有发布计划,从能力上来看 Cocos Creator 3D 是能满足跨平台需要的。


Cocos 团队:原生性能一直是我们非常重视的关键指标,开发者们可以尝试把自己的游戏发布到原生平台,可能会有惊喜哦。

为什么选择用 3D 的形式来呈现这个游戏呢?

按照之前的一些经验,我们希望《最强魔斗士》这个项目在动作层面上拥有更好的表现力,同时也有更好的移动手感、更加流畅的移动体验、以及在整个美术制作流程和表现力上有更高的上限,所以最后我们决定试用 3D 的呈现方式。

选择斜 45° 的视角是出于什么考量呢?

45° 的视角从对抗模式来看,相较于弹幕体验,会更接近传统 RPG 的视角表现方式。在这样的视角上,可以突破纯弹幕的玩法设计禁锢,扩展更多的设计空间。比如后续我们会设计更丰富的武器体验,甚至近战等等,同时 45° 的视角也会更适合表现有压迫力的大型怪物,例如游戏中的 Boss 战斗,玩家体验就会更丰富一些。

Image title


如何提高游戏中关卡的制作效率呢?

在 Cocos Creator 3D 引擎下,项目组内部针对游戏的关卡和怪物都搭建了比较高效的编辑器,大幅度提高了关卡制作的效率。游戏前三章的体验量级,就有 600-700 个不同的关卡小岛,没有高效的编辑器是完全无法跟上内容消耗速度的。

美术方面的制作管线有涉及到哪些工具和岗位呢?

美术涉及到的工具和岗位都算是行业中比较常规的标配,二维绘图软件及 3ds max,岗位有交互、视觉、原画、3D 动效设计师这些。相对比较有挑战的是引擎的选择。产品在小程序上发布,角色需要 360° 自由旋转、射击,用 2D 图素就不那么好表现,图量也会很多,权衡之后用 3D,选用 Cocos Creator 3D,兼固了开发及美术 3D 需求。由于工具比较新,人力有限,美术的一些效果功能都是对应岗位的同学提给 Cocos 那边帮忙实现,相当于联合的技美。

游戏中丰富的动画和效果是如何制作的呢?

特效方面:采用 Cocos Creator 3D 编辑器开发制作,粒子系统、模型、序列图都结合使用,较多采用小型特效贴图,在编辑器里以 2D 模式,组合搭建出不同的动画特效。比如游戏里的子弹及受击,部分结合了粒子、模型、系列图等,单图居多,特效师做好每个子弹样式,由程序去实现弹道逻辑,比如飞行、抛射、折返、追踪、多弹道等不同效果,这种方法能保障在全屏群攻的时候,还能流畅地操作。 

Image title


UI 界面动效方面,分解界面素材,针对每个 UI 节点做动画。有些也需要程序协助触发的动效,比如技能选取,特效设计师先做好选取技能前后所要表达的特效文件,然后配合程序做好逻辑接入。

Image title


游戏中有丰富的装备系统,角色换装是如何制作的呢?

角色的换装是在三维软件里制作好模型动画,导出 fbx 格式,合入到 Cocos Creator 3D 里面,皮肤跟武器是分开的,可以自由搭配,并能实时旋转预览,这也是 3D 的优势。

激励广告是如何融入到游戏流程中的呢?

我们把广告加入到了对局内复活的功能上,对于类似类型的 PVE 游戏来说,这样的广告形式不影响玩家体验,比较自然。

我们是如何考量游戏的策略性的呢?

这里介绍两个魔斗士里面的技能组合:
弹道增强+追踪箭/折返子弹+背刺暴击,类似的思路,一方面这样的技能组合能够带来足够的视觉冲击力提升;另一方面,通过核心技能的搭配,可以达成 1+1 远远大于 2 的强度体验,包括能够突破一些特殊地形阻挡的限制,后续也会设计更多类似的技能组合,敬请期待哈~

可以简单分享下装备系统的设计思路吗?

我们希望能够通过外围的策略系统提供给玩家更多的长线追求和策略技能选择,主要是下述几个方面:

  • 不同的套装提供不同的玩法倾向;
  • 高品质套装的特殊魔法属性,可以让玩家打造属于自己的专属极品装备;
  • 上个版本更新的特殊套件装备,可以让玩家选择放弃一部分能力,来获得更多的关卡资源收益。

我们在用户黏性上有做哪些措施呢?

一方面是尽快提高我们更新关卡的速度,能够跟得上玩家消耗内容的速度;另一方面也是前面提到的挑战玩法,给平台期玩家提供了更多持续游戏的动力,后续也会继续在这个方向发力,给平台期的玩家提供更多有趣有深度的新玩法模式。

方便透露下后续会做哪些调整吗?

目前上线阶段还只是很少量级的数据测试,从测试数据结果来看,基本符合我们的预期吧,玩家的在线时长数据比较可观,这也为我们后续继续迭代内容提供了更多信心。另一方面我们也希望可以稍微降低前期的关卡难度,以及优化最基础的体验(摇杆手感、镜头逻辑、稳定帧率等等),希望有更多的玩家可以体验到这个玩法的深度乐趣~

对于各个岗位上手 Cocos Creator 3D 是否有什么建议呢?

在 Cocos Creator 3D beta 版本阶段,引擎和工具在稳定性以及易用性上面有较多不足,不过随着版本迭代,我们能感受到引擎的进化非常快,对 bug 的响应及修复都非常敏捷。
目前到了正式版阶段,我们开发团队认为问题不多了,引擎运行层面比较稳定,主要是编辑器方面的稳定性希望进一步加强。

Cocos Creator 3D 和 2D 在工作流体验上是否有差异呢?

非常接近,涉及 3D 的部分需要看一下文档,其它方面可以无缝切换。

如何评价 Cocos Creator 3D 的整体使用体验呢?

功能丰富性能强大、使用上很简单符合过往经验,IDE 集成度高,对团队协作支持得很好,代码开源对性能分析和优化很友好。建议方面还是集中在编辑器,希望有更高的稳定性和扩展能力,进一步提升开发效率。


以上就是我们今天想跟大家分享的内容啦,再次感谢腾讯光子团队为我们带来干货喔,也祝愿《最强魔斗士》能取得好成绩。


以上就是我们今天想跟大家分享的内容啦,非常感谢腾讯光子团队为我们带来的技术干货 。我们也希望越来越多的开发者,能够通过 Cocos Creator 3D 创作出更多的精品游戏,也祝愿《最强魔斗士》能取得好成绩喔!

(转发自:原日志地址
从零开始开发一款类卡牌式游戏——滑稽圣杯战争开发日志2
xdx3000 2020-04-30

2020.3.11

第六个Demo视频

1.制作了一个主界面。制作了故事的框架。游戏整体由多个章节构成,每个章节都是从主界面进入,在对话界面进行一定的情节对话,然后按照设定的敌人开始战斗。

2.不同章节之间存在解锁关系。完成前一个章节,则解锁下一个章节。

3.增加了胜利和失败的条件判断,如果一方人员死亡殆尽则另一方获胜。

4.增加了背景动态切换功能,每次进入战场都从7个场景中随机选择一个作为背景图。


2020.3.13

第七个Demo视频

1.完成了第1章和第2章的文本,同时增加了许多人物的立绘。

2.为立绘设置了懒加载功能,游戏中只存储分辨率很低的立绘,以便快速显示。同时,在服务器端存储分辨率较高的立绘,在运行过程中动态加载。这样既能保证立绘能马上出现(而不是空白等了半天才加载出来),又能有较好的效果。同时,也为对话和战斗的背景增加了此项功能。

3.实现了对话的场景切换,可以随着情节的进行切换场景。


2020.3.16

第八个Demo视频

1.完成了第3章的文本和立绘。

2.增加了战斗胜利后的对话,使得故事更加连贯。

3.保留了背景的懒加载功能,取消了立绘的懒加载功能,因为分辨率太低的立绘看起来效果很糟糕。但是背景没问题,因为大家一开始注意力都不会放在背景上。而且逐渐由模糊变清晰的过程还能模拟出睡眼惺忪刚睡醒或是刚刚传送到位的感觉。但是立绘真的太大了,微信小程序4M的分包限制伤不起。所以增加了一个载入界面。在游戏的开始界面进入主界面时,先把所有的立绘和英灵头像从网上下载完毕,再开始运行。

4.预加载界面太慢了……于是加了一只会跑的芙芙。比FGO的跑得更流畅-_-


从Demo视频回忆的开发日志到此为止,之后就是有开发日志的部分啦。


(转发自:原日志地址

加入 indienova

  • 建立个人/工作室档案
  • 建立开发中的游戏档案
  • 关注个人/工作室动态
  • 寻找合作伙伴共同开发
  • 寻求线上发行
  • 更多服务……
登录/注册