努力加载中，稍等...
暂无新消息
努力加载中，稍等...
已无更多消息...
这些人最近关注了你
努力加载中，稍等...
已无更多消息
努力加载中，稍等...
已无更多消息
& 关于游戏开发的几个面试问题
Interview questions
征集热心朋友翻译文章，奖励规则：每100汉字奖励10QB，30天内互动奖励0 - 50QB.
翻译请求：申请翻译
该文章来自用户转载
Interview questionsPosted on Nov 5, 2016 Recently saw quitesome twitter discussions about good & bad interview questions. Here’s a fewI found useful.In general, the mostuseful questions seem to be fairly open-ended ones, that can either lead to amuch larger branching discussions, or don’t even have the “right” answer.Afterall, you mostly don’t want to know the answer (it’s gonna be 42 anyway),but to see the problem solving process and/or evaluate general knowledge andgrasp of the applicant.The examples below arewhat I have used some times, and are targeted at graphics programmers with someamount of experience.When a GPU samples atexture, how does it pick which mipmap level to read from?Ok this one does have the correct answer, but it still can lead to a lot of discussion. Thecorrect answer today is along the lines of:GPU rasterizeseverything in 2x2 fragment blocks, computes horizontal and vertical texturecoordinate differences between fragments in the block, and uses magnitudes ofthe UV differences to pick the mipmap level that most closely matches 1:1 ratioof fragments to texels.If the applicant doesnot know the answer, you could try to derive it. “Well ok, if you were buildinga GPU or writing a software rasterizer, what would you do?“.Most people initiallygo for “based on distance to the camera”, or “based on how big the triangle ison screen” and so on. This is a great first step (and was roughly howrasterizers in the really old days worked). You can up the challenge then bythrowing in a “but what if UVs are not just computed per-vertex?”. Which ofcourse makes these suggested approaches not suitable anymore, and somethingelse has to be thought up.Once you get to the2x2 fragment block solution, more things can be discussed (or just jump here ifthe applicant already knew the answer). What implications does it have for theprogramming models, efficiency etc.? Possible things to discuss:The 2x2 quad has to execute shader
instructions in lockstep, so that UV differences can be computed. Which
leads to branching implications, which leads to regular texture samples
being disallowed (HLSL) or undefined (GLSL) when used inside dynamic
branching code paths.Lockstep execution can lead into
discussion how the GPU what are the wavefronts / warps /
SIMDs (or whatever your flavor of API/GPU calls them). How
branching works, how temporary variable storage works, how to optimize
occuppancy, how latency hiding works etc. Could spend a lot of time
discussing this.2x2 quad rasterization means
inefficiencies at small triangle sizes (a triangle that covers 1 fragment
will still get four fragment shader executions). What implications this
has for high geometry density, tessellation, geometric LOD schemes. What
implications this has for forward vs deferred shading. What research is
done to solve this problem, is the applicant aware of it? What would they do to solve or help with this?You are designing alighting system for a game/engine. What would it be?This one does not evenhave the “correct” answer. A lighting system could be anything, there’s atleast a few dozen commonly used ways to do it, and probably millions of morespecialized ways! Lighting encompasses a lot of things – punctual, area,environment light sources, realtime and baked il direct and shadows, reflections,tradeoffs between runtime peformance and authoring performance, platformimplications, etc. etc. It can be a really long discussion.Here, you’reinterested in several things:General thought process and how do
they approach open-ended problems. Do they clarify requirements and try to
narrow things down? Do they tell what they do know, what they do not know,
and what needs further investigation? Do they just present a single
favorite technique of theirs and can’t tell any downsides of it?Awareness of already existing
solutions. Do they know what is out there, and aware of pros & cons of
common techniques? Have they tried any of it themselves? How up-to-date is
their knowledge?Exploring the problem space and
making decisions. Is the lighting system for a single very specific game,
or does it have to be general and “suitable for anything”? How does that
impact the possible choices, and what are consequences of these choices?
Likewise, how does choice of hardware platforms, minimum specs, expected
complexity of content and all other factors affect the choices?Dealing with tradeoffs. Almost
every decisions engineers do involve tradeoffs of some kind - by picking
one way of doing something versus some other way, you are making a
tradeoff. It could be performance, usability, flexibility, platform reach,
implementation complexity, workflow impact, amount of learning/teaching
that has to be done, and so on. Do they understand the tradeoffs? Are they
aware of pros & cons of various techniques, or can they figure them
out?You are implementing agraphics API abstraction for an engine. How would it look like?Similar to the lightingquestion above, there’s no single correct answer.This one testsawareness of current problem space (console graphics APIs, “modern” APIs likeDX12/Vulkan/Metal, older APIs like DX11/OpenGL/DX9). What do they like anddislike in the existing graphics APIs (red flag if they “like everything” –ideal APIs do not exist). What would they change, if they could?And again, tradeoffs.Would they go for power/performance or ease of use? Can you have both (if “yes”- why and how? if “no” - why?). Do they narrow down the requirements of who theabstraction users would be? Would their abstraction work efficiently onunderlying graphics APIs that do not closely map to it?You need to store andrender a large city. How would you do it?This one I haven’tused, but saw someone mention on twitter. Sounds like an excellent question to me, again because it’s very open ended and touches a lot of things.Authoring, proceduralauthoring, baking, runtime modification, storage, streaming, spatial datastructures, levels of detail, occlusion, rendering, lighting, and so on. Lotsand lots of discussion to be had.Well this is all.That said, it’s beenages since I took a job interview myself… So I don’t know if thesequestions are as useful for the applicants as they seem for me :)
关于游戏开发的几个面试问题
版权所有，禁止匿名转载；禁止商业使用；禁止个人使用。
翻译：赵菁菁（轩语轩缘）
审校：李笑达（DDBC4747）最近我在推特上看到了一些关于好&坏面试问题的讨论，这是我找到的一些有用的问题。 总的来说，最有用的问题似乎都是非常开放的，这些问题可以引出更广泛的讨论，或者甚至没有“正确”答案。毕竟，大多数时候你不想要知道答案（反正快到42了），但是你想要看到问题解决的过程，以及/或者评估申请者的大体知识和掌握情况。 下面是我有时会问的一些例子，主要针对于有一些经验的图形程序员。 当GPU取样纹理时，GPU怎样选择从哪个Mip贴图级别读取？ 好吧这个问题确实有正确答案，但是它还是可以引出很多讨论话题。目前正确答案应该沿这个路线回答： GPU以2×2的片段块（fragment block）光栅化一切事物，计算块内片段之间水平和垂直纹理坐标的差异，并利用UV差异的大小挑选片段：纹理最接近1:1 Mip贴图级别。
如果申请人不知道答案，你可以尝试提这样的问题：“那么，好吧，如果你正在建立一个GPU或编写软件光栅化器，你会做什么？“。 大多数人最初的答案是“基于到摄像头的距离”，或“基于屏幕上的三角形有多大”等等。这是伟大的第一步（大致是光栅器在很久之前怎样工作）。你可以提升挑战难度，然后抛出一个问题：“但是如果UV不只是逐顶点计算的怎么办？“。这当然会使这些建议的方法不适合了，还必须考虑其他东西。 一旦你获得了2×2片段块的解决方案，能讨论的就更多了（如果申请者早已知道答案可以直接跳到这里）。对于编程模型，这个解决方案有什么影响，效率还是什么？可能讨论的事情： ·2x2四边形必须步调一致地执行着色器指令，这样一来就可以计算UV差异。这会带来分支问题，从而导致当使用内部动态分支代码路径时，纹理样本经常被禁用（HLSL）或未定义（GLSL）。 步调一致的执行可以引入这样的讨论：GPU总体上是如何工作的；Wavefront / Warp / SIMD是什么（或者无论你喜欢API/GPU怎么称呼它们）。分支是怎样工作的，临时变量存储的工作原理，如何优化占有率，隐藏延迟的工作原理等等，可以花很多时间讨论这个。 ·2x2四边形光栅化意味着小三角的大小无效（覆盖了1个片段的三角形仍将有四个片段着色器执行）。这对于高几何密度、镶嵌和和几何LOD方案有什么影响？这对于提前和延迟着色有什么影响？为解决这一问题有哪些研究，申请人知道吗？他们会做什么来解决或帮助这个问题？ 你正在为一个游戏/引擎设计光照系统，这个系统会是什么样的？ 这个问题甚至没有一个“正确”答案。光照系统可以是任何样子，但是至少有几十种常用的方法，甚至还会有几百万种更专业的方法！光照包括很多事情——准时，区域，环境光源，发光面；实时和烘焙的照明组件；直接与全域照明；阴影，反射，体积光效果；运行性能和编写性能之间的权衡，平台影响，等等，等等，这可以是一个非常长的讨论。
在这里，你会对几件事感兴趣： ·总体的思维过程以及他们如何处理开放式问题。他们能够明确需求并试图缩小范围吗？他们会告诉他们知道什么、不知道什么、什么还需要进一步研究吗？他们只是提出了一个他们最喜欢的技术而不能说出任何缺点吗？ ·意识到已经存在的解决方案。他们知道方案是什么并且了解常用技术的优缺点吗？他们自己都尝试过了吗？他们的知识是如何跟上时代的？
·探索问题空间和做决策。该照明系统只能针对一个特定的游戏吗？还是它必须通用且“适合所有游戏”？这会如何影响可能的选择，这些选择的后果是什么？同样，硬件平台、最低配置需求、内容的预期复杂性和所有其他因素是怎样影响你的选择的？
·处理权衡。几乎工程师做的每一个决策都涉及到某种类型的权衡——通过选择一种方式或其他方式做一些事情，你正在做一个权衡。它可以是性能，可用性，灵活性，多平台覆盖，实现复杂度，工作流影响，必须进行多少学习/教学，等等。他们了解权衡吗？他们深知各种技术的优点和缺点，或者他们能把它们解答出来吗？
你正在为一个引擎实现图形API 抽象，它是什么样的？ 与上面的照明问题类似，这个问题没有一个正确的答案。 这一问题测验了对于当前问题空间（控制台的图形API，像DX12/Vulkan/Metal 的“现代”API，和像DX11 / OpenGL / DX9的旧的API）的认识。他们对于现有的图形API喜欢什么不喜欢什么（如果他们“喜欢一切”就给红牌——理想API并不存在）。如果他们能改变什么，他们会改变什么？
再接着问权衡的问题。他们可以带来功率/性能或易用性吗？你能实现上述两种效用吗？（如果“是”——为什么、怎样实现？如果“否”——为什么？）他们是否缩小了抽象用户是谁的需求？如果底层图形API不紧密映射到他们的抽象，这些抽象还能高效工作吗？ 你需要存储和渲染一个大城市，你要怎样做？ 这一个问题我没有提过，但我在推特上看到有人提到。对我来说听起来像是一个很好的问题，我再次强调一下，因为它是非常开放的，涉及到很多东西。
创作，程序编写，烘焙，运行时修改，存储，流媒体，空间数据结构，细节层次，遮挡，渲染，光照等。可以有很多很多的讨论。 好吧，这就是所有。 也就是说，这些问题对我很有用，但是我自己已经很久没有面试了……所以我不知道是否这些问题对申请人一样很有用:)
【版权声明】 原文作者未做权利声明，视为共享知识产权进入公共领域，自动获得授权；
分类：程序新手圈
请勿发表无意义的内容请勿发表重复内容请勿发表交易类内容禁止发表广告宣传贴请使用文明用语其它
淫秽色情政治倾向人身攻击抄袭剽窃广告刷屏恶意挖坟冒充他人其它
登录后参与讨论。点击独立游戏开发者应该思考的50个问题
对于一个独立开发者来说，也许他们会碰到许许多多的问题，不过在他们的产品迈出第一步之前，如果能好好问一下自己这篇文章中的50个问题，并且都能给出答案的话，也许他们的游戏会走的一帆风顺。作者西蒙·班尼特Simon Bennet不是程序员，不是艺术总监，不是游戏设计师，也不是产品经理。不过他在游戏行业里做过市场、媒体、法务、HR、IP管理甚至是财务经理，见过了大大小小工作室的他，给开发商们抛出了这五十个问题，而这些问题中有很多都是独立工作室会遗忘的重要环节。西蒙·班尼特称：“这绝对不是一个详尽的清单，可能有些问题依然会有遗漏，不过如果六年前我的工作室开始制作第一款游戏之前有人告诉我这50个问题，相信我们能更为强大”。首先，我们从大框架来分。整个游戏从创意到产出价值分为五个阶段：1.游戏创作（从创意到制作游戏）2.市场营销（让别人知道你的游戏）3.销售（正式出售游戏）4.维护游戏（让玩家认同）5.产出价值（利用游戏赚钱）以下，就是这50个问题。项目启动的问题：04.jpg1.你是游戏圈的新人么？你的团队是新手么？2.你有一个管理整个项目的财务么？3.你有发行商么？还是你准备自己发行自己的游戏？4.你有足够的钱和时间支撑整个团队么？5.你有合适的团队，并且这个团队清楚你要做什么么？6.你确定整个团队都会100%把精力放在这个项目上么？7.你有合适的IP么？你将围绕这个IP做哪些内容？8.你跟所有参与项目的人都签有合同么？游戏开发的问题：03.jpg9.这是个有着明确市场需求的游戏么？10.如果它只是个，那么它吸引玩家的特点在哪里？11.你的游戏有没有独特的卖点？12.你有认真测试过玩家的喜爱程度么？13.你有适当的更新计划么？14.资金链断链的话，你有应急计划么？15.你有确定游戏上架时间么？16.你有完整地做过QA测试么？17.你有考虑过手中的IP如何做到利益最大化么？18.你有考虑过为游戏加入社区元素么？19.最重要的一点，你觉得自己的游戏有趣么？！市场营销的问题：05.jpg20.你的游戏准备针对哪个地区的用户？（本地？美洲？欧洲？全世界？）21.你的工作室在哪里？22.你有没有跟媒体做过预热？有没有在Youtube上发布视频？23.有没有准备好游戏发布时使用的新闻稿？24.有没有制作令人兴奋的游戏预告片？25.有没有预约访谈以及独家新闻？26.有没有把宣传能力发挥到极致？27.有没有在社交媒体上宣传？28.有没有在博客上宣传？29.有没有建立游戏或者工作室的网站？游戏销售的问题：06.jpg30.除了Steam以外，你有没有将自己的销售渠道最大化？31.你有没有实时监控销售数据？32.如果从自有渠道发布的话，你有没有制定降价和促销方案？33.你的游戏有没有经过本地化处理？34.你有没有做出最为合适的定价？35.游戏音轨你准备出售么？36.你准备跟其他游戏交叉推广么？37.你准备跟其他游戏捆绑销售么？维护游戏的问题：38.你真的已经完成游戏开发以及销售程序么？39.玩家满足于你的游戏么？不满足？赶紧打补丁！40.有没有付费下载计划？41.玩家有地方反馈游戏bug以及获得技术支持么？42.能做到密切关注玩家反馈，并第一时间做出相应改动么？财务问题：43.你的现金流能支撑游戏的进一步发展么？44.有没有一个专职财务计算年收益？45.分配多少给市场营销费用？46.有没有做过销售预测（高/中/低）47.有没有考虑过税费问题？48.你的项目有没有减免税收政策？49.你有没有考虑过RDA投资？50.你打算自己投资还是准备融资？当然，第十九个问题永远是重中之重，你的游戏有趣么？如果连你自己都没有信心的话，那么之后三十一个问题完全可以忽略不计，推倒重做，重新来过。如果对自己的游戏有信心的话，仔细思考过这50个问题，然后就放开手脚大干一番吧！
正文已结束，您可以按alt+4进行评论
相关阅读：
相关搜索：
[责任编辑：jojozhu]
热门搜索：
Copyright & 1998 - 2017 Tencent. All Rights Reserved游戏开发设计探讨：7个不可避免的问题
游戏开发设计探讨：7个不可避免的问题
这世上有无限多的画作，但人们对于杰作与庸常之作的定义却更为有限。游戏亦同此理，电子游戏的无限空间已经被限定了，其无限性也可能具有局限性。总之，游戏设计似乎具有一定规则。
“创意常量”是我用于描述这些规则的术语。它们是我们设计师所遇到的一些基本、定型的实用主义现实。我将其称为常量而非限制是因为，限制听起来更像是可以被打破的任意 规则。不要误解我的意思：可分解为原子的电子游戏当然存在许多任意规则，尤其是题材惯例。但常量是不同的。
常量是一个总是存在的因素，在某些方面是一种界线，但也是一种支柱。例如，光的最大速度(C)就是一个常量，它的影响遍及整个宇宙。c意味着到达其他星球远比建设一艘宇宙 飞船更困难，但它在将质量转变为能量、相对交互等方面也发挥着重要。我们对c的了解促进了最为现代技术的发展。
我们无法直接影响常量，所以只有我们的造物主知道如何使用它们。在游戏领域，看似最为明显的一个常量就是“平台”。平台局限性通常主导着任何游戏开发过程中的考虑因素 (游戏邦注：如控制范例，支持的商业模式，用户群体等)，但它们也是可变化的。今天令我们止步的东西也许明天就不再是个障碍(反之亦然)，所以平台是一个不断移动的目 标。因此它们并不是常量。
与之相似，人们也很容易将“玩家”视为一种常量，因为游戏就是用来给人玩的，所以我们必须时时考虑到玩家。这一点不假，但并不明确。多数游戏设计常量与玩游戏的心理活 动有关，如玩家怎么想和看待游戏，但它们必须分别来讨论才有意义。“受众”、“市场”或“规则”也同此理。这些都是制作游戏中的一个环节，但也都太容易变化或者普遍了 。
简而言之，我认为游戏设计有7大不可避免，但却可以帮助创造强大玩法的常量。
我曾将这个理念称为“趣味”，将其视为第一个常量，但趣味是许多人所分析的一个热词，对于新一代游戏设计师来说它是一种呆板的限制。体验《dys4ia》这种游戏并没有太大 趣味，但仍然有一定意义。我后来才发现我真正想表达的是“迷人”。
我经常遇到一些想避开系统的游戏设计师。摇骰子、规则和数字看起来都太乏味了，对于想创造情感、故事和意义的设计师来说它们都太机械化和数学化了。所以他们可能会创造 出充满交互而没有系统的体验型游戏，或者是较少交互性并且鲜有人问津的游戏。玩家可能会问“到处走走的感觉不错，但玩法在哪？”
游戏玩家的观点不无道理。缺乏有趣的逻辑、机制、数据、操纵等因素可能会让游戏折寿。他们可能有兴趣玩一两个小时，但不会持续太久。在一个重要社区也许这并不会是什么 扫兴之事，但在这个群体之外就会令游戏陷入困境了。
游戏应该具有迷人的特点。它必须拥有相互作用的活跃和经济机制，以便创造一个动态问题的幻象。无论是《模拟城市》中的大型复杂模拟，体育运运中的规则，或是冒险游戏中 的解谜行为，迷人的系统通常就是令玩家深陷其中的一个关键矢量。当你吸引住他们的时候，就可以带入情感。但它并不能独立存在。
完善与不完善游戏之间的区别就在于玩家所知信息的质量。例如，西洋棋就是一款完善的游戏，因为它所有的棋子都在棋盘上了，玩家知道所有的规则，并可能因此了解可行的移 动。而扑克牌就是一款不完善的游戏。玩家了解规则，但却不知道对方会在哪个时刻抛出哪张牌。他们只能靠猜。
所有电子游戏都是不完善的，即使是那些看起来相反的游戏(如电脑版本的西洋棋)。这是因为玩家只是在捣鼓与一个代码黑匣子，但却无从知晓后者的真正规则和操纵方式。游 戏会根据自己所隐藏的结构来执行规则，通常不会告诉玩家它的运行原理。所以玩家只能边玩游戏边掌握其中规则，由游戏来要求玩家采取行动。这具有令玩家产生好奇心的副作 用。
玩家会对玩法的公平性变得非常敏感。在体育运动中，玩家之间常会产生公平问题(例如在足球中的低级作弊行为在该项运动中被视为合理的)，但在电子游戏中玩家通常得自己 控制系统。例如，他们认为游戏对自己并不公平，而开发者则不然。他们要想象其中存在问题，甚至为了玩家而考虑进行一些打破平衡的修改(游戏邦注：例如增加战利品的掉落 率)以此来修复“破坏”的玩法。
另一个就是对游戏背后世界的感觉。电子游戏令人如此着迷的部分原因就在于，对某些人来说故事性的体验就是它所隐藏层次的感觉。玩家通常会赋予NPC(有时候甚至是物体)一 些实际上并不存在于游戏的人格和性格。他们相似《Hyrule》远比自己所想象的更大，并且坊间神话流传着一些可以解开其隐藏秘密的方法。他们看到《传送门》一面墙上的“这 块蛋糕是个谎言”的涂鸦，并想象出一个与游戏设计师的意图毫不相干的故事。
不完善的信息是一个很棒的常量。电子游戏可以让人信赖，也可以是恐怖的，惊人或者不可思议的，因为我们永远不知道它们表面之下在发生着什么情况。作为设计师你得拥有让 玩家因此而大开眼界的能力。
支持键盘 ← 和 → 分页
发布此文仅为传递信息，不代表认同其观点或证实其描述。
类型：大型RPG
特征：动作
类型：大型RPG
特征：沙盒
类型：大型RPG
特征：沙盒
你不知道点进去会是什么
Wan网页游戏免费玩}