通常说来, 第三人称 2D 游戏中通常把景物和精灵分开处理 (至少我是这样的) 尤其是游戏机上, 硬件对精灵有支持. 现在我们的显卡多也支持显存间的 keycolor 检查 Blt 操作, 实际就是用来加快精灵处理的 (也包括景物) 　　精灵在运动时, 往往是基于像素的 (虽然有人喜欢简化设计, 精灵在停止的时候仍旧是站在格子里) 而景物却是静止在格子中. 如果能使用更有针对性的方法分别绘制, 将

三月二十九日 至四月一日：场景显示及行走系统如果说‘消息处理’是整个程序的核心！那么‘场景显示及行走系统’就是整个游戏的核心。因为作为RPG游戏，其所有事件的发生几乎都是和场景有关，例如：不同的地方会碰到不同的敌人、与不同的人对话得知不同的事情、在特定的地点才能找到宝物等等，所有的这一切都说明‘场景’在一个RPG游戏中的重要地位。鉴于这部分的重要性，我们可再将它划分为：背景显示、行走 和 事件发生

斜视角已经成了目前RPG游戏的一个标准，它比普通的垂直视角在视觉表现方面要更胜一筹，但是也带来了一些不便。 　　先讲一下地图的拼法。现在的RPG、战棋和即时战略游戏的地图还是用一块一块的小图素（Tile）拼起来的，这样主要为了节省内存，但对美工的要求要高一些。而且斜视角的Tile是一个菱形，比之垂直视角的矩形Tile拼起来要复杂一些。 　　假设我们每个地图单元（即是下图中红线框出的一个矩形）的大小

遮挡的判断是游戏里非常繁琐的一个工程，但又是必不可少的。否则每次只要有一个东西移动，就要重画整个屏幕，这样好象有点得不偿失了。在3D技术中，就有什么画家算法、Z-Buffer算法、BSP树等很多消隐方法。在这里面我们不用这么烦了，我们把地图都分成一个一个的Tile，这样并不仅仅可以节省空间，在物体的遮挡判断上也容易得多。　　当然这有需要一点点投机取巧的方法。如图，在斜视角游戏里，每个物体都被包含在

有人在新浪网的游戏制作论坛问这个，那我随便说说这个问题的解法，先看看地图元素：可以看出来是个扁的菱形。这个地图元素的大小是64X32，你可以随意决定元素长宽，在设计程序时，地图元素大小并不重要，只要把尺寸扔进绘图方程，程序就能正确地绘制地图。在这个例子中，我们就先用64X32来演示。那么这个公式是怎么样的呢？先看看Staggered地图： 这个地图有5行，看着这个地图你会想，怎么拼图才能将地图拼出

滑步只跟步长有关，就是一轮人物行走(或跑步)实际移动的像素。当然国产游戏大多做的不好。大多数根本不去认真做人物行走的播放程序，简单一帧帧播放动画，并随意移动小人在地图上的位置了事。防止滑步又可以随意改变人物移动速度的方法是这样的：将走路的程序用步长和步速两个量来控制。步长必须定死，按做出来的图片中小人一组动画下来，移动的像素为准。步速是任意的，可以用游戏每帧或每 1/100 秒，人物移动的像素数来

Isometric Tile的处理比矩形的稍微复杂一点的地方在于屏幕是矩形的, 而反映出来的游戏世界的坐标轴有些不同. 无论是精灵的移动, 还是处理 Tile 都需要经过坐标变换. 而一个屏幕的区域在游戏世界的地图上却成了一个菱形. 我想,所有第一次设计 Isometric Tile 引擎的程序员都为这个烦躁过 (自己的感受啦;-) 不排除因为这个原因修改自己的原始设计的可能性 ^_^. 　　实际

Tile Base Engine 的优点在于其处理速度. 如果我们设计 Isometric Engine 而无视这个优点, 那未免太亏了. 所以贪图一时编程或美工的方便, 将游戏设计成 Tile 大小随意, 而又不去发挥任意大小 Tile 的优势, (例如形状任意, Sprite 运动路线的任意等等) 将无法超越从前的游戏 Engine。我们必须向效率和表现力两方面中之一努力. 这次我选择了效率.

四月二日：对话系统 经常听见有人说“RPG游戏不就是一个小人在屏幕上走来走去，碰到了人就说两句话吗！”。虽然这种评价有点过于偏激，但是，也从一个侧面反映出了对话在RPG游戏的作用和影响。客观的讲，人物对话是表现一个游戏故事情节的最直接、最有效方法！而其他的任何手段都无法替代它。例如：过场动画也可以表现游戏的情节和发展，但是，过场动画最适合的是烘托整个游戏的气氛，交代游戏发生的背景或是作为两段情节间

三月二十七日 星期六：系统分析“系统分析”如此专业的词汇可能会立刻吓退一大片人，我当初也是如此！不过只要你认真读完下面的文字，也许你会说一声：‘系统分析’也不过如此嘛！ 顾名思义‘系统分析’就是对整个游戏系统的规划，自顶向下的将它细化成一个个可由程序实现的模块；然后再把各个模块细化成一条条的语句。如此一来，写程序时就可以有条不紊，不会再像以前那样想到哪儿写到哪儿了。 相信大家对RPG都是非常熟悉的

自从我们的第一个正式电脑游戏《冲击》完成之后，已经有很长一段时间没有碰这方面的东西了，不过在我心中好象一直在期盼着什么东西……目睹着当今五彩缤纷的游戏世界和国产游戏的尴尬境地，我忽然有一种莫名的冲动，做游戏的冲动。也许是以前有过这方面的经验或者说是教训吧！我知道应该先让自己冷静下来，仔细的想一想我到底应该做什么类型的游戏？怎样做？我的目的又是什么呢？或许是对RPG的偏爱，或许是因为RPG实现起来相

基于 Tile 的引擎中重复利用率最高的图素，除了地面就是墙壁了, 大家回想一下恺撒III 中的修筑城墙, 或是 Simcity2000 中拉扯电线, 道路,每种物体都只有十几种基本的图素来拼接，而交叉处理都是程序自动选择正确的图素. 假设我们做一个地图编辑器, 这个功能应该也不能少吧:-) 　　实际上, 这个问题早在文本模式的程序就已经出现过. 那就是表格线的处理. 文本模式下, 不能绘制直线,

所谓 Isometric, 应该是指等距视角, 和透视相对, 指视野内的物体, 无论远近都用同一大小来表现. 而Tile 就是指的砖块, 我们平常所见的许多 2D 游戏, 都是 Tile 的. 比如新出的决战朝鲜, 还有去年的皇朝霸业;-), 这两个游戏都是典型的 Tile 游戏, 游戏中的元素被分割为一个个的砖块拼装起来. 不同的是, 前者是矩形的 Tile, 而后者是 Isometric 的.

关于地图：《仙剑奇侠传》地图图块(Tile)的大小为32X16（以象素为单位）。实际每个图块的大小为32x15（以像素为单位），通过拼接刚好天衣无缝。地图大小为128x128（以图块为单位）。排列方式如下：０　２　４　６　８…… // 第０行　１　３　５　７　９……０　２　４　６　８…… // 第１行　１　３　５　７　９……采用这种方式的好处是很容易确定那些图块在屏幕可见范围内，每次只画可见部分。