galgame

FProject_《galgame engine》篇

烂漫一生 提交于 2019-11-29 10:45:07
原项目日志(已荒废): http://hi.baidu.com/new/gal123 FProject: http://dl.vmall.com/c0xxq2qowq 全版本下载(目录,可选): http://dl.vmall.com/c0dd1sq75l FSC(最近无聊写的):命令行下的脚本游戏引擎(lua+bass),演示了bass的网络音乐库功能 FS0.04版:最早的前期版本之一 FS0.053版:尝试着写的超短缘之空同人 FS0.09版:比较接近成熟的一个版本,同样尝试着写了一个演示小剧本 FS0.15版:非常成熟的一个版本,第一次写了一个较为长的剧本(同为缘之空同人),30K的文本量,用一个礼拜的空闲时间吐出来的,。。——,= EXTRA音乐包:无聊写的一个有点仿OSU界面的音乐播放器(?=。=) FS0.2版:暑假因为胃病而没有继续发展下去的一个版本,仅仅是一个演示,第一次加入lua支持 转载于:https://my.oschina.net/gal/blog/200194 来源: https://blog.csdn.net/chenlian2409/article/details/100790328

python制作galgame引擎(五)

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

python制作galgame引擎(六)

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

python制作galgame引擎(三)

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

python制作galgame引擎(二)

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

python制作galgame引擎(一)

房东的猫 提交于 2019-11-28 21:21:02
写这个项目的直接原因是最近推galgame推得有点过头,gal推过头的直接结果就是YY能力上涨,抱着“我也想写好玩的剧本”的轻率念头,也就开始了这个项目。不过从直接感觉来说,galgame毕竟也是开发成本(个人)以及技术要求最低的游戏类别之一,这当然也算是原因。 于是到了现在,一个半成品式的框架就搭好了。实话实说,gal引擎开发,技术难度不算大。但是,需要考虑的方面却相当多,许多看起来很简单的东西开发起来却很麻烦,看上去很麻烦的东西只要换个思路,就会大为简化。 这篇文章涉及的只是一个Galgame引擎,剧情和素材方面,直接使用guochaoer君的Sakia。后者是一个自制的galgame,在google code上托管,开发时间先于我一年。guochaoer君的代码,给了我不少思路和代码方面的启迪,在此给予深深感谢。有兴趣的话,请务必拜会guochaoer君的项目,地址 Sakia 不多说了,现在考虑引擎的编写。 我们需要几个初期的目标,我的初期目标为: 1.一个能稳定运行的,可扩展的框架 2.代码逻辑和剧情内容彻底分开 第一个目标是显然的,关键是第二个。之所以提出这个目标也正是因为guochaoer君的代码,他的代码实际上写得不错,但是最大的弊病是代码和剧情文本混在一起,整体上来看,就显得比较凌乱,耦合度太高。这样做还导致一个问题:代码扩展性不太好。如果后面需要增添功能的话

python制作galgame引擎(EX)

浪尽此生 提交于 2019-11-27 14:58:01
来来来,最后一点东西。扯完了这个系列就暂时结束了,然后我就可以滚去再次开始憋代码……当有了比较大的更新或者长了比较大的姿势的时候,这个系列还会更新。极有可能的是,前几篇讨论的东西,会推倒重来一部分……嘛,都习惯了是吧? 这篇文章讨论两个问题: 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(