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 Zen(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. 个人日记

    本人引用但未注明的版权资料，可邮件联系 （不是故意只是懒~）

    2025-04-28

    人还是比较懒，虽然更新了很多代码（同时维护四个以上的框架，还是没时间更新文档）每次打开又要重新组织语言，还是得保证人能看懂（尽管写的比较散）

    • 像 Anywhere 现在叫 Zen 新增了大量模块 （比如 ECS版网络Module，Multiplayer 多人联机 Module 等, 哦 当然 Kpb序列化终于实现C#版本，（基于最早的C和Go版本已经过去了近两年，所以整个来说确实 挺墨迹的， 倒不是难而是懒，总觉得同一个算法写三次感觉脑子瓦特了，哈哈~

    • skynet 最早是为了解决云风大佬一些特异化场景而驱动开发的，但现在已经完全像个学术派 （ 把Go写成浓浓的C style味），果然还是喜欢折腾

    • 前阵子翻了翻几年的库，自我感觉写的一般，又拿出折腾了一番

    • 总之尽快更新新的文档，后续先提供可用版本，至于开源的事再考虑考虑，（毕竟国内，吃干抹净，过河拆桥的人不在少数，至少本人用开源保留 copyright, 也会提 issus 促进发展 ）

  2. typelang

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

    设计缘由

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

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

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

  3. Zen Gameplay Framework

    序

    Zen 是一个基于 Unity 引擎的GamePlay框架，脱离 Monobehaviour 开发，致力简化开发流程。内部提供了一个类ECS的架构满足开发，你也可以使用自定义的上层，比如自己实现像MVCC，或者是MVC的上层封装。让开发聚焦在游戏玩法而非一些底层架构上。同时也 提供一些自定义性，不至于给予开发者太强约束性

    Zen的一些设计思想不算是纯粹的OOP，它有ECS的概念，也有type embedding的概念，而且设计概念大部分是参考面过过程和内嵌的设计思想，所以理解曲线会比较困难，但是用起来还是挺 easy。

  4. kproto 编码协议

    前言

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

    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)

  5. skynet 服务器框架简介

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

    尽管Actor模型和CSP模型各有所有长，为什么不采用CSP主要有以下方面考虑。

    1. CSP模式使用尽管很简单，但是一个致命的问题是无法控制消息的优先级，当然若只处理一个Channel那可以规避，那么为啥还需要使用CSP,而且像go channel 本身是基于互斥锁（1.16）实现，且无法进行优化和更加精细的控制，只能依赖于runtime的调度。（网上所说什么时候触发调度，我认为channel不能包含其中，它本质也是加锁导致切换）

    2. 隔离性太弱，后续一些新的channel引入也会造成破坏性修改。

    3. select-case模式会随着等待数量的增加性能会慢慢减弱。

    4. channel 多大合适？

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

Less
More

Post activity