整体定位

  在现在游戏引擎非常丰富的时代,开发一个没有新概念的引擎是没有什么意义的. 所以我这里使用了一些非常激进的概念. 新引擎名称暂定为`Seija`.Seija是一个基于`函数式语言`的,使用`FRP`概念进行逻辑开发的2d为主的游戏引擎. 之后一切的设计都是围绕着这个中心点出发的. 
  同其他把简单易用当作主要特色的引擎不同,Seija并不会特意去追求`简单`,而只会追求`对所在领域最贴合的描述方式`,如果本身问题复杂度就特别高,并不会做任何多余的事情使问题进行所谓的"简化".

   Seija是一个2d为主的游戏引擎，引擎整体使用模块化方式构建，3D渲染可以后期进行扩展，但不是主要目标。引擎更多的关注`UI`和2d渲染部分。

技术选型

   引擎底层语言选用`Rust`,脚本语言选用`purescript`. `purescript`是一门编译到`JS`的语言所以我们可以使用JS引擎来承载它.同时`purescript`的语法非常类似于`Haskell`,只不过他默认不是`Lazy`的,也不需要语言运行时(GHCJS需要),所以编译出的JS非常简单易读. 

JS脚本引擎问题

   JS引擎暂定为选用[QuickJS 关于JS引擎一直无法找到更好的性能的解决方案.    
  第一个问题是purescript, 因为是一个纯函数语言他的编程方式和JS是完全不一样的,他虽然能编译成JS但是性能会比原生JS有一定的损失.最好的解决方法是为purescript专门写一个虚拟机,根据purescript的语法对这个虚拟机进行专门的优化(<del>然而我写不出来</del>).

  第二个问题是JS引擎在不使用nodejs的情况下比lua要慢很多.但是nodejs整个引擎又太大的,显然是无法塞进去的.然后就是JIT问题,主流的JS引擎默认都是使用JIT模式,但是IOS是并不允许JIT的,如果把主流JS引擎的JIT关掉,面对他们庞大的尺寸,还不如直接使用没有JIT的小巧的 QuickJS.

  其实purescript也是可以编译到lua的但是编译到lua的后端非常不成熟并且作者已经弃坑了(<del>我也接不下来</del>). 

FRP的实现问题

  这可能是`Seija`最独特和核心的地方了,因为这个概念提出的时候考虑的只是逻辑问题,并没有关注过性能问题, 其他部分估计要为了这部分做特定的优化. 这里所说的FRP基本概念整体类同于reflex-frp,这个FRP库是我所见过的最接近FRP本来概念的FRP库,但是实用性方面不太好,`Seija`会做一些改进.  

  FRP详细介绍可以参考我的这篇博客http://yangdao.fun/article/15

周边工具链

  要知道引擎周边的工具链也是非常重要的部分,这里遵循的原则是周边小工具尽量都开发成一份动态链接库模式供其他语言调用, 一份包装成命令行工具.  不依赖于引擎本身,即使不使用引擎本身周边工具也能成为其他领域的通用工具.

  关于编辑器,这里先不做考虑. 最理想的情况是UI部分开发完能用自己开发自己的编辑器. 现在唯一想到的一个目标是能像emacs那样,拥有高强度的可扩展性.

并非从零开始

我并不会完全的从零开始,造一些重复和低效的轮子. 游戏引擎发展这么长时间,很多概念模块和最佳实践都几乎已经定型了, 对于那些繁杂和已经没有争议的模块我们会使用现成的代码,例如渲染这块不但会使用[gfx](https://github.com/gfx-rs/gfx)这种多后端的支持的抽象层API,而且还会使用[rendy](https://github.com/amethyst/rendy)这种`Frame Graph`的渲染框架.  为了性能考虑还会在引擎层使用 [Specs](https://github.com/amethyst/specs)这个并发的ECS框架.