为什么面向对象编程是有用的？(以一个角色扮演游戏为例) - 文章 - 伯乐在线
& 为什么面向对象编程是有用的？(以一个角色扮演游戏为例)
本文面向的是那些刚刚接触编程，可能已经听说过”面向对象编程”，”OOP”，”类”，”继承/封装/多态”，以及其他计算机科学术语的，但是仍然没有真正明白如何使用OOP的朋友。在本文中，我将解释为什么使用OOP和如何轻松编码。这篇文章使用Python 3代码，但其概念适用于任何编程语言。
有两个关键的非面向对象编程概念需要马上理解:
重复的代码是一件坏事。
代码永远都在改变。
除了一些单任务和只运行一次的微小的”用完即弃”的程序，你几乎总是需要为了解决bug或增加新功能而更新你的代码。大部分编写良好的软件是那种可读性高，易于修改的软件。
如果你经常在你的程序中复制/黏贴代码，那么当你修改它的时候，就需要在很多地方做出同样的改动。这是棘手的。如果在某些地方遗漏了修改，你将到处修改bug或者实现的新功能有不一致性。重复的代码是一件坏事。程序中重复的代码将会把你置于bug和头痛之中。
函数让你摆脱重复的代码。你只需要将代码写到函数中一次，就可以在程序中的任何需要运行代码的地方调用它就可以。更新函数的代码就可以自动更新调用函数的地方。正如函数使得更新代码变得容易，使用面向对象编程技术也会组织你的代码使它更容易改变。记住代码总是在改变的。
一个角色扮演游戏栗子
大多数OOP教程都是令人作恶的。它们有”汽车”类和”鸣笛”方法，其他一些例子与新手写的或者之前接触过的实际程序都是不相关的。因此本博文将使用一个RPG类视频游戏(回忆下魔兽，宠物小精灵，或龙与地下城的世界)。我们已经习惯于将游戏中的事物想象成一些整数与字符的集合。看看Diablo（暗黑破坏神）角色屏幕或D&D角色表单上的数字：
从这些RPG视频游戏中去除图片，角色，装甲，其他对象只是变量形式的一个整数或者字符值的集合。不使用面向对象概念，你可以在Python中这样实现这些事物：
name = 'Elsa'
health = 50
magicPoints = 80
inventory = {'gold': 40, 'healing potion': 2, 'key': 1}
print('The hero %s has %s health.' % (name, health))
name = 'Elsa'health = 50magicPoints = 80inventory = {'gold': 40, 'healing potion': 2, 'key': 1}&print('The hero %s has %s health.' % (name, health))
以上变量名都是非常通用的。为了在游戏中增加怪兽，你需要重命名玩家角色变量，并且增加一个怪兽角色：
heroName = 'Elsa'
heroHealth = 50
heroMagicPoints = 80
heroInventory = {'gold': 40, 'healing potion': 2, 'key': 1}
monsterName = 'Goblin'
monsterHealth = 20
monsterMagicPoints = 0
monsterInventory = {'gold': 12, 'dagger': 1}
print('The hero %s has %s health.' % (heroName, heroHealth))
12345678910
heroName = 'Elsa'heroHealth = 50heroMagicPoints = 80heroInventory = {'gold': 40, 'healing potion': 2, 'key': 1}monsterName = 'Goblin'monsterHealth = 20monsterMagicPoints = 0monsterInventory = {'gold': 12, 'dagger': 1}&print('The hero %s has %s health.' % (heroName, heroHealth))
当然你希望有更多的怪物，接着你会有类似monster1Name, monster2Name等等的变量。这不是一种好的编码方法，因此你可能会使用怪物变量列表:
monsterName = ['Goblin', 'Dragon', 'Goblin']
monsterHealth = [20, 300, 18]
monsterMagicPoints = [0, 200, 0]
monsterInventory = [{'gold': 12, 'dagger': 1}, {'gold': 890, 'magic amulet': 1}, {'gold': 15, 'dagger': 1}]
monsterName = ['Goblin', 'Dragon', 'Goblin']monsterHealth = [20, 300, 18]monsterMagicPoints = [0, 200, 0]monsterInventory = [{'gold': 12, 'dagger': 1}, {'gold': 890, 'magic amulet': 1}, {'gold': 15, 'dagger': 1}]
然后列表索引0处是第一个哥布林的状态，龙的状态在索引1处，另一个哥布林在索引2处。这样你可以在这些变量中存放很多怪物。
但是，这种代码容易导致错误。如果你的列表不同步，程序将无法正常工作。例如玩家击败了索引0处的哥布林，程序调用了vanquishMonster()函数。但这个函数有一个bug，它会(意外的)删除列表中的所有值除了monsterInventory：
def vanquishMonster(monsterIndex):
del monsterName[monsterIndex]
del monsterHealth[monsterIndex]
del monsterMagicPoints[monsterIndex]
# Note there is no del for monsterInventory
vanquishMonster(0)
def vanquishMonster(monsterIndex):
del monsterName[monsterIndex]
del monsterHealth[monsterIndex]
del monsterMagicPoints[monsterIndex]
# Note there is no del for monsterInventory&vanquishMonster(0)
怪兽列表最后看起来像这样：
monsterName = ['Dragon', 'Goblin']
monsterHealth = [300, 18]
monsterMagicPoints = [200, 0]
monsterInventory = [{'gold': 12, 'dagger': 1}, {'gold': 890, 'magic amulet': 1}, {'gold': 15, 'dagger': 1}]
monsterName = ['Dragon', 'Goblin']monsterHealth = [300, 18]monsterMagicPoints = [200, 0]monsterInventory = [{'gold': 12, 'dagger': 1}, {'gold': 890, 'magic amulet': 1}, {'gold': 15, 'dagger': 1}]
现在龙的道具看起来跟之前哥布林的道具一样。第二个哥布林的道具是之前龙的道具。游戏迅速失控了。问题是你把一个怪物的数据散布在多个变量中。解决这个问题的方法是将一个怪物的数据放入一个字典里，然后使用一个字典列表：
monsters = [{'name': 'Goblin', 'health': 20, 'magic points': 0, 'inventory': {'gold': 12, 'dagger': 1}},
{'name': 'Dragon', 'health': 300, 'magic points': 200, 'inventory': {'gold': 890, 'magic amulet': 1}},
{'name': 'Goblin', 'health': 18, 'magic points': 0, 'inventory': {'gold': 15, 'dagger': 1}}]
monsters = [{'name': 'Goblin', 'health': 20, 'magic points': 0, 'inventory': {'gold': 12, 'dagger': 1}},
{'name': 'Dragon', 'health': 300, 'magic points': 200, 'inventory': {'gold': 890, 'magic amulet': 1}},
{'name': 'Goblin', 'health': 18, 'magic points': 0, 'inventory': {'gold': 15, 'dagger': 1}}]
啊哈！这段代码变得更加复杂了。例如，一个怪兽的状态是一个字典列表中的字典项。假如咒语或者道具栏也有它们自己的属性，且需要放到字典该怎么办？假如一个道具栏中的物品是一个背包，它本身包含了其他道具该怎么办？这个怪物列表会变得紧张。
这点是面向对象程序设计通过创建一个新的数据类型就可以解决的。
类是你程序中新数据类型的蓝图。面向对象编程对装甲，怪物等建模提供了新的方法，该方法比列表和字典的大杂烩好得多。虽然需要花些时间来熟悉OOP的概念。
事实上，因为英雄角色与怪兽们拥有相同的属性(健康值，状态值等等)，我们只需要一个英雄与怪兽共享的通用的LivingThing类。你的代码可以变为：
class LivingThing():
def __init__(self, name, health, magicPoints, inventory):
self.name = name
self.health = health
self.magicPoints = magicPoints
self.inventory = inventory
# Create the LivingThing object for the hero.
hero = LivingThing('Elsa', 50, 80, {})
monsters = []
monsters.append(LivingThing('Goblin', 20, 0, {'gold': 12, 'dagger': 1}))
monsters.append(LivingThing('Dragon', 300, 200, {'gold': 890, 'magic amulet': 1}))
print('The hero %s has %s health.' % (hero.name, hero.health))
1234567891011121314
class LivingThing():
def __init__(self, name, health, magicPoints, inventory):
self.name = name
self.health = health
self.magicPoints = magicPoints
self.inventory = inventory&# Create the LivingThing object for the hero.hero = LivingThing('Elsa', 50, 80, {})monsters = []monsters.append(LivingThing('Goblin', 20, 0, {'gold': 12, 'dagger': 1}))monsters.append(LivingThing('Dragon', 300, 200, {'gold': 890, 'magic amulet': 1}))&print('The hero %s has %s health.' % (hero.name, hero.health))
嘿，瞧瞧，使用类已经把我们的代码削减了一半，因为我们可以对玩家角色和怪兽使用同样的代码。
在上面的代码中，你可以定义新的数据类型/类(除了学院派，但是这两个术语基本上是一样的。参见)名为LivingThing。你可以实例化LivingThing变量/对象(重复一次，这两个术语基本上也是相同的)就好像你可以拥有整形值，字符值或布尔值一样。
上面代码特定于Python的细节：
class LivingThing():
class LivingThing():
上面class声明定义了一个新类，就像def声明定义一个新函数。该类名是LivingThing。
def __init__(self, name, health, magicPoints, inventory):
def __init__(self, name, health, magicPoints, inventory):
上面代码为LivingThing类定义了一个方法。”方法“只是命名属于这个类的函数。(参考)
这个方法很特别。__init__()用于类的构造函数(或者称为”构造方法”，”构造函数”，简写为”ctor”)。而一个类是一个新数据类型的蓝图，你还需要创建这个数据类型的值，以便于存储到变量或者使用函数传递。
当调用构造器创建新对象时，执行构造器中的代码，并返回一个新对象。这就是
hero = LivingThing('Elsa', 50, 80, {})
hero = LivingThing('Elsa', 50, 80, {})
这行的意思。无论类名是什么，构造器总是被命名为__init__。
如果类没有__init__()方法，Python会为类提供通用的构造方法，该方法什么都不做。但是__init__()是初始化建立一个新对象的绝佳地方。
在Python语言中，方法中的第一个变量是self。self变量用于创建成员变量，后面会做解释。
构造函数体：
self.name = name
self.health = health
self.magicPoints = magicPoints
self.inventory = inventory
self.name = name
self.health = health
self.magicPoints = magicPoints
self.inventory = inventory
这看上去有点重复，但这段代码所作的就是对由构造函数创建的对象的成员变量赋值。成员变量开头是self.表示这些成员变量属于创建的对象，且不是函数中的普通局部变量。
调用构造器
# Create the LivingThing object for the hero.
hero = LivingThing('Elsa', 50, 80, {})
monsters = [LivingThing('Goblin', 20, 0, {'gold': 12, 'dagger': 1}),
LivingThing('Dragon', 300, 200, {'gold': 890, 'magic amulet': 1}),
LivingThing('Goblin', 18, 0, {'gold': 15, 'dagger': 1})]
print('The hero %s has %s health.' % (hero.name, hero.health))
# Create the LivingThing object for the hero.hero = LivingThing('Elsa', 50, 80, {})monsters = [LivingThing('Goblin', 20, 0, {'gold': 12, 'dagger': 1}),
LivingThing('Dragon', 300, 200, {'gold': 890, 'magic amulet': 1}),
LivingThing('Goblin', 18, 0, {'gold': 15, 'dagger': 1})]&print('The hero %s has %s health.' % (hero.name, hero.health))
Python中调用构造器就像是一个函数调用，该函数名为类名。因此LivingThing()就是调用LivingThing类的__init__()构造器。
; html-script: false ]LivingThing('Elsa', 50, 80, {})
; html-script: false ]LivingThing('Elsa', 50, 80, {})
调用创建了一个新的LivingThing对象，并保存在到hero变量里。以上代码还创建了3个怪兽LivingThing对象并保存在monsters列表中。
至此我们开始看到了面向对象编程的好处。如果其他程序员读了你的代码，当他们看到LivingThing()调用，他们知道他们可以搜索LivingThing类，然后从LivingThing类中找出所有他们想知道的细节。
但一个更大的好处是当你试图更新LivingThing类时才能体会的。
假如你想给你的RPG增加”饥饿”度属性。如果一个英雄或怪兽的饥饿度为0，他们一点也不饿。但如果他们的饥饿度超过100，那么他们将受到伤害并且健康值每天递减。你可以这样改变__init__()函数：
def __init__(self, name, health, magicPoints, inventory):
self.name = name
self.health = health
self.magicPoints = magicPoints
self.inventory = inventory
self.hunger = 0 # all living things start with hunger level 0
def __init__(self, name, health, magicPoints, inventory):
self.name = name
self.health = health
self.magicPoints = magicPoints
self.inventory = inventory
self.hunger = 0 # all living things start with hunger level 0
不需要修改其他任何代码行，你游戏中所有LivingThing对象现在都有了饥饿度。你不需要担心某些LivingThing对象有hunger成员变量，而有些没有：所有LivingThing对象都更新了。
你也不需要改变任何构造器调用，因为你没有在__init__()函数的参数列表总中增加一个新的饥饿度参数。这是因为队一个新的LivingThing对象的饥饿度来说0是一个很好的默认值。如果你在__init__()函数的参数列表总中增加一个新的饥饿度参数，那么你需要更新所有调用构造器的代码。但这对其他函数也是一样的。
如果你的RPG有很多类似的默认值，通过使用类的构造器进行默认值赋值，就可以避免当量的”样板”代码。
方法具有执行代码来影响对象本身的用途。例如，你可以编码来直接修改LivingThing对象的健康度：
hero = LivingThing('Elsa', 50, {})
hero.health -= 10 # Elsa takes 10 points of damage
hero = LivingThing('Elsa', 50, {})hero.health -= 10 # Elsa takes 10 points of damage
但这样处理伤害不是一个非常健壮的方式。每当有什么东西受到伤害时就需要检查很多其他的游戏逻辑。例如，假设你想要检查一个角色在受到伤害后，它是否死亡。你需要这样的代码：
hero = LivingThing('Elsa', 50, {})
hero.health -= 10 # Elsa takes 10 points of damage
if hero.health & 0:
print(hero.name + ' has died!')
hero = LivingThing('Elsa', 50, {})hero.health -= 10 # Elsa takes 10 points of damageif hero.health & 0:
print(hero.name + ' has died!')
以上方法的问题是你需要检查各处代码来减少LivingThing对象的健康值。但是重复的代码是一件坏事。阻止重复的代码的非OOP方式可能是把以上方法放入一个函数中:
def takeDamage(livingThingObject, dmgAmount):
livingThingObject.health = self.health - dmgAmount
if livingThingObject.health & 0:
print(livingThingObject.name + ' is dead!')
hero = LivingThing('Elsa', 50, {})
takeDamage(hero, 10) # Elsa takes 10 points of damage
def takeDamage(livingThingObject, dmgAmount):
livingThingObject.health = self.health - dmgAmount
if livingThingObject.health & 0:
print(livingThingObject.name + ' is dead!') &hero = LivingThing('Elsa', 50, {})takeDamage(hero, 10) # Elsa takes 10 points of damage
这是一个更好的解决方案，因为任何更新takeDamage()(例如装甲防护，保护性法术，增益效果等)只需要增加到takeDamage()函数中。
然而，不利的一面是，当您的程序规模增长，takeDamage()函数很容易迷失在其中。takeDamage()函数与LivingThing类的关系并不明显。如果你的程序有成百上千的函数，它将很难指出哪一个函数与LivingThing类有关系。
解决的方法是将这个函数变成LivingThing类的方法：
class LivingThing():
# ...other code in the class...
def takeDamage(self, dmgAmount):
self.health = self.health - dmgAmount
if self.health == 0:
print(self.name + ' is dead!')
# ...other code in the class...
hero = LivingThing('Elsa', 50, {})
hero.takeDamage(10) # Elsa takes 10 points of damage
123456789101112
class LivingThing():
# ...other code in the class...&
def takeDamage(self, dmgAmount):
self.health = self.health - dmgAmount
if self.health == 0:
print(self.name + ' is dead!')&
# ...other code in the class...&hero = LivingThing('Elsa', 50, {})hero.takeDamage(10) # Elsa takes 10 points of damage
一旦你的程序有很多类，每个类有许多方法和成员变量，你将开始看到OOP可以帮助组织你的程序而使他更易于管理。
公共与私有方法
方法与成员变量可以被标示为public或private。公共方法可以和公共成员变量可以在类内部或外部的任何代码调用和赋值。私有方法和私有成员变量只能在对象自己的类内部被调用和赋值。
在某些语言中，例如Java，这种”可以被调用/赋值”由编译器严格的保证。而Python，却没有”私有”和”公共”的概念。所有方法和成员变量都是”公共”的。然而，语言规定如果一个方法名开头是下划线，它就被认为是一个私有方法。这就是为什么你将看到_takeDamage()等方法了。你可以方便的编写代码从对象的类的外部调用私有函数或者设置私有成员变量，但你已经被彻底警告不要去这样做了。
公共/私有的区别的原因是为了解释类如何与外部代码进行交互的。(参考)类的程序员期望其他人不会编写代码调用私有方法或设置私有成员变量。
例如，takeDamage()方法包括健康值低于0就检查死亡。你可能想要在代码中添加各种各样的其他检查。护甲、敏捷性和防护法术来减少伤害的可能因素。LivingThing对象可能穿着一件魔法斗篷，通过增加抗损害值，而不是减少它们的健康值来进行治疗。这个游戏的所有逻辑都可以放入takeDamage()方法中。
如果你偶然的把代码放到那里，所有的OOP结构就毫无意义了
class LivingThing():
# ...code in the class...
hero = LivingThing('Elsa', 50, {})
# ...some more code...
if someCondition:
hero.health -= 50
class LivingThing():
# ...code in the class...&hero = LivingThing('Elsa', 50, {})&# ...some more code...&if someCondition:
hero.health -= 50
语句hero.health -= 50会减少50点健康值，而不会考虑Elsa穿着哪种装甲，或者她有防护法术，或者她穿着魔法治疗披风。这段代码将直截了当的减少50点健康值。
很容易忘掉takeDamage()方法并且偶尔写出这样的代码。它不会检查英雄对象的健康值是否低于0。游戏继续运行好像Elsa还活着，及时她的健康值是负数！我们可以使用公共/私有成员和方法来避免这个bug。
如果你重命名health成员变量为_health且标记为私有的，那么当你写成这样就很容易捕获这个bug：
hero = LivingThing('Elsa', 50, {})
# ...some more code...
if someCondition:
hero._health -= 50 # WAIT! This code is outside the hero object's class but modifying a private member variable! This must be a bug!
hero = LivingThing('Elsa', 50, {})&# ...some more code...&if someCondition:
hero._health -= 50 # WAIT! This code is outside the hero object's class but modifying a private member variable! This must be a bug!
在一种语言中如Java，如果编译器确保私有/公共访问，它就不可能编写非法访问自由成员和方法的程序。面向对象编程帮助我们防止这种bug。
使用LivingThing类表示龙是不错的，但是除了LivingThing类提供的属性外，龙有很多其他的属性。因此你想创建一个新的Dragon类，它包含如airSpeed和breathType(可以使用 'fire','blizzard', 'lightning', 'poison gas'等字符串表示)等成员变量。
因为Dragon对象也包含health，magicPoints，inventory和其他LivingThing对象的属性，你可以创建一个新的Dragon类，并且从LivingThing类复制/黏贴所有代码。但这将导致重复的代码这一坏习惯。
相反，可以使Dragon类作为LivingThing类的子类：
class LivingThing():
# ...other code in the class...
class Dragon(LivingThing):
# ...Dragon-specific code in the class...
class LivingThing():
# ...other code in the class...&class Dragon(LivingThing):
# ...Dragon-specific code in the class...
实际上是说，”一个龙也是一种LivingThing，还有一些附加的方法和成员变量”。当你创建龙对象时，它会自动的拥有LivingThing的方法和成员变量(拯救我们脱离重复的代码)。但它也有龙特有的方法和成员变量。进一步说，任何处理LivingThing对象的代码都可以自动的操作龙对象，因为龙对象已经拥有了LivingThing成员变量和方法。这个原则被称为子类型多态性。
然而在实践中,继承是容易滥用的。你必须确保任何对LivingThing类做出的改变和更新都适用于Dragon类和所有其他LivingThing的子类。这可能不总是那么简单直接。
例如，如果你创建了LivingThing类的Monster和Hero子类，接着创建了Monster类的 FlyingMonster 和MagicalMonster子类，新的Dragon类继承自FlyingMonster 类还是MagicalMonster类？或者可能它只是Monster类的子类
这就是继承和OOP开始变得棘手且严谨的争论哪种是”正确”设计类的方式之所在。我希望报纸这篇博文简短而简单，因此我要把这些问题留给读者作为练习来调查。(参考
我讨厌由面向对象编程开始的面向初学者的程序教程。OOP是十分抽象的概念。有一些经验和编写过大型程序之前,你不会理解为什么使用类和对象使编程更容易。相反，它会给初学者留下一条陡峭的学习曲线去爬，他们不知道为什么攀登它。我希望这个RPG例子至少让你领略了为什么OOP是有帮助的。有更多的OOP。如果你想了解更多,试试搜索 和 。
如果你仍然对OOP概念感到迷惑，放心大胆的编写没有类的程序。你不需要它们，它们将导致过度设计的代码。但是一旦你已经有了一些编码经验,面向对象编程的好处会变得更加明显。祝你好运！
关于作者：
可能感兴趣的话题
关于伯乐在线博客
在这个信息爆炸的时代，人们已然被大量、快速并且简短的信息所包围。然而，我们相信：过多“快餐”式的阅读只会令人“虚胖”，缺乏实质的内涵。伯乐在线内容团队正试图以我们微薄的力量，把优秀的原创文章和译文分享给读者，为“快餐”添加一些“营养”元素。
新浪微博：
推荐微信号
（加好友请注明来意）
– 好的话题、有启发的回复、值得信赖的圈子
– 分享和发现有价值的内容与观点
– 为IT单身男女服务的征婚传播平台
– 优秀的工具资源导航
– 翻译传播优秀的外文文章
– 国内外的精选文章
– UI,网页，交互和用户体验
– 专注iOS技术分享
– 专注Android技术分享
– JavaScript, HTML5, CSS
– 专注Java技术分享
– 专注Python技术分享
& 2017 伯乐在线&&&&&话题页
回应/阅读：7/4678
【墨怀】手把手教你如何用RPG制作大师制作简单游戏
TA们刚刚顶过
00:15:13.0
最难过的是你眉头紧皱而我却没有理由抱你
13:21:07.0
I'M A PERFECT MAN[ Tokyo涩谷预定中 - ]&&&滞留地非中国。欢迎非正常人类及海外党来找我玩。[ 日语练习中 ]&&& & 日 &
& 東 京 時 間 . 22:29 & & 距离前往东京的航班还有3小时起飞。 & & 距离我的目标还有2年。 &
& 距离再次见到你还有5年。
13:55:31.0
15:27:36.0
最难过的是你眉头紧皱而我却没有理由抱你
15:12:00.0
I'M A PERFECT MAN[ Tokyo涩谷预定中 - ]&&&滞留地非中国。欢迎非正常人类及海外党来找我玩。[ 日语练习中 ]&&& & 日 &
& 東 京 時 間 . 22:29 & & 距离前往东京的航班还有3小时起飞。 & & 距离我的目标还有2年。 &
& 距离再次见到你还有5年。
16:42:35.0
& & & & & & & & & &
&爱我 憋走
00:39:43.0
注意日期哦。不然会被删回复←
12:58:59.0
& & & & & 米娜桑。。。这里是萌萌哒的小奈酱。。。= -、【求眼熟求深交。。。。 & & & & & & & & 哇达西。会互粉。。会卖萌。。会暖贴。。。。= -、【粉一个咯。。又不会怀孕。。 & & = -、。。。【二次元的小伙伴可以加企鹅哦。。。。。蟹蟹米娜桑 & & &
回应/阅读：7/4678
没有多多号？
人要是不活聪明点，自己怎么死的都不知道
蛇口の場所あの水水沒、水の影を照らし全体の輪、それに新しい水は再びが氾濫して、これはひとつの水の意志
若不能因时变事，而顽固格守旧俗，这本身就是致乱之湖。
水是一种鼓励，水是一种态度，一起水是最好的支持！
我们的征途是星&&
(?&??&?)??来都来了，点个关注呗
饮尽世界上所有酒窖的酒，换一场烂醉，花低头抬头叹着沧桑，蝶飞来飞去寻着永远遇上你。当前位置： >>
RPG游戏制作教程
RPG全称为：Role Playing Game（角色扮演游戏）
RPG游戏《仙剑奇侠传》(20张)　　RPG是电脑游戏的发展历史中形成的第一大阵营。作为具有一定的情节、描述人物成长过程、表现事件始末的一种游戏，决定了角色扮演类游戏必须提供一个广阔的虚拟空间来供游戏者旅行、冒险和生活。虽然这个空间是虚拟的，但它也有其一定的生存环境和规则。由于该类的大多游戏较别类游戏更强调文字的表现，使角色扮演游戏能够更为贴切地表达人类的情感。而整个游戏的流程由战斗，进行贸易，解开谜题和繁琐的迷宫串在一起。在很大程度上满足了游戏者潜在的对拥有多姿多彩的不凡生活的渴望。因为RPG游戏相对于其他类型的游戏，技术要求最低，电脑配置要求也最低，因此开发起来相对容易很多，RPG游戏在电子游戏中也是历史最为悠久、数量最为庞大的一种。在电子游戏发展史中，也留下了许许多多的经典作品，像家用电视游戏机上的《最终幻想》系列，PC机上《魔法门》系列，还有中文电脑RPG游戏的经典《仙剑奇侠传》、《轩辕剑》、《幽城幻剑录》以及《幻想三国志》系列、《新绝代双骄》系列等。 　　
游戏《上古卷轴》截图(20张)　相对于其他类型游戏，此类游戏更重要的核心是世界观表现及角色代入感体验（世界观依托于具有故事
RPG游戏《上古卷轴》(11张)性的文字设定，包括场景设定角色设定等诸多前期因素，所以此类游戏的前期筹备工作对于其他类型游戏来说是一个更为浩大的工程，对于RPG本身来说也是最为重要的工程），在很大程度上满足了游戏者潜在的对拥有多姿多彩的不凡生活的渴望。RPG的前身是交互式小说，与现在的冒险类游戏(简称AVG或ADV)同源，RPG游戏在电子游戏中也是历史最为悠久、数量最为庞大的一种。世界上第一款电子平台的RPG是1981年的游戏《巫术》。 　　在电子游戏发展史中，也留下了许多经典作品，比如家用游戏机上的《最终幻想》、《勇者斗恶龙》（电子游戏中的两大RPG龙头，都属于SQUARE-ENIX公司，某种程度上左右着次世代游戏机战争）、《阿月历险记》、《异度传说》、《口袋妖怪》SEGA的《梦幻之星》系列、
RPG游戏《暗黑破坏神》截图(11张)《光明》系列；NAMCO的《传说》系列（包含《幻想传说》、《宿命传说》、《深渊传说》、《永恒传说》、《重生传说》、《薄暮传说》、《世界传说》、《心灵传说》、《风雨传说》）；Falcom的《英雄传说》系列、《伊苏》系列、《双星物语》系列；PC上的《暗黑破坏神》、《无冬之夜》、《上古卷轴》、《博德之门》、《魔法门》，《神鬼寓言》还有中文电脑PC平台中的RPG经典――《仙剑奇侠传》以及《轩辕剑》、《剑侠情缘》、《幽城幻剑录》、《幻想三国志》、《新绝代双骄》、《刀剑封魔录》、《秦殇》等。
2.2 分类判断
分类判断依据：
　　成长要素为判断游戏类型为角色扮演的最主要依据，包括角色的等级以及队友、宠物、使魔等一系列附属角色的成长，但不包括武器的成长（因为武器既作为大部分动作游戏的基本要素，也与角色本身的成长以及修为无关）。角色扮演游戏作为极有影响力的游戏类型，在游戏分类中也处于较为优先位置。例如，通常情况下，只要存在人物成长的要素，即便是以其他方式为主要操控方式的游戏也往往被分入角色扮演的类型。例如动作角色扮演游戏中的《暗黑破坏神》系列、《泰坦之旅》；策略角色扮演的《火焰纹章》系列、《FFT》。
主要游戏类型：
　　游戏类型
英文缩写 简介
动作游戏 ACT（Action Game） 玩家控制游戏人物用各种武器消灭敌人以过关的游戏，不追求故事情节，如《超级玛丽》、《星之卡比》、《波斯王子》等等。
冒险游戏 AVG（Adventure Game ） AVG的特色是故事情节往往是以完成一个任务或解开某些迷题的形式出现而且在游戏过程中强调谜题的重要性。动作类AVG如《生化危机》系列、《古墓丽影》系列等；解迷类AVG代表是《神秘岛》系列。
格斗游戏 FTG（Fighting Game） 由玩家操纵各种角色与电脑或另一玩家所控制的角色进行格斗的游戏。按呈画技术可再分为2D和3D两种，2D格斗游戏有著名的《街头霸王》系列、《拳皇》系列等；3D格斗游戏如《铁拳》等。
角色扮演游戏 RPG（Role playing Game） 由玩家扮演游戏中的一个或数个角色，有完整的故事情节的游戏。与冒险类游戏区分很简单，RPG游戏更强调的是剧情发展和个人体验，如《最终幻想》、《仙剑奇侠传》、《暗黑破坏神》等。
即时战略游戏 RTS（Real Time Strategy） 是战略游戏的一种，主要以电脑游戏的形式存在。游戏是即时进行的，而不是采用传统电子游戏及棋盘战略游戏中的回合制。代表作有《魔兽争霸》系列、《帝国时代》系列、《星际争霸》等。
策略战棋游戏 SLG（SimuLation Game） 玩家运用策略与电脑或其它玩家较量，以取得各种形式胜利的游戏。代表作为《英雄无敌》系列、《三国志》系列、《樱花大战》系列，《天使帝国》系列等。
模拟经营游戏 SIM（Simulation Game） 模拟经营游戏和策略战棋游戏英文表示一样，都为Simulation Game，代表作品为《大富翁》系列、《模拟人生》系列、《模拟城市》、《过山车大亨》、《主题公园》、《足球经理》等。
养成游戏 EDU （Education Game） 顾名思义，就是玩家模拟培养的游戏，如《明星志愿》系列、《美少女梦工厂》系列、《凌波丽育成计划》等等。
体育游戏 SPT（Sports Game） 模拟各类竞技体育运动的游戏，花样繁多，如《FIFA》系列、《NBA Live》系列、《实况足球》系列、《VR网球》系列等。
射击游戏 STG（Shoting Game） 一般指的是卷轴式射击游戏，《雷电》、《鲛鲛鲛》、《空牙》、《沙罗曼蛇》系列、《战区88》 等。
竞速游戏 RAC（Racing Game） 在电脑上模拟各类赛车运动的游戏，通常是在比赛场景下进行，代表作有《极品飞车》、《山脊赛车》、《摩托英豪》等。
音乐游戏 MUG（Music Game） 培养玩家音乐敏感性，增强音乐感知的游戏。伴随美妙的音乐，有的要求玩家翩翩起舞，有的要求玩家手指体操，这类游戏的代表作品有《复员热舞革命》系列，《太鼓达人》系列，《DJ》系列。
恋爱游戏 LVG（Love Game） 玩家回到初恋的年代，回味感人的点点滴滴，模拟恋爱的游戏。代表作有日本的《心跳的回忆》系列、《思君》，中国的《青涩宝贝》等。
益智游戏 PUZ （Puzzle Game） PUZ游戏多需要玩家对游戏规则进行思考，判断。系统表现相当多样化，主要依游戏规则制定。由于对游戏操作不需要太高要求，代表作品为《俄罗斯方块》系列，《泡泡龙》系列等。
卡片游戏 CAG（Card Game） 玩家操纵角色通过卡片战斗模式来进行的游戏。丰富的卡片种类使得游戏富于多变化性，给玩家无限的乐趣，代表作有著名的《信长之野望》系列、《游戏王》系列。
第一人称射击游戏 FPS（First Person Shooting） 以第一人称视角使用各种武器，主要是枪械进行射击，消灭敌人的游戏。例如我们玩的CS、Quake系列等等游戏。
2.3 系统分类
　　按照游戏系统分类，大致可分为：
（1）传统角色扮演游戏
　　RPG――Role Playing Game 　　此类游戏基本沿袭早期RPG系统，操作方式大多为RPG回合制或半即时制，换句话说，这个类型最重要的特征是非实时指令，由最终幻想系列首创的带有ATB系统的RPG由于近年被广泛应用，一般也归为传统RPG类型。因为着重突出世界观表现、剧情体验及角色性格刻画，且游戏系统本身对操作要求不像动作游戏或者格斗游戏那么高，所以此类型是受到最广大玩家欢迎的类型（特指动作苦手的非核心玩家），而发展至今，这类游戏中的佼佼者吸引人的不再只是引人入胜的剧情。因为硬件机能的提升，游戏中的场景、角色越来越精致，游戏中技能的效果诸类也较早期更为华丽.....正统RPG画面单调的时代已经过去（其他类型其实也都一样） 　　代表作品： 　　NINTENDO《口袋妖怪》系列 　　SQUARE-ENIX《最终幻想》系列、《勇者斗恶龙》系列、《格兰蒂亚》系列 　　SQUARE-ENIX&NBGI《异度》系列（包括《XENOGEARS》以及《XENOSAGA》系列） 　　NBGI《hack》系列 　　SCE《荒野兵器》系列 　　ATLUS《女神异闻录》系列 　　FALCOM《英雄传说》系列 　　LEVEL-5《银河游侠》（LEVEL-5为《勇者斗恶龙8》外包开发商） 　　DATA-EAST《重装机兵》系列 　　CAPCOM《吞食天地》FC版 　　TECMO《怪物农场》系列 　　EA《指环王：第三世纪》 　　《仙剑》《轩辕剑》系列
（2）策略角色扮演游戏
　　SRPG――Simulation Role Personate Game 　　此类游戏又被形象地称为战棋类游戏，通常为泛回合制或半即时制，以剧情为核心的特点承袭自传统RPG，而在游戏系统上，除了传统RPG原有的要素外，更重视有限战斗场景中玩家对所操控团队中各个角色行动的配合以及对所操控的团队整体作战策略上的把握，且需要考虑场景地形对团队作战以及角色技能施放的影响，此要素吸收自SLG（Simulation Game，策略游戏），算是两种类型系统上的融合 　　代表作品： 　　SQUARE-ENIX《最终幻想战略版》 　　BANPRESTO《机战》系列 　　BANPRESTO《召唤之夜》系列 　　NINTENDO《火炎纹章》系列 　　SCE《妖精战士（ARC THE LAD）》系列 　　日本一《魔界战记》系列 　　SEGA《战场的女武神》系列、《光明》系列早期作品 　　Enterbrain《泪之指轮传说》系列 　　IDEA FACTORY / NEVER LAND《鬼魂力量》《新天魔界》《混沌战争》等系列 　　ATLUS《星神》
（3）动作角色扮演游戏
　　ARPG――Action Role Playing Game 　　此类型在保留传统RPG游戏的基本要素上，系统更重视指令的实时性，以及对所演绎角色的动作体验（这是从早期动作游戏中吸取的要素），所以在战斗方面更加紧凑刺激，操作方面更考验玩家的实时反应 　　代表作品： 　　BLIZZARD《暗黑破坏神》系列 　　SQUARE-ENIX《王国之心》系列、《圣剑传说》系列 　　NAMCO《传说》系列 　　FALCOM《双星物语》系列、《伊苏》系列 　　SEGA《梦幻之星》系列、《光明》系列自《光明力量》、《光明之泪》后的两个分支。 　　3A《星之海洋》系列、《北欧女神》系列（注*3A作为日本一个特立独行的RPG游戏制作公司，是游戏类型融合的实干派先驱，其作品无论在美工水准、系统设定和游戏耐玩程度上都不亚于现在被极力吹捧的暴雪，该公司现已被SE收购为子公司，但与暴雪一样作为独立工作室，虽然偶尔协助参与制作其他分部作品，但本部工作方式及企划方案不受总部干预）。 　　EA《指环王》三部曲（与《指环王：第三世纪》相区别）。
（4）桌面角色扮演游戏
　　TRPG――Table-top Role Playing Game 　　相关描述同百度“跑团”词条，这个类型相对于日式传统RPG侧重剧情性质世界观和角色刻画来讲，更重视对原创世界观的灵活运用，以及真实个人在原创世界观中的代入体验，系统方面则是更侧重规则的平衡性，是MMORPG的前身，此类型的理念由《龙与地下城（DND）》首创，TRPG在日式作品中非常少见，基本等同于欧美传统角色扮演游戏的概念。
（5）大型多人在线角色扮演游戏
　　MMORPG――Massively Multiplayer Online Role Playing Game 　　前身是TRPG（见上述），其核心是原创规则的平衡性及当前网络化趋势下以原创世界观为平台的真实人类之间的交流（网络化也是所有游戏的一大趋势）与此同时也会融合其他几个RPG分支的要素以增加游戏性，拥有除去网络休闲棋牌类游戏外全世界最广大的玩家群。 　　代表作品： 　　BLIZZARD《魔兽世界》 　　SQUARE-ENIX《最终幻想11》《最终幻想14》 　　其他如《石器时代》《传奇》《奇迹》《天堂》《梦幻西游》
2.4 风格分类
（1）欧美传统角色扮演游戏
　　这类游戏大都以高级龙与地下城（AD&D）规则为蓝本，与早期TRPG概念基本相同。依据龙与地下城规则，有丰富的游戏战役题材，可玩性极高，不过由于此类游戏涉及游戏规则较多，大都上手困难。系统上一般沿袭了ARPG中的实时指令系统，但由于早期的硬件限制或策划理念的因素，动作体验相对来说不是比较重要的因素，所以独立出来与现今的欧美主流ARPG相区别。欧美玩家向来重视实时体验，所以也很少有使用日式传统角色扮演游戏的回合制或半即时系统的作品。 　　代表作品： 　　博德之门（Baldur's Gate） 　　无冬之夜（NeverWinter Nights） 　　冰封谷（Icewind Dale） 　　光芒之池（Pool of Radiance） 　　异域镇魂曲（Planescape: Torment） 　　上古卷轴 　　哥特王朝 　　龙腾世纪（Dragon Age） 　　指环王：第三世纪（欧美传统游戏中极少数引用日式ATB系统的作品）
（2）欧美动作角色扮演游戏
　　突出游戏的操作体验，既吸收了动作游戏酣畅淋漓的打击感，又保留了传统RPG游戏的剧情和大量稀奇古怪的装备、近些年大多数欧美RPG游戏都是该类型。 　　代表作品： 　　暗黑破坏神 　　圣域2 　　巫师 　　泰坦之旅 　　地牢围攻 　　火炬之光 　　神鬼寓言 　　指环王三部曲
（3）日式传统角色扮演游戏
　　相对于美式RPG，日式RPG强调的更多的是剧情的推进。更像一部能够互动的电影。画面上，美式RPG画风偏写实，硬朗力求真实感。而日式RPG则大量采用漫画风格。而在操作方面，日式传统RPG的战斗方式大都采用回合制或半即时制的系统，玩家有充足的时间考虑下一步要做什么。 　　代表作品： 　　RPG―― 　　NINTENDO《口袋妖怪》系列 SQUARE-ENIX《最终幻想》系列、《勇者斗恶龙》系列、《格兰蒂亚》系列、SQUARE-ENIX&NBGI《异度》系列 　　NBGI《hack://》系列 　　SCE《荒野兵器》系列 　　ATLUS《女神异闻录》系列 　　FALCOM《英雄传说》系列 　　DATA-EAST《重装机兵》 　　CAPCOM《吞食天地》FC版本 　　TECMO《怪物农场》系列
（4）日式动作角色扮演游戏
　　与美式RPG的区别之处在于，更强调在原创世界观中对剧本性质作品的代入体验，而非个人原创角色的代入体验。玩家虽然被系统限制，无法自由发挥，然而这类游戏却有着极强的代入感，玩家往往被剧情感动，不自觉的扮演了游戏中的角色。 　　代表作品： 　　SQUARE-ENIX《王国之心》系列、《圣剑传说》系列、《最终幻想：纷争》、《龙背上的骑兵》系列 　　NAMCO《传说》系列 　　FALCOM《双星物语》系列、《伊苏》系列 　　SEGA《梦幻之星》系列、《光明》系列自《光明力量》《光明之泪》后的两个分支 　　TRI-ACE《星之海洋》系列、《北欧女神》系列 　　LEVEL-5《银河游侠》（LEVEL-5为《勇者斗恶龙8》外包开发商） 　　（5）日式策略角色扮演游戏 　　这类游戏又被称为战棋游戏。这类游戏严格的说更接近SLG。但是，这类游戏的剧情却感染了很多玩家。如：最终幻想战略版、魔界战记系列、星神等。相对其他细分的类型而言，并无出彩之处，但是因为泛回合制系统以及视角相对固定等条件，相对其他细分的RPG分支类型更容易开发。此类型与《三国志》等为代表的正统SLG的区别在于：SRPG拥有主线剧情，而SLG则一般可以自由选择阵营且系统方面的平衡性调整得更完善。 　　代表作品： 　　SQUARE-ENIX《最终幻想战略版》 　　BANPRESTO《机战》系列 　　BANPRESTO《召唤之夜》系列 　　NINTENDO《火炎纹章》系列 　　SCE《妖精战士》系列 　　日本一《魔界战记》系列 　　SEGA《战场的女武神》系列、《光明》系列早期作品 　　Enterbrain《泪之指轮传说》系列 　　IDEA FACTORY / NEVER LAND《鬼魂力量》《新天魔界》《混沌战争》等系列 　　ATLUS《星神》
（6）中式仙侠角色扮演游戏
　　这类游戏大都以中国奇幻武侠文化或传统的神话题材为蓝本设定世界观。中国传统的水墨画风格为画风。游戏带有强烈的中国文化色彩。系统上存在类似日式RPG细分的区别，但业界并不具体细分，一般统一划为RPG。 　　代表作品： 　　传统RPG―― 　　大宇分部上海软星（已解散）《仙剑奇侠传》系列 　　台湾大宇《轩辕剑》系列 　　新瑞狮（已解散）《天河传说》 　　宇峻奥丁《幻想三国志》系列 　　宇峻科技《新绝代双骄》系列 　　上海烛龙《古剑奇谭》（2010年内发售） 　　ARPG―― 　　目标软件《秦殇》系列、西山居《剑侠情缘》系列
（7）中式仿日角色扮演游戏
　　这个类型一般引用日式RPG的要素，使用原创架空世界观和日式漫画风格 　　代表作品： 　　RPG―― 　　大宇分部北京软星《阿猫阿狗》系列 　　台湾智冠《第七封印》《最初幻想》 　　SRPG―― 　　台湾智冠《风色幻想》系列
（8）中式在线角色扮演游戏
　　这个类型是最不需要多说的，大多引用欧美MMORPG的框架，代之仙侠角色扮演的外壳，国内业界工资普遍偏低，所以游戏的制作成本为世界最低，但在线人均收费额却是全世界最高的 　　代表作品： 　　《完美世界》、《诛仙》、《仙剑OL》等等。
〖一〗
　　制作游戏中，角色扮演游戏可以说是所有游戏中最复杂的。它需要统合各方面的人员（像是程序、脚本、美术、音乐音效等等），因此对于一名游戏企划来说，如何去制作一个角色扮演游戏就成为最大的挑战。在国内某知名游戏公司内部有一种说法，就是「制作游戏的数量不到三套，不能算是一个专业的游戏制作人员。」不过还有一些人对这一点有另外一种看法，就是「没有制作过角色扮演游戏的人，不算是真的经历过考验。」由这种说法，可以知道角色扮演的制作有多么的复杂。
　　在开始制作一个角色扮演游戏前，前置作业相当的重要。什么是前置作业呢t最简单的说法就是对于整个游戏的规划。由于笔者刚才也提过制作一个角色扮演游戏需要协调各方面的人员，因此前置作业的成功与否，就会影响到游戏的后期制作。现在先请各位看下面的这个图表：
　　工作类别　第一月　第二月　第三月　第四月　第五月　第六月
　　企划脚本　
　　程序设计　　　　　
　　美术设计　　　　　　　
　　音乐音效　　　　　　　　　　　　　
　　这个图表是表示一个计划在六个月里完成的角色扮演游戏各方面的工作进度表。当然啦，制作一个角色扮演游戏所需要的时间可能不止六个月，不过本专栏为了不浪费各位太多的时间，因此将以一个较小的案子来进行，因此设定的制作时间就只有六个月。至于工作类别的分类上，笔者也以最少量的人员来进行规划（在许可的情况下，部份的工作可以再作一些分工，像是企划和脚本就可以分成两个不同的工作类别）。
　　在这个子中，笔者只将工作分成四个部份。现在笔者就先为各位说明各个工作类别所负责的工作：
　　1.企划脚本（Game Designer/Scenario Writer）
　　企划和脚本可以说是角色扮演游戏中的骨干，一个好的脚本可以让整个游戏的剧情引人入胜，同时好的企划也能够吸引玩家。因此在这四个游戏的分类中，企划脚本可以说是最重要的工作了。不过各位可不要以为工作就只有这么一点点，在游戏制作中，企划通常也担任了资料设定、调整以及测试难易度的工作。特别是在台湾目
前的游戏产业来说，由于人手并不是那么的充足，同时具有企划经验的人才也不是很多，因此各位读者若是玩到一个难度设定不佳的游戏，通常都是没有经验的企划所设定的。或许有些人会认为只不过是设定资料嘛，这又有什么难的t但是请各位先想想看，在各位玩过的角色扮演游戏中，是不是有一些难度设定的刚刚好，不需要玩家花太多的时间去练功的呢t这样子的游戏各位在玩的时候是不是比较舒服呢t
　　至于还有什么东西需要设定呢t各位看看在一个角色扮演游戏中，每一个城镇有什么样的设施（像是旅店、武器店、道具店等等）；商店中要卖什么样的东西；每个地点出现的敌人有那些；以及各种在角色扮演游戏中看起来不是那么醒目的东西，其实都需要有人一一去设定。这些看似不怎么重要的东西，若是设定的人没有仔细的规划，那么这些资料就白费了。在国内的角色扮演游戏中，曾经出现过人物有一堆的属性，但是在战斗中完全没有作用的情况，这也就是企划不良的后果。
　　2.程序设计（Programmer）
　　这个工作从字面上来看，就可以知道它是作什么的。当然啦，笔者也不在这里多花时间和各位说明程序设计有多么的重要，或是程序设计要注意些什么事。不过隐藏在游戏设计之下，却有很多程序与企划协调有关的事情，若是要制作一个角色扮演游戏时一定要注意。首先，如果各位在制作一个角色扮演游戏时担任的是游戏企划的话，那么各位必需要和程序保持相当程度的连系，对于程序所开发的各种工具也必需要全盘的了解程序的规格。为什么笔者会这么说呢t我们就举一个例子来说，在角色扮演游戏中地图的大小，也就是地图是由多少个地形元素【注一】所构成的，企划就必需要了解。因为这是程序在撰写工具时所开出的上限，如果说企划不需要用到这么大的范围，那么最多不过是浪费了些内存，这还没有关系；但若是企划要求的范围比这个还要大，此时原本写好的程序就完全的白费了。
　　以实际的数据来说，若是程序在工具中只提供１２８ｘ１２８的地图范围，而企划所要求的是２５６ｘ２５６地图范围的话，那么在内存上的要求整整差了四倍。这样的问题虽然可以借由修改程序来解决，但是所花费的时间就浪费了。从这个例子来看，各位可以发现这其实只要稍微的沟通一下，就不会发生如此的情况，因此在程序开始制作时，必要的沟通是不可避免的。而随时和程序保持相当程度的连系，更是一件重要的工作。
　　3.美术设计（Graphic Designer）
　　在一个游戏里，最容易看到的工作就是美术设计了，当然各位读者也一定很了解美术对于角色扮演游戏的重要。在早期的游戏中，由于画面并不是游戏的重点，因此当时常有程序兼美术或是企划兼美术的情况，甚至有些游戏所需要的图形全是用扫描的。但是随着硬件的进步，这样的情况已经不太常见了。
现在，美术在游戏中占了很重要的地位。举例来说，从游戏制作初期角色的设定，中期各种地行元素、人物的绘制，一直到后期各种画面上的特效，都需要美术人员来制作。随着硬件的进步，美术人员使用的工具也不再只有DPⅡ、PHOTOSHOP等软件了。像是3D STUDIO、3D STUDIO MAX等等，部份的游戏公司还引进了高级的绘图工作站ＳＧＩ【注二】，使得美术工作的挑战也越来越大了。
　　4.音乐音效（Music and Sound）
　　在一个游戏中，音乐和音效担任的是搭配的工作。不过这一项工作在国内还没有到达一个专业的程度，国内大部份的游戏公司都在找外围的音乐工作室【注三】进行配乐，由于配乐者对于游戏的内容并不是很了解，因此曲子和游戏的搭配也就不如国外游戏表现得那么的完美。虽几家公司是由公司内部的人员来担任配乐的工作，但是也还没有达到专业的程度。
　　至于音效的部份，像国外那样由专业的音效工作室负责的情况也很少出现，大部份的公司还是维持在使用录音设备自行录制音效，因此有些游戏里的音效就直接从其它游戏中录制。就算是游戏中的语音，也还有一些公司是使用单纯的麦克风来录制，因此游戏在音效上的表现实在是并不理想。这样的情况虽然可以解释为市场太小没有充足的资金，但对于有接触国外游戏的玩家来说，就没有办法认同了。只能希望有一天国内的游戏产业发展到一个阶段后，可以重视这样的问题了。
　　现在我们再看看刚才那个时间表，各位可以发现到在游戏开始制作的第一个月，只有企划脚本方面的工作要进行，这是什么原因呢t其实这个阶段是在进行游戏的规划，也就是说其余的成员要依据这个阶段设定的各项规格来进行制作，而这个工作就是笔者在前面曾经提过的前置作业。
　　事实上在其它的国家，这个前置作业的时间不会只有这么短，以邻近的日本来说，有时候前置作业的时间甚至比真正在制作游戏的时间还要长。但是在这个前制作业中，担任各部份企划的人员会将所有相关的资料全部设定好，有时后甚至连每一个元素或是人物的位图都已经画好，这样子在后期制作的时候就只要照着画就可以了。国内目前还没有到这个程度，因此大部份的情况下都是由企划一个人【注四】负责整个前置作业，因此自然无法和国外的案子进行的情况相比。但若是一个游戏在执行制作的时候超过了原本预计的执行时间（举例来说原本预计一年完成，结果实际的制作时间是三年），这可就是企划在预估制作时间时的错误了。
　　由于是一个人进行规划的，因此自然也无法和国外那种各项专长集合在一起的团队创造来得完美。据笔者所知，国内的某游戏公司的主管就曾经要求底下的企划写出「两百页」的企划案，而且在完全不知道硬件需求及软件限制下蒙着头硬写，会有这样的情况明显得是这位主管不了解国内的游戏制作情形。因为若是采用这样的方式去执行企划案，很有可能在制作的时候发生问题。
　　举例来说，该公司曾经计划要支持某一块尚未上市的３Ｄ加速卡，因此计划要制作一款３Ｄ的格斗游戏，结果因为不知道那块加速卡的硬件功能，只有纸上的资料，在花了几个月的时间后案子也不了了之，这正是管理者错误的执行情况。就以这个案子来说，若是想要顺利的完成，应该要先取得硬件，然后让程序去根据硬件的资料来了解这块加速卡的功能到什么程度【注五】，然后将这些测试后的数俱交给企划去开出可以执行的企划案来。而不是在什么都不了解的情况下，就这么贸然投注人力去执行。
第一月 企划脚本 游戏系统的设计、故事大纲的编写
程序设计 没有
美术设计 没有
音乐音效 没有
第二月 企划脚本 编写各种装备、敌人资料、剧情内容
程序设计 设计地图编辑工具及主地图画面程序
美术设计 绘制地图组件及编排地图
音乐音效 没有
第三月 企划脚本 设定地图资料
程序设计 设计战斗子程序
美术设计 绘制地图组件及编排地图
音乐音效 没有
第四月 企划脚本 设定剧情资料
程序设计 设计各种特效程序
美术设计 绘制人物及敌人
音乐音效 为各场景编写背景音乐
第五月 企划脚本 设定战斗资料
程序设计 进行所有子程序的连结
美术设计 绘制战斗效果时事件画面
音乐音效 录制各种音效
第六月 企划脚本 进行测试及调整游戏难度
程序设计 修正程序中的错误部份
美术设计 没有
音乐音效 没有
　　这就是根据上表所排出的每个月的工作进度，在游戏的前置制作中若是能够有这样子的预先规划，那么就算是稍有延迟，也不会太过于离谱了。
　　注一：所谓的地形元素，指的是用来构成地图的基本组件。在角色扮演游戏中，无论地图的大小是多少，都是由这基本的组件所组合而成的。至于地图的复杂程度，则视元素的数量而定。
　　注二：ＳＧＩ指的是一种绘图工作站，并不是一套软件。在这个上面有几套很有名的绘图系统。像是因超级任天堂版「大金刚」而闻名的Alias、Gameware、以及被Microsoft移植到Windows NT上的Softimage等等。目前电影中大部份的特效（像是「魔鬼终结者Ⅱ」）都是使用这样的绘图工作站来进行特效制作的。
　　注三：虽然国外的游戏公司也有外包工作给工作室，但是在专业的程度上有很大的不同。举例来说，在Mech WarriorⅡ这款游戏中的音响效果就是由负责电影「魔鬼大帝」的音效工作室所担任的。
　　注四：虽然有部份的公司是由小组一起讨论，或是由公司里几个人一起来构思。但是在游戏制作的时候只有一个人来进行企划的编写，而没有各方面专长的人来参与。如果说是由一个小组，里面有各种专长的人员，那么就很完美了。
　　注五：再举一个例子，就以国内几家取得Saturn授权的公司来说。从取得授权到现在这么久的时间，都是花在熟悉硬件机能上。毕尽一款新的硬件还是需要时间趣研究的，想要靠别人写出通用的工具总是没有那么快啊。
RPG游戏制作教程
〖二〗
　　在经过了上一个月的介绍后，本月正式进入角色扮演游戏设计的第一个月了。首先请各位先看看上个月的专栏，在第一个月里是不是只有企划脚本的工作呢？不过以国内目前的游戏界来说，由于前制作与后制作负责的人都是同一群，因此在进行初期的企划脚本时，大多是采取集体创作的方式。一方面可以集合众人的意见，使得游戏的创意更加的丰富；另一方面可以让所有即将参与这个案子的伙伴对于游戏有认同感，在进行制作的时候更有冲劲。以下笔者将就第一个月进行时的流程作一个详细的说明。
　　◎第一步：找寻点子
　　开始制作一个游戏的第一步就是寻找点子，身为企划人员，广泛的吸收各方面的知识是相当重要的。举例来说，除了从游戏中吸收其它游戏的创意外，还可以从小说、漫画、电视、电影中找寻各式各样的点子。平时保持不断吸收新知的习惯，然后将自己有兴趣的点子一一记录下来，等到要开始创作一个游戏的时候，就不用全部重头想起，只要由这些记录中找寻有用有趣的点子，就是很好的办法。
接下来就是将这些点子形成一个游戏的基本架构。一般来说，设计游戏的人员都会将自己的喜好加入游戏的点子中，使得游戏成为自己所喜欢的样子。在这个阶段的公式是：
　　　　自己喜欢的游戏＝自己想完成的游戏
　　可是自己所想要完成的游戏是不是就是玩家有兴趣的游戏呢？如果说设计者不注意的话，可能会造成自己所设计的游戏无法吸引玩家的喜爱，使得原本的公式会成为：
　　　　自己喜欢的游戏＝自己想完成的游戏≠玩家想玩的游戏
　　因此，如何在自己喜欢的游戏和玩家想玩的游戏间取得平衡，就是各位在进行企划会议时要注意的事情。除了要找出有趣的点子，还要找出可以吸引玩家的点子，这样子设计出来的游戏才会成功。
　　◎第二步：构思背景
　　决定了各项的点子之后，就要为游戏创造出一个时代背景来。在这的时候，需要注意以下的几点：
　　1.时代
　　整个游戏是发生在什么时代里。在笔者的游戏企划经验里，大致的将时代分为古代、近代、未来、以及近未来这四个时段。像一般玩家常看到的这些幻想式的角色扮演游戏（无论中国或是西洋的）都是古代的；至于使用现实的社会状况，像是游乐器中「三只眼」这样题材的游戏，则是属于近代的；如果故事是发生在遥远的未来，与现实的状况没有关连，则可以算是未来；至于近未来，指的是和目前时间相差的不会太远，例如说一九九九年，由于时间很近所以和现实的状况不会差得太多，但是又可以有某些程度的不同。
　　为什么我们要这么样来区别时代呢？其实这是为了要让游戏的时空背景先确定下来。因在这样子的作法下，每一个时代都会有各自的特色及风格，不会有错乱的情况。虽然说在某些游戏里也有混合时代的作法，但由于玩游戏的人通常对于时代都有固定的认知，因此这种混合时代的方式并不是很成功。举例来说，若是我们设计一个古代的武侠角色扮演游戏，结果里面出现了像是雷射枪这样的现代武器，不是很奇怪吗？虽然说设计者也可以用其它的方式「掰」出合理的解释。但是无论如何的解释，这样的设定还是和一般人的观念不合，因此还是会发生有玩家无法适应的状况。
　　2.场合
　　游戏剧情发生的场合。就以古代这个时代背景来说，就可以简单的分成中国的古代或是西洋的中古时期，若是要更详细的分类，就还可以依时间来标明这个场合是发生在什么样的时代里。以中国的武侠角色扮演游戏来说，在不同的场合里自然就会有不同格局的游戏。
　　场合除了用来作时代的补充之外，也可以用来做更进一步的说明。若是各位要架构一个需构的时代（举例来说像是第三次世界大战后，人类几乎都已经灭亡，由机器人统治整的地球），就需要在场合上做更进一步的说明，才可以让游戏的背景明显得表现出来。
　　3.社会结构
　　在这个时代及场合中，社会是如何的一个结构。就以前面笔者所说的这个第三次世界大战后的情况来说，社会的结构就必需要详细的加以描述。像是整个地球由一部主控计算机所控制，人类的地位只不过是机器人的奴隶。这样子的描述可以让企划在开始编写剧本时，能有一个固定的依据。
　　编写一个架空的社会结构时，由于没有什么参考资料，因此企划可以天马行空的任意发挥。若是一个有真实年代的游戏，在这方面的限制就比较多，因为设计者虽然可以在某着程度上扭曲历史，但是还是会受到限制，若是一个依照史实来编写的剧本，在资料的考究上就更是重要了。
　　由以上的这三点，各位一定会发现到若是要设计一个与历史有关的游戏，自然会受到比较多的限制。这也就是为什么各位在目前市场上的角色扮演游戏中，找不太到这一方面的游戏了。大多数国内的游戏企划，也为了资料取材上的便利性，大多选择了幻想式的剧本，如此一来发挥的空间也比较大。
　　那么如果各位要开始进行一个角色扮演游戏的企划案，就可以先依这三点来起头，此时请看下面的例子：
　　时　　代：剑与魔法的中古骑士时代　　场　　合：神圣的卡拉斯王国，统治者是现任的国王卡拉斯　　　　　　　七世。由于受到魔王手下的危害，使得王国受到了威胁。　　社会结构：卡拉斯王国是由农民所组成的王国，因此没有和　　　　　　　魔王对抗的能力。
　　好了，这就是笔者随笔写出来的一段起草案，故事的内容正如同传统的角色扮演游戏中勇者杀魔王拯救王国的背景相同，很老套不是吗？那么各位也可以试着自己写写如此的起草案，并不会很困难。如果你不喜欢如此老套的背景，也可以自己想一些有创意的背景呀，这才是笔者开辟此一专栏的意义。
　　◎第三步：故事大纲
　　现在我们有了游戏的背景就可以开始想想故事大纲了。在国内的某些游戏设计者的经验里，故事似乎都是边做边想的。不过笔者并不鼓励这样的作法，因为随着游戏的进行，企划很有可能因为其它事情在忙而不得不分心，在这种情况下发展的故事常会有「虎头蛇尾」的状况。因此若是能够在企划的初期就定下故事大纲，就可以避免这样的情况。
　　要开始进行故事大纲的编写前，我们先来看看角色扮演游戏的标准故事流程：
　　　　　┌────┐　┌────┐　┌────┐　┌────┐　　　　　　　　　　　　　　　　
　　　　　│游戏开始├→│收集情报├→│战斗成长├→│更换装备├┐　　　　　　　　　　　　　　　
　　　　　└────┘　└────┘　└────┘　└────┘│　　　　　　　　　　　　　　　
　　　┌────────────────────────────┘　　　　　　　　　　　　　　　
　　　│　┌────┐　┌────┐　┌────┐　┌────┐　　　　　　　　　　　　　　　　
　　　└→│解决事件├→│向前推进├→│打败头目├→│游戏结束│　　　　　　　　　　　　　　　　
　　　　　└────┘　└────┘　└────┘　└────┘
　　在这个标准的单线式角色扮演游戏的流程图中，各位可以看到会影响到游戏进行的就是其中「解决事件」这一格。这个解决事件，也就影响到游戏剧情的有趣与否，设计者如何去规划一个又一个的事件让玩家去解决，也就是角色扮演游戏的最大目的。
　　在角色扮演中，最常见的事件就是打败某个出现在固定地点的角色，依这名角色的重要性，我们可以分别将之命名为小头目、中头目、大头目、以及最后头目等四级。在这其中除了最后头目照惯例只有一位外，其于的三种则是依在剧情中的重要性和不可或缺的程度来决定，而且决对不只有一只。为什么笔者会说依它的重要性和不可或缺性呢？因为随着角色扮演游戏的发展，有些游戏已经出现了所谓的旁支剧情的结构，这些旁支剧情不会影响游戏的进行，因此玩家若是不去处理也不会造成「卡住【注一】」的状况。至于对于游戏进行会影响的头目的重要性自然也就比较高了。
　　不过是一个角色扮演游戏中所有的剧情都是「打倒某地的某某」这样的情节的话，恐怕玩家也会抗议了吧。因此游戏中也有一些不是那么血腥的任务，像是帮某个重要的人士找东西以换取通行证啦，协助分离的情侣重新见面啦，如此的情节各位在角色扮演游戏中也经常看到吧。以下笔者列出一些常见的事件发生情况：
　　　　1. 某个ＮＰＣ向玩家一行人求助，要求玩家去协助他。
　　　　2. 某位ＮＰＣ有某种程度的仇恨，希望玩家能够助他复仇。
　　　　3. 追寻着某位ＮＰＣ的行踪。
　　　　4. 某地正准备发生谋反或是暴动的状况，而玩家正好卷入这场动乱。
　　　　5. 一场战争即将发生，位于其中的玩家该如何的处事。
　　　　6. 为了达成某种目的，因此接受了严苛的训练或是考验。
　　所以啦，若是各位担任企划的人平常多看小说戏剧等等，自然可以从其中获得不少的参考资料。这些生活上的一点一滴，最后都可以成为您的一部份，并且在您的游戏中发挥很大的作用呢。现在我们就依上面的那个起草案，来写出它的故事大纲：
　　游戏的主角是一名流浪的骑士，这一天经过一个残破的村庄，从村民的口中得知王国正受到魔王的危害。　　基于正义感，主角前往王城觐见国王卡拉斯七世，从国王的口中得知一切的事情，同时也知道公主已经在上一次魔王手下的来袭时被抓走了。国王告知想打败魔王，就要先取得传说中的勇者之剑及勇者之铠。勇者之铠被放置在大陆西边的神殿里，那里已经被魔王的部下所占领了；勇者之剑则要取得大陆南边火山里的金属，再交给老铁匠来打造。　　于是主角来到大陆西边的神殿，打倒了占领此地的魔王手下，取得了勇者之铠。　　接下来南边的火山，在通过了迷宫洞窟的考验后，找到了可以打造勇者之剑的神秘金属。　　带着神秘的金属找到了隐居的老铁匠，将神秘金属交给他，就可以打造出勇者之剑。　　有了勇者之剑和勇者之铠之后，前往魔王的宫殿与魔王展开决战，在打败了魔王救回公主后，使王国恢复了和平，而者名流浪的骑士也和公主结婚成为下一任的国王。
　　这就是笔者所写的故事大纲，有了这个故事大纲后，身为企划的人就可以依照这个故事大纲来区分会有多少的事件。在这个例子里，共有下的几个事件：
　　　　1. 骑士来到村庄，得知事情。
　　　　2. 前往王城见到国王，了解解决事情的办法。
　　　　3. 打倒神殿里的敌人取得勇者之铠。
　　　　4. 通过火山迷宫取得神秘金属。
　　　　5. 将金属交给老铁匠，就可以获得勇者之剑。
　　　　6. 进入魔王宫殿打倒魔王，游戏结束。
　　这样子一共是六个事件，以条列式的写法就是这一到六号。在游戏中，若是一定要先取得勇者之铠才能取得勇者之剑，则流程图是以下的状况：
　　　┌─┐　┌─┐　┌─┐　┌─┐　┌─┐　┌─┐　　　　　　　　　　　　　　　　　　　　　　
　　　│一├→│二├→│三├→│四├→│五├→│六│　　　　　　　　　　　　　　　　　　　　　　
　　　└─┘　└─┘　└─┘　└─┘　└─┘　└─┘
　　这种状况的剧情结构就是传统的单线式剧情。若是游戏中取得勇者之剑或是勇者之铠并没有一定的顺序，那么玩者可以自己决定行动的顺序，则流程图如下：
　　　　　　　　　　　　┌─┐　┌─┐　┌─┐　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　┌→│三├→│四├→│五├┐　　　　　　　　　　　　　　　　　　　　　　　　
　　　┌─┐　┌─┐│　└─┘　└─┘　└─┘│　┌─┐　　　　　　　　　　　　　　　　　　　　
　　　│一├→│二├┤　　　　　　　　　　　　├→│六│　　　　　　　　　　　　　　　　　　　　
　　　└─┘　└─┘│　┌─┐　┌─┐　┌─┐│　└─┘　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　└→│四├→│五├→│三├┘　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　└─┘　└─┘　└─┘
　　这种状况就可以称之为多线式剧情了。虽然说每一位玩者接触的事件都相同，但是可以因排列的顺序不同而有多变的情节，则是每个企划都希望能够做到的。若是由于事件发生前后的不同，也能有对应的对话讯息，则更是完美了。否则只有多线的外观而没有多线的内容，虽可以骗过不知情的玩家，但总是缺了那么点似的。
　　◎第四步：决定游戏的外观
　　在游戏的内容物决定了之后，就要来订定游戏的外观了。以角色扮演游戏来说，最常见的分法就是地图画面及战斗画面。
　　以地图画面来说，通常是分为平面式、立体式、以及最近常见的四十五度角式【注二】。至于战斗画面则是以面对面、左右方、以及四十五度角等变化比较多。目前，也有一些游戏在战斗时不切入战斗画面，而直接在地图画面上表现。这种作法我们就将他认定说地图与战斗画面相同好了。
　　选择画面的外观通常会牵涉到设计者所想要表现的，这一部由于牵涉较广，同时也有一些美术方面的问题，因此笔者在这一期不多作说明，留待下个月谈到地图原件时一并说明。
　　◎第五步：决定系统
　　在这里所提的系统，指的是游戏中玩者所会接触到的界面。也就是我们所说的使用者界面（User Interface）。这些界面包含了在地图上移动得控制方式，有那些可以使用的指令；在战斗中的控制方式，以及各种的战斗指令；其余像是进入商店时的操作界面，玩家可以看到的窗口等等，都属于这一部份的工作。这个部份规划得好不好，直接影响到玩家在进行游戏时的便利度，同时也等于游戏对于玩家的友善程度。
　　好啦，这一个月笔者就谈到这里了。本月的讨论内容大多集中在企划的工作上，但是下个月开始，程序与美术的工作将要一件一件的加进来了，各位下个月见uuu
　　注一：这是一个角色扮演迷口中常见的名词，指的是游戏的进度被卡住，没有办法继续向下推进。
　　注二：自从国内的「仙剑奇侠传」一炮而红之后，这种视角也有人戏称为仙剑Like。事实上，虽然「仙剑奇侠传」并不是第一个采用此种视角的游戏，但是从市场上一堆长得很像仙剑的游戏来看，这种说法倒也是没错。
RPG游戏制作教程
〖三〗
　　经过了第一个月的规划期，在进入第二个月了之后，企划、程式、以及美术都要开始工作了。因此，在本月的文章中，笔者将分别介绍各部份的工作以及注意事项。
□企划部份
　　◎第一步：决定资料格式
　　在进入游戏制作的初期，由于有许多和程式有关的资料需要编整，因此担任企划的人员常会忙得乱七八糟。在这个阶段，企划人员必需要和程式商量游戏中资料的格式。举个例子来说，在程式要开始设计游戏的相关工具程式时，他就会需要各种相关的资料，此时企划就必需要将这些资料一一表达给程式，让程式能够设计出合用的工具程式。像是设计一款角色扮演游戏时第一步要做的就是一个地图编辑器，因此身为企划的人要能够很明确的讲出这个地图编辑器的规格，像是地图的尺挤段А咀⒁弧俊⒚空诺赝寄芄皇褂玫牡赝荚厥俊咀⒍俊⑿枰瓒ㄊ裁聪喙刈柿系鹊取咀⑷俊
　　◎第二步：设定各项资料
　　解决了地图资料后，程式就会开始设计地图编辑程式，此时企划并不是没有事要做了，而是面临了另一个新的工作，就是设定游戏中的各项资料。在这里所指的各项资料，指的是在游戏中将会使用到的各种相关资料，像是在角色扮演游戏中占有重要地位的道具资料；使用不同魔法发生效果的设定资料；以及战斗中的另一主角～敌人资料的设定，都是包含在这个阶段的任务。由于当程式人员将地图编辑程式写好后，企划就要开始针对这个程式进行一连串的工作，因此若是不在这个阶段先将游戏相关的资料整理好，等到要用的时候就会手忙脚乱了。
　　现在笔者就以道具资料来做个介绍。各位读者先想想看，在设定道具资料时需要有那些相关的资料呢t以道具的种类来说，通常我们可以将它分为几个大类，首先是可以大略的分为人物用的装备以及使用道具，接下来装备有可以依功用的不同而再区分为武器、护甲、头盔、盾牌等等，有些游戏甚至还细分到手套、鞋子等多项不同功用的人物装备，这都是视企划认为自己的游戏中需要而决定。至于在使用的道具中，也可以大略分为治疗用道具、移动用道具、辅助型道具、以及角色扮演游戏中过关所需的必要道具。
　　那么我们再来看看在角色扮演游戏中的道具到底还需要些什么相关的资料呢t首先是人物装备这一类，在角色扮演游戏中需要设定每一件装备那些人人可以使用，以及装备后所能产生的效果。通常我们常见的简单作法就是依装备的种类给予一个数值，这个数值所代表的就是攻击力或是防御力。不过这样子的设计对于要求比较多的玩家似乎无法满足，因此也有的游戏采用每一件装备都有数个数值是表示影响人物的状况。就让我们举个例子来说吧：
　　我们就以简单与复杂的两种方式来表示装备的资料，首先我们看以下的资料（先不管可以装备的人物）：
　　　┌──┬──────┐
　　　│名称│能力　　　　│
　　　├──┼──────┤
　　　│短剑│攻击力＋１０│
　　　│巨斧│攻击力＋２２│
　　　└──┴──────┘
　　这就是简单的装备资料设定，这种作法只能简单的表现出每件装备的好坏，但是却缺乏了装备的特性，因为在装备的资料中，只有一个数据是与战斗有关的，因此对于玩家来说，东西的好坏就只有靠数值的大小来决定。
　　不过各位想想看，当一位角色装备了一把短剑、和装备了一把巨大的战斧时，是否只有攻击力上的差异呢t是不是装备了巨斧的人物会受到武器的影响而使得攻击的速度较慢呢t因此在角色扮演游戏中也有这种复杂的装备资料：
　　　┌──┬───┬───┐
　　　│名称│攻击力│敏捷度│
　　　├──┼───┼───┤
　　　│短剑│＋１０│－　２│
　　　│巨斧│＋２２│－１０│
　　　└──┴───┴───┘
　　如果采用以上的方式，那么人物装备了一件比较强力的装备时，可能会有其他的属性随之下降，因此玩家在给人物装备武器时，所要考虑的就不只是武器的攻击力，而同时要考虑到这件武器是否适合这名人物了。这样的作法，使得每一件装备都更有特色，购买装备时也不再是挑数字大的装备就好，使得游戏能够比较多变。
　　那么是不是这样子就够了呢t其实各位担任企划的人员可以发挥自己的巧思，增加独特的装备特性。举个例子来说，可以增加一组数据作为武器的攻击命中率。如此一来可以设计出攻击力强但是命中率低的独特武器；也可以设计出攻击力低但是命中率高的武器，如此一来玩家在进行装备时就要更加注意了。只有发挥巧思规划出自己的特色，才能够让每一件装备有著与众不同的个性。
　　那么一般的道具又有什么重要的资料是不可缺少的呢t各位读者请先想想看在您所玩过的角色扮演游戏中这些道具有什么资料呢t在角色扮演游戏中常见的道具就是用来恢复生命及法力的药剂（有的游戏是草药或是卷轴等等），此外恢复人物不良状况的道具（像是中毒、麻庳等）也是常见到的。这一类的道具，通常我们都称之为治疗用道具。
　　除此之外还有些什么样的道具呢t像是用来打开各种不同门的钥匙、使用后可以产生与魔法相同作用的魔法道具、可以让角色快速的移动到其他地点的道具、以及在剧情中需要的各种道具，都是角色扮演游戏中常见的不是吗t这些道具有的看起来可能不是那么的起眼，但是它们的存在却让角色扮演游戏增色不少，因此如何去规划这些道具就是各位企划的一个重责大任。
　　好了，现在道具的资料该怎么设定大家都知道了吧，现在我们来看看其他要设定的资料。首先要看的是魔法的资料，在这里我们要设定每一项魔法的功用，像是这项魔法是攻击、防御、还是其他功用的，至于使用时消耗的法力、以及魔法的效果（治疗法术是恢复点数，攻击法术是伤害点数）都要在这个时候一一规划好。
　　完成了魔法的规划，就可以开始设定敌人的资料。在进入战斗时，每一名敌人角色所需要的资料其实就和玩者控制的角色相同，才可以进行各种相关的运算，因此在这个阶段，担任企划的人员就要小心的规划每一名敌人角色的数值，才可以使得游戏进行时不会有太难或是太简单的状况发生。有一些游戏为了预防这样的状况，因此出现敌人的等级是随著玩者控制角色的强弱而随之更改，也算是解决了难易度的问题。
　　◎第三步：编写完整的剧情
　　在这些资料都设定完成后，企划就要开始正视角色扮演游戏的骨干～剧情了。由于在第一个月中已经完成了故事大纲，因此这个时候就要跟剧这些大纲发展相关的情节。现在就请各位先看看上个月我们设计的剧情大纲：
　　游戏的主角是一名流浪的骑士，这一天经过一个残破的村庄，从村民的口中得知王国正受到魔王的危害。　　基于正义感，主角前往王城觐见国王卡拉斯七世，从国王的口中得知一切的事情，同时也知道公主已经在上一次魔王手下的来袭时被抓走了。国王告知想打败魔王，就要先取得传说中的勇者之剑及勇者之铠。勇者之铠被放置在大陆西边的神殿里，那里已经被魔王的部下所占领了；勇者之剑则要取得大陆南边火山里的金属，再交给老铁匠来打造。　　于是主角来到大陆西边的神殿，打倒了占领此地的魔王手下，取得了勇者之铠。　　 接下来南边的火山，在通过了迷宫洞窟的考验后，找到了可以打造勇者之剑的神秘金属。　　带着神秘的金属找到了隐居的老铁匠，将神秘金属交给他，就可以打造出勇者之剑。　　有了勇者之剑和勇者之铠之后，前往魔王的宫殿与魔王展开决战，在打败了魔王救回公主后，使王国恢复了和平，而者名流浪的骑士也和公主结婚成为下一任的国王。
　　企划人员要依自己所规划的剧情大纲，来开出游戏中要出现的地点。这些地点，也就是要提供给美术人员进行地图的绘制，因此一些相关的资料以及描述自然也少不了。以这个范例来说，需要出现的地点如下【注四】：
　　　　1. 受到攻击的村庄。
　　　　2. 国王所在的王城。
　　　　3. 大陆西边的神殿。
　　　　4. 大陆南方火山的迷宫洞窟。
　　　　5. 老铁匠的隐居地点。
　　　　6. 魔王的宫殿。
　　这六个出现在故事大纲中的地点就是本游戏中一定要存在的地点，也就是在制作时要列为第一优先的地点。当然有些游戏设计者也会在地图上放置一些无关剧情的地点，这就要让各位担任企划的人员自由发挥了。到了这里，本月份企划的工作也到一个阶段了。以这个月来说，企划的工作是相当繁重的，不过若是不能好好的处理这一方面的问题，恐怕会导致游戏制作后期更大的状况喔。
□程式部份
　　◎第一步：和企划讨论程式的规格
　　进入第二个月之后，程式就要开始进行程式的撰写了。此时第一件事就是和企划进行讨论，开出各项的规格。
　　这个时候，担任程式的就必需要时时计算企划所开出来的规格会使用到多少的记忆体，自己所写的程式是不是能够负担这样的容量。虽然现在制作游戏已经进入了Windows的时代，可以不用太记较记忆体的使用，但是太过于夸张的记忆体需求，还是会造成玩家机器的负担，影响到游戏的效率，因此仔细的推算将是日后的保障。
　　◎第二步：撰写工具程式
　　在前面企划的部份笔者曾经和各位讨论过工具程式开出的规格，这里就和各位讨论这些规格对于记忆体的负担。首先我们来看看地图元素大小对记忆体的影响，在同样以２５６个地图元素的情况下，不同尺妓加玫募
忆体如下：
　　　┌────┬─────────────┐
　　　│地图尺寸│占用记忆体大小　　　　　　│
　　　├────┼─────────────┤
　　　│ 16×16 │16×16×256＝65535 bytes　│
　　　│ 8× 8　│ 8× 8×256＝16384 bytes　│
　　　└────┴─────────────┘
　　接著我们来看看地图范围这项数据，先不管地图的尺寸大小，我们还是决定每一张地图上只会出现256 个地图元素，因此在这种情况下，不同的地图范围所占用的记忆体如下：
　　　┌────┬───────────┐
　　　│地图范围│　　所需记忆体大小　　│
　　　├────┼───────────┤
　　　│256×256│256×256＝65535 bytes │
　　　│128×128│128×128＝16384 bytes │
　　　│ 64× 64│ 64× 64＝ 4096 bytes │
　　　└────┴───────────┘
　　这个数据是怎么求出来的呢t各位读者就先把一张地图想像成方格纸，每一格就代表了地图上的一块地点。我们将256个地图元素分别编号为0至255，那么每一格只能放一块地图元素就等于每一格只能填一个数字，因此这张地图上的资料就需要如上表一般的记忆体范围才能放得下了【注五】。
　　在这里我们所记算出来的数值是只有地图元件编号的空间，因此在这当地图上不能再加上其他的资料了。若是各位还要在地图资料上加上其他的资料，恐怕就需要第二层地图资料。这个第二层地图资料可以用来储存各种相关的资料，不过也会使得地图的资料增加一倍，因此在规划的时候程式要告知企划如此制作的后果。
　　在目前国内的游戏界，由于许多的程式也身兼企划工作，因此这个沟通的问题比较不容易发生。不过同时也由于身兼数职的情况常见，有时反而会因此疏忽了其他的问题，这样的情况千万要注意。
□美术部份
　　◎第一步：t解企划所开出的规格
　　身为美术人员，在进行游戏制作时最重要的就是要遵守企划所开出的规格。举例来说，若是企划开出的地图元素是16×16的大小，那么美术就必需遵循这个规格来绘制。不过若是企划开出的条件太过于苛刻，像是一张256×256的地图只能使用32个地图元素，会使得地图看起来太单调的话，就必需尽快向企划反应。
　　◎绘制相关的地图元素
　　在进入绘制地图元素的阶段后，美术人员唯一的工作就是画图。因此这个阶段要注意的事情就已经从游戏的制作转移到每个人对于自己专长的努力了。这个阶段并不在笔者这个专栏的讨论范围，因此笔者不多做说明。至于在上个笔者曾经讲过要谈地图元件的拼排，在下个月讨论到地图编排时会一并说明，请各位下个月继续收看。
□本月总结
　　这个月的工作到这里就到一段落了，若是各位对本专栏有问题的话，欢迎来信询问。我们下个月再见啦u
　　注一：在设定地图的范围时，就是要决定游戏中最大地图的尺肌Ｔ诮巧缪萦蜗分校赝级际怯梢豢橐豢榈牡赝荚兀蚴浅圃煨停┧槌桑虼说赝嫉某贾傅木褪怯啥嗌俚牡赝荚厮槌傻摹＞倮此担羰瞧蠡龅氖菔128×128，那就表示地图是由128×128个地图元素所组成。
　　注二：这里所指的地图元素数量，指的是在一张地图里能够使用的数量。虽然地图的尺伎梢陨杓频煤艽螅堑赝忌匣故怯行矶嘀馗吹牟糠荩虼说赝荚厥恳欢ǖ陀诘赝挤段А＞倮此担徽128×128的地图，可能只使用了256个地图元素。
　　注三：通常在角色扮演游戏中，在地图上还会同时设定一些其他的资料。像是这个地点可不可以通过、有没有隐藏宝物、以及敌人出现的频率、等级等等。这些资料有些人的作法是随著地图资料，有些人是另外编辑相对的资料档。
　　注四：在角色扮演游戏中，一定要有的地图就是整个游戏的大地图。这张地图是用来放置所有出现的地点，同时也是玩家经历冒险的整个经过。
　　注五：若是每一地图所能够使用的地图元素大于256个的话，那么所用的记忆体范围将会增加至少一倍。因为在电脑里每个Byte的数值只有０到255，因此当数值大于255之后，就必需要采用两个Byte来放置，使得记忆体的要求增加一倍。
RPG游戏制作教程
〖四〗
　　各位读者，游戏制作已经进入第三个月了。也渐渐的出现的一些雏形。在本月的文章中，讨论的重点将是与游戏的完成有著密不可分关系的部份，像是如何完成一个个游戏中的场景、各种与场景有关的资料、以及地图的构成。现在就请各位读者慢慢的往下看吧。
□地图的构成
　　在谈到编整地图场景的资料前，就让笔者先来介绍一下有关于地图的构成方式以及一些相关的知识。由于角色扮演游戏中是由一张一张的地图所构成，而故事也就是发生在这些地图上，因此t解地图的构成方式就是开始制作时必备的知识。
　　在角色扮演游戏中，地图的构成有许多种不同的方式，在这里笔者只介绍两种国内常用的方式～平面俯视角以及四十五度角。这两种视角可以说是国内的游戏公司所常用的视角。就以平面俯视角来说，就是早期一一些有名的游戏（像是“侠客英雄传”、“轩辕剑系列”、“天外剑圣录”等）都是使用这种视角；至于四十五度角则是这几年流行的，一些知名的游戏（像是“破坏神传说”、“仙剑奇侠传”、“金庸群侠传”等）则是使用这种视角。
　　这两种视角在画面的构成上有很大的差别，首先我们就以平面俯视角为例。在这种视角下地图的构成是由一片一片的元素【注一】所组成，因此在视觉上较无法做出立体的感觉。若是想要创造出立体的场景，就必需适度的利用远近法以及设定布景为前景或是背景来达成立体的效果。
　　说到这里，也许又会有读者问起为什么要创造出立体的场景呢t这样做又有什么作用t请各位先想想看，在角色扮演游戏中，当角色移动到一堵墙的后面时，是不是应该要有适度的遮罩呢t让人物会受到墙的遮掩而消失在玩家的视线之内不正是真实的状况吗t在这样的情况下，我们在编排地图的时候就要将这堵墙会造成遮罩的部份设定为前景，如此一来就可以造出立体的状况。如果要以图来表示，那就是以下的状况：
　　　┌───────┐←───　背景
　　　│┌───────┐←──　人物
　　　││┌───────┐←─　前景
　　　│││　　　　　　　│
　　　└││　　　　　　　│
　　　　└│　　　　　　　│
　　　　　└───────┘
　　这种方式和卡通拍摄时的方法类似。在一部卡通进行拍摄的时候，也是利用前景、背景的方式，来使得场景有著立体的效果。所以在各位读者进行角色扮演游戏的设计时，也可以利用同样的方式来达成相同的效果。只要在编排地图的时候，记得前景、背景的关系，就可以造出相同的效果。至于要达到这个目的，在设计地图编辑程式的时候也要先计划好，才可以达成这个目标。
　　至于另一种四十五度角，自从“仙剑奇侠传”一炮而红之后，加上“金庸群侠传”的销售状况，一下子市面上都是这一类的角色扮演游戏，无论是古代或是现代，无论是怎么样的故事背景，好像不使用这种视角就不行似的。在这种情况下，使得市场上所有的角色扮演游戏都采用了相同的模式。
　　不过，这种模式并不是现在才有的，早在好几年前就有几款游戏是使用这个视角了，像是有著不错声光表现的“破坏神传说”、有浓厚中国风味布景的“聊斋志异之幽谷传奇”、曾相当引人注意的“依卡斯特传说”，都是使用这样的视角。只不过当时这些游戏虽然表现都不错，但是没有引发一股跟风，因此在这种视角的地位上不及后来