引擎

姗姗来迟的续篇不是么（笑）。嗯哼，不要在意上一篇充满忧郁的离别气氛～～～ 这一篇是新增语法的设计和解释，分别是立绘的绘制（渲染？或许用render更靠谱？)语法和跳转指定帧的语法。前者很麻烦，后者很简单。 所谓人物立绘，galgame游戏中，就是人物的肖像，一般来说就是对话对方的肖像。非gal玩家估计比较难想象……有兴趣的话可以查一下相关定义。顺便，虽然不是gal，但是东方的zun绘，依然是人物立绘…… 值得注意的是，人物立绘出现的频度很频繁，这就要求语法定义必须要很简单。但是问题是，立绘的渲染本身需要的参数就很多，这算是一个不大不小的矛盾。 如果对立绘参数要求很多这一点有异议，请仔细考虑一下。人物立绘的渲染，到底需要哪些参数：本地人物图片的右下角（切割图片位置），缩放大小，屏幕位置。对吧，至少需要三个参数。为了简便起见，后面也只考虑这三个参数。 考虑需求的频度较高，使用[xxxxxx]语法就过于麻烦了，这里我使用{}来标明立绘的语法域。 因为立绘有几个特征：同样的图片可以在画面移动（用来表现走路啊什么的）；同样大小的图片，虽然位置不动，但是图片本身改变了（人物表情变化）；图片和图片位置（中心位置）不改变，大小变化（人物由远及近）。处于便捷性考虑，每次都填写同样的东西并不爽，于是允许缺失值，缺失值会直接使用之前一帧的值，这样的思路要好一点。不太好理解？请看一下我定义的语法吧： {

因为明天回学校了，所以项目也暂时不会动弹什么了，值得庆幸的是，总算在走之前初步写完了整个项目，虽然bug遗留下不少……嘛嘛，反正呢，这篇也就是类似于第一部大结局般的存在。 这篇讨论的内容是save和load功能。事先说明，这部分代码赶工出来的，并且我对这部分内容没有一点积累，代码质量很糟糕，并且由于没有大量的测试，也不好说会在哪里出现问题。事实上，就我测试的结果来看，有可能会出现index没法找到的情况，原因尚不明朗。站在现在的角度来看，使用状态机或许能解决不少逻辑混乱的问题，遗憾的是我这里没时间了…… 言归正传，我这里谈谈自己的思路，请随意指出我的疏漏、不足和错误，如果有更好的解决思路和方法我会相当感激的。 一般来说，不管是save还是load，都是需要切换界面的。老实说，切换界面这个行为也就是把新界面的图片覆盖在屏幕上就好，真不太费事儿。但是要发生切换这个动作，就需要按下按钮不是么，所以首先从按钮开始。 这里给出我这里的效果图……如你所见，右边那两个丑丑的按钮就是了，当然为了完成这个目标，位置要反复调试好，且不多说了，代码很容易。其实也就是NodeItem每次渲染的时候多渲染两个按钮就好了…… def __initSettingButtons(self): dic_settingButtons = {} dic_settingButtons['save'] = Button((

正如上一篇所见，试验代码相当丑陋，效果也极度不堪……而且内部代码全部暴露，甚至没有一个接口，增添功能时也必然是伤筋动骨。于是，这一篇的目标是： 1.对代码进行封装，并且代码中不能出现常量或常量字符。 2.增加异常的处理----主要是pygame的异常 说起来，对异常貌似有一个讨论，出自joel？不太记得了，大意是异常不是必要的编程元素。对于这一点，我持保留态度，个人认为引入异常能使得错误更容易被定位，给用户的提示也更加友好，还可以通过引入各种异常来提供某些特定的功能。请大家也仁者见仁。说到joel，那本《More Joel on Software》还是相当不错的一本书，适合吃饭后读着玩，因为其相当易读。Joel的话，这里有一篇他的文章，真的推荐看看： 我的七个建议 。 貌似我总是习惯性离题？ 恩恩，封装的话，得先明确封装那些元素。对galgame来说，这倒是一个易于回答的问题，而就目前的进度而言，更是一个易于回答的问题：需要封装的元素是 背景图片，背景音乐，剧情文本。 Ok，那开始吧。 首先，为这个封装类起一个恰当的名字？我是随手用了NodeItem这个名字----估计是Sakia的影响……说到Sakia，guochaoer君在定义的时候，把文本，图片，音乐都各自用一个类来封装起来，并且都继承自pygame.Sprite.sprite。这当然是一种不错的思路，很清晰。但是我觉得

上一篇主要涉及的其实是我个人的一些初期目标，以及解决方式。虽然提了提Parser类的实现，但是代码毕竟不是主要讨论的对象。而且很明显的，上一篇几乎与galgame制作无关…… 这一篇主要讨论的实现，中心目标是实现一个“能显示背景图片，播放背景音乐，如同galgame般显示文本”的试验程序。称之为试验程序的主要原因是：它的代码可能很乱，命名也是随意命名的，无视耦合……这部分代码只用来显示相关代码是否正常运行------不过说起来，大多数人都是这样做的？ 上一篇忘了说，这个项目已经完成的部分我已经上传至github（最近应该没问题了吧？），有兴趣的欢迎围观和clone，branch也是大大欢迎的。地址是这个： 项目地址 。 关于git已经github的使用，有需要的话，请看一下这篇博客 git教学 ,或者看看官方的文档。 不多说了，接下来是正文部分。 上一篇中，通过Parser类，可以得到三个变量，分别是背景图片的名字，背景音乐的名字，和剧情文本的内容，但是我不准备引用这三个变量。原因是，文件读入的文字，会受操作系统的文字编码影响。当然一般来说是没问题的，但是若是编写跨平台的程序时，就会很麻烦。最终完成的程序是能够跨平台运行的，文字编码这部分当然使得我很是困扰，这部分说长不长，说短不短，我留到最后来说说。 后面的内容涉及了许多pygame的内容，官方文档很棒

来来来，最后一点东西。扯完了这个系列就暂时结束了，然后我就可以滚去再次开始憋代码……当有了比较大的更新或者长了比较大的姿势的时候，这个系列还会更新。极有可能的是，前几篇讨论的东西，会推倒重来一部分……嘛，都习惯了是吧？ 这篇文章讨论两个问题： 1.跨平台的字符编码 2.文本框中字符对齐 python字符编码问题一直是个痛----我不太清楚别的语言是否也会纠结这个（貌似我记得php会？昨天看的那个神翻译文章php迎风撒尿什么的，印象深刻）。以前我在写另一个程序的时候，用了一点小手段解决了跨平台print输出的问题，但是同样的方法，对于文本读取的编码问题是无能为力的。 python的编码问题，开源中国有一些很棒的文章，请围观： Python、Unicode和中文 这篇也不错： 转-Python Unicode与中文处理 相比起上面那些研究独到的文章，我这里只是一个小方法而已，恩，就这样。 众所周知，linux下字符编码通常是utf8，windows是gb2312，linux的行尾是\n，windows是\r\n。windows下，直接读取linux系统编辑过的文本，全是乱码。反之亦然。通常使用的方法,比如很容易看见的这个:a.decode('gb2312').encode('utf8') 事实上我试验的结果来看，真不太好用。我用print测试过，windows下，直接 open(