2006年8月31日

八月七夕.预感

昨天晚上是今年的第二个七夕,我和小冯同学乐呵呵的趴在电脑前玩DOTA.他杀了2个
人,死了8次,我直夸他有进步,他眉开眼笑的,然后一转头又去摆弄3D引擎改2D引擎.

工作没什么眉目,事情可以分成两个方面来看.

一方面是我能力不足,英语几近于不会,只是勉强看点日常会话的程度,程序不能写,美
术不能画,然后还没有什么拿得出手的作品,去外企一个照面下来就问:"请问你在过去
的从业经历中有什么能证明你创意的商业作品?".我张口结舌,心想:妈的,国内公司不
是张口就是执行如何,创意无用么,这下把老子坑了.接下来在英文答卷环节中就被三振
出局了.

另一方面,自从昱泉好死不死给我来个高层招聘意向出错这种事情之后,国内公司也突
然消声匿迹,上海我是不想去了,北京也没几个公司招人,一眼望去都是些不知道什么时
候冒出来的小公司,看看他们的招聘要求就可以想见这些公司的结果.目标从许邦那件
事以后我就没太大兴趣,何况现在的招人要求摆明是要做赛车休闲游戏,像素和完美倒
是挺好,可惜简历发去石沉大海,不知道是我条件太糟糕还是对方人事效率问题...估计
后者的可能性不大.

刚巧朋友叫我和他一起做些事情,我也颇为意动,虽然会有些实际的困难,毕竟也算是自
己给自己做事,刚好我对这方面持续关注了很久,也算有些想法.接下来可能会暂时离开
游戏业一段时间,和朋友在一起做事,享受下生活的乐趣,学习些东西,增长些见识.

回想这两年,往往夜不能寐,心上百转千徊,至今一事无成,却也有滋有味.总的来说,我
不后悔.

--
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/

游戏平衡和游戏数值系统可调整性(草)

1 游戏平衡
1.1 什么是游戏平衡
SidMeier 曾经说过:"一个游戏是很多有趣的选择的集合。"因此得出的是如果游戏失
去平衡,就会减少这些选择而影响游戏性。一个理想的游戏应该经过一系列的选择,
最后以胜利或其它完成的条件结束。有时一些选择明显成为唯一的选择,或明显是无
效的。如果在某一阶段,游戏出现仅有唯一的选择,而游戏却没有结束,就说明游戏
的平衡性有了问题。
比如说在RTS游戏红色警戒当中,使用苏军的坦克加激光塔推进战术,是很明显的最优
策略:威力大,造价中等,能够快速出现,不易死亡。导致这个游戏在不同的玩家手
中千篇一律:造坦克、造电厂、造激光塔,一路推过去,胜负取决于谁按动鼠标的速
度较快而不是谁的策略较优。于是这个游戏就失去了它的魅力,游戏没有提供给玩家
多少有用的选择,虽然还有飞机、步兵等选项,不过他们比起坦克激光发射器来说,
没有用。
1.1.1 玩家对NPC的平衡
在单机游戏和网络游戏当中都有玩家对系统角色(NPC)的游戏内容,最常见的就是玩
家角色与系统角色之间的战斗。
当NPC在玩家通过努力可以被打败时,这里的努力是指玩家调整自己的战斗策略或者获
取较好的游戏装备甚至与通过提高等级,我们说玩家与NPC之间达成了平衡。
当玩家不费什么力气,很轻松就能打败敌人时,游戏出现了轻微的不平衡,因为这些
NPC并没有给玩家提供挑战的乐趣,如果玩家不是出于搜集物品、提升等级之类的目的
主动寻找这些很容易打败的敌人,那么这些NPC只起到了烦人的作用。
当玩家无论如何也无法打败一个本可以打败的NPC敌人时,这给玩家造成了强烈的挫折
感,就是说游戏出现了严重的不平衡。
1.1.2 玩家对玩家的平衡
在网络游戏当中,玩家与玩家之间经常发生对抗,这时玩家与玩家之间的平衡就变得
至关重要。
具体到单个玩家或者单个玩家职业在对抗当中稳胜另外的某种玩家不是不平衡,但这
就要求有另外的玩家或者职业能够在对抗当中胜过他,至少是存在胜过他的可能性。
如果某一种类型的角色(某种职业、配点方式、装备组合)在游戏中绝大多数时候都
能占据优势,就会导致大多数玩家选择使用这种类型的角色进行游戏,其他类型的角
色就失去了存在的意义,玩家的"有用的选择"变少了,所以说这样的情况是不平衡
的。
当玩家发现了一种占据绝对优势的游戏方案时,这种方案很快就会在玩家当中蔓延开
来,大家通过使用这种方案的体验,觉得自己已经获知了这个游戏最终的"诀窍",这
个游戏在他们面前已经失去了研究、把玩的价值,接下来很快就会有大量的玩家流
失。
而我们所要做的就是尽力发现这种情形,减少这种情形,最低程度要做到改善这种情
形时不会严重影响到玩家的游戏体验。
1.2 不可能在设计初期就达到完美平衡
很多游戏设计师迷信在游戏设计初期通过复杂的计算,能够得到一个"完美的平衡",
或许这种完美的情况是存在的,不过在我多年的游戏经历中并没有感受过这种情况,
当然,石头剪子布和1-1=0这两种情况除外,他们都是极简单的情况,但是我们知道,
现代游戏比这要复杂的多,玩家们的要求不止于此。
游戏平衡的典范之作"星际争霸"在发行之初有着严重的平衡问题,人族的士兵移动速
度太快,真正做到了来去如风、侵略如火。虫族和神族在这种频繁的跑带打战术中消
耗疲于奔命。幸运的是暴雪及时发现了这个问题,在接下来的版本更新中降低了人族
的移动速度,然后就是虫族的长时间称霸。暴雪的版本更新中对游戏数值的调整从来
就没有停止过,直到1.10版,才算达到了平衡,即使如此,由于人族部队具有射程优
势,在操作上的提升空间较大,在星际老手之间的争斗人族仍然占据一些微小的优
势。
精品游戏公司的数值典范之作在游戏数值方面尚且如此,其他游戏更是可想而知,把
一切希望寄托在"完美设计"上是不现实的。
就我的了解,战斗伤害输出可以使用每秒伤害输出这样的数值加以比较,但在结合了
移动速度、操作难度、特殊技能效果等因素之后,每秒战斗伤害输出并不能准确衡量
战斗效率,就这个问题我也咨询过一些游戏数值设计师,他们对此的回答是:"有时
候,需要一点对游戏的直觉",这是一个不错的答案,不过让完美的平衡去死吧。
1.3 如何达到游戏平衡
游戏平衡对一个游戏的生命周期是如此重要,我们如何才能达到游戏平衡呢?
上市之前的大量测试是必不可少的,只有这样才能在游戏到达玩家手中之前发现一些
隐藏着的平衡性问题,而平衡性测试不同于功能性测试,很多战斗策略在玩家手中被
创造出来,在游戏到达玩家手中之前很难被发现,伴随着的许多平衡性问题也就隐藏
了起来。当然这需要游戏开发公司为之付出大量的测试费用才能尽可能多的发现这些
平衡性问题的一部分,这也许是许多游戏公司宁愿迷信设计师的"完美平衡"而不愿意
进行严格测试的经济原因。
经过了测试、调整、测试、调整……这样似乎没有休止的循环之后,游戏总算能够上市
见人了。不过,事情还远没有结束。
对于单机游戏而言,在上市后一段时间会发行一些补丁包,改善游戏BUG,调整游戏数
值,改善一些功能之类。对于网络游戏而言,进行游戏内容更新简直就是必不可少的
动作,只有这样才能给玩家新的内容挽留住玩家,改善游戏里的种种BUG包括游戏平衡
以平息玩家的怒气。
然而无论是在测试期还是在上市之后的游戏平衡调整都基于这样一个前提:这个游戏
是可以调整的,不会牵一发而动全身,这就涉及到游戏数值系统的可调整性。
2 游戏数值可调整性
游戏数值系统可调整性,就是在整个游戏系统当中,某一件物品或者某一个招式的数
值,相对于其他物品和招式的数值是分离的,对它做出一些细微的修改,影响的范围
尽可能的小,只针对它本身和它所针对的对象。
比如战士有一个招式专门用于克制盗贼,那么对这个招式的调整并不会对法师有过多
的影响(从长远来看,影响必定存在,一个系统中的事物总是会互相影响的,对这种
长远影响很难进行判断),虽然可能会产生一些影响,但这比调整战士的HP导致战士
对任何职业都增强了一些好多了。
在游戏系统设计之初,在玩法和技能、职业类型的划分上就要尽可能将它们模块化,
最好做到一一对应,每一个技能或者物品影响的范围都非常有针对性。做到这样,就
可以说具备游戏数值系统可调整性,,在发现问题时可以头痛医头脚痛医脚,而不是
在不远的将来理不清的一团乱麻。当然,这样的代价就是对测试的依赖增多,需要测
试部门去发现尽可能多的平衡性问题,而不象使用一组完美的平衡公式那样能够快速
的修改几个参数就宣称解决了所有的问题,实际上,这样一组公式只会让问题变得越
来越严重,因为这样的公式涉及的方面太多了,难免遮了头,露出了屁股。


--
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/

2006年8月29日

游戏开发人员联合声明

(转载并支持)
游戏开发人员联合声明

  游戏米果网络科技(上海)有限公司于2006年8月28日在全国各大游戏媒体发布了"
游戏米果关于若干员工竞业禁止的严正声明" 一文,部分游戏开发行业从业者在网络
上发表联合声明,回应游戏米果发布竞业禁止声明事件。原文如下:

  各位业界同仁:

  游戏米果网络科技(上海)有限公司于2006年8月28日在全国各大游戏媒体发布了"
游戏米果关于若干员工竞业禁止的严正声明" 一文,在未经当事人许可的情况下,公
开发布了赖介婷小姐等6位从业人员的身份证号码和照片,震惊业界。这种行为,已经
违反了中华人民共和国宪法第三十八条:中华人民共和国公民的人格尊严不受侵犯。
禁止用任何方法对公民进行侮辱、诽谤和诬告陷害(公民的生命健康、姓名、肖像、名
誉、荣誉、信用、隐私等权利统称人格权,法律保护公民的人格权不受侵犯)。

  游戏米果网络科技(上海)公司知法犯法,完全忽视员工的人格权,这种明目张胆
违反宪法和民法的行为,对赖介婷小姐等6位开发人员造成了严重侵害。在法制健全的
社会,公然进行这种不尊重人权以及滥用媒体暴力的行为,令人齿冷。

  现特发表联合声明如下:

  我们决定,我们自即日起永远不为游戏米果及其投资的所有公司发生任何业务往
来,永远不为游戏米果及其投资的所有公司工作,我们同时呼吁业内所有媒体和公
司,不要和游戏米果及其关联公司发生牵连,以借此呼吁所有业界同仁认识到法律法
规的重要性,维护从业人员的人权和尊严。

  有良知的人,为了捍卫自己的尊严,为了保护自己的权益,请在这里签下你的大
名。冷眼旁观,置身事外,今天的他们也许就是明天的你们。

事件详细报道地址:http://games.sina.com.cn/y/zt/gametjl/index.shtml#2
GAMERES的反应:http://bbs.gameres.com/showthread.asp?threadid=62698

--
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/

2006年8月28日

XNA 现况与未来

Sunday, August 13, 2006 1:42 PM
XNA Then and Now Part One
XNA 现况与未来 - 1
Hello everybody and welcome to the XNA Team Blog. This is an exciting time
for myself and everyone else on the team as we finally get to go public
tomorrow morning at Gamefest with the "Big Thing" we've been working on.
I'm pleasantly surprised that it hasn't been leaked and expect there to be
excitement out there as the implications of what we are doing become
apparent.
大家好,欢迎来到XNA组的网志。我们现在十分紧张,因为我们努力研制的大作将会在
明天早上的游戏节里公开。我感到很惊喜哦,它竟然没被泄露出去,相信当我们发布
后,定必会引来高潮。

I'll talk more about the big announcement after it happens tomorrow. Until
then, let me tell you a little about the strange/fun journey which as been
XNA.
过了明天之后,我会谈及更多的重大消息,现在就让我向大家展示少许XNA的资料吧。

XNA was announced with much fanfare at GDC in March 2004. For many reasons
the first XNA announcement was louder than it should have been. Everyone
wanted to talk about the Xbox 360, which wasn't going to be announced, or
even confirmed, until E3 in May. Next generation graphics were the thing
and we knew we had to show some of it.
在2004年三月的GDC上,XNA在备受各方赞赏下正式向大家作出预告,因为有很多因素
影响下,这次预告好像有少许夸大了。即使是在五月的E3上才确认的消息(和
Xbox360有关),也一早被大家讨论得如火如荼。实际上,XNA就是次世代图像引擎,我
们知道我们一定要展示一部份给大家知道。

The real XNA message was supposed to be about solving the deeper problems
in the game industry. Most people don't realize this but games are a tough
business. As the graphics quality bar rises, so does the art costs. Many
games are better looking than they are fun and their sales suffer while
the costs soar. Most games lose money while a few make lots. Hopefully,
the ones that make money make enough to cover all of the ones that lose.
开发XNA是为了解决一些在游戏工业中的深层问题,很多人都不知道,其实游戏开发是
一盘十分困难的生意。随着图像质素的提升,美工方面亦要付出相同代价。很多游戏
都在画面下功夫,却忽略了游戏性,加上索价甚高,因而损失大量金钱,相反,有些
游戏却是大丰收。希望后者可以平衡前者的损失吧。

This creates a situation where the industry is afraid to try anything
really innovative. Certain game play styles and genres sell in a
"predictable" sort of way and, thus, appear to have less financial risk
associated with them. This is why we see so many sequels on the market, so
many copycat games, and so few real innovations.
由于以上原因,很多公司也害怕作出创新,来来去去都是那数类游戏,从而减低财政
危机的可能,这亦都是我们常常看到续集推出的原因。市场上,抄袭多,原创少!

To throw more fuel on the fire: making games is hard (we hope to fix
that). In addition to the technology being hard, game studios have been
fast and loose in their development process creating poor practices and
controls around how things get done. This leads to delays, overruns, and
games that are unplayable when they ship and require a big patch to finish
them. It isn't fun for the people making the games who work long hours,
and the turnover in the industry is crippling. There just aren't enough
educated and talented new people coming in to meet demand.
制造游戏是十分困难的,对于那些公司来说,尤如火上加油,因此我们希望改变现
状。除了技术上有困难,游戏工作室在开发过程上不认真的态度,亦造成很多不良现
象,延迟、甚至在运送过程中导致游戏不能玩的,最后可能需要打补丁才解决问题。
又,缺乏一些知识人士、有才之士的加入,导致游戏工作者长时间工作,一个恶性循
环,最终就会使游戏工业瘫痪。

The big XNA announce at GDC in 2004 was really about a project to fix some
of the deep issues in the industry, although most people thought it was
about the Xbox 360 which we couldn't talk about yet. Some people thought
we were going to make a game engine, and some thought it was all a big
joke as then things went quiet for a few years. None of those were true.
纵使很多人都在谈论我们未能公开的资料(关于Xbox360),XNA确实是一个解决这深层
问题的方案。有人推测我们是在造游戏引擎,有人则认为它只是一个玩笑,在几年后
就会不了了之,我可向大家说,这些都是假的。

Just over two years ago, I was the Development Manager for Xbox Live. I
must have done a good enough job helping to define and build that service
that they asked me to run the new XNA team. The offer felt a lot like the
beginning of XBL as there was a lot of opportunity, big meaty problems,
and very little clear direction. The task was: given the outline I just
described above, go figure out, build and ship whatever XNA should be. And
don't take too long either.
两年前,我还是Xbox Live的Development Manager时,我有一个想法:我要打造一队
XNA工作组。这就像XBL的开始一般,有很多困难,缺乏清晰的方血。当时我要做的就
是上述的情形,我要想清到底XNA是什么,我要怎做等等问题,时间亦不能太长。
I quickly made a few key hires and got a small, but talented team
together. We then talked to a lot of people in the industry. The idea was
to not only listen to their complaints, but actually watch what they do
and see what bothers them the most.
很快地,我聘用了一些人才,麻雀虽少,五脏俱全。随后我们就和很多游戏工作者讨
论,我们的宗旨是『除了听取他们的意见,还要实地考察,明了他们的苦况。』

Here is a sample of issues we found:
以下是一些我们发现的:
• Most of the people on game teams are artists and story tellers, yet all
of the "telling" is owned by the coders, who would rather work on engines.
• 在游戏开发组中,大部份是美工人员以及剧本创作者,而描绘出故事的,则是一群
宁愿开发引擎的程序员。
• There is very little innovation because of financial risk averseness.
• 因为要顾虑开支的原因,很少创意可被加入
• Burnout on teams is very high, and there aren't enough new people
coming out of the schools to backfill.
• 人才需求很大,却只有很少毕业生加入
• Even if you do get a relevant degree, it is hard to get into the
industry because of a certain amount of elitism.
• 即使你有相关的学位,可是不够精通,你也难以加入游戏工业
• It is too hard to build games – in the technical code build sense. Art
assets are complicated and intertwined and your C++ linker doesn't do
anything to help.
• 在技术范畴上,是很难去创建游戏的。美工本来就很困难,在C++不提供协助下,
就难上加难。
• Creating a game is hard. The APIs, tools and such have all been written
with the expert coder in mind. Unfortunately, the best game designers are
usually not the best coders.
• 开创游戏是很难的。APIs,工具等等都是为专家而设的,可是最好的游戏设计师往
往不是最好的编写员。
And so on.
还有很多,不能详述。

So we started multiple investigations to see what we could do to help the
industry. The first two, which I started talking publicly about at the
CEDEC conference in Tokyo last year were a build system for art and a
related set of asset management tools. These were on the CTP we released
at GDC this year.
所以,我们开始多方面的研究,希望给予游戏工业一些援助。在上年东京的CEDEC会
议,我首度公开一个美工建立系统以及一连串资源管理的工具,这些都在本年GDC上
CTP中发布。

The other project was secret for a long time. We were working with Mike
Zintel's .NET Compact Framework team to see if we could bring their
technology to the Xbox 360. Rob Unoki and others on that team did a
stellar job and we were able to show managed running, and being debugged,
on a Xbox 360 Development kit to our execs in September 2005. After this
we zeroed in on what we wanted to ship first, finished hiring a team that
can ship code, and have been running like mad ever since.
有另一个项目一直是秘密的。我们和Mike Zintel的.NET Compact Framework合作,试
图把他们的技术应用到Xbox360上。Rob Unoki 以及其组员做了一项重要的工作,在
2005年九月,在我们的展览上,我们展示出能够在Xbox 360 Development Kit上做出
managed running以及除虫的工作。在这之后,我们招聘的工作告一段落,便开始空前
的疯狂工作。

GDC 2006
The GDC 2006 show was an important milestone for us. We showed working
managed code running on an Xbox 360 development kit and talked about how
it is going to help designers and others get games written more quickly
and cost effectively. Just as importantly, we shipped a CTP of some of our
tools and gave away all the art and source code to the game MechCommander
2.
GDC 2006是一个重要的里程碑,我们展示了在Xbox 360 Development kit 中运行
managed code,并道出它如何帮助设计者有效率地编写游戏。另一边厢,我们在CTP上
亦展示了我们一部份的工具以及MechCommander 2的所有美工图及代码。

Let me repeat that. We got permission from the company to give away all
the art and source code for the game MechCommander 2 (minus the networking
code). A big part of the team philosophy is to give back to the community.
我重申,我们已经向该公司取得权限去做出以上行动。我们组的其中一个宗旨,就是
回馈社会。

We want people to see how games are built. We want people to learn how to
build new games. We want people to do innovate things that nobody is
expecting. We want people to surprise the industry with new genres and new
gameplay styles. We want to see the equivalent of the Sundance for games.
We want to see more creativity. We want to make games, and game
development fun. We want to lower the barriers to entry and we want more
people to participate.
我们想让人们看到如何制造游戏,我们想人们学习去制造游戏,我们想人们造出没人
估计到的创新作品,我们想人们为这新游戏风格惊叹,我们想人们造出如Sundance(是
美国艺术中心吧) 的大作,我们想看到更多的创意,我们想令游戏、游戏开发都变得
有趣,我们降低门坎,让更多的人参与在其中。

I'll talk more about how we intend to achieve this tomorrow.
明天我会再谈我们想达到的目标!
Boyd Multerer
Product Unit Manager - XNA
posted by XNABlog | 9 Comments

XNA 现况与未来 - 2


星期一, 8月14, 2006 7:59 AM
再次向各位问好!
我不知道有多激动地告诉你们关于我们XNA小组真正在做的东西.在今年的GDC上,我们
展出了在XBOX360上运行的Managed Code.但我们认为那是个帮助游戏企业的工具.而我
则相信它会成为一个优质环境,让大家创造普通的游戏,而且随著不断的发展,它会
令制造FPS以及其他大作更加方便.
当我们展出这个时,我们就在想,如果能让大多数的刚入门的游戏团队能在XBOX360上运
行他们的程序,那该有多屌.然后我们都笑了,并盼望着那一天的到来,我们能拿出些真
的东西出来的那一天.

今天我们发布这个公告的核心就是这个.我们将在今年秋天推出XNA Game Studio
Express.这个工具完全为那些数量众多的使用Visual Studio在WINDOWS环境下开发游
戏的团队所准备.他们将可以使用此软件将他们的游戏运行在任何WINDOWS或零售的
XBOX360上.对,正如你想的那样,你可以将你自己的程序运行在任何一台在商店中购买
的XBOX360上,当然,包括你已经拥有的XBOX360.

当然,以上是这篇公告最值得你注意的部分,但是,我想强调的是,这个程序的目的是学
习和对游戏的大致开发流程有一个认识.除了我们在GDC上放出的源程序,我们将继续放
出更多的能在任何平台运行的游戏示例.你可以在9月份下载BETA版(WINDOWS ONLY)时
得到第一个示例.

在春季GDC过后,有人指出开放XBOX360将是个艰难的商业模式,对于我们,也对于
MICROSOFT,这是游戏机的本质决定的.他们是对的.在你的XBOX360上运行一个没有许可
的游戏将需要99美元每年.WINDOWS方面的开发程序则将是免费的.这些费用将允许我们
开放新的XBOX商业模式,投资于新的示例游戏,并维持软件的更新.

当我还是个孩子的时候,就祈求我的父母给我买台电脑.他们最终答应了,并且我成了一
个骄傲的Timex-Sinclair 1000的拥有者,当时,这台机器只有16K的扩展内存.它并不能
做太多事,但我用它写了几个简单的游戏.这使我爱上了编程,成为了我事业的开端.我
们想将这种体验传达给每一个有潜力的人.我们听到很多家长的声音,他们希望将游戏
作为一种能教育孩子并且开发孩子创造力的体验.实际上,已经有好几所学校在介绍游
戏引擎给年青人.

然而,我们正在开发的这个软件并非只是一个入门级程序.你可以开发一个完整的游
戏,并且使用阴影特效,高端的图形效果,只要你肯深入研究.比如,我们和Garage
Games有很好的合作.他们已经使用XNA技术创造了自己的工具和引擎.他们已经开发了
一个MARBLE-BLAST使用C#的版本,那很酷.

他们也已经得到了很多使游戏开发更容易的工具,使编剧,美工等对程序不熟悉的部门
更好的投入游戏的开发.

总之,我们都对这些情况感到很开心.我们对于改善周围的游戏小组的状况和让开发革
命性游戏更容易感到愉快.随着时间推移,我们将看到更多这方面的资料.

因为这只是个BLOG,我也没什么压力,所以我可以说一些这个计划的漏洞.当我们在秋天
放出XNA Game Studio Express时,你可以在WINDOWS上分享你的成果给任何你希望的
人,但如果你想在XBOX上这么做,恐怕得不到任何支持.我们非常希望在以后改进这
点,当然,如果在这其中我能做什么,我一定尽力做到,让它赶快实现.当然,越多的人付
费并开发他们心目中革命性的游戏,这一点越容易做到.

最后我想说的是,我为我能和如此有才能的人一起工作感到荣幸.我们希望将游戏的创
造性带给这个世界并且就在今年.我们急切的想玩到你们用XNA Game Studio
Express开发的革命性游戏!

Thanks,
Boyd Multerer
产品经理 - XNA

翻译 by 小龙


--
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/

XNA FAQ中文版

微软XNA邮箱:xna@microsoft.com


XNA FAQ
XNA Framework、XNA Game Studio Express FAQ


1、XNA Game Studio Express是什么?
XNA Game Studio Express是以学生和游戏开发爱好者为用户群体的一个全新的开发程
序。XNA Game Studio基于Visual C# Express 2005,开发出以Windows系统以及Xbox
360为对象的游戏。包含如下:

a.XNA Framework是一套管理代码开发库,它可以使得游戏开发人员开发基于
Windows和Xbox 360游戏时更加多效。
b.XNA Framework内容通道是一套工具,它允许开发人员将3D内容融合到游戏中。
c.XNA Game Studio Express亦提供了完整的参考文件,"怎样做"及"新手上路"等等,
让你学会如何最佳地使用内容通道以及XNA Framework。
d.XNA Game Studio Express包含一整套文档,其包括怎样最好地利用XNA内容通道以
及XNA Framework。

XNA Game Studio Express Beta版将在8月30号发布。当beta版公布时,我们会在网站
上标明,请进入http://connect.microsoft.com,再选择"Available
Connections."。之后选择XNA的链接下载XNA Game Studio Express Beta版(注意:
需要Windows Live ID,如果没有,请先申请注册)。

2、XNA Game Studio Express 和 XNA Framework有什么不同?
XNA Game Studio Express是一套基于Visual C# Express 2005的工具。而XNA
Framework则是包含XNA Game Studio Expres的一套管理库,其基于.NET Framework
2.0。

3、请问可以利用XNA Game Studio Express和XNA Framework开发Xbox 360商业性游戏
吗?
XNA Game Studio Express 使开发Windows和Xbox 360游戏得更加容易。不过Xbox的游
戏必须是非商业性的,而windows的则没有限制。但是明年春季发布的XNA Game
Studio Professional版,允许基于Windows和Xbox 360的商业性游戏。

4、Q: 如果我拥有360开发工具,我有权使用XNA Framework吗?
我们定于明年春天发布的XNA Game Studio Professional将会支持使用Xbox 360的开
发工具来开发商业游戏。与用XNA Game Studio Express开发的游戏不同,用XNA
Game studio professional 设计的游戏是可以支持certification来发布的。

5、XNA Game Studio Express/XNA Framework的价格是多少?
XNA Game Studio Express的工具及其Windows的运行环境是完全免费的。但如果要在
Xbox 360上开发、调试或者运行游戏的话,就需要在Xbox Live在线市场上购买一个
XNA 的"开发者俱乐部"的订单。该订单分两种:$99一年或者$49四个月。

6、XNA Framework可不可以通过传真方式(running in emulation mode)在Xbox
360上运行?
在Xbox 360上,XNA Framework将会利用普通的.NET Compact Framework 2.0 CLR来执
行。

7、XNA Framework可不可以在非Microsoft平台运行?
XNA Framework只能运行于Windows以Xbox 360平台。

8、在XNA Framework中的管理编码是否未被编译所以才会那样慢? 对啊,它没被编
译。当IL被载入后,在执行前,IL会被编译为本地编码。这可以针对PC和Xbox360的硬
件来达至最佳效果。

9、为什么beta版不支持Xbox 360?
基于安全原因,微软没有发布支持Xbox 360的beta版,但XNA Framewor可以在
Windows 和Xbox 360上设计和运行。自8月30号以后用XNA Game Studio Express 开发
的游戏将会很容易地被移植到Xbox360零售版使用

10、XNA Framework确切的说是什么?
XNA Framework允许游戏开发人员使用C#程序语言和一整套开发库来开发时下流行的
各种游戏。XNA Framework提供了一些列自己特有的内容通道,将会使开发人员更容易
地将各种内容素材(3D,2D,音乐……)加入到游戏中。XNA Framework也为在Windows 和
Xbox 360上的运行,提供了一系列非常高级的API接口。

11、XNA Framework与.NET Framework有什么不同?
Framework(框架)是创建Windows程序的基础,XNA Framework的原理也一样,比如类
库和通用语言运行时间,但XNA Framework是针对游戏开发和执行的最优设置。它包括
一套专门为游戏开发而使用的跨平台的库。

12、如果我想把自己的Xbox 360的游戏和其他Xbox 360的玩家共享该怎么做?是不是
我的游戏只能共享给"开发者俱乐部"的用户?还是可以共享给所有拥有Xbox Live帐号
的用户?
一般来说,如果要将游戏与其他Xbox 360用户共享,必须符合下面4项条件:

如果你想将游戏游戏与其他用户共享,就必须登陆Xbox Live并且拥有一个XNA开发者
俱乐部的订单。
游戏接受者必须下载基于Xbox 360XNA Framework通用运行环境。
游戏接受者必须安装有XNA Game Studio Express。
游戏的全部内容都必须传送给游戏接受者。然后游戏接受者再编译和配置到自己的
Xbox 360上。.

13、我可以将XNA Game Studio Express游戏储存到记忆卡上和朋友分享吗?
目前游戏开发人员是不能使用记忆卡将游戏与他人分享的。

14、在Xbox 360主机上运行基于XNA的游戏需不需要硬盘驱动器?
是的。针对Xbox 360, XNA Framework的通用运行环境需要物理硬盘驱动器在你在
Xbox 360的零售版上。

15、Q: 我可以用XNA Game Studio来制造非游戏软件吗(如媒体中心/播放器等)?
A: 在Windows上,这是可行的,但在Xbox360上,则只可用来编写游戏。这是我们在讨
论区中看到的用户意见。

16、Q:XNA Framework需要D3D9硬件吗?
A: 最低要求是一块支持Shader Model 1.1的Direct3D 9.0卡。因为大部份都要求一块
支持Shader Model 2.0的卡,所以建议必须拥有一块支持Shader Model 2.0的卡。

17、Q: XNA Framework 会和DirectX SDK一起发布吗?
A: 目前,XNA Framework(Windows版)会和XNA Game Studio Express一起发布,而非
Direct SDK以及XNA Framework(360版)则需要用家订阅XNA "开发者俱乐部",随后就
可通过Xbox Live在线市场取得。
18、Q: XNA Framework的支持策略是怎样?
A: XNA Game Studio Express用户可以到我们的XNA Framework 和 XNA Game Studio
Express讨论区,通过Game Development区,进入http://msdn.com/xna/forums查询。

19、Q:D3DX有X的特色。那么XNA Framework会有吗? A:我们已经把D3DX的特色大量
地应用到XNA Framework上。我们正在努力地找出游戏开发者可能会用到的,可是被忽
略了的一些功能。我们会通过新闻组、讨论区及email(xna@microsoft.com) 等等途径
来获取更多的回馈。

20、Q: MDX1.1是指什么? A: MDX1.1是在有限度的工程模式当中,即不会再有任何新
功能。如果你有什么游戏是需要用一些只在MDX1.1中有的特别功能,请告知我们,我
们会考虑把它移植至XNA Framework上。

21、Q: XNA Framework怎样支持音频?
A: XNA Framework提供 XACT处理方式来进行对音频的录制的灌入 。

22、Q: XNA Framework支持处理 XINPUT 或 DirectInput 吗?
A: XNA Framework将会通过处理的XINPUT,从而在制作游戏中提供导入装置的功能。

23、Q: XNA Framework包括Xbox Live的功能吗?
A:在 Xbox 360 上首发的XNA Framework将不会对网络有任何支持。但我们知道很多玩
家对此非常感兴趣,我们可能将在后续版本上提供这种功能。,

24、Q: 怎样将基于XNA 制作的游戏在Xbox 360运行?
A: 可以在idows桌面运行XNA Game Studio Express,从而通过远程调试连接来进行游
戏机调试。,

25、Q:XNA Game Studio Express支持哪些Windows版本?
A:XNA Game Studio Express现在只支持Windows XP SP2。一旦Windows Vista发
布,XNA Game Studio Express 将完全支持Windows Vista。

26、Q: XNA Framework 直接覆盖我原本的Framework 在我的Windows桌面吗?
A:不。XNA Framework不会覆盖您现有的Framework,也不会任何不良影响。XNA
Framework是一个基于Windows系统的NET Framework 2.0. 的类库(类)的集合。
27、Q:请问XNA Framework支持Windows和个人掌上电脑吗?
A:XNA Framework现在不支持手机Windows或个人掌上电脑,但如果客户普遍需要,这
将是未来我们发展的XNA Framework 一个方向。我们知道游戏开发行业是一个日益成
长的热门领域,我们将在未来提供尽可能的支持。

28、Q:full-featured beta 版本的XNA Framework 何时会有?
A:XNA Framework beta将在8月30日发布,beta版将提供XNA Game Studio Express
beta的部分功能的使用。如果你对XNA Game Studio Express beta的提供下载的时间
感兴趣可以去http://connect.microsoft.com,选择 "Available Connections." ,
然后选择XNA connection ,接着进行XNA Game Studio Express Beta的报名。(注:
需要一个有效的Windows Live ID,如果你没有的话,你需要去申请一个。)

29、Q:开发者如何获得XNA Framework?
A: XNA Framework将会为Windows用户提供一个自由下载点。关于360的平台, 用户
需要需要加入为XNA "开发者俱乐部",它包括开发一个非商业性游戏所需的所有事
物。

30、Q: 如何了解更多有关XNA Framework的知识?
A:我们将会在XNA 网站 (http:// msdn.com/xna)发布更新升级相关的信息,同时继
续发展讨论区。你可以访问 http:// msdn.com/xna/forum ,参与社区讨论。除此之
外,如果你有任何的问题,你也能够发送EMAIL到 xna@microsoft.com ,但我们不能
保证对对每封电子邮件做出回应。

31、Q:XNA Game Studio Express能够奉献给全世界的游戏开发者吗? 还是计划只在
局部地区使用?
A:基于XNA Game Studio Express的开发工具和环境都通过http://msdn.com/xna在全
世界范围内下载。基于Xbox 360 的XNA Game Studio Express零售版也将在几乎所有
国家之间进行运送和零售,并且保持与Xbox Live连接性。目前只有英文版。

32、Q:在XNA Game Studio Express中, XNA Game Studio Pro 和 XNA Studio有什么
不同?
A:XNA Game Studio Pro and XNA Studio是分别针对对业余游戏开发者和专业人士的
相关产品。两者都是基于Microsoft Visual Studio的。XNA Game Studio Express更
面向兴趣爱好以及小团体开发,并且因此开发出非商业的游戏。XNA Game Studio
Pro 会包含一些专业游戏开发者需要的额外功能(如函式库)来支持Xbox
Live(Achievements,Leaderboards,多人游戏) 以开发出商业化游戏。XNA Studio 会
推出企业版以供大型AAA studio的生产线使用。

33、Q:在Xbox 360 上怎样用XNA Game Studio Express完整的制作和运行一个游戏?
A:在Windows上,你将能够免费的开发和测试以及发布使用XNA Game Studio
Express开发的程序。当你支付一年订阅费用,注册针对Xbox 360的XNA Game Studio
Express 用户时, 你可以先在Windows环境下开发一个游戏,然后送给你一款 Xbox
360对游戏进行测试。最后,你将能够把代码发布给其他Xbox 360主机,从而打开一条
拥有自主版权的、基于游戏主机发展的新思路

34、Q:我能不能够先开发一个游戏,然后在Xbox 360和Windows上同时运行?
A: 你需要在每一个平台先编译好。在这个版本中,你需要为每一个平台产生一个独立
的项目,然后再编译。我们的目标是尽可能让最多的程序代码可在两个项目中使用,
在两个项目中使用同一个代码,但最终平台专有的代码也是要分开编译的。

35、Q: 为什么XNA Framework 内容通道不支持我最爱的组件设计工具?
A:我们已为内容通道选择了一些发展健全的档案类形,这些档案已有很多设计工具
了,而未来将会有更多的设计工具可以使用。

36、Q: C#是什么语言?
A: C#是一种现代化的对象导向程序语言,它是以开发者的角度来设计的。C#在世界上
已有过百万的开发者在使用,它提供了全面的功能让开发者可在.NET Framework,
Compact Framework, 以及 XNA Framework 的环境下开发程序。

37、Q: 管理程序代码有何优点?
A: 由一般的语言产生出来的管理执行环境为开发者提供了很多开发优势。这类语言在
garbage collection(资源垃圾回收), hardware abstraction(硬件提取), thread
management(线程管理), 以及 sandboxed security model。要知道更多关于Common
Language Runtime(CLR)以及Framework的信息,可访问
http://msdn.microsoft.com/netframework

38、Q: C#在游戏开发上有被广泛使用么?
A: 大部份的游戏开发公司得悉C#的优势后便已经开始使用它来开发内部工具,而且市
面上已有少部份Windows平台的游戏大作是用C#来编写的。但在XNA Framework释出来
的前,用C#来为Windows及Xbox 360设计跨平台游戏是不可能的。因此,我们相信XNA
Framework 会是一个游戏开发公司的黄金机会。

39、Q: XNA Framework 和Managed DirectX (MDX) 1.1 或 MDX 2.0 有不同吗?
A: 当然有。XNA Framework 在技术上与MDX完全不同,它是以游戏开发者为目标的。
但它与一些和DirectX有关的技术仍有部份类似的特性,XNA Framework也对其他技术
(如XACT和X/Input等)有所影响。

40、Q: XNA Framework 包括了Managed DirectX 2.0吗?
A: XNA Framework 会包含很多在Managed DirectX 2.0有的功能,并且加入更多适用
于游戏开的功能,让开发者可以写出大作。有一点是十分重要的,MDX2.0 beta和XNA
Framework 是有所不同的。我们会在XNA Framework发布的初期提供指引,让使用者可
从MDX2.0 beta 转至XNA Framework。

41、Q: MDX2.0还会有改进吗?
A: 目前的MDX2.0 beta 函式库自2006年四月SDK发布开始便没有再变了。MDX2.0
beta将会停止开发,并且不会再由官方发放了。当XNA Framework beta发布
后,MDX2.0将会由DirectX SDK中移除。

42、Q: XNA Framework是否取代了MDX?
A: XNA Framework 会有一个为使用Xbox360硬件及Windows而设的管理API。这个API会
把如今MDX2.0 beta的函式纳入在内。

43、Q: MDX1.1 支持使用.NET Framework 2.0来开发吗?
A: MDX1.1 is fully compatible with the .NET Framework 2.0.
A: MDX1.1和.NET Framework2.0是完全一致的。

44、Q: 我的MDX1.1代码会在XNA Framework中运行吗?
A: 我们会提供从MDX1.1转移XNA Framework的指引。

45、Q:我本身是游戏开发商,我已经设计出一套用MDX1.1的工具,但Microsoft是否不
再支持MDX1.1?
Q:Microsoft会维持一贯的政策,继续支持MDX1.1。当XNA Framework发布后,我们便
会提供从MDX1.1转移XNA Framework的指引。

46、Q: XNA代表什么?
Q:XNA不是缩写。

--
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/

Paper Burns: Game Design With Agile Methodologies

A fear of next generation development can be seen everywhere; it's at the water cooler, it's in magazines, it's talked about at the Game Developers Conference and in Game Developer Magazine. With increased hardware capacity allowing for ever more expansive and immersive games, everything is growing: Team sizes, asset requirements, person hour investment, and of-course required capital from investors to support it all. Audiences are also expecting more. They want more mechanics with greater functional and technical depth, denser polygon art, higher resolution textures, more complex AI, more testing and quality assurance, and the list goes on.

This fear of the next generation is not confined to the industry. The press has caught, and with them the consumer. Game site FiringSquad.com said, "Game publishers and developers industry-wide are complaining of ballooning development costs, mostly due to art teams that have to grow exponentially to create all the content that's possible." [Press01] A vast majority of the problems facing the industry are deep seated in the very production methodology that is employed. Teams of approximately 100 people are still using methodologies developed for a time when ten people were considered a bloated team. There are alternatives.

Traditional game development uses a production methodology that spends a lot of front-end time, defining intended functionality, often with implementation of important elements such as mechanics and levels waiting around until the mad scramble at the end. The traditional methodology, often called Waterfall, isn't dissimilar to an assembly line, with the beginning of the line starting the process of piecing together the product while the end of the line waits to add polish. The wait is what creates the problem. Designers and publishers are never able to get a real feel for the game, for example whether their initial assessment of mechanics was right, or the implementation of features doesn't end up to original specifications. Factors like these are what degrade product quality..

One alternative addresses exactly these problems with traditional game development methodology. It is, a product R&D process and team management style aptly referred to as Agile Methodology. Agile puts the emphasis on producing demonstrable iterations of a game almost immediately into production, creating prioritized vertical slices that iterate on the most critical elements and features. The method also puts great emphasis on the organization of teams and the relationships therein, as well as the cycles in which teams must plan and carry out their project objectives. The challenges faced by game development teams can be numerous and as varied as the divide between the discipline, such as art, engineering and design, that need to work together. The road to the end of game projects is also long; short games are in development for one to two years, bigger titles are running the gamut from a three years, and in exceptional cases up to five or more.

This paper will cover how the Agile method and a specific methodology, Scrum, can directly address these challenges, and perhaps are especially suitable for the complexity game developers, and explicitly designers, face with next-gen console development.

Methodologies

WATERFALL
Most game design or game development books contain very little about methodology. They assume the vast majority of developers use the exact same approach, a method often referred to as Waterfall. In the Waterfall approach work moves sequentially in one direction, such as from a project requirements or design phase to production and implementation. There is very little iteration in the early phases, leaving little opportunity for evaluation. What's more, much like running water, once the sequence is in progress the process is not easily reversed.

In Waterfall game development, a game designer or group of game designers will first create the game design document, where they lay out many of the features and mechanics. The design document is then broken up into smaller chunks which producers use to extract required functionality and assets. The requirements for these assets and functionality elements span the spectrum of teams involved in the project.

Thus begins the sequence of the Waterfall method, as the requirements "flow down" to animation, programming, level art, character art, QA, FX, etc. This continues as once an individual or team is done with a piece of a feature, they then hand it to another. A character, for example, would begin with the design document and get handed to a producer or a project director. From there, it would be broken out into its components: The mesh and texture of the character, the animation, the effects the character plays when hit, attacking or idling and finally the AI technology which powers the character. Each department focuses on its component, then work to implement it until its bears some semblance of completion.

It's then moved back to the designer for tuning, handed off to QA for testing, to the level designers to populate in levels, then bounced back to various departments for bug fixes. While this character is being worked on, other individuals and teams are working on their pieces of specific mechanics. In the same day, a single developer may work on pieces of several different mechanics. The nature of the methodology is a percolation, where the game's many mechanics are brought from the ground up over time.

AGILE
In the late 1990s, a number of new software development methodologies began surfacing, derived from teams ranging from web applet development to systems powering NASA flights. Each methodology possessed its own do's and don'ts, its own mantras and blasphemies, yet despite their variances, a majority of them had several fundamental things in common.

In 2001, several of the those who had helped spawned the half dozen or so methodologies in use organized a summit in Utah. The result was a central ideology, and a manifesto to go along with it:
A working piece of software had more value than a document that indicated what the software should do.
Regular collaboration with customers was valued more than extensive contracts that outlined the intended usage of a product up front.
Value individuals solving problems rather than processes or tools.
And most importantly, they valued responding to change over following a plan. [Agile01]



Implementation over documentation, ongoing customer collaboration and the ability to problem solve and change course with agility. The central tenets to Agile Methodology were short, but they had large implications, and they were applicable to any complex product development system.

SCRUM
As use of Agile development grew, a number of different methodologies surfaced. Some were derived from Agile, others were systems that had been in use but never fully defined or applied to software development. One such method was Scrum, an approach to product R&D which had its roots in Japanese car and consumer electronics manufacture. By definition, scrum refers to a maneuver in rugby where everyone on the team is involved in an action to move the ball.

As a methodology, the same approach is applied to product development in spirit, where project teams are reorganized into small teams that work closely together on specific components of a project. Iterative development is stressed, with the project divided into components that are "shippable" pieces that can be demonstrated, tested and evaluated for functionality.

One of the principal tenets in Scrum is that everyone on the team is involved in the process. Scrum breaks down production into short work cycles called Sprints. At the beginning of each Sprint, the entire project team meets to create objectives and self-organize into small Scrum teams. The Scrum teams are interdisciplinary, with artists working alongside designers working alongside programmers. Though the goal of each team is determined by project managers, producers and publishers at the planning meetings, the teams ultimately decide the path they will use to achieve their goals for the Sprint. Once into the Sprint, the teams are completely self-managed in their daily planning and execution of tasks.

As recited often by those familiar with Scrum, projects become delayed one day at a time. For this reason, a critical component of Scrum is daily meetings among individual Scrum teams throughout the Sprint. The meetings can be as brief as 5-10 minutes, and are designed to ensure that objectives are on track, any impediments to progress are recognized, and daily accomplishments are seen by everyone involved. [Agile02] The process creates a sense of ownership among every member of the team, and its transparency is designed to create accountability among team members that ultimately boosts productivity.

With the team self organizing, regular reviews keep the team on target and give everyone a full diagnostic of the product in the purest form possible; how it looks and performs. At the completion of every Sprint, the teams conduct reviews that demonstrate their accomplishments, and allow their product owners or "customers," such as studio managers and publishers, to evaluate progress. The customers can then determine what the priorities are for the next Sprint.




Graphic01: A simple visualization of Scrum. Game features are broken down into individual tasks by programmers, artists and designers, they then work on these for an iteration of two weeks to a month, accounting for their tasks and to each other in a daily meeting. At the end of the iteration a product review occurs of all work done for that iteration where project directors and publishers can determine how to prioritize the next iteration based on the work done in the latest.




The goal for these teams when reviewing with their customers is to demonstrate a "vertical slice" of the game, as in a piece of a game such as a single level hub or a completely playable mechanic or a tuned feature. While not all mechanics can be delivered in a single iteration, the individual pieces of them become the vertical slices that teams focus on. For example, an AI character is very difficult to deliver in a single Sprint. Yet a single behavior of that AI character can be fully programmed, animated, have sound attached to it, be deployed in a level, etc., resulting ultimately in something that can be tested.

With these two elements in mind, a customer can look at a product and see exactly what's been achieved, where it's going, how fast production is progressing, etc.. A customer does not need to guess or have faith, they can see a direct diagnostic, and often by picking up a controller rather than looking at spreadsheets or wireframes. Scrum also gives customers flexibility from iteration to iteration, just as it does product teams.

Customers have room to redirect project goals between Sprints if what's been created and evaluated is not living up to expectations. And because of the iterative process of Scrum and the short work cycles of Sprints, redirecting a project rarely results in large volumes of wasted work.


--
世界之大,远超过我们的眼界可以容纳的范围,不管人们走得多慢;走得多快,他们也不会看到更多。真正珍贵的东西是所思和所见,不是速度。

2006年8月27日

Paper Burns: Game Design With Agile Methodologies

fear of next generation development can be seen everywhere; it's at the water cooler, it's in magazines, it's talked about at the Game Developers Conference and in Game Developer Magazine. With increased hardware capacity allowing for ever more expansive and immersive games, everything is growing: Team sizes, asset requirements, person hour investment, and of-course required capital from investors to support it all. Audiences are also expecting more. They want more mechanics with greater functional and technical depth, denser polygon art, higher resolution textures, more complex AI, more testing and quality assurance, and the list goes on.

This fear of the next generation is not confined to the industry. The press has caught, and with them the consumer. Game site FiringSquad.com said, "Game publishers and developers industry-wide are complaining of ballooning development costs, mostly due to art teams that have to grow exponentially to create all the content that's possible." [Press01] A vast majority of the problems facing the industry are deep seated in the very production methodology that is employed. Teams of approximately 100 people are still using methodologies developed for a time when ten people were considered a bloated team. There are alternatives.

Traditional game development uses a production methodology that spends a lot of front-end time, defining intended functionality, often with implementation of important elements such as mechanics and levels waiting around until the mad scramble at the end. The traditional methodology, often called Waterfall, isn't dissimilar to an assembly line, with the beginning of the line starting the process of piecing together the product while the end of the line waits to add polish. The wait is what creates the problem. Designers and publishers are never able to get a real feel for the game, for example whether their initial assessment of mechanics was right, or the implementation of features doesn't end up to original specifications. Factors like these are what degrade product quality..

One alternative addresses exactly these problems with traditional game development methodology. It is, a product R&D process and team management style aptly referred to as Agile Methodology. Agile puts the emphasis on producing demonstrable iterations of a game almost immediately into production, creating prioritized vertical slices that iterate on the most critical elements and features. The method also puts great emphasis on the organization of teams and the relationships therein, as well as the cycles in which teams must plan and carry out their project objectives. The challenges faced by game development teams can be numerous and as varied as the divide between the discipline, such as art, engineering and design, that need to work together. The road to the end of game projects is also long; short games are in development for one to two years, bigger titles are running the gamut from a three years, and in exceptional cases up to five or more.

This paper will cover how the Agile method and a specific methodology, Scrum, can directly address these challenges, and perhaps are especially suitable for the complexity game developers, and explicitly designers, face with next-gen console development.

Methodologies

WATERFALL
Most game design or game development books contain very little about methodology. They assume the vast majority of developers use the exact same approach, a method often referred to as Waterfall. In the Waterfall approach work moves sequentially in one direction, such as from a project requirements or design phase to production and implementation. There is very little iteration in the early phases, leaving little opportunity for evaluation. What's more, much like running water, once the sequence is in progress the process is not easily reversed.

In Waterfall game development, a game designer or group of game designers will first create the game design document, where they lay out many of the features and mechanics. The design document is then broken up into smaller chunks which producers use to extract required functionality and assets. The requirements for these assets and functionality elements span the spectrum of teams involved in the project.

Thus begins the sequence of the Waterfall method, as the requirements "flow down" to animation, programming, level art, character art, QA, FX, etc. This continues as once an individual or team is done with a piece of a feature, they then hand it to another. A character, for example, would begin with the design document and get handed to a producer or a project director. From there, it would be broken out into its components: The mesh and texture of the character, the animation, the effects the character plays when hit, attacking or idling and finally the AI technology which powers the character. Each department focuses on its component, then work to implement it until its bears some semblance of completion.

It's then moved back to the designer for tuning, handed off to QA for testing, to the level designers to populate in levels, then bounced back to various departments for bug fixes. While this character is being worked on, other individuals and teams are working on their pieces of specific mechanics. In the same day, a single developer may work on pieces of several different mechanics. The nature of the methodology is a percolation, where the game's many mechanics are brought from the ground up over time.

AGILE
In the late 1990s, a number of new software development methodologies began surfacing, derived from teams ranging from web applet development to systems powering NASA flights. Each methodology possessed its own do's and don'ts, its own mantras and blasphemies, yet despite their variances, a majority of them had several fundamental things in common.

In 2001, several of the those who had helped spawned the half dozen or so methodologies in use organized a summit in Utah. The result was a central ideology, and a manifesto to go along with it:
A working piece of software had more value than a document that indicated what the software should do.
Regular collaboration with customers was valued more than extensive contracts that outlined the intended usage of a product up front.
Value individuals solving problems rather than processes or tools.
And most importantly, they valued responding to change over following a plan. [Agile01]



Implementation over documentation, ongoing customer collaboration and the ability to problem solve and change course with agility. The central tenets to Agile Methodology were short, but they had large implications, and they were applicable to any complex product development system.

SCRUM
As use of Agile development grew, a number of different methodologies surfaced. Some were derived from Agile, others were systems that had been in use but never fully defined or applied to software development. One such method was Scrum, an approach to product R&D which had its roots in Japanese car and consumer electronics manufacture. By definition, scrum refers to a maneuver in rugby where everyone on the team is involved in an action to move the ball.

As a methodology, the same approach is applied to product development in spirit, where project teams are reorganized into small teams that work closely together on specific components of a project. Iterative development is stressed, with the project divided into components that are "shippable" pieces that can be demonstrated, tested and evaluated for functionality.

One of the principal tenets in Scrum is that everyone on the team is involved in the process. Scrum breaks down production into short work cycles called Sprints. At the beginning of each Sprint, the entire project team meets to create objectives and self-organize into small Scrum teams. The Scrum teams are interdisciplinary, with artists working alongside designers working alongside programmers. Though the goal of each team is determined by project managers, producers and publishers at the planning meetings, the teams ultimately decide the path they will use to achieve their goals for the Sprint. Once into the Sprint, the teams are completely self-managed in their daily planning and execution of tasks.

As recited often by those familiar with Scrum, projects become delayed one day at a time. For this reason, a critical component of Scrum is daily meetings among individual Scrum teams throughout the Sprint. The meetings can be as brief as 5-10 minutes, and are designed to ensure that objectives are on track, any impediments to progress are recognized, and daily accomplishments are seen by everyone involved. [Agile02] The process creates a sense of ownership among every member of the team, and its transparency is designed to create accountability among team members that ultimately boosts productivity.

With the team self organizing, regular reviews keep the team on target and give everyone a full diagnostic of the product in the purest form possible; how it looks and performs. At the completion of every Sprint, the teams conduct reviews that demonstrate their accomplishments, and allow their product owners or "customers," such as studio managers and publishers, to evaluate progress. The customers can then determine what the priorities are for the next Sprint.




Graphic01: A simple visualization of Scrum. Game features are broken down into individual tasks by programmers, artists and designers, they then work on these for an iteration of two weeks to a month, accounting for their tasks and to each other in a daily meeting. At the end of the iteration a product review occurs of all work done for that iteration where project directors and publishers can determine how to prioritize the next iteration based on the work done in the latest.




The goal for these teams when reviewing with their customers is to demonstrate a "vertical slice" of the game, as in a piece of a game such as a single level hub or a completely playable mechanic or a tuned feature. While not all mechanics can be delivered in a single iteration, the individual pieces of them become the vertical slices that teams focus on. For example, an AI character is very difficult to deliver in a single Sprint. Yet a single behavior of that AI character can be fully programmed, animated, have sound attached to it, be deployed in a level, etc., resulting ultimately in something that can be tested.

With these two elements in mind, a customer can look at a product and see exactly what's been achieved, where it's going, how fast production is progressing, etc.. A customer does not need to guess or have faith, they can see a direct diagnostic, and often by picking up a controller rather than looking at spreadsheets or wireframes. Scrum also gives customers flexibility from iteration to iteration, just as it does product teams.

Customers have room to redirect project goals between Sprints if what's been created and evaluated is not living up to expectations. And because of the iterative process of Scrum and the short work cycles of Sprints, redirecting a project rarely results in large volumes of wasted work.


--
世界之大,远超过我们的眼界可以容纳的范围,不管人们走得多慢;走得多快,他们也不会看到更多。真正珍贵的东西是所思和所见,不是速度。

2006年8月21日

小资,愤青,朋克, 你占哪方面多一点[转]

小资是风筝,样式艺术,结构科学,接近高贵,有文化根基,懂得借风非翔,收放自如,不易丧失自我。
    
    愤青是气球,色彩形状皆大同小异,都充满怒气,弹性也能易破的脆弱,越飞越高的最终气炸了,非不起来的直到泄气光光,他们看似无拘无束,实则难以控制自己。
    
    朋克是羽毛,被原有的生命体放弃,然后玷染污浊,行迹多变,如美丽的死魂,有不完全是垃圾,有一天再也飞不动,等待变成灰粒,更也许在此之前扑火燃尽。
    
    [阿非正传]中的张国容是一个假装小资的朋克,张学友是一个看似朋克的愤青,梁朝伟是一个本应朋克却宁穷也要小资的小资,后来他的角色不那么穷了,于是延续到[花样年华]中成了真正的小资,而刘德华基本酸是个正常人。
    
    小资讲究行为艺术。
    愤青讲究行为准则。
    朋克讲究行为随意。
    
    小资的理想中有自保的安逸,习惯动作是抚头发。
    愤青的理想中有冲动的秉性,习惯动作是挽袖子。
    朋克没理想。
    
    小资最复杂,但很少有人觉得他们狡猾。
    愤青最表面,电很少有人觉得他们无知。
    朋克最单纯,但很少有人觉得他们可爱。
    
    小资看完一部电影,懂得了小资变成色狼也像正人君子。他看的是[云上的日子]
    愤青看完一部电影,剃了个莫西干发型,他看的是[出租车司机]
    朋克看完一部电影,生气的大叫"我的马桶竟然不是最脏的",他看的是[猜火车]
    
    小资看奥斯卡,是因为他看不懂柏林电影节。
    愤青看奥斯卡,是因为他想连续骂个三小时。
    朋克看奥斯卡,是因为想听里面的黄色笑话。
    
    恋爱!
    小资女+小资男=三天分手
    小资女+愤青男=世上有多了一个傻小子
    小资女+朋克男=又一个朋克诞生
    
    愤青女+小资男=愤青男+加小资女
    愤青女+愤青男=超级完美组合
    愤青女+朋克男=互殴
    
    朋克女+小资男=朋克女+另外一个男的
    朋克女+愤青男=愤青男哭了
    朋克女+朋克男=爱情消失欲望实现
    
    小资很懂得养生之道。
    愤青只管练一身肌肉。
    朋克根本就不想长寿。
    
    小资的早餐既营养有方便。
    愤青不吃早餐。
    朋克早上不起。
    
    小资喝咖啡是因为已经上瘾。
    愤青喝咖啡是因为别人给了他一包咖啡。
    朋克喝咖啡是为了在自己家里到时差。
    
    小资骑自行车时想的是,有朝一日我要开宝马。
    愤青骑自行车时想的是,全世界骑自行车的无产阶级万岁。
    朋克骑自行车是想的是,这自行车是谁的啊?
    
    小资戴耳机,很可能什么都没听,而是在装酷
    愤青戴耳机听的是什么,你离他五米头能听到一首摇滚版的《国际歌》
    朋克自己就是个大音箱。
    
    50岁的邻居老太太经常能看到对门的小资,像看见一个"栋梁"
    60岁的邻居老太太偶尔能看到对门的愤青,于是总总想报警。
    70岁的邻居老太太突然有一天发现对门的朋克,以为撞见了鬼,吓疯了,被救护车连同朋克一起送进了精神病医院。
    
    小资谈莎士比亚和贝多芬,尽管多数是在装蛋。
    愤青讲俾斯麦和切.齐瓦格,尽管多数上他们在讲自己。
    朋克聊冰激凌和大便的关系,哪个总统最适合做变性手术,大学生和白痴的异同点.章鱼怎么弹吉他,香蕉是雄的还是雌的......
    
    小资在QQ里叫"失眠的饼"或"心渊",让人难分性别,开口习惯说:"你好,我喜欢伯格曼,你喜欢我吗?"
    愤青在QQ里叫"永垂北方"或"弑",就让人以为是男的,开口习惯说:"你看过有关攻占把势底狱的电影吗"
    朋克不用QQ,朋克根本记不住任何密码,朋克认为网络太虚了。
    
    小资在网络聊天室里就变成了愤青。
    愤青在网络聊天室里就变成了小资。
    朋克在网络聊天室说不过三句就被网管踢出去了。
    
    小资发起短信就没完没了。
    愤青打手机总喜欢吼叫。
    朋克总想捡两个手机,自己给自己打。
    
    小资看基耶洛夫斯基和王家卫。
    愤青看格里哥.阿拉齐和杨德昌。
    朋克看[希德与南茜]和自己的演唱会。
    
    小资恋物。
    愤青毁物。
    朋克无任何物,也有任何物。
    
    小资爱饮名酒,为了情调,不过量。
    愤青狂喝扎啤,为了勇气,常烂醉。
    朋克是酒就喝,为了虚无,又吐了。
    
    商业街里。小资看美女用的是含苞欲放的眼神和欲擒故纵的微笑。
    在大马路上。愤青看美女用的是批判世俗的表情和故作镇定的从容。
    随便在任何地方。朋克看美女......朋克看"美"女?朋克眼中根本没有美女,所以朋克看"没"女!
    
    烛光晚餐进行到第37分钟。小资对女友Sophia说:如果有人比我更爱你,他一定是明天的我。我永远爱你!
    在开往西北的火车上。愤青对女友小雯说:愿意跟我一起流浪吗?如果我有个馒头,一半给你,一半给我妈!
    从某张乱床上一觉醒来。朋克对女伴某某某说:唉,你叫什么来着......你是刚才那个女的吗?你怎么还没走啊?
    
    小资说;我相信真爱,也珍惜拥有。
    愤青说:我渴望真情,更追求真理。
    朋克说:我X一切。
    
    小资偷偷看琼瑶,然后跟别人聊曹雪芹。
    愤青偷偷看《金瓶梅》,然后跟人说《花花公子》是资产阶级腐朽的产物。
    朋克明目张胆的看A片。
    
    小资可以消费时尚,引领时尚。
    愤青善于品评时尚,揭露时尚。
    朋克本身就是时尚,但时尚不承认朋克。
    
    小资至少是像个富人。
    愤青仇富。
    朋克反正是怎么都能活。
    
    小资强调品牌,穿西装像模像样。
    愤青支持过货,着装搭配会让民工觉得像有钱的城市人,会让城市人觉得像个有钱的民工。
    朋克喜欢在体恤衫上涂鸦,喜欢改造牛仔裤,喜欢纹身,喜欢金属饰物,喜欢怪异发型,喜欢别人不喜欢的。
    
    小资爱装绅士,常把"请"。"谢谢"。'对不起"等礼貌用语挂在嘴边,乘BUS 时喜欢让座,不乱丢垃圾,关爱女性。
    愤青故意讲粗口,爱施舍乞丐给旁人看,找茬更别人变量哲学,政治,艺术等等等,总想控制女性。
    朋克就是朋克,一发明脏话为乐,抢走乞丐的钱去乘公交,住的地儿像个垃圾场,也像个前卫艺术实验室,不缺女性。
    
    小资说愤青,你简直就是流氓!然后赶紧离开。
    愤青说朋克,你他妈流氓一个!然后打成一团。
    朋克说流氓,你是不是欠偏啊?然后被流氓打!~
    
    小资怀才不遇。变成愤青。
    愤青屡屡受挫,变成朋克。
    朋克遇到唐僧,变成凡人。
    
    小资说人有成为人的原因。
    愤青说人在退化。
    朋克说人人都是SB!


--
世界之大,远超过我们的眼界可以容纳的范围,不管人们走得多慢;走得多快,他们也不会看到更多。真正珍贵的东西是所思和所见,不是速度。

2006年8月12日

看到一些有趣的话,转载

李敖曾经说过:充满了失败经验的上一代人们没有理由责备这一代。李敖还指出:应该放开羁绊,让青年们尽量奔跑,与其流于激烈,不可流于委琐;与其流于狂放,不可流于窝囊……苟能使整个国家年轻活泼到处是朝气,其中有一些青年发几句狂言、道几句壮语、做一点不知天高地厚的傻事,这又算得了什么……在这种认识之下,我觉得上了年纪而又没有朝气的人,实在应该有鼓励青年的雅量。"(《 十三年和十三月》)
 
 
 

一直以来,我都在追逐一种有趣的生活态度。关于有趣,很多人把它简单化了,认为有趣就是好笑、好玩或者很有幽默感。对我来说,有趣不是这个意思,有趣是一种看问题的方式。它并不会直接的表现出来,也不会让别人都看到,而是只有你自己能够体会。

 

比如王小波看萧斯塔科维奇的回忆录,然后就想象这个大作曲家一手抓住眼镜,另一手护住胡子,往别人的烧水壶里吐痰的情景,他就高兴的哈哈大笑,觉得这很有趣。但是他的朋友看了就不笑,说境界不高,思想也不好。我特别能理解王小波当时的心情,因为我也经常有类似的经历。就是说当我觉得一件事情很有趣的时候,周围的人却并不和我持同样的看法。

 

我老家有个人,早年受了些刺激,脑子就不怎么好使了,经常会做出一些奇怪的举动。比如他隔三差五的就会跳到猪圈里去,然后搂着他家的老母猪聊天,控诉他媳妇和老丈人。母猪哪听他这一套,很不耐烦地甩甩尾巴走掉了,然后他就死乞白赖的在猪圈里追着母猪跑。我就在猪圈上面看着这种场面,觉得实在是有趣极了。但是我姥姥却不这么看,她认为这个人是个神经病,并警告我离他远一点。

 

你看,这就是有趣的分界线。每个人眼中的有趣都是不一样的,所以有趣也没有标准可言。有人觉得把"了"说成"鸟"是很有趣的,但是我就觉得很无聊,不仅无聊,而且肉麻,不仅肉麻,而且恶心。我一听到有人说什么吃饭去鸟、吃鸟一块巧克力这类的话,我就受不了。我发誓绝对不使用这种变态的语言,但是在那些使用这种语言的人看来,我这个人就不可爱,假正经,他们就会把我排除在鸟人的体系之外。
 
...... 后来我就释然了,我不能强迫别人接受我的有趣,别人也不能强迫我接受他们的有趣。但是在现实生活中,要做到这一点却很难。因为有趣已经成为了可以用来判断一个人的东西,而一旦一样东西可以判断的时候,就必须首先要制造标准,然后根据标准来进行判断。这句话可能太绕口了,但实际上很好理解。比如你判断一个人是男人,那么标准就是鸡巴。所以,有鸡巴,是男人。没鸡巴,是女人。问题就简单化了。同样,判断一个人是否有趣,有些人认为也需要标准。这时候,分歧就出现了。

 

自认为有趣的人试图通过制定标准来划定分割线,只有认可了他们对有趣的定义,你才会被认为是有趣的。比如他们喜欢说鸟,而你不喜欢,那么 sorry ,你不有趣。他们喜欢在饭局上吹捧,而你却不喜欢,同样,你也不有趣。他们喜欢郭德纲,而你不喜欢(当然,他们现在也不喜欢了);他们喜欢大声喧哗,而你不喜欢;他们喜欢吃屎,而你不喜欢。。。因此,你不是一个有趣的人。

 

有趣就是这样沦丧的。在我眼里看来,有趣首先是宽容,其次才是别的。在这个意义上讲,有趣的愤青依然只是愤青,有趣的脏话也依然只是脏话。王小波之后,我没有再看到什么真正有趣的人。也许那个跟母猪唠嗑的傻子是个例外。


--
世界之大,远超过我们的眼界可以容纳的范围,不管人们走得多慢;走得多快,他们也不会看到更多。真正珍贵的东西是所思和所见,不是速度。

2006年8月11日

幸福是一只温暖的小狗

家里的网络很糟糕,想玩玩DOTA但是老是断线,就打开网络电视看看有什么节目。
 
周星驰专场已经看了好多遍,笑料仍然很足,但是我想换个口味,很久没看日剧了。
 
日剧频道正在播出《导盲犬小Q》,刚巧赶上开始。热乎乎的五只小狗,一副肉脚模样在地板上嗅来嗅去,把纸卷弄得到处都是,水户太太来选导盲犬时,四只小家伙欢天喜地跌跌撞撞跑过去,另外一只用温柔疑惑的小眼神看着水户太太的样子。看起来就觉得很好笑。
 
就想起了自己曾经养过的小京巴,想起来大卖的任天狗游戏。说实话任天狗不是一款能让人入迷的游戏,过于休闲化了,其实更像是模拟城市那样的软件玩具,但是每个人在看到它的第一眼都会发出惊喜的叫声,脸上不自觉堆起温柔的笑,条件允许就会拿起触摸笔来逗弄一番,还会试着叫两声狗狗的名字,看它高高兴兴地跑过来。没人能抵抗一只可爱小动物依恋着自己的感觉,对于女性来说,杀伤力巨大。
 
这些毫无防备亦不会伤害的小狗,很轻易的就让人想起幸福:热乎乎的、软软的、亲亲热热的、不会跑开的、可以信赖的东西。
--
世界之大,远超过我们的眼界可以容纳的范围,不管人们走得多慢;走得多快,他们也不会看到更多。真正珍贵的东西是所思和所见,不是速度。

2006年8月5日

凌晨5点

凌晨5点。
 
从电脑旁起身去卫生间,看着镜子里杂乱的头发和灰败的脸,感觉自己最近放松过度。
 
睡觉、DOTA、小说、音乐、吃饭、睡觉、…………。
 
室友也和我的状况差不多,他和我的区别只在于每过3天去一次超市,而我依靠外卖。
 
空调开到18度,结果感冒了,天天吃干煸肉丝,结果满脸疙瘩。
 
对于留在北京这个结果,我心里松了一口气,或许从这一点上能看出我终究不是个能吃苦的家伙。
 
有时候我很疑惑,我到底想要些什么,我还没有搞明白。一些看起来很平常的事物,在失去之后才知道它们的宝贵之处。得陇,却又望蜀,很累,但是没办法,鱼与熊掌不可兼得,可以自主的话,其实每个人都会想鱼也要、熊掌也要吧。
 
相对于年龄来讲,在心态上还是有些幼稚,性格中有很多不稳定的成分。

--
世界之大,远超过我们的眼界可以容纳的范围,不管人们走得多慢;走得多快,他们也不会看到更多。真正珍贵的东西是所思和所见,不是速度。

2006年8月2日

TEST

MSN空间改版,在资源消耗和版式上让人很不满。刚好www.blogger.com  在国内似乎可以访问了,以前在那里注册了一个账号,开始试用,由于blogger可以给MSN空间发送更新邮件,因此我只要更新blogger,msn也会跟着跟新。
 
先实验一下。

--
世界之大,远超过我们的眼界可以容纳的范围,不管人们走得多慢;走得多快,他们也不会看到更多。真正珍贵的东西是所思和所见,不是速度。

2006年8月1日

最糟糕的情况

好吧,最糟糕的情况出现了。

--
世界之大,远超过我们的眼界可以容纳的范围,不管人们走得多慢;走得多快,他们也不会看到更多。真正珍贵的东西是所思和所见,不是速度。