作为工程师自己制作游戏

在Unity for Software Engineers系列中，我简要介绍了Unity中的游戏开发。在过去的几个月中，订户一直在关注该系列文章，经常建议涉及或阐述的领域。几个月前，一位读者（也是一名软件工程师）向我伸出援手（内容经过精心编辑，重点突出）：

对我来说最大的未知数是：如何开始？创建游戏的过程是什么样的？我应该先建立场景吗？我应该先设计游戏机制吗？有了商业软件，它就变得更加熟悉了。它很容易想到：“好吧，我需要编写DAO或控制器等。”但是有了游戏，我就迷失了。

尽管没有一个正确的答案，但我们仍然可以做出一些区分，以帮助我们适应新环境。答案无疑也将取决于谁在进行开发：个人，小型独立团队还是大型工作室？如果是个人，答案还取决于他们的主要技能：开发人员，艺术家或设计师？

在这里，我将对启发式软件特别有用，这对于作为独立项目，业余爱好或概念验证来独立开发游戏的各个软件工程师而言非常有用。

你知道你的比赛是什么吗？您对您的游戏将有什么感觉？您知道这个游戏会有什么样的风格，控制和主题吗？

如果是，则可以决定从哪里开始编码。否则，还有其他一些问题要问自己。

不介意项目是完全可以的！也许您是在制作原型。也许您在墙上扔了一堆迷你游戏，然后看到了什么东西。或者，您正在寻找灵感并尝试实施随机机制，以了解有趣的地方。

如果你希望开始在特定的凝聚力的游戏上工作，你将很大意想知道你在建造什么。考虑头脑风暴和素描一个非正式的游戏设计文件。您可以决定使用的各种细节级别的模板。特别是作为一个软浪费的人在我大脑中玩抽象想法，我将从一个超高级的GDD开始，涵盖了我想到的游戏的感觉，主题，类型和力学。也许有几张图片或吸引力的草图，这就是它。本练习的关键部分将是我正在努力的机制名单。

如果您想要原型和实验，您应该已经有一个可能是有趣的1-2力学的幻觉：可能是不寻常的运动或不同的控制计划。它可能是一个传统的技工，你想知道如何实现。例如，我可能决定建立一个第三个人角色和科法拉控制器，看看它的“感觉”，试验它一点，并且发起了我感觉良好的光滑和抛光。我最终可能会在我的背部口袋中保持该码，或者我可能会使用与该控制器一起使用的播放会话来移动场景，添加一些资产，并使用它作为一个初期来看，看看“感觉”各种机制和设计。

许多迭代软件开发模型的目标是向软件开发出来。通过快速失败并提前获得反馈来这样做。在GameEvelopment中，成功的主要指标是一种感觉：游戏应该是福伦。所以，在决定在游戏工作时开始的东西，一个询问的询问是：“我怎么能看到这个游戏尽快是有趣的吗？”或“我如何”如何实现游戏的“有趣”部分尽快？”

这样做的一种方法是看看游戏的机制并在某种命令中实现它们。与我共鸣的建议是在首先是最“核心”机械机械的游戏力学。

让我们抓住1945年的射击游戏 - 作为一个例子。这是我在重视的降序编写其主机的尝试：

如果我正在尝试从头开始发展1945年，我将在该命令中实施该列表。游戏的力学互相建立，所以我只能判断出来的“乐趣”是如果我能在屏幕上移动，如果我有障碍清除（否则，只需按下空间和射孔就会出现飞机）。

在更简单的游戏中，我们可能会订购我们的机制，以便每个新功能都会增加TOA游戏的感觉。所以，随着每个新的机械师添加，如果它添加了您希望添加的内容，您可以玩游戏Andtell。

在更复杂的游戏中，一些“核心”力学可能太“标准”来“冒险”本身，但你仍然需要核心机制实施的托架是多么有趣的其他力学。您可能会选择使用SimplerThroWay实现，如几行输入处理代码和Unity的CharetController组件。您希望您的核心机制只是谢语，他们不会破坏你在它的顶部层的乐趣。此处的方法是使用资产商店。我之前提到过终极FPS（UFPS）资产，您可以选择在构建FPS游戏时使用，然后继续缩放战斗或更唯一的（但仍然是“核心”的特征首先）。

在机械师内，您的传统软件工程直觉变得符合。我希望花在随后的文章中讨论以统一非常有用的模式，但这里有几个需要考虑：

在Unity的Object-Component Paradigm内工作。如果您为播放器添加了新功能，请将其写为自己的组件。

调整在游戏开发中尤为重要;代表alechanic的有趣作品作为可配置的，可序列化数据将被输入到组件的输入将帮助您播放和迭代。

不要害羞地远离使用普通数据对象来代表与之合作的核心概念。例如，健康，弹药信息或供电。如果您希望它在编辑器中传递（或保存到DiskAcross会话），请制作其iserializable。

如果概念的片段不对应于场景中的单个对象，请考虑使用脚本对象来完成作业。脚本opjectsIntroduce许多可能有助于代表您在做的模式。

一旦你的直觉更强烈地代表不同类型的ofdata和抽象，读者的初始评论也成为答案：

容易想到：“好吧，我需要编写DAO或控制器，等等。”但是对于游戏，我迷失了。

除了学习游戏开发中有用的模式和抽象以使开发更加清晰和整洁外，真正的收获还在于在宏观层面上决定要做什么。

在开发机械师时，您应该继续前进到清单上的另一个好信号吗？通常，那是您确信的时候：

传统上，人们经常会说在发展的后期阶段担心抛光。李·佩里（Lee Perry）在他的GDC 2016微型谈话“首先抢眼，随后波兰”中，用这种传统智慧做出了区分。

一定程度的不愉快可能会让您更好地了解自己的技工和感觉。一定量的上光或打蜡也可以帮助您以新的眼光看待您的游戏并激发您继续前进。果汁是另一种形式的花痴。在游戏设计的某些枯燥时刻，添加果汁可能是一种使事情陷入困境的低成本方法。

我希望有冲突的建议能显示出什么时候添加什么才是银弹。而是，就像在传统软件开发中一样，此选择是关于一系列权衡取舍的，这些取舍取决于开发人员，项目以及更多其他方面。

对于某些软件工程师来说，我们经常被引诱为似乎有趣的系统编写代码。有时，我会想到一个游戏，但实际上，我有兴趣实施一个很酷的库存系统，其中游戏中的所有物品都是一件物品。它可能不是核心机制，但可能是我想要构建的东西。

当你没有建造游戏而是建造并系统时，很重要。如果您只是在您的工作中辞职，在您的现金耗尽之前辞职，并且在耗尽现金之前有Ayear的跑道，那么启动一个复杂的库存系统可能是一个不好的想法，你甚至不知道你需要1但是如果您在侧面编程以弯曲游戏开发肌肉，那么就在它。

我不认为我是合格的本身来回答“伊斯塔特如何？”的问题。然而，我希望通过展示给出回答这个问题的矛盾的矛盾片的例子，您将在决定尝试什么时可以调整参数，并且最终会为您工作。

如果你有一个范式取得了成功（特别是我在这里尚不点要的东西），请告诉我！随意伸出推特或直接伸出援手。

这可能是一个重要的外卖，我没有完全隐含的sofar。您认为最独特的机械师可能不会最终在您建立整个游戏时最终呈现。这就是为什么从'塞尔开始'和迭代是如此有用。 ↩

您也可以订阅并留在循环中 - 这意味着很多！