GameMaker: Studio 中文教程特别篇 #1: 来聊聊版本管理 | indienova 独立游戏
GameMaker: Studio 中文教程特别篇 #1: 来聊聊版本管理
本篇作为 GMS 中文教程系列的特别篇放出，来和大家聊聊版本管理的问题。
我相信有很多刚开始做独立游戏的人不用版本管理（VCS），因为我自己常常也懒得用。但如果你是认真的想要做出点什么像样的东西，很难想象你能不通过版本管理而完成这一切。比如看看以下这些场景：
你想尝试一个新的功能，结果发现把整个游戏搞砸了，这时你是否想要直接回滚到上一个能让游戏正常运行的版本？如果没有这样回滚的功能，也许你根本就不敢尝试有风险性的改动？
你和你的团队远程合作（这种情况在独立游戏里很常见），如何共享内容给彼此呢？曾经我合作的一次是双方互相发送邮件附件来传送项目文件……直到项目文件超过了25M（Gmail的附件大小限制）。更不用说多方同时对一个文件进行修改时的冲突管理了。
你是否会在多个地点或者设备制作你的游戏，例如家里的台式机以及外出时的笔记本？
你是否会为不同的场合交付不同的游戏版本？例如为独立游戏节提交的参赛版需要是一个稳定的版本，而给帮你测试的小伙伴们的是包含最新内容的版本。
当帮你测试的小伙伴告诉你bug出现的时候，你要如何迅速知道是哪里的改动导致了这个 bug？
当游戏发布以后每次版本更新时，你要告诉玩家此次更新所包含的内容，你如何得到确切的改动列表？
上面所提到的这些情形，都可以通过版本管理来得到很好的解决。所以，今天我会介绍如何用 GitHub 提供的免费 git 仓库以及 GitHub Desktop 客户端来对你的 GameMaker:Studio 游戏项目进行版本管理。当然，其实这个版本管理的过程与 GMS 完全无关，即使你以后用 Unity 或者别的引擎来开发游戏也同样适用。
我们简单地向不了解的读者科普一下什么是版本管理。
正如前文的介绍，版本控制会记录项目之下一个或多个文件的内容变化，以便将来查阅特定版本。即便不使用专门的版本控制系统，在游戏的开发过程中，无论是出于协作还是备份的目的，我们也经常会有保存不同版本的需求：许多人习惯复制整个项目来备份不同版本，还会重命名文件标注时间以示区别。这样做看似简单，但问题却不少：一旦混淆了所在的工作目录，弄错了文件损失了数据，就没法简单地实现撤销恢复。
为了解决这些问题，版本控制系统出现了，最早是模仿复制备份操作的本地版本控制系统，其中最流行的一种是 rcs，直到今天它甚至还存在于许多计算机系统之中，它的工作原理基本上是保存并管理文件补丁（patch）。文件补丁是一种特定格式的文本文件，记录了对应文件修订前后的变化。因此，根据每次修订后的补丁，rcs 可以通过不断打补丁，计算出各个版本的文件内容。
本地版本控制系统确实解决了部分问题，但如果遇到需要多人协作的场合就显得不那么适用了。在稍微成规模的项目中，这非常常见，因此，集中版本控制系统（Centralized Version Control Systems，即 CVCS）出现了，CVS、SVN、Perforce 这类系统，会有一个单一的集中管理服务器，用来保存所有文件的修订版本，而协同工作的人会通过客户端链接到服务器上，同步最新文件或者提交更新。
CVCS 一度成为版本管理的标准做法，但文件集中保存在中央服务器上，容易因为单点故障影响整个项目，在协作管理方面也不够灵活方便，于是，有人提出了分布式版本控制系统（ Distributed Version Control System，即 DVCS ）：在分布式版本控制系统中，每个参与协作的人都保存完整的代码库，而不是仅仅从服务器同步文件快照，此外，分布式版本控制系统允许指定和多个不同的远端代码库进行交互，这样，在同一项目下也可以分别组成不同的工作小组进行协作。整个项目的管理可以根据实际需要指定多层次的工作流，相比集中式的系统，灵活性大大提高。
Git 诞生于 2005 年，是 Linus Torvalds 在进行 Linux 内核开发时开发的一个工具类产品。与CVS、Subversion这类的集中式版本控制工具不同，它采用了分布式版本库的做法，不需要服务器端软件，就可以运作版本控制，使得源代码的发布和交流极其方便。git的速度很快，这对于诸如Linux内核这样的大项目来说自然很重要。git 的主要缺点（如果非要认为是缺点的话）可能在权限管理方面，作为诞生自开源社区的项目，它没有对版本库的浏览修改做任何权限限制，但通过其他工具可以实现有限的权限控制。
本教程介绍的 GitHub 是一个通过 Git 进行版本控制的代码托管服务，使用 Ruby on Rails 编写而成，最早在 Ruby 社区中十分活跃，随着注册用户和托管项目的激增，以及一些重量级的项目也逐渐迁移到 GitHub 上，它事实上已经成为世界上最大的代码托管平台与开源社区。
GitHub 注册
GitHub 是一个通过 Git 进行版本控制的软件源代码托管服务，这个 GMS 系列教程之前的所有项目资源均存放在 GitHub上。
它提供 1G 的免费公开代码仓库，公开代码仓库的意思是任何人都可以看到你的项目文件，如果需要无限量的空间或私有代码仓库，则需要升级到付费账户。与 GitHub 类似，但可以提供免费的私有代码仓库的网站有
和 Bitbucket.org，所以如果你很介意不希望你的项目公开的话，可以选择这两个地方。
特别提示：
提供 git 服务的地方其实非常非常多，不希望托管的话可以选择
提供的方案。如果希望使用国内服务的话，也可以考虑
首先你需要注册一个 Github 账号，这个过程相当简单，首先在
的首页上的注册区填入你想要起的用户名、邮箱和密码，然后点击 Sign up for GitHub 注册即可。点击进去后会让你选择是免费的公开仓库还是付费的私有仓库，默认是免费账户，所以点 Continue 继续下一步就好。然后到了第三步会让你填写一些个人信息，不过这些都是可以跳过的，直接点 Submit 提交就完成了注册。你会看到下面这个欢迎页面：
同时你所填入的邮箱也会收到一封验证邮件，点击邮件内的链接验证你的邮箱有效即可。
建立代码仓库
点击 Start a project（新建项目）来到建立代码仓库的页面，你所要填写的仅仅是你的代码仓库名称（Repository name）：
例如我这里新建了一个叫做 GMS_Repository 的仓库，然后点击左下角的 Create repository（新建仓库）就完成了创建过程。这时就来到了你的代码仓库的首页，这里显示了你的git访问地址和一些操作的命令行简介：
这个地址以及你的用户名密码等信息会在使用第三方工具访问 GitHub 时用到。
以上步骤完成后，还需要配置 SSH 公钥。它来为用户提供提交代码的身份认证。这一步需要用到简单的命令行操作，按部就班如下面的指南操作即可。
Git 服务器一般会使用 SSH 公钥来管理认证。换句话说，用户向某个代码库提交代码，需要提供身份认证，这套认证系统即 SSH 公钥。如果没有事先配置过，需要专门生成一份。默认情况下，用户的 SSH 密钥存储在其 ~/.ssh 目录下，如果是 Windows 系统，则在形如 C:Documents and SettingsAdministrator.ssh 的目录下。
为方便起见，如果没有合适的命令行工具，推荐在前往安装 git 的 windows 版本。安装完成后，打开 git bash 会出现一个命令行窗口。
按下列步骤操作：
输入命令：ssh-keygen -t rsa -C ""，邮箱建议使用 github 注册邮箱。
一路回车，提示中会要求是否使用密钥口令，建议留空。
生成的密钥会出现在前文所说的路径下，其中 .pub 后缀文件即为公钥。
用文本编辑器打开 .pub 文件，复制密钥，粘贴到 github 管理界面的密钥管理页面中（用户头像-&setting-&SSH and GPG keys-&New SSH key），如果使用其他的托管平台，操作方式也差不多，如果是自建 git 服务器，相信你有办法解决这个小问题:D。
安装GitHub Desktop
本来这里是打算介绍使用 SourceTree 这个工具的，但后来看了一下它的注册过程需要翻墙，所以本着尽量方便的原则，就用 GitHub 的官方工具 GitHub Desktop 来演示好了。其实一旦熟悉了版本管理的概念后，任何工具都是类似的，或者有人会更喜欢用命令行的方式来操作。
这部分写给认为命令行更加方便的部分人士。
隆重推荐 githug (点击来获得它)这个通过命令行来完成的交互小游戏。
在通关同时，你应该也差不多能够掌握使用 git 所需的大部分指令了。
点击上图中代码仓库首页的 Set up in Desktop（设置桌面）就会跳转到GitHub Desktop的下载页面。下载安装过程一路确定就好，在安装成功的欢迎页面会有三个步骤（如下图），分别是登录、配置、仓库，首先在登录页面会需要你用之前注册的 GitHub 账号登录：
在配置页面使用默认的设置继续下一步，在最后的仓库选择页面，如果你之前没有配置过任何 git 仓库的话，应该是看到以下的空白信息，选择 Skip 跳过就好。
最后就来到了GitHub Desktop的主界面：
GitHub Desktop实践
Git 是一个很强大的分布式版本管理系统，但正因为如此强大灵活，以致与我刚从 svn 这样的集中式版本管理切换过来的时候都晕了好一阵。所以不如我们直接通过对工具的使用来熟悉 Git 的各个概念。
一、克隆（Clone）
你应该还记得在 GitHub 注册那一节内容里，我们在 GitHub 网站上创建了一个叫做 GMS_Repository 的仓库，这个仓库是存在于网站上的，叫做远程仓库（Remote Repository），我们要做的第一件事是将这个远程仓库克隆到本地，有了 GitHub Desktop 的支持，这个操作非常简单：
在点击左上角的+号并选择 Clone 后，它会列出你在 GitHub 网站上已有的仓库，选择我的仓库 GMS_Repository 并确定后，再选择一个本地的目录，就会将远程仓库克隆到本地。
因为我们这时仓库里没有任何内容，所以只是会克隆到一个空的本地目录，但假设我们的游戏开发到一半的时候，团队增加了一个新的成员。那么此时他在克隆项目仓库时，将会得到所有远程仓库中已有的游戏内容。
而那个我们将远程仓库克隆到的本地目录，在上面的动图演示中，就是我桌面上的“GMSFolder”目录，被称为工作目录。我们在本地创建和修改游戏项目，是在这个目录中进行的。
二、本地改动（Local Changes）
现在，在 GitHub Desktop 显示的本地仓库下面，还没有任何改动，这个页面是这样的：
接下来我们用 GMS 来在这个目录中新建一个项目，我把这个项目的名字叫做 GitHubSample，建立后保存一下，再回到 GitHub Desktop 工具，稍等一下工具的刷新，就会看到所有 GMS 新建的项目文件都已经被显示在了改动列表当中：
上图中那些打勾的文件即为 git 所检查出来发生改动的文件，而右边绿色的+号表示这些文件是新加入的文件。
三、提交改动（Commit）
在上图的的改动列表下面就是提交改动的地方，分别是所要提交改动的概要和描述，其中改动概要是必填项，填好以后就可以提交你的改动了。
这里所谓的“提交改动”是指让本地的git版本管理系统能够记录你的版本信息。举例说，假如现在我去这个项目的本地目录 GitHubSample。gmx 里将 GMS 所生成的项目文件全部删除掉，我依然可以在 GitHub Desktop 中通过 Discard changes（撤销改动）命令来把这些文件恢复回来，这就说明了本地的git仓库中保留了这些文件的信息。
但如果我们把本地的git仓库删除掉，那么这些文件的版本信息就丢失了，因此我们需要把本地的版本改动推送到GitHub的远程仓库中。
四、推送改动（Push）
推送改动的意思是指将本地已经记录下来的版本改动（对我们来说是新建了一个GMS项目），也同样的应用到你在GitHub的远程仓库（也就是说GitHub也保存一份你新建的这些项目文件）。
推送的操作在GitHub Desktop中叫做Publish，我们将GitHub Desktop页面切换至History栏，左边这里会显示之前提交的本地改动：
点击右上角的Publish按钮，即开始了将推送的操作，这一步根据网络状况会持续数秒左右，等到那个转动的图片停止下来的时候即完成推送。这时候我们再登录GitHub网站查看，就会看到改动已经在远程仓库里了：
那么在这个时候，即使你删除掉本地仓库或者是你换了另一台电脑，你都可以通过再次克隆（Clone）这个远程仓库到本地来重新获取项目文件。
五、拉取改动（Pull）
如果这是你的个人项目，那么你的工作流程应该是这样：对每一个新添的游戏内容或者功能，首先在本地修改实现，然后提交改动到本地仓库，最后推送改动到远程仓库。但如果是多人的远程合作，那么每个人都会将自己的改动推送到远程仓库，如果你想要获取别人的改动（你应该总是尽可能的及时获取其他人的改动，以避免修改冲突），这时你需要去做一个拉取（Pull）的操作。
这里我们通过直接在GitHub网站上对远程仓库操作来演示。先登录GitHub，进入你的仓库后，可以通过网页直接进行文件的添加、修改或删除等操作。我们以添加文件为例：
红色框那里的按钮可以在当前目录新建一个文件，点击后进入文本编辑页面：
这里我新建了一个Test.txt文件，并随便填入了一些测试文本。在这个页面的下方点击绿色的Commit new file（提交新文件）按钮即可完成提交。完成后，就可以在仓库的首页看到这个新加的文件了。
然后我们回到本地的GitHub Desktop客户端，在这里Pull操作是通过一个标签为Sync的按钮完成（这个Sync按钮和之前提交改动时的Publish按钮其实是同一个，根据当前仓库状态的不同而显示不同内容）：
数秒后等待操作完成，即可看到在改动列表里显示了我们之前在GitHub网页上提交的新文件：
同时在文件目录中也可以发现这个新的 Test.txt 已经更新至本地了。
六、合并改动（Merge）
在远程合作时，多方常常需要同时对项目进行修改。当相互之间改动的文件没有重叠时，这些改动的合并是非常简单的。而如果两方同时修改了一个文件，情况就会稍微复杂一些，因为这需要你去手动解决双方的改动冲突（Resolve conflicts）。这里我们来演示一下这样的情形。
我们首先来在本地进行一些改动：
修改Test.txt
在之前文本的下方再加入三行文本：
This is line 1.
This is line 2.
This is line 3.
新建一个FileA.txt
完成后 GitHub Desktop 会自动检测到这两处改动：
注意左边红色标注的这里表示这两个文件的改动，一个是添加的新文件，一个是修改文件内容。上方红色标注这里是每当 GitHub Desktop 检测到本地改动时，Change 标签上会显示一个小圆点。
接下来我们按照之前说过的步骤，给这个改动的概要填写为“本地的第一次改动”，然后将改动提交到本地。
此时，我们先不要将改动推送至远程仓库，而是在 GitHub 网站上进行另一项改动来模拟多人合作时的情形：
修改Test.txt
在之前文本的下方再加入四行文本：
This is line 1.
This is not line 2.
This is line 3.
This is line 4.
这里我们特意将远程的修改与本地修改的内容不同。
在GitHub上修改文件的操作是先点击Test.txt文件，进入到这个页面后点击右上的编辑按钮：
将新的内容粘贴之后点击下方的绿色按钮将改动提交至远程仓库。
此时本地和远程仓库的改动列表就存在了差异，这是本地的历史记录：
这个是远程的改动记录：
这个时候，假设我作为进行了本地改动的人，想要将我的改动提交到远程仓库，我会去做推送的操作，于是去点击那个Sync按钮，结果就会遇到同步冲突的提示：
当你确认后，此时的改动列表里会显示Test.txt这个文件存在冲突
于是接下来需要我们去手动如果解决冲突的内容，点击右键选择打开文件或者直接在目录中打开Test.txt文件均可。其中：
&&&&&&& HEAD
This is line 2.
This is line 3.
这部分是显示的本地的改动，而下面这一半显示的是远程的改动：
This is not line 2.
This is line 3.
This is line 4.
&&&&&&& origin/master
值得注意的是，虽然版本管理能帮我们很大的忙，甚至有的版本管理工具能够一定程度的自动解决冲突。但最好的避免冲突的办法还是尽量在人员划分上清晰设置每个人的工作内容，在项目结构上不要将不相关的内容放置在同一处地方。原因是：
只有文本文件（代码文件）能够进行冲突合并，而对于图片、二进制数据文件等，就只能二选一选择继续使用本地的改动或者远程的改动了。
就算是自动解决冲突的方案，本质上也只是通过文本的匹配来识别双方修改中共同的部分（例如上面那个改动例子里的This is line 3.）、一方新增的部分（如This is line 4.）等基本情形。而如果双方的改动涉及复杂的逻辑，这个过程通常就只能手动进行，这需要对双方的代码逻辑都十分清楚才能完成。
对于我们示例中的情况，我们只需用文本编辑器打开Test.txt后，修改成以下内容即可：
This is line 1.
This is line 2.
This is line 3.
This is line 4.
然后在GitHub Desktop中提交这个改动后再次推送，这次就应该能够成功进行了。这时再到GitHub网站上去查看远程仓库，就能够看到“本地的第一次改动”和刚才解决冲突的改动都已经存在了：
以上介绍这些内容能够让你初步使用 git 进行版本管理了，但是，如果希望深入了解更全面的内容，还远远不够。
这里再提供一些入门资料供大家进一步参考：
已有 5 人赞过
已有 20 人收藏
近期点赞的会员
&分享这篇文章
您可能还会对这些文章感兴趣
参与此文章的讨论
好详细。。。
推荐一篇简易的
您需要登录或者注册后才能发表评论
<div id="failed-message" data-notify-position="top-right" data-notify-type="error" data-notify-msg=" 操作失败！请通知管理人员。">「游戏开发」GameMaker Studio 2 初体验
「游戏开发」GameMaker Studio 2 初体验
关注“indienova”，挖掘独立游戏的更多乐趣引言这篇文章将简要为大家介绍 GameMaker Studio 2 这款引擎（后文简称为 GMS2）。它是 yoyogames 出品的 GameMaker Studio 系列引擎的最新一代。经常访问 indienova 的读者朋友应该不会对 GameMaker Studio 这个系列的引擎感到陌生，大家熟知的经典独立游戏名作 Nuclear Throne，Undertale、Downwell、Hyper Light Drifter，Crashlands、Hotline Miami，Nidhogg 等等都是利用这款引擎完成的。GMS2 定位则依然和前代保持一致，是一款上手简单，功能强大，适合个人或者小型团队开发 2D 游戏的优秀引擎。这款软件于号正式公布并开始 beta 内测，正式版本则于上周四，也就是日发布，同步也上架了 steam 版本。本软件采取买断制销售，目前不带移动端和网页端导出功能的桌面基本版官网售价 99 美元，steam 版本国区则仅售人民币 249 元，加上针对一代用户的 40% 折扣优惠，仅需人民币 149 元即可购入。由于 steam 版购入后也能同时获得官网版本，因此对国内用户来说，目前最优惠的购买方案即是从 steam 版本购入。如果没有用过一代无法享受折扣优惠，可以委托拥有一代的朋友购买成礼物，同样能享受折扣优惠。steam 版也需要绑定 yoyogames 帐号登录，在上周刚刚发布时由于使用了某不存在网站的验证导致国内用户难以正常登录，官方已经及时解决了这个问题，目前应该没有这方面的困难。Steam 链接/app/585410/我也选择在这个时机入手并尝试了这款软件，结合官方分享的资料，希望能为那些想要稍微尝试或者将其作为开发工具的读者朋友提供一些参考。后文有很多对比是相对一代来说的，如果对 GMS 尚无认知，可以参考这里（/indie-game-development/professional-developers-look-at-gamemaker/）。概述GMS2 相比一代并非简单的功能升级，虽然沿袭了一代的许多特点，并且向上兼容一代项目，但基本上可以认为它是一款全新的引擎。相比主流的商业通用引擎 Unity 或者 UE 来说，GMS2 并不能用来开发次世代画面的3D大作，它虽然提供了简陋的 3D 支持，但主要还是专注于 2D 游戏开发。它提供了一整套方便实用的编辑工具，几乎不对开发者暴露技术的实现细节，而是希望开发者专注于游戏玩法，快捷高效地将自己的创意转变成游戏作品。对于开发2D游戏的个人或者小型开发团队来说，GMS 是非常高效的生产力工具。相比一代显著的改善GMS2 作为沿袭 GMS 的进化产品，依然使用内置的 GML 编程语言，熟悉一代的开发者能够非常快速地上手使用这款引擎。GMS 在许多方面都有着显著的进步。界面是最为显而易见的变动：相比一代其貌不扬的界面，GMS2 的 UI 在视觉方面有非常大的提高，简约大方，很有科技感。布局也合理了许多，很容易找到想要的功能，对初学者十分友好：资源树位于右侧，一目了然；工作空间中的各种资源以链式线框图的形式组织显示，非常直观清晰；新开编辑器会以标签页的形式展示，而不是出现一大堆相互重叠，难以管理的窗口。将GMS1 中分裂的图形化编程和代码编程方式有机融合：在许多不太了解 GMS 的人眼中，GMS 更像是一款玩具而非生产力工具，其中主要的原因之一就在于它拥有一套面向新手的拖拽放置式图形化编程工具。GMS 提供了一些颇为实用但却不那么灵活方便的内置功能，能够让初学者积木式地快速搭建简单的游戏功能。而对进阶的开发者，则可以使用 GML 进行开发。问题症结在于两种开发模式的分裂。习惯全面掌握项目实现细节的开发者会倾向于避免使用内置函数，而使得这套本来非常强大的图形化编程工具显得鸡肋而无意义。GMS2 则在这方面进行了巨大的革新，它允许图形化编程和代码编程实时同步地相互转换，并且废弃了一些过于鸡肋的内置函数。配合多编辑器同步更新的资源编辑工具和全面优化的工作空间，大大改善了 GMS 项目开发的工作流程。另外，图形化编程模式改为类似 UE 蓝图的线框图形式，更加灵活方便。内置编辑工具有着显著的改善和进步：一代尽管内置了一整套开发工具，但很多工具功能比较鸡肋，在实际开发时最佳方案还是结合外部工具来使用，但 GMS2 却在这些方面提交了一份令人满意的答卷。资源树被精简，原来的背景（background）和瓷砖(tileset)都被合并到了精灵(sprite)类型中，统一了处理逻辑，减轻了不少心智包袱；全面基于图层的地图编辑器（room editor）的进步非常显著，功能层级更加合理，并且允许开发者制作实用的瓷砖笔刷来快速地编辑地图。而地图能够继承的特性则让快速编辑大量关卡成为可能；内置的精灵（spriter）编辑器不再鸡肋，基于图层，能够实时预览动图，足以胜任制作简单的像素动画。性能的显著进步：GMS2 从一代的 DirectX9 迁移到了 DirectX11，性能据说有 20% 的提升，GMS 官方论坛有人专门针对性能进行了测试，详细可以参考这里（/index.php?threads/gms-2-0-vs-gms-1-0-benchmark.11844/）。跨平台支持更加完善：GMS提供的各种方法原生支持各个平台，大大减少了多平台开发的难度。目前支持 Windows，Mac，Linux，iOS，Andriod 等多个平台。各个平台支持的软件不再以基本版配合DLC的形式发布，而是需要单独购买。引言中所指的特惠版本指 Desktop 版，支持 Windows，Max 和 Linux 平台的打包导出，移动平台，UWP版，网页版导出则需要购买单独软件，我想吐槽的是面向移动端的版本售价远高于桌面版本，好处则是：如果专注开发移动版本，也无需单独购买桌面版，它们都是各自独立的软件。官网中标注支持PlayStation和Xbox平台，但并无单独的版本发布，可能需要专门联系 yoyogames 索取技术支持。方便实用的向上兼容特性消除了项目从一代升级的顾虑：如果已经是 GMS 一代的用户，我建议立即考虑将项目迁移到这款全面升级的新一代引擎中：GMS2 为1代的项目提供了自动迁移功能，使用 GMS2 载入 GMS 项目会将一些废弃的方法自动替换成新 API 中等价的方法（虽然这并不意味着完全没有工作量，但显然能节约大量的迁移时间）。笔者进行测试后发现，GMS1.4的项目导入后 GMS2 没有任何问题就正常运行了起来。结语GMS2 在国内并不流行，很多不够了解的开发者以为它只是面向新手，简化游戏开发难度的玩具。另外它采用的买断制经营模式也制造了一些进入门槛。但总的来说，这是一款非常优秀的游戏开发工具，值得游戏开发爱好者甚至专业的游戏开发者尝试和学习。强烈推荐给以下人群：GMS1代用户；个人或小型开发团队；2D游戏开发者；游戏开发新人；需要快速游戏原型的策划或开发。不推荐人群：喜欢研究技术实现多过机制玩法的开发者；图形学爱好者；3D游戏开发者；大型开发团队。GMS2 的很多功能沿袭自一代，因此一代用户稍加摸索就能上手，软件也内置详细的帮助功能，详细资料则还是推荐参阅官方手册（目前尚无中文版本），这里有一个在线版本（/source/_build/index.html），快速上手则推荐参考这里的官方教程（/hc/en-us/articles/-Getting-Started-With-GameMaker-Studio-2）。indienova 在 GDC 期间同 yoyogames 的官方人员取得了联系，得知他们有进入国内市场的计划，后续动态我们会继续保持密切关注。本文只是一篇粗略的初体验分享，稍后还会有 GMS 开发经验更加丰富的开发者在 indienova 分享他的心得体会，容我在这里先卖个关子不透露详情，大家敬请期待~想了解更多？请点击下方阅读原文
本文仅代表作者观点，不代表百度立场。系作者授权百家号发表，未经许可不得转载。
百家号 最近更新：
简介: 外星人，提供最全面的信息。
作者最新文章indienova 已经作为专题推出。&br&&a href=&///?target=https%3A///column/7& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&GMS 中文教程 | indienova 独立游戏&i class=&icon-external&&&/i&&/a&&br&&br&并且增补 GMS2 相关内容。&br&大家可以考虑升级了。&br&---&br&&a class=& wrap external& href=&///?target=http%3A///indie-game-development/gms-tutorial-1-introduction-and-installation/& target=&_blank& rel=&nofollow noreferrer&&GameMaker: Studio 中文教程 #1: 介绍与安装&i class=&icon-external&&&/i&&/a&&br&&a href=&///?target=http%3A///indie-game-development/gms-tutorial-2-2d-characters-walking/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&GameMaker: Studio 中文教程 #2: 2D人物行走&i class=&icon-external&&&/i&&/a&&br&&a class=& wrap external& href=&///?target=http%3A///indie-game-development/gms-tutorial-3-the-settings-to-build-the-scenes-of-your-game/& target=&_blank& rel=&nofollow noreferrer&&GameMaker: Studio 中文教程 #3: 游戏场景的设置&i class=&icon-external&&&/i&&/a&&br&&a href=&///?target=http%3A///indie-game-development/gms-tutorial-4-collision-and-occlusion/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&GameMaker: Studio 中文教程 #4:碰撞与遮挡&i class=&icon-external&&&/i&&/a&&br&&br&由 GMS 老手撰写的 step by step 详细教程，每周三持续更新。&br&&br&如果有需要解决的问题或者希望看到教程未来的方向也可以留言提出。
indienova 已经作为专题推出。
并且增补 GMS2 相关内容。 大家可以考虑升级了。 ---
Game Maker算是有年头的入门级2D游戏引擎。mac版好像可以输出xcode的project，用以制作iOS的游戏，待求证。最近一次更新新增加支持HTML5，还有尚在Beta中的新版本Studio将会支持跨平台开发，包括手机。一直以来，GM的定位似乎并不是大型商业开发，主要还是爱好者。近年借mobile的兴起，似乎动作大起来了。目前GM还算不上手机游戏开发的好选择。尽管有过一些好的作品，如Spleunky(Derek Yu的作品，一人完成，他甚至提供了完整源码下载，&a href=&///?target=http%3A///original.html& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/origi&/span&&span class=&invisible&&nal.html&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&，目前在制作XBLA版）。另外曾经看过有开发者表示，GM本身的还存在不少问题，造成了他们开发上的很多麻烦。所以严肃的开发，一般还是还是选用成熟一些的引擎吧，比如Unity，UDK等等。市面上还有一些类似的引擎，如Stencyl（基于Action Script），Game Salad等等，都拥有图形化的游戏逻辑编辑器，一定程度上降低了门槛。他们的价钱也是相当的便宜。&br&不过，GM有自己的脚本语言。上面提到的Spleunky就大量使用脚本来随机生成迷宫。任何严肃的开发，是不可能绕开手写代码的。&br&国内是不是类似的引擎就不知道了。
Game Maker算是有年头的入门级2D游戏引擎。mac版好像可以输出xcode的project，用以制作iOS的游戏，待求证。最近一次更新新增加支持HTML5，还有尚在Beta中的新版本Studio将会支持跨平台开发，包括手机。一直以来，GM的定位似乎并不是大型商业开发，主要还是…
已有帐号？
无法登录？
社交帐号登录