已被分离到了 ./original_project.md
这对我来说是一个游戏，又或者是一个引擎
不要将无关的函数公开到头文件，尽量保持公开元素只需要简单调用就能自初始化所有需要的成员临时变量
仅管理所有场景单元的顺序，也就是在管理对话树
在讨论游戏一切以前，作为一个练习项目它的 UX 其实早已被我固定好了——长得像传说之下的文字冒险游戏/互动小说。
我比较讨厌写的垃圾的 GUI 软件，也对自己的水平有些清醒的认知，所以这次所有的想法都会在 TUI 中尝试实现。
但我并不想过于含糊，TUI 虽然有些简陋但上限并不那么低，比如文字的类抖动、颜色变换、控制间隔实现的喘息，都是很轻松就可以做到的目标。
所以，我们要从哪里开始呢...
模块化是我在开始整个项目之前就意识到了的问题，谁也没法保证我不会给这个游戏添加第二段对话树。
C 是一个极其面向过程的语言，但其设计又可以有些模块的身影（翻译单元与链接）。这时想实现模块化的第一反应自然就会是将整个场景完全分离到不同的 .c 中了，这么做真的好吗
ncurses 是整个项目中最核心的依赖库，想要在这么多的嵌套中保证界面渲染不出错我认为是有些费劲的，加之可能的指针传递很有可能会将整个程序变成比原始项目还差的东西
但由于要用 ncurses 实现很多功能，所以每个场景都几乎必须拥有操纵有限的光标空间的能力。
并且这些功能有很多可能会是重复功能（例如短暂的文字变色），那么现在的项目结构应该会是...
- main.c -> call scene functions
- scene1.c
- scene2.c
- utilities/ -> storge common features
- func
- func...
这是基本框架，现在聊聊 dialogue event（对话事件） 吧。
由于设想中的对话窗口会有些怪怪的特效，加之我不喜欢任何形式的转义字符，我便想用分段储存一段对话的方式解决问题。
比如，xxxyyyzzz 中 xxx 是普通文本，则将其标记为普通文本，yyy 可以标记为需要慢速打印的文本，zzz 可以被标记为有反色衬底的文本，整个段落就被分割成了三个结构。
这么做大概是为了直接用 C 的结构体完成目标并且可以简单的从标记语言转换（虽然我不是很想做这个）
但，我会把场景做的更大的对吧，我甚至都想做一个《我的小鲨鱼》出来了，这种情况下场景应该也要拥有掌控整个窗口（ncurses 中的概念）的权力。
如果要这么做，main 函数将只能控制场景的输出大小，不过可能只有调试模式会用到了吧...
相对的，场景将可以实现更多更多的窗口变化甚至完全自主的小程序，而非简单的输出部分对话。
这听上去挺符合 scene/场景 的概念的，不过需要更多的文档层面的约束才能保证代码的可读性。
比如，所有场景间的切换需要尽量由 main/或第三方 函数调度，只有极其特殊的情况下才能多次嵌套
我真的把握的了这么大的东西吗...