• QFramework Pro 开发日志(二)为啥要搞 Pro


    自己的独立游戏《鬼山之下》鸽了有半年了。

    上一次《鬼山之下》的大规模的功能新增是在 8 月份左右。然后感觉一直用 AssetStore 的素材也不是长久之计。于是就花了 2 个月的时间去学美术去了,把美术需要的基础都过了一遍,而现在基本上美术可以说是入门了。学完美术就到 10 月份了,还有一个月就双十一,于是就全部时间都花在了双十一的新课筹备上了,然后就一直忙,忙到 1 月 1 日,反正面包是要排在理想之前的。

    在 1 月 1 日的时间点,自己的大部分教程都完结了,于是就又开了新坑,开始准备一个平台跳跃的课程案例,准备了 1 个月,2 月份开始录制课程,录了一个月加上春节初二~初四连续在 b 站直播 3 天,每天 3 ~ 6 小时的直播时长,结果嗓子就开始发炎了,连续打了一周点滴没见好,医生说只能静养了,课就不能录课了。

    所以自己的所有正在进行的课程都暂停掉了。

    这个时候我在想能做什么事情,一是可以接着制作《鬼山之下》,二是接着往下制作平台跳跃课程的案例。

    结果我选择了搞 QFramework Pro 版本。

    为啥要搞 QFramework 的 Pro 版本。

    这里简单说明一下,在之前 QFramework 的大部分用户群体都是在公司上班的童鞋,可以说 QFramework 开源版本是面向企业和公司的。

    而自己有半年多的独立游戏《鬼山之下》的制作经验,在个人或者小团队制作独立游戏的时候,要解决的问题与企业或者公司要解决的问题是有不少区别的。

    公司和企业由于大部分都是做移动端手游的居多,所以游戏的性能很重要,于是就有了一些资源管理方案,QFramework 的资源管理方案是 ResKit。还是由于性能问题,游戏的界面最好可控管理,不能一股脑地把所有界面扔到场景就行了, 还要考虑 Canvas 的 Mesh 重建、层级管理、加载卸载等问题,在这个基础上还要考虑界面的制作效率问题,所以可能会用 FGUI、psd 2 ugui 等解决方案,但是一般面向企业或者公司的框架都会有个 UI 管理框架,有了 UI 管理,可以将没个界面的工作分工出去,而不会造成冲突,也就是说有了 UI 管理也方便团队协作。

    根据以上简单的分析可以得知,面向企业的方案考虑的指标:

    • 团队协作
    • 生产效率
    • 性能

    除此之外有很多公司有资源热更、脚本热更的需求,也有网络的需求。配置表、多语言等等。这里可以说很多,但是就简单啊说这几点足够了。

    所以 QFramework 之前都考虑的都是 企业和公司的需求,当然市面上排名比较靠前的框架,基本也都是面向企业和公司需求的。

    至少资源管理、UI管理基本都有,然后有的框架提供架构 MVVM、MVC、ECS 等,有的框架小而美开箱即用,有的框架提供一整套脚本热更方案,等等。基本都是围绕着公司的需求做的,QF 也不例外。

    而自己有幸拥有了半年的独立游戏制作经验,在制作的过程中发现,由于独立游戏很多都是在 pc 上发布,相比于移动端,性能方面更宽松一些。这个时候资源管理方案可能用了反而拖慢游戏的制作进度。所以很尴尬,笔者在做自己的独立游戏的时候就没有用到 QF 的资源管理方案。

    独立游戏基本都是自己一个人开发,所以团队协作也不用考虑了,除非要把一部分制作的工作外包出去。。所以 QFramework 里的 UI 方案 也用不了了,唯一用得比较多的只有 QF 里的音频管理方案,再加上一堆工具类库之类的,还有决定版架构部分用得比较多。

    自己的独立游戏《鬼山之下》鸽了有半年了。

    上一次《鬼山之下》的大规模的功能新增是在 8 月份左右。然后感觉一直用 AssetStore 的素材也不是长久之计。于是就花了 2 个月的时间去学美术去了,把美术需要的基础都过了一遍,而现在基本上美术可以说是入门了。学完美术就到 10 月份了,还有一个月就双十一,于是就全部时间都花在了双十一的新课筹备上了,然后就一直忙,忙到 1 月 1 日,反正面包是要排在理想之前的。

    在 1 月 1 日的时间点,自己的大部分教程都完结了,于是就又开了新坑,开始准备一个平台跳跃的课程案例,准备了 1 个月,2 月份开始录制课程,录了一个月加上春节初二~初四连续在 b 站直播 3 天,每天 3 ~ 6 小时的直播时长,结果嗓子就开始发炎了,连续打了一周点滴没见好,医生说只能静养了,课就不能录课了。

    所以自己的所有正在进行的课程都暂停掉了。

    这个时候我在想能做什么事情,一是可以接着制作《鬼山之下》,二是接着往下制作平台跳跃课程的案例。

    结果我选择了搞 QFramework Pro 版本。

    为啥要搞 QFramework 的 Pro 版本。

    这里简单说明一下,在之前 QFramework 的大部分用户群体都是在公司上班的童鞋,可以说 QFramework 开元版本是面向企业和公司的。

    而自己有半年多的独立游戏《鬼山之下》的制作经验,在个人或者小团队制作独立游戏的时候,要解决的问题与企业或者公司要解决的问题是有不少区别的。

    公司和企业由于大部分都是做移动端手游的居多,所以游戏的性能很重要,于是就有了一些资源管理方案,QFramework 的资源管理方案是 ResKit。还是由于性能问题,游戏的界面最好可控管理,不能一股脑地把所有界面扔到场景就行了, 还要考虑 Canvas 的 Mesh 重建、层级管理、加载卸载等问题,在这个基础上还要考虑界面的制作效率问题,所以可能会用 FGUI、psd 2 ugui 等解决方案,但是一般面向企业或者公司的框架都会有个 UI 管理框架,有了 UI 管理,可以将没个界面的工作分工出去,而不会造成冲突,也就是说有了 UI 管理也方便团队协作。

    根据以上简单的分析可以得知,面向企业的方案考虑的指标:

    • 团队协作
    • 生产效率
    • 性能

    除此之外有很多公司有资源热更、脚本热更的需求,也有网络的需求。配置表、多语言等等。这里可以说很多,但是就简单啊说这几点足够了。

    所以 QFramework 之前都考虑的都是 企业和公司的需求,当然市面上排名比较靠前的框架,基本也都是面向企业和公司需求的。

    至少资源管理、UI管理基本都有,然后有的框架提供架构 MVVM、MVC、ECS 等,有的框架小而美开箱即用,有的框架提供一整套脚本热更方案,等等。基本都是围绕着公司的需求做的,QF 也不例外。

    而自己有幸拥有了半年的独立游戏制作经验,在制作的过程中发现,由于独立游戏很多都是在 pc 上发布,相比于移动端,性能方面更宽松一些。这个时候资源管理方案可能用了反而拖慢游戏的制作进度。所以很尴尬,笔者在做自己的独立游戏的时候就没有用到 QF 的资源管理方案。

    独立游戏基本都是自己一个人开发,所以团队协作也不用考虑了,除非要把一部分制作的工作外包出去。。所以 QFramework 里的 UI 方案 也用不了了,唯一用得比较多的只有 QF 里的音频管理方案,再加上一堆工具类库之类的,还有决定版架构部分用得比较多。

    经过自己的经验知道了面向企业的框架和方案,不适合做独立游戏。

    自己做独立游戏遇到的需求:

    • 关卡设计

      • 关卡脚本:最好用可视化脚本方案,这里笔者用的是 PlayMaker,用得很顺手。
      • 敌人 AI:也是 PlayMaker,这里也推荐 BehaviorDesigner
      • 关卡机关、可交互物体:也是 PlayMaker
    • 剧情对话:需要用可视化对话树插件,可以用 Dialogue System 或者 NodeCanvas,我买了个国人开发额插件,PlayText 也算好用。

    • 背包、任务、成就,这里也都用的各种插件,什么 Inventory System、Quest Machine 等等

    • 基本上这些算是笔者花了钱才解决的需求吧,如果按照以往自己只做开发的话,以上这些自己都能手撸,但是无奈,做独立游戏不能只专注在技术上,还有很多其他事情要做,所以这些方案能买就都通过花钱解决了,独立游戏,时间是稀缺资源。

    经过自己的经验知道了面向企业的框架和方案,不适合做独立游戏。

    自己做独立游戏遇到的需求:

    • 关卡设计

      • 关卡脚本:最好用可视化脚本方案,这里笔者用的是 PlayMaker,用得很顺手。
      • 敌人 AI:也是 PlayMaker,这里也推荐 BehaviorDesigner
      • 关卡机关、可交互物体:也是 PlayMaker
    • 剧情对话:需要用可视化对话树插件,可以用 Dialogue System 或者 NodeCanvas,我买了个国人开发额插件,PlayText 也算好用。

    • 背包、任务、成就,这里也都用的各种插件,什么 Inventory System、Quest Machine 等等

    • 基本上这些算是笔者花了钱才解决的需求吧,如果按照以往自己只做开发的话,以上这些自己都能手撸,但是无奈,做独立游戏不能只专注在技术上,还有很多其他事情要做,所以这些方案能买就都通过花钱解决了,独立游戏,时间是稀缺资源。

    这个是独立游戏制作的时候遇到的需求,好在都有对应的不错的方案,但是 QFramework 没有支持这些。

    除了制作独立游戏,自己做独立游戏的课程也需要以上的这些工具的,否则,这些要么在课程里从头手敲出来,要么告诉童鞋去卖这个插件那个插件,课程里用这个插件那个个插件的,这两种都不太好,全都手敲课程猴年马月能完结?如果全都让童鞋买买买,本来学课程的群体是学生和刚入行的童鞋居多,基本也没什么钱,在花钱买动砸 300 ~ 400 的插件,肯定吃不消。

    再加上自己的 框架搭建 决定版 后续第四季 ~ 最终季 也需要有一些解决方案设计的案例来讲,然后前边自己做独立游戏的需求还有做独立游戏课程的需求,最终思考出来的答案,就是让 QFramework 也提供以上独立游戏需要的工具。

    于是就开始构思 QFramework 的 Pro 版本了,因为工作量实在太多,提供的功能也实在太多,而免费开源版,被抄烂了 ,所以这次就象征性地定了一个 AssetStore 的最低价,4.99 刀。

    抄可以抄,因为很多开源协议是允许抄的,但是我更希望抄也是按照开源的规矩的抄,自己抄过或者参考过就坦诚一点,别搞的抄完之后这个当作自己发明的东西了,好在这种人我也就遇到一两个,大部分朋友借鉴完,还是会厚道地给 QFramework 一个链接地址的。

    当然 QFramework 的开源版,从 19 年开始就没怎么加新功能了,首先说明版本稳定能用,其次还想说,这两年我自己代码水平进步了不少,19 年的开源版只是我 19 年的水平。19 年之后,我给一公司带了 9 个月的项目,再往后设计了决定版架构,之所以叫决定版架构,是因为这套架构的演化过程我给出了一套课,叫 Unity 游戏框架搭建 决定版,在 Unity 中文课堂有售。所以这次 QFramework Pro 会以现在的代码水平来开发,做出来应该会比 QFramework 的开源版先进很多,清爽很多,好用很多。

    由于 QFramework Pro 是在开源版基础之上开发的,所以也会慢慢把开源版的代码重新整理一下,一些积攒的小问题也都一一修复掉。

    OK,差不多到这里说清楚了,为啥要搞 Pro。

    • 自己独立游戏需要各种工具集
    • 自己的独立游戏课需要
    • 自己的框架搭建 决定版 第四季往后需要讲很多工具&方案设计的内容,刚好多积攒一些案例。

    除了这三点,还有一点,就是其实自己一直想试试在 AssetStore 出付费插件的,QFramework 的 AssetStore 在 2017 年就申请好了,当时想着以后万一自己有能力在 AssetStore 出付费插件呢,那得多屌啊,还能赚零花钱花。而现在 4 年过去了,时机刚好。刚好自己因病不能肝教程。。。也刚好自己做独立游戏《鬼山之下》开始厌倦了,一想到做鬼山之下就头疼。

    鬼山之下虽然鸽了半年,但是 steam 上的版本,是能完能通关的,这是因为游戏一开始就是能完整体验的版本了,这个在鬼山的开发日志里说过,所以鸽得再久都没事,哪天来了创作欲加上 时机不错 就接着推进呗。更何况,我现在做得每一件事情都对推进《鬼山之下》有帮助,比如 QF Pro 出来了,那么鬼山的很多工具集用 QF 我自己写的,自己写的好处就是自己魔改起来游刃有余,也更顺手。再比如 独立游戏课 会逼自己去把经验总结出来分享出来,这个对提升自己游戏制作能力是有很大提升的,在总结过程中叫不准的要看很多资料,当然持续学习是必须的,还能用这个经验换点资金,来接着推进《鬼山之下》。所以独立游戏《鬼山之下》虽然没有实际推进,但是也间接推进了,去学了 2 个月美术,双十一忙着挣钱,出独立游戏教程,写 QF Pro,都对《鬼山之下》有推进作用。

    从 3 月 1 日开发 QFramework Pro 开始,又体会到了写代码的快乐,自己骨子里还是个程序员啊,只考虑写代码真的很快乐,有点找到初心的感觉。

    会想 qframework 七年前刚开源时,写的文章时 Unity 游戏框架搭建(一)概述(现在叫 Unity 游戏框架搭建 2017(一)概述)。

    在概述里画了个大饼,从单例模式 到 ManagerOfManagers,再到 StrangeIOC、uFrame 这种 MVX 模式。QFramework 的开源版,也从最初的 Singleton 架构,慢慢发展成 Manager Of Managers 架构,再到去年年中,QFramework 系统设计架构(System Design Architecture 现在简称 决定版架构)正式完善,决定版架构 就是 和 StrangeIOC、uFrame、还有 PureMVC 这样的同等定位的架构,不过整个源码只有不到 800 行。有了决定版架构,也算是把七年前的概述走完了吧。所以走完了之后,再下一个小目标,就是笔者目前正在做的 Pro 版本。

    好了,碎碎念了很多, 感谢大家愿意看到这里。

    祝我顺利吧。

    这篇就写到这里。

    各种地址

  • 相关阅读:
    SpringBoot学习笔记
    2021牛客多校第一场 I题(DP)
    CSS小结
    AOP小结
    IOC容器小结
    Educational Codeforces Round 56 (Rated for Div. 2) G题(线段树,曼哈顿距离)
    Codeforces Round #656 (Div. 3) E. Directing Edges(拓扑排序)
    Educational Codeforces Round 101 (Rated for Div. 2) E
    [FJOI2017]矩阵填数 (容斥原理)
    优秀代码样板收集计划(python)
  • 原文地址:https://www.cnblogs.com/liangxiegame/p/15971406.html
Copyright © 2020-2023  润新知