作者：Herman Tulleken

在2013年11月份，我和两个同事制作了30款游戏。虽然我之前做过一些游戏原型，但在如此短暂的时间内制作这么多游戏还是让我获得了之前所没有的收获。正如我对好友所说的，这就好像在数天内看完一部电视连续剧，而不是每周定期看一集——你会有不同的体会。

我在以建议的形式综合了自己的一些观察和心得。我想也许有不少读者已经看过《如何在7天内快速创造游戏原型》这篇文章。从某些方面来说，本文是该文章所呈现理念的一个编程扩展版（如果想了解更多创建原型的文章，还可以看看《如何在30天内制作了30款游戏》这篇文章）。

A.快速是一种心理状态

极为快速地制作内容有许多乐趣。日常开发可以是缓慢的过程，因为离最终的产品成型还有数月（甚至数年）时间呢。在你的闲暇时间捣鼓一个理念，可以让你获得一些见解，但其结果却不甚明朗。

快速创造原型可以让你获得即时的满足感。它让你专注，让你投入精力并加快速度。

但你应该摆脱开发模式，以及捣鼓模式。你得知道自己将会把作品抛置一边，并浪费一些精力。你得知道有时候你并不需要最佳决策——你只要直接让它成型即可。你得摆脱完美主义和细节情结。

你得抓住核心。

了解和记住目标

创造原型的原因多种多样，以下是其中的几例：

*为在固定时间前完成一款游戏（例如游戏开发大赛）

*为找到有趣的游戏核心（例如在项目的预开发阶段）

*为从一系列选择中找到最佳理念

*为测试某一理念的技术可行性（游戏邦注：这个理念可以是关于整款游戏的理念，也可以是某项图像技术或AI算法）

最好的方法是根据这个目标来制作和制定决策。要明确这个目标是什么，并时时自我提醒。

如果某项任务并没有让你离目标更近，那就不要动手了。

找到你理念的实质，并为此安排足够的时间。

这个实质可能是一个机制，一种风格，一个主题，一个设定，一种情感体验。要找到它，然后将其从其他支持元素中区分出来。

当你安排项目进程时，要据此分配时间。如果你的实质是一种新机制，你就会希望拥有足够的时间来探索它，因为你不想把自己所有的时间用来创建关卡或编写着色器。

接受创意冒险，但要避免技术风险

如果游戏原型失败了，那应该是因为它很无趣，而不应该是技术问题（当然，当你的目标是技术原型时例外）。你想让自己的原型完工，并允许你和团队探索其实质，并其此传递给玩家。

*避免棘手、复杂的数据结构和算法

*避免复杂的系统和结构

*避免试图让制作速度更快

*避免无助于提升玩法的技术性特征

B.规划和过程

考虑内容

问问自己你的游戏为呈现一种感觉需要哪些内容：

*你需要创造多少内容？

*你将如何注入多样性？

*应该在哪个开发阶段注入多样性？

*如果你耗尽了所有时间，拥有一个注入实质内容的计划，那该使用哪些折衷方法？这会让boss成为关卡敌人的软弱版本吗？

计划

*制定一个粗糙的计划，写下统计时间。

*根据目标检查你的计划，并移除那些无法让你更接近目标的计划。

*根据你的游戏理念的实质检查计划，并核实你是否为探索该实质而分配了足够的时间。

*确定你估计最可能完成的环节。牢记折衷想法，考虑减少他们的影响/角色/复杂性。想想占位符策略。

遵从一个执行策略，但要根据创意过程进行灵活调整。

以下就是我建议你遵从的次序。要谨记其中的相关性。

1.让屏幕显示一些东西

2.执行头个关卡游戏

3.执行用户控制方式

4.执行一个极简化关卡

5.执行一个玩具逻辑

6.执行游戏目标

7.执行AI

8.执行反馈

9.润色

创造原型并不只是编写一个规格，记住这里会有一个不成功的开端，你得及时调整。在必要情况下要更改计划和更新日程安排。

清楚和避免时间流失

有些事情就是会占用大量时间。要认识到这一点，并确保你安排了足够的时间，留有折衷办法，保持其简单性（通常的时间耗损当然与游戏类型有关）。

控制方式：在动作游戏中，控制方式可能需要投入长期时间才会具有可玩性。

平衡：在模拟游戏中，平衡很费时间。要保持系统低数量，保持低变量。并留下足够的时间进行平衡。

GUI：在信息密集型的游戏中，GUI可能耗尽你所有的时间。找到合适的音频需要很长时间——所以除非有必要，或者你已经拥有了所需的音频，否则就不要添加音频。

动画：动画可能吸收大量时间，要考虑使用捕捉姿势，或者进行合适的滑动。

程序生成内容：针对内容生成调整算法可能非常费时。与其他算法不一样的是，内容生成算法的技术参数很难制作对象。

考虑到使用系列开发（编程管道）

对于拥有不止一名程序员的团队来说，将项目划分为多个环节，并为每名程序员指派任务，以便大家平行工作是一种普通做法。

还有另一种方法不妨一试，看看它是否适合你们团队。

这种方法要求多数代码以错列的方式经手所有程序员。首个程序员将执行项目的大致框架，下一个程序员将开始填充细节，如此反复。每名程序员不只是编写一部分代码，每位程序员在一定的时间片段都要接手整个项目（当然，这些时间片段可能有所重叠）。如果你使用大量占位符，它就尤其管用。

这一方法的好处在于，减少了界面的讨论。在你的时间空档中，如果你需要更改一个界面，就可以立即更改。这不会破坏其他程序员的代码，因为你就是唯一的程序员（即使是在重叠性的时间片段也仍然管用，只是你需要更加小心，以及相关计划）。

当然其负面效果就是你所得到的设计可能非常糟糕。但这没有关系，因为设计并不重要。这看起来有点浪费，因为总有些时候某些程序员并不需要编程。

（当然，这意味着要划分编程任务：如果是同其他创意工作一同展开这项任务，那就太遗憾了。在许多创造原型的项目中，程序员同时也是游戏设计师，但这并不适用于设计师）

不要陷入僵局

有些事情可能会让你觉得受到阻碍：漏洞、难以执行的代码，不具可用性和棘手的控制方式，内容数量，关卡设计等。

当你身陷泥淖时，一定要想法脱身，并继续前进。以下是你陷入僵局时可以采用的一些做法：

*忽略那些不会破坏玩法的棘手漏洞

*砍削有问题的功能，减少内容

*使用简单的占位符算法或近似值

*使用强力检查——这是在消耗一定内存，以及在主循环（甚至是游戏）之外投入的额外时间这一情况下设计正确、快速算法的有效方法。

*伪装。那些能够响应玩家的怪物看起来就比不具响应性的怪物更智能，无论它们实际上有多智能。

*硬码。一个冗长的怪物系列比一个复杂的造波算法更容易编码。

*隐藏。

C.代码设计和执行

使用占位符代码

在任何可行的地方使用占位符代码，这样你就可以更早地转向核心玩法。当你确定玩法后，就可以有组织地用代码来替换占位符代码。这种方法的好处在于，当你所有的系统都到位，并制作核心玩法时，就更容易根据玩法影响来划分任务的主次顺序了。

以下就是占位符的一些通常候选对象。

控制：在一些游戏中，控制方式尤其重要。但如果二级控制方式不会影响玩家体验，并且更快执行，那就要先执行二级控制方式。例如，在许多滑行益智游戏中，最佳控制方式允许玩家使用鼠标（或手指）来滑动对象。这可能是一种很难执行的方法。换句话说，带有方向键或按钮的鼠标选择执行很快，能够让你更快进入其他玩法元素。

反馈：反馈很重要，它负责提供信息以及优化体验。但首先要做一些简单的操作：对话和信息，换色，闪光或喧哗声。

AI：AI很困难，我们很难预测哪种战略会奏效。以下是你执行最终算法之前可用于AI占位符的一些做法：

*随机AI

*使用简单启发法的AI可以取代预见性的AI，反之亦然，哪种方法更简便就用哪一种。

*贪婪算法（游戏邦注：这是一种不追求满意解，只希望得到较为满意解的方法）。

*无法执行所有可以操作的AI。

程序生成内容：如果你的游戏依赖程序生成内容，你可以使用以下类型的替代方法。

*固定内容

*纯随机内容

近似值：粗糙的近似值通常可能非常管用。以下就是其中例子：

*使用碰撞球体而非碰撞网眼。

*为曲线使用线性近似值。

使用设计捷径

（要慎用）在制作代码中你应该避免“万能”类，但原型中，它们可以替你节省大量时间。你不需要从作用物延伸而来的怪物或玩家，而是将所有代码导入作用物，并使用相似的切换法而非多态性。

不要相信任何比动态列表更复杂的数据结构，尤其是在你需要自己执行的时候。专注于简单、安全和便于理解的数据结构和算法。

避免错误的设计捷径

*命名规则和原型组织不变。

*不必要地暴露数据（使用公共域）即使是在短暂的一两天中也会让你受害。因为要记住将命值调整为0是否就会杀死怪物，或者你是不是还需要亲手了结它，这并不是一件容易的事。

*状态机（或任何追踪状态的东西）所需的声明远超过你的想象。如果你试图使用捷径，而不是合理的抽象法，那就很可能陷入漏洞百出的混乱代码中。

管理你的可调整内容

*让游戏在某个地方保持可调整状态，以便更容易地微调游戏。

*并非每个值都需要调整：不要害怕将其变为常量。但要让它们处于中间位置。不要使用幻数。

*谨慎命名你的可调整内容。

*当你设计一个可调整系统时，确保其中暴露的变量拥有明确而线性的作用。模糊不清的可调整内容最好要隐藏起来。最好制作一个清晰易懂，但却无法彻底控制的系统。

编写可读代码

一次性的代码不应该用最高标准来编写。

但是，它仍然要能够服务于传达你的意图，尤其是当你在团队中工作时。混乱不堪的代码会浪费大量时间。快速开发时编写代码的最有效方法就是：

*正确命名

*富有组织性

*避免深度分层和复杂的依赖性

*保持方法的简单性

*限制“智能”类的数量。智能类是处理游戏逻辑的方法。在小型、不稳定的项目中，最好是集中化逻辑，并保存用于展示的助手类。这更易于制作快速调整。只要你保持方法的简短性。

使用执行模式

执行模式是一种做事的标准方法。例如，以下这个游戏主要文件的执行模式：

public void Start()
{
Reset()
}

public void ResetGame()
{
currentLevel = 0;
ResetLevel();
}

public void ResetLevel()
{
DestroyObjectsFromPreviousPlay()
InitialiseVariables()
BuildLevel()
InitGameState()
}

public void Update()
{
ProcessGameFlowInput(); //Reset or next level

if(gameOver) return;

ProcessGamplayInput(); //player controls
UpdateContinuousGameState(); //movement, AI, etc.

gameState = GetGameState();

if(gameState == GameState.Win) WinGame();
if(gameState == GameState.Loose) LooseGame();
}

private void NextLevel()
{
currentLevel++;
ResetLevel();
}

private WinGame()
{
ShowMessage(“You win”);
EndGame();
}

private LooseGame()
{
ShowMessage(“You loose”);
EndGame();
}

private EndGame()
{
gameOver = true;
}

通过使用标准，你将减少用于思考，以及争辩替代性方案的时间。执行模式对制作代码也很有用，但创造原型模式却有所不同：它们强调简单性和明确性，而不是面向对象编程的重用和有效性。

你可以经常设置像模版一样的模式，这样你就可以在创造原型时使用。

另举一例，以下是一个随着时间发展更改一个变量值的执行模式：

private IEnumerator ChangeSomething(thingToChange, initialState, finalState)
{
float timePassed = 0;
Set(thingToChange, originalState);
bool finalStateReached = false;

DoThingsAtStartOfChange();

while(!finalStateReached)
{
timePassed += Time.deltaTime;

if(timePassed >= time)
{
timePassed = time;
finalStateReached = true;
}

Set(thingToChange, Lerp(originalState, finalState,
timePassed / totalTime);

yield return null;
}

DoThingsAtEndOfChange();
}

D.之前，之后，之间

如果你经常创造原型，你就可以利用这一优势，在创造原型的空隙做一些事情。

反思

在你完成一个原型时，做一份事后分析报告，并鉴别其中的好坏经验。在你开启下个原型项目时简短地回顾其中的要点。

创造一个促进快速创造原型的代码库

这不同于制作项目的库。你可以使用有点低端的技术，或者制定一些平台假设，或者使用其他你无法正常使用制作代码的技术。

例如，我们在自己的许多游戏中通过利用像素纹理来，而不是使用精灵来渲染网格。这个方法适用于创造原型，但对最终成品来说太慢了。

确定执行模式，漏洞模式和时槽

在一些原型之后，你可能就会开始看出一些模式。制定一个列表，以此来指导你的库需要什么内容。

你能够在自己的以来中像模板一样编纂执行模式吗？你能否设计更好的数据结构来避免一些代码漏洞模式？你能否在一个时槽中，通过添加库的内容而让自己获得有利的开端？（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Rapid Game Prototyping: Tips for Programmers

by Herman Tulleken

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.

The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

In November 2013, two colleagues* and I made 30 games. Although I have done some game prototyping before, working on so many games in such a short period gave me some insights I did not have before. As I said to a friend, it’s like watching a television series in a few days, instead of watching each episode week by week – you just see different things.

In this article, I collect some of these observations in the form of a set of tips. I kind-of assume you are already familiar with the classical How to prototype a game in 7 days, which describes prototyping from a more general point of view. In some ways, this is a programming-specific extension to the ideas presented there.

(*Their names are Jonathan Bailey and Eduard Beukes. If you want to read more on our protoyping endeavour, see How we made 30 games in 30 days.)

A. Rapid is a State of Mind

Making something very quickly is a lot of fun. Day-to-day (“proper”) development can be slow progress, with the final products months (or years) away. Tinkering with an idea in your spare time gives you insight, but its outcome is vague.

Building a rapid-prototype gives you immediate satisfaction. It gives you focus; it allows you to channel energy, and gear up.

But you need to get out of development mode, and out of tinkering mode. You have to know you will throw work away, and waste some effort. You have to know that sometimes you don’t need the best decision – you just need to make it straight away. You have to let go of perfection and details.

You have to get to the core.

Know and remember the goal

The reasons for building a prototype are varied. Here are a few examples:

To have a finished game at the end of a fixed time (such as in a jam).

To have the core of a game that is fun (such as in a pre-preproduction phase of a project).

To select the best idea from a set of alternatives.

To test the technical feasibility of an idea (where the idea can be anything from a full game to a graphics technique or AI algorithm).

The best way to work and make decisions depends on this goal. Be clear about what the goal is, and remind yourself frequently.

If a task is not moving you closer to your goal, don’t do it.

Find the essence of your idea, and schedule enough time for it

An essence can be a mechanic, a style, a theme, a setting, an emotional experience. Find it, and, separate it from the supporting elements.

When you schedule, assign time accordingly. If your essence is a new mechanic, you want to have enough time to explore it; you don’t want to spend all your time building levels or coding atmospheric shaders.

Take creative risks, but avoid technical risks

If a game prototype fails, it should be because it’s boring, not because of a technical problem. (Except of course when the goal is technical prototyping). You want your prototypes to be finished, and allow you and your team to explore the essence, and pass this on to players.

Avoid tricky, sophisticated data structures and algorithms.

Avoid sophisticated systems and architectures.

Avoid trying to make things too fast.

Avoid technical feats that do not improve gameplay.

B. Planning and Process

Think about content

Ask yourself a few questions about the content your game will need to get a feel for its scope.

How much do you need to build?

How will you inject variety?

At what stage during development should it go in?

What fallbacks can be used? If you run out of time, have a plan to get essential content in. Will it work to make the boss simply a pink version of the level-enemies? Could boxes work instead of characters?

Plan

Work out a rough plan, and put down some time estimates.

Check your plan against the goal, and remove things that do not take you closer to your goal.

Check your plan against the essence of your idea, and verify that you allocated enough time to explore the essence.

Identify the sections where your estimates are likely to be out. Keep fallbacks in mind; consider reducing their impact / role / complexity. Think of placeholder strategies (see below).

Follow an implementation strategy, but adapt it to follow the ebbs and flow of the creative process

Here is the order I would suggest you follow. It puts the most important things first, keeping in mind (typical) dependencies.

Get something on screen

Implement top level game

Get user controls in

Implement a minimalist level

Implement toy logic

Implement game goal

Implement AI

Implement feedback

Refine

Prototyping is not coding a specification, though. Remember that there will be false starts, and that you will have to adapt. When necessary, change the plan and update the schedule.

Know and avoid time drains

Certain things just suck up a disproportionate amount of time. It’s useful to recognise these, and make sure you schedule enough time, have fallbacks, and keep it even simpler than you would other parts of the game. (Typical time drains depend of course on the type of game; the examples below are just to give you a sense of what I mean).

Controls. In actions games, controls can take a long time to get playable (never mind to getnice).

Balance. In simulation games, balancing takes a long time. Keep the number of systems low; keep the number of variables low. And leave enough time to balance them out.

GUI. In information-heavy games, the GUI can suck up all your time. Finding audio can take a long time – don’t add it unless it’s essential, or you already know where the sounds you need are.

Animation. Animation can slurp up a lot of time: consider using snap poses, or gliding when appropriate.

Procedural content generation. Tweaking algorithms for content generation can be time consuming. Unlike other algorithms, the specifications for content generation algorithms are hard to make objective.

Consider using serial development (programming pipelines)

For teams with more than one programmer, it’s common to divide a project up in components, and dish each one out to a separate programmer, so that everyone works in parallel.

There is another method, and it is worth trying it out once or twice and see if it works for your team.

With this approach, most of the code passes through all the programmers, in a staggered fashion. The first programmer will implement the broad strokes of the project; the next one will start filling in details, and so on. Instead of owning a piece of the code, each programmer owns the entire project for a time slice (these slices may overlap somewhat, of course). It works especially well if you use a lot of placeholder code.

The nice thing about the approach is that it reduces discussions about interfaces. In your time slot, if you need an interface change, you make it. It won’t break other programmers’ code because you are the only programmer. (It still works with overlapping slices, but you need more care, and a plan.)

The down side is of course the design you end up with may be quite bad. It does not matter, though, because the design is not important. It seems a bit wasteful, since there are times where some programmers don’t program.

(Of course, this is meant to split off programming tasks; it would be a shame if you do this with other creative activities. In many prototyping projects programmers are also game designers; this does not apply when you have your design hats on!)

Don’t get stuck

Several things can make you feel stuck: bugs, tricky-to-implement code, unusable and fiddly controls, sheer amounts of content, level design.

When you are in the mud, get out of it, and move on. Here are a few things you could do when stuck:

Ignore tricky bugs that do not ruin gameplay.

Cut culprit features; reduce content.

Use a simpler placeholder algorithm or approximation.

Use brute force with lookup – a handy technique to design correct, fast algorithms quickly at the expense of memory and some extra time spent outside the main loop (maybe even outside the game altogether).

Fake it. Monsters that respond to players look more intelligent than monsters that don’t, regardless of how intelligent they actually are.

Hard-code it. A long array of monster sequences is much easier to code than a sophisticated wave generation algorithm.

Hide it.

C. Code Design and Implementation

Use placeholder code

Use placeholder code wherever you can so that you can move onto core gameplay earlier. Once you have that nailed, you can systematically replace placeholder code with code that does a better job. What is nice about this approach is that once you have all the systems in and working with your core gameplay, it is much easier to prioritize tasks according to their gameplay impact.

Here are some typical candidates for placeholder code.

Controls In some games, controls are extremely important. But if second-rate controls won’t cripple the player’s experience, and it’s faster to implement, implement that first. For example, in many sliding puzzle games, the best controls allow you to use the mouse (or finger) to slide around objects. This can be a difficult scheme to implement. On the other hand, mouse selection with arrow keys or buttons can be quick to implement, allowing you to get onto other gameplay elements faster.

Feedback Feedback is important, it provides information and improves the experience. But first do something simple: dialogs and messages, colour changes, flashes or beeps.

AI AI is difficult: it’s hard to predict whether any given strategy will work. The following can be use for AI placeholders before you start implementing the final algorithm:

Random AI.

AI using simple heuristics can stand in for look-ahead AI, or vice-vera, whatever is easier.
Greedy algorithms.

AI that cannot play all possible moves.

Procedural Content If your game relies on procedural content; you can use the following types of stand-ins:

Fixed content.

Purely random content.

Approximation Crude approximations can often be very useful. Here are some examples:

Using collision spheres instead of collision meshes.

Using linear approximations for curves.

Use design Shortcuts

[USE WITH CARE] You should avoid god-like classes in production code, but in prototypes, they can save a large amount of time. Instead of having a monster and player that extends from actor, dump all the code in actor, and use the familiar switch-atrocity instead of polymorphism.

Mistrust any data structure that is more sophisticated than a dynamic list, especially if you need to implement it yourself. Focus on simple, safe, and easy to understand data structures and algorithms.

Avoid false design shortcuts

Rules for naming and organisation in prototypes don’t change.

Unnecessary exposure of data (using public fields) can bite you even in the short span of a day or two. It’s simply not that easy to remember whether setting health to zero will kill a monster, or whether you also need to destroy it yourself.

States machines (or anything that keeps track of states) almost always need more states than you think. If you try to use a shortcut instead of an appropriate abstraction, there is a big chance that you will get entangled in a buggy if-else mess.

Manage your tweakables

Make the game easier to fine-tune by keeping tweakables in one place.

Not every value needs to be tweaked; don’t be afraid to make them constants. But put them in a central place. Do not use magic numbers.

Carefully name your tweakables.

When you design a tweakable system, make sure that the exposed variables have clear and linear effects. Subtle tweakables are best hidden away (or left until the end). It’s better to make a system that is clear to understand, but cannot be controlled completely.

Write readable code

Throwaway code should not be engineered to the highest standards possible.

However, it still needs to serve the purpose of communicating your intention, especially if you work in a team. A muddle of code can waste a lot of time. The most useful things to do when writing code for rapid development:

Name things properly.

Be organised.

Avoid deep hierarchies and complicated dependencies.

Keep methods damn short.

Limit the number of “smart” classes. A smart class is anything that handles game logic. In smaller, volatile projects, it’s better to centralise logic and reserve helper classes for presentation. It makes it easier to make drastic changes. As long as you keep methodsshort.

Use implementation patterns

An implementation pattern is a standard way of doing things. As an example, here is the implementation pattern of a game’s main file:

public void Start()
{
Reset()
}

public void ResetGame()
{
currentLevel = 0;
ResetLevel();
}

public void ResetLevel()
{
DestroyObjectsFromPreviousPlay()
InitialiseVariables()
BuildLevel()
InitGameState()
}

public void Update()
{
ProcessGameFlowInput(); //Reset or next level

if(gameOver) return;

ProcessGamplayInput(); //player controls
UpdateContinuousGameState(); //movement, AI, etc.

gameState = GetGameState();

if(gameState == GameState.Win) WinGame();
if(gameState == GameState.Loose) LooseGame();
}

private void NextLevel()
{
currentLevel++;
ResetLevel();
}

private WinGame()
{
ShowMessage(“You win”);
EndGame();
}

private LooseGame()
{
ShowMessage(“You loose”);
EndGame();
}

private EndGame()
{
gameOver = true;
}

By using standards, you will reduce the time you need to spend on thinking, and then quibbling over alternatives. Implementation patterns are useful for production code too, but prototyping patterns are different: they emphasise simplicity and clarity, rather than OOP re-use and efficiency.

You can often set up patterns as templates that you can use during prototyping. If you can, do it!

(You collect or design these standards between prototyping stints – see below).

As another example, here is an implementation pattern for changing a variable’s value smoothly over time.

private IEnumerator ChangeSomething(thingToChange, initialState, finalState)
{
float timePassed = 0;
Set(thingToChange, originalState);
bool finalStateReached = false;

DoThingsAtStartOfChange();

while(!finalStateReached)
{
timePassed += Time.deltaTime;

if(timePassed >= time)
{
timePassed = time;
finalStateReached = true;
}

Set(thingToChange, Lerp(originalState, finalState,
timePassed / totalTime);

yield return null;
}

DoThingsAtEndOfChange();
}

D. Before, After, In-between

If you build prototypes regularly, you can put yourself at a great advantage by doing some stuff in-between prototyping stints.

Reflect

After you finish with a prototype, do a post mortem, and identify the good and the bad. Review your notes shortly before your next prototyping project.

Build a library of code that enables rapid prototyping

This is different from your library that’s shared between production projects. You can use techniques that are a bit slow, or make some platform assumptions, or uses other technology that you cannot normally use for production code.

As an example, we rendered the grid in many of our games by drawing on a texture pixel-by-pixel, instead of using sprites. This method is fine for prototyping, but too slow for the final product.

Identify implementation patterns, bug patterns and time sinks

After a few prototypes, you may begin to see some patterns emerge. Make a list, and use this to inform what to put in your library.

Can you codify implementation patterns as templates in your library? Could you design better data structures to avoid some bug pattern? Can you give yourself a head start on a time sink by adding to your library?（source：gamasutra）