Linux打包流程 for wine Appimage

ErrorEutopia

首先,感谢一下linuxgame.cn提供的标准化打包工具

再感谢一下shinnku.com的Gal

(笑)
请让我把工具准备好:
一个Linux发行版(WSL也可以),我选用的是KaliLinux
Appimagetool(Github上有)

以及来自linuxgame网站的打包工具链接{自带旧版本appimagetool以及wine依赖,但我们不需要}

记得下好游戏并成功运行在本机wine环境上

以及打包的灵魂wine (可从archlinux包仓库或者debian包仓库获得)

这里我们演示的是...... GINKA !

成品演示:

在开始之前,我觉得我得解释一下,Wine是什么

Wine （“Wine Is Not an Emulator” 的首字母缩写）是一个能够在多种 POSIX-compliant 操作系统（诸如 Linux，macOS 及 BSD 等）上运行 Windows 应用的兼容层。Wine 不是像虚拟机或者模拟器一样模仿内部的 Windows 逻辑，而是將 Windows API 调用翻译成为动态的 POSIX 调用，免除了性能和其他一些行为的内存占用，让你能够干净地集合 Windows 应用到你的桌面。

Wine 项目由 Bob Amstadt 于 1993 年发起，旨在寻求一种在 Linux 上运行 Windows 3.1 程序的办法。不久之后，Alexandre Julliard 开始接手领导 Wine 的开发，从此由他管理这个项目。多年以来，随着 Windows API 和应用为了适应新硬件及软件而不断演变，Wine 也一直不断发展来支持新的特性，移植到更多其他系统，并且更加稳定，提供着更好的用户体验。

通过确立一个宏伟的目标，在 2008 年项目到达 v1.0 之前，Wine 一直稳健地持续了 15 年之久，那是第一个稳定版。多个版本以后，虽然还有许多工作要做，但今天 Wine 仍然在活跃地开发着。并且有大约数以百万人计的人们使用 Wine 在他们所选择的系统上运行 Windows 软件。
开放源代码和用户驱动的

Wine 将会永远是自由软件。大约一半的 Wine 代码由志愿者编写，其余部分由商业公司赞助。特别是 CodeWeavers，出售着一个 Wine 的支持版本。

Wine 也是高度依赖用户社区的。用户自愿贡献时间在我们的 Application Database 上分享技巧和他们程序的运行测试结果，在我们的 Bug-Tracker 上撰写 bug 报告提醒开发者问题所在，或者在论坛上回复问题。
(来自wine官网链接)
(注:无论是最近苹果的游戏打包工具还是安卓的win模拟器,本质上都是wine哦~)

关于APPIMAGE

简单.

AppImage的核心思想是一个应用程序 = 一个文件。每个AppImage都包含应用程序以及应用程序运行所需的所有文件。换句话说，除了操作系统本身的基础组件，Appimage不需要依赖包即可运行。

可靠.

AppImage 格式是上游应用打包的理想选择，这意味着你可以直接从开发者那里获取软件，而不需要任何中间步骤，这完全符合开发者意图。非常迅速。

快速.

AppImage应用可以直接下载并且运行，无需安装，并且不需要root权限。
(来自appimage官网链接)

打包流程

事实上没什么可以讲的,请看图:

这个是软件入口,gamux将它指向了文件"$(pwd)/usr/bin/games"(好像还有一种是指向.desktop桌面文件的)

我们再来看看脚本内容

首先是config,这是一个配置文件

#!/bin/bash

###设置，根据需要修改###
#游戏名称,可以随意起，请务必使用英文，游戏名切勿包含空格及其他符号
GAMUX_GAME_NAME="GINKA"

#游戏所在文件夹的名称，默认为game
GAMUX_GAME_BIN_DIR="game"

#game文件夹中游戏执行文件
GAMUX_GAME_EXEC="run"

#是否启用steam-runtime，0为不启用，1为启用。若不启用，可以删除当前目录的steam-runtime节省游戏体积
#非x86游戏不支持steam-runtime
GAMUX_STEAMRUNTIME=0

#x86平台只支持在64位系统运行，不论游戏是32或64位
#arm平台只支持在arm64系统运行，不论armel、armhf或arm64的游戏
PLATFORM=amd64

###定义变量部分，无需修改###
HERE=$(cd "$(dirname "$0")";pwd)
cd "${HERE}"

GAMUX_GAME_READONLY="${HERE}/${GAMUX_GAME_BIN_DIR}"
GAMUX_GAME_DIR="${HOME}/.local/share/gamux/${GAMUX_GAME_NAME}"
GAMUX_GAME_DATA="${GAMUX_GAME_DIR}/data"
GAMUX_GAME_DATA_TMP="${GAMUX_GAME_DIR}/${GAMUX_GAME_NAME}_gamux_mountdir"

###自定义部分，补充默认脚本的不足###
function gamux_function1() {
#  if [ ! -d "${GAMUX_GAME_READONLY}/characters" ];then
#    tar zxvf "${HERE}/characters.tar.gz" -C "${GAMUX_GAME_DATA_TMP}"
#  fi
  return 10086
}

大佬写的注释挺详细的哈,我们应该向ta学习[笑]
基本上就是定义了游戏名称"GINKA",游戏所在文件夹"game",以及"game"文件夹中的可执行文件"run",其余的对于我们打包而言,意义不大(但是没有shell基础不要乱改哈)

我们再来看看games

#!/bin/bash

source "$(cd "$(dirname "$0")";pwd)/config"

"${HERE}"/game_run

fusermount -u -z "${GAMUX_GAME_DATA_TMP}"
rmdir "${GAMUX_GAME_DATA_TMP}"

我们先来看看第一行#!/bin/bash
这是设定一个解释器,这里是bash,你也可以设置为dash,sh,zsh等
往下看,这是一个经典的当前路径获取代码,获取当前脚本文件的父目录，注意 $0 为脚本执行时传入的脚本路径名,翻译过来就是:打开并运行当前脚本文件父目录下的config脚本,这是配置了环境变量
(关于${HERE},请查看config文件的 ###定义变量部分，无需修改### 部分)
下面两行是挂载与垃圾清理,不重要(其实就是懒,毕竟已经23:01了)

game_run文件,看名字就知道是干什么的了吧......

#!/bin/bash

# figure out the absolute path to the script being run a bit
# non-obvious, the ${0%/*} pulls the path out of $0, cd's into the
# specified directory, then uses $PWD to figure out where that
# directory lives - and all this in a subshell, so we don't affect
# $PWD

source "$(cd "$(dirname "$0")";pwd)/config"

if [ ! -d "${GAMUX_GAME_DATA}" ];then
  mkdir -p "${GAMUX_GAME_DATA}"
fi

if [ ! -d "${GAMUX_GAME_DATA_TMP}" ];then
  mkdir "${GAMUX_GAME_DATA_TMP}"
fi

UNIONFS="unionfs_${PLATFORM}"

"${HERE}"/${UNIONFS} -o big_writes,umask=0002,direct_io,auto_cache,sync_read,nonempty,uid=$(id -u),gid=$(id -g),cow "${GAMUX_GAME_DATA}"=RW:"${GAMUX_GAME_READONLY}"=RO ${GAMUX_GAME_DATA_TMP}

#自定义代码
gamux_function1

###############################################################################################

#启动游戏
cd "${GAMUX_GAME_DATA_TMP}"

if [ ${GAMUX_STEAMRUNTIME} -eq 0 ];then 
  "${GAMUX_GAME_DATA_TMP}/${GAMUX_GAME_EXEC}" "$@"
else
  "${HERE}/steam-runtime/run.sh" "${GAMUX_GAME_DATA_TMP}/${GAMUX_GAME_EXEC}" "$@"
fi

接下来就是我自己写的脚本了,位于game文件夹中的run脚本,

#!/bin/sh

export WINEHOME=$(pwd)
export WINEPREFIX=$(pwd)/C
#export WINEARCH=none
export WINE=./bin/wine 
$WINE game/run.exe
export WINEDLLPATH=$(pwd)/lib/wine/i386-windows/:$(pwd)/lib/wine/x86_64-windows/

非常简单的几句代码,分别设定了wine主目录的环境变量,wine c盘的环境变量,wine的架构(没有设定,为none),以及wine的可执行程序

$WINE game/run.exe (用wine运行game目录下的run.exe)

打包

打包之前要注意以下几点:
1.在此之前先运行一下games文件,检查game/C 文件夹是否有以下文件,没有就失败了(可以运行,但喜提 -1GB空间,你可以理解为这是优化)

2.一个game.png文件推荐256x256(不是也行)
3.编辑desktop

附赠desktop文件内容(以免损坏)

[Desktop Entry]
Name=GINKA
Exec=games
Icon=game
Type=Application
Categories=Game;
Comment=
Path=
Terminal=false
StartupNotify=false

开始打包

准备好appimagetool.appimage,在此打开终端,输入

ARCH=x86_64 ./appimagetool-x86_64.AppImage squashfs-root GINKA.Appimage

解释:
[ARCH=架构] [运行appimagetool] [参数1:所要打包的文件夹] [参数2:打包成什么]

出现以下场景就成功了

作者的小声哔哔:写这个时候才21:20左右,现在是23:34了,现在脑子一团糟,文章后期也开始偷懒,有什么纰漏请见谅

mikeo

支持（｀・ω・´）

ErrorEutopia

我文件刚删,有兴趣的可以逝世这个课题:
如果将game目录下的文件全部放在bin目录下,并将run文件改名为games,问:是否可以正常运行且C盘位置生成正常?

ErrorEutopia

文章有个Bug,C盘位置生成有问题,并且除了第一次会出现更新外,删除生成文件后是不会二次生成的

ErrorEutopia

因在不同发行版会出现细微BUG,即第一次会明文初始化(理想正常情况是不会的)会造成磁盘浪费,暂未找到解决方案及打包工具太过老旧,已在个别发行版出现不可运行BUG等种种原因,将文章归档作为历史参考

请耐心等待新版本的释出(这可能会需要很长时间?),感谢您的参与

真紅の資源討論組