notice
网站的繁荣,有赖于每个人的参与
2013年2月26日 | 分类: Network | 标签:

  这篇的目的是让你在github上的readme看着尽可能舒适,而不至于被留下为”F*ck”的奇怪评论。

  简单说说github的MarkDown吧……这货的存在直到昨天我才注意到,我就说奇怪了,为什么github上那些兄台,个个README都写得异常漂亮,而我的就几乎是一坨SHIT。嘛,原因就是这货了,具体的概念什么的请查阅wiki,Markdown。顺便说一句,目前这个时间点我异常讨厌谷歌亲切的拼写纠错功能。因为这货,让我一直把名字记成Makedown而浑然不觉……

  wiki上的那个只是各种markdown的超集,应该不同的地方有不同的规定来着?反正就我所知道的,github扩展了不少内容。这篇中不会涉及所有的语法,随意写写我涉及到的。不满足的话看看这个吧—-github’s markdonw

  这里随便发发牢骚:为什么学物理的计算机都那么牛B!!?认识好多个人了,很多都是学物理的。真这样下去,真担心计算机科班家伙们的前程。嘛,说到这里,说明一点,我虽然也几乎算是学物理的,可是[……]

Read more / 查看全文

2013年2月17日 | 分类: Python | 标签: , ,

  因为明天回学校了,所以项目也暂时不会动弹什么了,值得庆幸的是,总算在走之前初步写完了整个项目,虽然bug遗留下不少……嘛嘛,反正呢,这篇也就是类似于第一部大结局般的存在。

  这篇讨论的内容是save和load功能。事先说明,这部分代码赶工出来的,并且我对这部分内容没有一点积累,代码质量很糟糕,并且由于没有大量的测试,也不好说会在哪里出现问题。事实上,就我测试的结果来看,有可能会出现index没法找到的情况,原因尚不明朗。站在现在的角度来看,使用状态机或许能解决不少逻辑混乱的问题,遗憾的是我这里没时间了……

  言归正传,我这里谈谈自己的思路,请随意指出我的疏漏、不足和错误,如果有更好的解决思路和方法我会相当感激的。

  一般来说,不管是save还是load,都是需要切换界面的。老实说,切换界面这个行为也就是把新界面的图片覆盖在屏幕上就好,真不太费事儿。但是要发生切换这个动作,就需要按下按钮不是么,所以首先从按钮开始。

  这里给出我这里的效果图……如你所见,右边那两个丑[……]

Read more / 查看全文

2013年2月16日 | 分类: Python | 标签: , ,

  姗姗来迟的续篇不是么(笑)。嗯哼,不要在意上一篇充满忧郁的离别气氛~~~

  这一篇是新增语法的设计和解释,分别是立绘的绘制(渲染?或许用render更靠谱?)语法和跳转指定帧的语法。前者很麻烦,后者很简单。

  所谓人物立绘,galgame游戏中,就是人物的肖像,一般来说就是对话对方的肖像。非gal玩家估计比较难想象……有兴趣的话可以查一下相关定义。顺便,虽然不是gal,但是东方的zun绘,依然是人物立绘……

  值得注意的是,人物立绘出现的频度很频繁,这就要求语法定义必须要很简单。但是问题是,立绘的渲染本身需要的参数就很多,这算是一个不大不小的矛盾。

  如果对立绘参数要求很多这一点有异议,请仔细考虑一下。人物立绘的渲染,到底需要哪些参数:本地人物图片的右下角(切割图片位置),缩放大小,屏幕位置。对吧,至少需要三个参数。为了简便起见,后面也只考虑这三个参数。

  考虑需求的频度较高,使用[xxxxxx]语法就过于麻烦了,这里我使用{}来标明立绘的语法[……]

Read more / 查看全文

2013年1月29日 | 分类: Python | 标签: , ,

  来来来,最后一点东西。扯完了这个系列就暂时结束了,然后我就可以滚去再次开始憋代码……当有了比较大的更新或者长了比较大的姿势的时候,这个系列还会更新。极有可能的是,前几篇讨论的东西,会推倒重来一部分……嘛,都习惯了是吧?

  这篇文章讨论两个问题:

  1.跨平台的字符编码

  2.文本框中字符对齐

   

  python字符编码问题一直是个痛—-我不太清楚别的语言是否也会纠结这个(貌似我记得php会?昨天看的那个神翻译文章php迎风撒尿什么的,印象深刻)。以前我在写另一个程序的时候,用了一点小手段解决了跨平台print输出的问题,但是同样的方法,对于文本读取的编码问题是无能为力的。

  python的编码问题,开源中国有一些很棒的文章,请围观:Python、Unicode和中文 这篇也不错:转-Python Unicode与中文处理

  相比起上面那些研究独到的文章,我这里只是一个小方法而已,恩[……]

Read more / 查看全文

2013年1月28日 | 分类: Python | 标签: , ,

  这一篇主要讨论的内容是帧的切换以及按钮的处理。

  这个帧,并不是普遍意义上的帧数什么的,事实上,这货是我自己定义的一个概念。如果你不明白帧是什么,请务必再看看第一篇的内容,这个术语在那里我定义过了,这里不累述。

  前面三篇所讨论的东西,合起来做出来的效果也只是一个静态的无趣玩意,完全不能被称作galgame。但是,使用第三篇所封装的类,实现一个真正的galgame其实很容易。事实上,我们可以把一帧和一个NodeItem类等同起来,每一帧其实就是一个NodeItem的实例调用update方法而已。这样的话,切换帧的过程也就可以等于对NodeItem值进行更新的过程。而需要的值,都已经包括在一个待解析的字符串列表里面了。只需要对每一项进行解析,再对NodeItem赋值,更新过程就完成了。OK,现在,所有的材料貌似都已经准备完成,也许应该开始写代码了?

  且慢,为了更好地实现“动起来”这一目标,需要引入一个玩意,或者说概念:Frame Index。嘛,虽然这货也是我随意取的名字……但是,正如分析的[……]

Read more / 查看全文

2013年1月27日 | 分类: Python | 标签:

  正如上一篇所见,试验代码相当丑陋,效果也极度不堪……而且内部代码全部暴露,甚至没有一个接口,增添功能时也必然是伤筋动骨。于是,这一篇的目标是:

  1.对代码进行封装,并且代码中不能出现常量或常量字符。

  2.增加异常的处理—-主要是pygame的异常

   

  说起来,对异常貌似有一个讨论,出自joel?不太记得了,大意是异常不是必要的编程元素。对于这一点,我持保留态度,个人认为引入异常能使得错误更容易被定位,给用户的提示也更加友好,还可以通过引入各种异常来提供某些特定的功能。请大家也仁者见仁。说到joel,那本《More Joel on Software》还是相当不错的一本书,适合吃饭后读着玩,因为其相当易读。Joel的话,这里有一篇他的文章,真的推荐看看:我的七个建议

  貌似我总是习惯性离题?

  恩恩,封装的话,得先明确封装那些元素。对galgame来说,这倒是一个易于回答的问题,而就目前的进度而言,[……]

Read more / 查看全文

第 1 页,共 9 页123456789