ゲーム
このページではゲームの実行と関連するシステム設定に関する情報のみを集めています。GNU/Linux 向けの人気ゲームの一覧はゲーム一覧を見て下さい。
ゲーム環境
Linux でゲームを遊ぶための環境は様々なものが存在します:
- ネイティブ – Linux 向けに書かれたゲーム (大抵はフリーでオープンソース)。
- ブラウザ – この種のゲームをプレイするのに必要なのはブラウザとインターネット接続だけです。
- 専用環境 (ソフトウェアエミュレータ) – 他のアーキテクチャや環境のために作られたソフトウェアを実行するのに必要です (あなたの国の著作権法に注意)。詳しくはエミュレータのリストを見て下さい。
- Wine – 膨大な Windows ソフトウェアだけでなく、Windows のゲームの実行も可能にします。Wine ではゲームのパフォーマンスが下がらないため (むしろ高速に動作することもあります)、Windows で動作するシステム要件が低いゲームならば大抵は Wine でも動作します。ゲームごとの互換性の情報は Wine AppDB を見て下さい。
- Crossover Games – Codeweavers チームのメンバーは Wine の主要なサポーターです。Crossover Games を使うことでゲームのインストールや設定を楽にしたり、他の方法を使うのと比べて信頼性を高めたりすることができます。Crossover は有料の市販品ですが、開発者がコミュニティと対話できるように フォーラム が用意されています。
- DosBox – DOS エミュレータ。古典的な DOS タイトルを動かすのに使われます。
- scummvm – 多数のクラシックなアドベンチャーゲームで使われていた SCUMM ゲームエンジンのゲームをエミュレートします。対応タイトルの完全なリストは ScummVM ウェブサイト を見て下さい。
- ハードウェアエミュレータ – ソフトウェア環境ではなくデバイス全体をエミュレートします。著作権については同じです。仮想マシンを使うことで Windows 専用のゲームを遊ぶことができます。VirtualBox は 3D もサポートしています。Windows の KVM ゲストから OVMF による PCI パススルーによって直接ハードウェアを利用することも可能です。
ゲームの取得
ネイティブ
公式リポジトリや AUR からかなりの数が入手できます。Loki はいくつかのゲームのインストーラーを提供しています。
デジタル配信
- Desura — インディーゲームに特化したデジタル配信プラットフォーム。豊富なゲームがあると考えてよいでしょう (セキュリティやバグがあまり気にならないならば)。
- http://www.desura.com/ || desuraAUR[リンク切れ: パッケージが存在しません]
- Steam — Valve によって開発されている著名なデジタル配信とコミュニケーションのプラットフォーム。最近 Linux に (開発会社によって) 移植された有名ゲームが揃っています。Source (Half-Life 2) や Goldsource (HL1) エンジンのゲーム, Serious Sam 3, Brutal Legend, 多数の Humble Bundles のゲームやその他のインディータイトルなどを含んだ巨大なライブラリが存在します。
- https://store.steampowered.com || steam
- Steam under Linux
- linux ゲームカタログを見る
- Steam のタイトル全てがネイティブであるとは限りません。中には Wine を使って動作するゲームも存在します。
- The Humble Store
- lgogdownloaderAUR パッケージを使うことでコマンドラインから GOG タイトルをダウンロードすることができます。
- GOG.com が公式でサポートしているのは Ubuntu と Linux Mint だけです。サポートを求めるときはこのことを覚えておきましょう。たとえ Arch でゲームが動かせなかったとしても返金してもらうことはできません。
- ほとんどの GOG.com タイトルは DOSBox, ScummVM, Wine によってパッケージ化されています。
Java
- 多くの 4kb 以下のゲーム (中にはゲームデザインの名作もあります) が http://www.java4k.com にあります。
- https://www.pogo.com/ – 最大のカジュアル Java ゲームポータル
- The Java Game Tome - カジュアルゲームの巨大なデータベース
Wine
- Wine におけるゲーム (やその他のアプリケーション) の実行については Wine AppDB に情報が集積されています。
- カテゴリ:Wine も参照。
playonlinux を使うのが (特に初心者には) おすすめです。必要な依存パッケージが全てインストールされ、最初の起動時に Windows ツールを自動でダウンロード、ネイティブの windows アプリケーションが正しく実行されるように設定を行います。詳しくは、公式ウェブサイトを見て下さい。
ゲームの実行
特定のゲームや、ゲームのタイプによっては実行するのに特別な設定を必要としたり、または設定されていることが前提になっていることがあります。大抵のゲームは、何も設定をしなくても Arch Linux で動作し、コンパイル時の最適化によって、他のディストリビューションよりもパフォーマンスが出ることもあります。しかしながら、特別な環境を使っている場合、希望通りにゲームをスムーズに実行するために多少の設定やスクリプトが必要になるでしょう。
マルチスクリーン環境
マルチスクリーン環境ではフルスクリーンのゲームで問題が発生することがあります。そのようなときは、別の X サーバーを実行するのが一つの解決方法になりえます。他の方法は NVIDIA の記事を見てみて下さい (NVIDIA 以外を使っているユーザーも見る価値があります)。
キーボード操作
多くのゲームはキーボードの入力を横取りするため、ウィンドウの切り替え (alt-tab) ができなくなることがあります。
SDL のゲーム (例: Guacamelee) では Ctrl-g
を押すことでキーボードの占有を無効にすることが可能です。
また、sdl-nokeyboardgrabAUR[リンク切れ: アーカイブ: aur-mirror] をダウンロードすることでも SDL のゲーム中にキーボードコマンドを使えるようにすることができます。さらに、libx11-nokeyboardgrabAUR[リンク切れ: パッケージが存在しません] を使うことで X11 レベルでキーボードの占有を無効にしたり、libx11-ldpreloadnograbAUR[リンク切れ: アーカイブ: aur-mirror] で LD_PRELOAD
を使って特定の占有を止めるようにしてアプリケーションを実行するなど細かい制御をすることもできます。Wine/lib32 ユーザーは各 lib32 ライブラリにも気をつけて下さい。
別の X サーバーでゲームを起動する
上記のような場合だと、別の X サーバーを実行するのが必要もしくは望ましいかもしれません。二番目の X サーバーを実行することには複数の利点が存在します。より良いパフォーマンス、Ctrl+Alt+F7
/Ctrl+Alt+F8
を使ってゲームを"最小化"することができる、ゲームがグラフィックドライバーと問題を起こしてもメインの X サーバーはクラッシュしないなどです。新しい X サーバーは ALSA へのリモートアクセスログインと同じく、ユーザーは音声を聞くために audio
グループに入っている必要があります。
別の X サーバーを起動するには次のようにします (例として Xonotic を使っています):
$ xinit /usr/bin/xonotic-glx -- :1 vt$XDG_VTNR
さらに、別の X 設定ファイルを使うことでちょっとしたスパイスを振りかけることができます:
$ xinit /usr/bin/xonotic-glx -- :1 -xf86config xorg-game.conf vt$XDG_VTNR
別の xorg.conf を使う理由としては、メインの設定では、NVIDIA の Twinview を使って Xonotic のような 3D ゲームをマルチスクリーンの中央、全ての画面にまたがって、レンダリングしているのが考えられます。これが望ましくない場合は、二番目の X を起動してセカンドスクリーンを無効にした設定を使うようにするというのが良いでしょう。
Openbox を利用してホームディレクトリや /usr/local/bin
でゲームを起動するスクリプトは以下のようになります:
~/game.sh
if [ $# -ge 1 ]; then game="$(which $1)" openbox="$(which openbox)" tmpgame="/tmp/tmpgame.sh" DISPLAY=:1.0 echo -e "${openbox} &\n${game}" > ${tmpgame} echo "starting ${game}" xinit ${tmpgame} -- :1 -xf86config xorg-game.conf || exit 1 else echo "not a valid argument" fi
chmod +x
したら、次のようにしてスクリプトを使うことが可能です:
$ ~/game.sh xonotic-glx
マウス検出の調整
マウスの素早い操作が鍵を握るゲームの場合、マウスのポーリングレートを調整することで精度を上げられます。
OpenAL とバイノーラル音声
OpenAL を使っているゲームでは、ヘッドフォンを使用している場合、OpenAL の HRTF フィルターを使ってより良いポジショナルオーディオを得ることができます。有効にするには、次のコマンドを実行して下さい:
echo "hrtf = true" >> ~/.alsoftrc
または、AUR から openal-hrtfAUR をインストールして、/etc/openal/alsoftrc.conf
のオプションを編集して下さい。
Source エンジンのゲームの場合、HRTF を有効にするにはゲーム内設定の `dsp_slow_cpu` を `1` に設定します。設定しなかった場合は代わりに自前の処理がゲームによって有効にされます。また、ネイティブランタイムを使うように Steam を設定するか、または openal.so のネイティブランタイムのコピーをローカルコピーにリンクさせる必要があります。完全性のために、以下のオプションを使って下さい:
dsp_slow_cpu 1 # Disable in-game spatialiazation snd_spatialize_roundrobin 1 # Disable spatialization 1.0*100% of sounds dsp_enhance_stereo 0 # Disable DSP sound effects. You may want to leave this on, if you find it doesn't interfere with your perception of the sound effects. snd_pitchquality 1 # Use high quality sounds
Pulseaudio の調整
PulseAudio を使っている場合、最適な動作をさせるためにデフォルト設定から変更することができる部分がいくつかあります。
realtime プライオリティと負の nice レベルを有効にする
Pulseaudio はオーディオデーモンとしてリアルタイムの優先度で実行されるようにビルドされます。しかしながら、システムがロックアップする可能性があるというセキュリティ上のリスクのため、デフォルトでは標準のスレッドと同じようにスケジューリングされます。これを変更するには、まずユーザーを audio
グループに追加してください。そして、/etc/pulse/daemon.conf
の以下の行をアンコメント・編集してください:
high-priority = yes nice-level = -11
realtime-scheduling = yes realtime-priority = 5
編集したら pulseaudio を再起動します。
高品質なリミックスを使ってサウンドを良くする
Arch の Pulseaudio ではリミックスチャンネルにデフォルトで speex-float-0 を使っていますが、これはやや低品質なリミックスとされています。あなたのシステムに負担を増やす余裕がある場合は、以下の設定をすることでサウンドを良くすることが可能です:
resample-method = speex-float-10
ハードウェアバッファを Pulse のバッファリングに合わせる
バッファをあわせることで音の途切れを減らし、ほんの僅かですがパフォーマンスを向上させることができます。詳しくは ここ を見て下さい。
Cgroups
Cgroups はプロセスをグループでまとめてユーザースペースで優先順位を付けて、レイテンシーを最小限にすることができるカーネルのアジャストメントです。IO の優先順位や CPU の優先順位など、複数のファクターを調整することができます。Systemd は Cgroups を暗示的に管理することができ、多数のスレッドが実行しているシステムをスムーズに動作させます。systemd をインストールするだけでこの動作の改善が行われます。
CPU 周波数スケーリングの設定を確かめる
適切な cpu 周波数スケーリングドライバーを使うように正しく設定されている場合、システムはデフォルトの governor を Ondemand に設定します。デフォルトでは、この governor はシステムが CPU の 95% を利用しているときのみ、非常に短い時間だけ、クロックを変更します。この設定では、電力が節約され熱が少なめですむ代わりに、パフォーマンスにかなり影響を与えることになります。システムの governor をチューニングすることで、ダウンクロックするのをアイドル状態の時だけに限ることが可能です。詳しくは Cpufrequtils#ondemand governor を調整するを参照。
スケジューリングポリシーによってフレームレートやレスポンスを改善する
カーネルがタスクに優先順位をつけるのに適切なスケジューリングポリシーを設定することはほとんどのゲームで有利に働きます。しかしながら、デーモンの助けを借りない場合、この再スケジューリングは手動で実行するかポリシーごとに複数のデーモンを使う必要が出てきます。これらのポリシーはアプリケーション自身によってスレッドごとに設定されるのが理想的なのですが、全ての開発者がポリシーを実装しているわけではありません。なんとかポリシーを正しく使うための方法というのが複数存在します:
Wine プログラムの場合
wine-rtAUR[リンク切れ: パッケージが存在しません] はスレッドごとの基準によるスケジューリングポリシーを実装したパッチがあてられた Wine で、Windows の開発者が意図したスレッドの動作方法と同じように動きます。デフォルトのパッチはどちらかというとプロフェッショナルオーディオのユーザーを対象としており、ゲームを遊ぶためとしては手に余るところがあります。nice レベルが含まれ複数のポリシーを使用する、このパッチ を使用したほうが良いかもしれません。このパッチは Linux-ck でしか実装されていない SCHED_ISO
を使用し、あなたのシステムにサポートがない場合は、代わりに THREAD_PRIORITY_ABOVE_NORMAL
スレッドの renice を行うので注意してください。
Wine#CSMT パッチも参照。
その他の場合
スケジューリングポリシーを実装していないプログラムのために、schedtool というツールとそのデーモンである schedtooldAUR でタスクを自動的に処理させることができます。プログラムをどのポリシーに交代するのか編集するには、/etc/schedtoold.conf
を編集してプログラムを追加してください。
ポリシー
何よりもまず、スケジューリングポリシーを SCHED_ISO
に設定することで、プロセスが CPU の最大80%まで使用できるようになるだけでなく、できるかぎり遅延を減らすことにつながります。SCHED_ISO
を使うには Linux-ck が必要です。SCHED_ISO
は linux-ck でしか実装されていません。Linux-ck 自体にも遅延を減らす工夫があるので、インストールするべきでしょう。全てではなくとも多くのゲームで効果が得られます:
bit.trip.runner -I
Linux-ck を使用しない場合、代わりに SCHED_FIFO
を使うことができ、SCHED_ISO
よりも効果がある場合もあります。SCHED_FIFO
でアプリケーションがスムーズに動作するかテストして、もし上手く動作するようならば SCHED_FIFO
を使うとよろしいでしょう。ただし、SCHED_FIFO
にはシステムを餓死させる危険性もあるので注意してください。そのような場合には -I を指定しているところに以下を使って下さい:
bit.trip.runner -F -p 15
Nice レベル
次に、先に処理させる必要があるタスクを昇順に nice レベルを設定します。ゲームなど、マルチメディアのタスクは基本的に nice レベルを -4 にすることが推奨されています:
bit.trip.runner -n -4
コアアフィニティ
ドライバーがマルチスレッドするべきか、あるいはプログラムがマルチスレッドするのか、開発において多少の混乱が存在します。ドライバーとプログラムの両方がマルチスレッドを使用しようとすると、フレームレートが下がってクラッシュします。最近のゲームや、GLSL を無効にしないで実行される Wine プログラムなどがこの例に含まれます。単一のコアを選択して、ドライバーだけがプロセスを管理できるようにするには、-a 0x#
フラグを使います。# はコアの番号に置き換えて下さい。例えば、1番目のコアを使うには:
bit.trip.runner -a 0x1
CPU にはハイパースレッディングによって 2 または 4 のコアしか存在しないのに 4 あるいは 8 もコアがあるように認識されることがあります。その場合、仮想コア 0101 (1 と 3) を使うには:
bit.trip.runner -a 0x5
一般的なケース
高いフレームレートと低遅延を必要とするほとんどのゲームでは、上記のフラグを全て使うのが一番良い結果になります。ただし、アフィニティはプログラムごとに確認してください。ほとんどのネイティブゲームは正しい使い方を理解しています。一般的なケースのフラグ例:
bit.trip.runner -I -n -4 Amnesia.bin64 -I -n -4 hl2.exe -I -n -4 -a 0x1 #Wine with GLSL enabled
Optimus やその他の便利なプログラム
一般的に、ゲームが動作するのに必要なプロセスはゲーム自体のプロセスよりも上のレベルに renice されるべきです。奇妙なことに、Wine には reverse scheduling という既知の問題が存在し、重要なプロセスに nice レベルが高く設定されることがあります。そこで、スケジューリングポリシーを設定すると動作が改善します。Wineserver も CPU 全体を消費することはあまりなく、必要なときは優先度を高くする必要があるので、無条件で SCHED_FIFO
を設定したほうが良いでしょう。
optirun -I -n -5 wineserver -F -p 20 -n 19 steam.exe -I -n -5
別のカーネルの使用
標準の Arch カーネルは一般的な使用のためのベースラインとしては十分です。しかしながら、あなたのコンピュータに搭載されたコアが16未満で、主にワークステーションとして使っている場合、バッチ処理のスループットを多少犠牲にして Linux-ck を使用することで大幅なレスポンスの向上を得ることができます。自分でカーネルをコンパイルしたくないのならば、Repo-ck を追加して、このリポジトリに入っているカーネルを使うこともできます。事前に最適化済みのカーネルを使用することは、結果として生じる可能性のあるスループットのロスとの相殺に必ずなるので、あなたが使っているアーキテクチャに相応しいカーネルを選択するようにしてください。
BFQ を使う
BFQ は linux-zen や Linux-ck に付属している io スケジューラであり、シンプルになるように最適化されており、サーバー以外のワークロードに対してよりよい応答性とスループットを実現します。有効にするには、Linux-ck#BFQ I/O スケジューラを有効にする方法を見て下さい。多くのガイドでは SSD には noop や deadline を使うことが推奨されていますが、複数のスレッドがデバイスにアクセスしようとしたときに応答性に悪影響を及ぼすことがあるので注意してください。スループットのアドバンテージがどうしても必要というわけでもない限り bfq を使用するのがベストです。
参照
- LinuxGames - linux ゲームのニュース
- OSGameClones - オープンソースのゲームクローンリスト
- Free Gamer - オープンソースゲームのブログ
- FreeGameDev - フリー・オープンソースゲームの開発コミュニティ
- SIG/Games - Fedora の wiki にある OS/Linux ゲームニュースサイトとゲームの一覧
- live.linux-gamers - Arch ベースのライブゲームディストロ
- Gaming on Linux - アクティブな Linux ゲームニュースとソース、コミュニティ
- Unixgames - Linux ゲーマー向けの Q&A サービス。