@fa93hws
2017-08-30T12:30:31.000000Z
字数 10243
阅读 766
未分类
@podcat asked me to prepare a Dev Diary from a Project Lead perspective...
Quick background on me: I came on as Project Lead for HOI4 shortly after the game was released, last summer. That’s my perspective. I speak from a expansion-development point of view, and our work going forward.
Podcat要求我从一个项目领导的角度准备一篇开发日志…………
首先做一下自我介绍，去年夏天钢4游戏发售没多久我就调过来做项目领导。而我的目标，从扩展包的角度来看，就是让我们的工作继续下去。
The purpose of today’s Dev Diary is to give you a little insight into our development process.
Why we fix some bugs and leave others... How we decide what goes into the next expansion... and more.
今天难道开发日志的目的是告诉你们我们的开发进度。为什么有些bug我们修复了而另一些没有？我们如何决定下一个扩展包会有什么新内容？以及一些更多的问题
Imagine, if you will, a crowded bar
假设你是一个拥挤的酒吧
Imagine all the customers screaming out their orders at once, to a single hard-working bartender.
想象一下所有的顾客同时都冲着唯一的酒保叫嚣着他们的订单(第一反应是鸡尾酒问题。。。)
How many words do you think the bartender will be able to make out, over the collected noise of the crowd?
这个酒保能从这嘈杂的纷扰中听到多少单词呢？
How many drink orders do you think he will he be able to get right?
有多少饮料这个酒保能够正确的调制出来呢？
If you answered “none”, you’d probably be close to the truth.
如果你的回答是“没有”的话，你可能就离真相很接近了。
My job, if I’d been working in that bar, would be to to organize a queue-system that works.
To move things along and make sure that people get what they want, as quickly as possible.
从这个酒吧的例子来讲，我的工作就是去实现一个可用的队列系统。移动东西来让顾客能尽快得到他们想要的。
As project lead at Paradox; it’s my job to make sure that our players get what they want.
Best possible value in the game, within the shortest possible amount of time.
作为P社的一个项目领导，我们的工作就是让我们的玩家得到他们想要的功能。在最短的时间内制作出最符合他们预期的游戏内容。
Here is a super condensed version of how the team and I go about making this happen.
以下就是一个非常简练的小结，来总结我和我的团队是如何尽力让之前所说的目的成为可能的。
First, within the team; the designer speaks for the players. They’re the one that decide what the team should do.
首先，在团队内部，设计师站在玩家的角度思考问题。他们(设计师)是决定这个团队该做什么的人。
(Game director @podcat and game designer @Pallidum , in our case.
我们的团队中主任是@podcat，游戏设计师是@Pallidum
Continuing with the bar analogy; they’re the people who have a feel for the market and decide what goes on the drinks menu.)
继续我们的酒吧例子，他们就是那个对市场有研究的人，以及决定酒吧的菜单上有什么的人。
New content to keep players engaged and happy... Weaknesses in the game that needs to be addressed... A balanced mix of all that good stuff is collected together in a “design document”.
让玩家保持兴奋和投入的新内容，游戏中不当的需要修改的内容。对这两个点的权衡之后的点会被收集起来，变成一个设计文档(design document)
The document explains the vision for each new feature, or fix, that goes with a new expansion. It essentially serves as a specification, or commission for work to be done, for the team.
这个设计文档会解释新的扩展包中新功能或者bug修复的背景。它在团队需要完成工作中就像规范和委托书的一样。
How do we decide what new features and fixes go into an expansion?
我们是怎么决定哪些新的功能或是bug修复需要在下一个扩展中加入的呢？
How do we choose which bugs to fix? (A bug’s journey from the bug forum to being fixed)
我们怎么决定哪些bug要修复(一个从bug反馈论坛决定的需要修复的bug日志)
As I mentioned; we have a big database with bugs, improvement ideas and feature-suggestions.
(Really big. You just won't believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it's a long way down the road to the chemist, but that's just peanuts to our database.)
就象我之前提到的一样，我们有一个庞大的bug,改进方案和功能建议数据库
(真的很大，你难以想象的大。我是说，你可能觉得你家到药店很远，但是这对我们的数据库来说就像花生一样大)(真尼玛会吹，千万级别都不到的数据库好意思这么吹……谁给瑞典人的脸…………)
A lot of entries in this database, however, are related to the same underlying system. Doing an overhaul on that system will get rid of a whole bunch of bugs. These are things we prioritize.
然而，这个数据库中的很多内容都关于一个同样的系统。对这个系统的改进可以从这个数据库删掉一大堆的内容，这也就是我们要去优先完成的任务。
A bug often starts out coming onto our radar by being reported, here, in our bug forum.
(I really want to stress this point, because we occasionally see people posting bug reports on reddit or other places. The odds of someone from Paradox stumbling over those reports and carrying them forward into our database are slim.)
我们往往是通过玩家在官方论坛的反馈汇报来发现bug的。(我要强调的就是官方论坛的作用，因为我很少看到玩家在rediit或者其他地方汇报bug。有P社员工在其他论坛捣鬼的可能性很低)
The bug is transferred from here into our database. And we start looking into it, by analyzing it.
We need to know how frequent the problem is. How serious, and how quick it is to fix.
The more frequent or serious it is increases its chances of getting fixed. Soon.
If it also happens to be quick to fix… well, that’s just a win-win.
当bug进入我们的数据库之后，我们就会开始研究分析这些问题。我们需要知道这个bug发生的频率有多高，发生后的严重性有多大以及我们可以多久去修复它。高频，严重的bug都会增加我们立即去修复他的概率。如果碰巧这个bug也用不了多久就能修复，那就是双赢的结局了(如果是这样你们为什么要看修复这个bug要花多少时间……直接到分析频率和严重性之后直接把它标上要修复后在估算修复要多久不才是正常的吗。。。吹牛都不会吹= =)
If a bug is serious, frequent and quick to fix and it’s still not being fixed… The most likely explanation to why we’re not fixing it ; is because we simply couldn’t fit it into our schedule.
如果一个bug后果很严重，发生的频率很高并且修复起来也很容易但是它依旧没有被修复……那么最后可能的结果就是我们原定的计划没有把他包含进去……(……逻辑上我是真的搞不懂了。。我只能理解为有更严重或者发生频率更高或者修复起来更容易的bug的优先级比这高吧。。。。)
It might help to understand this, if you…
如果你……这或许让你更好的理解我们把。
Think of the development process as a single work day...
想一想一个工作日的开发流畅吧
Serious things you hear about, before lunch, will get fixed before the day is done. For sure.
Then you might work on something else, with lower priority, for a while.
午休前你听到的严重的事情你在当天就一定会去解决。之后你可能就去做一会儿低优先级的事情
Until the next big problem pops up.
直到下一个严重的问题出现
But, by then, you can’t start on it. Because you can’t get it all the way done, before you have to go home. It’ll have to wait until the next day.
但是，到那个时候你不可能再去解决他的，因为已经到下班时间了啊！！回家了啊！！！只能明天在搞了啊！！！(说的这么理直气壮好意思吗。。。)
So, in order to not waste precious time, you squeeze in something else that will fit.
因此，为了不浪费宝贵的时间，你会把另外的事情放在今天完成而不是更高优先级的事情。
This is how our development cycles work. Sometimes we simply can’t start on something and get it fixed, or improved, before the expansion has to ship.
这就是我们的日常开发工作流程。有些时候我们只是不能在扩展包发行前挖新的坑。
(This also illustrates how sometimes things with lower priority get done when some higher prio stuff are left for later.)
这也就是为什么有些低优先级的事情做了，而高优先级的事情反而没做的原因。
Difficult judgement calls
难以判断的建议
Other bugs or suggestions are more up for debate.
另外的一些bug或是建议都是比较有争议的
Doing something that will make one group of people leap for joy - might seriously anger another group. We have to stay on top of that.
有些事情做了回让一部分玩家欢呼雀跃，同时也会伤害另一部分玩家的感情。那我们只能保持不动。
The big time-stealers
耗时任务
Not to mention that some requests, like improving AI, is a perpetual job that can’t be rushed.
更不用说有些比如对AI优化的要求是一个不是一朝一夕能完成的长久工程。
As obvious as it is that an area needs work; some things are like hatching an egg. It takes the time it takes. No matter how many bodies you throw on the problem.
很明显这必然是一个需要加工的方面。有些问题就像孵鸡蛋一样，他就是要这么多时间，跟你在这个问题上分配多少人根本没有关系(这点还是同意的，人月神话中讲的也是这个道理)
(Btw, this is how I imagine a Steam Summer Sale going. If Steam was a physical store.)
顺便，如果steam是一个实体商店的话，那么夏季促销差不多就是图中的景象了。。。
The Breakdown & Estimation process
任务细分和预估阶段
Moving on: Once the design doc is complete… The team takes the design and breaks it down into bite-size tasks for coders, content designers, art, UX-design, sound etc.
继续说吧，当设计文档完成之后，团队会把这个文档分成一个个最小的任务后分配给程序团队，内容设计团队，美术团队，UI设计团队以及音效音乐团队
When we have everything broken down into a list of tasks; we sit down together and “estimate” each task. Giving us an idea of how long the full feature will take to develop, once you add it all together.
当我们把所有任务都分成一个原子任务的清单后，我们一起坐下来"预估"一下每个任务的消耗。这就能给我们一个大概整个扩展需要多久能完成的概念。
How are deadlines and release-dates determined?
死线和预估的发售日期是怎么确定的？
Paradox has a plan for how many expansions/DLCs we should release per year.
P社队旗下每个游戏都有一个每年发行多少扩展/DLC的计划
HOI4 release dates are determined based on: 1. that plan, 2. how quickly we can reach the desired sell-value of the release, and lastly 3. coordinated with specific dates that our marketing team have selected.
钢4的发行日期取决于
1. 这个计划
2. 我们多久能做足够一个扩展包的内容
3. 和营销组协调发行日期
(More on this subject in next week’s Dev Diary.)
这个部分会在下周的日志中展开讨论
Can we make the expansion-design happen within the deadline?
我们能在死线前做完吗？
After all features have been estimated; I can figure out if what we want to do is possible within the deadline. With the people at our disposal.
所有的需要做的功能都被预估完之后，我们才能确定这些是不是能够在死线前完成。
If yes: Huzzah!
如果可以的话，万岁！
If not: This is where I have to crush the designer’s hopes and dreams.
如果不能的话，我就不得不让设计师失望了
[IMG]
Splat!
啪！
We need to cut something in order to be able to finish on time.
我们必须砍掉一些内容来在死线前完成！
This is something we discuss and agree on, together. While I gently pat their backs and hand them tissues.
这是我们一起共同决定的，我只是站在团队的背后支持他们，并处理这些问题。
What gets cut?
哪些内容会被砍掉
When cutting something I have to consider, for example:
当需要砍掉内容的时候，我会考虑比如
- The desirability and priority of the feature.
- 这个功能的需求度以及优先级
- What people we have available.
- 我们手底下的员工
- How much, and what, each person can work on.
- 每个人的工作能力
- While not being blocked, or blocking, someone else.
- 有没有遇到什么问题
- What features tie into other features.
- 哪些功能和其他功能更相通
(If there is anything independent enough to cut cleanly.)
有些与其他功能无交互的被砍掉也不会有什么影响
Sometimes laying this complex puzzle, trying to fit high priority pieces together, is trickier than trying to nail jello to a wall. Things slip and change constantly. This is the very essence and nature of development work.
有时候在这些复杂的条件下，把高优先级的事项写入清单列表比在墙上钉一个果冻还难。计划赶不上变化，这是工作中再正常不过的事情了
Speaking of the nature of development work… While the example above mostly serves illustrate problems with communication, which is always a factor when people with different perspectives discuss something… I think it says something about how frequent certain development problems are; that a site exists where you can create your own project cartoon, like this one.
说到开发工作的本质，之前提到的几个极端的例子都是讲述了在交流中的问题。不过这些问题也是不同背景的人探讨在过程中无法回避的问题。我认为这也说明了这些问题发生的有多频繁。有一张很经典的图片就阐述了这一切。
The issues that Paradox and HOI4 struggle with are the same problems that all IT projects, everywhere, grind their teeth over. It’s terribly complex work. Which is why, although the problems and risks are well known and can be anticipated and planned around, to a degree… they remain.
之前说的问题，在所有的IT项目，包括P社和钢4所要面对的都是一样的。这在工作中是极端的复杂。这也就是为什么有些你们发现的问题已经广为人知并且也在某种程度上写入了计划。。。但是他们还是没有被修正的原因。
The silver lining, I think, is that while our problems are the same… we at Paradox have a hell of a lot of fun while working on them.
不过希望还是有的，毕竟这些问题都是一样的。我们在P社内解决这些问题还是比较开心的。
Next week, our Brand Manager will write a Dev Diary. Before handing the baton back to podcat.
下周是我们的品牌经理来写开发日志了。之后开发日志会回到Podcat的受伤
Don't forget to tune into World War Wednesday today at 16:00CEST on https://www.twitch.tv/paradoxinteractive! To see podcat run Germany in massive co-op, with the other devs as generals.
别忘了本周的周三世界大战哦。