如何15步制作一个roguelike游戏

先附上原文链接和原文，有空慢慢翻

-------------------------原文链接--------------------------------------------------------

How to Write a Roguelike in 15 Steps

 ---------------------------------------------------------------------------------------------

另推荐一个好游戏

The Temple of Torment

---------------------------------------------随手翻译分割线---------------------------------

第一步下决心写游戏

大部分人都会迈出这一步，但是这个第一步也是要遵守基本法的。最重要的开发一个你自己的roguelike游戏的理由是“你自己乐在其中”。

不要到处去问人家roguelike游戏的定义—你不需要知道。如果你做的游戏在别人看来根本不是roguelike但是你还是乐得其在—你是成功的。这又不是什么游戏开发大赛。

别做太多计划。当然了，如果你有一些特别的想法，你应该把它写下来以预留空间—但是别指望能够实现所有的想法—这是不可能的。当你写文档时，你会做一大堆的决定性的设计。但是大部分的决定性的设计在经过足够的测试和写一些包含这些设计的小程序进行验证前是不现实的。只有当你达到了一个里程碑时你才应该做这些决定，那时你不需要再增加额外的代码了，因为你的工程已经包含了你所有想要的。

跟着感觉走是有趣的，给自己留下一些自由发挥的空间吧。别去担心出错或者让程序可变性变差，如果有需要你完全可以到时再改嘛，而大部分情况下，这没啥大不了的。

（欧美人还真是随性啊。。。难怪他们永远做不出任天堂式的设计精巧的箱庭游戏。。。都这么干活的？）

第二步 Hello World

准备好你的编程环境。编程语言，平台，编译器和解释器，文本编辑器，版本控制软件，自动化构建工具，以及其他杂七杂八的东西。把他们折腾好让你能够舒舒服服的开始编程。

决定要用什么lib库，当然了这以后是可以变动的，但是相信我那会很痛苦滴。别担心太多可移植性的问题，船到桥头自然直。多关心关心你想要什么趁手什么吧。

决定用什么语言写注释和变量名，强烈推荐英文--因为这样你会获得更多人的帮助。（说的太好了，我选择拼音）

别担心国际化的问题，翻译问题在开发中是非常靠后的步骤。

写一个简单的hello world! 程序并测试它是否工作良好。测试你的lib库，范例—你不会想要什么惊喜的对吧。

现在开始编程吧。

第三步是个男孩！（这么翻没错吧。。。）

从屏幕输出和键盘输入开始。决定屏幕布局的最上层（以后你还可以改的）并且编程绘制地图字符，状态栏和信息栏

编程识别键盘按键（暂时不需要配置表和按键设定）

做一个@在空空如也的屏幕中走来走去。玩一会儿吧，想象你的游戏已经完成了（神经病呢？）

写信息显示函数---尤其是debugging信息—他们会很好使的。

第四步地图

决定你的地图生成机制。不用包罗万象—你以后还可以扩展。让你的空地图显示在屏幕上。如果需要可以加上滚动效果。加入一些元素看看它们显示的正不正常（直接硬编码就行了，你现在还不需要一个关卡生成器）

让你的@显示在地图上--不是作为主角，只当个光标使。测试地图滚动，如果学有余力，可以实现下’look’的功能。（你执行了’look’：看到一只猴子拿着一个玉佩）

现在让@回归主角的功能，你现在依然没有时间实现太多功能，只是让主角响应键盘在地图上走来走去而已。加入对墙壁的检测代码，有余力的话可以加入开门命令。

第五步保存和读取

（事先说明一下，其实你可以完全没有保存和读取，早期的很多roguelike游戏就没这功能，他们随机生成地下城而不是将它们写在源码里，其实这样更加roguelike！）

从文件中而不是硬编码中读取地图，如果你在一开始用一种可阅读的方式制作地图，你可以做做玩并用不同的配置方式进行尝试。

增加’保存’命令并实现其功能-首先是地图，然后循序渐进的加入其他的游戏元素。从这一刻起，你加入一些新的游戏元素时，就有马上实现他们的保存。

这里有一篇如何实现文件保存的文章 (handy article);建议读一读。

既然你实现了文件读写，你就可以写你的配置文件和按键设定文件了。再次提醒：最好把他们写成可读的文件，可以给你省不少事儿。

现在，当你不清楚游戏里的哪些元素出了问题时，你就可以保存游戏并在保存文件里去检查它们。

第六步It's alive! Alive! （你以为你是弗兰肯斯坦么。。。）

实现其他的生物（怪物）和时间流逝功能。首先加入一个怪物。赋予它简单的AI（例如说话，等待，或者是随机移动）

从回合制开始，然后实现你想要的时间系统（或者是实现一个预期的简化版本然后在之后将其进行完善）

（注意：如果你用了lib库，可以很容易的实现Dijkstra Maps （The Incredible Power of Dijkstra Maps），你还可以看看这篇文章Dijkstra Maps Visualized）

记住要做好测试再进行下一步哦。

第七步 交互

为你的生物们增加状态，一般情况下先实现一个你的预想的简化版本。最好是在需要的时候加入这些状态，而不是你觉得他们看上去很coooooooooooooooooool,但是你绝对不会忍住的J。

让这些生物注意到彼此，实现碰撞，攻击等等功能。逐渐的增加他们的AI，这样他们就会来追逐你（来追我呀~）

实现和测试战斗系统—当然现在是没有装备的。现在硬编码数值就可以了。做大量的测试吧。

第八步 数据文件

将生物，地图特征以及诸如此类的东西移动到数据文件中。如果有的东西移不进去，暂时忘了它吧。。。

（注意：这一步跟翻译没什么关系。你可以在这里借机整理你的代码让以后添加新的居民或地图元素更加容易）

第九步 物品

增加物品。一开始只需要添加那些你可以捡起的物品—没有所属。逐步的赋予它们所属，类型，状态，诸如此类。实现物品清单，捡起和丢弃，装备和使用（虽然现在毛作用没有），如果需要还可以实现物品的堆叠和容器之类的功能。

这一步需要大量的测试以达到平衡。

第十步 魔法

加入物品特效，特殊怪物攻击，魔法值。把它们加入物品和怪物以测试。你不需要一下子实现所有可能的效果，只需要加入下一步需要的效果就够了

第11步简单游戏

努力的去完成一个简单，硬核的游戏。玩它并且把它推荐给你的朋友。测试你到现在为止实现的构成。看看这个游戏是否好玩。改变你需要改变的。不要忘了进行大量的测试。不断地让人去尝试这个游戏的“亮点”，或者你自己每隔一段时间去尝试。时间太短有的东西是很难察觉的。

这一步会花费很长的时间，直到你获得一个有可玩性的有趣的小游戏

第12步 关卡

写你的关卡生成器。实现关卡和关卡之间的移动功能，实现野外以及城镇（如果你想要的话），如果你需要的话，将关卡存储成文件，这样他们就永远存在了（还不占用内存）。

把怪物们散布在不同的层数。加入更多的怪物和物品，如果需要，加入不同的效果

第13步经验值

开发你的经验和技能系统。调整怪物和物品的属性。制作角色生成界面，职业，种族和其它一切你想要的东西。

经常性的玩和测试你的游戏。

第14步村民们

加入NPC们，店主，如果你喜欢，加入简单的任务系统。持续性的加入特性并且调试属性

第15步随心所欲的去干吧

加入和测试任何你觉得cooooooooool的“独特”特性

数月（年？）之前，当你开始这个项目时，还记得你的那些神奇的主意么？它们还适合这个游戏么？

写下你的宠物随机生成系统，派系系统，无限的野外生成器，神经元AI（？？？这是要做天网么），或者其他独特的特性，现在你可以在一个可以运行的游戏里尝试它们了。

-----------------------------------------------原文分割线---------------------------------

This is a rough route map for the creators of roguelikes. I'm well aware that there are many possible routes and that no two journeys are the same -- this is a description of one of possibilities and maybe will help you to plan your own. 

Please add your comments -- maybe we could make this article really helpful.  What are your own routes? 

•  There is a school of thought in programming that data structures are more important than code: once you have the data structures right, the code will be self-evident. It may be useful to think before embarking about how you want to structure spatial information, a list of map tiles and their properties, character information, monster/NPC information, and information regarding objects and marks/sound/scent/footprints or tracks on the map (if at all). Cases where these types of decisions may become significant include conflict between monsters/NPCs, invisibility, flying, falling, gradients (like climbing hills), line of sight, transmogrify (becoming another being), save/restore, any situation in which map tiles are modified (burned, tunneled, teleported, melted, duplicated, scorched, etc.), and area transitions. Overground/wilderness areas often present different requirements to traditional dungeons. pratyeka

Step 1 - Decide to write a game 

Most of you will have this step behind you already, but there are some hints about the direction of the first step. The best reason to start developing your own roguelike game is to create a game that you will enjoy playing yourself. 

Don't start by asking around about the definition of roguelike game -- you don't need it. If the game you write is not considered roguelike by others, but it's still fun to play for you -- you succeeded.  It's not like there's some kind of a contest to write a game meeting certain specifications. 

Don't plan too much. Of course, if you want certain things in your game, you must write it so that there is room for them -- but don't even try to anticipate everything -- it's just impossible.  When you write a design doc, you make a lot of decisions. Most of the decisions can't be made without performing some test first -- usually by writing small programs utilizing given feature. It's best to make the decisions when your project has already reached appropriate stage -- when you don't need to write an additional program, because your project already has everything you need. 

It's no fun to just proceed according to plan -- leave some space for improvisation. Don't be afraid about making mistakes or implementing something in an inflexible way -- you can improve it when you need it -- most of the time it will be ok. 

 Step 2 - Hello world! 

Prepare your programming environment. Choose your language and platform, choose appropriate compilers/interpreters, editor, version control, automated build, and other utilities. Set them up so that you're comfortable with them.  

Decide on which libraries you're going to use -- it can change later, but it's usually a painful change. Don't think too much about portability -- it can be fixed later. Think about what you need and what you're comfortable with. 

Decide on the language you want to write comments and object names in your code, as well as the language you want to be used in your game. It's strongly recommended to use English in your source code -- you can get more help this way from others. 

Don't worry about i18n yet; translation is usually a very late step in the development process. 

Write a simple 'Hello world!' program and test whether it works. Test your libraries, etc. -- you don't want any surprises. 

Start coding. 

 Step 3 - It's a boy! 

Start with screen output and keyboard input. Decide preemptively on your screen layout (easy, you can change it later) and make the routines that display map characters, status lines and messages. 

Make the routine to read key-presses (no config files, no keys redefinition). 

Make a '@ walking around the empty screen' demo. Play with it a little, clean things up, play some more, imagining the game is finished and you're playing it. 

Make the message handling routines -- especially for the debugging messages -- they come in handy. 

 Step 4 - The map 

Decide on your map structure. Don't over-generalize -- you can add things later. Make your (empty) map displayed on the screen. Scrolled if you need it. Add some elements to your map to see if they are displayed correctly (just hard-code them, you don't need a level generator yet). 

Make your '@' appear on the map -- not as it's element at first, just as a cursor. Test the scrolling, maybe make a 'look' command. 

Now turn '@' into creature. You still don't have time implemented, so the keyboard-reading routines will just move it around the map. Include the checks for walls in the movement code. Maybe add doors and open/close commands. 

 Step 5 - Saving/Loading 

(First: Note that you can initially do away with save and load entirely - a feature not present in many early implementations - and generateyourdungeons instead of hard-coding them, which is arguably a more roguelike approach!) 

Read the map from a file instead of hard-coding it. You can play with it and test different configurations if you make it human-readable from the start. 

Add the 'save' command and the procedures to save your game -- the map at first, then, gradually, all of other game elements. From now on, when you implement something that needs saving, also implement saving it as soon as possible. 

Here's a handy article about save files and how to implement  them; it's worthwhile to read when planning ahead what form you'll save things in. 

Once you work with files, you can make your preferences and keybindings config files. Again, if you make them human-readable, you'll save yourself a lot of trouble. 

Now, when you're not sure how any element of the game works, you can save the game to a file and just check it. 

 Step 6 - It's alive! Alive! 

Implement other creatures (monsters) and time. Add a single monster to begin with. Give him some simple AI (like, say, stay still, or maybe move randomly). 

Start with my turn-your turn, then implement the time system you want (or, usually, a simplification of it and gradually make it more complicated later). 

(Note: If you use a library, it can be easy to implement The Incredible Power of Dijkstra Maps. See also Dijkstra Maps Visualized.) 

Remember to test everything as you go. 

 Step 7 - Interaction 

Add stats for your creatures. A simplification of the ones you envisioned, probably. It's best to add stats as they are needed, not because they 'look cool', but you might not be able to resist ;). 

Make the creatures notice each other -- bump, attack, etc. Gradually improve their AIs, so that they can chase the player. 

Implement and test the combat system -- without equipment for now, just hardcode the values. Do lots of testing. 

 Step 8 - Data files 

Move the creature, map features, etc. definitions to data files. Forget about scripting for now If something cannot be moved -- just leave it for now. 

(Note: This is an irrelevant step for interpreted languages. You may instead take the opportunity to organize your code in such a way as to make adding new denizens or map features an easy process.) 

 Step 9 - Items 

Add items. For start, just objects you can pick up -- no properties. Gradually give them properties, kinds, stats, etc., implement inventory, picking up and dropping, equipping and using (no effects yet), also stacking, containers (if you want them), etc. 

This step usually requires lots of testing to balance. 

 Step 10 - Magic 

Add item effects, special monster attacks, spells. Add items and monsters to test them. You don't need all the possible effects right away, just the ones that are needed for the next step. 

 Step 11 - Simple game 

Try to make a simple, hard-coded game. Play it and give it to your friends. Test the mechanics you've implemented so far. See if the game is fun. 

Change everything you need to change. Don't forget to test a lot. Always ask someone to test the game's 'fun factor', or test it yourself after a while; it's hard to notice some things right away. 

This step should take a pretty long time, until you've got a playable, fun mini-game. 

 Step 12 - Levels 

Write your level generators. Implement moving between the levels, a wilderness and/or town if you want them, saving the levels on level change if you want them to be persistent (so that they don't take up memory). 

Spread your monsters and items on different depths. Add more monsters and items, with their effects, as needed. 

 Step 13 - Experience 

Start developing your experience system and skill system. Tune the monsters' and items' stats. Make character generation screen, classes, races, and whatever else you need. 

Playtest your game frequently. 

 Step 14 - Citizens 

Add NPCs, shopkeepers, and simple quests if you need them. Keep adding features and tuning the stats. 

 Step 15 - Free at last 

Start adding and testing all the 'unique' features you thought were so cool months (years?) ago, when you started the whole thing. Revise your opinions of them and see if they fit the game. 

Write your pet random plot generator, factions system, infinite wilderness generator, neural network AI, or other unique feature, since you can now test it in a working game.