Global Game Jam，简称GGJ即48小时游戏极限开发活动是世界上最大的游戏创作活动在每年的一月末举行从2009年开始GGJ大会每年都会提出一个活动的主题，参赛者需要按照主题进行游戏的创意迭代与思考：历届GGJ活动主题
2009：只要我们拥有彼此，就永远不会遇到问题；2010：欺骗2011：灭绝2012：一张衔尾蛇的图片2013：心跳的声音2014：我们不是从事物的角度看事物，而是从我们的角度看事物2015：我们现在干什么2016：仪式2017：波浪2018：传动2019：家对你而言意味着什么2020：修复2021：失物招领2022：“二元论”2023：？？？每位参赛人员都需要发挥创作力，探索在艺术表达、动画、变成、创意迭代、故事创作等方面的发展过程与经验分享，并将这些浓缩在48小时的开发周期内，所以GGJ可以被称为是一场游戏开发领域的“编程马拉松”。 GGJ适合—— 所有对游戏设计感兴趣的人~无论你是高中/大学/考研党还是正在就业的打工人~只要你有游戏美术、游戏设计、动画、插画、编程、建模、策划这些技能都可以参加！特别推荐正在准备游戏/动画作品集的同学！！在比赛中，不仅能完成一个完整的游戏作品，拥有国际大赛经验背景，团队作品会在GGJ官网展示。 你将得到—— 1、顶尖名校导师带领团队合作创作游戏经验！2、获奖证书、团队作品官网展示、国际大赛经验背景！3、为留学申请、就业、考研增添亮点！用一个周末的时间体验游戏开发的全过程，参与到一场全球游戏创意探索的狂欢中，让全世界知道你正在制作的游戏项目，遇到更多有趣有能力的人，对游戏开发有新认知！Global Game Jam 2023等你组队！DiCO也为想参赛的童鞋整理了一份比赛生存指南！速速mark起来吧~1.查找距离自己最近的站点在官网查找距离自己地区最近的站点，注册账号再选择想要参与的站点。深圳DiCO赛点链接https://globalgamejam.org/2023/jam-sites/art-dico-gamejam深圳DiCO报名信息填写地址深圳市南山区鲤鱼门街前海深港青年梦工场 10栋504（地铁9号线梦海站C出口）2.活动前准备留意时间地点提前确定好自己参加站点时间与交通信息，规划好行程，因为一旦迟到的话，很有可能会影响组队的进程。深圳DiCO站点活动开启时间——2023年2月3日 周五下午6:00 确认周边设施有条件的话建议提前去踩点一下现场周边的设施，虽然是48小时极限游戏开发挑战，官方还是不建议扛个睡袋直接睡在现场。有条件的可以提前订好附近的酒店，保证最舒适和充足的睡眠。确认好附近的餐厅以及便利店等设施，如果为了节约时间的话，出门就餐最好避开吃饭高峰。由于很多人会选择通宵，便利店的话确认好周围的24小时便利店，如果附近没有24小时便利店，建议在便利店关门前购买好水和带有糖分的点心，糖分摄入有助于在晚上更好的思维。准备好自己的装备现场开发环境是自带的，大多数开发者都是自带笔记本电脑，当然也有不少人直接抗台式机和显示器过来的。除了开发设备之外，记得准备好洗漱等日常用品，以及带好一些常备的应急药物。3.寻找志同道合的队友组队可以提前组件队友，如果找不到也可以在当天现场寻找队友。但据了解，2023年会采取线上/线下结合参赛的形式呢~建议大家提前寻找小伙伴组队~GGJ深圳DiCO赛点交流群链接进群需要准备一份自我介绍的PPT，为组队提前做好准备~个人PPT模板如果群链接失效了，也可以扫下方二维码添加DiCO客服，备注GGJ即可让客服小姐姐邀请进群噢~4.提前准备部分素材开发过程中可能需要用到一些素材，比如音效、音乐等等~推荐AVG图形化制作工具NVLMaker的素材库，有大量的音乐和音效素材可以提前准备好。https://www.nvlmaker.net/material.html虽然各个Global Game Jam站点可能都会评比作品，但要记得这是一个活动，不是一个比赛，相信每个人都能在活动中有很多收获。参加这样的活动，希望更多去享受和伙伴一起创作游戏的过程，感受纯粹创作游戏的乐趣。除此之外，一定程度上检验自己的一个过程，至少它有这样的意义。最后，DiCO祝大家在即将到来的2023 Global Game Jam中国深圳DiCO赛点玩的开心！}

上周末很幸运参加了线下的global gamejam 2023，地点在东京六本木的一所编程学校Code Chrysalis。因为是第一次参加线下的gamejam，准备不足但是也收获颇丰，所以想趁着记忆还算新鲜的时候把48小时的经验记录一下。因为是个人经验主要为了记录用，很多想法可能有误，所以仅供参考。第零天关于事前准备：1. 比赛前一周和程序朋友语音商量了一下比赛内容，确定了一下要用的游戏引擎（Unity），统一了引擎的版本以及商量了美术音乐素材的问题。然后说这段时间可以再看看玩玩一些独立作品，刺激一下思维（虽然最后也没做）。2. 在场地附近租了酒店。3. 事后反思来看，事前准备应该也包括建立在线文档以及建立云盘。第一天 2月3日关于入场：1. 一定要提前在GGJ官网报名，因为现场的人数都是限定的，不报名入场大概率是会被拒绝的。2. 除了官网报名外还要仔细看其他要求，比如秋叶原场地就需要在GGJ官网以外的另一个网站报名（因为要收取入场费），不过一般主办方也会发邮件提醒。3. 看好场地使用语言，尽量选第一语言就是自己熟练使用的，否则可能沟通上会有困难。关于破冰活动：1. 破冰活动并不会决定最后的队伍组成，不过现场大多数都和破冰结识的朋友组队了。2. 我运气非常非常好，在破冰活动的时候就认识了一位负责美术的阿根廷女生还有一位负责音乐的德国女生。再加上本来就认识的程序朋友，组成了一个很合适的四人组。3. 本次破冰活动的内容就是根据本次的主题“Roots“在小组讨论后提出一个初步的想法，包括游戏类型、游戏角色和玩法。之后的游戏开发也延续了这个初步的想法。关于脑暴：1. 正式确定小组成员后就坐下来开始脑暴了。脑暴还是需要纸和笔或者是绘板来快速表达创意。这时候会感觉高效的表达能力和一些基础的绘画功底在试图说服其他人的时候是很重要的。2. 其实所有来玩gamejam的人无论是负责美术、音乐程序或者策划，大多数都是对游戏感兴趣的玩家，因此在脑暴中所有人都在提点子，只不过玩过的游戏数量和品类差异比较大，所以讨论中可以明显看出这些差异，这些差异也成为讨论的障碍，降低效率。3. 在达成共识后进行有效讨论非常关键。在对一件事，比如一个基本的游戏类型达成共识后，接下来的讨论应该尽量（其实不是尽量，几乎是必须）在这一共识的基础上进行。而不是多数人已经决定要做一个2d的冒险游戏，这时候有人又反过来讨论一个射击游戏的想法。4. 为了有效讨论，要在适当的时机做出“决定“，决定要写在纸面上让所有人都看得到。这些决定可能包括，turn-based还是real-time，目标是什么，怎么算game over等等。5. 脑暴之后所有人的的脑海中都应该对游戏有一个大致轮廓，脑暴后本组的美术同学开始绘制概念美术，音乐同学开始着手制作一些必要音效，程序同学开始思考怎么实现核心玩法，我主要负责整理讨论结果还有绘制游戏的流程图。其他：1. 由于本次六本木的场地并不支持24小时开发，十点之后就要离开，所以之后就要各回各家了。为了方便，在开发场地附近租一个临时住所还是有必要的。但是六本木的酒店价格确实是过高了。2. 和国际友人组队很重要的一点是必须要使用大家都熟悉的语言，我和朋友说中文就会被组内另外两位朋友说是在说悄悄话，所以后来就强迫自己纯英语交流了。第二天 2月4日关于最终讨论：1. 由于第一天脑暴并没有讨论出最终结果，所以上午又进行了最终讨论，这次的讨论也是在纸面涂涂画画很多次，最后从两个方案中二选一，最终确定了游戏流程、游戏玩法、游戏名还有整体风格。总的来说是比较顺利的，因为四个人性格都不算强势，几次妥协之后就形成了共识，另外就是确定两个方案进行选择似乎比较有效率也比较尊重组员意愿。关于开发：1. 美术同学很快完成概念美术给全组确认过后就开始画背景素材。同时我也开始思考关卡设计然后开始写关卡的美术需求放到云盘。在只有一人负责美术的情况下任务就变得很繁重，不仅需要绘制UI和背景还有关卡中的素材，而背景的绘制周期比较长，因此关卡素材就滞后了，导致最后实装的时间很紧张。2. 程序其实比较快就实现了基本的玩法，但是需要一直调整手感和流畅度以及流程上出现的一些细枝末节的问题，比如失败后画面的渐出效果这些。3. 音乐素材的制作效率也很高，全组一起试听音乐素材成了一种休息的方式。4. 我在提交美术需求之后就在unity新开了一个项目开始搭建关卡，因为游戏玩法并不复杂机制也少，简单来说就是躲避障碍物，因此想让游戏增加趣味性反而更难。（其实在提需求的时候提到了一些动态的障碍物，但是最后时间不够也只能作罢）第三天 2月5日 关于最后的开发：1. 最后一天，基本大局已定。到了中午关卡搭建完成，程序也基本实现，剩下就是在等待美术素材实装。差不多到中午UI素材完成，到了下午完成了关卡最基础的两种障碍物的素材。因为实际的素材和我自己用的范例素材有一定差异，因此需要调整大小、位置和碰撞体，做完这些时间几乎所剩无几，最后匆匆上传，实际上最后版本的关卡和我本身预想的还是有差异，但是没有更多调整的时间了。关于展示：1.东京时间下午5点提交作品之后就到了展示环节。2. 前面看了八组的作品，完成度都比较高，也风格迥异，但是也没有特别惊艳的作品，所以到我们展示的时候也没有很大压力。3. 作为组内脸皮最厚的人一直是负责上台说话的角色，最后展示也是在台上拿着话筒，介绍队友介绍游戏，因为是最后一组，所以还是紧张了很久，不过上台后就会松弛很多了。胡说八道吧，没人在乎。关于试玩和pizza环节：1． 上传以及展示之后其实gamejam差不多就到尾声了，最后就是互相试玩游戏，出乎意料的是，来试玩（或者说挑战）的人不少，热度比较高，评价也还不错。国际友人的高强度夸夸一直是在线的。试玩会某种程度上也是高强度社交，会有人不停来打招呼、来聊天，也需要不停介绍游戏以及游戏的bug，这也是乐趣所在。2． Pizza有点少，没吃上几块。关于告别：1. 最后组里四个人加上另一位中国朋友一起溜达到日比谷线六本木站，坐上不同方向的地铁就各回各家了。地铁上和阿根廷朋友天南地北扯了很久，别的不提，她跟我说世界杯夺冠那天晚上在日阿根廷人走上涩谷街头甚至骑到了八公像上，属实给了我一点小小的阿根廷震撼。 2. 希望有缘再见。关于作品：1． 作品链接：}

夹在实习和期中的缝隙里挤出了个周末参加了社团的game jam。其实大一就想参加了，但是每学期这会都忙得一团，也就过去看一眼当当裁判啥的，结果四年过来我居然一次都没正式参加过。一想再不参加就要毕业了，所以死活抽了时间出来整一把，拉了两个朋友一块参加。我们社团的game jam叫bear jams，时间相比主流的jam比较短。周五6:30pm公布主题，周日3:00pm就要交，满打满算连45小时都没有，做起来紧赶慢赶的。活动海报这次的主题是Into the Unknown。以前每次参加game jam想游戏玩法就要想半天，结果这次敲定得很快。主要原因是之前就有类似的玩法点子，这次正好可以改改拿过来。而且很巧的是两个人都想到一块去了，所以头脑风暴过程几乎没什么分歧，一顿饭吃完游戏玩法也就定下了。游戏的玩法就是一个2d格斗游戏。但和传统格斗游戏不同的是，一般情况下画面是全黑的，只能看到玩家自己的角色，敌人/场景等等都是看不到的。玩家需要依靠音效线索来判断敌人的位置距离 以及接下来要出什么招 -- 当时想想感觉再改改就是另类音游了。考虑到时间因素和以前的惨痛教训，最初设计的时候，游戏特性就被砍到最低。一个关卡，一个敌人，场景没有特殊互动。玩家可以左右移动，出拳（上段攻击），踢腿（下段攻击），上段格挡，下段格挡，发火球和闪避。对手的基本模组和玩家是一致的，就是不同的系统组合。上下段攻击会被对应的格挡防住，我们还加入了烂俗的完美格挡系统来提高一点点深度。每次击中敌人或者成功格挡的时候都会攒蓝条，消耗蓝条可以放不可可挡，但是可以被攻击破坏的的火球。这个格斗系统非常基本，玩法是希望玩家通过音效线索记忆ai的攻击模式，然后进行流畅的应对措施。设计难题这套玩法最主要的难点一方面在于平衡看不见对手出招导致的难度问题，一方面在于本身战斗系统的深度问题。老实说虽然设计的时候围绕着这两点做了很多，但是最后受于时间限制一部分特性没能完成，另一部分系统也没能好好调试数值，很多都是测试的数值就直接大差不差用了。难度问题考虑到游戏大部分时候是看不到敌人的，所以我们需要很好的设计音效让玩家感受到敌人的行动。敌人的所有行动都是3d音效，也就是离得越远音量越低，我反复调节了音量曲线来确保能比较明显的感受到敌人的距离感。与此同时，敌人的所有动作都必须要发起音效：移动时的脚步声发起连招前的固定喊声连招内每次出拳/踢腿都有固定的喊声发火球的喊声受击玩家控制角色的对应音效反而要少。诸如脚步声这类的全都砍了，出拳/脚踢也都用相同的一个，受击音效也更短促。原因很简单，玩家能看到自己角色的动作，加入这些音效不仅没必要，反倒是会让玩家从需要专注的敌人音效线索上分心。实际上玩家相关的音效都是2d的，更加方便直接控制音量，所有音效的优先级也都低于敌人。为了提高辨识度，玩家和敌人同一动作音效是严格不一致的，避免让玩家感到迷惑。不过设计的时候就考虑到“想法很美好，执行一坨糟”的情形，我们也没有过于期待音效线索能完美发挥，所以基于此设计了一套兜底的系统。首先是距离判定，敌人移动时不仅会发出脚步声，同时隔一段时间也会有一个小且快的粒子特效，给玩家提供一点视觉辅助。脚步特效与此同时每次双方交手的时候都会在攻击处产生一个特效和临时光源，短时间点亮局部情形。当用出完美格挡后这个光源直径会更大，持续时间也会更久。对于火球这样的攻击，干脆在上面附一个很小的光源跟着一起飞。最后的最后，每隔15-30s会随机“打雷”，整个场景都会被短暂点亮，让玩家清楚看到敌人的位置。打雷这套玩法比较头疼的要不然太难，要不然太简单。取舍之后考虑到game jam里大部分人也不会对游戏有什么深刻的研究，所以决定还是宁愿简单，至少让人能玩起来。实际设计完之后确实挑战性不足了：由于交手会产生光源，除了第一下攻击，真正交起手来光源不停出现还是可以直接看到敌人的出招的 -- 不过另一方面由于出招非常快，实际上还是要靠音效去预判攻击，某种意义上设计目的还是达到了。深度问题让游戏不要太难后另一个问题就是怎么让他好玩。默认的战斗机制就是个猜拳赌博的玩法，而且我们特别怕玩家会滥用格挡，又或者掐准距离不停hit stun AI。对于后两者相对比较好解决：就像大部分格斗游戏一样，在格挡和攻击之后都有一个不能行动的后摇阶段，提高玩家错误行动的代价。前者一开始设计的时候想法还是很好的：主要玩法就是尽量格挡住敌人的一套连招，每次格挡都会积攒一个伤害buff；如果能完美格挡AI连招最后的收尾一击，敌人会出现一个大的破绽状态，配合之前积攒的伤害buff来打出海量输出。其实就是现在很流行的break系统。但是呢，上面都是扯犊子。由于时间原因，无论是格挡增加伤害buff还是最后完美格挡的破绽系统都没来得及做出来。。。为了让完美格挡收益不至于太低，玩家在完美格挡后能获得一大截蓝条，用来在安全距离放大伤害的火球。同样由于时间原因，敌人完全复用玩家的动作模组，也没有独特的攻击动画，所以各种连招其实上下段攻击的组合。为了提高可玩性，连招是在每局开头随机出来的。每次会随三个连招，分别对应固定的出招呐喊音效，方便玩家识识别。执行难题系统深度已经缺乏了，那怎么激励玩家用完美格挡呢？那就得靠呈现了。默认格挡我们做了个很沉闷的音效，但是完美格挡的音效则是非常鲜亮尖锐的。考虑到完美格挡的时候双方距离肯定很近，完美格挡音效我们直接做成了2d，保证一致的音量大小。与此同时搭配一个亮绿色而且比别的大得多的格挡特效，尽量凸显出完美格挡不一样的气质，至少把手感做的舒爽。另一个执行问题就是每个动作判定具体应该是多少。比如玩家出拳，前摇要多少帧，伤害判定要多少帧，后摇要多少帧...这些问题一开始很容易忽略，但是实际做的时候发现是个难题。我除了大乱斗很少碰格斗游戏，直觉上觉得一次攻击可能要半秒到一秒，其中大半是伤害判定帧。然而按这个调出来的手感非常差，感觉操作非常不灵活。另一个队友经常玩格斗游戏，提出大部分攻击应该在10帧以内（我们游戏锁60fps，按帧判定）这样才感觉灵活，按4:4:2分配前摇：伤害：后摇。但效果也不太好，还是差点味道。然后我们发现了一个宝藏：https://ultimateframedata.com/这个网站记录了大乱斗里所有角色所有动作的详细帧判定细节。拿马里奥轻攻击连段的第一击 举例：一共19帧，2帧前摇，第2、3帧有伤害判定，最后16帧后摇。这个数据让我大吃一惊：后摇阶段居然是前摇+伤害判定的7、8倍长度（当然大乱斗的手感相比传统格斗游戏也是要慢一点）。算是学到了新东西。有了参考对象就好指定我们的帧判定，基本原则就是起手+伤害尽量短，后摇要显著更长（虽然相比大乱斗我们还是砍短了点）。技术难题我们三个人算两个半程序，但是另一个程序想做美工，所以最后程序的活90%都落在了我的头上。老实说我是从来没做过格斗游戏，所以这次也是也是有点挑战。另一方面，这次参加game jam也想着不要太执着于技术，所以尽量能简单点做就简单点做。玩家控制器由于砍了跳跃，状态管理要简单很多。本来想直接用dynamic rigidbody2d做但是有一个要求是角色移动的时候可以慢速互相推动对方。虽说也能用dynamic rigidbody2d做，但是受限于物理引擎，实际效果不怎么好调节，所以简单试了试还是觉得自己写移动物理。其实也不复杂，场景非常简单，除了两侧和对手没有障碍物。所以基本逻辑就是移动前做一个手动的sweep test找到最大移动距离。如果是对面角色（可被推动物体），那会根据推力和剩余距离计算一个推动距离，让对面角色进行一次sweep and move，最后再对自己sweep and move剩余距离。说起来简单实际发现还是有点坑。一个是如果角色capsule collider2d紧贴着左边的墙，但是往右边移动，大概因为浮点精度原因，sweep test返回最近的点是capsule和左边墙的交点。这个解决起来也简单，在找最近碰撞点的时候根据方向kill掉不符合的碰撞点就行了。另一个也是浮点精度问题。由于我们游戏逻辑是基于帧的（因为我看大部分格斗游戏都是这么做的），当帧数更过的时候，会产生每帧移动距离太小导致玩家碰撞体被吸在障碍物上离不开的现象。这个也没什么好说的，锁60fps基本就不是问题了，实在不行也可以把关卡比例放大。不过这个问题主要出现在>150fps的时候，所以影响不大。最后做完了发现还是整复杂了。考虑到场景里没别的障碍物，完全可以根据玩家的capsule宽度直接算出能移动的左右最大/小坐标然后限制在里面就行了，只能说脑子里还是第一反应想复杂了。闪避加闪避主要是为了替代跳跃。当时想法是跳跃需要地面检测，更复杂的状态管理，玩家更多的操作（需要跳起来再左右移动），所以干脆用闪避代替。但最后。。。闪避也没实现，因为发现这比想象的复杂。主要问题是我们游戏里不允许两个角色重叠，但是闪避可以穿越角色到一侧。这就会导致一个edge case：如果玩家的闪避距离正好会移动到对方角色的内部，那该怎么办呢？一开始想那就停在对方面前就好了，提前退出闪避。但是又意识到另一个问题：如果对方角色每一帧也在移动，比如说正好后退到本来空置的闪避结束点怎么办呢？我相信肯定有个解决方法，但是觉得一时半会想不出答案，和队友一阵讨论决定把闪避直接砍了。打击特效无论是受击还是格挡都需要一个打击特效。想法是类似音游那种扩大的圆环效果，但是实际制作起来有一点点麻烦：直接放大一个圆环sprite的话，圆环的厚度也会改变，达不到想要的效果，而且说实话放大了锯齿也比较难看。实际想做的好话原理也不复杂，在着色器里里用sdf（圆公式）画圆镂空中心就行了。但这次我不想花功夫整渲染了，所以直接抄了 @YY-2023 的urp shader graph，可以自由调节圆心位置和大小，效果非常棒。加了特效立马效果不一样了https://www.zhihu.com/video/16168090026078248963D音效尽管前面设想很好，但周日早上接入音效，实际体验之后还是咯噔一声：本来想着直接开3d音效就行了，但是开了之后由于对手一直在玩家的正右侧，直接让游戏变成完全的单声道体验 -- 左耳朵完全不出声。这个效果就完全不能接受了，当时突然感觉人傻了。不过仔细分析后，我们想要的效果是只要音量衰减，但是不怎么带方向性。一种方案是完全用2d音效然后脚本根据距离控制音量，但是考虑可能还有别的坑所以直接用了一个很简单的trick：既然不要方向性，就让音效的x/y坐标一直都和绑在主角身上的audio listener一致就好啦！音效的z坐标则是实际音效离玩家的距离。这样我们保证3d音效一直都在玩家的正前方，那就不存在方向性了啦。相当于绑在敌人身上的是一个虚假音源，真实的播放音源会根据虚假音源以及玩家的位置更新自己的实际位置，播放3d音效。很快就解决了问题。URP光源URP的2d光源支持还算可以，所以就直接用了。碰到几个问题，一个是如何设置部分物体不受光照影响。这个其实就是把这些物体单独放进一个光照layer里，然后对他们用一个intensity为1，blend style为multiply的global light。另一个问题就比较复杂。在我们游戏里移动的火球会有个光源，但同时可能也有打击特效产生的光源，甚至会有背景打雷的全场景光源。这三个光源怎么叠加就是个问题。最初的构想其实是类似遮罩一样，只要一个地方有光源就显示像素，但是一个像素如果有多个光源的话不会产生重叠的光照效果。然而urp没办法很简单的设置成这样，不同光源的混合要不然additive，要不然alpha blend。这样有时候会产生下面这张亮度一层层的瑕疵：最后还是算了，接受这点瑕疵了，实在没时间研究。我估计要解决的话，可能就是选用sprite光源，然后给一张全屏sprite，每帧把光源形状画到这个sprite上当mask用。成品最后成品就是这样的：BLIND man BRAWLhttps://www.zhihu.com/video/1616810529401544704尽管有这样那样的遗憾，老实说我个人还是比较满意的。难得一次game jam把主要玩点实现了外，还进行了一定程度的打磨，无论是音效还是视效也都做出来，至少整个游戏给人感觉是比较完整的。周六下午是最折磨的时候，当时同时写8、9个脚本，但一个都没成型，一时觉得要写不完了，不过最后还是赶上了。总的来说game jam主要是享受下这个过程，单纯时间设置上来说很难让你去真的设计能耐玩的好点子，以后大概也不会太想参加了。当所有资源汇总起来变得可玩的时候还是很激动的游戏http://itch.io页面在这里上传的版本还是有bug的，部分电脑不知道为什么锁不上60fps。。。（unity这个vsync设置也是坑）}