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

论述游戏设计初期阶段的准备工作

作者:Tim Huntsman

有些游戏能够为我们带来高质量的设计和游戏玩法,但是也有很多游戏做不到这点。这是为什么呢?我发现很多游戏制作人大多信口开河,不能明确一个合适的目标,并且很多设计师还都是新手,不清楚玩家真正想要的是什么,甚至大多数开发公司都未曾面向游戏创造和执行建立一个正式的设计过程。

如今有许多关于游戏设计的书籍和杂志。因为游戏设计本身就是一种创造性任务,每个人都认为自己能够实现这一任务。而如果真的这么简单的话,我们便能看到更多拥有更加优秀的控制系统,AI,容易使用的前端界面,游戏机制(平均12岁的玩家都能够轻松开始玩游戏)以及更少的软件阻碍因素等。我的朋友就曾经面临过一个来自大型开发商/发行商的副总裁的质疑,对方问他,为何自己要将140万美元投入他的项目而不是股票市场?答案是什么呢?那就是,如果最终能够创造出一款高质量且有趣的游戏并能够即时发行的话,该投资商便能够从中获得巨大的利益。

我将把关于设计过程的这系列文章分为三大块:行动,思考和需要。而今天我将着重阐述在准备创造一款游戏时需要做些什么。

做什么:

设计师的主要任务便是设计游戏。这听起来好像很简单;但也意味着设计师应该更关注于游戏设计而不是编写一大堆感叹自己想法的文字,不能只是洋洋洒洒地写下大量具有诱导性但却毫无意义的细节内容,并且是除了自己其他人都看不懂的东西。

1.提出问题

这听起来好像很简单,也就是你需要在开始编写设计文件前问自己一些问题。当你在构思下一款畅销游戏理念的同时你必须考虑许多因素。当然了,我并不可能在此列出所有内容。有些问题是基于你当时所面临的情境(也就是其它游戏可能不需要考虑到这些内容),也有些项目需要涉及更多额外的问题。所以明确自己需要回答哪些问题便是你工作的重中之重。

当前的趋势是什么?

关于设计的当前趋势是什么?浏览一些贸易杂志,从中找出引起现今潮流的对象和人物。就像技术推动着我们能够创造出更加多元化的世界,我想玩家肯定也希望能够获得更棒的娱乐体验吧!一些富有创造性的公司便是通过

模糊现有类型间的界限而持续吸引玩家的注意。这同样也推动着我们能够朝着获得玩家的认可并揭开创造性设计的神秘面纱而努力。

WWF War Zone(from mylot.com)

WWF War Zone(from mylot.com)

像选择和功用也是一大趋势,即通过给予玩家更多的游戏控制权而吸引他们的注意,并因此提高游戏的竞争力。就像在摔跤类游戏中玩家迫切希望从头开始创造属于自己的定制摔跤手。《WWF Warzone》便是突出了这一功能,而现在THQ和EA也开始将更多“玩家权利”理念整合到自己的游戏中去。

市场营销的目标是什么?

这也可以理解为“游戏玩家的目标是什么?”这时候我们便可以寻求市场营销专家的帮助,因为他们总是能够清楚地知道玩家想要些什么。他们会进行焦点小组测试,并通过从反馈中编译数据而找到答案。同时我们还需要考虑市场的接受度。就像“复制”产品总是不如原产品卖得好。

我们可以使用何种工具?

例如,观察什么样的动态捕捉能够更好地帮助你进行动画创造。但是我并不是说“始终坚持这一动态捕捉”,而是这种数据能够帮助你建立一个好的基础,并推动你使用更加强大且更有效的动态编辑器,有效调整动作去适应之后的游戏设计。

3D程序编写和世界建造工具也是非常普及的工具,能够帮助或阻碍我们的设计过程。如果你必须快速建造一个游戏理念原型,赶在圣诞假期或游戏授权过期前尽快发行游戏,你便可以使用一些先前存在的工具,说不准你能够因此获得意想不到的好结果。

工具不仅能够帮助你建造游戏原型,也能够帮助你更好阐述你的想法。除此之外你也可以因此省去许多不必要的麻烦。循环利用技术并不是什么坏事,除非你们公司所能宣传的就只有技术而非玩法。

有些游戏适合某些特定的音乐类型,或者是专业的乐队演奏,或者是个人独奏。而我们需要做的便是仔细听他们的表演,然后从中选择合适的类型整合到自己的游戏中。有些市场营销人员便会挪出大量的开发预算去签约一些乐队或个人表演者,将他们的音乐带到自己的游戏中——但是据我的经验看来这种情况少之又少,有的话也是购买那些曾经制作过游戏音乐之人的作品。有些情况下,邀请人气音乐人创作游戏音乐可能会在网上或杂志中引起轰动,从而让游戏更加受瞩目,但是这却不足以影响用户的购买欲望,并且这种授权还可能引起对方不能按时或有效完成音乐制作等问题。这时候同步授权便是一个很好的解决方法(即你可以在游戏中使用一首歌曲,但是却不是原制作人的原音记录)。

Toonstruck(from squakenet.com)

Toonstruck(from squakenet.com)

有些公司还浪费大量的资金去邀请一些知名人士帮助游戏配音,以此作为游戏的市场营销手段。玩家是否真正关心Rob Schnider(游戏邦注:著名的影视演员)为《Fork in the Tail》配音或者Christopher Lloyd的声音出现在《Toon Struck》中?就像之前所提到的,通常情况下玩家都不会只是因想听某个名人的声音而去购买游戏。

你应该选择一些真正适合游戏的内容(或配音员),这将帮助你更好地提高玩家的游戏体验。而这也才是你真正需要关心的元素。

完成了些什么,并且是如何完成这些内容?

我们不应该去阐述一些耳熟能详的故事,也不应该再尝试一些别人创造过的内容,或者重新改造那些即将被淘汰的游戏类型。你应该展开相关研究,并从研究中吸取经验和教训。你还应该尝试着玩各种简单的游戏。你必须清楚现在市面上有哪些游戏,别人已经尝试了哪种创想,你面前的门槛有多高,你又该如何去跨越它。

2.工作设计文件

当你专注于自己的游戏理念时,你便需要开始思考你的设计文件。设计文件好比是脚本;我们必须让其他专业人员能够从中更好地了解整个产品,而不只是告诉他们如何执行自己手上的工作。

其它的娱乐产业总是会有呈现理念的明确基本规则和格式。就像从“Smith/Corona老式英文打字机”时代以来我们就遵循着“双倍行距的12-point Courier字体”格式,甚至是电视和电影也始终遵循着标准的脚本格式,所以在此明确统一的格式是一种必须的任务。

但是游戏产业却有所不同。这个产业还较年轻,暂时不存在一定的标准或原则;但是我们将不断推动并扩展产业标准与实践。简单地来说,传统总是孕育着期望。我们必须在任何问题出现在产品中之前好好解答它们。这便是创意想法维护者的工作。我们必须努力找出各种问题的答案,帮助团队中的所有成员找到他们所需要的信息并了解发生了什么,或者是即将发生什么等。

我们可以将设计文件分为两种格式:它们可以用于描写一些游戏理念并说服上层管理者,然后被永久地封存在橱柜中;或者它们也可以变成你们当地的黄页,尽可能提供所有相关细节内容,但是编写者却对此毫不关心或者根本不想去阅读这些内容。

为了更好地维持设计员工与制作团队间的交流,我们想出了一种“功能导向型”文件,以此确保所有项目参与者能够在设计发生改变时迅速获得相关信息。

就像当你在阅读制作电影脚本时会发现,在整个脚本中的任何特定内容都会出现不同颜色的页面。这些页面正是代表着从电影开始后脚本中所发生的改变。而区分不同颜色则能让演员和工作人员更好地察觉到任何变化,并保持脚本的连贯性。

与脚本一样,设计文件内容也会根据环境,人员,创造性问题的解决或制作团队等元素的变化而变化。这时候我们不仅需要明确记录这些改变,同时还需要确保那些参与相关任务的人员能够了解这些变化。

功能导向型设计文件

我们的功能导向型设计文件作为一种基本模式能够确保6名涉及设计文件的人员即时获得相关信息。这不仅是面向团队中所有成员的灵活指南,同时也可以说是一种实况文件,能够引领着我们在3款不同的游戏设计中穿梭。

我们将设计文件放在局域网中,让设计团队成员能够不断添加或更新相关信息。版本控制是一种简单的软件(在这里指的便是文书处理软件),每次只允许一个人编辑个人子文件。

这种文件本身便包含了一些能够确保事物有序的功能,包括一些强调主要项目(游戏邦注:如需要使用什么引擎,AI,游戏模式,动作等等)的标题。在这些标题下还有一些特定的子文件用于解释团队中的个人在设计中所负责的相关任务及作用。当我们明确了一个新的设计功能时,我们便能够将相关信息通过电子邮件(附加了文件的相关链接)发送给相关团队成员。而我们之所以能够这么做也是因为所有团队成员都了解这些文件内容。

子文件是以数字模板呈现出来,同时还有一些与目录内容相关的数字。如此我们便能在面向不同产品进行设计时通过功能或项目去区分这些文件。这种模板能够帮助我们获得更多功能的细节设计,帮助设计师预先明确问题的答案,并呈现出更加完整的设计而投入最终制作中。

design document-gameplay(from ansonrutherford.wordpress.com)

design document-gameplay(from ansonrutherford.wordpress.com)

除此之外基于这种模板我们便能够设计出多种版本的游戏。就像我们可以对一些设计功能进行分层,并将其分别呈现在一系列游戏内容中,同时我们也将始终推动着一些功能向前发展。

关于设计文件的总体规划便是将其链接到技术设计文件(以相同方式进行排序)和计划调度软件中(如项目管理软件)。

模板:

大多数美工人员和程序员之所以不读设计文件主要是因为:如果文件中真的包含某些实践性设计功能,它们也会被一页又一页持续段落所掩盖。也就是说,没人愿意穿过各种无意义内容去寻找自己想要的信息。这时候,模板便能够帮助我们有效地区分各大内容。

我们必须牢记,这是一种功能导向型设计文件,也就意味着这里包含了某些特定的目标,并且这些目标也被分割成一些可行的比例。

0 目录—-这里需要包含你所面对的所有内容的主标题。这里必须包含像AI,意见冲突,关卡设计,前端逻辑流程,控制输入等内容。

1 功能标题—-描写并罗列出讨论中的问题/功能。目录中的数值索引将帮助你更好地进行项目排序,并快速找到相关内容。

1.1 联系及“参考”信息——简单来说就是:接触那些设计出这些功能的人以及一些涉及到这些功能的外部文件。

1.2 目标—-以子弹列表模式罗列出相关目标,包括你在执行功能时可能遇到的问题及其相关解决方法。

1.3 执行—-你将如何影响这些功能。你需要在此通过公式,图表或流程图排出讨论中的设计功能,帮助相关人员即时了解到功能的发展与变化。

1.4 影响—-这些功能将如何影响现状。对于这种影响你不能总是通过预测去寻找答案,就像我们便通过改变现有的引擎/游戏,而以此去影响我们当前所执行的相关功能。为摔跤选手创造一个新行动便是一个合适的例子,同时我们还需要创造一个按压按钮以完成这一行动。除此之外这一标题也能够帮助我们明确所需要的额外资源,并规划出今后可能会用到的相关功能。

1.5至1.8的任务和问题:

设计师

程序员

美工人员

2D

分析员

动作

音效

每个开发团队中的每个部门都需要包含“任务和问题”。也就是说讨论中的设计师,美工,程序员或音效设计师可以直接跳到与他们相关的任务中,而无需浏览其它无关的内容。同时这也让设计团队中的成员能够在遇到问题时在此提问——尽管他们不一定会遇到那个能够直接回答他们问题的人。

你同时也想要标记下那些不合理或遭到抑制(出于任何原因)的功能。你并不需要删除这些功能,因为它们将会以自己的方式再次回到你当前的设计中或者出现在你的续集游戏中(如果有续集的话)。

就像在我们本身的例子中,我们便同时致力于多款游戏的设计。为了让读者更容易在屏幕上阅读与区分,我们基于不同版本和颜色将每个标题都扩展成3个子标题。

电子邮件和链接

通过在线设计文件,我们便能在设计,改变或放弃某一功能时通过电子邮件通知所有相关人员。除了在电子邮件中说:“我们设计,改变或放弃了这一功能”外,我们还可以添加相关链接,将读者直接带到相关页面进行阅读。

关于电子邮件的使用还有一点需要注意的是,我们必须确保项目管理者能够清楚成员什么时候以及是否阅读了电子邮件。如此才能有效地维持每个成员对于自己工作的责任性,并确保他们即时执行相关任务。这种结构同时也适合于HTML类型的文件,我们便通过使用MS Frontpage(微软推出的一款网页设计,制作,发布,管理的软件)创造了一款可行的在线文件。当然了Dreamweaver也是个不错的选择。使用该软件我们便可以通过浏览器去访问设计文件,并轻松地导航到任何我们所需要的信息。甚至,我们还可以创造美工指导手册,添加缩略图链接以及实际图片参考,并确保所有的资源都可行与安全。

游戏邦:原文发表于2000年6月30日,所涉事件和数据均以当时为准。(本文为游戏邦/gamerboom.com编译,拒绝任何不保留版权的转载,如需转载请联系:游戏邦

A Primer for the Design Process, Part 1: Do

by Tim Huntsman

For every game that sets the high-water mark in design and/or game play, there are dozens of titles that don’t. Why is that? I’ve discovered a number of possible reasons. Many games are made by people who shoot from the hip instead of taking a good and proper aim at success, many designers are relatively new to their jobs and aren’t certain what’s expected of them, and few development companies have established a formal design processes for creating and implementing a game.

Books and magazines are only now dedicating themselves to the craft of game design. Because it is an inherently creative task, everybody thinks they can do it. If that were true, there’d be more games out there with better control, better AI, more user-friendly front-ends, game mechanics that the average 12 year old can immediately pick up and play, and less games clogging the clearance bin at Software, Etc. A harsh reality story a friend of mine likes to tell regards a VP of development-type for a larger developer/publisher asking why he should invest 1.4 Million dollars in his project versus simply investing it in the stock market. The answer? The possibility of an astounding return on investment provided the game is well designed, on time, and fun to play.

This primer for the design process is broken into three separate sections: Do, Think, and Need. The first article explains what you need to do to get ready to make a game, the second looks at what you need to think about while you’re making the game, and the final piece examines what you’ll need to do the task.

What to Do:

The primary task of the Designer is to design the game. That sounds simple; it was meant to. More goes into designing a game than writing frilly paragraphs about just how cool you think your idea is, just more is required than writing a massive, hernia-inducing tome of endless and unnecessary detail that no one but the author can bring themselves to read.

Good design is about the implementation of ideas and details. To know what you need for your game, you need to know what’s going on around you. You need to know what the market might support and what the market is sick and tired of seeing. You need to know what your company (or those funding your company) may or may not want to see. In short, you need to start by asking some questions.

1. Asking questions

This is as simple as it sounds, you need to ask questions before you begin to write your design doc. There are a lot of things to consider while you’re cooking up ideas for your next platinum-selling title. By no means is this list all-inclusive. Some questions might be irrelevant to your respective situation -not all games need the same considerations- while some projects might require additional questioning. Determining which questions to ask is one of the most important parts of your job.

What are the current trends?

What are current trends in design? Scan the trade-mags and look at what and who are causing a buzz. As technology gives us the ability to push more polys, build and view larger worlds, light them in real-time, and maintain an acceptable frame-rate, we see that gamers are expecting more from their entertainment. One way that certain creative companies have kept the ongoing interest of gamers is to blur the lines between established genres. It helps us to challenge what’s become “accepted” and push the veil of innovative design.

Screen shot from WWF Warzone

Trends can also exist in things like options and utilities-how the competition is empowering the player by giving them more control over their game play environment. One standard now being called for in the wrestling genera is the need/want to create custom wrestlers from the ground up. This became the most talked about feature on the US side with WWF Warzone, and now THQ and EA both incorporate more “player-empowering” concepts into their titles.

What is marketing looking for?

This could be restated as, “What are gamers looking for?” Look to the marketing experts, they should have a good idea about what people want. They do the focus-group testing, they should be compiling data from this feedback. Also, consider what the market can stand. “Me-too” products usually sell much less than the product they’re emulating.

What current tools do we have access to?

For example, look at what motion capture did for animation. Don’t get me wrong, I’m not advocating an “all motion capture, all the time” game world, but that kind of data is an excellent way to build a foundation that your well-paid and well-respected motion editors can start from, tweaking the motion to fit the design after the fact.

3D authoring and world-building tools are still probably the most prevalent example of things that can help or hinder the design process. Preexisting tools can also give you jump if you need to either prototype a concept in a hurry or if you need to race to make the Christmas buying season before you loose the license for your game.

Tools give you a way to either prototype a design to get an idea across. They also allow you to get a job done with less hassle. Recycling technology is not a bad thing, unless the only thing your company can hype is tech with no game play.

Some genre’s lend themselves to certain kinds of music, often from professional named bands or individuals. Take a listen to what’s good, what seems to be happening, then incorporate its style into your title. Some marketing folks will fork over a chunk of your development budget to sign bands or individuals to do the music for your title, but it’s been my understanding that very seldom, if ever, will a person’s decision to purchase a title be based on the fact that someone they may have heard on the radio once did the music for the game. In certain cases having a named talent do the music might add to the “cool” factor and help generate a little buzz on websites or the odd magazine, but it’s not going to sway the consumer and it can also be a huge licensing hassle with no real guarantee that what gets written for the game will be delivered on time or be any good. If there’s any question, a good solution is to try to get a synchronization license (Where you get the right to cover the song, but not to use the original recording by the original artist) for a piece of music you’d really like in your game.

Screen shot from Toon Struck

Some companies have been known to waste a ton of cash trying to get a particular vocal talent or talents to act in their game as, unfortunately, a major marketing aspect of the title. Did it matter that Rob Schnider was the main vocal talent in A Fork in the Tail, or Christopher Lloyd was in Toon Struck? As above, more often than not most gamers won’t buy a title simply because there’s some celebrity voice actor that they button past in the first 2 seconds of hearing it in order to get back to the game play.

Get something (or someone) good that fits the attitude of the game, and it will increase the gaming experience for the player. That’s all you need to be worried about.

What’s been done and how was it done?

I talk about this later on in the “Think” section about Critical Evaluation, but this is a very important issue when you first start your design. There’s absolutely no need for you to tell a story that’s already been told, or develop a game that’s already been done, or rehash a genre that’s on the way out. Do your research and learn from that research. You should be playing games, plain and simple. You need to know what’s out there, what’s already been done, and how high the bar has been set so that you can clear it.

2. The Working Design Document

Once you’ve focused your ideas, its time to think about the design doc. The design doc acts as a script; it should be giving every other professional involved with the product a more than firm idea of what they need to know to implement their portion of the product.

Like other parts of the entertainment business, there are some basic rules and formats for how ideas are presented, as well as a few things that people no longer want to see. Publishing has its “double spaced 12-point Courier font” from the old Smith/Corona days, and film and TV have standard script formats for either television or the silver screen. These formats are not only expected, but also demanded.

Our business is a little different. It’s not quite old enough for standards and guidelines to exist, but we’re moving into the “broad spectrum formalization” for industry standards and practices.

Simply stated, tradition has bred expectation. Certain questions should be answered before the thing is sent to production. This is your job, O Maintainer of the Creative Vision. You need to answer these questions and more, as everyone on the project will be coming to you or your people for information and the lo-down on what needs to happen and, more importantly, how it’s supposed to happen.

Design documents tend to fall into one of two formats: they either loosely describe a game concept so upper-management can sign off on the idea, then get dropped into someone’s filing cabinet never to be read again OR they are the size of your local Yellow Pages, filled with every imaginable detail that no-one but the person who wrote it cares about or is willing to read.

In an effort to maintain the working lines of communication between the design staff and the production team, we came up with the idea of a “feature-oriented” document that could keep everyone on the team up to date and informed whenever a design change was made or redesigned.

If you look a production movie script, you’ll see that there are different colored pages at any given point throughout the entire script. These pages represent changes that have been made to the script since the start of filming. The colors allow the cast and crew to follow the changes and thus maintain continuity and keep everybody -pardon the unintentional pun-on the same page when updates occur.

Like a script, things in a design document will change due to circumstance, talent, or innovative problem solving on the part of management or the production team. These changes should not only be noted, but also sent out to the people whom they affect.

The Feature-Oriented Design Document

Our feature-oriented design document began as a basic form that could help keep the 6 people involved with the design document up to date. It was designed not only as a fluid guide for everyone on the team, but also as a living document that could carry us through the ongoing design of 3 different games.

We put the design document on our LAN, with the design team continually adding to or updating the document at the same time. Version control is a simple matter of the software (in this case MS Word) not allowing more than one person to work on an individual sub-document at any given time.

The document itself incorporates a couple of features that help with keeping things organized, including major headings calling out important items like what the engine needs to do to, AI requirements, game modes, motion requirements, and on and on. Under these heading are the particular sub-documents explaining the features or functions that individuals on the team have been tasked with designing. Whenever a new design feature is nailed down we can send out updates to the relevant team member through E-mail with a hyperlink attached to the virtual document for easy access by team members. We can do this because the document is being written with the whole team in mind.

The sub-documents themselves take the form of a numerated template with the heading numbers tied to the table of contents. This allows us to sort these documents by feature or project when we work on layers of design for separate products. The template helps push for a more detailed design for each feature and also helps the designer answer questions up front, allowing for a more thorough design when the project hits production.

This template also allows us to design for more than one version of the game. Some design features have been layered to appear over a series of releases and as such, you’re always on the same page with whatever feature you’re thinking to forward.

The master plan for the design document is to have it linked with both a Technical Design Document that’s arranged in the same manner and some sort of scheduling software like MS Project. This has the added function of allowing us to asses any impact to milestones or budget new design features may have.

The Template:

The major reason most artists and programmers don’t read the design document is that, if there are any practical design features contained within, they are usually buried in page after page of ongoing paragraphs. Simply stated, no one wants to weed through it to get to what they need to know. The template, in this form, serves the major function of being digestible in small relevant chunks.

Remember, this is a FEATURE-ORIENTED design document, which means that it is put together with certain goals in mind, and these goals are broken down into doable bits.

0 TABLE OF CONTENTS – This needs to contain EVERY major heading that you’ll be dealing with. It should include sections like AI, collision, level design, front-end logic flow, controller input, and the like.

1 FEATURE HEADING – Describes and numerates the issue/feature in question. The numerical index, established in the TOC allows for easy finding and sorting once the project is underway.

1.1 Contact and “See Also” Information – Straightforward: Point of contact for who designed the feature and what other documents it relates to outside of this one.

1.2 Goals – A bullet list of associated goals including problems you may encounter implementing this feature and possible solutions to said problems.

1.3 Implementation – How you’re going to affect the feature. This is where you’d include formula, diagrams, or flowcharts that layout the design feature in question that all relative parties may need to know/follow to get the feature up and rolling.

1.4 Impact – How this feature will impact the current status quo. You can’t always crystal ball this, but in our case we’re making changes to an existing engine/game, so some changes do affect the way we’re currently implementing some features. An example of this would be having a new action for a wrestler to do, and needing a button-press to pull it off when we’re already overloaded here.

Another use for this heading is to help you identify extra resources you may need, and schedule relevant needs to bring the feature into line.

1.5 to 1.8 Tasks & Questions for:

Designers

Programmers

Artists

2D

Modelers

Motion

Sounds

There must be “Tasks & Questions” sections for each arm of the development team. This allows the Designer, Artist, Programmer or Sound Designer in question to skip straight to the task relevant to them without having to filter through all the other text. This also lets the design team ask any questions they may have at a time when they might not have access to the person that could immediately answer it.

You’ll also want some way to tag features that have been dropped or held back for whatever reason. You don’t necessarily want to delete those features, as they may make their way back into the current design or appear in the sequel if you’re doing one.

In our particular case, we’re working on the design for several titles at one time. Each heading is further expanded into 3 sub headings-one for each version-and color coded to make reading and separating them on-screen a little easier.

E-mail and the Hyperlink:

With the design doc online, we’re able to send intranet e-mail to all concerned parties when a feature is designed, changed, or dropped. In addition to the email saying, “This feature has been designed, changed, or dropped,” we can also add a hyperlink which, when clicked upon, will take the concerned party directly to the page(s) they should be reading.

The e-mail has a secondary consideration in that the Project Manager will know when and if the Email is being read. This helps in maintaining team accountability for what each person’s job should be, and how they need to implement it when the time comes. This kind of organization lends itself to a HTML-type document as well. We’re currently setting up just this kind of accessible, online document using MS Frontpage. You could also use Dreamweaver if you were so inclined. This allows anyone with a web browser to access the design doc and very easily navigate their way to whatever piece of info they need. Even better, you can do things like create art bible’s, complete with linked thumbnails and actual photo reference on the network, making sure all or your resource is available and protected.

The next section (THINK) will go deeper into asking questions about what you’re supposed to be doing as a designer. This also includes my list of “Nevers,” garnered over the years both from friends in the industry and from simply doing things the hard way.

Tim Huntsman has been with Acclaim Studios, SLC for over 4 years and is the Lead Designer for Acclaim’s next-gen wrestling title. He has worked on the ECW wrestling franchise as well as the genre-defining WWF Attitude for PSX and N64, projects that taught him more about professional wrestling than he ever thought he’d know. When not working on games and their design, he’s playing guitar in experimental projects, writing various forms of fiction, painting in the Sumi-E style, and fencing (with swords, not wooden planks.) (source:GAMASUTRA)


上一篇:

下一篇: