游戏开发的过程大致是怎么样的？

JamesB · 发表于 2021-11-17 10:22

我手里有好几套游戏源码，都是基本从零开始自己写完的，而且现在还有两个游戏在手上运营着，感觉自己有发言权吧。

我说的不是实现啊，如果你想知道游戏人物是怎么走的，请开另外一个游戏实现（编码）的新题目吧，我也能说得清楚。我说的是游戏开发从零到后期运营的过程步骤。

一般来说开发游戏的初衷各不一样，有些是觉得好玩，有些是为了赚钱，有些是为了学习等等，但是如果你想把游戏做出来，并且有人玩，那么应该逃不脱我接下来说的这些吧？

首先确定用户群。这个应该是最容易忽视的。是硬核还是休闲，是单机还是联网等等，这一步简单，但是非常重要，非常重要，非常重要，就像之前我第一个创业失败的老大说的，一开始方向错了，之后再怎么努力正确都是白搭。

然后确定核心玩法。核心玩法顾名思义就是用户操作与游戏反馈最多的循环子系统，其他的各个子系统都是围绕这个系统来的。单机的核心玩法是重头，比如跑酷，核心玩法就是跳、闪、吃，并且坚持越久越好，而其他的角色培养，增加速度，各种道具等等就是辅助系统，是小系统。而一般的网游则不同，辅助系统极为庞大，什么宠物培养、英雄培养、活动、竞技、公会等等很复杂，但也是说围绕那个核心去的。核心玩法不确定之前无法进行下一步。你可以用沙盘，纸片，画板等等实体物品进行研究，这个核心玩法是否能够适合你心目中的那个游戏。

确定核心玩法之后，核心玩法所涉及到任何数据，就可以先设计子系统了。提前说一下，如果游戏后续开发过程中需要扩展，其实就是增加核心玩法的数据，并且添加对这个数据进行更改的子系统。

大部分游戏到此时就必须进入实现的过程了，所谓的出demo的时候了，程序员些代码，策划写案子，美术定下美术风格。在这一步，没有先后，各个单位最好独立，有一个人负责统领即可，这个人最好是策划老大。程序实现可以用黑白块，美术直接ps即可，千万千万不能乱开集体会，一定不能乱炖，不然大家会吵起来，因为任何demo都是缺陷无数的，而任何人都能够从中找到问题，最坏的结果往往是程序挑美术和策划的问题，策划挑美术和程序的问题，美术则挑程序和策划的问题。。。无数个项目死于demo的无休止争吵和修改中。咱就省省吧，因为这个过程中所犯下的任何错误，bug，界面问题，策划问题都可以在后面解决。甚至着整个核心和demo都会更改甚至丢弃。

一段时间过后，大概一周到15天，也就是程序和美术基本完成自己的demo部分，然后简单凑到一起，能跑的小人，可以转动的方块，可以挥动的木板等等，这个demo就好了，此时就可以开会了，也必须开会。说要确定的是，这个demo值不值得继续，如何继续，如何更好的继续下去，这个需要有详细会议记录，美术需要做什么，程序能否实现，策划需要增加些什么系统。记录、分类、整理，必须弄好，这一步死的可能性为：这个核心玩法不值得做下去。曾经做过一个游戏，核心玩法demo出来直接就被集体投票废掉了。

那么抄袭的那些游戏需要这个探索过程么？我觉得应该省掉了很多事情，不需要前期的讨论、探索和不确定性，所以大多数开发团队就是抄袭，用一个确定的样板省掉了时间，迎来了团队的和谐，大家在争论的时候，只要一个人说“xxx游戏怎么做的？”就能停止一切讨论，埋头干活去了。

第一版demo为基础版本，就可以做迭代了，大型游戏一般是一个月一个版本，小游戏就快很多，不过这个都取决于程序的开发速度，有的游戏快的一周一个版本，有的半年憋不出来，毕竟最后还是运行在设备上的软件，不是策划案和ps里面。我感觉这个时候进度还是策划老大统领是程序和美术来把握，每个版本的内容需要固定下来，而不是随便更改，多的东西可以移到下一个版本，不要太赶。这个过程相对是比较愉快的，只要有工资发，大家还都相安无事，除了大的人事变动以外，项目基本不会死。

每次循环迭代的最后一个环节都是简单的测试，不能过度测试，有bug只要不妨碍正常演示即可，如果组合操作会引起，就不做那个操作，至于为什么不要过度测试，是因为在上线见玩家（内测、公测、xx测试）之前，汇集成所有的子系统，每个子系统耦合到其他子系统之后，bug会井喷，而且即便每个子系统内部完成了测试，确定无误，集成之后也会加入新的bug。bug井喷期如果没有管理好，没有经验，大家可能又相互扯皮，说程序就是渣渣，说策划老是该需求云云，其实很正常的系统集成产生bug的过程，很多项目都死于无知。

做完n次迭代版本之后，差不多要见玩家了，如果是手游，那么接入各个平台sdk少不了，如果项目有deadline的话，一定要给出足够的时间来接入，这个不是看电影，买张票就进去了，里面的坑挺多的。

如果你有足够的人手，宣传推广，预热啥的有人做，这个时候可以并行地处理很多事情，去迎接玩家，如果只有几个人，那就慢慢来吧。

至于推广，预热什么的，算然也算游戏开发规程，而且是很重要的过程，所谓“资本主义惊心动魄的最后一跳”，但是我不是很专业，而且在我看来目前这个供大于求的市场情况来看，最后就是你有多少钱，就能有多少人来。最后要算推广费用的人头数与ARPU值之间的差值，竞争相当惨烈，毫无激情、兴趣、方法可言。这个过程死的游戏最多了，因为玩家不待见，那就没辙了。其实每个游戏都会有玩家，只是找到他们的时间、金钱成本是多少罢。

游戏上线了，后面其实也是前面迭代过程的翻版，只是玩家数据加入到了决策中，玩家的反馈也影响到了游戏的改进过程中。当然有时候是玩家付费率不高，开发组做出一堆决策加大营收的问题，也不属于本题的范围了吧？

噼里啪啦说了这么多，不知道有没有符合题主的问题。多说几句，我看了很多关于游戏开发的流程的相关问题和回答，也包括本题其他回答，虽然游戏是软件，它符合软件工程的大多数流程，但是绝对是有大量的不一样的过程在里面的。

首先一点就是需求的过程很短，而且不是最主要的驱动。很多传统软件，比如外包，大型企业软件等等都有很重的用户需求收集过程，而游戏则是用快速（原型）迭代方法，而且美术在其中的作用绝对重要得超过你的想象，游戏中可以为一个美术需求来改动整个策划案，在其他软件基本不可能。

其次是没法使用测试驱动整个项目。传统软件可以先写测试用例后写实现，游戏基本不可能，因为游戏中，状态大大多于一般软件，每个像素都可以是一个不同的状态，并且相互影响，基本上无法先想好怎么玩（测试），再去实现。这样导致一句话：“游戏上线才是开始”。因为bug会伴随游戏一生。

又多说了两句，也是将游戏开发的特殊性说一下，觉得有用的话，赞一下吧。

Zephus · 发表于 2021-11-17 10:31

我手里有好几套游戏源码，都是基本从零开始自己写完的，而且现在还有两个游戏在手上运营着，感觉自己有发言权吧。

我说的不是实现啊，如果你想知道游戏人物是怎么走的，请开另外一个游戏实现（编码）的新题目吧，我也能说得清楚。我说的是游戏开发从零到后期运营的过程步骤。

一般来说开发游戏的初衷各不一样，有些是觉得好玩，有些是为了赚钱，有些是为了学习等等，但是如果你想把游戏做出来，并且有人玩，那么应该逃不脱我接下来说的这些吧？

首先确定用户群。这个应该是最容易忽视的。是硬核还是休闲，是单机还是联网等等，这一步简单，但是非常重要，非常重要，非常重要，就像之前我第一个创业失败的老大说的，一开始方向错了，之后再怎么努力正确都是白搭。

然后确定核心玩法。核心玩法顾名思义就是用户操作与游戏反馈最多的循环子系统，其他的各个子系统都是围绕这个系统来的。单机的核心玩法是重头，比如跑酷，核心玩法就是跳、闪、吃，并且坚持越久越好，而其他的角色培养，增加速度，各种道具等等就是辅助系统，是小系统。而一般的网游则不同，辅助系统极为庞大，什么宠物培养、英雄培养、活动、竞技、公会等等很复杂，但也是说围绕那个核心去的。核心玩法不确定之前无法进行下一步。你可以用沙盘，纸片，画板等等实体物品进行研究，这个核心玩法是否能够适合你心目中的那个游戏。

确定核心玩法之后，核心玩法所涉及到任何数据，就可以先设计子系统了。提前说一下，如果游戏后续开发过程中需要扩展，其实就是增加核心玩法的数据，并且添加对这个数据进行更改的子系统。

大部分游戏到此时就必须进入实现的过程了，所谓的出demo的时候了，程序员些代码，策划写案子，美术定下美术风格。在这一步，没有先后，各个单位最好独立，有一个人负责统领即可，这个人最好是策划老大。程序实现可以用黑白块，美术直接ps即可，千万千万不能乱开集体会，一定不能乱炖，不然大家会吵起来，因为任何demo都是缺陷无数的，而任何人都能够从中找到问题，最坏的结果往往是程序挑美术和策划的问题，策划挑美术和程序的问题，美术则挑程序和策划的问题。。。无数个项目死于demo的无休止争吵和修改中。咱就省省吧，因为这个过程中所犯下的任何错误，bug，界面问题，策划问题都可以在后面解决。甚至着整个核心和demo都会更改甚至丢弃。

一段时间过后，大概一周到15天，也就是程序和美术基本完成自己的demo部分，然后简单凑到一起，能跑的小人，可以转动的方块，可以挥动的木板等等，这个demo就好了，此时就可以开会了，也必须开会。说要确定的是，这个demo值不值得继续，如何继续，如何更好的继续下去，这个需要有详细会议记录，美术需要做什么，程序能否实现，策划需要增加些什么系统。记录、分类、整理，必须弄好，这一步死的可能性为：这个核心玩法不值得做下去。曾经做过一个游戏，核心玩法demo出来直接就被集体投票废掉了。

那么抄袭的那些游戏需要这个探索过程么？我觉得应该省掉了很多事情，不需要前期的讨论、探索和不确定性，所以大多数开发团队就是抄袭，用一个确定的样板省掉了时间，迎来了团队的和谐，大家在争论的时候，只要一个人说“xxx游戏怎么做的？”就能停止一切讨论，埋头干活去了。

第一版demo为基础版本，就可以做迭代了，大型游戏一般是一个月一个版本，小游戏就快很多，不过这个都取决于程序的开发速度，有的游戏快的一周一个版本，有的半年憋不出来，毕竟最后还是运行在设备上的软件，不是策划案和ps里面。我感觉这个时候进度还是策划老大统领是程序和美术来把握，每个版本的内容需要固定下来，而不是随便更改，多的东西可以移到下一个版本，不要太赶。这个过程相对是比较愉快的，只要有工资发，大家还都相安无事，除了大的人事变动以外，项目基本不会死。

每次循环迭代的最后一个环节都是简单的测试，不能过度测试，有bug只要不妨碍正常演示即可，如果组合操作会引起，就不做那个操作，至于为什么不要过度测试，是因为在上线见玩家（内测、公测、xx测试）之前，汇集成所有的子系统，每个子系统耦合到其他子系统之后，bug会井喷，而且即便每个子系统内部完成了测试，确定无误，集成之后也会加入新的bug。bug井喷期如果没有管理好，没有经验，大家可能又相互扯皮，说程序就是渣渣，说策划老是该需求云云，其实很正常的系统集成产生bug的过程，很多项目都死于无知。

做完n次迭代版本之后，差不多要见玩家了，如果是手游，那么接入各个平台sdk少不了，如果项目有deadline的话，一定要给出足够的时间来接入，这个不是看电影，买张票就进去了，里面的坑挺多的。

如果你有足够的人手，宣传推广，预热啥的有人做，这个时候可以并行地处理很多事情，去迎接玩家，如果只有几个人，那就慢慢来吧。

至于推广，预热什么的，算然也算游戏开发规程，而且是很重要的过程，所谓“资本主义惊心动魄的最后一跳”，但是我不是很专业，而且在我看来目前这个供大于求的市场情况来看，最后就是你有多少钱，就能有多少人来。最后要算推广费用的人头数与ARPU值之间的差值，竞争相当惨烈，毫无激情、兴趣、方法可言。这个过程死的游戏最多了，因为玩家不待见，那就没辙了。其实每个游戏都会有玩家，只是找到他们的时间、金钱成本是多少罢。

游戏上线了，后面其实也是前面迭代过程的翻版，只是玩家数据加入到了决策中，玩家的反馈也影响到了游戏的改进过程中。当然有时候是玩家付费率不高，开发组做出一堆决策加大营收的问题，也不属于本题的范围了吧？

噼里啪啦说了这么多，不知道有没有符合题主的问题。多说几句，我看了很多关于游戏开发的流程的相关问题和回答，也包括本题其他回答，虽然游戏是软件，它符合软件工程的大多数流程，但是绝对是有大量的不一样的过程在里面的。

首先一点就是需求的过程很短，而且不是最主要的驱动。很多传统软件，比如外包，大型企业软件等等都有很重的用户需求收集过程，而游戏则是用快速（原型）迭代方法，而且美术在其中的作用绝对重要得超过你的想象，游戏中可以为一个美术需求来改动整个策划案，在其他软件基本不可能。

其次是没法使用测试驱动整个项目。传统软件可以先写测试用例后写实现，游戏基本不可能，因为游戏中，状态大大多于一般软件，每个像素都可以是一个不同的状态，并且相互影响，基本上无法先想好怎么玩（测试），再去实现。这样导致一句话：“游戏上线才是开始”。因为bug会伴随游戏一生。

又多说了两句，也是将游戏开发的特殊性说一下，觉得有用的话，赞一下吧。

mypro334 · 发表于 2021-11-17 10:34

其实，游戏如何制作应该也能想象出来。接下来由浅入深解释一下。

比如2048小游戏，和大部分软件是没有区别的，使用非游戏引擎也能做的出来。关键技术只有两点：
1、根据数据，显示（专业名词叫做渲染）对应数字的图片。
2、需要移动位置时，按固定帧率（比如每秒60次）刷新图片位置，做出动画效果。
只要有这两点原理，那么2D动画也一样可以实现：

如上图，上图中人物位置没有变化，只是在不断变换图片而已，那么只需要在2048游戏的基础上加一条：
3、显示人物图片，每隔10帧换一个图片，循环反复，形成动画效果。
那么想让人物走起来就是小儿科的问题了：
4、用变量控制人物位置，向前移动，同时人物动画一直播放。
到这里都是1+1=2的问题，估计题主更想知道的是：3D人物行走，背后原理是什么？

不好意思，3D游戏的实现原理，一下子从2D游戏产生了质的飞跃。第一个真3D游戏《雷神之锤（QUAKE）》也是多次技术革新的产物（在这之前也有3D游戏，但是基本上是依靠图片的缩放斜切变换、限制摄像机角度伪造出的效果）。
想知道3D游戏历史发展过程，推荐这本书：

做出行走的3D人物之前，要先解决这个问题：
1、如何在屏幕上显示3D的立方体、球体。且能转换到不同角度。
越基础的问题越是复杂，在《雷神之锤》之前，已经有不少3D软件支持类似的显示技术了，但挑战在于——如何在动态展示3D物体时，保持至少30帧的刷新速度。
解决这个问题经历了相当久的时间，因为在二十多年前，需要高深的图形学知识以及深度的编程优化才能实现出最基本的效果。明白了这点，也就明白了为什么第一个算得上真3D的游戏直到1996年才出现。

最基本的问题最困难。对实时性的高要求让3D技术产生了两大分支——实时渲染（用于游戏）和非实时渲染（常见用于影视）。
在解决了最基础的问题之后，接下来一系列眼花缭乱的技术，就只是寻常的技术演化罢了：
2、将任意物体，用“顶点”和“贴图”概括，做出3D的外观。
3、表现出光线、阴影。
所谓顶点就是三维空间中的坐标点，贴图就是把图片糊在3D顶点上，就形成了三维空间中的模型。
制作模型依赖于3D软件，而3D软件工具的出现，比3D游戏要早得多。
所以说一个新技术的突破，大的历史环境、技术背景是必须的。
另外3D模型是否能看得过去，十分依赖于光照、阴影是否真实，这又是另外一个大问题了。
3、3D动画是怎么做的？让顶点动起来即可。
既然我们已经拥有了以30帧的速度渲染物体的技术，那么只要让人物模型的三维“顶点”动起来，不就实现走路的动画了吗？
另外再加上物体整体的位移和旋转，实现动画的最基本技术就齐备了。
4、间接移动顶点——骨骼动画技术
基本问题解决之后，剩下的不过就是进一步完善罢了。在QUAKE的时代，人物只是非常僵硬的抬抬手、动动脚，远远达不到逼真的要求。如何才能做出具有真实感的动作呢？

问题的关键是：如果直接移动顶点，美术设计师几乎不可能做出真实的动画，因为顶点之间本质上是有关联的，如果用手一个一个拖，其工作量要大于用橡皮泥做动画。
所以后来出现了一个间接技术——给模型绑上骨骼，一个骨骼控制一部分顶点。这样一来，美术设计师只需要让“骨架”真实的动起来，模型也自然会跟上，形成细腻真实的动作。
5、将以上所有技术结合在一起——游戏引擎
看了以上讲解，你一定会和我一样，发现“让3D人物行走”其实是一系列技术的结合。所以外行人很难凭空想象出来。
甚至对于内行人来说，完全理解整个流程也太复杂了。因此后来逐渐出现了“游戏引擎”的概念。
“游戏引擎”把游戏开发必要的的模块和工具整合起来（但不包含专业的美术制作工具），可以让游戏开发者专注到游戏本身，不再需要关注原理问题，因为渲染原理已经形成固定模式了。
有了“游戏引擎”之后，从外行人的角度看，游戏开发工具就只剩两大块了：
1、3DMax、Maya等三维建模和动画软件。由专业的美术人员使用，制作出原始模型和动画素材。
2、技术人员和游戏设计师，一起在游戏引擎中整合资源、编写游戏逻辑，形成完整的游戏。

看了以上解释，题主应该能大致想象出，3D游戏是如何实现的了吧？

Ilingis · 发表于 2021-11-17 10:38

《幽灵玩具屋》（Daunting Dollhouse）是我、陈潮和两位外国同学在 USC 游戏设计专业 Design for Interactive Media 课程上设计的最终项目，课程结束后，我们又对这个游戏的系统设计进行回顾思考，发现了很多深层的系统设计问题。
1. 游戏玩法与设计思路
《幽灵玩具屋》是一款双人同屏竞技游戏，一个玩家控制幽灵，一个玩家控制幽灵猎手，他们附身在六个 NPC 中的两个。玩家要试图伪装成 NPC 以隐藏自己。每局游戏时长约一分钟。
幽灵玩家可以在房间中闹鬼（HAUNT）三次以获得胜利，同时可以转换控制(SWITCH)同一房间内的另一个 NPC 角色。猎手玩家要抓住幽灵；幽灵闹鬼时会暴露自己所在的房间，以给猎手线索；猎手也可以用听（LISTEN）技能，以查看幽灵玩家是否和自己在同一房间。
课程的要求是设计 emergent narrative，涌现性叙事（我们最后放弃了对叙事设计的追求，做成了纯 emergent 游戏）。我们最终的想法来自于两方面的结合：
（1）有具体角色在房间中移动的杀人游戏：考虑到杀人游戏的 emergence，以及其潜在的叙事设定，如果有具体角色，可能会创造出剧情；
（2）SpyParty - A Subtle Game About Human Behavior：非常受期待的一款独立游戏，玩家扮演间谍执行任务，或扮演狙击手从 NPC 中找出间谍。设计者 Chris Hecker 希望设计一款有很深的策略深度、以人和人心理对抗为概念的游戏。

2. 纸面原型设计
基于以上的思路，我们设计了三个房间五个 NPC 角色在其中移动的核心机制，以及确定了幽灵和猎手这两个玩家身份；这些被沿用至最终版本。
有了这些，我们就可以开始测试游戏，并逐步增减其他机制。多次测试的主要精力用在平衡游戏上。这里的平衡并不是数值的调整，而是机制的增减。我们往往在尝试用不同小改动来平衡一个问题无效后，会发现更深层的问题，因此退一步思考，做出更大的改动。
（1）设计与沟通方法
因为设计的是纸面原型，任何问题都可以快速修改。平均每个小时都会改规则重新测试 1-2 次。到后期规则相对稳定时，找新人测试的机会增多。
我们每天花大量时间开会。在这样密集修改规则的阶段，长时间开会非常适用，因为人进入状态需要时间；短时间的会议，刚刚进入状态就打断了，下次又要重来。
这个阶段的设计讨论，和头脑风暴阶段相似，但有不同。相似在于：这个阶段由于游戏框架很不成熟，会有大量不同方向的想法，因而需要像头脑风暴一样密集思考，并鼓励不同的想法，思考各种可能性；不同在于：这个阶段的每个想法、每个改动都是需要测试来验证的，成本远比头脑风暴中提出一个想法要高，加上测试后出现的问题，这些都需要详尽的分析解构，而不能沉浸于做但不反思。
在这个阶段，每个人提出的想法，其他人要尽可能地去深入理解和分析，发现它的优、缺点，大家从他人的想法上汲取灵感，比如一个想法如果有缺点，那有没有一种好的方式解决这个缺点但又不导致更大的问题？如果一个想法有优点，那么有没有其他方案也能实现这一优点而带来更小的隐患？每个人的思路不同，分析清楚别人提出一个主意时的思路，往往能帮助自己用不同的视角来思考和提出创意。

使用 App 查看完整内容目前，该付费内容的完整版仅支持在 App 中查看
App 内查看

jquave · 发表于 2021-11-17 10:42

对这个问题感兴趣的人挺多，这里做一个百科式的简单说明。
从典型的人员分工来看，大体有四大部分：设计，美术实现，技术实现，测试。
从开发时间进程上看，大致可以分为预研和立项，从立项到alpha版，从alpha版到正式发布，运营和维护。
这个时间顺序是以典型的单机产品为例。网游产品后期可能会不间断开发，后期还会进入第二轮开发、第三轮开发……可以看成是以上流程在持续循环。
1、预备阶段

游戏一开始只是一个创意或想法，如果把具体用图片和文字展现出来，就形成了一个最初的概念设计，概念设计最重视的是创意、玩法和美术风格。找到一个很合适的独立游戏概念文档：
游戏概念设计文档---《hunter》（追猎者） | indienova 独立游戏（现在说到概念设计，狭义上指的是视觉方面的概念设计，其实广义来看，还应当包含游戏框架和大体玩法、游戏大体流程。）
在这个阶段，美术特别是原画人员的工作是最重要的，要不断出各种概念草图、原画稿，然后一起讨论、打磨，反复修改到满意的程度。因为美术风格必须紧贴主题、紧贴世界观，所以配色、场景风格、人物造型都需要反复尝试，最终达成满意的结果。

技术工作这时也不应该闲着，对还未完全确定的新项目要尽快进行技术预研，确定几个大的问题：

总之这个阶段开发的工作量还没有完全铺开，而是集中在少数主要负责人手中，明确方向、提前发现主要的障碍是最重要的。
这个阶段中，不仅仅要得到大家满意的原型设计，而且成败的关键是——立项符合市场需求，具有足够数量的潜在消费者。如果市场有潜在问题，则应当根据用户属性修正设计，这点对于任何游戏来说都很关键。
如何得到相对客观的反馈呢？其实测试人员作为玩家的代表，在一开始就可以起到很重大的作用。
2、从正式立项到alpha版

正式立项之后，按项目规模可能需要招兵买马、适当扩大团队，然后进入正式的alpha版开发。
对原创性的游戏来说，从0开始很可能会遇到很多意想不到的问题。在alpha版之前，或者立项之前先做一个demo版来验证可行性也是有必要的。
根据项目计划，所有必不可少、不得不完成的高优先级工作，都要排在alpha版本中。
比如对于《黑暗之魂》这样的动作游戏来说，所有的主角动作、移动和攻击、至少三套武器、盾牌和防具是必须的；UI界面特别是道具系统是必要的；三个以上的关卡和BOSS也是必要的。
内容过于太少的话无法体现出足够的游戏内容，让测试人员无法判断游戏的好坏。
根据实际开发中遇到的问题，alpha版可能会如期完成或者延后。项目可能会因为失败而被延期、要求重制甚至砍掉，如果顺利过关则可以进入下一步。
3、铺量制作阶段

不同公司、不同团队对alpha版之后的版本名称叫法不同。有的叫做beta版，有的公司（比如鹅厂）会分得更细，每一季度定一个版，称为Q2、Q3、Q4……
总之由于游戏产品的特殊性，看似alpha版已经完成了绝大部分功能，实际上，真正工作量较大的部分还在后面。好在alpha版已经确定了绝大部分系统的制作方法，之后的工作主要是铺量了。
“铺量”的工作包括更多的怪物、关卡、场景、道具、BOSS、装备、任务、活动、后续剧情等等，总之要不断填充游戏世界，让玩家体验更丰富，同时要保证所有内容的统一性。
现代游戏对内容丰富度的要求非常高，特别是有一定级别的大作，在最终定版之前要不断完善内容，即便如此玩家有时还会觉得游戏时长不足：）。
除了工作量很大之外，对开发者来说最可怕的事情正发生在鹅厂、supercell、暴雪等规范化的大厂。由于对游戏品质的严格把控，定期检查项目情况时，很可能会整个砍掉项目：
Supercell高管：近10个项目9个是要被砍掉的_游戏狗新闻现在好游戏很多，制作游戏的压力还是蛮大的，特别是对于项目负责人来说。
4、正式发布前后

如果你的游戏足够幸运，会最终迎来正式发布这一天。
如果说铺量阶段最大的工作量在美术那边，那么到这时大部分美术设计师（负责美术宣传的除外）可以稍微松一口气了。
相对的，由于现代游戏大部分都加入了联网功能，上线前最提心吊胆的除了制作人，恐怕要数服务器开发人员了。
“开服后玩家较多，导致服务器崩溃，开发商正在紧急处理”，（无数血淋淋的例子教育我们，写代码要少留一些BUG【狗头】）。其实，决定产品质量的所有工作中，测试是非常关键的一环。

以上就是从时间流程上，结合各部门工作内容来说明“游戏开发的过程大致是怎么样的”。
对于题主想要问的另一个问题：简单的人物行走是如何实现的。可以参考这个回答：
游戏开发的过程大致是怎么样的？

IT圈老男孩1 · 发表于 2021-11-17 10:46

【转】我的Flash 游戏制作流程：

1、某天，由于某种原因，产生冲动，决定要做游戏。
2、设想游戏效果，冲动越发强烈。
3、打开电脑。
4、双击Flash 图标。
5、。。。茫然。
6、开始上网找参考资料。
7、三小时后，发现自己已经通关了二十几个Flash 小游戏。
8、挨个关闭浏览器窗口，发现了最底下的Flash 程序窗口。

9、。。。茫然。
10、饭菜香味飘来，点击最小化，去买午饭。
11、午觉过后，敲醒睡眠了的电脑。
12、发现电脑因为睡眠过久，已经彻底关机。
13、打开电脑。
14、双击Flash 图标。
15、。。。茫然。
16、翻参考书。
17、新建一个文件，命名为“射击小游戏”。
18、点确定。
19、。。。茫然。
20、找水喝。
21、发现了参考书的附带光盘，将其插入光驱。
22、从光盘里找到若干源码，稍加修改将其贴入自己的文件。
23、关闭AS面版。
24、开始绘制游戏图片。
25、新建影片剪辑，在时间轴上拖出50帧空白。
26、从第一帧画起。
27、埋怨没有手写板。
28、感觉主角衣服和裤子的颜色搭配不起来。
29、打开光盘示范文件，用吸管直接吸取衣服和裤子的颜色。
30、感觉不如示范文件画得好看，删去重画。
31、埋怨没有手写板。
32、。。。绘制完第一帧，发现已经过了30分钟。
33、。。。茫然。
34、打开光盘示范文件，剪切主角人物。
35、将程序与动画链接，按Ctrl + Enter。
36、出错。
37、关上播放器，检查程序。
38、觉得跟光盘里的基本一样。
39、按Ctrl + Enter。
40、出错。
41、。。。茫然。
42、删除所有程序，贴入原光盘里的程序。
43、按Ctrl + Enter。
44、出错。
45、打开光盘里的游戏文件，按Ctrl + Enter。
46、正常运行。
47、。。。茫然。
48、又有饭菜香味飘来。
49、点“保存文件”。
50、发现存储路径是在光盘的文件夹里，点“另存文件”。
51、出现“另存文件”对话框。
52、将“射击小游戏”改为“孤胆神枪”。
53、将“孤胆神枪”改为“孤胆神枪1.0 ”。
54、将“孤胆神枪1.0 ”改为“孤胆神枪demo”。
55、将“孤胆神枪demo”改为“射击小游戏 ”。
56、确定。
57、关闭文件。
58、。。。茫然。

kirin77 · 发表于 2021-11-17 10:55

有意思，你为啥会觉得想不出来呢？
其实大部分游戏的逻辑都类似
你需要有一个展示，也就是图形api，将你的图片，模型等资源，渲染到屏幕上去，就是在屏幕上画出来，这是第一条，这也是最基本的功能，没有这个的话，那你只能做点简单的游戏，文字类或者数字类，这个图形api基本上就那么几个，标准的opengl（gl），标准升级版的vulkan（vk），win上的direct3d（d3d），还有苹果平台上的metal，而且这个渲染，一般必需用硬件加速，也就是用gpu来画，一般cpu还搞不定，太慢了，因为都是浮点型计算，所以你的显卡很重要
然后有了图形api之后，你需要做的就是让你的程序代码，能够调用这些api进行渲染，那这个除了这些图形api自身暴露的c（gl，vk）或者c++（d3d和metal）以外，你还可以通过其他语言的ffi来包装并调用这些图形api，这个并不困难，一般完成这事的叫做图形引擎，比如javafx的prism，flutter的skia，有了图形引擎之后，就能把常用的c/c++的api暴露成其他语言的api
然后有了这个之后，你就已经能开发游戏了
但是还缺少一个基本的游戏逻辑，gameloop，也就是游戏自循环系统，你需要拿出一个线程，然后这个线程每隔1/60秒，刷新一下游戏逻辑，然后再根据你游戏的需要，建立模型，然后把这个模型放入这个自循环系统中去，每隔60分之一秒更新一下
然后根据这个gameloop，每隔60分之1秒刷新一下屏幕，这里其实有离屏表面等技巧，但是现在图形引擎基本上屏蔽了这些实现细节，你只要调用他们的api就好了，很容易的，为什么是60分之一秒呢？因为眼睛对于低于60分之一秒的改变，并不敏感，也就是人眼的极限就是一秒放60张图片给他看，他就感觉不到闪烁，除非你的图片变化比较大，如果是动画帧序列的话，以一秒60张图片的方式播放的话，他会感觉到图片上的人物动了起来，这也是基础的动画原理，电影，电视，卡通，动画，都是差不多逻辑
解决了最重要的渲染和动画问题之后，游戏其实已经完成了大部分，剩下的就是输入，这个超级简单，调api就行，然后还有gui控件，就是预先给你画好各种按钮，输入框等控件，那这个也相对简单，最后还有一个网络的问题，如果你想做网游的话，还需要服务器端的知识，尤其是vert.x等，但是没有这个，其实也能做个单机的游戏出来不是？

RedZero9 · 发表于 2021-11-17 10:58

楼上的也太啰嗦了，我就写个最简单的游戏伪代码，会点程序的就知道游戏主逻辑是怎么回事了
while(!isGameEnd) {
UpdateUserInput();       // 处理用户输入
UpdateGameObjectAI();    // 更新游戏里所有游戏对象的逻辑，包括坐标，状态，物理等等
RenderGameObjectOnScreen(); // 把游戏对象画到屏幕上
Wait(someTime);          // 等待些时间，游戏跑60帧就是1秒钟里这个while跑60次。
}

FeastSC · 发表于 2021-11-17 11:04

你们做的游戏，复杂度还是太低了。

APSchmidt · 发表于 2021-11-17 11:12

游戏开发实际上是分阶段的。
1、用别人的画，做出核心玩法。让亲朋好友去体验和反馈
2、增加周边功能。比如注册、登陆、统计、分数、语音、第三方SDK等
3、优化游戏体验。特效、换成自己的画面
4、小范围测试、规模测试等，修改BUG
5、发布游戏
一个人做游戏如果过了第一阶段，后面可以就自己努力或者说服别人加入或者投资，当然也可以自己完全做，只是慢一点。下面这个南宁麻将就是我一个人开发，一个多月。https://fir.im/qiyoumajiang
需要说明的我有10多年的游戏开发经验，也有自己的游戏开发工具，所以自然快点。客户端用lae工具开发，逻辑部分用lua开发，6000多行代码吧。服务器是用libevent写的一个架构，很简单也很实用，也是用lua写的逻辑。包含两大块：游戏逻辑和游戏其他功能（登陆、统计、聊天、语音、更新等），游戏逻辑部分也就3000多行代码，游戏辅助功能也有5000多行吧，openresty nginx写游戏辅助功能，libevent和lua写游戏逻辑服务器。

		自动登录	找回密码
密码			立即注册

游戏开发的过程大致是怎么样的？

本帖子中包含更多资源

本帖子中包含更多资源

本帖子中包含更多资源