作者：Jorge Diaz

人人都有坏习惯。可以说，坏习惯是人们日常生活中的一部分，不管我们是否喜欢，它们都将影响我们的日常工作。到底应该如何定义坏习惯？

坏习惯可以指那些定期重复且下意识出现的负面行为。游戏开发可以说是一个重复循环的周期或过程，但是我们要如何定义设计坏习惯？这个问题就跟定义游戏设计师一样困难。

我们可以说游戏设计是关于设计游戏内容和规则的过程，而“内容”则包含声音，关卡，对话等方面。我将在这里列出我所知道的20个不良设计习惯，它们也适用于游戏之外的一些创造性领域。

游戏设计的坏习惯（排序不分先后）：

1.执拗于某个理念

我们可以在许多方面中看到这一问题。并且促使这一问题的原因也不只有一个。毕竟我们总是很难判断什么时候某个功能还有更大的作用或者什么时候我们需要移除这个功能。而在这里我们所面临的挑战在于，我们自己的工作激情将直接影响设计的成败。

Tom Cadwell（Riot Games设计总监）将这点描写为“难以割舍”的陷阱。他认为风险评估能够帮助开发者做出最合适的决定。而从设计师个人的角度来说，他们必须明确，没有哪种理念（不论好与坏）会直接决定最终产品成形，而且这些理念也不能反映他们的创造能力。

2.未明确设计范围

如果不能在一开始就明确设计范围，将会导致生产过程中出现许多不必要的麻烦，并最终影响游戏的成形。如此不仅会出现耗时，误差等情况，还会让整个开发过程变得困难重重，因为你并未确立能够参照的衡量标准。

如果预先规划了标准的设计模式，团队成员便能够基于一些较小的目标进行迭代，如此便能够明确制作前期所需要的时间安排了。我们必须基于一个宏观或微观层面去衡量任何任务所需要的时间和成本，并将此范围应用于所有的设计任务中，而不只是将其当成是针对特殊设计要求的工作。

3提出不可靠的设计

不论出于何种原因，在游戏的制作过程中我们总是需要删除某些设计内容。我们必须保证设计的灵活性，能够在不影响其它部分的前提下进行调整。并且我们需要投入更多的精力去识别设计所面临的风险和可衡量的选择。

假设你正在设计一个不存在更多可改变空间，或者直接影响项目完工的系统，那你就要确保这个系统必须获得团队中所有成员的认可，让它获得足够的重视。而往往，过度相互依赖是很多团队容易忽视的一种坏习惯。

4.缺少自我批评或者批评过甚

我们总是很容易选定一些对设计有帮助的内容，但是却很难确保设计能够给玩家留下深刻的印象。自我批评就像是一把双刃剑，有时候它能够帮助我们更好地达成共识，但是有时候它也会让我们深陷于某些问题之中。

特别是时间有限的情况下，更需要谨慎地处理自我批评，因为这时候你可能不会愿意浪费更多时间于设计中而选择继续前进。但是有时候，欲速则不达。

另一方面，我们也有可能出现批评过甚的情况，特别是在开发初期。我们必须清楚，过度的批评将会导致我们过多地关注于某些内容而忽视了其它内容。要尽量接受任何新观点，针对那些风险较低的内容更是如此。如果设计达到了预期的目标，你便可以将其早前的内容与最近更新的内容进行更加客观的比较。

不论是缺少批评还是批评过度，如果你所面临的内容过于客观化，你最好能够请求别人的帮助，听取其他人的（如用户测试者）的看法。

5.忘记设计目标

设计目标犹如灯塔，将指引着我们做出正确的设计决策，但是在混乱的开发过程中，我们总是容易错过这个灯塔。

当你开始执行任何一项任务时，让自己能够始终遵循设计目标。确保自己能够很容易便找到这些内容。与设计团队讨论设计目标，以便他们在评论和展示过程都始终牢记这些目标。你可能会因为进行测试而决定改变某些特别的目标，这时候就必须即时通知团队成员，并与之一起回顾早前的工作。

6.为自己而非目标用户设计游戏

这是设计目标中常见的一种错误，通常是由人们本身的存在感而引起的。而这与为目标用户设计游戏的不同点在于，如果我们是为自己设计游戏，那么我们所确定的设计目标很可能与预期用户的需求相悖。除非你自己也是游戏的目标用户，但即便如此，我们也很难平衡玩家与我们游戏习惯的差异。

问题的根源便在于，创造游戏体验是一个复杂的过程。我们总是很难保持最终游戏内容的客观性，因为我们总是带着一种偏见去创造游戏内容，而这有可能不是终端用户真正想看到的游戏。

纠正这个坏习惯的一大方法便是更好地理解目标用户的游戏体验。可以通过测试，论坛讨论，QA交流以及专家评审等方法进行改良。

7.完全无视竞争产品

了解竞争对手与其它同类型的游戏是非常重要的过程。有时候，这种调查研究还真的吃力不讨好的苦差事。而创造研究指南并评估同类型产品能够帮助你更好地达到目标。并且这么做也能够帮助你避免一些坏习惯，如为自己设计游戏等。

8.遗漏新手教程/简介

新手教程或简介是游戏机制、内容给玩家的第一印象。它们将直接影响玩家的游戏体验，并与游戏其他部分的内容存在区别。

通常情况下这些简介不会只出现一次，它们将会随着游戏引进更多新功能和内容时重复出现。因为这种简介能够将玩家更好地引进全新的世界（游戏邦注：包括故事，图像和声音），所以我们必须更加深思熟虑地针对于目标用户进行设计。

很多人都因为设计新手教程/简介太过于繁琐而故意避开或忽视这些内容。为了避免这些问题，我们必须确保在游戏开发过程中就要重视新手教程/简介的设计任务。

如果在规划阶段忽视了新手教程，那么可能出现的后果将不再只是形成坏习惯了，而是会导致试验性生产过程中缺少关键需求。

9.设计负荷

有些设计师常误认为充满大量功能的设计就是优秀的设计。问题在于，他们难以判断什么时候应该添加新功能，或者删去不必要的功能。通过调查研究、专家评审，列出设计目标或进行原型设计能够帮助设计师淘汰那些不必要的内容，并挖掘出设计中的“乐趣”核心。

我们必须牢记，设计本身也会越变越复杂，在有些功能涉及到其他领域的知识才能完工时更是如此。

一开始便添加更多功能并不能够保证解决游戏机制的问题。这么做可能导致的唯一结果是开发者不得不花费更多时间去创造游戏原型。设计的核心目的是尽可能简单地向玩家传递游戏内容。朋友曾告诉我：“如果你不能将游戏玩法概括为2行的内容，那就说明你的游戏过于复杂。”我认为这是一个良好的指导原则。

10.繁琐的文件内容

撰写密密麻麻的文件内容或列表是对人们阅读水平和理解能力的挑战。有时候游戏所涉及的文件数量非常之多，而这时候我们便更加难以确保这些文件的可读性。随着功能列表的发展或变化，我们需要做的是保持这些内容在文件中的更新。

我发现，图片可让文件内容更加简洁，模块化也有助于解决这个问题，可以方便不同群体阅读和使用文件。我们可以分解功能的规格，或者做出特殊标记以帮助不同对象（游戏邦注：包括程序设计人员，美术人员以及用户）寻找，评价或编辑他们所需要的信息。

当你将描述内容分解成小部分内容时，你必须确保读者能够轻易找到你的设计目标（或者功能要求），从而帮助他们理解这些内容与最终游戏之间的联系。

11.只是为测试而测试

如果你进行测试并获得以下结果，那么这也是一种坏习惯的表现：

*只是想通过测试证实一种意见。

*只是想借此保全面子或者所获得的结果没有实际作用。

*获得一些对团队无帮助的内容或结果。

开发团队必须有规律地针对预期用户进行游戏测试；并且必须牢记，测试的目标是理解特定玩家的游戏体验以及他们对游戏的看法。最理想的测试结果能够帮助你创造出一款得到优化的成品游戏。

12.低估目标用户

不同人会用不同方式去体验游戏。不要认为那些不理解游戏功能或者过不了某些关卡的测试者就“没有能力”，“不会玩游戏”。实际上，如果正视测试者所遇到的这些限制因素，你便能够进一步调整游戏，而创造出更易大众使用的最终产品。

你真正需要改掉的坏毛病是低估用户所提供的数据。著名的易用性专家Jakob Neilsen认为，根据统计，15个用户中的前5名用户能够找出85%的游戏易用性问题。我认为，如果玩家不能够接受或理解游戏功能，这种方法可能也就不再那么有效了，但是最重要的还是，不要让自己的自尊心阻碍了客观公正的评判标准，一定要正视玩家的观点。

13.闭门造车地设计游戏

为了快速创造出游戏功能或内容而忽视了其它领域的内容（包括编程和图像）便是需要改正的坏习惯之一。其它领域的技术目标和美学目标也很重要，所以进一步讨论这些内容能够帮助你强化开发团队并完善整体游戏。尽可能在设计任务中安插具有跨学科知识与技能的设计师。

要经常与团队中的其他成员讨论设计中任何可能发生的调整，尤其是与工程设计人员和美术总监，以判断不同领域间存在的意见分歧。切记，越快并不代表越好。

14.因“调查研究”而分心

很多时候，“调查研究”往往只是一种借口，尤其是当你表示目标素材（如书籍，游戏或电影）太过吸引人而导致你耽搁了其它生产工作时。

有时候我们总是很难判断何时该停止搜索并开始进行生产。设定研究目标并坚持写研究日记能够帮助我们更加集中注意力。我们确实需要偶尔释放压力。但切记不要让过多的“研究”影响了其它工作进程，或者耽搁了自己的发展。

15.回避评价

如果团队中并未设置观察评价政策，开发者便很容易染上这一坏习惯。评价确实需要我们投入一定时间和精力，并且有时候还会出现返工的情况。不同任务和项目需要涉及评价工作的人员和时间也不同。事后评价能够帮助那些不理解迭代过程，并且混淆了最终产品与早期游戏原型的成员更好地理解游戏。

通常情况下，你的同事需要经常帮你评价工作。Tom Cadwell认为过久地延迟评价是我们应该重视的一大问题。他鼓励开发者尽早以一种积极的方式去创建评价体系，并欢迎任何态度的评价。而如果有意地避开评价将会导致设计缺陷，并最终影响游戏的质量。

16.把琐事当借口

在这里繁忙的工作是指一些不断循环的小任务，并且是可以自动完成，委任给其他人或者暂时延迟的琐事。而有些设计师认为完成这种“繁忙的工作”能够给他们带来成就感。

如果缺少了自动化过程，开发者将不得不面临整体游戏制作的延迟，或者他们会将琐事当成是推迟或避开一些即将发生的任务或问题的借口。

我们要善于把握高效率与浪费时间的界线，区分究竟哪些事情属于琐事。而通过进程评价和时间追踪，设计师能够进一步明确哪些方面值得自己投入更多的时间和精力。

17.设计停滞，害怕未知或失败

为了进行迭代，创新与优化而反复使用同一种类型的设计。设计师通常会为了避免一些不可预期的结果（而并非为游戏或用户着想），反复使用之前的内容。

任何个体或者团体中的成员只要通过自我反思，便能够发现这种过度依赖性会严重耽搁游戏设计的进程。但是人们总是畏惧改变。我们在创造游戏原型时可以使用的一种技巧便是遵循“多次尝试，尽早发现问题”这一格言。这样你的团队成员们便能够尽早发现何时真正需要创造新设计。

18.从不玩自己的游戏

任何人都不应该以太忙为借口而不尝试自己创造的游戏。时间限制，缺少兴趣，充满漏洞或者质量低劣都可能导致我们不愿意玩自己的游戏。设计师很容易养成这一坏习惯，特别是在测试硬件或者面对访问受限的情况下。

我们可以通过时间管理或者识别并移除那些影响游戏访问的障碍而解决这些问题。

19.自卫型设计意识

自卫心理将会进一步渗透到生活中的方方面面，也包括工作。特别是在某些关键时刻，设计师更容易发生这种自卫行为。并且，并不是那些非常顽固的人才会养成这种习惯。压力以及其它元素会在我们的工作中砌起一道无形的墙，而阻隔我们与别人进行交流与合作。

提高倾听与交流技巧能够帮助我们更好地理解并传达信息。

20.忽视事后检查

为了进一步判断项目执行过程中的好坏情况，我们总是需要在开发中的多个阶段进行事后检查和阶段分析工作。因为我们在处理这些问题时总是会加倍紧张，所以更应该小心谨慎，避免造成敌意或批评。

并且我们不能以不方便为由忽视这种自我评估的过程。随着时间的流逝，我们总是很难唤回人们对于过去工作的记忆。如果你是在一个较大的开发团队中工作，那么在纸上记录事后检查或者召开小组讨论便是非常有效的方法。

事后检查数据多为主观性的结果，所以我们不应该将其作为规划未来发展的唯一标准。而漏洞数据库，预算拨款以及时间追踪工具能够为讨论中所得到的问题和假设补充更多细节。

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

Understanding Bad Habits in Game Design

by Jorge Diaz on 02/06/12

We all have and share bad habits. They are a part of everyday life and as a result they will develop in our line work whether we like it or not. How do we define a bad habit?

For our purposes we will say that bad habits are negative routines of behavior that are repeated regularly and tend to occur subconsciously. Habituation is an extremely simple form of learning that can sometimes be compulsory.  Habitual behavior often goes unnoticed in persons exhibiting it, because a person does not need to engage in self-analysis when undertaking routine tasks.

Notice the last part of this definition “routine tasks”. If you think about it, game development is measured in recurring cycles and processes, so it is no surprise that there exist bad design habits.  But how do we define bad design habits? The answer can be as difficult as defining what a game designer does?

Well for our purposes we will say that a game design is the process of designing the content and rules of a game. The term “content” can be anything from sound, to levels, to dialog etc. Thus instead of referring to any specific job description we’ll look for those “unnoticed behaviors” that can be specific to a majority.  It is very likely that some of the items listed may apply to other creative disciplines outside of games.

The following unsorted list of bad habits focuses on mainly Game Design. It was compiled from the feedback of experienced designers as well as from other sources cited at the end of this document.  It is my hope that presenting such a list can help generate discussion and debate as well as new understanding.

Bad Design Habits (unsorted):

1.Unwillingness to let go

I have heard this issue come up in many ways. Its driving motivator is not limited to a single individual. Over all it can be hard to determine when a feature needs more time or when it needs to be removed.  The challenge may line in the fact that successes and errors in design can be equally driven by the excitement for our own work.

Tom Cadwell (design director Riot Games) described this as the “Too Awesome to cut” pitfall.  He believes that risk assessment can be a powerful tool in helping make this determination.  On a personal level a designer should understand that, for whatever reason, not all ideas, be them good or bad, will make it into the final product and that it is not a reflection on their ability to be creative.

2.Not planning the scope of a design

Failing to scope the design properly from the beginning will lead into many issues during production that can affect quality and the ability to complete the game. The contributing factor is that determining scope can be time intensive, error prone and becomes more challenging when there is no available data to measure against.

If the design is kept modular the team members can iterate on mini-milestones that can confirm or deny scheduling assumptions in pre-production. It is important to understand that measuring the expected time or cost for any task can be done in a macro or micro level and applies to all design tasks and is not job specific to design leads.

3.Designing a House of Cards

For whatever reason there will always be need in production to cut something out of the design. Our designs should have flexibility to account for change without falling to pieces. Identifying the risks and scalable options for your design will require effort.

If you are designing a system that has very little room for alteration or is integral to completing the game then this system should be agreed on by team consensus so that it receives the appropriate amount of attention.  The bad practice is working in too many critical interdependencies which are not visible to the team.

4.Not being Critical enough or Being Too Critical

It can be very easy to settle on something that works well enough for a tasks but does not have the right elements to make it memorable. Self criticism is a two edge sword and it is as easy to go with consensus at times as it is to become get stuck on a single item.

Be wary of not being critical enough when time is a constraint and you would rather move on than spend more time on a design.  Faster is not always better.

On the other side of the spectrum, it is easy to be overly critical of work, especially in its early stages.  Beware that excessive criticism can devote too much effort in one area of the design while neglecting others. Try to keep an open mind to new ideas, particularly when the risk is low. If the design satisfies its intended goals set a time to come back to it when it can be more objectively compared to the most updated content.

Whether it is too much or too little criticism, if one is too close to the material to be objective it is best to ask for help and fresh set of eyes (ears or user-tester).

5.Forgetting your Design goals

Design goals are the beacon that steers our design decisions and in the chaos of development it is very easy to lose sight of them.

Always establish and refer to your design goals when you begin a task. Keep them close where they can be readily available. Discuss design goals with the team so that they too can be aware of them during reviews and presentations. If any particular goal has to change, perhaps as a result of testing, be sure to update the team and to review your previous work.

6.Designing the game for yourself instead of the target audience

This is a very common mistake that perhaps can be tied to design goals combined with our sense of ownership. The difference is that, when we design for ourselves, our design goals are less likely to align with the intended audience. The only exception is when we are the intended audience and even then it is tricky to accommodate play styles.

The root of the issue is that creating a game play experience can be a complex task.  Objectivity in final tuning it’s very difficult to maintain because the way we perceive the content we make is inherently biased and different from the end user.

The way to correct this habit is to get a better understanding of how the game is experienced by the target audience. Focus testing, discussion boards, QA interactions and peer reviews can be good sources to use.

7.Not playing, reviewing or researching competing products

Understanding one’s competition or other games in the genre is an important task that should not be neglected. Sometimes this research can be viewed as expensive, immeasurable or as an unnecessary or undesirable chore. Creating guidelines for researching and reviewing products in genre helps create achievable research goals. It also helps us avoid other bad habits such as designing the game for ourselves.

8.Forgetting the Tutorials/Introductions

The tutorial or introductory section of a game will be the player’s first impression of the game-play mechanics and content.  The outcome of this experience is one that directly affects the player’s ability to experience and contrast the remaining content.

These introductions do not all happen in one place and will recur as more functionality and content change over game-play time.  Introducing the player to new worlds (also story, graphics and sounds) requires us to design for our audience and requires us to design in a more deliberate manner.

For this reason tutorials/introductions can be perceived as unwieldy or stressful and their design is then avoided or neglected. To avoid this issue it is important that tutorials/introductions maintain a significant priority status during production.

If tutorials are constantly missed during the planning phase then the issue is not necessarily a bad habit but a side effect of lacking a key requirement during preproduction.

9.Over Designing

There is a point in every designer’s life where a good design will be misunderstood for a feature-filled design. The problem is that it can be hard to determine when one must add to, subtract from or outright remove a game feature.  Research, peer reviews, design goal listing and prototyping should help designers peel away at unnecessary layers and get to the core “fun” aspects of their design.

Remember that Designs have a tendency to grow in complexity on their own. This is especially true when other disciplines ask for features to enhance the way they will contribute to completing feature.

Adding more features in the beginning is not guaranteed to correct issues in a game-play mechanic. If anything it only guarantees it will cost more time to produce a prototype.  The core purpose of your design should strive to be as easy to convey as possible. A friend of mine told me once: “If you can’t explain how something works in 2 sentences it’s too complex”. I find this to be a good guiding principle to strive for.

10.Dense Documentation

Writing dense documentation or lists that is challenging to read or parse is both a bad habit as well as a rookie mistake.  The amount of documentation that goes into games is massive and keeping it readable can be tedious at times.  As feature lists grow or change it can become a real feat to stay up to date with the documentation.

When trying to make documentation leaner I find it helpful to use graphs, lists and sketches. Modularity will also help with this problem, specifically understanding the various audiences that use your documents. The specifications for a feature can be broken down or labeled in a way that makes it easier for specific parties (programmers, artist and clients) to locate, comment or edit the information they are looking for.

As you break down the description into smaller chunks make sure that readers can easily find your design goals (or feature requirements) to help them understand how it fits into the final product.

11.Focus testing for focus testing sake

It is a bad practice when focus testing and its results are either:

Distorted by the desire to validate one opinion.

Performed to keep up appearances or the findings are not acted upon.

Left undocumented or handled in a manner that it is not available to the team.

It is very important for development teams to regularly focus test their game with its intended audience. It should not be forgotten that the goal of focus testing is to understand and document how specific audiences perceive and play the game. Ideally the results from testing should be acted upon to produce a more polished end product.

12.Underestimating your target audience

Different people will experience your game in different ways.  Do not assume that a tester who doesn’t understand your feature is “dumb” or that a tester who can’t do something is just “bad at games”.  Their limitations shed light into the accessibility of your product.

The main take away is to not underestimate the data.  Renowned usability consultant, Dr. Jakob Neilsen believes that statistically the first 5 users out of 15 will be able to find 85% of your usability problems. Personally it always hurts when a feature is not received or understood well but it is important not to let pride get in the way of being objective.

13.Designing in a Vacuum

It is bad practice to not include the various disciplines (programming and art) into the design process in other to quickly turn out a feature or content.  The technical and aesthetic goals of other disciplines matter and discussing the issues will help strengthen both the team and overall product. Beware of scheduling a designer into a design task devoid of interdisciplinary input.

Always discuss possible changes to the design with the other members of the team, particularly the Engineering and Art leads, to determine ramifications on other departments. Faster is not always better.

14.Become addicted to your “researching the source material”

“Research” can become a common excuse, especially when the source material (be it books, games or movies) is very enticing and can be used as a means to procrastinate on other production work.

It can sometimes be hard to tell when to stop consuming and begin producing. Setting research goals and keeping a research journal can help keep one centered.  We all need ways to relieve stress from time to time. Be wary excessive “research” may hurt the work of others or your own standing among your peers.

15.Avoiding reviews

This will probably be more common in places where there is no set or observed review policy. Reviews do take time to complete and often require rework. Figuring out when and who to involve will vary between tasks and projects.  Late reviews work well for an audience that doesn’t understand the iterative process and may confuse an early prototype with a final product.

Typically your peers should review your work early and often. Tom Cadwell described postponing reviews for too long as the “Grand Unveil” in his list of pitfalls. He encourages framing early review in a positive productive manner and a mistake-forgiving culture. Intentionally avoiding a review for whatever reason can lead to design defects and will affect the quality of the work.

16.Hide in busy work

Busy work here is defined by repetitive small tasks that could perhaps be automated, delegated or postponed. Some designers may experience great accomplishment if completing this “busy work”.

The risk is that the lack of automation may be in fact setting the overall product back or that the “busy work” serves as a means to procrastinate or avoid tackling an impending task or issue.

When it comes to busy work there is a fine line between being productive and wasting valuable time. Process reviews and time tracking can help point out areas where a designer’s time will be more effective.

17.Stagnate Design, fear of the unknown or failure

Often a type of design is revisited, reshuffled or copied several times for the purposes of iteration, innovation and polish. It can be tempting to re-cycle the previous work and features not for the benefit of the game (or audience) but rather to avoid dealing with the unexpected.

This issue can be very perceptual and it’s up to the individual, or group of individuals, to self examine the reasoning for the type of over-reliance that can lead to design stagnation. Change can be scary. A technique used when prototyping is to follow the motto “Fail early, fail often”. This will hopefully help your team know of it’s time to re-invent the wheel or not.

18.Not playing your own game

One would think no one should be too busy to not play their own game but this is not the case.  Time constraints, lack of interest, buggy builds or unpolished quality can make strong arguments to steer clear of one’s own software. This habit can also form over time specially when testing hardware or access is limited.

The solution to developing more discipline in this area can be time management as well as identifying and removing the obstacles that may prevent one from accessing the game.

19.Design Defensiveness

Being defensive can expand into all aspects of our lives including our work. I find this habit to be one that gets particularly common during peak crunch time. The challenge is that a person does not need to be necessarily stubborn or defensive to develop this habit. Stress and other factors can build up the pride in our work into a wall that can hurt our ability to work together.

The practice of listening and communication techniques can help improve the way we perceive and express information.

20.Postmortem Neglect and Misuse

Postmortems and critical stage analysis occur at various stages of development in order to bring out good and bad practices within a project.  Tensions can be high during these events and they need to be handled carefully so that they can bring closure and innovation as opposed to animosity and cynicism.

It is as bad to neglect these self evaluation processes just because they are not convenient. As time passes it will be more difficult to capture people’s recollections of events.  Paper postmortems followed by small group discussions can be useful when the development team is too big or too busy.

Postmortem data will be mostly perceptual and one should avoid using it as the single metric for planning future project. Bug data bases, budget allocations and time tracking tools (such as Personal Software Process) will fill in the details into the issues and assumptions brought up during the discussion.

My thanks to Brandon Sheffield, Dan Tanguay, Leander Hasty, Adrian Earle, Jonathan Mintz, Bret Dunham, Jonathan Russell , Mathew Goldstein, Jon Meschino, Tom Cadwell, Luis Barriga and Eric-Jon R?ssel Tairn.(source:GAMASUTRA)