Avatar
😀

Organizations

README.md

About me 👋

  • I love games, I love coding, and I’m interested in games, computer principles, and operating systems.

  • I often use go,c, csharp,lua to develop some frameworks and tools, and now I am working on arm and rust.

  • I developed the service framework skynet-go(based on cgo) and the game framework Anywhere(based on Unity3d).

  • I also developed an register base scripting language (scriptc).

  • Also wrote a new coding protocol (kproto) which is faster than protobuf-v3.

  • 👋 The above, they are not open source yet and may be in the future, but most of the technical theories can be found on my website

Link

Repo

Domyson’s GitHub stats

Thanks

supported themes

Pinned

  1. typelang

    这篇文章将会是一个系列，更新会比源码慢，文档写的也不会写的很完全，名字暂定 typelang, C syntax-like

    设计缘由

    早在2019之前就想开发一门脚本语言，一是加深编译原理的理解，二是觉得程序员不应该消耗在语言特性上，也一直想为自己的服务端框架 skynet-go 写一门dsl，现在是用lua作为服务的脚本端。但由于的若约束性导致在开发的时候很多同时并不够优雅，总是以一种奇怪的方式来解决问题，Lua本身并没有任何问题，它被设计之初是为了修补C的不足，但它的语法设计却并不符合我的预期。

    尽管它的性能是脚本语言中顶尖的，但是一些隐式写法并不能保证它的预期性能，如混合table,过多的函数调用栈，字符串操作以及无类型系统。

    关于类型系统有利有弊，但我个人的观点是宁愿多出30%的开发时间，从而减少70%的bug。

  2. anywhere 客户端框架概述

    序

    Anywhere 是一个基于 Unity 引擎的游戏框架，它被设计成无感知框架的框架（没有打错，事实上我也无法找出一个抽象的词语来形容这套抽象的框架），脱离 Unity 本身的编码方式，致力于采用无框架化开发的方式，内部提供了一个ECS的上层抽象来开发它，但事实上你并不一定需要使用这个ECS，你也可以使用自定义的上层。结合RMS、Datatable、Network等模块来开发你的游戏，这些模块都是可以单独使用的，并且可以和ECS模块进行无缝结合。你也可以自己实现像MVCC，或者是MVC的上层，只要符合Anywhere的规范就可以和Anywhere框架进行无缝结合。

    设计目标

    1. 无框架化，它之所有不提供是为了更好的设计出不同品类的游戏，而我在近10年的游戏开发生涯中，我始终觉得框架的约束即使最大的约束，因为业务的多样性和非明确性的特点，一般游戏后期的一些奇奇怪怪的需求总是会迫使你绕过框架的约束从而形成屎山code，所以我希望Anywhere框架本身可以尽可能的简单，让开发者可以自由的去选择框架的约束。你可使用Anywhere的一部分，或者全部，甚至是都不需要。

    2. 无MonoBehaviour编程设计，解除引擎原始的约束，更自由的编程方式

    3. 模块化，Anywhere的一大特色，以像C library的方式来组织模块，让模块之间可以互相调用，并且可以互相替换，让开发者可以自由的去选择模块的约束。选择何种内置模块，或者是自定义模块由开发者决定，这也是 Anywhere 唯一的约束，你的模块可以是框架，也可以是Lib。

    4. 简单化，Anywhere 本身只提最必要的一些基础组件，你可以重新实现，而并非是必要的，就是这么随意，就像它的名字一样。

    5. 自由化，游戏开发是自由的，是创造性的，Anywhere 不会约束你干什么，你只需要关注你的想法，怎么做取决于你的点子。

    6. 去屎山，Anywhere尽可能提供一种自由约定而非规定来让业务不容易形成屎山，避免屎上填粪的代码出现

    7. 非文档约束性组件控制器绑定，面向对象的模式必然导致代码变得复杂，因使用内嵌代替OOP，但显然C#做不到，需要额外的封装，但过于麻烦不符合Anywhere的设计哲学，故通过静态泛型约束实现。

    8. 无任何反射调度，提高代码的运行速度。

    9. Hybrid集成（todo）

    10. 开源，Anywhere很快将会进入开源状态。

  3. kproto 编码协议

    前言

    其实在cobweb之初就设计了一种编码协议(kproto)，用于内部消息的编码,但因为公司项目长期需要维护以及开发（两款线上，一款开发中），所以一直未对此库进行维护， 而后期在研发的时候，发现需要与多种语言交互，显然 json,xml 不是一个很好的选择，而 protobuf 对弱类型语言支持不友好。

    Benchmark

    • cpu: Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
    • os: windows11
    • arch: amd64
    format compress rate encode rate decode rate
    json std 0% 0%( 213.8 ns/op) 0%(1204ns/op)
    proto v3 -40% -51%(98.36 ns/op) -84%(190.1ns/op)
    kproto -40% -76% (65.21 ns/op) -95%(62.18ns/op)

  4. skynet 设计初衷以及特性

    概述

    skynet 是一个基于消息和服务的Actor分布式服务框架，采用go编写，致力于简化开发难度和成本。

    它是一个年轻的框架，仅仅经历了两款项目的迭代 现在版本为 v1.6.0 2023-05-28

    设计目的

    1. 过往的工作中曾经开发了一个cobweb的分布式服务器框架（基于golang,c）,但是在实际开发过程中代码难以维护以及更新，主要是每次都需要跨平台进行编译，特别是cgo 往往需要指定平台的系统库,而且一些不规范的使用方式造成无法充分发挥多核的优势，可以参见 关于Go协程的思考 虽然1.16 支持抢占式，但错误的使用方式依然造成了cpu过高的问题。

    2. 再者，服务器过多的 goroutine 被创建，极大浪费了内存以及cpu。我不希望滥用协程，其代价比预估的要高。

    3. 由于以上目的，重写了cobweb 的底层，底层对用户不再透明。而是通过脚本语言导出来提供支持

    4. 包括后续的DSL

    5. 在2024/03我重新用C实现了一版以提供更好的性能和更底层的控制

Less
More

Post activity