游戏邦在:
杂志专栏:
gamerboom.com订阅到鲜果订阅到抓虾google reader订阅到有道订阅到QQ邮箱订阅到帮看

关于独立游戏开发5个过程的相关建议

发布时间:2013-07-27 15:56:10 Tags:,,,,

作者:Macoy Madson

作为一名独立游戏开发者,在制作游戏过程中尽量多学些东西这一点极为重要。我认为这一过程包含以下几个步骤:

1.想法

2.原型

3.迭代

4.测试

5.完工

我希望针对这个过程的每个阶段提供一些对你们有所帮助的建议,以便你们加快开发速度,提升游戏质量。

逐步进阶的过程

首先,要注意到这并非线性的“瀑布”过程。它非常有组织。你通常是先从一个理念开始,接下去就是以无序方式开始创建原型、迭代和测试。这有助于你进行试验,克服僵化的游戏设计,从而推动游戏的积极发展。

indie game developer(mistergoh.com)

indie game developer(mistergoh.com)

步骤1:想法

初级游戏设计师有时候会认为这是整个过程中最重要的一步,并且会因为一个正在探索中的想法而中止整个开发过程。因此,他们很容易出现过度设计的倾向(游戏邦注:例如编写出庞大的游戏设计文件),自不量力地将项目放大,高估游戏理念的价值。这也会让设计更为僵化,长期来看也会对游戏造成消极影响。

虽然想法很重要,但最重要的还是认识到如果不制作原型并测试想法就根本学不到什么经验。你会发现自己脑中的想法听起来确实很有趣,但试玩原型之后可能就会觉得很糟糕。你还可能发现一个根据听起来很“无趣”的理念所制作的原型反而非常有趣。

在这个阶段,你要明确自己的目标和局限性。例如,“制作一款有趣的游戏”就不能算是一个明确的目标,而“在一个月内使用‘Flowers’主题,并更好地使用新COM系统制作一款游戏“才能算。这第二个例子还显示了约束条件。有些适用于多数人的约束条件包括在特定时间内,以及在自己的技能范围内制作游戏。约束条件可以让你想出更多主意,但通常你可以针对每个游戏项目进行一些自由取舍。

提到想法,我们通常会提到灵感一句。要记住灵感无处不在,例如你的生活,其他媒体,游戏设计理论,它甚至可以是随机生成的!最重要的是知道“灵感”并非没来由的念头!当你“获得灵感”时,你的大脑可能会被蒙蔽,从而难以看到这个想法的糟糕之处。你要做的就是再多给自己一些时间,无论它现在听起来有多好,至少也要想个三四天后再将它写下来。

在低级阶段,重要的是专注于理念中的机制。记住,你是在编写一款游戏,而不是一个故事,所以你需要玩法!如果你不能想出这个故事的好玩法,也许最好使用其他媒介形式表达这个故事。

当你有一个想法并且酝酿了足够的时间(而该想法听起来仍然很不错)之时,下一件要做的事情就是将其精简为最基本的形式。从而发现你最看中该理念的哪些元素。你得找到令该想法如此具有吸引力的最原始、核心的元素。这是你创建原型的切入点,因为你的整款游戏都要依赖这些元素。

这里还有个悲观的提示,要记住你终有一天会死。将此牢记在心,把它当成你制作的最后一款游戏。

步骤2:原型

如果你还是坚持使用某个想法,我还是要强调:你只有制作出了原型才能看到该想法的可塑性。所幸这通常就是游戏开发过程中最有趣的步骤,因为你可以在此看到自己的想法成真!但若要有效使用你的理念,那就一定要准确创建原型。

在创建原型过程中,你一定要勇于面对失败。如果你害怕失败,你就永远不会发布游戏。我喜欢将原型保存在不同于源代码控制的开发文件夹以及桌面文件夹中,只是因为这可以突出创建原型需要实现的临时可玩性。如果你搞砸了,就要告诉自己这正是你预料中的情况,这没有关系!

除了直面失败,你还需要加快创建自己的原型,因为在你成功之前很可能遭遇多次失败。你可以通过优化代码来提高速度。这里我并不是指实现性能上的优化,而是“寿命”优化。你希望以最大化重用和简化的方式编程,这意味着要创建一个充满可重用代码的游戏库,并制作一个你可以复制和重用的游戏模版。这个游戏模版应该包括一个拥有渲染精灵的开放窗口,输入和可行的生成文件等。这是为了方便起见!

此外,你还要避免使用创建原型的“更简便”方法,而是坚持使用你自己最熟悉最拿手的工具,因为这可以加快创建原型的效率和速度。我大部分原型是用C++编写的,因为我对这一语言有4年的接触经验。

在你碰到任何一行代码前,要确保你已经明确了原型所需解答的问题。而这些问题应该极为简单,并包含游戏理念最重要或最具“风险”的部分。理想情况下,你应该在一些显而易见的地方写下问题,这样就不至于让自己脱轨。只要原型解答了这一问题,你就可以继续向下一个问题进军了。

当你终于做出了能够肯定想法的原型之后,要找到肯定它的核心元素,并摒弃其他所有冗余内容。精简就是优秀设计的核心。

步骤3:迭代

此时,你已经制作了不少次可确定自己想法潜力的原型,也已经确认了想法的技术可行性,以及在编码时如何执行这一理念。你还发现了自己最喜欢这一理念的哪些元素,并删除了那些与游戏体验不相干的内容。如果你没有实现这些目标,那就回去重新制作更多原型吧!

我所提到的迭代,是指开发和优化最终产品。你应该避免使用原型作为成品代码,因为原型是为回答某个问题,而非整款游戏而量身制作的内容。在这个开发环节,你要使用自己最可持续的编码技能来创建整个游戏成品。原型阶段还不是让这些技能上场的时候,因为原型迟早会被抛弃。

迭代应从最重要元素向最不重要元素入手(像原型一样)。如果你在尚无可运行的主游戏机制之前编写界面或图像代码,你就真是犯了大错!没有人会在乎你的图像或菜单,他们在乎的是玩法!要先制作“玩具”,最后再动作制作菜单,以及润色其他元素。

虽然现在你是在编写“最终”代码,但还是要进行一些试验。在进行这些试验时一定要小心谨慎,一不留神就可能漏掉之前所专注的核心元素。要确保你清楚为何游戏具有吸引力。十有八九不是因为你有逼真的布偶物理机制。你的试验应该与产品相分离(如果你使用源控制方法,这就很棘手了)并且易于取消。你在这种试验阶段应该专注仅优化核心元素!如果试验与核心元素存在明显分歧,那就写下来并在之后制作原型。

当你开发一个新模块时,一定要再它完成和可行时再继续开发另一个模块!这很困难,因为你可能已经疲于应付新系统中的漏洞,但重要的是完成该模块。这一点之所以重要是因为漏洞的叠加会导致整个系统崩溃。

另一个原因是你在创建组块的过程中可能会忘了之前知道的事情,所以就需要再回头花些时间进行调整,并可能因此犯错。完成模块也可以让你获得更多动力。在你“完成”一个组块并发现其中存在漏洞时,要立即修复它,否则你就将其搁置一旁,之后忘得一干二净。

Keep_It_Simple__Stupid(from forgecommunications)

Keep_It_Simple__Stupid(from forgecommunications)

不要在时机未成熟时进行优化!作为一名程序员,你可能已经听过KISS(游戏邦注:即“Keep It Simple,Stupid!”简写)这一理念。要严格贯彻这一原则!Jonathan Blow讨论过算法和数据结构,以及它们如何针对运行性能或内存进行优化,但并非“终身优化”的问题。更重要的是在一个月内结束以20 FPS的速度运行的游戏,而不是在一年内完成以60 FPS速度运行的游戏。

在迭代周期编码时,你得辨别出可以在未来游戏中重用的系统,并将它们添加到自己的库中,而不是让它们仅运用于原来的游戏。这不但可以优化你的库,还可以加快之后的游戏(和原型)开发速度。不要试图重用那些过于专门化的系统。

在通过迭代扩充你的游戏库时,还要专注于那些能完成而非运行表现,并且能够鼓励代码重用,缩短开发时间的功能。例如,碰撞检测和分辨率就极有用处,值得你花时间去执行,但执行一个“优化”的碰撞路径就不是了。记住,只有在你需要时才进行制作!在功能方面的例子,我最近执行了自己的COM(或CES)系统,因为我发现这更便于进行代码重用。当然,你会遇到运行性能方面的问题,但动态的、可移植笥和重用性元素在终身优化时可以弥补这些不足!

如果你已经进行到了这一步,就没有必要抛弃项目了!当然,你已经通过代码错误学到许多经验,完整的重新编码对项目也有好处,但不要再浪费自己的时间了!许多初级游戏开发者总是在开发中期抛弃项目,这也正是为何他们仍是新手的主要原因!你已经遇到了一个所谓的“瓶颈”状态,此时你并不想再继续推进项目开发进程。一定要挺过去,否则你之前所做的一切都白费功夫了!我已经发布了7款游戏,其中2款甚至一度将遭遇死刑。但我挺过来了,并从错误中汲取了许多经验。你一定要完成整个项目,不要轻易言弃!

迭代很大程度上会受到下一个环节的景,即玩法测试。

步骤4:玩法测试

得承认,我在玩法测试中遇到过许多麻烦。你很难正确处理这一问题,但如果处理得当,就会极大提升你的游戏。玩法测试很明确,所以我在此要列出一些能够让你更有效率的原则:

首先,尽早和经常测试!怎么测试都不算太多!在原型阶段就要开始测试,发布时也同样不例外。你会发现自己原先认为很完美的游戏内容,其他人却完全看不明白,所以不要闭门造车地开发游戏!

其次,要奉行多样化原则!这包括人群和技术。要尽量在多种设备和操作系统上测试。我有一款游戏在自己的两台电脑(拥有完全不同的配置)上运行都很理想,但在多数其他人的电脑上却出现了崩溃性的漏洞!针对人群进行测试时,不要局限于某一群体,让大家都来玩玩游戏,无论对方的性别、年龄或兴趣!你的测试对象越多样化,你的用户也就会越广泛,你的游戏就会越有包容性。

不要浇灭测试者的热情。他们试玩一会儿之后,可能就会带有偏见,尤其是在他们已经看过游戏早期版本之时。你得让测试者拥有清醒的状态和头脑,所以要经常更换测试者。

观察是你在测试过程中最需要掌握的一项技巧。要观察测试者何时说话,何时停止说话,何时在游戏中挂掉,何时获得成功,何时不再玩游戏等。多数人的表现情况都一样,即使你也在场。观察也是你在测试过程中唯一需要做的事情。不要给予测试者任何背景,或者向其解释情况,对其提供帮助等,你只负责观察,并及时做记录。

在他们完成测试后,可以向他们提出以下三个问题“

1.(对这款游戏)你喜欢什么?

2.你讨厌什么?

3.有什么困惑?

这可以让你获得关于应该重视和改变哪些地方的清晰反馈。此外,玩家给你提供优化游戏的建议时,不要关注建议本身,而要琢磨他们为什么要提供这个建议。

步骤5:完工!

到了这一步,你就可以准备完成游戏了!最后10%的开发过程总让人感觉像是90%,但你一定不要放弃!记住即使是“90%完工”的游戏也是无用之物!完成是指你突破瓶颈,让所有松散的环节连成一片。此时可以回头看看自己究竟走了多远,前面还有多长路程。总之,马上就要到终点了。

虽然你已经快完成了,还是要在多个平台进行测试。你得测试一切内容,甚至是“说明”文件也不例外!

你得缩短玩家发现你游戏的路径,尽你所能降低一切门槛,让他们更方便地查看你的游戏。这里的关键就是方便。

如果你想知道为何自己的游戏看起来仍像是个“业余”项目,那有可能是因为它润色不够。在菜单或加载屏幕等一些极小的细节上有瑕疵,而正是这种细节让玩家产生了这种感觉。记住,玩家最先看到的就是这些内容,所以一定不能在此出差错。研究一下“专业”游戏项目,以及它们看起来“更专业”的原因。润色很大程度上要取决于自己的感觉,所以你需要自己去体会,但它确实值得你花时间。

如果你还是为自己的游戏质量而“惭愧”,或者知道它有严重的缺陷,那就尽己所能修复问题。完成你的项目,从错误中学习经验,在下一款游戏中发挥更佳表现。

总结

祝贺你完成了游戏!现在再做一次,但要避免再犯影响游戏质量的错误。

在此我将每个步骤的核心理念概括如下:

1.想法

1)原型仍然很重要

2)设置一个明确的目标和约束条件

3)多花点时间

4)找到验证该想法的核心元素

5)要全力以赴

2.原型

1)不惧失败

2)尽快制作原型,尽量让代码更便捷

3)使用你已经知道的工具

4)明确原型所需解答的问题

3.迭代

1)制作高质量的代码

2)从最重要到最不重要的元素入手

3)试验,但不要遗忘核心元素

4)完成模块再推进工作(例如消灭所有漏洞)

5)KISS/终身优化/不要在时机未成熟时优化

6)在游戏库中增加重用代码

7)仅向游戏库添加可提升开发速度或加强性能的功能(不要为追求速度而编码)

8)此时一定不要放弃!

4.玩法测试

1)尽早和经常测试

2)多样化你的测试群体

3)替换测试者

4)提问

5.结束

1)挺过去

2)测试,测试,测试

3)降低开始玩游戏的障碍

4)进行润色

5)发布游戏并汲取错误教训

本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

General Tips on the Process of Solo Game Development

By Macoy Madson

As a solo game developer, it’s important to learn as much as you can about everything you can, including the process you follow when making games. The process I will discuss consists of the following steps:

Idea

Prototype

Iteration

Playtest

Finish

I hope to provide you with helpful tips on each stage of this process so that you can improve the speed of development and the quality of your games.

The Process, Step By Step

First of all, it’s important to note that this isn’t a linear “waterfall” process. It is very organic. While you will always start with an Idea, the following steps of Prototyping, Iteration, and Playtesting will happen in an unorderly fashion. This is good because it encourages experimentation and goes against the rigidity of a game’s design, which allows positive evolution of the game. Over time, you’ll get a feel for how you usually follow the process and how you can improve.

Step One: Idea

Beginner game developers sometimes think this is the most important step in the process, and that all development should halt while an idea is being thoroughly explored. As a result of this, they tend to overdesign (ex. huge game design documents), scale it too large for their skills, and overestimate the value of ideas. This also makes a design much more rigid, which ends up affecting the game negatively in the long run.

While the idea is important, it is most important to understand how little you can learn without making a prototype and playtesting that idea. You’ll find that ideas in your head sound really fun, but actually playing a prototype of that idea ends up being really dull. You’ll also find that a prototyped “dull” idea can be really fun!

During this stage, make sure that you have your goal and constraints clearly defined. For example, “make a fun game” is not a very clear goal, while “make a game in a month that uses the ‘Flowers’ theme and preferably utilizes the new COM system” is. The second example also shows good constraints. Some very immediate constraints that apply to most everyone are making the game in a certain amount of time (“before death” even) and staying within (and very slightly exceeding) your skill range. Constraints can help you think of more ideas, but it is often good to fluctuate the amount of free movement you have on each game project.

Inspiration is a word that often comes up when talking about ideas. Just remember that inspiration comes from anywhere, such as your life, other media, game design theory, or even random generation! The most important thing you need to know about “inspiration” is to not jump on an idea! When you are “inspired”, your brain is pumping in those reward chemicals for your successful idea generation, which makes it very hard to see the bad in the idea! All you have to do is give it time. No matter how good it sounds at the moment, give it at least three or four days before doing anything more than thinking about it and writing it down.

At a lower level, it is important to focus on the mechanic(s) of your idea. Remember, you’re writing a game, not a story, so you need gameplay! If you cannot think of good gameplay for that story, maybe that story is best expressed using another form of media.

When you get an idea and have waited a sufficient amount of time (and it still sounds good), the next thing you need to do is scale it down to its most basic form. Look for what makes you really like that idea. You need to find the most primal, core element(s) that makes that idea so appealling to you. This is the first thing you need to prototype as your entire game will be relying on these elements!

On a more somber note, remember that you will die. Keep that in mind, and make the game as if it was your last.

Step Two: Prototype

If the Idea section hasn’t nailed it into you enough, I will repeat: you cannot see the potential (positive or negative) of an idea until you prototype it! Thankfully, this is often the most fun step in game development because you get to see your idea come to life! However, it is still critical to prototype correctly in order to use it most effectively.

When prototyping, you must be open to failure. If you fear failure, you will never release that game. I like to keep my prototypes outside my source-controlled Development folder and in my Desktop folder, just because it emphasizes the temporary playfulness that prototyping needs to succeed. If you mess up, it’s important to tell yourself that that is expected and completely OK!

With this openness to failure, you also need to develop your prototypes faster, because chances are you will experience that failure many times before you create a winning prototype. A ton of speed can be obtained by optimizing your code. I don’t mean performance optimizing, but life optimizing. You want to engineer your code for maximum reuse and simplicity, which means building a game library full of useful reusable code, and making a game template that you can copy and reuse. This game template should include an open window with rendered sprite, input, and a working makefile etc. You are going for convenience!

Also, you should avoid using “easier” tools for prototyping; rather, stick with what you know and have the most experience with, because that will make the fastest (and most useful) prototype. I write most of my prototypes in C++ because I have four years of experience with the language and the library.

Before you touch a line of code, make sure you have a well-defined question that you want the prototype to answer. This question should be very simple and involve the most important and/or “risky” parts of your game idea first. Optimally, you should write down the question somewhere clearly visible so you do not get off track. As soon as the prototype answers this question and explores a bit, you should move on to another.

Once you’ve made the prototype(s) that affirms the power of the idea, find the core element that affirms it and cut everything else away. Simplicity is the key to an elegant design!

Step Three: Iteration

At this point, you’ve made enough prototypes to confirm the positive potential of your idea. You’ve also confirmed the technical feasibility of the idea and how you might approach implementing it in production code. You’ve also found what you most enjoy about the idea and trimmed away what wasn’t necessary to the experience. If you haven’t, go back and make more prototypes!

When I say iteration, I mean the development and refinement of the final product. You should avoid using a prototype for your production code because that prototype was tailor-made to answer one question, not to become an entire game. At this point in development, you are using your most sustainable coding practices to build the production game. There are many articles that teach these practices, so now is the time to use what you’ve learned about high quality coding. The prototype was not the time to use these practices because they are going to be thrown away anyways!

Iterations should go from most important elements to least important (like prototypes). If you code a main menu or fancy graphics before you have your main mechanic running, you are doing something very, very wrong! No one cares about your graphics or your menues, they care about the gameplay! Make the “toy” first, and save the menues and polish for last.

Though you are now working on the “final” code, you should still experiment. Be very careful with such experiments as they can make you lose your vision of that core element that you focused on before. Make sure that you know why your game is engaging. Nine times out of ten it’s not because you have realistic ragdoll physics or you can mine metals underground! Your experiments should be made seperate from production (if you’re using source control, this is where “branching” becomes handy) and easily undoable. You should focus such experiments on improving the core element only! If the experiment is too divergent from the core element, you should write it down and prototype it later.

When you are developing a new module, do not move on until it’s completed and working! This is hard because you will get tired of killing the bugs in the new system, but it’s critical that you finish it. This is primarily because bugs will build upon bugs until the entire system collapses. It’s also because you will forget the things you know as you build the module, so when you come back to it you will have to take time to adjust and may make mistakes. It’s also very rewarding to finish a module completely, so you will get a motivation boost if you do. After you “finish” a module and discover there is a bug, immediately fix it, or you’ll put it off and forget about it.

Do NOT, under ANY circumstances, prematurely optimize! As a programmer, you’ve probably heard of KISS, which stands for “Keep It Simple, Stupid!”. Follow this principle as closely as you can! Jonathan Blow talks about algorithms and data structures and how they are optimized for performance or memory, but are not “life optimized”. It is more important to finish a game in a month that runs at 20 FPS than finishing it in a year for 60 FPS!

When it comes to coding during the Iterative cycle, you want to recognize systems that can easily be reused in future games and add them to your library rather than making them game dependent. This will not only improve your library, but also make every subsequent game (and prototype) faster to develop. Don’t try to reuse systems that are too specific though!

While furthering your game library through Iteration, focus on features that a) are useful not for their performance, but for what they accomplish and b) encourage code reuse and shorter development times. For example, collision detection and resolution is extremely useful and worth taking the time to implement, but implementing an “optimized” collision routine is not. Remember, don’t make it unless you need it! As an example of (b) features, I recently implemented my own COM (or CES) system because I saw how much easier code reuse becomes with it. Sure, you take a performance hit, but the idea of dynamic, portable and reusable components makes up for it in life optimization!

If you’re this far, there isn’t any reason to scrap the project! Sure, you’ve learned a lot from coding mistakes and a complete recoding would probably do the project good, but don’t waste your time! Many beginner game devs continuously scrap projects right in the middle of development. This is the main reason why they are still beginner devs! You’ve hit what’s commonly known as “the Wall”, the point at which you no longer want to continue development on a project. Just push through it, or all of the work you’ve done will be worth nothing (to consumers, at least)! I’ve released seven games, and two of them ended up being hell near the end. I pushed through it though, and learned from my mistakes. You MUST completely finish your projects! Do NOT give up!

Iteration will be heavily influenced by the next step, which is…

Step Four: Playtesting

I have to admit, I have a lot of trouble with playtesting. It’s quite difficult to do it correctly, but when done correctly it will end up massively improving your game. Playtesting is quite straightforward, so I will present a few rules of thumb you can use to do it more effectively.

First, playtest early, playtest often! You can never playtest too much! Playtest as early as the prototype stage, and as late as release. You’ll find that parts of your game that make perfect sense to you will completely confuse others, so do not develop in a vacuum!

Next, diversify! This includes people and technology. Run on as many devices and operating systems as you can. One of my games worked well on my two computers (with quite different specs) and virtual operating systems but had game breaking movement bugs on most other computers! When it comes to people, do not eliminate any demographic. Let anyone play your game, no matter what gender, age, or interest! The more diverse your playtesters are, the more diverse your audience will be, and the less biased your game will be.

Don’t burn out playtesters. After a while, they get quite biased, especially because they’ve seen earlier versions of the game. You want the playtester to have a clean slate and an open mind, so make sure to switch out people often.

Observation is the most important thing you need to learn how to do during a playtesting session. Watch when they speak, when they stop speaking, when they die, when they succeed, and when they stop playing. Chances are most people will do the same, even though you effect them because you are there. Observation is also the only thing you should do during a playtesting session. Do not give them a background, or explain something, or help them out, or anything. Just watch, and take notes.

After they are finished playing, you should ask them the following three questions:

What did you enjoy?

What did you hate?

What confused you?

That gives you very clear feedback on what you need to emphasize and what you need to change. Also, when the player gives you a suggestion for improving the game, focus not on the suggestion but what made them give you that suggestion.

Step Five: Finish!

If you’ve made it this far, you’re ready to finish your game! The last 10% of development often feels like 90%, but you must not give up! Remember that even a “90% completed” game is worthless! Finishing is all about pushing yourself through the Wall and getting all of the loose ends wrapped up. Look back at how far you’ve come already, and look how far you have to go. It’s not that far away!

While you put the finishing touches on and zip it up for the first time, test on as many platforms as possible. You need to test everything, even your “readme” files (one time my newlines were Unix-style and didn’t work on Windows computers :) )!

You want the path a player takes from discovering your game to playing it as short and smooth as possible. Lower all of the barriers you can, and make it extremely easy for them to check out your game. Convenience is key at this point.

If you’re wondering why your game still looks and feels like a “hobbyist” project, it’s because it isn’t polished enough. Very small things, like menues or loading screens, can make a big difference on the player’s feelings towards your game. Remember, the very first thing the player will see will be one of those things, so it is very important to get it right. Study “professional” games and why they look more “professional”. Polish is largely by feel, so you will just need to practice to get it right, but it is well worth the extra time.

If you’re extremely embarassed by the “quality” of your game or know that it has serious flaws, fix as much as you can and push it out there. Finish your project, learn from your mistakes, and do better on the next game.

Conclusion

You’ve now made a game! Congratulations! Now do it again, only avoid the mistakes that hurt the quality of the last game.

I’ve covered a lot, so I’m just going to do a quick outline on each step:

Idea
Prototyping is still essential

Set a well-defined goal and constraints

Give it some time

Find the core element that makes the idea shine

You will die, so make it count!

Prototype

Be open to failure

Do it as quickly as possible, and make the code as convenient as possible

Use the tools you already know

Have a well-defined question to answer

Iteration

Make high-quality code

Go from most important elements to least important

Experiment, but don’t lose vision of the core element

Finish a module before moving on (kill all the bugs etc.)

KISS/life optimize/NO premature optimization

Add reusable code to your game library

Only add features to your game library that make development faster or add capabilities (do not code something for speed unless you need it)

Do not abandon/give up on a project at this point!

Playtesting

Playtest early, playtest often

Diversify your playtester demographics

Swap out overused playtesters

Ask questions

Finish
Push through it

Test, test, test!

Make it easy to start playing

Add polish

Release it and learn from your mistakes(source:gamedev


上一篇:

下一篇: