-
makefile 很早就想写了,高阶概念总是忘了又忘,一千个人一千个哈姆雷特,理解抽象概念的方式各有不同 What’s makefile?
-
序
对于一个源码文件而言,里面的内容只是一个个字符,机器是无法识别的,而词法分析器的作用类似于转义器,将一个个字符拆成若干个有特定意义的词,而这一过程称为词法分析,此时它也不能被机器(或者这个虚拟机)识别
-
这篇文章将会是一个系列,更新会比源码慢,文档写的也不会写的很完全,名字暂定
typelang
, C syntax-like设计缘由
早在2019之前就想开发一门脚本语言,一是加深编译原理的理解,二是觉得程序员不应该消耗在语言特性上,也一直想为自己的服务端框架 skynet-go 写一门dsl,现在是用lua作为服务的脚本端。但由于的若约束性导致在开发的时候很多同时并不够优雅,总是以一种奇怪的方式来解决问题,Lua本身并没有任何问题,它被设计之初是为了修补C的不足,但它的语法设计却并不符合我的预期。
尽管它的性能是脚本语言中顶尖的,但是一些隐式写法并不能保证它的预期性能,如混合
table
,过多的函数调用栈,字符串操作以及无类型系统。关于类型系统有利有弊,但我个人的观点是宁愿多出30%的开发时间,从而减少70%的bug。
-
序
Anywhere
是一个基于 Unity 引擎的GamePlay
框架,脱离 Unity 本身的开发方式,致力于采用无感开发的方式(极少的父类需要继承,无关乎生命周期),内部并提供了一个ECS
的上层抽象来开发它,但事实上你并不一定需要使用这个ECS
,你也可以使用自定义的上层,比如自己实现像MVCC
,或者是MVC
的上层封装。设计目标
-
无框架化,它之所有不提供是为了更好的设计出不同品类的游戏,而我在近10年的游戏开发生涯中,我始终觉得框架的约束即使最大的约束,因为业务的多样性和非明确性的特点,一般游戏后期的一些奇奇怪怪的需求总是会迫使你绕过框架的约束从而形成屎山code,所以我希望
Anywhere
框架本身可以尽可能的简单,让开发者可以自由的去选择框架的约束。你可使用Anywhere
的一部分,或者全部,甚至是都不需要。 -
无
MonoBehaviour
编程设计,解除引擎原始的约束,更自由的编程方式,像之前开发游戏,一个角色身上可能挂在各式各样的组件,一旦后期业务变动很容易出现引用丢失或者维护起来更为困难,而且一些特殊的时候可能还需要设置一下脚本的执行顺序,给维护带来巨大的不便(如我之前所呆的项目各种口口相传的细节规范,让开发痛不欲生) -
模块化,
Anywhere
的一大特色,以像C library
的方式来组织模块,让模块之间可以互相调用,并且可以互相替换,让开发者可以自由的去选择模块的约束。选择何种内置模块,或者是自定义模块由开发者决定,这也是使用Anywhere
唯一的约束,你的模块可以是框架,也可以是Module
。 -
简单化,
Anywhere
本身只提最必要的一些基础组件,你可以重新实现,而并非是必要的,就是这么随意,就像它的名字一样。 -
自由化,游戏开发是自由的,是创造性的,
Anywhere
不会约束你干什么,你只需要关注你的想法,怎么做取决于你的点子。 -
去屎山,一旦使用
Anywhere
的Module
约束,那么它一定是强类型约束,这么做的目的是让业务不容易形成屎山,避免屎上添粪的情况出现(我所在的一些项目就是这样,后期持续性优化,由于业务量巨大,实难以支撑) -
非文档约束性组件控制器绑定,面向对象的模式必然导致代码变得复杂,因使用内嵌代替
OOP
,但显然C#做不到,需要额外的封装,但过于麻烦不符合Anywhere
的设计哲学,故通过静态泛型约束实现。 -
无任何反射调度,提高代码的运行速度。
-
Hybrid
集成(todo) -
开源,
Anywhere
很快将会进入开源状态。
-
-
简介 DatatableModule 是一个基于 kpb 编码的配置文件管理系统,它定义了一个配置文件的数据结构,并提供了相应的API来操作和访问配置文件。在Anywhere中它是一个GameModule。 Feature lazy load,它不会加载所有表格在开始的时候,而是按照需要动态一部分一部分的加载 DatatableModule 加载接口提供同步和异步两种模式,也可以加载远程资源,依赖于 RMS DatatableModule 提供代码和数据生成的编辑器,无需关注实现逻辑。 通过 GameModule.GreateOrGet<DatatableModule>.Get<T>(index) 直接获取表格行数据 多种类型数据支持 bool,int,float,string,binary,int*,float*,string*,满足绝大部分场景 基于kproto编码协议,极小的二进制文件 栈内存映射,大部分情况下不需要开辟堆空间,节省一部分内存的分配,减少Mono Reserved的分配。
-
序 这篇文章仅仅是介绍如何使用Anywhere 集成 ECS 框架,ECS并非必须的,甚至可以无框架化,就像我们第一次做Demo的时候一样,不要迷信框架,发挥自己的想象力去开发一个好玩的游戏才是最重要的,需要注意的是,本篇ECS并非是unity的ECS,它没有burst,也没有job system,而是一种设计思想。 本编会按照ECS的定义手动实现一个ECS框架,会有自己的一些设计糅杂在一起。 架构 System System 用于描述一个实体的行为,比如MovementSystem,AnimationSystem等,System 之间可以相互组合,比如MovementSystem和AnimationSystem组合在一起,就是一个CharacterController Component Component 用于描述一个实体的状态,比如Transform,Rigidbody,Animator等,Component 之间可以相互组合,比如Rigidbody和Animator组合在一起,就是一个Character,Component 之间可以相互组合,比如Rigidbody和Animator组合在一起,就是一个Character,Component 之间可以相互组合,比如Rigidbody和Animator组合在一起,就是一个Character Enity Entity 用于描述一个实体的状态,比如Transform,Rigidbody,Animator等,Entity 之间可以相互组合,比如Rigidbody和Animator组合在一起,就是一个Character,Entity 之间可以相互组合,比如Rigidbody和Animator组合在一起,就是一个Character, Chunk Archetype