微信小游戏

创建于:2017-12-28

创建人: MotionWalk Studios

66 信息 617 成员
关于微信小游戏的内容
露易丝佣兵团 安卓 版发布啦

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视频回忆的开发日志到此为止,之后就是有开发日志的部分啦。


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

作为FGO玩家,我对于圣杯战争的系列设定还是很感兴趣的。于是就有了这个项目。大概是想用来讲述一些自己心目中的故事,以及纯娱乐吧。

开发的后期是有开发日志的,但是早期更多的是试水,是在“我到底能不能做出来呢”的想法下的实验,所以谈不上什么日志。但是为了记录效果,有一些录屏,大概可以用来帮忙回忆起一些细节。


2020.2.26

萌生了“想要做个游戏”的想法。因为完完全全是个新手,考虑到开发的应该是个2D游戏,在衡量之下选择了Cocos Creator作为开发的工具。因为不知从何下手,所以看了几篇Cocos Creator官网上的视频教程,收获颇多。视频教程的一个好处就是可以让你迅速上手,不用迷惑在开发文档中不得要领。开发文档我觉得作为一个备查的字典类的资料是比较合适的。


2020.2.27

在开会的期间,放飞自我,在本子上做了一下设想,不打算像FGO一样做成复杂的职业相克,而打算更加还原原作的一些设定。例如弓兵和魔术师远程(虽然弓兵近战已经成了梗),狂战士攻高血少,骑兵敏捷高等等。定下了最初的各职业基础数值,(后期来看,只是各职业的第一个英灵的数值而已hh)包括攻击力、血量和速度。(没有防御力的设置,因为太麻烦了hh)


2020.2.28

因为本身是个毫无美术功底的人,在用PS画出了最初的几个UI元素之后,我放弃了继续画人设或是地图的想法,转而想到了借用FGO游戏的部分UI。因为也没有动画的功底,游戏的特效只能尽量简单化,因此最终决定了使用类似炉石传说的人物设置,即一张人物图片+外框+表示血量和攻击力的标志。这样可以简化动作,降低制作难度。

于是我上网搜索,在百度贴吧找到了一个来自于吧友的解包。感谢原帖主遗忘的银灵。另外,我还从FGOWiki下载到了人物的滑稽版立绘,以及人物的对话立绘。因为界面简单,所以比起原版的严肃向立绘,在战斗界面下还是滑稽版立绘比较适合。因此也定下了游戏的名字,“滑稽圣杯战争”。


2020.3.1

第一个简易的Demo完成。作为从零开始的开发,第一步先实现了人物选择界面。设定了每个职介各一个英灵,作为初始的待选角色。在选择界面让人物排列待选,单击即可选择人物。因为教程中提到了Layout,而这个一直是之前让我感觉比较麻烦的部分。事实证明,在成熟的工具中,这不算太麻烦。虽然折腾了点。


2020.3.3

第一个Demo视频,实现了:

1.选择人物的数量上限,限制为最多3人。毕竟如果全部上场的话,设置这么多人就没意义了。

2.实现了第二个界面,战斗界面。但是里面目前非常简单,只有一个背景。并且实现了场景切换,点击开始后切换到战斗界面。

3.战斗时人员进场特效,使用了简单的动画。


2020.3.4

第二个Demo视频

1.调整了选择人物界面的人物大小,毕竟一开始人物不多,界面那么大显得太空旷了。

2.更改了人员进场特效,由从侧面进入改成了从上下进入。原因是这样可以为每一个人物分别播放特效,而不用整体播放。(由于Layout的原因,每个人物只有纵坐标有自由度。)

3.更改完特效后,就可以支持后续人员入场了。增加了重新入场和补充人员的功能。这些属于测试功能,同时为了后期多批人员进场做铺垫。

4.人员掉血测试。确认可以操作人员的血量。


2020.3.5

第三个Demo视频

1.战斗动画,就是后退一点然后用力往对面撞过去。只能撞向正前方。为了动画不太违和,也定下了只有最前面的人才可以战斗的规定。后面的都算是候补人员。

2.战斗结算,根据攻击力扣减对面的血量,当血量为0的时候人物慢慢变小消失,后面的人自动补位上来。(利用Layout的特性)

3.不同人员的速度不同,所以攻击频率能体现出不同,每个人使用单独的计时器。


2020.3.6

第四个Demo视频

最近发现开发一个游戏并没有想象中的难,迸发了热情,所以开发进展比较快。

1.技能的设置,设置了诸如冲锋、战续、射击等技能。冲锋是进场马上攻击一次(而不用等待一个攻击间隔),战续是将死的时候回复1的血量,射击是在后排也可以攻击。射击的设计花了一些功夫,用到了update中的判断,感觉会影响性能,让我有些不爽。但是目前看来影响好像不大。

2.技能的表示,发动了技能不能没有反馈,所以会在人物脑袋上冒出相应的字样。

3.人物选择界面介绍人物技能。


2020.3.9

第五个Demo视频

1.增加了开始界面,使得它看起来更像一个游戏了。

2.增加了对话界面,便于进行故事。

3.增加了敌人不断出现的功能,用于测试。

4.打算上架微信小游戏。所以注册了账号。因为大小超出了微信的4M限制,不得不缩减资源。看了一下,每个人物头像都有几十k,对话立绘每个几百k,战斗背景大几百k,最恐怖的是字体,一个字体居然占了十几M!更不用说后期可能加上的音乐和音效。只能对部分资源压缩,再将部分资源放在远程服务器,运行中加载。副作用的运行起来开始有了卡顿的感觉。打算下一步采用分包加载的办法,但是压缩的趋势是不变的,因为后续要增加的资源还有很多,两个分包加起来最多也只有一共8M的大小限制,必须精打细算。


同时,软著的申请走起来了。为了能够在各大平台上线。

(转发自:原日志地址
求各类微信小游戏团队和个人合作
暗河 2020-03-05

本公司有大量流量,需要小游戏合作,广告变现,所以希望有好产品的团队和个人合作!QQ:1061943883,合作微信和电话:16601157826

独立开发的微信小游戏上线了
胡霁 2019-12-02

Image title


整体是黑白风格的游戏,反复修改了好几版,关卡也重做了几版,欢迎体验。

故事背景是未来世界,一部分穷人被迫到地下生活,所以视觉退化了,只能看到三种颜色。目前剧情的感觉还不是很强,后面会继续优化。

加入 indienova

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