在游戏上应用的少，我只知道一个OW，效率也确实超神。unity现在加速转变DOTS，ecs架构在unity上普及是早晚的事。

2D游戏也同样推荐GODOT，免费开源，比业余的引擎专业，IDE集成在编辑器里（个人比较喜欢这种整合的），比专业的引擎轻量。
其次unity吧， 其他的什么love2d，资料实在太少，国内几乎没人用。
我觉得游戏制作人 会一个unity就行了，资料多，学习成本低点，下到手游小游戏，上到新的管线也能适应3A作品。

再加一句ue4什么都好，但做手游实在是不适合

古有NS吉里吉里，今有……忘了，去freem看看，有能输出html的。
但是还是要用一些码控制换行什么的，也不会再简单了。

love2d逻辑也很简单，反正纯2d，不用考虑编译。
以前好像还有人用日本的HSP，但是应该一直不能显示中文。
另外有好像能做PS4 PSV NS游戏的ＤＸライブラリ。

renpy？

godot的luascript有人用过吗？

也许做FC游戏？
github.blog/2018-07-16-how-the-nintendo-entertainment-system-lives-on-in-open-source-game-bytes/

MD游戏
gamasutra.com/blogs/DoctorLudos/20191019/352537/Making_a_SEGA_Mega_Drive__Genesis_game_in_2019.php

还有gameboy游戏
github.com/gbdev/awesome-gbdev

不需要先学十种锤子的用法，然后满世界找钉子。首先你要有个想砸钉子的地方（做游戏的想法），然后用且只用一把锤子好好地把钉子砸进去。
完整砸进一个钉之后，再反思这把锤子有没有不好用的地方，要不要换一把更趁手的，许多技巧举一反三上手新锤也不慢；或者下次还用这个锤子熟能生巧，获得了许多可以把钉子砸得更漂亮的心法。
Done is better than perfect，做工具党容易一直研究工具但是不出活。最关键还是有真正想做的游戏，并坚持下去。
(以上也是自己的教训）

但是如果只有自己全部搞懂，那有的部分就像数学，老师觉得“只是转了个弯”的题，可能自己永远钻不出来。所以先看看成品拆开怎样的，还有别人用这些工具怎么做，我觉得也是正确的。

其实arcaea就是用cocos2dx做的

宝可梦大师也是cocos做的

这话……可能对学生们有用，还不用太深入，看公式就可以了，不用管为什么是这样列。如果真的要做的话只要涉及都该看看，毕竟很多不按直觉的东西，就算不是自己亲自动手做的部分也需要懂，知道那些部分限制在哪里，因为很多确实是不按直觉，不然人人都一打开就会用unity了，何须教程之类。

一个独立游戏制作者最关键的是知道自己要做什么，有没有毅力坚持下去。只要这件事确定下来，可以说事情已经做成了一半。其他完全可以边做边学，需要什么学什么。尤其刚开始的时候工具都不用挑，根据想做的东西稍加选择，投入进去即可，大部分都能举一反三。手边只有RPG Maker？拿来做个RPG毫无问题。只填充内容和逻辑利用现有游戏底子做成MOD？一样能把游戏的想法展现出来。

Celeste原型是用PICO-8 Lua写的，废都物语是RPG Maker做的，Dota是魔兽的地图，吃鸡是武装突袭的MOD，太吾绘卷则来自Unity中蹩脚的编码。而这些丝毫不影响他们成为经典。反观常立志的制作者经常陷入工具的深渊。一会儿纠结这个效率底下，一会儿纠结那个资源匮乏，MOD太不自由，RPG Maker太low，UE4太难，H5又做不出3A——拜托，等那天想做3A的时候再考虑吧。

当然，独立游戏制作者和游戏程序员是完全不同的职业，跟引擎程序员更是八竿子打不着。我默认这里讨论的主体都是前者。后者真的不需要看一个玩家论坛的帖子做决策。如果你讨论的是后者，那你把UE4源码看一遍写个架构解析出书，我也不会拦着你。

没有什么独不独立，什么职位，有的只是兴趣，不管是有多少人，想做什么，都可以讨论，如果你已经默认以“职业”为前提那我也不管那块。

好像有个公开控制部分源码的游戏不太记得是不是celeste，有几千行，老实说我想象不出来，不就是上下左右加几个键吗，各人有各人的做法了，那我至少知道有这回事，并认为不适合自己，然后看有没别的做法。

主要是一般有这个“爱好”的人，都是想做游戏的人，而不是想做程序员接活的人。对独立开发者来说，程序方面主要是原型和机制框架实现，程序外的东西才是工作主体。

像本贴这样的技术讨论当然毫无问题，只是之前注意到很多人陷在大量细节实现之中，而游戏本身甚至还没有可玩原型用来验证，实为本末倒置，因而有感而发提出一些自己的经验教训。以自己要做的游戏为中心而不是追求工具和细节的完美主义，从最小原型着手开始做，需要什么再学习什么也更有效率和成就感。

GameMaker Studio 2
上手指南：https://indienova.com/indie-game-development/gms-2-tutorial-for-starters/引用文章的最后一段：

现实来说，如果实在没人，最好是有美术基础的人自己学会做游戏，就看看有没有了。

想问下这帖里应该有专业的技术大拿，用引擎做游戏内录的过场已经是非常成熟的技术了，那么以后有没有可能用引擎做更高端的类型影片，比如宣传动画啥的

我觉得有点道理，有实力大概都可以去参加game jam啥的，还干嘛对喷……

为了避免变成这样，我提个问题，看有没有人来回答，因为我用不上所以暂时不会管，但如果自己弄懂了大概也发一下。

问题是，看过某blog说，在unity2d里可以设置成一个方块，上下左右分别是不同判定，比如某一面是刺，但是不需要再另外做一个刺的判定形状，那到底要怎么实现？要是别的引擎或工具也行。

用normal判断即可

是可以。看到的时候大概还没碰过，不知怎么想起，然而写着时我也觉得按接触到平面的方向就行，要么坐标也直接能算。但不知道有没记错，如果真的是说是可以“设置”成那样，那大概就是设计和程序分开，设计一直都觉得就是这么回事，如果真的那样，到底是好还是不好呢。又或者真的可以，只是方法比较隐秘。

设计当然要通过程序体现。你想设计这么个四向刺球，那就把这个刺球的所有可能产生的行为定义清楚不就行了。

说起来ps4那个dreams有谁试过了？貌似搞出成品的不少

SFM了解一下

那么想做个模拟经营游戏用什么最快呢？
rpgmaker能做这种类型吗？

—— 来自 Sony G8142, Android 9上的S1Next-鹅版v2.2.0.1

只做2d的话先用gms2实现起来挺方便的，我个人倾向于先提出需求，再想办法实现出来，不用太纠结具体用什么工具。

学技术和提需求相互作用，想要自己做游戏的话后者更重要一些。对技术现实有一些大体上的了解，有助于提出更合理的需求。

当然如果励志做程序员只关心技术，确实要把大部分精力都放在学习掌握技术上。

蔚蓝人物控制的代码确实很长，有很多细节优化，代码在网上公开的。其中一个优化是跳跃落地之前几帧如果按下跳跃键会储存这个命令直到落地执行，防止没落地提前按跳吞掉操作，玩家不知道具体原因只会觉得手感差。

如果不理解为什么需要做这么多优化调节，跟着教程做一个平台跳跃游戏，自然就明白了。比如人物跳起来和落下的加速度，移动的惯性，跳跃时控制方向的速度变化等等。

楼上大佬说过了蔚蓝做了防吞操作的设计的。
现在可能没什么教材教输入缓冲（Input buffering）和土狼时间（Coyote time）那种手感优化了，大概是专业开发者觉得太简单，新入门开发者也没有那种优化经验根本不会想的到，以前读过一个海外blog怎么在gms上优化动作游戏的输入判断，受益匪浅
至于蔚蓝为什么要做输入缓冲和复杂的状态机来判断角色输入及位置状态（不多，几百行大概），你找个那种普通的U3D跳跃教程，就拿那种用什么物理引擎做2D的，然后操作一下，基本就会发现那种教程都是胡写，手感和操作控制都是屎，甚至写教程的自己都没试过。

https://www.baidu.com/s?wd=%E8%BE%93%E5%85%A5%E7%BC%93%E5%86%B2+%E5%B9%B3%E5%8F%B0%E6%B8%B8%E6%88%8F
https://www.google.com/search?source=hp&q=input+buffering+2d+platformer


来感受一下输入缓冲用中文搜索引擎只能搜到一条正确结果的凄凉感。

做MOD没得选还好说，哪怕是自己坐着玩，引擎还是要挑一挑，工具还是要点推荐。

选UNITY这些主流的，网上教程一大堆，完全可以现学现卖，找个小众的引擎，怕是现学都找不到地方。



一些工具也是很重要的，就像MOD一样，让没有能力的人变得有能力。

比如像素画风的话，我上面就推荐Pixelmash，找点现实中的照片转换成像素画，调一下色作为场景/背景素材就挺好了，可以让不会画画的人省掉不少功夫。

还有Qubicle Voxel Editor把像素画转换成像素风模型，即使没有什么基础的人都可以搞定像素建模。

这2个STEAM还有得卖，价格也不贵，不用折腾**。

所以我还是希望有更多这类工具推荐。

学习学习

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

有个教程里见到没没验证过的说法，是马里奥跳起和落下是两种曲线，如果是，要么自己截图自己算，要么看有没相关资料，有的话当然是看资料方便了。也听说过有第一人称游戏其实已经离开了平台要掉下去，但还是给一点“多余空间”来起跳。总之就是，先告诉我那种游戏完整具体是怎样的就方便多了，移动这种程度的话不需要具体代码，但具体数据还是要。

我更倾向于从内到外学习，自己先做，发现一堆问题去看看别人怎么做的，而不是事先在网上收集好多少种优化，做游戏时塞进来。

比如最开始学习写人物移动的代码，键盘按住左再按右是否改变方向，再松开右还是否继续向左走等等，试试就知道该怎么改了。

这些“硬核”玩家们肯定不屑，而且不是说好几行吗？
indienova.com/u/root/blogread/11340
而且如果游戏真的硬核，给这种缓冲反而不好吧，重试的时候说不定感觉更乱，反正硬核游戏我不碰所以不太清楚，我想也许可以给一个落地瞬间如果跳键是按住的状态的话还是能起跳，那其实在起跳条件里写成按住或按下似乎就好。当然都没实际试过。

至于物理引擎，所以说不推荐特别是“像素”游戏用，以前游戏是用长方形（或类似方法）判断碰撞，移动一次是水平移动和垂直移动分开，其实斜移是会像这样

至少我看的教程是这样说的。

我只见过一种写法，if left left，else if right right，else if up……
就是其实只接受一种，而且有先后，如果先先判断右，那自然会按左和右时向右，还没见过其他什么奇特的写法。

试过就知道了，不做缓冲输入就被吞。。。。 毕竟玩家的手和帧刷新是有延迟的，可能按早了或者按晚了，但是心理想的是我明明按下了怎么吞键？！
另外物理引擎是用来做hitbox aabb的

输入序列还是有的，那些类似格斗游戏连按指令的要用到。

那“硬核”玩家就应该习惯，明白是在那时按才有效，如果给一个提前多少帧的错觉那反而对“硬核”玩家不好。另外如果有这种缓冲，应该只按住跳键就会一直在原地跳，有哪些这样的游戏？

不太确定意思，但物理引擎做AABB还是物理引擎，该怎么物理引擎还是怎么物理引擎。

那应该就是另一种系统了，其实也可能需要，因为有能搓招的动作游戏，只是还没见过这种教程。

我想想，平台游戏不这么做主要是“不需要”，为什么要同时按左和右？按你们的说法，这种程度还是需要考虑的。我也见过俯视2D的控制，好像有左和右是一块，下面不用else上和下是一块，然后还搞了个加速度。至于360度手柄摇杆是另一回事，应该有值可以直接拿来用。

不过就是讨论而已嘛，要是我能说到你会做游戏，还是你说到我会做游戏都很好啊。

只是对事，这样写应该不好，玩家输入和不管物理引擎什么角色的“惯性”是分开的，这样写就变成了按完左再按右还有留下向左的速度需要先减完，（当然不是完整的码，单这样还不会，只是我猜是这个意思，）如果非得做同时按左和右会不动之类也应该能简化点，比如直接在if left和else if right间加个if right。

刚见到的平台游戏，想玩可能要趁早，只是不清楚是用什么做的，感觉效率可以接受，网页版我的机也能玩。
eniko.itch.io/superbernieworld
More information里有steam连接
感觉已经做的很好了，我自己一个要是能做到这个程度已经该被自己感动得泪流满面，但明显对比真正的马 奥还差了很多。

不做缓冲硬核玩家能把操作精确到1个tick的吗？那叫TAS，不是人类的操作， 逐帧判断和输入缓冲并不冲突，输入缓冲是为了保存上一次tick的输入结果后给当前的tick用，这种90%的现代动作游戏都是基本配置的东西，结果讨论来讨论去就歪楼了，变成了“硬核”不需要这东西，“玩家”应该去习惯，“横板游戏不可能同时按两个方向键”，“我只见过一种写法”， “另外如果有这种缓冲，应该只按住跳键就会一直在原地跳”。

我说老哥，这不讨论蔚蓝呢么，你怎么抗拒他干嘛。。。。嫌他写的不好？既然只接受一个观念，那就算了，不再讨论。

那设计比如强制拖板时留点余地啊，而不是什么按早按晚了，至少除非以前的游戏都这么做，我个人觉得这种做法有疑问。如果要说有延迟，那你可以根据最基本的按方向键时等多久才动来感受，音游也能调延迟，但那是全部的延迟而不是单独某个键的。

没说不可以按，但很多手柄不能按，要是你非要按，给个理由，所以个人觉得不处理也是正规的，当然按键盘输入为前提处理了也算用心。

不然呢？因为有缓冲啊，那不是该一直跳吗？

不知道，我脑力有限，只想按自己的方式搞懂，要是跟不上别人的思路，那也就算了。

还有想起以前玩过一个按格移动游戏，有冰面会滑动途中不能操作，但是其实它记住了操作，在滑到底时会立即按那个操作移动，我个人觉得如果是这种情况虽还算不上BUG吧，还是应该修一下。
其实还是忍不住要吐槽，想想几个人说想做游戏，为按左右键这种事争论了半天，这游戏还能做出来吗？当然可能我也回的太主观，那再客观点，1是除非游戏需要按住左右键的操作，否则可以不用考虑，2是缓冲到底有没必要，如果是我我觉得可能没区别，因为我的迟钝有可能分不清10帧什么的，但多少可以“感到”，那失败一次又一次反而可能永远找不到感觉，因为和实际不一样了。3是我觉得是会一直原地跳，要不是怎样的复杂条件分歧？4是不对游戏，而且玩的时候都没所谓，没这么认真，但一样东西拆开后当然就会开始想，这里怎么放得这么乱之类，既然我的目的也不是非得做出来不可，自然还是想放的至少自己觉得舒服。

貌似不少引擎/或者主机API之类的都是自带了缓冲的，不需要自己处理。

说到缓冲，个人觉得有个更有必要的是储存，比如很多unity小游戏就没存档功能，还有像推箱子类撤回操作，还有回顾已读文本应该都需要，只是不知道是不是算同一种。

是的，确实有个例，但无法改变大趋势了，连maimai这种大型街机都用unity了。

想了想，我其实目前并不想真的做一个游戏，总之定个稍微有趣的目标，就是尽量把这些视觉效果做出来
bilibili.com/video/av184101/
首先就是砍起来的那个轨迹，如果可以尽量想直接做成动画，但这样就是有个平时看不到的一片，到挥时才显示出来，这到底能不能直接动画暂还不清楚，还有其实这些发光半透明效果也还不知道标准做法。