这篇文章适合没有做过游戏开发，甚至是不太懂软件开发的朋友阅读，不过如果你是游戏开发者，也许读完也会有一些启发。
大家也知道，我算是一个成分比较复杂的人，除了做代码开发以外，偶尔也会录点游戏视频发出来。
这两天趁着纪念碑谷3的发售，我也录制了一套横屏状态下的全流程通关视频，然后发到了B站上。
正好，很多朋友好奇我是如何将这个竖屏的游戏转为横屏的，我也很想借此机会聊聊游戏开发中的一些问题，所以就有了这篇文章。
一、我是如何把竖屏的纪念碑谷改成横屏的？
这个部分的内容比较偏向于代码相关技术，如果不太感兴趣，可以直接跳过这一部分，但如果你能坚持看完，一定会有不少收获。
我这边采用的是安卓系统，因为IOS设备的限制太严格了，操作起来也确实不太方便，所以就尚且聊聊安卓这一块的东西作罢。
实际上，让一个竖屏的应用强制转为横屏显示的方法是很多的。
比如说，我们可以使用一些强制旋转屏幕的工具，你可以非常轻易地在各大应用商店找到这类应用。
不过有些可能需要你提供Root权限，这一块还是比较麻烦的。毕竟现在大多国产手机都已经不提供官方工具解除BootLoader锁了，想获取Root权限也是非常困难的。
实际上还可以采用另一个方法，那就是直接修改游戏的APK文件。
我们知道，不论是APK还是其他类型的应用安装包，实际上都是一个压缩包，因此只要能解压这个压缩包，我们就可以对里面的文件进行修改。
在APK当中，有一个非常重要的文件，那就是AndroidManifest.xml。
这个文件是安卓系统用来识别应用的配置文件，我们可以在这个文件当中找到应用的一些基本信息，比如说应用的名称、版本号、权限等等。
我们现在不妨把APK文件直接解压，然后用开发工具VSCODE打开AndroidManifest.xml文件。
咦，怎么回事，为什么全都是乱码？
这是因为在安卓项目打包之后，为了优化和减少文件大小，AndroidManifest.xml文件会被压缩成二进制文件，所以我们需要用工具将其转换为可读的XML文件。
这里我使用了一款非常流行的反编译工具，叫做APKTool。
如果你使用的是Linux系统，你可以直接在终端使用apt或者yum安装，比如：
sudo apt-get install apktool
当然，Windows下我也比较推荐使用Scoop这种包管理器安装，这样会比较方便，比如你可以直接在Powershell下输入：
scoop install apktool
安装好之后，我们就可以使用apktool来反编译APK文件了。
我们转到APK文件所在的目录，我的apk目录位于下载目录下，现在在终端输入：
apktool d C:\Users\用户名\Downloads\MonumentValley3.apk -o C:\Users\用户名\Downloads\MonumentValley3
这样就会把APK解压到同目录下的MonumentValley3文件夹中。不过值得一提的是，这个地方是不支持相对路径的，所以你需要输入绝对路径。
解压完成之后，我们可以在MonumentValley3文件夹中找到AndroidManifest.xml文件，现在用VSCODE打开这个文件，你会发现这次已经是可读的XML文件了。
这边再为大家简单介绍下xml文件的结构。
xml文件是一种标记语言，它主要由<标签名 属性名="属性值">内容</标签名>这样的结构组成，前一个中括号内的部分是标签的开始，后一个包含反斜杠的中括号内的部分是标签的结束，开始和结束以及之间的内容组合成了一个完整的标签。
每一个标签都是一个节点，节点之间可以有父子关系，也就是标签之内嵌套标签，例如<父标签><子标签></子标签></父标签>，也可以有兄弟关系，也就是同级标签，例如<标签1></标签1><标签2></标签2>。
标签也可以拥有属性，属性是标签的一些特征，比如说<标签 属性1="值1" 属性2="值2"></标签>。
在AndroidManifest.xml文件中，我们可以看到一些<activity>标签，这些标签定义了应用的一些活动，比如说应用的主界面、启动界面等等。
对于<activity>标签，我们可以在里面定义一些属性，比如说android:screenOrientation属性，这个属性就是用来定义应用的屏幕方向的，他有如下几个值（了解前几个即可，后面的不是很常用）：
unspecified：默认值，系统会根据设备的方向来决定应用的方向。landscape：横屏方向。portrait：竖屏方向。user：允许用户根据设备的传感器和设置来选择屏幕方向。behind：使Activity的屏幕方向与堆栈中的下一个Activity一致。sensor：根据设备的传感器来选择屏幕方向。nosensor：不根据传感器来选择屏幕方向，而是根据设备的默认方向，通常是竖屏，pad是横屏。sensorLandscape：根据设备的传感器来选择横屏方向（正向横屏或者反向横屏）。sensorPortrait：根据设备的传感器来选择竖屏方向（正向竖屏或者反向竖屏）。reverseLandscape：反向横屏方向。reversePortrait：反向竖屏方向。fullSensor：根据设备的传感器来选择全方向。userLandscape：允许用户根据设备的传感器和设置来选择横屏方向。userPortrait：允许用户根据设备的传感器和设置来选择竖屏方向。fullUser：允许用户根据设备的传感器和设置来选择全方向。locked：锁定屏幕方向。
观察AndroidManifest.xml文件，我们可以看到纪念碑谷3的APK拥有很多个<activity>标签，因此我们不妨利用VSCODE的搜索功能，搜索android:screenOrientation关键字，这样我们就可以找到所有拥有这个属性的标签了。
目前我们可以找到10个拥有android:screenOrientation属性的标签。
其中，62行的标签的android:name属性的值是com.unity3d.player.UnityPlayerActivity，这个标签就是纪念碑谷3的主活动，他的android:screenOrientation属性的值是portrait，这就是为什么纪念碑谷3默认是竖屏的原因。
剩下的9个标签的android:screenOrientation属性的值都是behind，这个值的意思是使Activity的屏幕方向与堆栈中的下一个Activity一致，也就是说这9个Activity的屏幕方向会根据堆栈中的下一个Activity来决定，而最终他们的屏幕朝向的值都会指向主活动的屏幕朝向。
因此，我们只需要修改62行的android:screenOrientation属性的值为landscape，然后重新打包签名APK文件，就可以让纪念碑谷3强制横屏显示了。
顺带一提，在Unity3D引擎中，文件->生成设置->玩家设置->安卓小机器人图标->分辨率和演示->方向->默认方向这个选项可以设置应用的默认方向，这个选项就对应着AndroidManifest.xml文件中的android:screenOrientation属性，不过这边只对应了几个常见的选项，毕竟其他的选项确实用的比较少。
不过，相比纪念碑谷2，开发商这次在apk当中加入了一些更加严格的防止篡改的措施，因此即便进行简单地进行签名打包，安装后也是无法正常运行的，后边还需要做很多的工作，流程实在是冗杂麻烦。
本身做这一块的事情就不太光彩，而且这一块也不是今天这篇文章的重点，因此我就不再继续展开了，大伙有兴趣可以去网上查找相关的文章自己尝试。
二、为什么游戏改为横屏后显示依旧正常？
你可能会好奇，分辨率修改过后，游戏画面不应该会被拉伸变形吗？为什么纪念碑谷3改为横屏后显示依旧正常呢？
首先明确一点，纪念碑谷这款游戏从初代到3代，一直都使用的是Unity3D引擎。
虽然这个引擎叫Unity3D，实际上他也可以做2D游戏，而且做2D游戏的效果也是非常好的。
在Unity引擎中，所有的视角都是由摄像机来控制的，摄像机的视角是可以自由调整的，比如说我们可以调整摄像机的位置、旋转、视野等等。
对于2D游戏和3D游戏，虽然摄像机的设置有所不同，但是原理是一样的，因为我们所处的游戏世界永远是一个三维的空间。
在2D游戏中，我们通常会使用正交投影的摄像机，这样可以保证游戏中的所有元素都是等比例的，不会因为距离远近而产生视觉上的变形。
在3D游戏中，我们通常会使用透视投影的摄像机，这样可以让游戏中的元素看起来更加立体，更加真实。
再回到刚才说的拉伸变形的问题，实际上如果我们修改了分辨率，影响的其实是摄像机对应的视口。
在Unity当中，不论是2D还是3D游戏，绝大部分的3D场景元素都是直接跟场景坐标系绑定的，因此他们的位置、大小、旋转等等都是相对于场景坐标系来说的，大概率不会因为摄像机视口的改变而产生变形。
因此，当分辨率从竖屏改为横屏时，我们可以看见在竖屏状态下我们所看不到的一些游戏元素。
然而，部分元素还是会因为摄像机视口的改变而产生变形，或产生位移，比如UI相关的元素。
以UGUI为例，UGUI是Unity3D中自带的、也是最常用的UI系统，我们需要在场景上放置一个Canvas，然后在Canvas上放置一些UI元素，比如说按钮、文本、图片等等。
Canvas是一个独立的2D渲染层，有三种渲染模式，分别对应着屏幕空间、世界空间和摄像机空间。
在屏幕空间下，Canvas的位置是相对于屏幕的，不会随着摄像机的移动而移动，但是会随着视口的大小改变而改变。
在世界空间下，Canvas的位置是相对于场景的，这个时候即便改变视口大小，Canvas的位置属性也不会发生变化。
在摄像机空间下，Canvas的位置是相对于摄像机的，改变视口大小，Canvas的位置属性会随着摄像机视口变化而变化。
在Canvas上的UI元素，大概率使用的是RectTransform组件，与普通的位置组件不同，这个组件是用来控制UI元素的位置、大小、旋转等等的。
每个使用该组件的元素都有四个锚点和一个轴心。
锚点决定了UI元素在其父容器中的位置和大小。当Canvas大小变化时，UI元素的位置和大小会根据锚点的位置和大小进行定位和缩放。
中心点决定了UI元素旋转和缩放的参考点。它以相对UI元素自身的比例（0 到 1 之间）设置，默认情况下中心点位于元素的中心（0.5, 0.5）。
一般情况下，我们会让Canvas处于摄像机空间或者屏幕空间，以此方式实现UI与视口大小的自适应。
在此基础上，设置好元素的锚点和中心点，我们就可以实现UI元素的自适应了。
比如说，图中这个按钮位于界面的左上角，不论我们将视口从16:9改为16:10，或是其他分辨率，这个按钮都会始终位于界面的左上角，并且宽高相对正常。
因此回到纪念碑谷3当中，你会发现，即便改为横屏，大多数元素位于世界空间下，因此并不会因为视口的改变而产生变形，而那些UI元素也非常完美地实现了自适应。
三、浅聊横屏后“正常”当中的“不正常”
机会难得，不如挖挖游戏的制作细节。
实际上，对于很多游戏来说，如果你执意要把竖屏改为横屏，最终得到的游戏体验可能并不会像纪念碑谷3这样完美。
作为一个踏入游戏开发领域尚且有一阵子的开发者，我可以向各位透露，实际上很多开发者会在这类游戏的开发过程中，把摄像机视口外的部分用来做一些“出戏”的事情。
比如说，我们会把视口外的区域当做缓冲加载区，把一些即将进入视口的元素提前加载到这个区域，这样可以减少游戏中的卡顿，实现优化。当你把竖屏改为横屏时，你会看见有许多游戏角色、物件等元素在视口外原地踏步，直到触发某些条件，才会进入视口。
又或者说，当前场景是加了一层背景的，而这个背景其实是一张图片，刚刚好能铺满，或稍稍比视口大一点，当你把竖屏改为横屏时，你会发现这个背景并不是无限延伸的，而是有一个明显的边界，这个边界就是这张图片的边界。
不论如何，在你强行将分辨率转换为游戏开发者未曾提供的分辨率时，上述的一些设计就会影响到游戏的体验。
在之前横屏游玩纪念碑谷前两作的时候，我并没有感受到这些问题，甚至可以说，游戏开发者在竖屏视口外还做了许许多多漂亮的设计，即便你将画面改为横屏，也不会显得突兀。
那么，纪念碑谷3仍旧是这样的吗？
是，但也不是。
实际上，在纪念碑谷3的许多关卡当中，你仍旧能看见一些竖屏状态下看不到的小细节。
比如说，第一关的第一个场景，在路径旁边还存在着两块礁石，这两块礁石即便是在iPad的竖屏状态下也是看不到的。
类似的设计比比皆是，这里就不一一列举了。
但是，你也会发现，纪念碑谷3的一些关卡在横屏状态下会显得有些“突兀”。
比如，如果你在横屏状态下观察第二关第一个场景的结尾，你会发现，城墙右下角明显缺了一堵墙。
又比如说，第五关的第三个场景中，视角移动到最上方时，可以看见左上角缺失了一块水体。
然而，在露出这个破绽之前，实际上这个场景中也存在不少竖屏状态下看不到的建筑物。
当然，这款游戏的场景设计师肯定不止一个人，但有可能的是，开发者联想到后续这款游戏可能会推出PC版，上架Steam平台，因此在场景中也设置了一些横屏状态下的元素。
又可能是因为工期太赶，或者是因为其他原因，虽然考虑到了以后会推出横屏版本的问题，但也遗漏或刻意不去处理一些细节。
但这并非是一种不好的做法，毕竟目前这款游戏本就不应该出现横屏版本，开发者没有理由，也没有义务去为我这种肆意魔改糟践他们的作品的人提供更好的体验。
四、总结
老实说，其实考虑但却没考虑周全的设计并不坏，反倒还符合软件开发当中的一些原则。
在软件开发当中，我们非常鼓励的一种做法就是保持扩展性，也就是说，我们在设计软件的时候，应该尽量考虑到未来可能会发生的变化，以便在未来的某个时候，我们可以轻松地对软件进行扩展。
开发者考虑到了横屏版本的可能性，因此在游戏中设置了一些横屏状态下的元素，这样在未来推出横屏版本时，就可以节省不少的时间，同样这也是对自己游戏作品的一种尊重。
在如今快节奏的生活中，有太多软件开发者急功近利，走一步算一步，产品生产速度大于用户体验，人人都在为了上级定下的不合理的发版死线加班加点，谁还会在意这些细节呢？
这或许也是目前我们在各类游戏奖项中，争不过其他国家的游戏的原因之一。
我们很难为未来铺路，很难为玩家着想，更是很难去尊重自己的作品。
又或者说，我们做的不是艺术品，不是作品，而是一种商品，一种靠无聊的信息差和短暂的刺激来吸引用户的劣质赚钱工具。
是时候停下来深思了，如果只是为了赚钱而去生产一些电子垃圾，来钱快的行业可比游戏开发多太多，为什么我们要选择踏足这个行业呢？
