这里抛砖引玉写点引子。欢迎指正和补充~

# 我才刚刚开始，应当如何入门？

开发游戏大体分为三部分，设计游戏玩法，搭建游戏的程序框架、填充游戏的美术素材。而它们将通过游戏引擎被结合在一起。
## 骨架：游戏引擎
### 什么是游戏引擎
游戏开发需要使用一个游戏开发引擎。可以认为是就像你要写作需要使用Word，要作图需要使用Photoshop一样的一个工具集。
以前，游戏开发引擎其实只是一个游戏公司制作多款游戏时所提取的各种可以复用的代码的集合，这样以后开发新作的时候就不用总是从零开始了。
后来形成了专门将这些相关代码整合在一起的公司，直接向社会售卖通用引擎，方便了其他公司甚至个人爱好者直接使用工业级代码而不用自己重造。抽象和复用是人类文明的基石。
现在进行hobby/indie游戏开发，应当直接使用这些现有引擎而非自行编写。除非你的idea已经清晰到自己知道必须从图形API开始搭才能达到想要的效率和便利度，写代码的水平也不在吹哥等人之下，那么请随意。或者你想制作一个现有游戏的MOD，那么你使用的游戏引擎基本上就是这个游戏本身。

### 有哪些引擎，我应该选择哪个
常用的hobby/indie游戏开发引擎有：
- Unity
- Unreal Engine
- GameMaker Studio
- Godot
- RPG Maker
……
等等，等等。具体可参照：https://github.com/mbrukman/awes ... ines-and-frameworks

一般来说，使用游戏引擎需要编写程序的能力。如果之前没有接触过也不用担心，首先有类似蓝图之类机制可以减少编码，其次贴吧十岁的小学生，十几岁的初中女孩都能学会的东西，你没有理由学不会。使用游戏引擎时所需的编码能力主要是描述游戏逻辑、游戏机制的运行，涉及更多计算机知识的相关模块，游戏引擎早已提供给你并且封装好给你调用了，因此但凡有比较清晰的逻辑思考能力，这种程度的顶层逻辑式编码应该不在话下。

至于应该选择哪个引擎呢？
个人的建议是，如果你是作为业余爱好进行开发，不排除未来可能Release在平台上发售，同时也不排斥编程，那么直接选择Unity是毫无问题的。从indie到3A，基本上你能想到的机制它都能轻松实现，尤其是社区非常发达，想要什么资源都能找到，对接进去极为便利。Unity的Personal版本对年收入10万美元以下的公司是免费的，当然会有一些限制在其中。如果未来你成为了更高阶的开发者，可以考虑花钱订阅Unity，当然价格还是比较不菲的。选择Unity当然也有一个明显的好处，就是未来转型游戏程序员和找工作也会有点作用。大量商业公司尤其手游公司是使用Unity加魔改进行开发的。

如果你想要一个完全免费，并且对标Unity的引擎，那么Godot就闪亮登场了。https://godotengine.org/
这是一个比较年轻的引擎，但这些年影响力已经迅速普及开了。它开源，跨平台，而且最重要的是免费，功能同样强大，相比Unity更加轻量和易用。当然社区积累或许还不如Unity，但凭借经验，许多领域的商业软件和免费软件总是能形成阵营，免费的东西一定能吸引很多人来完善和改进，现在已经不错，未来也更是可期。

商业引擎还可以选择Unreal Engine，拥有强大的性能和图形引擎，并且蓝图提供了不用编程的可能；Game Maker Studio, 制作入门门槛极低，十分适合新手，等等。无论选择哪个引擎，最关键的事情是开始做游戏——之前提到过：Celeste原型是用PICO-8 Lua写的，废都物语是RPG Maker做的，Dota是魔兽的地图，吃鸡是武装突袭的MOD，太吾绘卷则来自Unity中蹩脚的编码。而这些丝毫不影响他们成为经典。反观常立志的制作者经常陷入工具的深渊。一会儿纠结这个效率底下，一会儿纠结那个资源匮乏，MOD太不自由，RPG Maker太low，UE4太难，H5又做不出3A——最重要的是你到底想做一款怎样的游戏？这个游戏为什么好玩？它有什么独到之处？只要把这些问题想清楚并坚持下去，相信你无论在什么引擎上都有机会能做出旷世之作。

当然，作为一种技术路线本身的选择，可以理解为什么有些人会比较谨慎。不过indie开发者和游戏程序员是两个不同的职业，前者不需要过于担心技术路线的问题，许多游戏开发中的问题一通百通，无论哪个引擎都会遇到，解决方案大同小异，未来想要适应其他引擎只要举一反三，也十分容易。

### 选择引擎之后
选择引擎之后，就可以跟随一个入门教程进行学习了。Unity的中文教程方面我不太熟悉，英文的话可以推荐一个：
https://www.udemy.com/course/unitycourse/
Ben Tristem的这个教程可能是最适合入门Unity的教程之一了，每一个例子都很经典，手把手教导循序渐进。可惜是收费的。
Unity同时是有官方教程以及文档的，可以根据自己的情况选择学习：https://learn.unity.com/
这里还有一些其他推荐：https://medium.com/hackr-io/lear ... inners-5119542e7af0

如果你已经完成了这些教程，就可以着手开始自己的游戏了。其中你肯定会遇到各种各样的问题，比如角色如何寻路？如何判定我角色的挥砍？如何做UI？如何做格斗游戏指令输入？如何做战棋游戏的战场？你遇到的问题，别人有极大概率已经遇到过并解决了，甚至可能给出了详细的教程，这也是社区够大带来的好处。下面你要做的就是遇到问题->思考方案->简单尝试->搜索网络->学习内容->尝试解决的循环，最终一定能探索出满意的方案。

## 血肉：美术素材
游戏引擎为你提供游戏运转的骨架，然而有血有肉的美术、模型、动画等等同样需要自己填充进去。因此你可能需要一些美术创作的功底。同时也需要其他工具支持你进行美术素材的创作。你的风格最好与游戏本身的设计相吻合，并且能反应你对游戏美术的独到见解。当然，你也可以选择做DreamQuest作者那样的灵魂画师，或是交给另外的小伙伴，或者外包公司去解决。
## 灵魂：游戏设计
骨架和血肉并不能真正塑造一个完整的游戏，游戏的灵魂是游戏设计。游戏的设计应当足够有趣好玩，并且能够反应你自己的个性，理念，甚至哲学。因此做游戏最关键的是你知道自己想做什么游戏。在此基础上快速塑造原型验证它好不好玩，并进一步完善它的一个关卡或场景到成品级别，之后制作更多的关卡和内容，并最终Release。

# 有什么其他资料可以参考的吗？
可以先参考几个路线图(仅做大体顺序和依赖参考，别真一个个学）：
- 一个简单的成为GameDev的路线图：
https://github.com/utilForever/game-developer-roadmap
- 游戏程序员的学习之路 by miloyip:
https://miloyip.github.io/game-p ... rogrammer-zh-cn.pdf
- 游戏开发相关工具、资源清单：
https://github.com/Kavex/GameDev-Resources
- 另一个清单：
https://github.com/ellisonleao/magictools
- 中文版清单：
https://indienova.com/sp/gameDevResource
- 顺便一提，一个清单的清单（Meta清单）
https://github.com/bayandin/awesome-awesomeness

如果是指卡通化风格渲染这块最强基本要数ARC,可以找他们的图形渲染方面的分享,之前几个帖子也有人发,另外也可以看看崩坏3的技术分享

定义材质需要的还是美术经验。成品游戏里大部分东西也不是实时渲染的，或许可以参考一下Blender的Anime Style相关教程。

顺便楼上说的GG渲染我帮补充一下吧，之前发在别的楼：

4gamer的专栏：西川善司の「試験に出るゲームグラフィックス」
※日文注意
https://www.4gamer.net/words/006/W00633/

讲GG渲染部分的中文翻译：
【翻译】西川善司「实验做出的游戏图形」「GUILTY GEAR Xrd -SIGN-」中实现的「纯卡通动画的实时3D图形」的秘密，前篇（1）
https://www.cnblogs.com/TracePlus/p/4205798.html
【翻译】西川善司「实验做出的游戏图形」「GUILTY GEAR Xrd -SIGN-」中实现的「纯卡通动画的实时3D图形」的秘密，前篇（2）
https://www.cnblogs.com/TracePlus/p/4205834.html

有没有介绍DEFCON游玩算法和方式的文章？在群里聊天时候突然想到肖战这事可以提炼出来，然后参考一些DEFCON和其他游戏的玩法来做一个不一样的题材的游戏

所以不单是技术的问题，想好看必须得美术调吗？我之前想如果在3D还原画家绘画的时候用到的特效是不是就行，看来没这么简单

DEFCON是不是那个核战争游戏……这游戏没啥特别的算法吧，Unity就能克隆。
要说就是判断拦截**的时候把所有对象编入KD-Tree搜近邻的复杂度低一些，这里有个教程：
https://www.youtube.com/watch?v=6rDlfYC4HxM
世界地图方面，这个我一开始想做类P社游戏的时候是用SVG地图+Adaptive的Voronoi地块映射，不过后来没继续做。这里有个Kit看起来很不错
World Map Strategy Kit (WMSK)
https://assetstore.unity.com/pac ... -strategy-kit-55121

为什么要提醒我在摸鱼……

我用的emuera，好处是不用考虑美术资源+有不少开源作品可以直接扒代码，比较适合既不想搞美术又不懂编程的人，坏处是适应作品类型的范围太小+成品受众范围也太小，可以拿来练手+自HIGH，真想往职业的路子上走肯定还是要转工具的

话说一直很好奇 如果自己做了个独立游戏在泥潭发个帖宣传一下要不要交保护费（原本真的了再私聊版主问 不过有这贴就借楼问一下）

这种事还是私聊泥狗吧，我个人觉得：
- 首先，发在这个楼里肯定没问题，宣传也好demo也好。
如果发主题帖：
- 纯粹免费一毛钱氪金元素也没有的游戏一般没问题。
- 如果是多年的坛友应该问题不大，那种新注册的或者马甲号戏服不太好。
- 给坛友发码的可能没事，至少隔壁NGA没事。
- 卖惨够到位，帖子写得好看有意义应该也行。
- 特别精品的游戏契合游戏区风格的，应该也可以一定程度看做游戏推荐帖。
- 啥也没有的推广，还是有金主的组，可能会被当广告哥处理吧……

我听说游戏有些特别机制，说是制作组参考了一些现实情况，然而我从来没玩过，而且我最早设想的时候首先想到的是paper,plz

不过我没空真搞这些的，我自己游戏都玩不过来

-- 来自 能看大图的 Stage1官方 iOS客户端

独立游戏通常就不用了，毕竟大家都是没几个钱的幸苦人

你不会是考虑做侦探类的avg吧

-- 来自 能手机投票的 Stage1官方 iOS客户端

反复入门了两年unity和C#，屁都没做出来，痛定思痛决定能用插件绝不多写一行代码。
另外给大家推荐一个美术资源网，有各种老游戏的图片素材（图集）资源,可做练手之用
https://www.spriters-resource.com

明白了，感谢回复

-- 来自 有消息提醒的 Stage1官方 iOS客户端

233不出意外应该会是

-- 来自 有消息提醒的 Stage1官方 iOS客户端

玩游戏多更容易对游戏设计产生敬畏，看着自己设计的垃圾关卡深感惭愧

我觉Billboard+不同视角的Sprite切换应该能实现。空轨的2D人物是能cast shadow的，比如艾丝蒂尔的shadow是有双马尾的，要么有建模，要么是顺便把shadow和动态也画了一遍并根据方向transform。异度装甲应该简单很多。
关键还是把各个方向的Sprite画好，这东西不是简单用程序就能实现的。看提取的空轨的Sprite资源集，可以用海量来形容。
https://www.spriters-resource.co ... thesky/sheet/82219/

Billboard就是把那个纸片硬弄成永远对着镜头的角度，不能解决插进3d模型的问题。

之前学过点java和c，不排斥编程，是不是直接unity上手就完事儿了。

-- 来自 有消息提醒的 Stage1官方 Android客户端

那角色的碰撞体大小根据倾斜角度取，防止他穿墙这样？

那角色远离屏幕那块就明显空出来一块。我见过在unity前的同人游戏甚至能下水，水面刚好没过2d纸片一点点，不说难不难，肯定能实现。

当然这个问题也许太难了

空出来是有什么问题呢？不如说就是要故意空出来的

youtu.be/B_pqcnxNuZQ
如果不空出来，强行将角色渲染延后，会发现角色像壁画一样贴在墙上

现在2.5D基本都是斜着的呀


看你的说法好像很麻烦一样，进Unity里摆一摆不就出来了吗

为什么以前的人又不空呢？看到以前有过这样的游戏，有人想做成这样也是很正常吧？总之就是2D人物，3D建筑和地形。如果是像上面这样2D立起来的就该考虑做出立体贺卡那样，不是我想要的效果。

呜哇好怀念，这个游戏小时候玩过，但是看不懂日语就放弃了
还记得有一个2.5d动作游戏特别喜欢，名字忘了，是1p女主那双环近战，2p女主拿魔杖远程，手感爽，敌人死掉爆水晶也爽……

话说我们讨论这个问题，你应该清楚的，这个问题的起因在于摄像机观察方向
你发的那张图里，摄像机向下观察，与地面夹角较大，那么角色面片也要倾斜才能在视觉上被玩家所接受
所以才要想办法规避掉面片穿模的问题
而解决办法一众同类游戏开发者都有给出，搜2.5d game camera就有很多
也会出现你所说的：人与障碍物之间有空隙

你拿来反驳的这个游戏，摄像机观察方向，跟地面接近于平行，这跟你最初提问发的那张图性质可就不同了
用来充当玩家角色的面片几乎垂直于地面，角色甚至无需倾斜，视觉上玩家就可以接受
并且自然直接就可以贴上墙面，亲密接触


那么现在你的问题是否变成了，你想要摄像机是俯视，又要像28楼的这个游戏一样角色能贴上墙？
这个与你最开始所问的可以说是两个不同的问题，你有责任说清楚

否则你的回复会看起来像为了反驳而强行反驳

当然你也可以说还不够近，要么你装上空轨试试，空轨能转镜头角度，能撞街灯，无法作弊吧？反正我不会去买个来截的。
总之不要逃避问题，不说人行不行了，就说unity不行吧。

好了这个问题我放弃，总之这图能省下大家的时间了吧？

尽量不要和这个mes搭话，这是那种无法讨论问题的人。你看他之前的帖子和回帖就知道了。

拜托看看3d场景，如果角度真这么平，怎么会在屋顶以上？红箭头看不出指的什么，但你可以试着解释为什么人没陷入这么近的桌子。总之算了，你以为我来找“讨论”吗？我来找答案，反正你们继续，再这种回法我也不管。

逛个gamedev楼都能往黑名单多塞一个人真的服了

—— 来自 OnePlus GM1910, Android 10上的S1Next-鹅版v2.2.2

>>拜托看看3d场景，如果角度真这么平，怎么会在屋顶以上？
这个是什么意思？我的回答里哪里有说角度平，另外屋顶以上又是什么？
我们原本不是在讨论你说的缝隙的问题吗

嗨呀你发现我故意没说的指向椅子的红箭头彩蛋啦
这个是我截图的副产物，故意留给人指出的
我当时一看也是没想好怎么实现的，所以留出来
这种细节的实现方法有人一起来讨论钻研才有意思

ggx那个渲染技术有针对他们团队历史的特殊原因。作为开发思路提点一下还不错，真的不建议实际应用。对美术人员的2d素养和要求很高，而且像掰法线那种模式也是堆工作量堆出来的

— from Google Pixel 3, Android 10 ofS1 Next Goosev2.2.2

你们怎么又和他吵起来了，他连billboard shader都不一定知道怎么写

原来如此呀，将与椅子接触的地方隐去来做视觉欺骗
这个trick整的不错

贴图包看漏了，没有下

非科班，尝试过几次系统学习cs，都因为个人执行力原因没能坚持学深，总想着“这个东西在我想做的游戏里好像用不到”就学不下去了。
但因为本身就是策划，平时进行配置时会有意去了解一下对应的代码实现，时间长了也渐渐能读懂gameplay相关的大部分代码了（虽然读得比较慢），对角色属性变化流程、数据驱动的buff机制、技能逻辑、关卡控制、AI的实现都有了大概的了解。
感觉下来好像gameplay这块并不需要什么进阶的编程知识也能勉强挑战一下？会选用适用的数据结构，会写条件判断、流程控制，了解一些基本的算法，会运用委托反射，好像就已经可以开始尝试游戏开发了？
其实我自己已经开始尝试了，准备做个刷子游戏兼武侠小说生成器（大概有点太吾绘卷×流放之路的意思），目前觉得摸索起来比较吃力的反而是gameplay之外的部分，比如Editor的开发、配置数据解析等。

那么想了解一下，对于一个只会写if else 和 循环 的独立游戏开发者，以“做出一个可玩游戏”为目标的话，最必须补充的专业知识有哪些？
（我现在就隐约感觉gc、线程啥的好像很重要，这些似乎就涉及到内存管理/计算机原理相关的知识了

另外，如果想找同伴开发的话，一般都是在什么平台呢？
我希望我一个人把基础demo做出来后能扩张成一个小团队去完成整个作品，但因为并不想刻意为了迎合玩家或市场去做一些设计上的改动，所以很难指望获得什么商业回报，也就是说很可能只能找愿意为爱发电的同好了。
indienova和奶牛关都看了一下，似乎活跃人数都并不多

一般来说都会稍微补一下图形学。不过你如果要做太吾这种UI-heavy的2D游戏倒也不用。procedural generation的成分需要一些基础的算法和数据结构，不方便补的话至少对语言本身、库、API这些更熟悉一些，读一些已有的自动生成内容的项目可能有帮助。线程和GC可以暂时不用考虑，现在通用游戏引擎的主体在CPU端多是单线程的，涉及物理、碰撞、大规模排序和数学计算之类需要多核/多线程的情况，你调用的库内部自然有相关的多核和SIMD优化，本身是透明的。毕竟很多P社游戏都没优化的东西你也可以先别管。

感谢大佬
图形学一般除了处理模型特效相关的表现外还有哪些应用场景吗？

-- 来自 能看大图的 Stage1官方 iOS客户端

请问2D平台潜入类游戏有推荐的吗，之前玩过忍者之印，结果自己做demo关卡的时候感觉怎么做怎么无聊，想先抄点现成的学习一下

This War of Mine也算是个剖面潜入游戏吧；有个老游戏阿比逃亡记，算是解谜向的；Katana ZERO这种不知算不算。

gunpoint, Ronin, deadbolt

请教一下2D平台跳跃里的一些编码思路，用的是godot
因为我想做一些比较复杂的跳跃机制（比如贴墙滑行，空中冲刺等等），所以需要在_process()(类似于Unity的Update()?)里面做状态更新，现在参考网上一些教程，基本思路是：
用全局变量和计时器来储存角色状态（能否跳跃，冲刺时间等）
获取用户的实际轴向输入（八向）储存为一个2维向量，然后将其归一化
更新角色的状态，计算出实际的标量速度
将标量速度乘轴向输入向量，作为角色的最终velocity，调用对应的函数进行移动

现在主要有几个疑问：
1. 更新角色状态是应该都写在_process()里，还是封装成不同的函数，在_process()里逐个调用？如果封装为函数的话会不会因为调用的问题导致运行效率低
2. 是否应该将水平和垂直方向的输入分开存储？例如我想实现在空中按住↓时加速落地
3. 基本思路有什么可以优化的地方吗？

先谢过各位大佬了

最近在渲染上碰到一些问题，不知道是否有人了解在unity引擎里，要把使用shadergraph制作的shader修改成默认builtin渲染管线可用，有什么比较简便的方式吗