游戏制作_游戏制作工具 - CSDN
精华内容
参与话题
  • 我做游戏开发这八年

    万次阅读 多人点赞 2020-07-19 10:01:37
    我做游戏开发这八年简述与编程擦肩而过从图像设计到痴迷编程入门编程沉迷编程Java的图形编程就职游戏开发2011,第一次面试&实习生第一个游戏2012年,第二个重量级IP游戏2013年,转战手游与创业2014-2015,第一次...

    简述

    这篇文章并不是想教会大家如何开发游戏,更不能教大家如何成为技术总监。而是分享我一路做开发的一些经历或心得体验。

    与编程擦肩而过

    2004年,初三升高中时,因为我考上市里最好的高中,因此父母兑现承诺给我买了一台电脑。那时候电脑配置还是挺好的(我记得是P4的CPU,1G内存,80G硬盘,优派的液晶显示器,还买了打印机、扫描仪)。由于我热爱游戏,因此有了电脑之后就开始陷入于各类游戏中无法自拔。基本每天晚上通宵玩游戏,玩到凌晨5、6点睡1-2个小时,然后去上学。基本高一玩了各种游戏,然后成绩自然也是一落千丈。

    到了高二的时候,因为我表姐夫是做美术设计的,因此我开始接触了Photoshop、Coredraw这两个软件。我一边瞎画着各种东西,一边想如果能让这些也动起来多好。因此开始接触了Flash。开始在网上看看各种Flash的教程,能做一些动画,能用按钮控件控制一些流程,也了解到AS2这一门语言,然后在网上找了各种酷炫的AS2代码加到自己的Flash里面,实现比如鼠标跟随的特效等等效果。这时候其实我还不会独立地写代码。

    由于高中各种的不务正业。从中考数学全市前几名,到最后高考没考上重点大学,这其实也是我预料中的。因为本来我就不是一个相信运气的人。那时候我只想快点脱离高中,可以更自由做自己喜欢做的事情。因此也没有选择复读。

    从图像设计到痴迷编程

    入门编程

    进入大学之后,我参与了好几个社团,成为各个社团网络部的成员。然后接下来的事情就是社团搞活动经常需要一些海报什么的。因此我高中自学的Photoshop和Coredraw就派上用场了。大一基本就是做了一年各种图像设计的工作。而从高中到大一带来的各种突如其来的自由,也使得我继续沉浸在各种游戏中。到了大一的暑假时,校团委突然找网络部帮忙做网站,而师兄们准备毕业的、准备考研的,都没啥时间。因此这重任落到了我一个人头上,我也不知道那么多成员为啥选中了我,也没想那么多。因此,我暑假放假前1个月,外加暑假2个月,整个3个月时间开始疯狂学习Html、CSS、Javascript、PHP、MySQL,然后3个月时间从学习到开发完成了校团委的任务,制作了一个CMS网站。这三个月时间让我觉得编程原来这么有趣。

    沉迷编程

    接下来大二的时候我就陷入了疯狂的学习和开发之中,最疯狂的时候一天在图书馆借一本PHP的书,当天借当天看完,晚上再自己把那本书最后的例子实现了,然后第二天再去换书,就这样我很快把图书馆所有PHP的书都看完了。书中的例子也都能自己写出来。然后开始接了很多外包,也快速赚到了第一个笔记本的钱。

    Java的图形编程

    由于大二做了很多的网站,已经觉得有点厌倦。进入大三,刚好我们有一门Java的课程,我看到Java可以开发图形界面(Swing/Awt),因此开始转向学习Java。我大概花了2-3周把学校发的Java书看完了,并且把里面的示例也都自己敲了一遍。基本没有障碍的完成了Java的学习。但是书本里面关于图形界面的太少了,只介绍了最基本的一些控件以及做一些简单的界面。因此我开始自己在网上找各种资料。这时候室友告诉我“Java做图形不好看的,还不如C++不如C#,等等”。我就偏偏不信了,我依旧进行自己的学习和研究,而他也依旧站在他认为的鄙视链顶端鄙视我。就这样,他学习他的SSH,而我学习着不入流的Swing、Java3D等。

    其实我那时候的心理:为啥你觉得他不行他就不行?我得自己实践过才知道。实践出真知,我觉得这是做技术一个很重要的特质。很多时候,很多东西大家只是凭经验人云亦云地传播,并没有亲自实践过。而我那时候还有一个心理,哪怕最后我花了很多时间之后做出来的东西确实不好看,那我也不亏,我在这个过程中肯定是能学到东西的。很多时候很多人会比较看重眼前做的事情收益如何,回收周期多长。但是我觉得,很多值得学习的知识都是回收周期很长,而且眼前收益很低的。 对于我而言,我更多的是基于兴趣去学习。我觉得这就足够了。

    最后的结果就是,我用Java开发出来的东西,他们觉得太好看,根本难以想象是Java快发的。这里有一些大学用Java快发的图形程序。

    1. swing超绚丽系列一—— 俄罗斯方块
    2. 纯Java开发的游戏引擎V0.5–DEMO2 – 物理引擎
    3. 杂七杂八的东西

    就职游戏开发

    2011,第一次面试&实习生

    2011年初,不知不觉到了大四第二学期。本来我还不想这时候去找工作,因为此时我觉得还有很多事情想做,比如那时候我还在用Java自己做一个3D游戏。但是大四寒假的时候,有个同学发了一个网页游戏公司的招聘链接给我,说这个公司还不错,我看了一下招聘要求,感觉自己符合要求,于是就顺手投了个简历。其实投简历之前,那时候北京GLU有位前辈想让我毕业后去试试。还有另一家互联网公司也是让我毕业后去工作。主要在于我大学期间经常在各个技术QQ群里帮大家解决问题,最开始他们以为我应该工作了几年,后来知道我还在上学,因此就想我毕业后去他们公司工作。

    后来肯定是我投的简历的公司让我去面试了,那天从下午2点面试到下午6点。从HR、主程序、制作人到CTO都面了。最后CTO面试的时候网络的BIO、NIO、多线程的安全问题如何解决也都问了。最后CTO说“你简历里写的都是Java做的图形界面,我们这Java都是做服务器,你接受做服务器吗“,我怕服务器又是做网站,于是问他”服务器也是做游戏吗“,他说“肯定是做游戏。我们做的是网游”。因此我就说“可以呀,只要是做游戏就好。”于是CTO接着说“你进我们公司肯定是没问题的,估计过几天会给你发Offer,你也不用去面试别的公司了”。

    因为我个人也懒得比较,既然CTO也那么说了,我就没去面试别的公司,在同学那玩了一周,一周后就入职了。

    记得那时候CTO还问过我一个问题“你说你这么喜欢写代码, 你想写到几岁”,我说“30岁吧”。他问我为啥只写到30岁。我说那时候可能我是技术总监了。就不用写代码了。后来我30岁的时候,成为了技术总监。但是我还是喜欢写代码。其实兴趣是可以一辈子的。我也不知道为啥面试那时候那么回答了。

    2011,第一个游戏

    刚进入工作比较紧张,总怕哪里做不好。第一周项目组说让我去改一下服务器列表。我那时候压根没有远程登陆过服务器改东西,主程就给了我IP、用户名、密码,以及网页的位置。于是我赶紧自己搜索了各种资料,在接到任务的半小时内,我第一次用SecureCRT登陆服务器,第一次用VI在服务器上修改文件。

    接着几天就是熟悉项目,我在服务器上自己找到了聊天的协议入口,然后加入了一些GM,给自己的账号加了赵云、吕布这些牛逼的武将。

    接着几天后,主程找我,说来的毕业生里面感觉你编程能力不错,你想去做新项目吗。我自然想体验从0开发游戏的过程。于是就满心雀跃地说“想!”。

    新项目开发的时候我充满了激情,基本上第一周我就完成了背包系统的开发。那时候公司其他游戏的数据存储都是同步的。主程就说,这个新项目估计用户交互会比较频繁和实时,同步存储怕会卡顿。于是我那一周开发背包的时候,顺便被服务器的数据存储写了个异步的存储。(后面该功能还被公司其他那项目组引用),立项一个月后主程就去了腾讯。而我们项目本来是公司的尝试性项目(公司其他项目都是SLG,而这个项目是RPG),因此也一直得不到重视,一直得不到重视。我们这项目加上我就2个服务器,开发了半年上线了。我对游戏业务非常熟,编程基础也还行,因此开发速度很亏,一个人开发了70%的系统。那时候很多同学问我,你做那么多,公司给你加工资了没有。我说没有,他们说,那没有你为啥做那么多。

    其实有的时候不是你在这个位置才能做这个事情。而是你有能力、主动地去做这个位置的事情,做多了你自然也就是这个位置的人。因为我觉得没有哪个公司会愿意付出成本让你冒险。

    项目上线的时候,公司也让我成为了这个项目的服务器主程。那时候我距离实习才半年,一直怕自己做不好,因此一直很努力提示各种能力。由于我开发的功能BUG极少,而且出BUG的时候修改极快,因此项目组的测试负责人说我说最受测试欢迎的程序,直到后来她去了银汉后遇到她,她还说她在银汉和测试部说,曾经有个程序员这样这样…

    写程序出BUG是常见的事情,想要减少BUG数量,要思维谨慎,业务熟悉,而想要修BUG快速,需要对所写的东西都烂熟于心,我之前经常对别人说要做到代码在心中。如果你写的代码你内心都很清晰,那么出问题的时候,很快就能定位到问题。这就像,你的代码存在于内存中,查找肯定快。如果每次都是要去慢慢看代码文件,那就像每次都检索磁盘,肯定会慢一点。我之前好多个性能问题都是在走路和洗澡想到的解决方案,假如心中没有代码,又如何能做到呢?

    2012年,第二个重量级IP游戏

    12年初的时候,公司准备做一个ARPG项目,是星爷授权合作的游戏《西游降魔篇》,那时候公司从我们第一个项目的表现觉得我们项目组还是具备比较好的研发能力的,因此这个项目就给了我们项目组。

    一开始公司让我做这个项目的主程序,我觉得我才毕业1年,我玩游戏很多,自知ARPG项目比我上一个RPG肯定要高。因此最开始希望公司能招一个经验丰富的主程,我可以过去学习。公司也同意了,主程入职了一直在看天堂2的源码,也拉着我看。我觉得天堂2的源码存在很多问题。比如各种在“父类中判断自己是否是某个子类”等。后来2个月过去了,连登陆都还不能登陆。因此制作人就问我,说你觉得他行不行。我也把我对天堂源码的判断说了一下。后来制作人说,要不还是你来当主程吧。那时候我觉得也行吧。反正本来想跟一个有经验的人学东西,结果反而他老来问我各种东西,而且开发进度也很慢。于是我就答应了。然后我又重新开始搭框架。第一周花了时间把网络、副本采用的线程模型搭好了。第二周CTO带着我做了场景。第二周我们已经可以多客户端同步移动、怪物有了简单的AI和普攻了。而且我为了减少和客户端连调的不便,还自己用Swing写了一个图形界面,用于显示服务器当前地图中各个角色的位置。(所以说,假如我大学的时候很功利地觉得学习Java的图形开发性价比不高,那么这时候我肯定没法自己快速完成这个工具

    这个项目我们花了9个月上线。作为公司第一个ARPG项目,其实也很快了。

    项目上线后玩的人挺多,那时候单物理服导量的时候有6000人同时在线。不过这个游戏收费没有调起来。

    2013年,转战手游与创业

    西游降魔篇调了整整8个月都没把付费调起来,甚至越来越差。从最开始每月单服的700W变为几乎没有。此时已经是2013年中,我建议公司可以使用Unity3D(其实12年底已经说过一次,制作人说次年可以申请看看)开发手游,但是公司的战略明显还是在页游,因为公司靠页游已经做到借壳上市,不愿意也觉得没必要去踩手游的坑。公司唯一一个和手游有关的部门其实是把页游项目通过AIR发布为手游。这样出来的手游性能堪忧,而且体验也没有做针对性优化。

    于是在2013年8月,我就辞职自己去创业做手游了。

    自己创业肯定面临的是资金问题,短缺的资金不可能请得了很多牛人,因此我自己又开始做起了Unity3D客户端。把战斗等最核心的东西都自己扛下来。

    我们2策划、2程序、1美术从立项到做完Demo花了大概3个月,然后开始拿着手机去演示DEMO,去找投资。

    那时候的DEMO是用Unity3D做了一个2D游戏。因为我们唯一的美术人员比较擅长画画。Demo可以在这里看到:第一个Unity3D 的Demo

    我们大概找了4个投资人谈,最后确定了投资。

    2014-2015,第一次创业

    就像上面说的,创业资金的短缺,而且那时候Unity3D人员的稀缺,导致我们想找一个牛逼的人员根本不可能,因此我只能自己扛下战斗、Shader等核心的工作。那时候白天写服务器,教新人写代码,一行行代码地边敲边讲,晚上写客户端,最疯狂的几个月基本睡公司,凌晨5、6点入睡,早上9点半起来。

    那时候我用Unity3D,也只是为了为公司省成本,也没想什么太多的东西。结果也正是这段经历,使得我后来成为了另一家百人公司的技术总监。所以我还是挺相信一句话:但行好事,莫问前程!

    最后创业肯定还是失败了,其实还是因为团队成员的不成熟。因此在2015年中的时候,经过了几轮调整和测试后,由于测试结果表现不理想,我们就结束了创业。我并没有对这次创业感到后悔,毕竟那是一次宝贵的经历。而且整个创业过程也都是很充实,很开心。

    2015,西山居和多益网络

    创业结束后我觉得想找个公司积累一下。那时候只面试了珠海西山居和多益网络,西山居剑网3项目组也希望我过去,但我觉得我就是因为懒,最后选择了继续留在广州的多益网络。我学习可以很努力,但是对于公司的选择却经常是很懒。

    2016-2018,第二次创业

    在多益做的时间不长,基本过了试用期,以前第一家公司的制作人就找我创业。并不是因为我个人喜欢创业,其实我只想做一个成功的游戏,能被大家认可的游戏。那时候出去创业,更多是因为这位制作人以前对我不错,也是因为他我才能刚毕业就当上主程,因此这次创业,其实更多的还是报恩。

    这次创业的结果无疑还是失败的。

    2018-2020,360游戏艺术(岂凡网络)技术总监

    2018年4月,由于以前带的一位程序的推荐,我便去了360游戏艺术担任技术总监。这时候刚好30岁,正好和刚毕业实习的时候自己说30岁可能会当上技术总监。实现了自己当初不假思索的一句话。但是回想起来,我这一路并没有为当技术总监去做任何刻意的学习与准备。只是我一路以来学习的都是自己喜欢的,做的都是自己喜欢的,而且该公司正好需要我目前拥有的能力而已。 这也是我最后想和大家分享的,有的人会问怎么才能当主程,怎么才能当总监。我觉得不管当什么职位,重要的就是为公司解决问题,你能解决什么样的问题,你自然就能胜任什么岗位。而有很多舍本逐末的做法,其实看似近路,最后都是无尽的弯路。我觉得做什么都不重要,重要的应该想想,自己能为游戏这个行业做什么,平常应该怎么提升自我去成为行业真正渴求的人。

    2020-至今,昆仑万维技术总监

    承蒙公司信赖,有幸加入并在《仙剑奇侠传移动版》上线前参与了性能优化,解决了一些性能问题。目前主要也在公司做一些架构设计、难题攻克、渲染效果、渲染性能方面的工作。

    今天正好有空,谨以此文,献给所有想为自己所在行业做点贡献的小伙伴!希望一起努力,共勉!

    展开全文
  • 基于Unity的游戏开发(上)

    万人学习 2019-06-24 11:55:37
    本课程是Unity游戏开发的入门课程,课程分为上、下两个部分。上篇主要讲述游戏的基本概念、Unity的开发环境、游戏资源的创建和使用等基础内容。
  • 经典游戏制作教程[zz]

    千次阅读 2005-03-09 22:29:00
    经典游戏制作教程peng1.游戏制作的主要流程-------------------------------------------------------------------------------电脑游戏开发小组中的任何一个人(这个角色通常有策划担任),只要有了一个新的想法 或...

    经典游戏制作教程

    peng


    1.游戏制作的主要流程
    -------------------------------------------------------------------------------

    电脑游戏开发小组中的任何一个人(这个角色通常有策划担任),只要有了一个新的想法 或念头,就孕育着一个新游戏的诞生。在这个创意被充分讨论之后,再加上对其操作过程的趣味性及市场销售的可行性的预测等因素的准确判断,一个完整的策划方案才可能产生。在经过充分的讨论后,策划人员必须将讨论的重点写成文字,也就是提出完整的策划方案,经决策者同意认可后,才能进下一步的工作。这份策划方案就像一部电影的剧本,它必须完整地涵盖整个游戏的故事、流程、内容、方式、游戏画面、角色造型、 场景规划、人工智能、硬件配备、市场评估等。对整个游戏过程的详细描述及实施规划都应 记录在案。 当进入创作过程之后,策划还必须随时和美术设计师和程序设计员保持联系,以免游戏程序的编写失控。策划应能对游戏设置的内容与精神了如指掌,与各个小组及时沟通,并且控制整个游戏制作的进程。

    2.游戏设计基本论
    -------------------------------------------------------------------------------   

       要设计一个游戏,首先你必须要确定几个重要方针,第一是你要设计的游戏是属於那一种类型,第二是时代背景,第三是模式,第四是程式技术,第五是表现手法,第六是市场定位,第七是研发时间,在掌握上述七个方针之後,你就可以再做详细的规划内容及调配资源,那麽何谓是七项方针呢? 笔者以范例来说明之!
    一、类型:
       所谓的类型是指这个游戏所着眼的一个游戏方式,通过这个方式来使玩者达到娱乐的目的,这个游戏方式有专有名词来各别予以命名,兹如下述:

    (1) RGP角色扮演:
       这个类型的游戏以通过故事剧情牵引来使玩家能溶入主角所存在的一个世界,这类型态的游戏多半透过战斗升级系统及人物对话的方式来一步步完成设计者所布下的剧情路线,最具代表的作品有日本史克威尔所设计的 "太空战士系列" 及国内大宇资讯所设计的"仙剑奇侠传",当然还有很多部作品例如"神奇传说"等也是此中的佼佼者。
       在RGP的类型中,在近几年来又分支了几个类似的型态,例如说Blizzard的"暗黑破坏神"Dirblo"被定位为"动作RPG",因其动作成分相当高所至,而"神奇传说"、"超时空英雄传说"则被定位尽"战略RPG",只因战略成分比重较高所以又有别於传统RPG。

    (2) SLG战略:
       谈起战略游戏,大家最耳熟能详的应是日本光荣公司所出品的"三个系列",KOEI的三国志风靡东亚,从一代进化到现阶段的六代皆为玩家们所津津乐道,而所谓的战略游戏则是透过经营→战争→扩大领土三个手段来蠃得游戏最终目标,一般而言动态成分少,最较偏重於花费脑力的游戏,但从WestWood的新型态战略游戏"沙丘魔堡"问世之後,战略游戏也有了重大的分野,一是以KOEI代表的三国志系列被称为回合制战略游戏,一是以WestWood代表的C&C及Blizzard所代表的魔兽争霸被称为即时制战略游戏,和回合制所不同的是,即时制拥有较多可由玩家与电脑互动的机会,比较不花费脑力,所进行的 方式是建设→生产→攻击→歼灭,在业界有句俏皮话是这样说的:「玩回合制游戏像是自己当了个大将军(元首),运筹帷幄决胜千里之外,而玩即时制游戏则像是个士官长(部队指挥官),只能一味的打打杀杀」由此你可以了解到这两个型态的异同的了。

    (3) ACT动作:
       所谓的动作游戏其实就完全靠玩家的反应来做过关的条件,较有名的像DOOM、古墓奇兵、QUAKEⅡ 等,在动作游戏中也分支了相当多的类型,例如快打旋风、铁拳Ⅲ等被定位为格斗型态,主要游戏方式就是二人到四人互相对打一直到分出胜负为止,而DOOM、古墓奇兵则被定位为3D动作冒险游戏,主要目的为杀敌闯关,再来像阿比逃亡记、黑暗之心被定位为横向卷轴游戏,游戏方式就是以攻击跳跃等动作来走过一连串的关卡,表现方式多为2D卷动画面的方式在进行,再如飞龙骑士、极上疯狂大射击则被定为动作射击游戏,游戏方式就是闪躲射击冲过火网进而歼灭守关魔王为止,这些分支型态有共 通特点却又那样的不同,这也是动作游戏吸引人的重要原因。

    (4) PZL益智:
       这类型的游戏以趣味性的思考为游戏的主轴,内容可以包罗万,思维模式也可朝物理性及逻辑性方向着眼,具代表性的是大宇资讯的"台湾十六张麻将"、"大富翁"、"仓库番"等,而棋盘式的思考方式着名的有"决战中国象棋"及光谱资讯的"五子棋大师"等,这些游戏入手容易且不分男女老少皆喜欢的特性,使得益智型态的开发较有市场,成本也较低。

    (5) ADV冒险:
       冒险游戏的内涵多半脱离不了解谜的成分,是的!这类型的游戏让玩家抽丝剖茧的找出设在游戏背後暗藏的谜底,以顺利完成游戏,具代表作有恶灵古堡、异星搜奇、幽魂等,这类型的游戏年龄层较高,比较不适合国内厂商来研发。
       当你在构思一个新的游戏企划时即应预先想的所属意的类型,然後才进行下一步的计划,一般而言国内市场接受度最高的莫过於 RPG角色扮演类型,这也是为何国内厂商会如此的大力研发RPG型态的游戏。

    二、时代背景:
       对於游戏美术来说是一个很重要的方针,因为决定一个时代背景所意味的是资料的搜寻工作方便与否,与美术人员在制定造形时需依据的范例;以国内市场来说多半能接受中国古代时代背景,基本上时代背景有好几种,例如说WestWood的红色警戒架构在公元2000年左右的未来,而魔兽争霸则定在虚幻的欧洲中古世纪中,三国志定位在汉朝末年,星海争霸架构在外太空世界,轩辕剑则定在春秋战国时代等。
    时代背景绝对是企划人员在第一阶段规划整个游戏时已先决定好了,如此美术人员才能放心的去搜集资料。

    三、模式:
       当决定好类型及时代背景之後,再来就开始要去构思游戏中所要呈现的模式,如假设你的背景订在古代中国,而类型是定为即时战略,这时你必去思考出游戏内容的进行方式,可能你的游戏需要生产的因素,这个因素是什麽? 可以是粮食、矿产及木材,也可以是火山能源、石油、太阳能或天然气等,随着你故事情节上的需要而去制定项目,在作战方式上你所设计的模式可能会去考虑到地形因素、天候因素及资源因素,而且会大量运用到各种战术及攻击方法等,因为如此所以同一种类型的游戏虽多,但模式上却各有特色各有偏重的游戏路线,也各自聚集了拥护者,这就是模式设定的一个重要性,切记千万不可去抄袭他人所定的模式,因为这样一来,当你所设计的游戏完成之後,眼尖的玩家们会把你的产品以过时抄袭为由而弃如敝履,这在这剧烈竞争的国内市场而言是无法存活太久的。

    四、程式技术:
       无论你对一个游戏想得多好,架构设计多庞大,如果程式人员本身的技术无法配合的话,那其实一切还是流於空谈,所以在设计一个游戏之前必要先去徵询程式人员的意见,在现在这个环境中不仅程式人员要会Windows98及Wi-ndows NT相关技术,一个完整的系统分析及系统规划是不可缺少的,如此可以避免掉在程式中不可预期的错误出现,而且在一个游戏设计中最好有二个程式人员在运作,一个负责内部程式 (游戏核心引擎) ,一个负责外部程式(介面程式),这样方可发挥完整的战力。

    五、表现手法:
          在这个环节中,企划人员、程式人员、美术人员要做完善的沟通及讨论,一般我们知道大部份的电脑游戏是256 色的系统,在这些游戏中对於色盘的控制有相当严苛的要求,为了达到最好的视觉效果,美术人员通常会向程式人员要求多重色盘的资源,而程式人员则会考量到切换时的状况及记忆体配置是否能完全充份,在系统上的问题确定之後,企划人员会提出呈现效果的建议,例如说爆炸效果的表现方式,由内而外扩张到消失的火焰激烈型或包容大量烟雾的燃烧型,这要由企划人员依故事内容来给予定义,同时以物理性逻辑给予美术人员一个建议,再由美术人员前去绘制。
       还有一个例子,以"C&C之红色警戒"与"AGO Empir世纪帝国"的海岸来说明,在"AGO Empir 世纪帝国"的海岸表现是静止的,海水不会流动,最多只有鱼在海中央跳跃,而"C&C"之红色警戒"的海岸表现手法是会流动的,但海中没有任何的特异之处,这两种表现手法各有各的好处及考量,但以笔者而言仍较偏爱"C&C之红色警戒"。
        游戏内容的表现手法通常伴随着同类型游戏间的相异处而有不同的评价及支持者,而不光是美术效果的表现手法,企划人员构思的游戏玩法及程式人员的程式表现都有密切的关系。

    六、市场定位:
       不论你所设计的游戏构想如何的好,如果你没有去清楚的定位出你的市场走向,那麽到时制作完成的游戏软体可能会面临到销售不佳的窘状,所以在设计游戏之前你得知道你所定位的族群在那里,从下表中你可作一个市场定位的叁考:
    年龄层               教育程度适合的类型内容

    7~12岁 国小动作、益智较多趣味性、教学性
    13~18岁 国中、高中动作、益智、 较多思考性质、图形精美化同 角色扮演、战略时又较多反射
    19岁以上 低知识水平益智、动作较暴力及冒险、趣味性质,操 作简单
    19~30岁 大专、大学以上角色扮演、战略富含多重思维性,可以影射周 、冒险、模拟、 遭事物,解谜及创造性运动 

    七、研发时间:
          这是企划人员在初步规划中的最後一个项目,针对上述的制作方针你必须对美术人员及程式人员安排一个完整的SCHEDULE,从这个SCHEDULE中去研判律发时间,从企划的角度来说,为了不使良好的点子被其他游戏公司抢先推出,同时也要避免推出後模式已落伍,一个游戏的研发最好在一年内,最多不可超过18个月,以成本控制的角度来说比较符合获利标准。
           假设你规划这个游戏需要一年的时间,那麽你就要去区分出美术制作时间 (第一线)及程式制作时(第二线)间的差异,并考量推出DEMO 版及游戏完成的时间,在适当时机打出游戏知名度,为游戏销售上打下一记商机。

    制作流程
       一个游戏的制作如果不能充份控制整个作业程序,那即有delay 的危险,大家都知道游戏软体delay对於销售上的影响会有多大,所以如何尽量避免de-lay是每个游戏设计者应极力去避免的,而要去避免游戏开发作业上delay的情况最重要的是严密控管作业流程及计划表。
       那麽究竟游戏制作流程是一个什麽样的情形呢? 首先企划人员在执行制作的前一个月即要定出企划大纲及搜集可用资源,并经程式人员及美术人员确认後开始执行,我们以一个即时战略的游戏来说明,在制作分期程式人员即投入地图编辑器的撰写,而地图编辑器的逻辑设定要由企划人员先期规划,然後程式人员才根据企划人员的规划而进行程式写作。
       在此同一时期美术人员即开始分工合作,一般一个游戏工作小组会有四位美术人员,他们分别负责造形、人物动作、介面、地图四个部分来制作,但这只粗分法,国内游戏公司较常使用这样的组合,在国外美术人员分为造形、人物动作、介面、地图、片头、过场、後制分镜、场景等九大部份,每个部份皆可能都有二人以上在作业,并有一名监制在执行风格及水准的品质控管,这些人统一由後制人员来与程式人员做交图及配合修图等沟通上的交流,所以说後制作美术人员的成败实关系到整个游戏品质的高低。
    由於程式人员在设计地图编辑器时需要利用到一些图素来做测试,所以地图图素设计人员要先一步绘制出程式人员所需要的图素,
       在程式人员测试通过之後方可进入大量生产的阶段,由於地图编辑器的设计者多半直接负责游戏引擎的制作,所以在初期企划人员便开始着手人工智慧AI的逻辑判断作详细的叙述,以期在程式人员撰写地图编辑器之後能立即作人工智慧AI的撰写,而在此同时负责撰写介面的程式人员亦与负责介面设计的美术人员作密切的配合,开始着手制作各个介面,因为介面不仅在游戏中是一个主司控制整个游戏的操作盘,同时也是一个游戏的外观,一个拥有优良创意的介面是很受 玩家喜欢的。 在测试地图编辑器时,程式人员亦需要利用移动物件(人)来测试地图上的障碍物判断及最短路径搜寻法,所以设计人物动作的美术人员在此时要先去做出一组人物动作供程式人员作测试,待程式人员把地图编辑器制作出来之後,人物动作设计的美术人员则只要不断的做并不断的把图给程式人员即可。

     


    3.游戏设计十诫律
    -------------------------------------------------------------------------------
     

    Travis S. Casey


    1. 编写你所喜爱的游戏
    不要人云亦云。只要你和你的朋友喜爱就可以了。 同样道理,不要编写某个游戏主题仅仅因为它当前流行而已。编写你所喜欢的题材, 这样才能激发你的热情。

    2. 经验是最好的老师
    学习游戏编程最好的方法就是阅读大量的游戏程序。玩和分析这些游戏,然后设计 你自己的游戏或扩展游戏。我最主要的经验都是角色扮演类游戏,我的许多游戏范 例也来自它们,但思路却适用于所有类型的游戏。 我阅读过大量的RPG类游戏,粗略算算大约有七十多个。其中大部份我都玩过,精 通四十多个。不但玩和精通这些游戏,我还分析它们。是什么使得这些游戏好或者 不好?我如何修改它?哪些部份表现的出色?哪些部份不尽人意?为什么? 玩和分析过其它游戏后,我把这些知识用于我自己的游戏。比如在“超级英雄”类 游戏中,“斗士”和“英雄”在使用了“指数特性的换算法”取得较好的效果。如 果我想设计“超级英雄”类游戏时,我就知道“指数换算法”很可取。这样的分析 能给你许多被验证过的思想用于你的工作中。

    3. 测试、测试、再测试
    测试你的游戏,尽可能多次的玩。最好当你不在场的情况下,让别人来玩,过后再 告诉他们。(让别人当你不在的时候玩游戏称为:“盲测”) 还有,推敲你的规则。考虑假设情况,解决概率复杂性。比如,如果你正在设计一 个RPG,试着找出平均人们用弓箭从一米、五米、十米、五十米和百米范围内射中 人形大小目标的百分机率。对于二战游戏,检测你的监视器和解决一个小步兵摧毁 一辆坦克的机率。反复计算在不同的条件下,如:不同的地形、夜间等等。这将有 助于你找到在数学中出错的地方或建立了一个不好的假设。

    4.学习背景知识
    如果你想编一个中世纪的神奇游戏,就要去读中世纪的文学和历史。读有关魔法的 书及现有的中世纪传奇游戏。对其它类型的游戏也是如此,如果你想做一个越南战 争的游戏,就应去读有关战争的正史及野史,特别是战略、战术的分析。 所有的背景知识可以用于几种途径:首先,能帮助你创造出逼真的角色。另外它能 减少你在术语及背景知识方面,出现重大错误的可能性。当然,资料应该本身就很 有趣。如果对于所要学的都不感兴趣,那为什么还要编写这方面的游戏呢?

    5. 正规教育
    选一门介绍概率和统计的课。试着读一些游戏方面的数学理论。你可能觉得那没什 么用,但它能帮助透视算法的掌握。斟酌你的英语(或其它你发表游戏所用的语言) 当游戏描写得好的时侯,就更容易学,至少不能有大量的语法错误。 如果你想制作电脑游戏而没上过任何编程课时,不妨学几门。你可能学不到什么编 程序的具体东西,但一门好的课程可以教会你如何组织程序使之更容易维护和发现 错误。 建立一个“参考文献库”,它是一系列和你所制作游戏工程相关的游戏、书籍资料。 当你清晨三点突发灵感而图书馆却已关门的时侯,它将是非常有用的。

    6. 抽取些时间
    一个游戏就像孩子,当它刚出生时,它的父母总认为它是完美的。从你的游戏中抽 出些时间去得到一些新的观点,避免都耗在上面。一遍遍的重复这一过程。

    7. 保留记录
    确定你有一份以上的游戏拷贝。如果你是在电脑上输入的,就各保持一份硬盘和软 盘拷贝,另外再打印出一份清楚的最近版本(如每月打印一份,如果你干得快的话每 星期打印一份)。你不会觉得拷贝太多,因为你的好朋友们会来向你借或者想拥有拷 贝。而且这些拷贝能够减少你因为硬盘瘫痪或丢失笔记本等原因造成的丢失机会。 同样道理,保留旧版本的拷贝是有好处的。如果你在游戏测试时发现新的办法还不 如旧的好,而你却已将旧版本的扔掉了,这该怎么办?至少保留一份最后版本之前 的拷贝,同你当前版本的拷贝放在一起。

    8. 其它注意事项
    优秀的规划和书写是好的,但精美的视觉化说明对你的销售大有益处。如果你要自 己动手,就学一些桌面出版,或找一些现成的插图(比如:剪辑艺术或政府出版物) 或找别人帮你画些插图。 找个从事印刷业的人,和他探讨一些尽可能廉价的方法。低价格可以有助于销售, 低成本则有利于你的收益。

    9. 记住这只是个游戏
    不要因为制作游戏而忽略你的现实生活。如果有人不喜欢你的游戏,别介意。不用 担心别人窃取你的创意。记住第一条诫律,从你的所做中得到乐趣就行了。

    10.没有第十条了 :-)

    另外,这里有一些来自汤姆(“棱镜游戏”的主持者)的额外忠告,感谢汤姆!:
    1.不断的创新是非常好的。如果你游戏中的所有东西都令人似曾相识,就好像是 偷来的。如果所有东西都与众不同又会让人感到陌生。常见题材单一独到的构思是 好的,但会使得你的游戏看来像个“变体”,而两个熟悉题材精明的创意则会使游 戏有新鲜感同时容易上手。因此不要试图彻底从新发明某样东西,而应把当前所拥 有的主意清晰化、简洁化的用于扩展关键观念的创新和趣味方面上。
    2. 修正和雕琢你的游戏创意。测试不仅仅为了清除游戏和规则介绍中的错误,而 且就像一个讨论会,对照他们已经取得的东西,游戏设计师能够发现什么是真正所 要表达的。如果你将测试留到最后,这一发现将对你没有什么好处。如果你进行早 期的测试和经常从眼前试着发现这一游戏真正要表达的,你就能常常很大的改进这 一游戏。 “ Alpha”测试就像在问:“是否真有这个游戏?”“我得到它了吗?”“ Beta ” 测试看来在问:“是否用了最好的方法达到这一效果?”,“这是游戏的精炼吗? 或者它是否能被简化或删除?”“是否所有主要的游戏系统协同工作,给予了我所 期待的游戏体验?”“ Gamma ”测试又像在问“如何才能改善游戏的收支平衡 和介绍呢?”许多设计师停留在Alpha(生产一个吸引人但却是次品的游戏)之后或 者从Alpha直接到Gamma,跳过了Beta(生产一个好的但还不够完美的游戏)。 通常有必要靠你的亲密朋友/游戏小组及早的进行足够的批评性分析,帮助你发现如 何才能改进一个已经相当不错的游戏。

    我的一些其它建议:

    在我制作游戏过程中,从没有清晰明显的测试“阶段”。我倾向于每个阶段都做一 点。我修改一些系统,抛弃或替换一部分,改善其它的收支平衡和介绍,差不多是 在同时做的。这些部分来自于我所从事的主要游戏类型的设计-宇宙类RPG,你必须 在一个时间内干一个部分的事情。 关键在于去寻求达到你最好的作品。用不同的方法尝试,直到找到适合你的方法, 然后用它钻研下去。

    4.游戏的剧情
    -------------------------------------------------------------------------------


    游戏剧情的重要是不言而喻的,特别是RPG游戏,相信广大玩家对"仙剑奇侠传" 熟得不能再熟了,这个游戏以剧情取胜(他的音乐也相当不错),各大媒体对他的 评价也都是以剧情为主,这个我就不多说了.
    我也曾看过许多文章提到剧情的重要,这些文章说的相当好,相当有价值,但基 本上讲述的是剧情的要点及注意事项.而我将从另一个方面去分析游戏的剧情.
    游戏的剧情是游戏的灵魂(当然除少数不需要剧情的游戏,如体育类,赛车等), 游戏通过各种各样的方法让玩家融入到设定的剧情上以打动玩家,但如果游戏 的剧情不吸引人,那么无论游戏的表现手法有多好也不能达到目的,但是怎样 的剧情才吸引人呢.
    事实上中国与外国玩家有着很大的文化差异,这一点可以从各地所出产的游戏 上看得出来,欧美的游戏大多重视人物与场景的直实性,看上去就像电影,而东 方的游戏普遍追求漫画式的效果.但这两种风格哪种适合我们呢?答案是两种 都适合.不要忘记我们的玩家基本上是青年一代,对新事物的接受是相当快的, 对欧美的游戏我们的玩家接受得很快,从这可以看出国外的游戏制作是相当出 色的,就拿我自己举个例子,前两天我得到一款"生化危机2"的游戏,游戏开始 的动画可以说是扣人心弦,并且很好的衬托出了主题.而第二种风格的代表作 品就是"仙剑"了.
    游戏所要表现的内容必须能够被玩家接受,而且还要有创新,这样的剧情才说 得过去.现在我们有一个很好的观察点,那就是电影,外国的制作精良的大片 挤进中国后给我们的冲击多么大,而中国传统题材的作品也给我们留下难忘 的印象.
    我们不得不承认,在技术上我们与国外的游戏制作公司相比还差了一截,这 使得许多很好的题材我们不敢用,因为以现有的技术还不能很好的将他表现 出来,如果勉强还可能会起反作用(这是有例子的).
    在这里我只是起一个开头的作用,什么样的剧情适合大家也不是一下能说清 楚,希望广大游戏爱好者能积极讨论这个问题,这也是我们中国游戏业现阶断 的一个重要的有待解决的问题.

    5.角色扮演游戏的升级系统研究
    -------------------------------------------------------------------------------


    在一般的角色扮演游戏中,人物的成长是一件相当重要的事,无论是角色扮演游戏或是目前热门的策略型角色
    扮演游戏(简称RSLG),这些升级系统都是游戏的一个重要部份。不过在一般的角色扮演游戏中,人物的升级
    以及成长却有着很多种的处理方式。在本文中,笔者将为各位介绍各种角色扮演游戏中常用的升级方式,并且
    分析各种作法的优缺点。

    在一般的角色扮演游戏中,最常用的升级方式就是乱数式的成长方式。在这种模式中,当一名角色获得升级的
    时候,程式会使用乱数来决定升级的各项指数,也就是说所有的升级数值都不是在控制中,而是依据一个乱数
    表来决定提升的数值。这种升级的方式是如何处理的呢?

    当人物到达升级的标准时,就会进入处理升级的副程式中,在这个副程式中程式会依设计者所定出的一个乱数
    范围,来计算出这名角色所得到的升级指数,然後将这个数值加到需要增加的属性上。

    在这种乱数决定升级的情况下,玩者所能够获得的升级数值,完全是由设计者订定的范围中求出,无论是升级
    的上限或是下限都是在这个范围内,绝对不会有意外的情况发生,就算是设计者如何提高上限与下限,都不会
    改变这些。这种作法虽然可以让设计者很轻松的订出升级的上下限,但是却不能控制升级时的不利因素,那就
    是乱数的成份实在是太高了。若是有一名角色因为运气不好一直只有获得下限的升级数值,那麽它可能会比一
    个一次就获得上限升级数值的角色要弱。举例来说,当这个乱数的范围是一到五的时候,若是角色甲和角色乙
    分别获得上限和下限的升级数值,那麽会发生以下的状况:

    ┏ ┳ ┳ ┓
    角色甲 角色乙
    ┣ ╋ ╋ ┫
    LV1 10 10
    LV2 15 11
    LV3 20 12
    LV4 25 13
    LV5 30 14
    LV6 35 15
    ┗ ┻ ┻ ┛

    各位看看上表,是不是可以看到角色甲在第二级时的数值就已经和角色乙第六级的数值是相同了。由於乱数式
    的升级方式会有这种不公平的情况发生,因此常会使得玩者的努力需要有一些运气的成份在里面;若是运气不
    好,可能原本的努力都无法发挥所要的功效。

    由於乱数式的升级方式有这样的缺点,因此有两种不同的改进办法,首先就是百分比制的升级方式。在这一种
    办法里,角色在升级的时候还是使用乱数来进行,不过在每一个数字的出现比例上却做了一些调整。例如同样
    的升级的范围还是从一到五,但是每一个数字的出现比例调整如下:

    ┏ ┳ ┓
    数值 出现比例
    ┣ ╋ ┫
    1 10%
    2 20%
    3 40%
    4 20%
    5 10%
    ┗ ┻ ┛

    各位从上表中可以看到,在这一种处理方式上,每一个数字出现的比例做了一些调整。原本的乱数式中,每一
    个数字的出现比例都是相同的,就以上面的例子来说,每个数字出现比例是百分之二时,因此上限和下限的数
    值比较容易出现,发生不幸的情况比较多;但是在这样子调整後,上限和下限的数值出现的机会就减低了不少
    ,会发生不幸的情况就降低了。

    虽然这样的作法可以降低不幸的发生机会,但是还是无法完全的克服所有的状况,因为还是有可能会发生相同
    的状况,使得玩者陷入属性不佳的情况中。因此另外一种改良的方式~修正值升级方式就这麽出现了。

    其实修正值的升级方式和原本的乱数处理法在计算的时候是完全相同的,只不过是它在升级到一个程度的时候
    ,会来做一次计算并且取出一个修正值,以免玩者因为运气不好无法达到升级的功效。

    在这种作法上,上半部和乱数式的做法完全相同,唯一的不同是下半部的副程式。而这个副程式的作用就是在
    帮一些升级时运气比较不好的玩者取得一点修正值。

    我们就以前面所说的升级的数值是从一到五来做个例子,让玩者每升五级时就可以取得一点修正值。因此若是
    一名角色在五次升级中都只有获得一点的升级值,那麽目前它的数值就是:

    10 + 1 + 1 + 1 + 1 + 1 = 15

    不过在我们的升级表内中等的数值是三,因此当角色升了五级之後,应该可以获得以下的数值:

    10 + 3 + 3 + 3 + 3 + 3 = 25

    这麽说来这名角色因为前五级的升级运气不好,因此少获得了十点的升级指数,所以我们就在这一次把这个缺
    少的数值以修正值的方式补足,从修正值的计算式中可以得出:

    25 - 15 = 10

    就将这个数值加到角色的属性中,让角色不会因为运气太差而有不利的情况。若是角色在升级中都获得比较高
    的数值,那麽修正值就是负的,也就表示不需要有修正值的存在了。

    这种作法完全是为了不让玩者因为升级时运气不好使得属性太低,因此只能算是修正部份数值的作法,虽然不
    能完全解决乱数式的问题,但是可以将不利的因素降低,因此在某些游戏里的确有采用这样的作法。

    除了乱数式的作法外,还有一种是表列式的升级方式。在这种升级方式中,每一名角色的升级数值都是设计者
    已经订好的,完全不会有任何的变动。它的好处是设计者可以完全掌控所有的升级状况,但是相对的这样子的
    表格需要占掉较多的程式空间。

    举例来说,某个游戏若是采用这种升级方式,那麽在它的记忆体中就需要有这样子的升级表格。若是游戏中有
    七项属性会获得升级,等级共有一百级的变化,那麽基本上它就需要有七百个不同的数值表放在程式中。若是
    一个数值用了两个位元(BYTE),那麽就需要用到1K左右的记忆体。如果说游戏中有四名角色,它们升级情况
    又都是不同,那麽占掉的记忆体就将近有5K了。这麽算起来各位可能觉得不会很多,但是当这种资料越来越多
    的时候,记忆体的消耗也就越来越多,使得程式的空间也越来越小了。

    由於表列式的作法会使得升级的情况比较单调,因此大多数的游戏并不愿意采用这种作法,再加上这一类的作
    法对於记忆体的占用空间也比较高,因此如果不是必要,大多数都不会用这种作法。

    除了以上这些作法之外,还有一种就是指数型的升级方式。这种作法其实就是表列式的改良,因为它将升级的
    表格简化成一个叁数,在升级的时候就依这个叁数来计算能够获得的升级值。现在我就举一个例子来示范。目
    前有一名角色的属性以及升级指数如下:

    o 生命:10 生命指数:10
    o 法力:10 法力指数:10
    o 力量: 3 力量指数: 2
    o 智慧: 2 智慧指数: 2
    o 反应: 2 反应指数: 2
    o 体能: 4 体能指数: 2
    o 运气: 1 运气指数: 3

    那麽当他获得升级的时候,程式就会依这个升级指数来计算升到下一级时的各项属性值。因此在升了一级之後
    ,各项属性的数值就是以下的数字:

    o 生命:20
    o 法力:20
    o 力量: 5
    o 智慧: 4
    o 反应: 4
    o 体能: 6
    o 运气: 4

    用这种作法,在程式内不需要复杂的升级属性表,只需要几个简单的叁数就可以,若是能将各项叁数之间的关
    系加以变化,并作一些运算,那麽可以使升级时的变化更多。举例来说生命的增加和体能有关,或是法力的增
    加和智慧有关,那麽在计算起来时会有比较多的变化,使得整个升级的表现不会太单纯。

    以上这些作法大部份的变化程度都不会很多,没有办法表现出一个人的成长情况。就像我们有时候会形容一个
    人「大器晚成」或是说他「小时了了」这样子的情况都不能表现出来。因此後来又有一种成长曲线的升级方式
    。在这种升级方式中,我们首先要订出几种不同的升级情况。像是:

    A. 平衡成长
    B. 大器晚成
    C. 小时了了

    要达成这种效果,我们需要将升级的总等级数分成几个阶段。我们以一个可以升到一百级的游戏来说,将每十
    级分成一个区块,就可以订出这三种成长情况各要给它多少的数值。

    其实这种曲线式的升级方式,在处理上和指数式的作法差不多,只不过指数式的作法一个人物每一种属性只会
    有一个数值,这个数值是不会改变的。但是在曲线式的作法中,会依不同阶段有不同的升级指数,才可以造出
    不同的成长情况。我们就以一名「大器晚成」的角色来说,这一类的角色在开始成长的比较慢,但是当人物成
    长到一个阶段後,成长的速度就会加快,因此我们可能在前两个阶段只给他们一点的升级指数,後面几个阶段
    再给他们较高的升级指数,使这名角色会在游戏後期升得比较快。

    反过来说,若是要设计一名「小时了了」的角色,那麽我们在初期可以给他较高的升级指数,但是到了後期就
    要给它较低的指数,如此一来就可以表现出这样的情况。

    事实上,在游乐器中的「光明与黑暗续战篇」就曾经用过这一种作法,使得游戏中的每个角色都有各自不同的
    特色。特别是有些属於大器晚成的角色,曾经因为初期成长的速度太慢而被玩者抛弃,但是後来知道这名角色
    的特性之後,再回过头来训练的这种情况,正是这种曲线式升级的特色。这种作法使得角色除了单纯的数字属
    性之外,还增加了一些隐藏的特性,会让游戏更有味道。

    如果以笔者个人的喜好来说,我是比较欣赏曲线式的升级方式,因为这种方式比较可以隐藏角色的特色,也不
    会因为数字的变化太过单调而让玩者觉得过死板。比起乱数式的不定性和升级指数式的单纯来说,这一种作法
    可以说是兼具了两种的特色,同时还有全新的表现,是一种不错的升级方式。只惜目前国内的游戏很少使用这
    种作法,大多还是采用乱数式的作法,对於国内玩游戏的玩者来说,实在是有些可惜,因为大家没有办法体会
    到这种作法的优点。

    6.游戏中的智能系统处理
    -------------------------------------------------------------------------------

    游戏中的智能对手
     AI在游戏中最普通的形式是创建计算机控制的对手。因为大多数游戏是单人游戏,所以要设计游戏者在游戏中必须战胜对手。为了达到这个目的,你可以使用某种类似A*搜索的简单AI算法,以帮助对手穿过迷宫向游戏者发起进行。你也可以使用简单的算法预测游戏者的反应。
     但是,记住没有必要创建世界上最强大的对手。你的对手只要能给游戏者提供足够的挑战性就可以了。还有,要注意游戏的内容。例如:一个战棋式RPG游戏中策略占的是主要地位;而在纯RPG中故事情节和角色开发就更重要一些。千万不要因为计算机对手太强大而让游戏者们陷入失败的泥沼。

    游戏中的非智能对手
     通常,在游戏开发中AI技术是与计算机对手紧紧联系在一起的。这是因为早期的大部分类似角棋的游戏是一对一的。但是,任何好的探险游戏或RPG 游戏开发者都知道,AI同样可以用于非对手角色。例如:如果你正在建立一个RPG游戏并且你想让你的世界活起来,这就是说,让城市里的人以智能的方式活动,那么你可以使用某种算法确定在一天中的某个时候,角色应该在那里。你可以使用类似于AI算法如A*来辅助你将一个对象从一处移动到另一处并绕过障碍物。

    游戏中的智能系统
    游戏中的AI在本质上是最具有模仿性的,但它们基本上是依赖一些AI要素。 你可以将所有具有决策功能的对象在一个游戏中融合为一个整体。例如:在一个战争游戏中,你的各个部分可以依据各自所处的具体环境来作出各自的AI决策。
      使用这种方法,你得把精力集中于怎样在各个独立的决策个体之间建立联系,以及这些联系怎样才能使游戏成为融会贯通的整体。是用一个高级决策影 响其它决策,还是各个决策个体之间平等地互相影响呢?举个战争游戏来说, 你有十辆坦克,它们的思维模式基本相同。所以它们都决定去攻击敌人阵营中 HP值最低的一辆坦克。但是这时其中一辆坦克说:“这个敌人归我了!”那么 剩下的九辆坦克就应该依据这条信息各自调整下一步的攻击目标。当你建立智能个体时,要考虑在一个智能系统整体环境下,它应该如何行动。


    7.电脑游戏中的人工智能制作
    -------------------------------------------------------------------------------


     电脑游戏随着硬件执行效率与显示解析度等大幅提升,以往很多不可能或非常难以实现的电脑游戏如此都得以顺利完成。虽然电脑游戏的呈现是那么地多样化,然而却与我们今日所要探讨的主题,人工智能几乎都有着密不可分的关系。
     在角色扮演游戏中,程序员与企划人员需要精确地在电脑上将一个个所谓的“怪物”在战门过程中栩栩如生地制作出来;所以半兽人受了重伤懂得逃跑,法师懂得施展攻性法术。
     目前能让人立刻想到与人工智能有密切关系的游戏有两种:
    一是所谓的战棋/策略模拟游戏,二则是棋弈游戏。人工智能的比重与深浅度,在不同的游戏类型中各有不一。有的电脑游戏非标榜着高人工智能不可,不然没有人买;有的则是几乎渺茫到让玩家无法感觉有任何人工智能的存在。            

     导向式思考

     AI最容易制作的的方式,同时也是早期游戏AI发展的主要方向就是规则导向或称之为假设导向。在一些比较简单的电脑游戏中,程序员可以好不困难地将游戏中的规则与设定转化成一条条的规则,然后将它们写成电脑程序。让我们以角色扮演游戏为例。决大多数的企画在设定所谓电脑怪物时,所设定的属性通常有以下几种:

      生命值 攻击力 防御力 法力  属性

     最后一个“属性”是我在设定时喜欢增加的项目之一。透过这项属性的设定,我可以把怪物设定成“贪生怕死的”,也可以把战士设定为“视死如归”。以目前我们所掌握的资料,在战门系统中的大纲如是诞生了:                          

    规则一

    if (生命值< 10) // 边临死亡了吗 
    {  if (属性== 贪生怕死)               
       结果 = 试图逃跑               
      if (有任何恢复生命值的物品或法术可用)      
       结果 = 使用或施展相关物品或法术       
    }                                                 

    规则二
     
    if (可施攻击性法术 && 有足够法力)
    {                        
       结果 = 施展攻攻击性法术             
    }                        

     由以上一连串的“如果--就--”规则设定,建立了最基本的AI。说这样的制方式只能建立基本AI其实并不当然正确。只要建立足够及精确的规则,这样的方式仍然有一定水准的表现。
     规则导向的最大优点就是易学易用。在没有深奥的理论概念的前提下,仍有广大的使用群。所以很多老道的玩家常常没两下就摸清楚敌人的攻击策略,移动方式等等。

     推论式思考

     相信曾经接触过电脑语言课程,或是自习过相关书籍的朋友们,都曾曾经听过一个著名的程序,那就是井字游戏。用井字游戏作为讨论AI的入门教材,我个人觉得是最适当的例子。或许有人还不知道井字游戏怎么玩。只要任何一方在三乘三的方格中先先成一线便胜利了。我们在前面谈过的规则导向,在这里也可以派得上用场。

     if任何一线已有我方两子&&另外一格仍空//我方即将成一线吗
      结果 = 该空格                     
     if任何一线已有敌方两子&&另外一格仍空//防止敌方作成一线 
      结果 = 该空格                     
     if任何一线已有我方一子&&另外两格仍空//作成两子    
      结果 = 该空格

     有一次我在某本电脑书上,同样地也看到某些以井字游戏为介绍的范例。不同的是,我几乎看不到任何规则导向的影子。但在仔细分析该程序码后,我得到了极大的启发,原来AI是可以不用这么多规则来制作的。它用的方法正是在电脑AI课程中重要的概念:极大极小法。我在这里只说明这法则的概念。继续以井字游戏为例,电脑先在某处下子,接着会以假设的方式,替对方下子,当然,必须假设对方下的是最佳位置,否则一切则毫无意义。在假设对方下子的过程中,自然又需要假设我方的下一步回应,如此一来一往,直到下完整局游戏为止。 底下是节录书中的程序片段:                       
     
    bestMove(int p, int*v)
    {   int i; 
       int lastTie;                  
       int lastMove;                 
       int subV;                                   
    /*First, check for a tie*/            
        if (isTie()) {              
         *v=0;               
         return(0);              
       };
    /*If not a tie, try each potential move*/
     for (*v=-1, lastTie=lastMove=-1,i=0;i<9;i++)
      {
       /*If this isn't a possible, skip it*/          
       if (board[i]!=0) continue;
       /* Make the move. */
        lastMove=i; 
        board[i]=p;                             
       /* Did it win? */                       
        if (hasWon(p)) *v=1;                     
        else{                             
       /*If not, find out how good the other side can do*/
         bestMove(-p,&subV);                      
       /* If they can only lose, this is still a win.*/
          if (subV==-1) *v=1;       
       /* Or, if it's a tie, remember it. */         
           else if (subV==0){                 
              *v=0;       
              lastTie=i; 
              };                          
           };                              
    /* Take back the move. */           
               board[i]=0;          
    /*If we found a win, return immediately
         (can't do any better than that)*/     
      if (*v==1) return(i);                     
    /*If we didn't find any wins, return a tie move.*/         
      if (*v==0) return(lastTie);                      
    /*If there weren't even any ties, return a loosing move.*/     
      else return(lastMove); 
    };    

     国外的一些论坛曾举行过256字节的游戏设计比赛。作品非常多,其中有一件作品正巧也是井字游戏。作者用区区两百多行就写了与上述程序演算方式完全相同的作品,可见功力确实了的。另外,我也很希望类似的活动能在国内推展起来。对了,在这样的比赛条件限制下,除了汇编语言外,几乎没有其它的选择了。       .386c                        
      code      segment byte public use16      
              assume cs:code, ds:code      
                                
              org   100h            
                                
      tictac     proc  far             
                                
      start:                       
              push  cs             
              pop   ds             
              mov   ax,0B800h     ; 清除屏幕
              mov   es,ax       ;    
              xor   di,di       ;    
              mov   cx,7D0h      ;    
              mov   ax,0F20h      ;    
              rep   stosw       ;    
              xor   cx,cx       ;    
              mov   dl,5            
      loc_1:                       
              call  printBoard         
      loc_2:                       
              mov   ah,8        ; 等待按键
              int   21h             
                                
              movzx  bx,al            

              sub   bl,31h       ; 如果不是1..9
              jc   loc_2       ; 则重新输入 
              cmp   bl,8              
              ja   loc_2              
              cmp   data_1[bx],al          
              jne   loc_2              
              mov   byte ptr data_1[bx],'x'     
              dec   dl               
              jz   short loc_3           
              mov   al,'o'             
              call  bestMove            
              mov   [si],al             
              call  isWin   ; 判断是否已取得胜利 
              jnc   loc_1              
      loc_3:                          
              call  printBoard           
              mov   ax,4C00h            
              int   21h               
                                  
      data_1     db   '12'              
      data_2     db   '3456789'            
      data_3     db   0                
                                  
      tictac     endp                  
                                  
                                  
      printBoard   proc  near              
              mov   si,offset data_1        
              mov   di,548h             
              mov   cl,3              
                                  
      locloop_4:                       
              movsb                  
              add   di,5              
              movsb                  
              add   di,5              
              movsb                  
              add   di,133h             
              loop  locloop_4            
                                  
              retn                  
      printBoard   endp                  
                                  
                                  
      isWin      proc  near              
              mov   bx,1              
              mov   bp,3              
              call  sub_3    ; 检查横向是否完成 
              inc   bx               
              inc   bx               
              dec   bp               
              dec   bp               
              call  sub_3    ; 检查纵向是否完成 
              call  sub_4    ; 检查斜向是否完成
              clc
              retn                  
      isWin      endp                  
                                  
      loc_5:                         
              stc                   
              retn                  
                                                                
      sub_3      proc  near              
              mov   ah,3              
              mov   si,offset data_1        
      loc_6:                         
              mov   di,si              
              call  sub_5              
              add   si,bp             
              dec   ah               
              jnz   loc_6              
              retn                  
      sub_3      endp                  
                                 
      sub_4      proc  near              
              mov   di,offset data_1       
              inc   bx              
              call  sub_5             
              mov   di,offset data_2        
              dec   bx               
              dec   bx               
              call  sub_5              
              retn                  
      sub_4      endp                  
                                  
                                  
      sub_5      proc  near              
              mov   cl,3              
                                  
      locloop_7:                       
              cmp   [di],al             
              jne   short loc_ret_8         
              add   di,bx              
              loop  locloop_7            
                                  
              add   sp,4              
              jmp   short loc_5           
                                  
      loc_ret_8:                       
              retn                      
      sub_5      endp                      
                                      
      bestMove    proc  near                  
              mov   bx,31FEh                
              mov   cl,9                  
              mov   di,offset data_1            
                                      
      locloop_9:                           
              cmp   [di],bh     ; #empty?        
              jne   short loc_12  ; #no, skip       
              mov   [di],al                 
              pusha                      
              call  isWin      ; #CY: Win       
              popa          ;            
              jnc   short loc_10  ;            
              mov   bl,1                  
              mov   si,di                  
              mov   [di],bh                 
              retn                      
      loc_10:                             
              pusha                      
              xor   al,17h ; good! toggle 'o' / 'x'
              call  bestMove                
              mov   data_3,bl                
              popa                      
              mov   ah,data_3                
              neg   ah                   
              cmp   ah,bl                  
              jle   short loc_11              
              mov   bl,ah                  
              mov   si,di                  
      loc_11:                             
              mov   [di],bh                 
      loc_12:                             
              inc   bh                   
              inc   di                   
              loop  locloop_9                
                                      
              cmp   bl,0FEh                 
              jne   short loc_ret_13            
              xor   bl,bl                  
                                      
      loc_ret_13:                           
              retn                      
      bestMove    endp                      
      code      ends

              end   start


    7.游戏引擎 小谢
    -------------------------------------------------------------------------------

     

    早想写一点游戏设计的文章与大家交流,一是经验的问题,二是公司正在紧张的游戏制作期,实 在抽不出多少时间,一直没有动手,今天忽然头脑发热,写了一段,以后准备陆续写一些游戏创意,策 划,制作,流程管理,和制作工具等方面的文章供大家参考.

    我们的游戏设计经验主要是冒险游戏和角色扮演游戏,但我们设计游戏工具时尽量适应其余题 材,不过是否可行未经检验. 写这篇文章的意图一是想为游戏界做点事,抛砖引玉吧,另外是公司正在寻找志同道合的战友, 我写一点文章交一交朋友,许多东西仅仅是我们的经验,不一定很好.参考而已吧

    游戏设计工具包括游戏编辑工具和游戏引擎两块;
    编辑工具:交互编辑游戏数据,生成游戏引擎所需的数据文件,包括以下几个功能块: 图像编辑,场景编辑,物品编辑,动画编辑,人物编辑,事件编辑等,具体介绍在以后的 文章介绍.

    先从游戏引擎说起.
    语言:VC5.0
    操作系统:WIN95
    图像引擎:DIRECT X 5.0
    支持游戏风格:各种类型和视角以及多层次的冒险游戏和角色扮演游戏

    整个游戏引擎包括以下功能块:

    资源管理:图像库CIMGLIB,声音库CSOUNDLIB,通过编辑工具形成的资源文件来定义,每种资源 包括定义管理和一些操作接口.图像库图"像包括多种格式(BMP,GIF.AVI,FLC等)以及他形成的内存 格式定义,子图定义(每一张图片包括许多小图,需定义它的小图位置,当然可以自动生成),游戏需 要的特殊定义,比如行走,身体性质,中心定位点,触发区,可以根据自己的要求扩充各种性质定义. 图像最好允许图像组合定义.声音库包括WAV和 MID的定义和再现. 资源由IMGLIB.DAT和 SOUNGIMG.DAT定义,调试版本中最好不要将资源打包,而是指向正常的 文件名,发行版本中再打包,这样修改和不同工作人员协调容易一些,否则最好有一个自己的资源 管理器.我们在调试版本中数据文件采用文本描述格式.许多数据可以手工编写而不需要专门的 编辑工具.
    资源管理对象还包括内存管理,比如设置时间阀释放长期不用的资源.

    声音管理:CSOUND,包括Creat(),Sound(char *fileName...),SetPos(),等,DirectSound有一 些函数,我们要做的是封装简化,减少对外的接口.
    窗口系统:接管标准窗口系统,一个完善的游戏引擎最好有一个自己的界面系统,至于简单还是 复杂根据自己情况具体分析,一个具备基本功能的界面系统1000行程序就可以对付下来,需要窗口 系统的原因是一般的图像引擎不支持标准窗口,二是可以便于移植到别的操作系统.在我们的游戏 引擎中,游戏只是窗口系统的一种特殊控件(CWINGMCTR),因此可以实现多窗口游戏等特殊要求.
    CWINGMCTR是一种特殊控件,通过他来控制游戏.包括控制和显示.

    图像引擎:所使用的图像引擎的管理,我们使用的是DirectX,包括Creat(),CreatSurface(), OutToScr(),Bilt()等对外接口;他不是游戏的重点,我们尽量将图像引擎细节封装起来.

    图像管理:这是处理图像的中心,一般处理游戏显示喜欢以某种图像引擎为中心来设计,我觉得 最好设计自己的对象来封装别人的图像引擎,这样不会因某引擎而受限制,移植也比较容易,我们虽 然使用的DIRECT X ,但实际上对外的接口是一种CPICPAGE的界面,他不但包括DIRECT X 的surface, 也包括标准的位图,AVI界面,GIF动画界面,以及自定义的格式,他将各种类型的图像统一起来,对外 使用统一操作,比如DRAWTEXT,BILT,LINE等标准图形图像操作,以及扩充的ALPHA通道,透明度等操 作.为了减少内存的需求,特别是16M高彩,不要将全部图像使用DIRECT X的表面,对一些刷新不多的 图像,比如背景,可以使用标准256色位图,甚至一种GIF表面,需要时再解压,我们还使用一种单色位 图用来从背景中抠图,比如一所场景中一棵巨大的树,只要不是动画,我们可以用单色抠图的形式从 背景中扣除来作为另外一层,这样我们可以大大降低图像的内存需求.因此采用全部手绘(或3D场景), 而不是小图拼贴的场景成为可能.通过各种手段可以节约60%的内存需求.
    CPICPAGE可以通过TimeTrace()以及多线程来改写内容,比如AVI的改变.

    游戏控制:这部分包括显示和控制,由CGAME->CGAMEPAGE->CGMOBJ对象组成,CGAME是总控对象, 包括许多CGAMEPAGE游戏页,CGAMEPAGE是一个具有连续场景的游戏片断,有点类似于游戏的一关, CGAMEPAGE由一系列CGMOBJ组成,CGMOBJ是游戏的基本对象,由他继承出地图,物体,物品,人物,武器, 动画,触发器,多媒体按钮等特殊

    游戏对象,这是一个根据游戏要求不断丰富和改写的部分,对外的 接口是:SendDraw(),Draw(),TimeTrace(),AcceptMsg(),SendNetMsg(),AcceptNetMsg()等,他是通 过CWINGMCTR来调用,每种对象有许多控制参数,对象之间允许通讯,以及有自己的生长死亡发展的 控制,尽量做到对象与外界减少直接接口,通过消息实现交流.

    对象分为两类:景色对象和活动对象,
    景色对象定义了组成场景的元素,包括背景和前景两层,可以是由整个图片组成或由RPG常用的 图片拼贴法的组成,它的特点只作为背景或前景,活动物是在他们的之间活动,一般定义后不做改变, 也不做控制,由于支持图像界面多格式,所以我们可以方便地使用AVI或 GIF动画作为背景来增加场 景的效果和真实性.景色还包括了行走性质定义,我们采用的是8x8为一单元,每个单元定义了一种 性质,比如平地,草地,障碍物等.

    活动对象是在背景和前景之间活动,他们之间有相互的位置关系,前后关系随着位置改变会不断 改变,因此他在所属的CGAMEPAGE中次序是动态的.对象的关系一般是由Y轴定义,由于要支持斜视角和 复杂的地形结构,光靠Y轴是不够的,我们引入了地基线的概念,通过在地基线之上还是之下来判断前 后关系,地基线的定义在图像定义中描述.活动对象有复杂的参数,可以接受外界消息,可以有自己的 各种反应.我们在引擎中使用了一种描述语言来描述他们的反应,比如对鼠标击打,人物经过等产生 参数改变,发声,对话等的回应.描述语言将作为专门的一章来介绍. 游戏显示过程是这样的, 在每次刷新期时窗口的游戏控件调用他所属的游戏页 CGAMEPAGE->SendDraw(); 游戏页将要显示的对象按前后次序送往窗口,同时注明此对象是否改变,窗口分析改写的区 域,调用每个对象的Draw()接口来刷新活动的区域,为了增加速度,并不是显示所有的区域,而是只改 写活动区域,因此我们设计了一个CCLIP的对象来管理刷新定义,它的原理是将表面分为16*16的单元, 最终显示时计算出优化后的多个剪切区域.整个窗口系统和每个游戏控件拥有自己的CCLIP对象.另 外一项增加速度的方案是游戏控件拥有一个比显示窗大两倍的显示页,这样场景滚动时只要将显示 位置改变即可 ,不用刷新所有区域. 游戏控制的过程是这样的:AcceptMsg()来接受各种消息调用脚本来改变自己参数和状态并影响 别的对象,另外每次时钟来时,调用每个对象的TimeTrace()来改变状态,比如动画改变,运动轨迹改变, 观察周围的对象做出反应等.

    系统控制模块:对系统的参数做出反应.不同的题材控制不一样,比如即时战略等.只要改写这部 分以及扩充游戏对象,引擎便能支持不同的题材.至于人工智能,智能行走,只是对象的方法,比较简 单,只是需要时间. 游戏控制部分比较复杂,每一种游戏对象都有许多控制的细节,在这篇文章里不做具体描述,以后 再说吧.
    最后一个是网络模块:我们正在开发的是国内第一个图形化MUD游戏,网络是它的核心部分,介绍 网络的内容很多,需专门文章.我们使用的不是DirectPlay,使用的是WinSoct,考虑的是UNIX作为服务 器的需求.网络要解决的难点是安全,同步和数据压缩,这里要用到许多技巧.

    游戏是通过数据文件来定义:

    数据文件格式:数据文件包括资源定义文件和游戏定义,界面定义文件,文件的数据格式我们采用 的是文本形式,类似于WEB的文本,这样的好处一是版本升级容易处理,二是可以减少前期对编辑工具的 功能要求,因为我们可以用文字编辑器处理大部分数据,然后有时间再设计一个强大的工具比较现实, 当然,最终提供给用户的是处理后的数据文件.他中间有一个转换模块.
    游戏的运行流程描述(不是真正的过程,按DOS格式描述):
    CreatGameWindow();//初始化window窗口
    CreatDraw(hWnd); //初始化图像引擎
    CreatSound();//初始化声音引擎
    CreatAvi()//初始化AVI引擎
    CreatNet();//初始化网络引擎
    LoadGameData();//读取游戏定义数据,包括资源定义文件和游戏定义,界面定义
    While(1)
    {
    WINTraceMsg();//处理系统消息,比如鼠标,键盘等
    GameTimeTarce();//处理活动的游戏页的时间反应
    WinPaint();//刷新游戏显示
    OutToScr();
    }

    我们这里介绍的是单线程结构,许多部分可以用多线来加快游戏速度,但结构是一样的,就不多介绍了.
    游戏引擎的系统分析是游戏设计技术方面的成功关键,是最容易走弯路的部分,希望我们的文 章能给大家一点启发,由于今天的游戏趋向于多类型综合,设计引擎时一定不要拘泥于某一单项题材, 我们在策划这套引擎时要求他支持的游戏非常广,甚至支持多媒体设计,这套引擎只要扩充或改写参 数管理以及游戏对象,便能支持各种风格的2D类游戏.将来我们要做的是一套可以交互设计各种游戏 的开发平台,当然不是<<游戏工厂>>似的玩具.

    今天就写到这里,这只是对引擎结构的大概介绍,其中每一点将来都有详细的描述,欢迎同志商讨. 我们尽量回答朋友们的意见,欢迎加入我们的队伍.

    8.脚本语言浅介
    -------------------------------------------------------------------------------

      今天,我想先以一套游戏使用的技术为蓝本,导入实务设计的范畴。你听过“ZZT”这套共享游戏吗。

      如果没有,别太在意,这是91年发行的文字模式角色扮演游 戏。我们不谈游戏本身,而把焦点放在游戏的开发系统当中。ZZ T虽然老,所引用的“物件导向”设计概念可是一点都不含糊。

      为什么需要额外设计一套游戏专属的程序开发系统?利用现有的程序语言难到不可以吗?首先,现今常见的程序语言中,大 多半都是通用语言,当然也有不少专用语言,严格说来,没有一 套游戏设计的专用语言。(不过,早在八位电脑时代,已有一套 名为“游戏制作者”的软件,它允许使用内建的语言来开发游戏 )就目前游戏主要使用的C语言以及汇编语言来说,程序员必须 从无到有,制作出游戏的引擎系统。

      如果有一套游戏开发系统,制作游戏(特别是续集)会大幅 度降低程序设计制作游戏所花费的时间与精力。让我们来看看几个实际的例子:Origin的创世纪系列(人物行程管理、对话皆有 专属系統)等。只要游戏开发系统规划得适宜,一旦制作完成, 对日后制作的游戏程序,绝对有大补益。

      我不想在这里就编辑器、编译器之间的差异以及设计的详细原理做讨论。虽然这些都与设计一套游戏开发系统有密切关系, 但这些都属于“系统程序”课程的范畴,我们只需了解就行了。   将程序与游戏资料独立安排有许多好处。你不会因为仅需要修改 游戏资料,就必须重新进行“修改代码、编译、连接”等繁琐的 过程。让我们来看一段ZZT游戏中,某商店老板的“控制”程序            

    @Vendor
    #end                      
    :touch      “事件”触发(接触该“物体”)
       "Hello, you must be new to town!   /
       If you want to be successful     讯息显示
       around here, you'll need to buy  
       some supplies!"           /
                         
    !ba;Ammunition, 3 shots.........1 gem   /
    !bt;Torch.......................1 gem    选项控制
    !bx;Advice......................Free   /
    #end                   
                         
    :b             选择第一项:购买弹药
    #take gems 1 ca             
    #give ammo 3               
    "Here's your ammo... Happy hunting!"   
    #end                   
     
    :bt             选择第二项:购买火把
    #take gems 1 ca             
    #give torches 1             
    "Here's your torch..."          
    #end                   
                         
    :bx             选择第三项:提出忠告
    "It is whispered that soon        
    if we all call the tune,        
    then the piper will lead us to reason. 
                         
    "And a new day will dawn         
    for those who stand long        
    and the forests will echo with laughter."
                         
              -Led Zeppelin     
    #end                   
                         
    :ca             错误处理(无力购买)
    "You can't afford it!"          
    #end                   

    以上是ZZT程序片段
      你是否了解上面的程序,这类经过大量简化后的控制程序,我们把它称做脚本语言。脚本语言除了接近口语化的设计外,另 加上简化后的语法。(除了内建的命令外,通常仅需简单的逻辑 判断与数值计算即可胜任)因此用脚本语言制作游戏,不在是再 是非程序员不可的工作(除了系统本身的修订),企画人员也可 以很快地进入状态。另外,如果将来需要将游戏移植到其他平台 时,比起程序与资料的盘根错节的设计,利用脚本语言来开发的 游戏,只需要修改系统本身,脚本语言部分本身毋须更动,相形 之下出现问题的机会与范围就缩小了很多。      
      这次以ZZT游戏为例,就是想对脚本语言部分的设计作了概念性的介绍。

    9.RPG游戏的对话系统
    -------------------------------------------------------------------------------

    我要和各位谈谈角色扮 演游戏中的最重要的一个部份~那就是交谈系统。若是各位 玩者接触的角色扮演游戏够多的话,应该会知道在角色扮演 游戏中有着单句式以及关键字两种完全不同的交谈系统,今 天我们就来看看这两个不同系统。

    要怎麽分辨单句式和关键字系统呢?我们可以简单的从在 游戏中玩者和游戏中的人物交谈时是如何获得讯息来看。在 一般国内的角色扮演游戏中,经常使用的就是单句式的交谈 系统,也就是那种玩者只要和角色对话,对方就会一股脑的 将所有的消息告诉你,而玩者也就可以获得所有的讯息,这 种就是属於单句式系统(如大宇的轩辕剑系列、仙剑奇侠传 等等)。就算是有的游戏用比较刁钻的方式,会要求玩者多 问几次才会出现真正需要的讯息(像精讯的乱世伏魔录), 也不过是这一种系统的延伸使用罢了。

    那麽关键字系统呢?我想最有名的应该就是创世纪系列, 在创世纪的前几代中,玩者需要自行输入各个关键字 ,来 询问各式各样的问题,随着玩者输入不同的关键字,就会有 不一样的答案。但是也因为这个原因,使得一 些英文程度 不好的玩者在接触那几代的游戏时相当的辛苦(反过来说, 也有一些玩者因为玩这个游戏而使得英文程度大增),也使 得许多的玩者不愿意接触创世纪。但是到了创世纪七代的时 候,由於采用了滑鼠来进行游戏,因此整个关键字系统就做 了很大规模的改进了,玩者可以由画面选择要问的关键字, 因此不再会有找不到关键字来问的状况发生了。

    那麽我们来看看国内的几个采用关键字系统的角色扮演游 戏吧。在笔者的印象中,好像只有精讯的聊斋志异、大宇的 妖魔道、以及软体世界早期推出的一个侠影记而已。在这几 个游戏中,笔者觉得精讯聊斋志异的关键字系统是最成功的, 至於为什麽笔者会这麽认为,绝对不是因为笔者自己曾经叁 与过这个游戏的制作,而是从关键字系统的结构来看,这个 游戏才是真的使用到关键字系统的精髓。

    所谓的关键字系统,正如同它的名称一样,是一个以关键 字来串连游戏剧情的交谈系统,因此玩者必需要能够从某一 个游戏中人物的口中获得某个关键字後,再使用此一关键字 到另一名人物的口中发挥作用,这才能说是使用了关键字的 妙用。在聊斋志异这个游戏中,玩者要获得第一座塔~金形 塔的八字真言,就必需要先从一位书生的口中获得四字真言, 然後再到酒店里找一位酒女,用这前四个字的真言向她询问 後四个字的真言。而所 谓的关键字系统的巧妙,也就是当玩者若是没有获得前一 个关键字的时候,在後面的那个人口中是无法取得下一个关 键字的。在聊斋志异这个游戏中,若是玩者不能先由书生的 口中套出前四个字的真言,那麽在酒女的对话选单中是不会 出现那四个字供玩者选择,因此玩者就无法获得後四个字了。 也就是说,关键字系统是一个凭着玩者选项不同会有不同情 况的对话系统。

    那麽我们回过头来看看另外两个游戏的关键字系统吧,首先我们来看看大宇的妖魔道吧。在这个游戏中也有关键字系统,但是它的关键字系统所发挥的作用并不是在对 话上,而是当某些任务还没有解决时,这些关键字就会出现 在对话的选单中,让玩者可以选择它取得所需的资料,当这 一项任务或是事件解决了後,这个关键字就会从选项中消失。 这种作法并没有真正发挥「关键字」的作用,只是用它来提 供玩者多次获得相同的问题解答而已。

    接下来我们看看侠影记这个游戏,这可以说是关键字系统 使用的错误范例,因为在这个游戏中,提供玩者选择的关键 字并没有影响其他地方事件的作用,反而把原来简单的可以 在单句中表现的讯息切成一段一段的文字,让玩者需要将所 有的关键字选择完之後才可以知道全部的讯息。再加上一些 关键字所得到的讯息又都是没有用的讯息,使得这个游戏的 交谈系统完全没有表现出关键字系统应有的特色。

    现在我们就来探讨一下这两种系统在资料结构上究竟有什 麽不一样的地方。首先我们来看看单句式的资料结构 ,记 得在讨论剧情结构的那一篇文章中(第52期),笔者曾经 举过一个单线式剧情的范例吗?那种的结构就 是单句式交谈系统的标准结构。因为在单句式交谈系统中, 在玩者遭遇一名游戏中的角色时,角色会依据当时 游戏中的剧情发展情况,决定出要说那一句话,若是在剧 情没有改变的情况下,就会重复的使用这一句话。

    在这种系统中,当玩者控制的角色和游戏中的角色交谈时, 程式会依据这名角色所相对的几个旗标,判断出目前该显示 出什麽样的讯息。若是同时有几个旗标都成立的话,也只会 以最优先的旗标为准。在这种系统之下,讯息的结构相当的 单纯,程式也只要将每一句对话编上相对的代码,然後用判 断式就可以决定出要显示出那一句讯息。同样的,这种系统 的资料结构也比较单纯。

    接下来我们看看关键字系统的资料结构吧。在前面说明单 句式系统的时候,笔者曾经说过要以旗标来判断显示那一句 讯息,其实这个所谓旗标就是游戏中控制剧情目前发展到那 里的指标。同样的在关键字系统中这些旗标也存在着,只不 过除了它们之外还要再加上一组关键字的旗标,而这些关键 字的旗标就是这种交谈系统的重心 。

    在游戏中,当玩者从其中一位角色的口中获得一个关键字 之後,这个关键字的旗标就会打开,之後若是有遇到对这个 关键字有所了解的角色时,在交谈的选单中就会出现这个关键字。

    在这种系统中,交谈的时候,程式会先判断目前玩者已经 获得那些关键字,然後再看这一名交谈的对象对於那些关键 字会有反应,接下来在在选单中就会出现这些有反应的关键 字让玩者选择。在选择了某个关键字之後,相关的讯息就会 显示在画面上,同时若是有某个关键字会因为问了这一句话 之後打开,也会在讯息显示之後将 此一关键字的旗标打开。接下来我们看看下面这个例子:

    在这个例子中,会有某甲以及某乙两个人,在游戏的过程 中玩者必需先从某甲的口中获得一句暗号,然後用这 个暗号向某乙询问,才可以获得所需的资料。因此在游戏中某甲的资料如下:

    某甲【无关键字】:喔,是你呀。我相信你一定是想要加入这个秘密的组织,不过若是没有组织的口令的话,是不可能加入的。

    ◎在这句讯息後关键字「口令」打开

    某甲【口令 】:你想要知道口令?好吧,那我就告诉你,我们的口令就是神出鬼没。

    ◎在这句讯息後关键字「神出鬼没」打开

    某甲【神出鬼没】:不对不对,这句口令不是对我说的,必需要找到我们组织的某乙,然後对他说出这个口
    令,就可以加入我们的组织了。

    因此在这个地方我们可以看到,在开始的时候玩者和某甲交谈时会先获得「口令」这个关键字,接下来这个关
    键字就会出现在交谈的选单中。而玩者选择口令这个关键字之後,就可以再获得进一步的资料以及「神出鬼没
    」这个关键字。之後再以神出鬼没这个关键字向某甲询问,就可以得知这个关键字的使用方式。接下来我们再
    看看某乙方面的资料:

    某乙【无关键字】:对不起,我什麽事都不知道,
    请你不要来打扰我好吗。

    某乙【神出鬼没】:你知道我们的口令,那麽你可以加入我们的组织了。我们的任务是要推翻目前的政府, 希望你也为这件事尽一份力。

    ◎成功的加入判乱组织了

    从这里我们可以看到,若是玩者在还没有获得神出鬼没 这个关键字的时候来找某乙交谈,那麽是无法从某乙的 口中获得任何的消息。但是当玩者从某甲的口中获得了「神出鬼没」这个关键字之後,在交谈的选单中就会出 现这个选项,选择後从某乙处就可以得到回应,也就可 以加入判乱组织了。这一种的交谈讯息结构,也就是关 键字系统真正能够发挥作用的地方。

    在设计关键字系统的时候有一件事要注意,那就是需要 适时的将某些没有作用的关键字关掉。就以上面的例子 来说,当玩者成功的加入了判乱组织之後,这一部份的 事件可以说是已经结束了,此时就可以将「口令」以及 「神出鬼没」这两个关键字关闭。不过若是这两个关键 字还有作用的话,就不可以这麽轻率的关闭它。

    说到这里也许有人会说其实这种剧情不需要用关键字系 统,就算是单纯的单句式结构就可以处理了。但是请各位 想想看,这里的剧情若是当玩者一和某甲交谈,某甲就将 所有的消息一股脑的都说了出来,那麽不是很没有 意思吗?除此之外,关键字系统在玩者被游戏卡 住的时候,还可以让玩者重复询问相同的关键字来获得讯息, 比起单句式结构那种不小心没有看到就会被卡住的情况来说, 是不是也显得比较人性化呢?

    前面所说的都是关键字系统的好处,但是为什麽目前的游 戏很少使用关键字系统呢?那都是因为要设计关键字系统的 话交谈的资料结构就绘变得比较复杂了。各位想想看,原本 在规划交谈的讯息资料时只要针对每个游戏 中的角色,配 合不同的剧情段落配上讯息就可以。但是在关键字系统中, 设计者必需要将关键字妥善的分配到
    各地的剧情对话中,才能使关键字系统真正的发挥作用, 因此在设计剧情的时候有比较多的困难。 除此之外,目前 国内的公司大多有将游戏推向国外的计划。由於中国字并不 是拼音系的文字,因此这些关键字 一但翻译成其它国家的 语言(像是韩文、英文等等)时,就会发生翻译出来的单字 变成好长一串的文字,若是 勉强的将一串文字删成适度的 长度时,又会有可能会文不对题的问题(这种情况就好像 魔法门三代中的问题被变成中文的问题那样奇怪),或是 因此要增加文字显示的区域。也因为这些原因,使得国内 的公司尽量的不去 碰这样的系统,以免自找麻烦。

    事实上关键字系统其实是个扩展性相当大的系统,就连游乐器的游戏中也曾经有采用过这样的系统。正因为它对於剧情的掌握比单句式的要强,以及它更结构化的 资料结构,它绝对是一个完美的交谈系统。

    10 完成制作的关键:推动力
    -------------------------------------------------------------------------------

    我最近听到一个说法:每开始制作50个游戏,最终只有一个游戏能制作完成。这个说法可以由几个原因来解释。制作者可能太超前了以致于在技术上完成不了;项目太复杂了或制作者们在协同工作时有分歧并导致开发停止。还有更多的原因显示了这种可能性:为什么98%的游戏不能最终完成。

    然而,我坚信以上的这些问题的影响都比不上在进度中失去推动力。成功的游戏制作者与失败的游戏制作者之间的区别并不是因为前一组成员更有才能,更聪明或更有经验。仅仅是因为前一组成员能完成他们的游戏。


    1.聪明,才智和经验
    聪明,才智和经验在你的游戏制作过程中和生活中将帮助你克服困难。让我们看看,简单地击键动作并不需要大脑的思考活动,但它需要一些你正在使用的计算机语言的知识,对操作系统的一些概念。大多数知识都能通过阅读帮助文件,相关的书籍,一些示例的源代码来获得,并且你并不需要透彻了解每样事件是如何运行的。

    举个现实生活中的例子,录像机有很多复杂的功能,你可能并不会用这么多的功能,但你仍能很好地使用录像机,使用遥控板上的放,前进,后退这几个键来操作就足够了。其它功能你并不需要掌握如何操作,那么你并不需要。编程也一样,做很多事情并不需要透彻地了解每个方面。当你进入一个新的领域,通常会阅读相关的资料来获得所需的信息。我学习一门计算机语言的方法是:简单地运行示例程序并不断地修改它,运行它,看看运行结果,来最终了解这种语言的。

    我并不暗示你不需要去努力学习,只是举例说明这些知识并不是决定性的。如果你不了解你的游戏软件和操作系统将怎样配合工作,那么你就需要去了解操作系统本身。尽可能多地去了解你的操作环境,直到你感到能够自如地工作,只会偶尔遇到几个问题时为止。


    2.麻烦和推动力
    社会的各行各业中,一个项目的完成都需要参与者的努力工作,项目完成所需的时间越长,人们就越可能会遇到更多的麻烦。游戏制作过程也不例外。

    游戏制作工业具有多变的本质,大众对游戏画面的要求,对某种游戏类型的喜爱,对游戏趣味性的要求,会经常发生变化。所以在制作期间及时了解业界的最新动态和互相交流是必须的。否则当你开始制作一个游戏,经历过一个较长的开发周期后,你制作的游戏可能已经落伍了。

    当你是独立制作游戏时,每次当你遇到一个问题时都可能会落入困境,特别是没有外部的支持时。制作中若有一个阶段达不到预期的目标,都可能会令你泄气。这对独立游戏制作来说是致命的。

    对不同的人来说,解决困难的动机是不同的。对有些人来说可能是需要成功以得到其它人的尊敬,或者得到一些报酬,金钱或其它形式的。对其它人来说,动机仅仅是一种创作自己心目中游戏的渴望。无论你的动机具体是怎样的,你都需要依赖它,在制作过程解决遇到的各项麻烦。忽视麻烦或中止开发一段时间,这简直和取消项目是一样的。所以制作者必须习惯于面对各类难题。

    保持推动力的一个方法是不断地尝试制作新的事物。每当你制作完成一个作品后,无论对你的自信心还是工作经验来说,都会更上一个台阶。如果你做了大量的工作但不能及时地看到结果,这会令你很不满意,并逐渐丧失推动力。如果你能及时地看到你的工作对作品的改变,那么制作人与作品之间的这种互动性很容易就能使你保持较高的推动力。这就是为什么强烈建议那些游戏制作的新人从一个小项目开始的原因。长周期的大项目往往需要一周或一个月的时间才能看到变化,这往往使新手变得沮丧,并最终不能完成他们的第一个游戏。


    3.中断一会
    在工作中适当地中断一会是十分重要的。如果你不适当地休息一会儿,你的注意力会渐渐变得分散,工作效率会下降。我曾看过关于注意力方面的研究报告,它指出大多数人在40分钟持续的做某件事后注意力将变得分散。很明显,每隔40分钟就休息15分钟将会浪费大量的时间。然而仅仅是去拿些饮料喝或去察看有没有新邮件到来,或者做任何别的事,都会帮助你长久地保持对工作的热情。

    在高强度的工作后,最好中断较长的一段时间。如果你遇到了一个特别困难的问题,那么最好在你开始工作前先休息一会,再解决它。短暂的休息能使你集中精力来工作,但是在你处理一件事的过程中最好不要中断,要一鼓作气。如果这个事件处理的过程很长,那么在完成一个阶段后再休息,并且做好中断点的记录,以便于下次能容易地接下做。当你在工作时,适当地中断一会对保持你工作的动力是很重要的。长时间的工作而不休息更有可能使你的游戏半途而废。

    现在来了解什么时候该休息,什么时候该继续工作。如果你处在一个工作气氛很浓的环境中,而且制作的进度很快,那么这时你最好尽你的所能持续地工作,把你所有的热情都投入其中,渴望产品的最终完成日。产品的最终完成日就像灯塔的顶部一样,在那里,你能够回想起你在制作过程中所有的努力。要记住,当你离开你的工作时必须确定,这个中断点在你回来后能够很容易地继续下去。这意味着如果你是一个程序员,若你的代码在编译时有一些错误,那么最好不要把这些错误留到明天再去解决,因为这会使你忘记是什么原因导致了这些错误。


    结论
    在你制作游戏时会遇到很多的障碍,你必须学会面对它们。推动力确实是完成你游戏的关键所在,要牢记,成功的游戏制作者首先必须先完成他们的游戏。

    11 十分钟学会 DirectX 中 的 COM 技术
    -------------------------------------------------------------------------------


    DirectX 是按照微软的COM(Component Object Model) 搭起来的。设计COM是希望它 能提供一个更安全,易升级,可移植的软件模块。COM用的面向对象的模式比一般的 C++更严格。例如,COM只能永远通过成员函数(member function)进行访问,并且不 能拥有公用数据成员(public data members)

    COM异常严格地对待对象(object)和接口(interface). 而且就不让你直接访问对象, COM竟然都不给对象起名字,让你老老实实通过接口来访问对象。在DirectDraw编程 中,我们讲:“访问对象”,其实都是在访问接口。叫惯了也就不改了。

    所有的COM接口都从 IUnknown 接口中派生出来。“I”打头是COM接口的标识(I for Interface). 所有的DirectDraw接口都以“I”打头,但莫明其妙的是在很多编程手 册中都把“I”略去。所以看书时要做到心中有爱(I)。

    IUnknown 接口提供三个成员函数,其余所有的COM接口,都继承这三个函数。
    AddRef()
    Release()
    QueryInterface()

    AddRef() 和 Release() 支持COM的一个特色功能,名字叫“活着封装”(lifetime encapsulation). “活着封装”是一个协议,用来让对象在崩溃时(destruction)自 己负责自己的后事。

    “活着的时候”(lifetime) 每个对象内部有一个值用来跟踪记载自己用过的指针(pointer) ,或引用(reference)。当这个对象建立时,该值为1。然后随着对它的调用/被调用, 该值递增。反之递减。当本身崩溃时(destroy itself),该值为0。

    AddRef()就是用来加计数器的。你可能不用亲自调用它。你在用DirectDraw API 时, AddRef()就被自动调用了。

    Release()则是对着干。减值。你常常要亲自用到它,因为程序可能会异常退出AddRef的 作用域(scope)。如出错控制中。

    QueryInterface()用来问COM一个接口是否可用。如可用,则返回一个相应接口的指 针。

    问对象是否支持一个接口用QueryInterface, 那么怎么问?当然要知道接口的ID。 我们用GUID来表示,GUID = Globally Unique IDentifier. (全局单一证认)。GUID是 一个128bits的数。所有DirectX中接口的GUID值都可在DirectX的头文件中找到。

    这就是全部了。怎么样,有概念了吧:-) he he he.


    12 windows 游戏设计时的单任务与多任务处理
    -------------------------------------------------------------------------------

    单 任 务 处 理

    Windows 最 杰 出 的 功 能 之 一 是 能 够 同 时 运 行 多 个 程 序, 但 有 时 也 会 让 人 感 到 头 疼, 特 别 是 对 于 那 些 习 惯 于 完 全 控 制 计 算 机 甚 至 时 钟 频 率、 非 常 自 信 的 游 戏 程 序 员( 当 然, 我 们 的 确 在 乎 那 些 没 礼 貌 的、 在 退 出 时 不 恢 复 正 确 的 系 统 时 间 的 游 戏。 但 是 幸 好, 现 在 我 们 可 以 忘 掉 这 些 了)。

    ---- 在 多 任 务 环 境 下, 游 戏 程 序 员 需 要 注 意 三 个 大 的 负 效 应:

    当 游 戏 失 去 焦 点 而 进 入 后 台 后, 其 执 行 不 得 不 被 挂 起( 可 以 在 Moby Dick Windows 中 使 用“ 中 止 的” 变 量 观 察 它 是 如 何 工 作 的)。 如 果 是 一 个 实 时 游 戏, 程 序 员 当 然 希 望 它 被 悬 挂。 但 在 回 合 制 游 戏 中, 当 玩 家 去 做 其 它 事 情 时, 程 序 员 可 能 不 希 望 计 算 机 一 方 作 任 何 动 作, 但 希 望 后 台 的 人 工 智 能(AI) 运 算 依 旧 执 行。


    其 它 的 任 务 占 用 CPU 时 间, 结 果 造 成 我 们 不 能 一 直 控 制 游 戏 中 事 情 发 生 时 的 速 度。 我 们 将 在 后 面 讨 论 这 个 痛 苦 的 问 题。


    每 当 游 戏 回 到 前 台, 程 序 员 不 得 不 重 画 游 戏 窗 口。Windows 并 不 负 责 记 忆 它 所 覆 盖 或 隐 藏 的 窗 口 的 内 容; 它 所 能 做 的 最 多 是 通 知 一 个 窗 口 需 要 重 画 其 客 户 区 域。 这 在 有 关 Windows 的 文 章 中 都 有 论 述( 参 见 WM_PAINT 的 内 容), 我 们 在 这 里 就 不 讨 论 了。 事 实 上,Moby Dick Windows 并 不 恢 复 其 自 己 的 窗 口; 我 们 将 在 讲 到 DirectDraw 下 的 双 缓 冲 时 看 它 是 如 何 实 现 的。

    程 序 中 的 多 任 务

    ---- 尽 管 Moby Dick DOS 在 使 用 中 断 处 理 程 序 时 展 示 了 内 部 多 任 务( 或 者 说 多 线 程) 的 一 种 原 始 形 式, 但 是 该 程 序 仍 然 没 有 突 破 DOS 的 单 主 题 特 性, 即 在 一 个 时 间 只 做 一 件 事 情。 有 些 DOS 程 序 的 确 作 到 了 真 正 的 多 线 程, 但 是 那 需 要 非 常 巨 大 的 编 程 工 作。Windows 95 SDK 使 这 项 工 作 简 单 了 许 多, 把 线 程 放 进 每 一 个 游 戏 开 发 者 的“ 锦 囊” 之 中( 如 果 读 者 还 不 熟 悉 这 个 概 念, 那 么 简 单 说 明 一 下, 一 个 线 程 就 是 程 序 的 一 部 分, 它 执 行 时 独 立 于 其 它 的 部 分, 并 且 不 需 要 与 其 它 部 分 同 步。 线 程 不 是 由 中 断 来 驱 动 的; 它 们 只 是 在 每 一 次 Windows 给 它 们 CPU 时 间 时 继 续 其 执 行。)

    ---- 在 下 列 情 况 下, 可 能 要 考 虑 实 现 独 立 的 线 程:

    允 许 后 台 AI。 就 算 是 用 户 正 忙 于 来 回 移 动(moving pieces around)、 打 开 对 话 框 等 事 情, 计 算 机 也 能 够 考 虑 其 下 一 步。 处 理 这 类 线 程 非 常 方 便, 因 为 它 不 需 要 与 其 它 的 事 情 同 步。


    预 先 加 载 数 据。 例 如, 当 玩 家 正 努 力 向 下 一 级 奋 斗 时, 使 一 个 线 程 负 责 读 取 文 件 并 准 备 好 游 戏“ 世 界”。


    给 予 时 间 紧 迫(time-critical) 的 任 务 优 先 权。 我 们 将 在 后 面 会 到 这 个 主 题。

    游 戏 循 环

    ---- 游 戏 循 环 的 概 念 在 各 编 程 环 境 下 都 比 较 相 似。 第 一 步, 需 要 获 取 输 入: 可 以 是 轮 询 它, 等 待 它, 或 者 在 它“ 运 行” 时 通 过 中 断 或 一 个 消 息 队 列 拦 截 它。 第 二 步, 处 理 该 输 入, 并 且 把 它 变 成 一 个 在 游 戏 中 有 实 际 意 义 的 动 作, 如: 使 飞 机 倾 斜 飞 行 或 小 卒 向 前 走 一 步。 然 后, 把 结 果 显 示 出 来。 当 然, 在 这 个 主 题 中 也 要 求 精 雕 细 刻 和“ 变 奏 曲”, 包 括 计 算 AI 的 移 动、 把 控 制 权 从 一 个 玩 家 移 交 给 另 一 个 玩 家、 检 查 胜 负 等 等。

    ---- 然 而, 在 Windows 和 DOS 下 实 现 循 环 的 机 制 迥 然 不 同。 每 个 Windows 程 序 都 建 立 于 一 个 消 息 循 环 之 上。 尽 管 一 个 游 戏 循 环 可 以 建 立 在 消 息 循 环 之 上, 但 是 这 两 者 仍 有 本 质 的 差 别。

    Moby Dick DOS 的 循 环

    ---- Moby Dick DOS 演 示 了 一 种 简 单 的 游 戏 循 环, 在 这 里 我 们 所 做 的 工 作 是: (a) 检 查 是 否 有 什 么 东 西 要 移 动, (b) 移 动 它, (c) 显 示 结 果。

    while (!gamedone)

    //调用时间程序 -如果时间未到,则没有任何响应。

    AhabMoved = Move_Ahab();

    //仅当 Ahab没有移动时移动 Moby Dick。

    //否则它们可能擦肩而过却不能拦截。

    if (!AhabMoved) Move_Moby();

    //如果有任何一个移动,更新屏幕,

    //并检查是否有胜利和失败。

    if ((MobyX != OldMobyX) || (MobyY != OldMobyY)

    || (AhabMoved))
    {
    UpdateScreen();

    if ((MobyX == AhabX) && (MobyY == AhabY)


    && (painted[MobyX][MobyY]))
    {
    gamedone = 1;

    cprintf("/a");

    cprintf("You win!");

    }

    if (TimesUp <= 0) { cprintf("/a"); cprintf("Time's up!"); gamedone="1;" } if (raw_key="=" MAKE_ESC) { gamedone="1;" progdone="1;" } } //结束更新 } //结束游戏内部循环 (while !gamedone) Moby Dick Windows的循环 从表面看来,好像没有多大的差别: do { if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) { if (msg.message="=" WM_QUIT) break; //唯一的退出循环的出口。 TranslateMessage(&msg); DispatchMessage(&msg); } else { if ((MobyX !="OldMobyX)" || (MobyY !="OldMobyY)" || (AhabMoved)) { UpdateScreen(); if ((AhabX="=" MobyX) && (AhabY="=" MobyY) && (painted[AhabY][AhabX])) { Control="MessageBoxEx(hwnd," "You caught Moby! Play again?", "Call Me Ishmael", MB_ICONQUESTION | MB_YESNO, 0); if (Control="=" IDYES) InitializeGame(); else break; } } //如果有人移动了 } //如果屏幕已更新 } //结束循环 while (TRUE);

    ---- 前 面 已 经 提 到 过, 这 里 没 有 检 查 是 否 运 行 超 时, 请 忽 略 它, 笔 者 在 Windows 版 中 未 实 现 它 是 为 了 避 免 令 人 烦 恼 的 中 断。 中 断 并 退 出 无 限 循 环 的 机 制 有 一 点 儿 而 且 并 不 重 要。 我 们 把 精 力 集 中 在 消 息 循 环 本 身, 所 以 把 其 它 的 无 关 代 码 都 删 掉, 只 留 下 最 基 本 的 部 分:


    do

    {

    if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))

    {

    if (msg.message == WM_QUIT) break;

    TranslateMessage(&msg);

    DispatchMessage(&msg);

    }

    else DoSomething();

    }

    while (TRUE)


    ---- 这 是 一 个 非 常 典 型 的 消 息 循 环。 唯 一 有 点 特 殊 的 地 方 就 是 它 使 用 的 是 PeekMessage 而 不 是 GetMessage。

    GetMessage 与 PeekMessage 的 比 较

    ---- 为 什 么 要 用 PeekMessage 呢 ? 原 因 很 简 单,GetMessage 等 待 一 个 消 息( 就 像 _getch), 而 PeekMessage 不 是 这 样( 就 像_kbhit)。 请 考 虑 下 面 的 循 环:


    while (GetMessage(&msg, NULL, 0, 0))

    {
    // 我 们 并 不 进 入 括 号 内 部, 直 到 有 一 个 消 息

    TranslateMessage(&msg);

    DispatchMessage(&msg);

    DoSomething()

    }

    // 当 GetMessage 返 回 NULL 时, 退 出 该 程 序

    return msg.wParam;


    ---- 在 这 里,DoSomething 不 会 完 成, 除 非 一 个 消 息-- 或 许 多 消 息-- 被 放 入 队 列 中 并 被 处 理。 如 果 DoSomething 恰 好 产 生 一 个 消 息, 例 如, 如 果 它 更 新 了 屏 幕 并 且 因 此 而 产 生 了 一 个 WM_PAINT 消 息, 那 么 好 了, 水 泵 注 水 后 将 开 始 启 动 了。 要 使 DoSomething 可 靠 地 完 成 其 工 作, 这 并 不 是 一 个 好 方 法, 它 使 代 码 有 点 混 淆, 但 它 工 作 的 还 不 错。

    ---- 相 比 之 下,PeekMessage 则 无 论 是 否 有 消 息 在 等 待, 只 要 检 查 一 下 消 息 队 列 就 完 成 其 操 作(yields the floor)。 在 我 们 的 例 子 中, 我 们 实 际 上 是 使 用 PeekMessage 来 处 理 消 息 的( 通 过 分 发 它 所 找 到 的 每 一 个 消 息 并 使 用 PM_REMOVE 参 数 从 队 列 中 清 除 它)。 同 下 面 同 样 有 效 的 代 码 相 比, 它 要 更 加 直 接:


    if (PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE))

    {

    if (!GetMessage(&msg, NULL, 0, 0)) break;

    TranslateMessage(&msg);

    DispatchMessage(&msg);

    }

    else DoSomething();


    ---- 在 这 里 有 非 常 重 要 的 一 点 要 说 明, 我 们 的 伪 代 码 DoSomething 是 独 立 于 消 息 的; 无 论 队 列 中 送 出 的 什 么 消 息, 甚 至 无 论 有 没 有 消 息 在 那 儿, 它 都 将 执 行。 在 Moby Dick 中, 我 们 将 屏 幕 更 新 和 胜 利 条 件 的 检 查 放 在 这 里, 因 为 在 这 里 检 查 一 个 或 多 个 消 息 被 响 应 后 是 否 需 要 更 新 屏 幕 或 是 否 达 到 胜 利 条 件 很 方 便。

    ---- 那 么, 消 息 循 环 就 是 游 戏 循 环 吗 ? 从 抽 象 的 角 度, 是 的, 因 为 它 是 大 的 齿 轮, 带 动 那 些 小 的 齿 轮。 但 是, 尽 管 把 一 些 函 数 调 用 放 在 此 处 可 能 比 较 方 便,Windows 编 程 规 则 却 要 求 任 何 响 应 一 个 消 息 的 动 作 都 应 该 放 在 消 息 响 应 程 序 中( 就 是 说, 放 在 窗 口 过 程 中)。 在 一 个 实 时 游 戏 中, 绝 大 多 数 的 动 作 发 生 在 一 个 或 多 个 WM_TIMER 消 息 响 应 程 序 中。 回 合 制 游 戏 则 常 常 在 输 入 消 息 的 响 应 函 数 中 做 大 量 的 工 作。

    ---- 事 实 上, 程 序 员 经 常 会 发 现 在 主 消 息 循 环 内, 除 了 标 准 的 翻 译 和 分 发 消 息 任 务 之 外 什 么 事 情 也 没 做。 如 果 这 样, 就 可 以 回 过 头 来 使 用 GetMessage, 因 为 除 了 响 应 消 息 之 外, 什 么 事 也 不 需 要 发 生。

    ---- 总 结 一 下, 实 现 循 环 有 两 个 关 键 点:

    Windows 消 息 循 环 与 游 戏 循 环 不 相 同。 游 戏 循 环 依 然 存 在( 至 少 在 概 念 上 如 此), 但 是 同 DOS 下 的 情 况 相 比, 它 的 部 件 在 代 码 中 更 加 分 散。


    如 果 想 要 在 消 息 循 环 内 执 行 任 何 独 立 于 时 钟 消 息 和 输 入 消 息 的 代 码, 请 使 用 PeekMessage 而 不 是 GetMessage。

    展开全文
  • 经典游戏制作教程

    千次阅读 2008-12-30 23:36:00
    经典游戏制作教程1.游戏制作的主要流程-------------------------------------------------------------------------------电脑游戏开发小组中的任何一个人(这个角色通常有策划担任),只要有了一个新的想法 或念头...
     
    

    经典游戏制作教程
    1.游戏制作的主要流程
    -------------------------------------------------------------------------------

    电脑游戏开发小组中的任何一个人(这个角色通常有策划担任),只要有了一个新的想法 或念头,就孕育着一个新游戏的诞生。在这个创意被充分讨论之后,再加上对其操作过程的趣味性及市场销售的可行性的预测等因素的准确判断,一个完整的策划方案才可能产生。在经过充分的讨论后,策划人员必须将讨论的重点写成文字,也就是提出完整的策划方案,经决策者同意认可后,才能进下一步的工作。这份策划方案就像一部电影的剧本,它必须完整地涵盖整个游戏的故事、流程、内容、方式、游戏画面、角色造型、 场景规划、人工智能、硬件配备、市场评估等。对整个游戏过程的详细描述及实施规划都应 记录在案。 当进入创作过程之后,策划还必须随时和美术设计师和程序设计员保持联系,以免游戏程序的编写失控。策划应能对游戏设置的内容与精神了如指掌,与各个小组及时沟通,并且控制整个游戏制作的进程。

     

    2.游戏设计基本论
    -------------------------------------------------------------------------------   

       要设计一个游戏,首先你必须要确定几个重要方针,第一是你要设计的游戏是属於那一种类型,第二是时代背景,第三是模式,第四是程式技术,第五是表现手法,第六是市场定位,第七是研发时间,在掌握上述七个方针之後,你就可以再做详细的规划内容及调配资源,那麽何谓是七项方针呢? 笔者以范例来说明之!
    一、类型:
       所谓的类型是指这个游戏所着眼的一个游戏方式,通过这个方式来使玩者达到娱乐的目的,这个游戏方式有专有名词来各别予以命名,兹如下述:

    (1) RGP角色扮演:
       这个类型的游戏以通过故事剧情牵引来使玩家能溶入主角所存在的一个世界,这类型态的游戏多半透过战斗升级系统及人物对话的方式来一步步完成设计者所布下的剧情路线,最具代表的作品有日本史克威尔所设计的 "太空战士系列" 及国内大宇资讯所设计的"仙剑奇侠传",当然还有很多部作品例如"神奇传说"等也是此中的佼佼者。
       在RGP的类型中,在近几年来又分支了几个类似的型态,例如说Blizzard的"暗黑破坏神"Dirblo"被定位为"动作RPG",因其动作成分相当高所至,而"神奇传说"、"超时空英雄传说"则被定位尽"战略RPG",只因战略成分比重较高所以又有别於传统RPG。

    (2) SLG战略:
       谈起战略游戏,大家最耳熟能详的应是日本光荣公司所出品的"三个系列",KOEI的三国志风靡东亚,从一代进化到现阶段的六代皆为玩家们所津津乐道,而所谓的战略游戏则是透过经营→战争→扩大领土三个手段来蠃得游戏最终目标,一般而言动态成分少,最较偏重於花费脑力的游戏,但从WestWood的新型态战略游戏"沙丘魔堡"问世之後,战略游戏也有了重大的分野,一是以KOEI代表的三国志系列被称为回合制战略游戏,一是以WestWood代表的C&C及Blizzard所代表的魔兽争霸被称为即时制战略游戏,和回合制所不同的是,即时制拥有较多可由玩家与电脑互动的机会,比较不花费脑力,所进行的 方式是建设→生产→攻击→歼灭,在业界有句俏皮话是这样说的:「玩回合制游戏像是自己当了个大将军(元首),运筹帷幄决胜千里之外,而玩即时制游戏则像是个士官长(部队指挥官),只能一味的打打杀杀」由此你可以了解到这两个型态的异同的了。

     

    (3) ACT动作:
       所谓的动作游戏其实就完全靠玩家的反应来做过关的条件,较有名的像DOOM、古墓奇兵、QUAKEⅡ 等,在动作游戏中也分支了相当多的类型,例如快打旋风、铁拳Ⅲ等被定位为格斗型态,主要游戏方式就是二人到四人互相对打一直到分出胜负为止,而DOOM、古墓奇兵则被定位为3D动作冒险游戏,主要目的为杀敌闯关,再来像阿比逃亡记、黑暗之心被定位为横向卷轴游戏,游戏方式就是以攻击跳跃等动作来走过一连串的关卡,表现方式多为2D卷动画面的方式在进行,再如飞龙骑士、极上疯狂大射击则被定为动作射击游戏,游戏方式就是闪躲射击冲过火网进而歼灭守关魔王为止,这些分支型态有共 通特点却又那样的不同,这也是动作游戏吸引人的重要原因。

    (4) PZL益智:
       这类型的游戏以趣味性的思考为游戏的主轴,内容可以包罗万,思维模式也可朝物理性及逻辑性方向着眼,具代表性的是大宇资讯的"台湾十六张麻将"、"大富翁"、"仓库番"等,而棋盘式的思考方式着名的有"决战中国象棋"及光谱资讯的"五子棋大师"等,这些游戏入手容易且不分男女老少皆喜欢的特性,使得益智型态的开发较有市场,成本也较低。

    (5) ADV冒险:
       冒险游戏的内涵多半脱离不了解谜的成分,是的!这类型的游戏让玩家抽丝剖茧的找出设在游戏背後暗藏的谜底,以顺利完成游戏,具代表作有恶灵古堡、异星搜奇、幽魂等,这类型的游戏年龄层较高,比较不适合国内厂商来研发。
       当你在构思一个新的游戏企划时即应预先想的所属意的类型,然後才进行下一步的计划,一般而言国内市场接受度最高的莫过於 RPG角色扮演类型,这也是为何国内厂商会如此的大力研发RPG型态的游戏。

    二、时代背景:
       对於游戏美术来说是一个很重要的方针,因为决定一个时代背景所意味的是资料的搜寻工作方便与否,与美术人员在制定造形时需依据的范例;以国内市场来说多半能接受中国古代时代背景,基本上时代背景有好几种,例如说WestWood的红色警戒架构在公元2000年左右的未来,而魔兽争霸则定在虚幻的欧洲中古世纪中,三国志定位在汉朝末年,星海争霸架构在外太空世界,轩辕剑则定在春秋战国时代等。
    时代背景绝对是企划人员在第一阶段规划整个游戏时已先决定好了,如此美术人员才能放心的去搜集资料。

    三、模式:
       当决定好类型及时代背景之後,再来就开始要去构思游戏中所要呈现的模式,如假设你的背景订在古代中国,而类型是定为即时战略,这时你必去思考出游戏内容的进行方式,可能你的游戏需要生产的因素,这个因素是什麽? 可以是粮食、矿产及木材,也可以是火山能源、石油、太阳能或天然气等,随着你故事情节上的需要而去制定项目,在作战方式上你所设计的模式可能会去考虑到地形因素、天候因素及资源因素,而且会大量运用到各种战术及攻击方法等,因为如此所以同一种类型的游戏虽多,但模式上却各有特色各有偏重的游戏路线,也各自聚集了拥护者,这就是模式设定的一个重要性,切记千万不可去抄袭他人所定的模式,因为这样一来,当你所设计的游戏完成之後,眼尖的玩家们会把你的产品以过时抄袭为由而弃如敝履,这在这剧烈竞争的国内市场而言是无法存活太久的。

    四、程式技术:
       无论你对一个游戏想得多好,架构设计多庞大,如果程式人员本身的技术无法配合的话,那其实一切还是流於空谈,所以在设计一个游戏之前必要先去徵询程式人员的意见,在现在这个环境中不仅程式人员要会Windows98及Wi-ndows NT相关技术,一个完整的系统分析及系统规划是不可缺少的,如此可以避免掉在程式中不可预期的错误出现,而且在一个游戏设计中最好有二个程式人员在运作,一个负责内部程式 (游戏核心引擎) ,一个负责外部程式(介面程式),这样方可发挥完整的战力。

    五、表现手法:
          在这个环节中,企划人员、程式人员、美术人员要做完善的沟通及讨论,一般我们知道大部份的电脑游戏是256 色的系统,在这些游戏中对於色盘的控制有相当严苛的要求,为了达到最好的视觉效果,美术人员通常会向程式人员要求多重色盘的资源,而程式人员则会考量到切换时的状况及记忆体配置是否能完全充份,在系统上的问题确定之後,企划人员会提出呈现效果的建议,例如说爆炸效果的表现方式,由内而外扩张到消失的火焰激烈型或包容大量烟雾的燃烧型,这要由企划人员依故事内容来给予定义,同时以物理性逻辑给予美术人员一个建议,再由美术人员前去绘制。
       还有一个例子,以"C&C之红色警戒"与"AGO Empir世纪帝国"的海岸来说明,在"AGO Empir 世纪帝国"的海岸表现是静止的,海水不会流动,最多只有鱼在海中央跳跃,而"C&C"之红色警戒"的海岸表现手法是会流动的,但海中没有任何的特异之处,这两种表现手法各有各的好处及考量,但以笔者而言仍较偏爱"C&C之红色警戒"。
        游戏内容的表现手法通常伴随着同类型游戏间的相异处而有不同的评价及支持者,而不光是美术效果的表现手法,企划人员构思的游戏玩法及程式人员的程式表现都有密切的关系。

    六、市场定位:
       不论你所设计的游戏构想如何的好,如果你没有去清楚的定位出你的市场走向,那麽到时制作完成的游戏软体可能会面临到销售不佳的窘状,所以在设计游戏之前你得知道你所定位的族群在那里,从下表中你可作一个市场定位的叁考:
    年龄层               教育程度适合的类型内容

    7~12岁 国小动作、益智较多趣味性、教学性
    13~18岁 国中、高中动作、益智、 较多思考性质、图形精美化同 角色扮演、战略时又较多反射
    19岁以上 低知识水平益智、动作较暴力及冒险、趣味性质,操 作简单
    19~30岁 大专、大学以上角色扮演、战略富含多重思维性,可以影射周 、冒险、模拟、 遭事物,解谜及创造性运动 

    七、研发时间:
          这是企划人员在初步规划中的最後一个项目,针对上述的制作方针你必须对美术人员及程式人员安排一个完整的SCHEDULE,从这个SCHEDULE中去研判律发时间,从企划的角度来说,为了不使良好的点子被其他游戏公司抢先推出,同时也要避免推出後模式已落伍,一个游戏的研发最好在一年内,最多不可超过18个月,以成本控制的角度来说比较符合获利标准。
           假设你规划这个游戏需要一年的时间,那麽你就要去区分出美术制作时间 (第一线)及程式制作时(第二线)间的差异,并考量推出DEMO 版及游戏完成的时间,在适当时机打出游戏知名度,为游戏销售上打下一记商机。

    制作流程
       一个游戏的制作如果不能充份控制整个作业程序,那即有delay 的危险,大家都知道游戏软体delay对於销售上的影响会有多大,所以如何尽量避免de-lay是每个游戏设计者应极力去避免的,而要去避免游戏开发作业上delay的情况最重要的是严密控管作业流程及计划表。
       那麽究竟游戏制作流程是一个什麽样的情形呢? 首先企划人员在执行制作的前一个月即要定出企划大纲及搜集可用资源,并经程式人员及美术人员确认後开始执行,我们以一个即时战略的游戏来说明,在制作分期程式人员即投入地图编辑器的撰写,而地图编辑器的逻辑设定要由企划人员先期规划,然後程式人员才根据企划人员的规划而进行程式写作。
       在此同一时期美术人员即开始分工合作,一般一个游戏工作小组会有四位美术人员,他们分别负责造形、人物动作、介面、地图四个部分来制作,但这只粗分法,国内游戏公司较常使用这样的组合,在国外美术人员分为造形、人物动作、介面、地图、片头、过场、後制分镜、场景等九大部份,每个部份皆可能都有二人以上在作业,并有一名监制在执行风格及水准的品质控管,这些人统一由後制人员来与程式人员做交图及配合修图等沟通上的交流,所以说後制作美术人员的成败实关系到整个游戏品质的高低。
    由於程式人员在设计地图编辑器时需要利用到一些图素来做测试,所以地图图素设计人员要先一步绘制出程式人员所需要的图素,
       在程式人员测试通过之後方可进入大量生产的阶段,由於地图编辑器的设计者多半直接负责游戏引擎的制作,所以在初期企划人员便开始着手人工智慧AI的逻辑判断作详细的叙述,以期在程式人员撰写地图编辑器之後能立即作人工智慧AI的撰写,而在此同时负责撰写介面的程式人员亦与负责介面设计的美术人员作密切的配合,开始着手制作各个介面,因为介面不仅在游戏中是一个主司控制整个游戏的操作盘,同时也是一个游戏的外观,一个拥有优良创意的介面是很受 玩家喜欢的。 在测试地图编辑器时,程式人员亦需要利用移动物件(人)来测试地图上的障碍物判断及最短路径搜寻法,所以设计人物动作的美术人员在此时要先去做出一组人物动作供程式人员作测试,待程式人员把地图编辑器制作出来之後,人物动作设计的美术人员则只要不断的做并不断的把图给程式人员即可。

     


    3.游戏设计十诫律
    -------------------------------------------------------------------------------
     

    Travis S. Casey


    1. 编写你所喜爱的游戏
    不要人云亦云。只要你和你的朋友喜爱就可以了。 同样道理,不要编写某个游戏主题仅仅因为它当前流行而已。编写你所喜欢的题材, 这样才能激发你的热情。

    2. 经验是最好的老师
    学习游戏编程最好的方法就是阅读大量的游戏程序。玩和分析这些游戏,然后设计 你自己的游戏或扩展游戏。我最主要的经验都是角色扮演类游戏,我的许多游戏范 例也来自它们,但思路却适用于所有类型的游戏。 我阅读过大量的RPG类游戏,粗略算算大约有七十多个。其中大部份我都玩过,精 通四十多个。不但玩和精通这些游戏,我还分析它们。是什么使得这些游戏好或者 不好?我如何修改它?哪些部份表现的出色?哪些部份不尽人意?为什么? 玩和分析过其它游戏后,我把这些知识用于我自己的游戏。比如在“超级英雄”类 游戏中,“斗士”和“英雄”在使用了“指数特性的换算法”取得较好的效果。如 果我想设计“超级英雄”类游戏时,我就知道“指数换算法”很可取。这样的分析 能给你许多被验证过的思想用于你的工作中。

    3. 测试、测试、再测试
    测试你的游戏,尽可能多次的玩。最好当你不在场的情况下,让别人来玩,过后再 告诉他们。(让别人当你不在的时候玩游戏称为:“盲测”) 还有,推敲你的规则。考虑假设情况,解决概率复杂性。比如,如果你正在设计一 个RPG,试着找出平均人们用弓箭从一米、五米、十米、五十米和百米范围内射中 人形大小目标的百分机率。对于二战游戏,检测你的监视器和解决一个小步兵摧毁 一辆坦克的机率。反复计算在不同的条件下,如:不同的地形、夜间等等。这将有 助于你找到在数学中出错的地方或建立了一个不好的假设。

    4.学习背景知识
    如果你想编一个中世纪的神奇游戏,就要去读中世纪的文学和历史。读有关魔法的 书及现有的中世纪传奇游戏。对其它类型的游戏也是如此,如果你想做一个越南战 争的游戏,就应去读有关战争的正史及野史,特别是战略、战术的分析。 所有的背景知识可以用于几种途径:首先,能帮助你创造出逼真的角色。另外它能 减少你在术语及背景知识方面,出现重大错误的可能性。当然,资料应该本身就很 有趣。如果对于所要学的都不感兴趣,那为什么还要编写这方面的游戏呢?

    5. 正规教育
    选一门介绍概率和统计的课。试着读一些游戏方面的数学理论。你可能觉得那没什 么用,但它能帮助透视算法的掌握。斟酌你的英语(或其它你发表游戏所用的语言) 当游戏描写得好的时侯,就更容易学,至少不能有大量的语法错误。 如果你想制作电脑游戏而没上过任何编程课时,不妨学几门。你可能学不到什么编 程序的具体东西,但一门好的课程可以教会你如何组织程序使之更容易维护和发现 错误。 建立一个“参考文献库”,它是一系列和你所制作游戏工程相关的游戏、书籍资料。 当你清晨三点突发灵感而图书馆却已关门的时侯,它将是非常有用的。

    6. 抽取些时间
    一个游戏就像孩子,当它刚出生时,它的父母总认为它是完美的。从你的游戏中抽 出些时间去得到一些新的观点,避免都耗在上面。一遍遍的重复这一过程。

    7. 保留记录
    确定你有一份以上的游戏拷贝。如果你是在电脑上输入的,就各保持一份硬盘和软 盘拷贝,另外再打印出一份清楚的最近版本(如每月打印一份,如果你干得快的话每 星期打印一份)。你不会觉得拷贝太多,因为你的好朋友们会来向你借或者想拥有拷 贝。而且这些拷贝能够减少你因为硬盘瘫痪或丢失笔记本等原因造成的丢失机会。 同样道理,保留旧版本的拷贝是有好处的。如果你在游戏测试时发现新的办法还不 如旧的好,而你却已将旧版本的扔掉了,这该怎么办?至少保留一份最后版本之前 的拷贝,同你当前版本的拷贝放在一起。

    8. 其它注意事项
    优秀的规划和书写是好的,但精美的视觉化说明对你的销售大有益处。如果你要自 己动手,就学一些桌面出版,或找一些现成的插图(比如:剪辑艺术或政府出版物) 或找别人帮你画些插图。 找个从事印刷业的人,和他探讨一些尽可能廉价的方法。低价格可以有助于销售, 低成本则有利于你的收益。

    9. 记住这只是个游戏
    不要因为制作游戏而忽略你的现实生活。如果有人不喜欢你的游戏,别介意。不用 担心别人窃取你的创意。记住第一条诫律,从你的所做中得到乐趣就行了。

    10.没有第十条了 :-)

    另外,这里有一些来自汤姆(“棱镜游戏”的主持者)的额外忠告,感谢汤姆!:
    1.不断的创新是非常好的。如果你游戏中的所有东西都令人似曾相识,就好像是 偷来的。如果所有东西都与众不同又会让人感到陌生。常见题材单一独到的构思是 好的,但会使得你的游戏看来像个“变体”,而两个熟悉题材精明的创意则会使游 戏有新鲜感同时容易上手。因此不要试图彻底从新发明某样东西,而应把当前所拥 有的主意清晰化、简洁化的用于扩展关键观念的创新和趣味方面上。
    2. 修正和雕琢你的游戏创意。测试不仅仅为了清除游戏和规则介绍中的错误,而 且就像一个讨论会,对照他们已经取得的东西,游戏设计师能够发现什么是真正所 要表达的。如果你将测试留到最后,这一发现将对你没有什么好处。如果你进行早 期的测试和经常从眼前试着发现这一游戏真正要表达的,你就能常常很大的改进这 一游戏。 “ Alpha”测试就像在问:“是否真有这个游戏?”“我得到它了吗?”“ Beta ” 测试看来在问:“是否用了最好的方法达到这一效果?”,“这是游戏的精炼吗? 或者它是否能被简化或删除?”“是否所有主要的游戏系统协同工作,给予了我所 期待的游戏体验?”“ Gamma ”测试又像在问“如何才能改善游戏的收支平衡 和介绍呢?”许多设计师停留在Alpha(生产一个吸引人但却是次品的游戏)之后或 者从Alpha直接到Gamma,跳过了Beta(生产一个好的但还不够完美的游戏)。 通常有必要靠你的亲密朋友/游戏小组及早的进行足够的批评性分析,帮助你发现如 何才能改进一个已经相当不错的游戏。

    我的一些其它建议:

    在我制作游戏过程中,从没有清晰明显的测试“阶段”。我倾向于每个阶段都做一 点。我修改一些系统,抛弃或替换一部分,改善其它的收支平衡和介绍,差不多是 在同时做的。这些部分来自于我所从事的主要游戏类型的设计-宇宙类RPG,你必须 在一个时间内干一个部分的事情。 关键在于去寻求达到你最好的作品。用不同的方法尝试,直到找到适合你的方法, 然后用它钻研下去。

     

    4.游戏的剧情
    -------------------------------------------------------------------------------


    游戏剧情的重要是不言而喻的,特别是RPG游戏,相信广大玩家对"仙剑奇侠传" 熟得不能再熟了,这个游戏以剧情取胜(他的音乐也相当不错),各大媒体对他的 评价也都是以剧情为主,这个我就不多说了.
    我也曾看过许多文章提到剧情的重要,这些文章说的相当好,相当有价值,但基 本上讲述的是剧情的要点及注意事项.而我将从另一个方面去分析游戏的剧情.
    游戏的剧情是游戏的灵魂(当然除少数不需要剧情的游戏,如体育类,赛车等), 游戏通过各种各样的方法让玩家融入到设定的剧情上以打动玩家,但如果游戏 的剧情不吸引人,那么无论游戏的表现手法有多好也不能达到目的,但是怎样 的剧情才吸引人呢.
    事实上中国与外国玩家有着很大的文化差异,这一点可以从各地所出产的游戏 上看得出来,欧美的游戏大多重视人物与场景的直实性,看上去就像电影,而东 方的游戏普遍追求漫画式的效果.但这两种风格哪种适合我们呢?答案是两种 都适合.不要忘记我们的玩家基本上是青年一代,对新事物的接受是相当快的, 对欧美的游戏我们的玩家接受得很快,从这可以看出国外的游戏制作是相当出 色的,就拿我自己举个例子,前两天我得到一款"生化危机2"的游戏,游戏开始 的动画可以说是扣人心弦,并且很好的衬托出了主题.而第二种风格的代表作 品就是"仙剑"了.
    游戏所要表现的内容必须能够被玩家接受,而且还要有创新,这样的剧情才说 得过去.现在我们有一个很好的观察点,那就是电影,外国的制作精良的大片 挤进中国后给我们的冲击多么大,而中国传统题材的作品也给我们留下难忘 的印象.
    我们不得不承认,在技术上我们与国外的游戏制作公司相比还差了一截,这 使得许多很好的题材我们不敢用,因为以现有的技术还不能很好的将他表现 出来,如果勉强还可能会起反作用(这是有例子的).
    在这里我只是起一个开头的作用,什么样的剧情适合大家也不是一下能说清 楚,希望广大游戏爱好者能积极讨论这个问题,这也是我们中国游戏业现阶断 的一个重要的有待解决的问题.

     

    5.角色扮演游戏的升级系统研究
    -------------------------------------------------------------------------------

     


    在一般的角色扮演游戏中,人物的成长是一件相当重要的事,无论是角色扮演游戏或是目前热门的策略型角色
    扮演游戏(简称RSLG),这些升级系统都是游戏的一个重要部份。不过在一般的角色扮演游戏中,人物的升级
    以及成长却有着很多种的处理方式。在本文中,笔者将为各位介绍各种角色扮演游戏中常用的升级方式,并且
    分析各种作法的优缺点。

    在一般的角色扮演游戏中,最常用的升级方式就是乱数式的成长方式。在这种模式中,当一名角色获得升级的
    时候,程式会使用乱数来决定升级的各项指数,也就是说所有的升级数值都不是在控制中,而是依据一个乱数
    表来决定提升的数值。这种升级的方式是如何处理的呢?

    当人物到达升级的标准时,就会进入处理升级的副程式中,在这个副程式中程式会依设计者所定出的一个乱数
    范围,来计算出这名角色所得到的升级指数,然後将这个数值加到需要增加的属性上。

    在这种乱数决定升级的情况下,玩者所能够获得的升级数值,完全是由设计者订定的范围中求出,无论是升级
    的上限或是下限都是在这个范围内,绝对不会有意外的情况发生,就算是设计者如何提高上限与下限,都不会
    改变这些。这种作法虽然可以让设计者很轻松的订出升级的上下限,但是却不能控制升级时的不利因素,那就
    是乱数的成份实在是太高了。若是有一名角色因为运气不好一直只有获得下限的升级数值,那麽它可能会比一
    个一次就获得上限升级数值的角色要弱。举例来说,当这个乱数的范围是一到五的时候,若是角色甲和角色乙
    分别获得上限和下限的升级数值,那麽会发生以下的状况:

    ┏ ┳ ┳ ┓
    角色甲 角色乙
    ┣ ╋ ╋ ┫
    LV1 10 10
    LV2 15 11
    LV3 20 12
    LV4 25 13
    LV5 30 14
    LV6 35 15
    ┗ ┻ ┻ ┛

    各位看看上表,是不是可以看到角色甲在第二级时的数值就已经和角色乙第六级的数值是相同了。由於乱数式
    的升级方式会有这种不公平的情况发生,因此常会使得玩者的努力需要有一些运气的成份在里面;若是运气不
    好,可能原本的努力都无法发挥所要的功效。

    由於乱数式的升级方式有这样的缺点,因此有两种不同的改进办法,首先就是百分比制的升级方式。在这一种
    办法里,角色在升级的时候还是使用乱数来进行,不过在每一个数字的出现比例上却做了一些调整。例如同样
    的升级的范围还是从一到五,但是每一个数字的出现比例调整如下:

    ┏ ┳ ┓
    数值 出现比例
    ┣ ╋ ┫
    1 10%
    2 20%
    3 40%
    4 20%
    5 10%
    ┗ ┻ ┛

    各位从上表中可以看到,在这一种处理方式上,每一个数字出现的比例做了一些调整。原本的乱数式中,每一
    个数字的出现比例都是相同的,就以上面的例子来说,每个数字出现比例是百分之二时,因此上限和下限的数
    值比较容易出现,发生不幸的情况比较多;但是在这样子调整後,上限和下限的数值出现的机会就减低了不少
    ,会发生不幸的情况就降低了。

    虽然这样的作法可以降低不幸的发生机会,但是还是无法完全的克服所有的状况,因为还是有可能会发生相同
    的状况,使得玩者陷入属性不佳的情况中。因此另外一种改良的方式~修正值升级方式就这麽出现了。

    其实修正值的升级方式和原本的乱数处理法在计算的时候是完全相同的,只不过是它在升级到一个程度的时候
    ,会来做一次计算并且取出一个修正值,以免玩者因为运气不好无法达到升级的功效。

    在这种作法上,上半部和乱数式的做法完全相同,唯一的不同是下半部的副程式。而这个副程式的作用就是在
    帮一些升级时运气比较不好的玩者取得一点修正值。

    我们就以前面所说的升级的数值是从一到五来做个例子,让玩者每升五级时就可以取得一点修正值。因此若是
    一名角色在五次升级中都只有获得一点的升级值,那麽目前它的数值就是:

    10 + 1 + 1 + 1 + 1 + 1 = 15

    不过在我们的升级表内中等的数值是三,因此当角色升了五级之後,应该可以获得以下的数值:

    10 + 3 + 3 + 3 + 3 + 3 = 25

    这麽说来这名角色因为前五级的升级运气不好,因此少获得了十点的升级指数,所以我们就在这一次把这个缺
    少的数值以修正值的方式补足,从修正值的计算式中可以得出:

    25 - 15 = 10

    就将这个数值加到角色的属性中,让角色不会因为运气太差而有不利的情况。若是角色在升级中都获得比较高
    的数值,那麽修正值就是负的,也就表示不需要有修正值的存在了。

    这种作法完全是为了不让玩者因为升级时运气不好使得属性太低,因此只能算是修正部份数值的作法,虽然不
    能完全解决乱数式的问题,但是可以将不利的因素降低,因此在某些游戏里的确有采用这样的作法。

    除了乱数式的作法外,还有一种是表列式的升级方式。在这种升级方式中,每一名角色的升级数值都是设计者
    已经订好的,完全不会有任何的变动。它的好处是设计者可以完全掌控所有的升级状况,但是相对的这样子的
    表格需要占掉较多的程式空间。

    举例来说,某个游戏若是采用这种升级方式,那麽在它的记忆体中就需要有这样子的升级表格。若是游戏中有
    七项属性会获得升级,等级共有一百级的变化,那麽基本上它就需要有七百个不同的数值表放在程式中。若是
    一个数值用了两个位元(BYTE),那麽就需要用到1K左右的记忆体。如果说游戏中有四名角色,它们升级情况
    又都是不同,那麽占掉的记忆体就将近有5K了。这麽算起来各位可能觉得不会很多,但是当这种资料越来越多
    的时候,记忆体的消耗也就越来越多,使得程式的空间也越来越小了。

    由於表列式的作法会使得升级的情况比较单调,因此大多数的游戏并不愿意采用这种作法,再加上这一类的作
    法对於记忆体的占用空间也比较高,因此如果不是必要,大多数都不会用这种作法。

    除了以上这些作法之外,还有一种就是指数型的升级方式。这种作法其实就是表列式的改良,因为它将升级的
    表格简化成一个叁数,在升级的时候就依这个叁数来计算能够获得的升级值。现在我就举一个例子来示范。目
    前有一名角色的属性以及升级指数如下:

    o 生命:10 生命指数:10
    o 法力:10 法力指数:10
    o 力量: 3 力量指数: 2
    o 智慧: 2 智慧指数: 2
    o 反应: 2 反应指数: 2
    o 体能: 4 体能指数: 2
    o 运气: 1 运气指数: 3

    那麽当他获得升级的时候,程式就会依这个升级指数来计算升到下一级时的各项属性值。因此在升了一级之後
    ,各项属性的数值就是以下的数字:

    o 生命:20
    o 法力:20
    o 力量: 5
    o 智慧: 4
    o 反应: 4
    o 体能: 6
    o 运气: 4

    用这种作法,在程式内不需要复杂的升级属性表,只需要几个简单的叁数就可以,若是能将各项叁数之间的关
    系加以变化,并作一些运算,那麽可以使升级时的变化更多。举例来说生命的增加和体能有关,或是法力的增
    加和智慧有关,那麽在计算起来时会有比较多的变化,使得整个升级的表现不会太单纯。

    以上这些作法大部份的变化程度都不会很多,没有办法表现出一个人的成长情况。就像我们有时候会形容一个
    人「大器晚成」或是说他「小时了了」这样子的情况都不能表现出来。因此後来又有一种成长曲线的升级方式
    。在这种升级方式中,我们首先要订出几种不同的升级情况。像是:

    A. 平衡成长
    B. 大器晚成
    C. 小时了了

    要达成这种效果,我们需要将升级的总等级数分成几个阶段。我们以一个可以升到一百级的游戏来说,将每十
    级分成一个区块,就可以订出这三种成长情况各要给它多少的数值。

    其实这种曲线式的升级方式,在处理上和指数式的作法差不多,只不过指数式的作法一个人物每一种属性只会
    有一个数值,这个数值是不会改变的。但是在曲线式的作法中,会依不同阶段有不同的升级指数,才可以造出
    不同的成长情况。我们就以一名「大器晚成」的角色来说,这一类的角色在开始成长的比较慢,但是当人物成
    长到一个阶段後,成长的速度就会加快,因此我们可能在前两个阶段只给他们一点的升级指数,後面几个阶段
    再给他们较高的升级指数,使这名角色会在游戏後期升得比较快。

    反过来说,若是要设计一名「小时了了」的角色,那麽我们在初期可以给他较高的升级指数,但是到了後期就
    要给它较低的指数,如此一来就可以表现出这样的情况。

    事实上,在游乐器中的「光明与黑暗续战篇」就曾经用过这一种作法,使得游戏中的每个角色都有各自不同的
    特色。特别是有些属於大器晚成的角色,曾经因为初期成长的速度太慢而被玩者抛弃,但是後来知道这名角色
    的特性之後,再回过头来训练的这种情况,正是这种曲线式升级的特色。这种作法使得角色除了单纯的数字属
    性之外,还增加了一些隐藏的特性,会让游戏更有味道。

    如果以笔者个人的喜好来说,我是比较欣赏曲线式的升级方式,因为这种方式比较可以隐藏角色的特色,也不
    会因为数字的变化太过单调而让玩者觉得过死板。比起乱数式的不定性和升级指数式的单纯来说,这一种作法
    可以说是兼具了两种的特色,同时还有全新的表现,是一种不错的升级方式。只惜目前国内的游戏很少使用这
    种作法,大多还是采用乱数式的作法,对於国内玩游戏的玩者来说,实在是有些可惜,因为大家没有办法体会
    到这种作法的优点。

     

    6.游戏中的智能系统处理
    -------------------------------------------------------------------------------

     

    游戏中的智能对手
     AI在游戏中最普通的形式是创建计算机控制的对手。因为大多数游戏是单人游戏,所以要设计游戏者在游戏中必须战胜对手。为了达到这个目的,你可以使用某种类似A*搜索的简单AI算法,以帮助对手穿过迷宫向游戏者发起进行。你也可以使用简单的算法预测游戏者的反应。
     但是,记住没有必要创建世界上最强大的对手。你的对手只要能给游戏者提供足够的挑战性就可以了。还有,要注意游戏的内容。例如:一个战棋式RPG游戏中策略占的是主要地位;而在纯RPG中故事情节和角色开发就更重要一些。千万不要因为计算机对手太强大而让游戏者们陷入失败的泥沼。

    游戏中的非智能对手
     通常,在游戏开发中AI技术是与计算机对手紧紧联系在一起的。这是因为早期的大部分类似角棋的游戏是一对一的。但是,任何好的探险游戏或RPG 游戏开发者都知道,AI同样可以用于非对手角色。例如:如果你正在建立一个RPG游戏并且你想让你的世界活起来,这就是说,让城市里的人以智能的方式活动,那么你可以使用某种算法确定在一天中的某个时候,角色应该在那里。你可以使用类似于AI算法如A*来辅助你将一个对象从一处移动到另一处并绕过障碍物。

    游戏中的智能系统
    游戏中的AI在本质上是最具有模仿性的,但它们基本上是依赖一些AI要素。 你可以将所有具有决策功能的对象在一个游戏中融合为一个整体。例如:在一个战争游戏中,你的各个部分可以依据各自所处的具体环境来作出各自的AI决策。
      使用这种方法,你得把精力集中于怎样在各个独立的决策个体之间建立联系,以及这些联系怎样才能使游戏成为融会贯通的整体。是用一个高级决策影 响其它决策,还是各个决策个体之间平等地互相影响呢?举个战争游戏来说, 你有十辆坦克,它们的思维模式基本相同。所以它们都决定去攻击敌人阵营中 HP值最低的一辆坦克。但是这时其中一辆坦克说:“这个敌人归我了!”那么 剩下的九辆坦克就应该依据这条信息各自调整下一步的攻击目标。当你建立智能个体时,要考虑在一个智能系统整体环境下,它应该如何行动。

     


    7.电脑游戏中的人工智能制作
    -------------------------------------------------------------------------------


     电脑游戏随着硬件执行效率与显示解析度等大幅提升,以往很多不可能或非常难以实现的电脑游戏如此都得以顺利完成。虽然电脑游戏的呈现是那么地多样化,然而却与我们今日所要探讨的主题,人工智能几乎都有着密不可分的关系。
     在角色扮演游戏中,程序员与企划人员需要精确地在电脑上将一个个所谓的“怪物”在战门过程中栩栩如生地制作出来;所以半兽人受了重伤懂得逃跑,法师懂得施展攻性法术。
     目前能让人立刻想到与人工智能有密切关系的游戏有两种:
    一是所谓的战棋/策略模拟游戏,二则是棋弈游戏。人工智能的比重与深浅度,在不同的游戏类型中各有不一。有的电脑游戏非标榜着高人工智能不可,不然没有人买;有的则是几乎渺茫到让玩家无法感觉有任何人工智能的存在。            

     导向式思考

     AI最容易制作的的方式,同时也是早期游戏AI发展的主要方向就是规则导向或称之为假设导向。在一些比较简单的电脑游戏中,程序员可以好不困难地将游戏中的规则与设定转化成一条条的规则,然后将它们写成电脑程序。让我们以角色扮演游戏为例。决大多数的企画在设定所谓电脑怪物时,所设定的属性通常有以下几种:

      生命值 攻击力 防御力 法力  属性

     最后一个“属性”是我在设定时喜欢增加的项目之一。透过这项属性的设定,我可以把怪物设定成“贪生怕死的”,也可以把战士设定为“视死如归”。以目前我们所掌握的资料,在战门系统中的大纲如是诞生了:                          

    规则一

    if (生命值< 10) // 边临死亡了吗 
    {  if (属性== 贪生怕死)               
       结果 = 试图逃跑               
      if (有任何恢复生命值的物品或法术可用)      
       结果 = 使用或施展相关物品或法术       
    }                                                 

    规则二
     
    if (可施攻击性法术 && 有足够法力)
    {                        
       结果 = 施展攻攻击性法术             
    }                        

     由以上一连串的“如果--就--”规则设定,建立了最基本的AI。说这样的制方式只能建立基本AI其实并不当然正确。只要建立足够及精确的规则,这样的方式仍然有一定水准的表现。
     规则导向的最大优点就是易学易用。在没有深奥的理论概念的前提下,仍有广大的使用群。所以很多老道的玩家常常没两下就摸清楚敌人的攻击策略,移动方式等等。

     推论式思考

     相信曾经接触过电脑语言课程,或是自习过相关书籍的朋友们,都曾曾经听过一个著名的程序,那就是井字游戏。用井字游戏作为讨论AI的入门教材,我个人觉得是最适当的例子。或许有人还不知道井字游戏怎么玩。只要任何一方在三乘三的方格中先先成一线便胜利了。我们在前面谈过的规则导向,在这里也可以派得上用场。

     if任何一线已有我方两子&&另外一格仍空//我方即将成一线吗
      结果 = 该空格                     
     if任何一线已有敌方两子&&另外一格仍空//防止敌方作成一线 
      结果 = 该空格                     
     if任何一线已有我方一子&&另外两格仍空//作成两子    
      结果 = 该空格

     有一次我在某本电脑书上,同样地也看到某些以井字游戏为介绍的范例。不同的是,我几乎看不到任何规则导向的影子。但在仔细分析该程序码后,我得到了极大的启发,原来AI是可以不用这么多规则来制作的。它用的方法正是在电脑AI课程中重要的概念:极大极小法。我在这里只说明这法则的概念。继续以井字游戏为例,电脑先在某处下子,接着会以假设的方式,替对方下子,当然,必须假设对方下的是最佳位置,否则一切则毫无意义。在假设对方下子的过程中,自然又需要假设我方的下一步回应,如此一来一往,直到下完整局游戏为止。 底下是节录书中的程序片段:                       
     
    bestMove(int p, int*v)
    {   int i; 
       int lastTie;                  
       int lastMove;                 
       int subV;                                   
    /*First, check for a tie*/            
        if (isTie()) {              
         *v=0;               
         return(0);              
       };
    /*If not a tie, try each potential move*/
     for (*v=-1, lastTie=lastMove=-1,i=0;i<9;i++)
      {
       /*If this isn't a possible, skip it*/          
       if (board[i]!=0) continue;
       /* Make the move. */
        lastMove=i; 
        board[i]=p;                             
       /* Did it win? */                       
        if (hasWon(p)) *v=1;                     
        else{                             
       /*If not, find out how good the other side can do*/
         bestMove(-p,&subV);                      
       /* If they can only lose, this is still a win.*/
          if (subV==-1) *v=1;       
       /* Or, if it's a tie, remember it. */         
           else if (subV==0){                 
              *v=0;       
              lastTie=i; 
              };                          
           };                              
    /* Take back the move. */           
               board[i]=0;          
    /*If we found a win, return immediately
         (can't do any better than that)*/     
      if (*v==1) return(i);                     
    /*If we didn't find any wins, return a tie move.*/         
      if (*v==0) return(lastTie);                      
    /*If there weren't even any ties, return a loosing move.*/     
      else return(lastMove); 
    };    

     国外的一些论坛曾举行过256字节的游戏设计比赛。作品非常多,其中有一件作品正巧也是井字游戏。作者用区区两百多行就写了与上述程序演算方式完全相同的作品,可见功力确实了的。另外,我也很希望类似的活动能在国内推展起来。对了,在这样的比赛条件限制下,除了汇编语言外,几乎没有其它的选择了。       .386c                        
      code      segment byte public use16      
              assume cs:code, ds:code      
                                
              org   100h            
                                
      tictac     proc  far             
                                
      start:                       
              push  cs             
              pop   ds             
              mov   ax,0B800h     ; 清除屏幕
              mov   es,ax       ;    
              xor   di,di       ;    
              mov   cx,7D0h      ;    
              mov   ax,0F20h      ;    
              rep   stosw       ;    
              xor   cx,cx       ;    
              mov   dl,5            
      loc_1:                       
              call  printBoard         
      loc_2:                       
              mov   ah,8        ; 等待按键
              int   21h             
                                
              movzx  bx,al            

              sub   bl,31h       ; 如果不是1..9
              jc   loc_2       ; 则重新输入 
              cmp   bl,8              
              ja   loc_2              
              cmp   data_1[bx],al          
              jne   loc_2              
              mov   byte ptr data_1[bx],'x'     
              dec   dl               
              jz   short loc_3           
              mov   al,'o'             
              call  bestMove            
              mov   [si],al             
              call  isWin   ; 判断是否已取得胜利 
              jnc   loc_1              
      loc_3:                          
              call  printBoard           
              mov   ax,4C00h            
              int   21h               
                                  
      data_1     db   '12'              
      data_2     db   '3456789'            
      data_3     db   0                
                                  
      tictac     endp                  
                                  
                                  
      printBoard   proc  near              
              mov   si,offset data_1        
              mov   di,548h             
              mov   cl,3              
                                  
      locloop_4:                       
              movsb                  
              add   di,5              
              movsb                  
              add   di,5              
              movsb                  
              add   di,133h             
              loop  locloop_4            
                                  
              retn                  
      printBoard   endp                  
                                  
                                  
      isWin      proc  near              
              mov   bx,1              
              mov   bp,3              
              call  sub_3    ; 检查横向是否完成 
              inc   bx               
              inc   bx               
              dec   bp               
              dec   bp               
              call  sub_3    ; 检查纵向是否完成 
              call  sub_4    ; 检查斜向是否完成
              clc
              retn                  
      isWin      endp                  
                                  
      loc_5:                         
              stc                   
              retn                  
                                                                
      sub_3      proc  near              
              mov   ah,3              
              mov   si,offset data_1        
      loc_6:                         
              mov   di,si              
              call  sub_5              
              add   si,bp             
              dec   ah               
              jnz   loc_6              
              retn                  
      sub_3      endp                  
                                 
      sub_4      proc  near              
              mov   di,offset data_1       
              inc   bx              
              call  sub_5             
              mov   di,offset data_2        
              dec   bx               
              dec   bx               
              call  sub_5              
              retn                  
      sub_4      endp                  
                                  
                                  
      sub_5      proc  near              
              mov   cl,3              
                                  
      locloop_7:                       
              cmp   [di],al             
              jne   short loc_ret_8         
              add   di,bx              
              loop  locloop_7            
                                  
              add   sp,4              
              jmp   short loc_5           
                                  
      loc_ret_8:                       
              retn                      
      sub_5      endp                      
                                      
      bestMove    proc  near                  
              mov   bx,31FEh                
              mov   cl,9                  
              mov   di,offset data_1            
                                      
      locloop_9:                           
              cmp   [di],bh     ; #empty?        
              jne   short loc_12  ; #no, skip       
              mov   [di],al                 
              pusha                      
              call  isWin      ; #CY: Win       
              popa          ;            
              jnc   short loc_10  ;            
              mov   bl,1                  
              mov   si,di                  
              mov   [di],bh                 
              retn                      
      loc_10:                             
              pusha                      
              xor   al,17h ; good! toggle 'o' / 'x'
              call  bestMove                
              mov   data_3,bl                
              popa                      
              mov   ah,data_3                
              neg   ah                   
              cmp   ah,bl                  
              jle   short loc_11              
              mov   bl,ah                  
              mov   si,di                  
      loc_11:                             
              mov   [di],bh                 
      loc_12:                             
              inc   bh                   
              inc   di                   
              loop  locloop_9                
                                      
              cmp   bl,0FEh                 
              jne   short loc_ret_13            
              xor   bl,bl                  
                                      
      loc_ret_13:                           
              retn                      
      bestMove    endp                      
      code      ends

              end   start

     


    7.游戏引擎 小谢
    -------------------------------------------------------------------------------

     

    早想写一点游戏设计的文章与大家交流,一是经验的问题,二是公司正在紧张的游戏制作期,实 在抽不出多少时间,一直没有动手,今天忽然头脑发热,写了一段,以后准备陆续写一些游戏创意,策 划,制作,流程管理,和制作工具等方面的文章供大家参考.

    我们的游戏设计经验主要是冒险游戏和角色扮演游戏,但我们设计游戏工具时尽量适应其余题 材,不过是否可行未经检验. 写这篇文章的意图一是想为游戏界做点事,抛砖引玉吧,另外是公司正在寻找志同道合的战友, 我写一点文章交一交朋友,许多东西仅仅是我们的经验,不一定很好.参考而已吧

    游戏设计工具包括游戏编辑工具和游戏引擎两块;
    编辑工具:交互编辑游戏数据,生成游戏引擎所需的数据文件,包括以下几个功能块: 图像编辑,场景编辑,物品编辑,动画编辑,人物编辑,事件编辑等,具体介绍在以后的 文章介绍.

    先从游戏引擎说起.
    语言:VC5.0
    操作系统:WIN95
    图像引擎:DIRECT X 5.0
    支持游戏风格:各种类型和视角以及多层次的冒险游戏和角色扮演游戏

    整个游戏引擎包括以下功能块:

    资源管理:图像库CIMGLIB,声音库CSOUNDLIB,通过编辑工具形成的资源文件来定义,每种资源 包括定义管理和一些操作接口.图像库图"像包括多种格式(BMP,GIF.AVI,FLC等)以及他形成的内存 格式定义,子图定义(每一张图片包括许多小图,需定义它的小图位置,当然可以自动生成),游戏需 要的特殊定义,比如行走,身体性质,中心定位点,触发区,可以根据自己的要求扩充各种性质定义. 图像最好允许图像组合定义.声音库包括WAV和 MID的定义和再现. 资源由IMGLIB.DAT和 SOUNGIMG.DAT定义,调试版本中最好不要将资源打包,而是指向正常的 文件名,发行版本中再打包,这样修改和不同工作人员协调容易一些,否则最好有一个自己的资源 管理器.我们在调试版本中数据文件采用文本描述格式.许多数据可以手工编写而不需要专门的 编辑工具.
    资源管理对象还包括内存管理,比如设置时间阀释放长期不用的资源.

    声音管理:CSOUND,包括Creat(),Sound(char *fileName...),SetPos(),等,DirectSound有一 些函数,我们要做的是封装简化,减少对外的接口.
    窗口系统:接管标准窗口系统,一个完善的游戏引擎最好有一个自己的界面系统,至于简单还是 复杂根据自己情况具体分析,一个具备基本功能的界面系统1000行程序就可以对付下来,需要窗口 系统的原因是一般的图像引擎不支持标准窗口,二是可以便于移植到别的操作系统.在我们的游戏 引擎中,游戏只是窗口系统的一种特殊控件(CWINGMCTR),因此可以实现多窗口游戏等特殊要求.
    CWINGMCTR是一种特殊控件,通过他来控制游戏.包括控制和显示.

    图像引擎:所使用的图像引擎的管理,我们使用的是DirectX,包括Creat(),CreatSurface(), OutToScr(),Bilt()等对外接口;他不是游戏的重点,我们尽量将图像引擎细节封装起来.

    图像管理:这是处理图像的中心,一般处理游戏显示喜欢以某种图像引擎为中心来设计,我觉得 最好设计自己的对象来封装别人的图像引擎,这样不会因某引擎而受限制,移植也比较容易,我们虽 然使用的DIRECT X ,但实际上对外的接口是一种CPICPAGE的界面,他不但包括DIRECT X 的surface, 也包括标准的位图,AVI界面,GIF动画界面,以及自定义的格式,他将各种类型的图像统一起来,对外 使用统一操作,比如DRAWTEXT,BILT,LINE等标准图形图像操作,以及扩充的ALPHA通道,透明度等操 作.为了减少内存的需求,特别是16M高彩,不要将全部图像使用DIRECT X的表面,对一些刷新不多的 图像,比如背景,可以使用标准256色位图,甚至一种GIF表面,需要时再解压,我们还使用一种单色位 图用来从背景中抠图,比如一所场景中一棵巨大的树,只要不是动画,我们可以用单色抠图的形式从 背景中扣除来作为另外一层,这样我们可以大大降低图像的内存需求.因此采用全部手绘(或3D场景), 而不是小图拼贴的场景成为可能.通过各种手段可以节约60%的内存需求.
    CPICPAGE可以通过TimeTrace()以及多线程来改写内容,比如AVI的改变.

    游戏控制:这部分包括显示和控制,由CGAME->CGAMEPAGE->CGMOBJ对象组成,CGAME是总控对象, 包括许多CGAMEPAGE游戏页,CGAMEPAGE是一个具有连续场景的游戏片断,有点类似于游戏的一关, CGAMEPAGE由一系列CGMOBJ组成,CGMOBJ是游戏的基本对象,由他继承出地图,物体,物品,人物,武器, 动画,触发器,多媒体按钮等特殊

    游戏对象,这是一个根据游戏要求不断丰富和改写的部分,对外的 接口是:SendDraw(),Draw(),TimeTrace(),AcceptMsg(),SendNetMsg(),AcceptNetMsg()等,他是通 过CWINGMCTR来调用,每种对象有许多控制参数,对象之间允许通讯,以及有自己的生长死亡发展的 控制,尽量做到对象与外界减少直接接口,通过消息实现交流.

    对象分为两类:景色对象和活动对象,
    景色对象定义了组成场景的元素,包括背景和前景两层,可以是由整个图片组成或由RPG常用的 图片拼贴法的组成,它的特点只作为背景或前景,活动物是在他们的之间活动,一般定义后不做改变, 也不做控制,由于支持图像界面多格式,所以我们可以方便地使用AVI或 GIF动画作为背景来增加场 景的效果和真实性.景色还包括了行走性质定义,我们采用的是8x8为一单元,每个单元定义了一种 性质,比如平地,草地,障碍物等.

    活动对象是在背景和前景之间活动,他们之间有相互的位置关系,前后关系随着位置改变会不断 改变,因此他在所属的CGAMEPAGE中次序是动态的.对象的关系一般是由Y轴定义,由于要支持斜视角和 复杂的地形结构,光靠Y轴是不够的,我们引入了地基线的概念,通过在地基线之上还是之下来判断前 后关系,地基线的定义在图像定义中描述.活动对象有复杂的参数,可以接受外界消息,可以有自己的 各种反应.我们在引擎中使用了一种描述语言来描述他们的反应,比如对鼠标击打,人物经过等产生 参数改变,发声,对话等的回应.描述语言将作为专门的一章来介绍. 游戏显示过程是这样的, 在每次刷新期时窗口的游戏控件调用他所属的游戏页 CGAMEPAGE->SendDraw(); 游戏页将要显示的对象按前后次序送往窗口,同时注明此对象是否改变,窗口分析改写的区 域,调用每个对象的Draw()接口来刷新活动的区域,为了增加速度,并不是显示所有的区域,而是只改 写活动区域,因此我们设计了一个CCLIP的对象来管理刷新定义,它的原理是将表面分为16*16的单元, 最终显示时计算出优化后的多个剪切区域.整个窗口系统和每个游戏控件拥有自己的CCLIP对象.另 外一项增加速度的方案是游戏控件拥有一个比显示窗大两倍的显示页,这样场景滚动时只要将显示 位置改变即可 ,不用刷新所有区域. 游戏控制的过程是这样的:AcceptMsg()来接受各种消息调用脚本来改变自己参数和状态并影响 别的对象,另外每次时钟来时,调用每个对象的TimeTrace()来改变状态,比如动画改变,运动轨迹改变, 观察周围的对象做出反应等.

    系统控制模块:对系统的参数做出反应.不同的题材控制不一样,比如即时战略等.只要改写这部 分以及扩充游戏对象,引擎便能支持不同的题材.至于人工智能,智能行走,只是对象的方法,比较简 单,只是需要时间. 游戏控制部分比较复杂,每一种游戏对象都有许多控制的细节,在这篇文章里不做具体描述,以后 再说吧.
    最后一个是网络模块:我们正在开发的是国内第一个图形化MUD游戏,网络是它的核心部分,介绍 网络的内容很多,需专门文章.我们使用的不是DirectPlay,使用的是WinSoct,考虑的是UNIX作为服务 器的需求.网络要解决的难点是安全,同步和数据压缩,这里要用到许多技巧.

    游戏是通过数据文件来定义:

    数据文件格式:数据文件包括资源定义文件和游戏定义,界面定义文件,文件的数据格式我们采用 的是文本形式,类似于WEB的文本,这样的好处一是版本升级容易处理,二是可以减少前期对编辑工具的 功能要求,因为我们可以用文字编辑器处理大部分数据,然后有时间再设计一个强大的工具比较现实, 当然,最终提供给用户的是处理后的数据文件.他中间有一个转换模块.
    游戏的运行流程描述(不是真正的过程,按DOS格式描述):
    CreatGameWindow();//初始化window窗口
    CreatDraw(hWnd); //初始化图像引擎
    CreatSound();//初始化声音引擎
    CreatAvi()//初始化AVI引擎
    CreatNet();//初始化网络引擎
    LoadGameData();//读取游戏定义数据,包括资源定义文件和游戏定义,界面定义
    While(1)
    {
    WINTraceMsg();//处理系统消息,比如鼠标,键盘等
    GameTimeTarce();//处理活动的游戏页的时间反应
    WinPaint();//刷新游戏显示
    OutToScr();
    }

    我们这里介绍的是单线程结构,许多部分可以用多线来加快游戏速度,但结构是一样的,就不多介绍了.
    游戏引擎的系统分析是游戏设计技术方面的成功关键,是最容易走弯路的部分,希望我们的文 章能给大家一点启发,由于今天的游戏趋向于多类型综合,设计引擎时一定不要拘泥于某一单项题材, 我们在策划这套引擎时要求他支持的游戏非常广,甚至支持多媒体设计,这套引擎只要扩充或改写参 数管理以及游戏对象,便能支持各种风格的2D类游戏.将来我们要做的是一套可以交互设计各种游戏 的开发平台,当然不是<<游戏工厂>>似的玩具.

    今天就写到这里,这只是对引擎结构的大概介绍,其中每一点将来都有详细的描述,欢迎同志商讨. 我们尽量回答朋友们的意见,欢迎加入我们的队伍.

     

     

    8.脚本语言浅介
    -------------------------------------------------------------------------------

     

      今天,我想先以一套游戏使用的技术为蓝本,导入实务设计的范畴。你听过“ZZT”这套共享游戏吗。

      如果没有,别太在意,这是91年发行的文字模式角色扮演游 戏。我们不谈游戏本身,而把焦点放在游戏的开发系统当中。ZZ T虽然老,所引用的“物件导向”设计概念可是一点都不含糊。

      为什么需要额外设计一套游戏专属的程序开发系统?利用现有的程序语言难到不可以吗?首先,现今常见的程序语言中,大 多半都是通用语言,当然也有不少专用语言,严格说来,没有一 套游戏设计的专用语言。(不过,早在八位电脑时代,已有一套 名为“游戏制作者”的软件,它允许使用内建的语言来开发游戏 )就目前游戏主要使用的C语言以及汇编语言来说,程序员必须 从无到有,制作出游戏的引擎系统。

      如果有一套游戏开发系统,制作游戏(特别是续集)会大幅 度降低程序设计制作游戏所花费的时间与精力。让我们来看看几个实际的例子:Origin的创世纪系列(人物行程管理、对话皆有 专属系統)等。只要游戏开发系统规划得适宜,一旦制作完成, 对日后制作的游戏程序,绝对有大补益。

      我不想在这里就编辑器、编译器之间的差异以及设计的详细原理做讨论。虽然这些都与设计一套游戏开发系统有密切关系, 但这些都属于“系统程序”课程的范畴,我们只需了解就行了。   将程序与游戏资料独立安排有许多好处。你不会因为仅需要修改 游戏资料,就必须重新进行“修改代码、编译、连接”等繁琐的 过程。让我们来看一段ZZT游戏中,某商店老板的“控制”程序            

    @Vendor
    #end                      
    :touch      “事件”触发(接触该“物体”)
       "Hello, you must be new to town!   /
       If you want to be successful     讯息显示
       around here, you'll need to buy  
       some supplies!"           /
                         
    !ba;Ammunition, 3 shots.........1 gem   /
    !bt;Torch.......................1 gem    选项控制
    !bx;Advice......................Free   /
    #end                   
                         
    :b             选择第一项:购买弹药
    #take gems 1 ca             
    #give ammo 3               
    "Here's your ammo... Happy hunting!"   
    #end                   
     
    :bt             选择第二项:购买火把
    #take gems 1 ca             
    #give torches 1             
    "Here's your torch..."          
    #end                   
                         
    :bx             选择第三项:提出忠告
    "It is whispered that soon        
    if we all call the tune,        
    then the piper will lead us to reason. 
                         
    "And a new day will dawn         
    for those who stand long        
    and the forests will echo with laughter."
                         
              -Led Zeppelin     
    #end                   
                         
    :ca             错误处理(无力购买)
    "You can't afford it!"          
    #end                   

    以上是ZZT程序片段
      你是否了解上面的程序,这类经过大量简化后的控制程序,我们把它称做脚本语言。脚本语言除了接近口语化的设计外,另 加上简化后的语法。(除了内建的命令外,通常仅需简单的逻辑 判断与数值计算即可胜任)因此用脚本语言制作游戏,不在是再 是非程序员不可的工作(除了系统本身的修订),企画人员也可 以很快地进入状态。另外,如果将来需要将游戏移植到其他平台 时,比起程序与资料的盘根错节的设计,利用脚本语言来开发的 游戏,只需要修改系统本身,脚本语言部分本身毋须更动,相形 之下出现问题的机会与范围就缩小了很多。      
      这次以ZZT游戏为例,就是想对脚本语言部分的设计作了概念性的介绍。

     

    9.RPG游戏的对话系统
    -------------------------------------------------------------------------------

     

    我要和各位谈谈角色扮 演游戏中的最重要的一个部份~那就是交谈系统。若是各位 玩者接触的角色扮演游戏够多的话,应该会知道在角色扮演 游戏中有着单句式以及关键字两种完全不同的交谈系统,今 天我们就来看看这两个不同系统。

    要怎麽分辨单句式和关键字系统呢?我们可以简单的从在 游戏中玩者和游戏中的人物交谈时是如何获得讯息来看。在 一般国内的角色扮演游戏中,经常使用的就是单句式的交谈 系统,也就是那种玩者只要和角色对话,对方就会一股脑的 将所有的消息告诉你,而玩者也就可以获得所有的讯息,这 种就是属於单句式系统(如大宇的轩辕剑系列、仙剑奇侠传 等等)。就算是有的游戏用比较刁钻的方式,会要求玩者多 问几次才会出现真正需要的讯息(像精讯的乱世伏魔录), 也不过是这一种系统的延伸使用罢了。

    那麽关键字系统呢?我想最有名的应该就是创世纪系列, 在创世纪的前几代中,玩者需要自行输入各个关键字 ,来 询问各式各样的问题,随着玩者输入不同的关键字,就会有 不一样的答案。但是也因为这个原因,使得一 些英文程度 不好的玩者在接触那几代的游戏时相当的辛苦(反过来说, 也有一些玩者因为玩这个游戏而使得英文程度大增),也使 得许多的玩者不愿意接触创世纪。但是到了创世纪七代的时 候,由於采用了滑鼠来进行游戏,因此整个关键字系统就做 了很大规模的改进了,玩者可以由画面选择要问的关键字, 因此不再会有找不到关键字来问的状况发生了。

    那麽我们来看看国内的几个采用关键字系统的角色扮演游 戏吧。在笔者的印象中,好像只有精讯的聊斋志异、大宇的 妖魔道、以及软体世界早期推出的一个侠影记而已。在这几 个游戏中,笔者觉得精讯聊斋志异的关键字系统是最成功的, 至於为什麽笔者会这麽认为,绝对不是因为笔者自己曾经叁 与过这个游戏的制作,而是从关键字系统的结构来看,这个 游戏才是真的使用到关键字系统的精髓。

    所谓的关键字系统,正如同它的名称一样,是一个以关键 字来串连游戏剧情的交谈系统,因此玩者必需要能够从某一 个游戏中人物的口中获得某个关键字後,再使用此一关键字 到另一名人物的口中发挥作用,这才能说是使用了关键字的 妙用。在聊斋志异这个游戏中,玩者要获得第一座塔~金形 塔的八字真言,就必需要先从一位书生的口中获得四字真言, 然後再到酒店里找一位酒女,用这前四个字的真言向她询问 後四个字的真言。而所 谓的关键字系统的巧妙,也就是当玩者若是没有获得前一 个关键字的时候,在後面的那个人口中是无法取得下一个关 键字的。在聊斋志异这个游戏中,若是玩者不能先由书生的 口中套出前四个字的真言,那麽在酒女的对话选单中是不会 出现那四个字供玩者选择,因此玩者就无法获得後四个字了。 也就是说,关键字系统是一个凭着玩者选项不同会有不同情 况的对话系统。

    那麽我们回过头来看看另外两个游戏的关键字系统吧,首先我们来看看大宇的妖魔道吧。在这个游戏中也有关键字系统,但是它的关键字系统所发挥的作用并不是在对 话上,而是当某些任务还没有解决时,这些关键字就会出现 在对话的选单中,让玩者可以选择它取得所需的资料,当这 一项任务或是事件解决了後,这个关键字就会从选项中消失。 这种作法并没有真正发挥「关键字」的作用,只是用它来提 供玩者多次获得相同的问题解答而已。

    接下来我们看看侠影记这个游戏,这可以说是关键字系统 使用的错误范例,因为在这个游戏中,提供玩者选择的关键 字并没有影响其他地方事件的作用,反而把原来简单的可以 在单句中表现的讯息切成一段一段的文字,让玩者需要将所 有的关键字选择完之後才可以知道全部的讯息。再加上一些 关键字所得到的讯息又都是没有用的讯息,使得这个游戏的 交谈系统完全没有表现出关键字系统应有的特色。

    现在我们就来探讨一下这两种系统在资料结构上究竟有什 麽不一样的地方。首先我们来看看单句式的资料结构 ,记 得在讨论剧情结构的那一篇文章中(第52期),笔者曾经 举过一个单线式剧情的范例吗?那种的结构就 是单句式交谈系统的标准结构。因为在单句式交谈系统中, 在玩者遭遇一名游戏中的角色时,角色会依据当时 游戏中的剧情发展情况,决定出要说那一句话,若是在剧 情没有改变的情况下,就会重复的使用这一句话。

    在这种系统中,当玩者控制的角色和游戏中的角色交谈时, 程式会依据这名角色所相对的几个旗标,判断出目前该显示 出什麽样的讯息。若是同时有几个旗标都成立的话,也只会 以最优先的旗标为准。在这种系统之下,讯息的结构相当的 单纯,程式也只要将每一句对话编上相对的代码,然後用判 断式就可以决定出要显示出那一句讯息。同样的,这种系统 的资料结构也比较单纯。

    接下来我们看看关键字系统的资料结构吧。在前面说明单 句式系统的时候,笔者曾经说过要以旗标来判断显示那一句 讯息,其实这个所谓旗标就是游戏中控制剧情目前发展到那 里的指标。同样的在关键字系统中这些旗标也存在着,只不 过除了它们之外还要再加上一组关键字的旗标,而这些关键 字的旗标就是这种交谈系统的重心 。

    在游戏中,当玩者从其中一位角色的口中获得一个关键字 之後,这个关键字的旗标就会打开,之後若是有遇到对这个 关键字有所了解的角色时,在交谈的选单中就会出现这个关键字。

    在这种系统中,交谈的时候,程式会先判断目前玩者已经 获得那些关键字,然後再看这一名交谈的对象对於那些关键 字会有反应,接下来在在选单中就会出现这些有反应的关键 字让玩者选择。在选择了某个关键字之後,相关的讯息就会 显示在画面上,同时若是有某个关键字会因为问了这一句话 之後打开,也会在讯息显示之後将 此一关键字的旗标打开。接下来我们看看下面这个例子:

    在这个例子中,会有某甲以及某乙两个人,在游戏的过程 中玩者必需先从某甲的口中获得一句暗号,然後用这 个暗号向某乙询问,才可以获得所需的资料。因此在游戏中某甲的资料如下:

    某甲【无关键字】:喔,是你呀。我相信你一定是想要加入这个秘密的组织,不过若是没有组织的口令的话,是不可能加入的。

    ◎在这句讯息後关键字「口令」打开

    某甲【口令 】:你想要知道口令?好吧,那我就告诉你,我们的口令就是神出鬼没。

    ◎在这句讯息後关键字「神出鬼没」打开

    某甲【神出鬼没】:不对不对,这句口令不是对我说的,必需要找到我们组织的某乙,然後对他说出这个口
    令,就可以加入我们的组织了。

    因此在这个地方我们可以看到,在开始的时候玩者和某甲交谈时会先获得「口令」这个关键字,接下来这个关
    键字就会出现在交谈的选单中。而玩者选择口令这个关键字之後,就可以再获得进一步的资料以及「神出鬼没
    」这个关键字。之後再以神出鬼没这个关键字向某甲询问,就可以得知这个关键字的使用方式。接下来我们再
    看看某乙方面的资料:

    某乙【无关键字】:对不起,我什麽事都不知道,
    请你不要来打扰我好吗。

    某乙【神出鬼没】:你知道我们的口令,那麽你可以加入我们的组织了。我们的任务是要推翻目前的政府, 希望你也为这件事尽一份力。

    ◎成功的加入判乱组织了

    从这里我们可以看到,若是玩者在还没有获得神出鬼没 这个关键字的时候来找某乙交谈,那麽是无法从某乙的 口中获得任何的消息。但是当玩者从某甲的口中获得了「神出鬼没」这个关键字之後,在交谈的选单中就会出 现这个选项,选择後从某乙处就可以得到回应,也就可 以加入判乱组织了。这一种的交谈讯息结构,也就是关 键字系统真正能够发挥作用的地方。

    在设计关键字系统的时候有一件事要注意,那就是需要 适时的将某些没有作用的关键字关掉。就以上面的例子 来说,当玩者成功的加入了判乱组织之後,这一部份的 事件可以说是已经结束了,此时就可以将「口令」以及 「神出鬼没」这两个关键字关闭。不过若是这两个关键 字还有作用的话,就不可以这麽轻率的关闭它。

    说到这里也许有人会说其实这种剧情不需要用关键字系 统,就算是单纯的单句式结构就可以处理了。但是请各位 想想看,这里的剧情若是当玩者一和某甲交谈,某甲就将 所有的消息一股脑的都说了出来,那麽不是很没有 意思吗?除此之外,关键字系统在玩者被游戏卡 住的时候,还可以让玩者重复询问相同的关键字来获得讯息, 比起单句式结构那种不小心没有看到就会被卡住的情况来说, 是不是也显得比较人性化呢?

    前面所说的都是关键字系统的好处,但是为什麽目前的游 戏很少使用关键字系统呢?那都是因为要设计关键字系统的 话交谈的资料结构就绘变得比较复杂了。各位想想看,原本 在规划交谈的讯息资料时只要针对每个游戏 中的角色,配 合不同的剧情段落配上讯息就可以。但是在关键字系统中, 设计者必需要将关键字妥善的分配到
    各地的剧情对话中,才能使关键字系统真正的发挥作用, 因此在设计剧情的时候有比较多的困难。 除此之外,目前 国内的公司大多有将游戏推向国外的计划。由於中国字并不 是拼音系的文字,因此这些关键字 一但翻译成其它国家的 语言(像是韩文、英文等等)时,就会发生翻译出来的单字 变成好长一串的文字,若是 勉强的将一串文字删成适度的 长度时,又会有可能会文不对题的问题(这种情况就好像 魔法门三代中的问题被变成中文的问题那样奇怪),或是 因此要增加文字显示的区域。也因为这些原因,使得国内 的公司尽量的不去 碰这样的系统,以免自找麻烦。

    事实上关键字系统其实是个扩展性相当大的系统,就连游乐器的游戏中也曾经有采用过这样的系统。正因为它对於剧情的掌握比单句式的要强,以及它更结构化的 资料结构,它绝对是一个完美的交谈系统。

     

     

    10 完成制作的关键:推动力
    -------------------------------------------------------------------------------

    我最近听到一个说法:每开始制作50个游戏,最终只有一个游戏能制作完成。这个说法可以由几个原因来解释。制作者可能太超前了以致于在技术上完成不了;项目太复杂了或制作者们在协同工作时有分歧并导致开发停止。还有更多的原因显示了这种可能性:为什么98%的游戏不能最终完成。

    然而,我坚信以上的这些问题的影响都比不上在进度中失去推动力。成功的游戏制作者与失败的游戏制作者之间的区别并不是因为前一组成员更有才能,更聪明或更有经验。仅仅是因为前一组成员能完成他们的游戏。


    1.聪明,才智和经验
    聪明,才智和经验在你的游戏制作过程中和生活中将帮助你克服困难。让我们看看,简单地击键动作并不需要大脑的思考活动,但它需要一些你正在使用的计算机语言的知识,对操作系统的一些概念。大多数知识都能通过阅读帮助文件,相关的书籍,一些示例的源代码来获得,并且你并不需要透彻了解每样事件是如何运行的。

    举个现实生活中的例子,录像机有很多复杂的功能,你可能并不会用这么多的功能,但你仍能很好地使用录像机,使用遥控板上的放,前进,后退这几个键来操作就足够了。其它功能你并不需要掌握如何操作,那么你并不需要。编程也一样,做很多事情并不需要透彻地了解每个方面。当你进入一个新的领域,通常会阅读相关的资料来获得所需的信息。我学习一门计算机语言的方法是:简单地运行示例程序并不断地修改它,运行它,看看运行结果,来最终了解这种语言的。

    我并不暗示你不需要去努力学习,只是举例说明这些知识并不是决定性的。如果你不了解你的游戏软件和操作系统将怎样配合工作,那么你就需要去了解操作系统本身。尽可能多地去了解你的操作环境,直到你感到能够自如地工作,只会偶尔遇到几个问题时为止。


    2.麻烦和推动力
    社会的各行各业中,一个项目的完成都需要参与者的努力工作,项目完成所需的时间越长,人们就越可能会遇到更多的麻烦。游戏制作过程也不例外。

    游戏制作工业具有多变的本质,大众对游戏画面的要求,对某种游戏类型的喜爱,对游戏趣味性的要求,会经常发生变化。所以在制作期间及时了解业界的最新动态和互相交流是必须的。否则当你开始制作一个游戏,经历过一个较长的开发周期后,你制作的游戏可能已经落伍了。

    当你是独立制作游戏时,每次当你遇到一个问题时都可能会落入困境,特别是没有外部的支持时。制作中若有一个阶段达不到预期的目标,都可能会令你泄气。这对独立游戏制作来说是致命的。

    对不同的人来说,解决困难的动机是不同的。对有些人来说可能是需要成功以得到其它人的尊敬,或者得到一些报酬,金钱或其它形式的。对其它人来说,动机仅仅是一种创作自己心目中游戏的渴望。无论你的动机具体是怎样的,你都需要依赖它,在制作过程解决遇到的各项麻烦。忽视麻烦或中止开发一段时间,这简直和取消项目是一样的。所以制作者必须习惯于面对各类难题。

    保持推动力的一个方法是不断地尝试制作新的事物。每当你制作完成一个作品后,无论对你的自信心还是工作经验来说,都会更上一个台阶。如果你做了大量的工作但不能及时地看到结果,这会令你很不满意,并逐渐丧失推动力。如果你能及时地看到你的工作对作品的改变,那么制作人与作品之间的这种互动性很容易就能使你保持较高的推动力。这就是为什么强烈建议那些游戏制作的新人从一个小项目开始的原因。长周期的大项目往往需要一周或一个月的时间才能看到变化,这往往使新手变得沮丧,并最终不能完成他们的第一个游戏。


    3.中断一会
    在工作中适当地中断一会是十分重要的。如果你不适当地休息一会儿,你的注意力会渐渐变得分散,工作效率会下降。我曾看过关于注意力方面的研究报告,它指出大多数人在40分钟持续的做某件事后注意力将变得分散。很明显,每隔40分钟就休息15分钟将会浪费大量的时间。然而仅仅是去拿些饮料喝或去察看有没有新邮件到来,或者做任何别的事,都会帮助你长久地保持对工作的热情。

    在高强度的工作后,最好中断较长的一段时间。如果你遇到了一个特别困难的问题,那么最好在你开始工作前先休息一会,再解决它。短暂的休息能使你集中精力来工作,但是在你处理一件事的过程中最好不要中断,要一鼓作气。如果这个事件处理的过程很长,那么在完成一个阶段后再休息,并且做好中断点的记录,以便于下次能容易地接下做。当你在工作时,适当地中断一会对保持你工作的动力是很重要的。长时间的工作而不休息更有可能使你的游戏半途而废。

    现在来了解什么时候该休息,什么时候该继续工作。如果你处在一个工作气氛很浓的环境中,而且制作的进度很快,那么这时你最好尽你的所能持续地工作,把你所有的热情都投入其中,渴望产品的最终完成日。产品的最终完成日就像灯塔的顶部一样,在那里,你能够回想起你在制作过程中所有的努力。要记住,当你离开你的工作时必须确定,这个中断点在你回来后能够很容易地继续下去。这意味着如果你是一个程序员,若你的代码在编译时有一些错误,那么最好不要把这些错误留到明天再去解决,因为这会使你忘记是什么原因导致了这些错误。


    结论
    在你制作游戏时会遇到很多的障碍,你必须学会面对它们。推动力确实是完成你游戏的关键所在,要牢记,成功的游戏制作者首先必须先完成他们的游戏。

     

    11 十分钟学会 DirectX 中 的 COM 技术
    -------------------------------------------------------------------------------


    DirectX 是按照微软的COM(Component Object Model) 搭起来的。设计COM是希望它 能提供一个更安全,易升级,可移植的软件模块。COM用的面向对象的模式比一般的 C++更严格。例如,COM只能永远通过成员函数(member function)进行访问,并且不 能拥有公用数据成员(public data members)

    COM异常严格地对待对象(object)和接口(interface). 而且就不让你直接访问对象, COM竟然都不给对象起名字,让你老老实实通过接口来访问对象。在DirectDraw编程 中,我们讲:“访问对象”,其实都是在访问接口。叫惯了也就不改了。

    所有的COM接口都从 IUnknown 接口中派生出来。“I”打头是COM接口的标识(I for Interface). 所有的DirectDraw接口都以“I”打头,但莫明其妙的是在很多编程手 册中都把“I”略去。所以看书时要做到心中有爱(I)。

    IUnknown 接口提供三个成员函数,其余所有的COM接口,都继承这三个函数。
    AddRef()
    Release()
    QueryInterface()

    AddRef() 和 Release() 支持COM的一个特色功能,名字叫“活着封装”(lifetime encapsulation). “活着封装”是一个协议,用来让对象在崩溃时(destruction)自 己负责自己的后事。

    “活着的时候”(lifetime) 每个对象内部有一个值用来跟踪记载自己用过的指针(pointer) ,或引用(reference)。当这个对象建立时,该值为1。然后随着对它的调用/被调用, 该值递增。反之递减。当本身崩溃时(destroy itself),该值为0。

    AddRef()就是用来加计数器的。你可能不用亲自调用它。你在用DirectDraw API 时, AddRef()就被自动调用了。

    Release()则是对着干。减值。你常常要亲自用到它,因为程序可能会异常退出AddRef的 作用域(scope)。如出错控制中。

    QueryInterface()用来问COM一个接口是否可用。如可用,则返回一个相应接口的指 针。

    问对象是否支持一个接口用QueryInterface, 那么怎么问?当然要知道接口的ID。 我们用GUID来表示,GUID = Globally Unique IDentifier. (全局单一证认)。GUID是 一个128bits的数。所有DirectX中接口的GUID值都可在DirectX的头文件中找到。

    这就是全部了。怎么样,有概念了吧:-) he he he.

     


    12 windows 游戏设计时的单任务与多任务处理
    -------------------------------------------------------------------------------

    单 任 务 处 理

    Windows 最 杰 出 的 功 能 之 一 是 能 够 同 时 运 行 多 个 程 序, 但 有 时 也 会 让 人 感 到 头 疼, 特 别 是 对 于 那 些 习 惯 于 完 全 控 制 计 算 机 甚 至 时 钟 频 率、 非 常 自 信 的 游 戏 程 序 员( 当 然, 我 们 的 确 在 乎 那 些 没 礼 貌 的、 在 退 出 时 不 恢 复 正 确 的 系 统 时 间 的 游 戏。 但 是 幸 好, 现 在 我 们 可 以 忘 掉 这 些 了)。

    ---- 在 多 任 务 环 境 下, 游 戏 程 序 员 需 要 注 意 三 个 大 的 负 效 应:

    当 游 戏 失 去 焦 点 而 进 入 后 台 后, 其 执 行 不 得 不 被 挂 起( 可 以 在 Moby Dick Windows 中 使 用“ 中 止 的” 变 量 观 察 它 是 如 何 工 作 的)。 如 果 是 一 个 实 时 游 戏, 程 序 员 当 然 希 望 它 被 悬 挂。 但 在 回 合 制 游 戏 中, 当 玩 家 去 做 其 它 事 情 时, 程 序 员 可 能 不 希 望 计 算 机 一 方 作 任 何 动 作, 但 希 望 后 台 的 人 工 智 能(AI) 运 算 依 旧 执 行。


    其 它 的 任 务 占 用 CPU 时 间, 结 果 造 成 我 们 不 能 一 直 控 制 游 戏 中 事 情 发 生 时 的 速 度。 我 们 将 在 后 面 讨 论 这 个 痛 苦 的 问 题。


    每 当 游 戏 回 到 前 台, 程 序 员 不 得 不 重 画 游 戏 窗 口。Windows 并 不 负 责 记 忆 它 所 覆 盖 或 隐 藏 的 窗 口 的 内 容; 它 所 能 做 的 最 多 是 通 知 一 个 窗 口 需 要 重 画 其 客 户 区 域。 这 在 有 关 Windows 的 文 章 中 都 有 论 述( 参 见 WM_PAINT 的 内 容), 我 们 在 这 里 就 不 讨 论 了。 事 实 上,Moby Dick Windows 并 不 恢 复 其 自 己 的 窗 口; 我 们 将 在 讲 到 DirectDraw 下 的 双 缓 冲 时 看 它 是 如 何 实 现 的。

    程 序 中 的 多 任 务

    ---- 尽 管 Moby Dick DOS 在 使 用 中 断 处 理 程 序 时 展 示 了 内 部 多 任 务( 或 者 说 多 线 程) 的 一 种 原 始 形 式, 但 是 该 程 序 仍 然 没 有 突 破 DOS 的 单 主 题 特 性, 即 在 一 个 时 间 只 做 一 件 事 情。 有 些 DOS 程 序 的 确 作 到 了 真 正 的 多 线 程, 但 是 那 需 要 非 常 巨 大 的 编 程 工 作。Windows 95 SDK 使 这 项 工 作 简 单 了 许 多, 把 线 程 放 进 每 一 个 游 戏 开 发 者 的“ 锦 囊” 之 中( 如 果 读 者 还 不 熟 悉 这 个 概 念, 那 么 简 单 说 明 一 下, 一 个 线 程 就 是 程 序 的 一 部 分, 它 执 行 时 独 立 于 其 它 的 部 分, 并 且 不 需 要 与 其 它 部 分 同 步。 线 程 不 是 由 中 断 来 驱 动 的; 它 们 只 是 在 每 一 次 Windows 给 它 们 CPU 时 间 时 继 续 其 执 行。)

    ---- 在 下 列 情 况 下, 可 能 要 考 虑 实 现 独 立 的 线 程:

    允 许 后 台 AI。 就 算 是 用 户 正 忙 于 来 回 移 动(moving pieces around)、 打 开 对 话 框 等 事 情, 计 算 机 也 能 够 考 虑 其 下 一 步。 处 理 这 类 线 程 非 常 方 便, 因 为 它 不 需 要 与 其 它 的 事 情 同 步。


    预 先 加 载 数 据。 例 如, 当 玩 家 正 努 力 向 下 一 级 奋 斗 时, 使 一 个 线 程 负 责 读 取 文 件 并 准 备 好 游 戏“ 世 界”。


    给 予 时 间 紧 迫(time-critical) 的 任 务 优 先 权。 我 们 将 在 后 面 会 到 这 个 主 题。

    游 戏 循 环

    ---- 游 戏 循 环 的 概 念 在 各 编 程 环 境 下 都 比 较 相 似。 第 一 步, 需 要 获 取 输 入: 可 以 是 轮 询 它, 等 待 它, 或 者 在 它“ 运 行” 时 通 过 中 断 或 一 个 消 息 队 列 拦 截 它。 第 二 步, 处 理 该 输 入, 并 且 把 它 变 成 一 个 在 游 戏 中 有 实 际 意 义 的 动 作, 如: 使 飞 机 倾 斜 飞 行 或 小 卒 向 前 走 一 步。 然 后, 把 结 果 显 示 出 来。 当 然, 在 这 个 主 题 中 也 要 求 精 雕 细 刻 和“ 变 奏 曲”, 包 括 计 算 AI 的 移 动、 把 控 制 权 从 一 个 玩 家 移 交 给 另 一 个 玩 家、 检 查 胜 负 等 等。

    ---- 然 而, 在 Windows 和 DOS 下 实 现 循 环 的 机 制 迥 然 不 同。 每 个 Windows 程 序 都 建 立 于 一 个 消 息 循 环 之 上。 尽 管 一 个 游 戏 循 环 可 以 建 立 在 消 息 循 环 之 上, 但 是 这 两 者 仍 有 本 质 的 差 别。

    Moby Dick DOS 的 循 环

    ---- Moby Dick DOS 演 示 了 一 种 简 单 的 游 戏 循 环, 在 这 里 我 们 所 做 的 工 作 是: (a) 检 查 是 否 有 什 么 东 西 要 移 动, (b) 移 动 它, (c) 显 示 结 果。

    while (!gamedone)

    //调用时间程序 -如果时间未到,则没有任何响应。

    AhabMoved = Move_Ahab();

    //仅当 Ahab没有移动时移动 Moby Dick。

    //否则它们可能擦肩而过却不能拦截。

    if (!AhabMoved) Move_Moby();

    //如果有任何一个移动,更新屏幕,

    //并检查是否有胜利和失败。

    if ((MobyX != OldMobyX) || (MobyY != OldMobyY)

    || (AhabMoved))
    {
    UpdateScreen();

    if ((MobyX == AhabX) && (MobyY == AhabY)


    && (painted[MobyX][MobyY]))
    {
    gamedone = 1;

    cprintf("/a");

    cprintf("You win!");

    }

    if (TimesUp <= 0) { cprintf("/a"); cprintf("Time's up!"); gamedone="1;" } if (raw_key="=" MAKE_ESC) { gamedone="1;" progdone="1;" } } //结束更新 } //结束游戏内部循环 (while !gamedone) Moby Dick Windows的循环 从表面看来,好像没有多大的差别: do { if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) { if (msg.message="=" WM_QUIT) break; //唯一的退出循环的出口。 TranslateMessage(&msg); DispatchMessage(&msg); } else { if ((MobyX !="OldMobyX)" || (MobyY !="OldMobyY)" || (AhabMoved)) { UpdateScreen(); if ((AhabX="=" MobyX) && (AhabY="=" MobyY) && (painted[AhabY][AhabX])) { Control="MessageBoxEx(hwnd," "You caught Moby! Play again?", "Call Me Ishmael", MB_ICONQUESTION | MB_YESNO, 0); if (Control="=" IDYES) InitializeGame(); else break; } } //如果有人移动了 } //如果屏幕已更新 } //结束循环 while (TRUE);

    ---- 前 面 已 经 提 到 过, 这 里 没 有 检 查 是 否 运 行 超 时, 请 忽 略 它, 笔 者 在 Windows 版 中 未 实 现 它 是 为 了 避 免 令 人 烦 恼 的 中 断。 中 断 并 退 出 无 限 循 环 的 机 制 有 一 点 儿 而 且 并 不 重 要。 我 们 把 精 力 集 中 在 消 息 循 环 本 身, 所 以 把 其 它 的 无 关 代 码 都 删 掉, 只 留 下 最 基 本 的 部 分:


    do

    {

    if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))

    {

    if (msg.message == WM_QUIT) break;

    TranslateMessage(&msg);

    DispatchMessage(&msg);

    }

    else DoSomething();

    }

    while (TRUE)


    ---- 这 是 一 个 非 常 典 型 的 消 息 循 环。 唯 一 有 点 特 殊 的 地 方 就 是 它 使 用 的 是 PeekMessage 而 不 是 GetMessage。

    GetMessage 与 PeekMessage 的 比 较

    ---- 为 什 么 要 用 PeekMessage 呢 ? 原 因 很 简 单,GetMessage 等 待 一 个 消 息( 就 像 _getch), 而 PeekMessage 不 是 这 样( 就 像_kbhit)。 请 考 虑 下 面 的 循 环:


    while (GetMessage(&msg, NULL, 0, 0))

    {
    // 我 们 并 不 进 入 括 号 内 部, 直 到 有 一 个 消 息

    TranslateMessage(&msg);

    DispatchMessage(&msg);

    DoSomething()

    }

    // 当 GetMessage 返 回 NULL 时, 退 出 该 程 序

    return msg.wParam;


    ---- 在 这 里,DoSomething 不 会 完 成, 除 非 一 个 消 息-- 或 许 多 消 息-- 被 放 入 队 列 中 并 被 处 理。 如 果 DoSomething 恰 好 产 生 一 个 消 息, 例 如, 如 果 它 更 新 了 屏 幕 并 且 因 此 而 产 生 了 一 个 WM_PAINT 消 息, 那 么 好 了, 水 泵 注 水 后 将 开 始 启 动 了。 要 使 DoSomething 可 靠 地 完 成 其 工 作, 这 并 不 是 一 个 好 方 法, 它 使 代 码 有 点 混 淆, 但 它 工 作 的 还 不 错。

    ---- 相 比 之 下,PeekMessage 则 无 论 是 否 有 消 息 在 等 待, 只 要 检 查 一 下 消 息 队 列 就 完 成 其 操 作(yields the floor)。 在 我 们 的 例 子 中, 我 们 实 际 上 是 使 用 PeekMessage 来 处 理 消 息 的( 通 过 分 发 它 所 找 到 的 每 一 个 消 息 并 使 用 PM_REMOVE 参 数 从 队 列 中 清 除 它)。 同 下 面 同 样 有 效 的 代 码 相 比, 它 要 更 加 直 接:


    if (PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE))

    {

    if (!GetMessage(&msg, NULL, 0, 0)) break;

    TranslateMessage(&msg);

    DispatchMessage(&msg);

    }

    else DoSomething();


    ---- 在 这 里 有 非 常 重 要 的 一 点 要 说 明, 我 们 的 伪 代 码 DoSomething 是 独 立 于 消 息 的; 无 论 队 列 中 送 出 的 什 么 消 息, 甚 至 无 论 有 没 有 消 息 在 那 儿, 它 都 将 执 行。 在 Moby Dick 中, 我 们 将 屏 幕 更 新 和 胜 利 条 件 的 检 查 放 在 这 里, 因 为 在 这 里 检 查 一 个 或 多 个 消 息 被 响 应 后 是 否 需 要 更 新 屏 幕 或 是 否 达 到 胜 利 条 件 很 方 便。

    ---- 那 么, 消 息 循 环 就 是 游 戏 循 环 吗 ? 从 抽 象 的 角 度, 是 的, 因 为 它 是 大 的 齿 轮, 带 动 那 些 小 的 齿 轮。 但 是, 尽 管 把 一 些 函 数 调 用 放 在 此 处 可 能 比 较 方 便,Windows 编 程 规 则 却 要 求 任 何 响 应 一 个 消 息 的 动 作 都 应 该 放 在 消 息 响 应 程 序 中( 就 是 说, 放 在 窗 口 过 程 中)。 在 一 个 实 时 游 戏 中, 绝 大 多 数 的 动 作 发 生 在 一 个 或 多 个 WM_TIMER 消 息 响 应 程 序 中。 回 合 制 游 戏 则 常 常 在 输 入 消 息 的 响 应 函 数 中 做 大 量 的 工 作。

    ---- 事 实 上, 程 序 员 经 常 会 发 现 在 主 消 息 循 环 内, 除 了 标 准 的 翻 译 和 分 发 消 息 任 务 之 外 什 么 事 情 也 没 做。 如 果 这 样, 就 可 以 回 过 头 来 使 用 GetMessage, 因 为 除 了 响 应 消 息 之 外, 什 么 事 也 不 需 要 发 生。

    ---- 总 结 一 下, 实 现 循 环 有 两 个 关 键 点:

    Windows 消 息 循 环 与 游 戏 循 环 不 相 同。 游 戏 循 环 依 然 存 在( 至 少 在 概 念 上 如 此), 但 是 同 DOS 下 的 情 况 相 比, 它 的 部 件 在 代 码 中 更 加 分 散。


    如 果 想 要 在 消 息 循 环 内 执 行 任 何 独 立 于 时 钟 消 息 和 输 入 消 息 的 代 码, 请 使 用 PeekMessage 而 不 是 GetMessage。

    展开全文
  • 收集傻瓜式游戏制作软件(目前还在更新中)

    万次阅读 多人点赞 2013-01-28 11:26:44
    傻瓜式就是对于没有编程能力但又想制作游戏的人而言的,废话不多说,一一列出我目前搜集到的游戏制作软件: 1、RPG Game Maker(RPG制作大师) RPG制作大师顾名思义就是制作RPG的软件,目前流行的是RPG Maker XP ,...

    傻瓜式就是对于没有编程能力但又想制作游戏的人而言的,废话不多说,一一列出我目前搜集到的游戏制作软件:

    1、RPG Game Maker(RPG制作大师)

    RPG制作大师顾名思义就是制作RPG的软件,目前流行的是RPG Maker XP ,RPG Maker VX 。两款RPG制作软件都有自己不同的风格特点。这两款软件能使不懂编程的人也能做出精美RPG及其他类型游戏的优秀软件,当你制作完游戏后可以打包给其他人人玩,这样没有安装 RPG Maker XP/RPG Maker VX (以下简称RMXP/RMVX)的人也能在电脑上也能运行,你说这是不是很不错! 这两款RPG制作软件都是由Enterbrain Incorporation公司出品的RPG游戏制作工具。下面来介绍下两款RPG制作大师的特点。----百度百科

    该软件的国内一大论坛是66RPG,要学该软件,必上66RPG,哈哈


    RPG游戏大师












    2、The Games Factory(游戏工厂)
    法国开发团队“Clickteam”创造。TGF的制造目的是让使用者用简易地编写游戏,因此在编写游戏过程里不需要用编程语言。Clickteam也创作了Multimedia Fusion,和TGF相似。----维基百科
    目前版本为2,官网地址:
    http://www.clickteam.com/website/world/


    3、Soul Game
    Soul Game(简称SG)是由灵魂代码工作室历经多年打造的一款简单易用的游戏制作软件,无需专业知识,通俗易懂的操作界面,比RM更佳容易上手,让你一目了然;只需导入素材,即可生成多种类型ARPG\RPG\横版\回合制等,网络游戏和单机游戏皆可以制作,多种制作多种玩法的游戏,让你的游戏决不单调。
    4、Action Game Maker 
    Enterbrain Inc. (RPG Maker的东家)自豪地宣布了在 Windows 平台上的最新最好用的游戏制作工具 —— Action Game Maker 的正式发行。它是在全球风靡二百万拷贝的游戏制作大师系列的延续。继在 RPG Maker XP/VX 上取得成功(尤其是拥有大量「欧美风格控」玩家的青睐)之后,Action Game Maker 作为公司的易用、「即点即拖即可制作游戏」的软件,扩展了多种游戏格调,同时支持三种类型的动作游戏的混合制作,成品游戏可以导出为 Windows 独立程序以及额外支持的 XNA (Xbox 360) 和 Adobe Flash 格式。基于内建的、可供分析观摩的范例游戏,你不需要具备任何与编程、图像合成相关的知识便可以制作经典的2D 动作游戏,左右平台闯关、上下 ARPG 、四方向射击游戏都随你便!使用可以进行简单调整的、基于流程图进行层次呈现的用户界面,更不用说标题画面了,对新手来讲直接制作游戏几乎是一马平川!尤其是软件自带的强大的动画编辑器,以及基于图砖的布局设定,还有混合多种游戏类型的能力,更能使得你作出更加出色的游戏!你可以在一个游戏中混入各种格调,你想搞穿越几乎没有问题。
    5、2DFM(2d ftg game maker)
    的全称是“2D格斗游戏制作工具2nd”。它是由日本OUTBACK制作、EB发行的一款2D格斗游戏制作工具,软件运行于PC平台。利用这款软件玩家可以独力制作出属于自己的格斗游戏——内地玩家morley制作的《KOF历代BOSS大乱斗》、《3Fighters》;日本玩家制作的《格斗变人》;台湾TEAM FK小组制作的《超级COSPLAY大战final02版》这些游戏都是用2DFM开发完成的!----百度百科
    6、恋爱游戏制作大师
    (又称恋爱模拟共和国)是由日本Enterbrain公司开发的一款冒险游戏制作工具,最大的特色就是使用GUI图形界面大幅降低游戏制作的程序技术,同时内建大量图片素材,让使用者可以简简单单按几个按钮就可以制作出自己心目中的AVG游戏。由于其上手简易的特色,成为华文地区同人游戏制作的主流工具。

    “恋爱游戏制作大师”是可以让玩家亲手制作恋爱模拟游戏的一款游戏制作工具。恋爱模拟游戏是从冒险游戏的其中一种进化而来,玩家扮演男性角色,与不同的女性角色邂逅,交织出引人入胜的动人故事,在游戏中可充份体验与享受恋爱中酸甜苦辣的真实情绪。前作“恋爱模拟共和国”自从2000年推出中文版,已经让许多玩家利用这款制作工具体验投入游戏创作社群的趣味经验,并藉由网路分享彼此的作品,形成一股不可忽视的创作新势力。但是随着时间的延续最让人头痛的事情也就出现了。避免不了的有黄色和色情的东西沾染其中.-----百度百科
    7、脚本游戏制作大师
    Edgame Maker(简称E.M).是一款独立游戏制作软件,是为想真正自己创造游戏,又因为各方面原因,不适合学习C/C++这种较专业的计算机编程,或是觉得市面上目前的游戏制作软件无法满足需要的朋友出现的.采用Lua脚本驱动,外接插件模式.极大的降低了业余游戏制作门槛,你可以制作做出你希望的任何2D游戏,包括网络游戏.目前仅支持2D游戏制作.

    8、Construct 2
    这是一款真正的理论上不需要任何编程知识可以方便做出任何形式的游戏的次世代工具
    下载地址

    http://www.scirra.com/construct2
    这个软件是免费的。做出来的游戏可以发布到所有平台。主要包括pc,ios,andriod,win8
    这个软件实际输出是html5可以发布到
    http://www.kongregate.com/
    如果是发布手机版。只需要通过
    https://build.phonegap.com/
    这个免费业务即可
    很方便的嵌入admob广告插件后,便可以赚钱了。不过注意,如果不想用破解版是不能发布的哦。需要79欧元。

    最后,介绍给大家一个交流的平台。
    qq群
    284921272

    大名鼎鼎的Hitpoints公司(发布了各种类型游戏制作软件)的游戏制作软件,下面附上Hitpoints公司官网,懂日文的童鞋猛击吧:

    10、Game Maker
    GameMaker 是一款拥有图形界面,可灵活编程,以2D游戏设计为主的游戏开发软件。本软件由 Mark Overmars 使用 Delphi 语言开发,于 1999 年 11 月发布了首个公开版本,在 4.3 版之后转为部分功能收费软件。后由英国公司 Yoyogames 收购,大力推动了欧美乃至全世界独立游戏界的发展。目前最新版本为 Game Maker 8.1。

    11、吉里吉里
    (英文缩写名称叫“KRKR”)是一款用于制作AVG、美少女游戏、视觉小说的游戏制作工具。
    由这款软件制作出的非常有名的一个游戏是:《FATE/STAY NIGHT》,是由日本TYPE MOON公司于2004年1月30日发售的PC平台文字冒险游戏。该游戏一经出品,立刻广受恋爱游戏FANS们的推崇,当年即荣登日本Getchu销售榜榜首。想了解KRKR软件的人,先去玩一玩这款游戏便会对KRKR有一个笼统的认识。
          
    又称T Visual Presenter(简称TVP),是一个由W.Dee氏所开发的同人游戏制作工具,以物件导向语言TJS做为底层开发,外包上KAG的Script语法让一般使用者使用,要使用吉里吉里只需要准备好文字编辑器(如记事本),就可以直接编写剧本。吉里吉里在处理2D图形上极为强大,支持的图像、音乐格式也是目前同人游戏工具中最多的。他让使用者可以很方便地整合图像、音乐、动画、文字剧本,使用者可以专注在游戏本身而不需要花费太多精神在程式码上。
    吉里吉里的本体采用GPL许可证,使用者不需要负担任何费用即可利用吉里吉里来开发游戏,包括免费、共享或是商业游戏,吉里吉里与NScripter并称为两大同人游戏工具。
           KAG3
    KAG为Kirikiri Adventure Game的简称,是吉里吉里中以TJS2定制的用于冒险游戏设计的系统,包括自定义的一套命令语法(Tag、タグ),使用方式与BBCode(或Html)极为类似,吉里吉里内带的tag命令已经包含所有2D圆形处理、音乐影像处理,仅使用KAG就可以编写出一套AVG游戏。
    使用KAG语法撰写的档案,副档名为.ks,可用记事本开启。
          TJS
    TJS2为吉里吉里的内嵌脚本语言,目前最新版本为TJS2,TJS是界与JAVA与JavaScript之间的物件导向程式语言,也是由作者W.Dee氏自行定义的程式语言,作为吉里吉里底层开发语言。由于KAG是利用TJS语言所编写,因此使用者可以透过修改或重新编写TJS档案,去扩充KAG的功能。
    使用TJS语法撰写的档案,副档名为.tjs,可用记事本开启。

    12、Dreamloader

    dreamloader属于免费系列软件 是一个面向独立开发的游戏制作工具
    ●面向独立开发者应用 简洁界面 简洁操作
    ●十大主要核心编辑器模块 包含所见即所的图块 动画 路径 物体等编辑器 制作流程一步到位
    ●gamemaker类的设计模式 很多概念来自GM
    ●内置代码编辑器 支持语法高亮等 考虑加入代码自动完成等
    ●自由度高的模板系统 支持不同类型游戏制作 第一个版本会出RPG制作整合包
    ●大多操作只需使用提供的整合包 简单修改参数 不需要接触脚本
    ●更深层接触DML后可自行编写脚本逻辑
    ●AI整合(版本不同 不同扩展包中附带各类基础AI 如寻路等)
    ●内置动态2D光源系统
    ●支持透明通道图形 如png的一键导入
    ●附带支持可定义路径和声效的粒子编辑器
    ●支持电影情节模式编辑 有可能会加入数据库操作功能
    ●考虑加入局域网功能
    ●考虑引入中小规模的网游制作模式
    ●整合PhysX2D物理系统
    官方网站:http://www.dreamloader.net/
          -----百度百科
    13、忆游横版游戏制作软件
    忆游横版游戏制作软件(忆游play)可以让用户可以加载素材按自己的意愿安排游戏角色制作2D横版游戏,不需要任何编程基础和脚本知识,完全鼠标拖放操作。

    忆游横版游戏制作软件是C#语言编写的基于.NET Framework 2.0的Winform程序,
    运行忆游play需要安装.NET 2.0或以上。


    14、Game Creator
    使用iOS设备制作游戏的最简单最便捷的方法,无需编程,只要很简单的拖拽和想象力就可以制作各种好玩的游戏。

    15、3D Game Studio

    是用于制作2D和3D游戏的游戏制作软件,对于业余爱好者来说,用该软件可以在几个小时内就制作出动作游戏或赛车游戏。

    下面附上该软件的官网链接: http://acknex.com/






    展开全文
  • 如何完成一款游戏? | 独立游戏制作

    千次阅读 2015-06-06 17:46:51
    文章来源:Make Games,作者:Derek,游戏葡萄原创编译,转载请注明出处。 本文是一位独立游戏开发者Derek发布在自己的博客Make Games上的文章,结合自己的开发经历,和大家分享了一些自己的思考。 对于很多...
  • Game4You是一款免费的游戏制作应用程序,允许你用你自己的照片创建第一人称游戏,并添加音频文件和文本。您可以自定义敌人的数量和游戏世界的规模。有需要的朋友们可以下载试试吧! Game4You适用于: 与你的照片和...
  • 如何开发一款游戏游戏开发流程及所需工具

    万次阅读 多人点赞 2018-01-16 08:48:17
    本文来自作者 goto先生 在 GitChat 上分享 「如何开发一款游戏游戏开发流程及所需工具」,「阅读原文」查看交流实录。「文末高能」编辑 | 哈比游戏作为娱乐生活的一个方面,参与其中的人越来越多,而大部分...
  • 游 戏 制 作 之 路

    千次阅读 2009-11-11 17:43:00
    设计制作电脑游戏这一行,可能是当今世界上能够找到的为数不多的迷人工作之一。在高科技的不断带动下,她让你充分享受创作和玩耍游戏的乐趣。而像id Software 这样一夜成名的传奇经历,更让成千上万想要成为游戏...
  • 游戏开发入门(十一)游戏引擎架构

    万次阅读 多人点赞 2018-03-03 11:22:29
    链接:游戏开发入门(十一)游戏引擎架构(8节课 时常:约2小时40分钟) 该堂课是对游戏引擎内容的一个概括总结,同时也是对游戏开发技术的一个相当全面的总结。 正如我在开篇所提到的,游戏引擎架构的学习有助于...
  • 写在前面:对于挂机游戏的概念这里不作赘述和定义,本文翻译所指的是idle game,直译应当是闲置类游戏或者放置类游戏,不过个人感觉与其翻译成放置类游戏制作工具或者放置游戏制作工具,还不如直接就叫挂机游戏制作...
  • 一方面,从技术上来说,如今的游戏制作门槛越来越低已经成为不争的事实。Unity3D、Cocos2dx这样简单易用的引擎让很小的团队也能做出精彩的游戏。另一方面,行业内频传的诸如A团队月流水达到数百万,B团队又被数亿...
  • 下面为大家整理了H5游戏制作教程。  H5互动游戏制作方法是怎样  如果想要在微信公 众平台里制作H5小游戏,可以参考以下操作:  ①申请一个微信人家营 销平台帐号,点击绑定公 众 号。  ②用...
  • 记得还是小时候幼儿园就开始玩游戏的吧。 第一款游戏
  • 傻瓜式游戏制作详解

    千次阅读 2012-12-27 08:20:09
    需用Construct 2工具 一、新建工程 打开Construct 2,可以看到很熟悉类似微软office风格的...使用Construct2里的Tiled Background对象(背景瓦片相信大家都很熟悉,RPG游戏制作大师系列的地图元素,通俗点,就是一
  • 扫雷游戏制作全过程00

    千次阅读 2012-01-07 14:35:13
    到今天为止,扫雷游戏刚好做了一个礼拜。也算基本成型了。由于初涉编程,在这个过程中犯了很多很多错误。 于是在此用一周的时间总结一下。希望无论对于自己还是像我一样的新手能够有所帮助。 第一篇目前版本的演示...
  • Win32游戏制作之---Bizzard

    千次阅读 2016-06-12 17:11:01
    之前写了一片关于游戏引擎设计的文章,今天就用游戏引擎来实现一个小游戏(其实很准确的说是一种场景),主要就是为了感受游戏引擎给游戏设计带来的便利,而并不是游戏本身,使用游戏引擎之后你会发现,游戏设计会...
  • 简单的酷跑游戏制作思路

    千次阅读 2016-12-27 18:17:59
    酷跑游戏是比较简单的,一个好的酷跑游戏,主要在于游戏场景的色调配置,以及动画制作的效果。酷跑游戏的简单的说就是手势的检测。 下面是我的在游戏物体上绑定的两个脚本对手势检测的脚本using UnityEngine; using...
  • 版权所有。所有权利保留。 欢迎转载,转载时请注明出处: ... ...本人做过几个安卓小游戏,从游戏的制作过程中,总结了一些经验,现在跟大家分享一下。...游戏制作很简单,一般不用xml文件,只需在游戏的Activity内放一
  • 一个简单的U3d生存游戏制作

    千次阅读 2017-06-05 14:05:41
    这篇博客主要是我制作游戏的过程和总结,首先声明此游戏并非我... 开始制作游戏,首先说一下,这款游戏为一款生存游戏,主要是系统有寻路系统,兵营系统,攻击系统和地图系统,涉及的UI制作比较多,利用unity自带的U
1 2 3 4 5 ... 20
收藏数 130,786
精华内容 52,314
关键字:

游戏制作