Squad日本サーバー提供開始しました
お待たせしましたが、Squadの国内サーバーの提供を開始しました。
サーバー名は[JP]Jujiya Gamingです。皆さんよろしくお願いします。
なお、今のところ40人サーバーでの運用を行っていますが、今後スロットが埋まり続けるようなら増強を行う予定でいます。
しばらくは40人サーバーでお付き合いください。
詳細はCCG鯖のBlog(Squad国内サーバーの提供開始のお知らせ 「続報」 )にて確認を行ってください。
Squadの日本鯖を開始します
これは、Steam & PC Gaming Advent Calendar 2015の25日目の記事です。
唐突ではありますが、Squadの国内鯖を提供します。
契約は済んでおり、後は鯖屋さんの準備を待っている状態です。
準備ができ次第鯖の設定を行い提供に入ろうと思っておりますので、しばしお待ちください。
鯖名は提供開始のタイミングでアナウンスしようと思っております。
運営者について
私はゲーム鯖の鯖管の経験があるわけではないので、鯖自体は私が借り、それをCanned-Catfood Gamingさんにて運用して頂くということでCCGの管理者である銀猫さんにお願いしてあります。
鯖の規模について
40人鯖からスタートしようと思っております。Squadの人口が増えて手狭になった際には増やしていこうと思っております。
サーバー管理人と連絡をとるには
ltakeshiと連絡をとるには以下の手段が存在しています。どれでも適当なヤツを選んで連絡をください。
TeamSpeak3: ts3server://ts3.canned-catfood.com (CCG鯖)
Skype: Japan Squad Players
twitter: @ltakeshi
GNU/LinuxでのSteamの現状
これは、Steam & PC Gaming Advent Calendar 2015の21日目の記事です。
皆さん、GNU/Linuxでゲームしてますか?(2回目)
前回の更新ではGNU/Linuxでゲームマシンを組むための指針について書いてみましたが
今回はとうとうGNU/Linux(Ubuntu 15.10)でゲームってのはどこまでできるのかというところに迫ってみたいと思います。
承前
今回実験に用いたマシンのスペックは以下のとおりです。
CPU: Core i7 4790k
GPU: GTX980
MEM: 16G
SSD:
M.2接続(内部接続SATA) -> Windows
SATA -> GNU/Linux
基本的にマシンは同一で、インストールしているSSDがM.2なのかSATA接続という違いだけですね。
こういう環境で、WindowsとGNU/Linuxでどのような違いがあるかが今回の調査となります。
The Talos Principle の場合
まず最初に取り上げるのはThe Talos Principleです。
このゲームはSerious Sam 3: BFEと同じエンジンを使ってるパズルゲーですね。
Portalと似たような感じですね。
スペックの計測にはこのゲームのベンチマークを用いてみます。
今回の計測ではGNU/LinuxとWindows7(DirectX11)およびWindows7(OpenGL)で計測を行いました。
これにより、GNU/LinuxとWindowsというだけでなくてDirectX11とOpenGLの違いや、OpenGLでもOSによる違いなどいろいろな視点で見ることができます。
こんなやつですね。それぞれの設定と結果は以下のとおりです。
GNU/Linux
設定
結果
- benchmark results -
11:27:27 INF:
Duration: 60.0 seconds (5577 frames)
Average: 93.0 FPS (102.4 w/o extremes)
Extremes: 225.2 max, 28.9 min
Sections: AI=6%, physics=4%, sound=2%, scene=67%, shadows=15%, misc=5%
Highs: 437 in 2.7 seconds (164.9 FPS)
Lows: 849 in 15.5 seconds (54.9 FPS)
30-60 FPS: 10%
> 60 FPS: 90%
Windows DirectX11
設定
結果
- benchmark results -
Duration: 60.0 seconds (6318 frames)
Average: 105.3 FPS (109.6 w/o extremes)
Extremes: 188.3 max, 49.3 min
Sections: AI=9%, physics=1%, sound=1%, scene=68%, shadows=16%, misc=5%
Highs: 833 in 6.0 seconds (139.6 FPS)
Lows: 1154 in 14.5 seconds (79.4 FPS)
> 60 FPS: 100%
Windows OpenGL
設定
結果
- benchmark results -
Duration: 60.0 seconds (4511 frames)
Average: 75.2 FPS (79.1 w/o extremes)
Extremes: 208.7 max, 17.5 min
Sections: AI=6%, physics=1%, sound=1%, scene=77%, shadows=11%, misc=3%
Highs: 529 in 4.8 seconds (109.9 FPS)
Lows: 809 in 15.1 seconds (53.6 FPS)
30-60 FPS: 18%
> 60 FPS: 82%並べてみると結構面白い結果になりましたね。
瞬間的なFPSだけみるとGNU/Linux(164.0FPS) -> Windows7_DirectX11(139.6FPS) -> Windows7_OpenGL(109.9FPS)
といったようにGNU/Linuxが上回ってるタイミングがありますが、アベレージで見ると
Windows7_DirectX11(105.3FPS) -> GNU/Linux(93.0FPS) -> Windows7_OpenGL(75.2FPS)
といったような結果になりますね。GNU/Linuxもゲーム自体はOpenGLで動いてますんで、
OpenGLはGNU/Linuxのほうがスペックが出るようですし、DirectX11を使わないゲームかつGNU/Linuxでも動くものはGNU/Linuxでプレイしても面白いかもしれませんね。
Grid AutoSport
次に取り上げるのはGRID Autosportです。
このゲームは昨年でたGRIDシリーズの最新作です。今回もThe Talos Principleと同様にベンチマークを用いて計測を行います。
こちらにはWindows版にてOpenGLで動かすオプションはありませんので、単純にGNU/LinuxとWindowsでの結果だけです。
以下設定と結果です。なおこのベンチマークではログをXMLで吐くため、結果については必要なところの抜粋とさせてください。
GNU/Linux
設定
結果
<fps_race av_fps_ms="14.319108" max_fps_ms="8.930698" min_fps_ms="22.795486" av_fps="69.836754" max_fps="111.973328" min_fps="43.868332"/>
Windows
設定
結果
<fps_race av_fps_ms="7.807260" max_fps_ms="6.050583" min_fps_ms="10.620408" av_fps="128.085907" max_fps="165.273331" min_fps="94.158340"/>
こうやって並べてみると結果が一目瞭然ですね。このゲームにおいては、GNU/Linuxではかろうじて60FPSを超えてるのに対して、Windowsでは120FPS超えというわかりやすい結果になりましたね。とはいえ、レースゲーでとりあえず60FPS超えてるというのはプレイ事態には支障がないでしょうから、それ単体で見ると悪くない結果といえるのではないでしょうか。
結論
今回二つのゲームのベンチを回してみて、GNU/Linux+Steamでゲームをプレイするということの現状が多少見えたかなと思います。
実は数年前にも試したことがありそのときは非常に芳しくない状況だったため、今回もそういうことになるんじゃないかと危惧していました。
しかし、最近のゲームを動かしてみると、Windowsと遜色なく動くタイトルもあれば、そこまではいかないものの遊べるという意味では及第点を出せるタイトルもあり案外遊べるもんだなと思いました。
とはいえ、問題がないかといえばそうでもなく、今回blogには乗せませんでしたが、Portal 2は日本語版をインストールして起動させたら文字が一切表示されないというトラブルが発生し、言語設定をEnglishに変更したら文字が表示されるということもありました。こういう事態は普通にゲームを買ってプレイするという人には不親切極まりない状況であり、SteamOSなどを推していくのであれば対応必須ではないかと思ったしだいです。
今後の展望についてですが、数日前に発表されていたのですがAnnouncing Steam OS Support for SFV といったように格闘ゲームの定番であるストリートファイターの次回作がSteamOSでもプレイできるようになるという話であったり、Batman™ : Arkham KnightのMac / GNU/Linux版が2016年春にはリリース予定など、GNU/Linuxでプレイできるゲームタイトルは増える傾向にあるという状況であり、SteamOSが軌道に乗った暁にはさまざまなタイトルがプレイできる素晴しい未来がくるのではないかとひそかに期待しています。
GNU/Linuxでゲームをするなら自作PCがお勧め
これは、Steam & PC Gaming Advent Calendar 2015の12日目の記事です。
皆さん、GNU/Linuxでゲームしてますか?
ValveもSteamOSというLinuxディストリビューションを発表するなど、昨今のGNU/Linuxにおけるゲーム環境は日進月歩の勢いで良くなっていってます。
そこで、今回来るべきSteamOS時代に備えて、いかにGNU/Linuxゲーミングマシンを構築するためのパーツ選定方針などについてつらつらと書いていこうと思います。
書いてない項目は特に書くこともないところです。メモリや電源はOSに依存しませんしね。
CPU
INTELでもAMDでもお好きなものを選んでいただけたらいいかと思います。
ただし、出たばかりのチップセット(最近だとZ170)を選ぶのは非常にリスキーなので、
多少古めのほうが安心できますね。人柱上等な人は迷わず最新をどうぞ。
たとえば、私は数日前に新マシンを構築したのですが、それにはZ97チップセットを選んでいます。
M/B
お好きなものでよいかと。気をつけるのは、NICとオーディオのチップセットが何かというところですね。ディストリビューション名+チップセット名で検索かけて動作報告があるかを確認したほうがいいかと。
GPU
基本的にNvidiaを選択するのがベターだと思います。
理由はいくつかあるのですが、一つはドライバ周りが非常に恵まれていることですね。
公式のプロプライエタリのドライバだけでなく、MesaというOSSなドライバも存在しているため、間違いなく動くという安心が得られるのはありがたいですね。
注意点としてはGNU/Linuxディストリビューションにおいては、パッケージで提供されているプロプライエタリドライバはバージョンが古い可能性があるので
インストールする予定のGNU/Linuxディストリビューションのドライバのバージョンを確認するか、自分でNvidiaからドライバを落としてきて手動で入れるという選択を考える必要があります。
Radeonについては正直お勧めできません。理由はドライバが非常に貧弱というのが一番の理由です。
GNU/Linux環境下でゲームをプレイすることを考えるとOpenGLというのが重要になってくるのですが、AMDのプロプライエタリは少なくとも数年前までは非常に怪しかったようです。
詳しくはDolphinエミュレーターとOpenGLドライバー、栄光と恥という翻訳記事を読んでいただけるとわかりやすいかと。
GC/Wiiエミュレーターの開発者という、ちょっとグレーゾーンな開発者の話ではありますが、得るべき知見があるため一度読んでおくのがよいかと。
サウンドカード
ゲームにおいてサウンドというのは重要かと思います。FPSなどで足音で敵が接近してきたのを知るというのはよくある話でしょう。
そこでサウンドーカードはどうしたらいいのかというのはあると思いますが、正直サウンドカードを買うのはお勧めできません。
ドライバの対応状況が微妙な場合が多いためです。よってhttp://www.alsa-project.org/main/index.php/Matrix:Mainをよく見て、ほしいと思うサウンドカードが動くかどうかを確認して購入するようにしてください。
実践、ゲームの開発にコミットしてみるには
これは、Steam & PC Gaming Advent Calendar 2015の7日目の記事です。
大げさなタイトル書いてますが、要は洋ゲーの日本語化を行ってそれを公式に取込んでもらおうって話です。
尚、今回ある程度分かってる人に書いてますんで、技術的な用語の解説等はしませんのであらかじめご了承を。
承前
今回はBF2:PRを例にとって行います。
BF2:PRはlocalizationファイルをGitHubというところで管理していて、そこにpull requestを投げることにより公式に取込んでもらうことができるようになっています。
githubにて
こんな記事見てる人は全員持ってると思いますが、一応githubのアカウント作っておいてください。
realitymod/pr-localizationからレポジトリをforkしてください。
できたforkを自分のローカルにcloneを行います。今回は私のレポジトリを例にとります。
$ git clone git@github.com:ltakeshi/pr-localization.git
ローカル環境にて
まず、作業用ディレクトリに移動しておきます。
で、最初に行うのは
$ git remote add upstream git@github.com:realitymod/pr-localization.git
まずこのレポジトリの上流を指定しておきます。これが今後重要になってきます。上流なのでupstreamという名前で登録しておきます。
その後に作業用ブランチを作成します。
$ git checkout -b jp_trans
この場合はjp_transというブランチを作成し移動が行われます。
これを行った後にjapanese/*.utxtを編集していくことになります。
尚、注意事項等はREADME.mdに書いてありますので、よく見て編集してください。
日本語化tips
BF2はフォントがまじめに実装されていないため、一部使えない文字が存在しています。(ex: ギ)
そのため、イギリス軍という表記ができないため英軍という表記になっていたりします。
使える文字はBattlefield 2 - Battlefield MOD日本語化 Wiki*にて公開されていますので、参考にしてください。
ダメ文字を確認した後に、翻訳を行い、実際にその文字等が使えるかを確認するためにPRに反映させてみるというのもよく行います。
例えば、Project Reality\Project Reality BF2\mods\pr\localization\japanese/pr.utxtの
``撃たないでくれ！"となっているところを翻訳した文章に書き換えて反映させます。
ローカルのcoopを立ち上げて、確認してみてください。
ファイル編集後
ファイルを編集した後には
$ git commit -a
で、編集の結果をgitに登録します。
これは編集を何度か行うことになると思うんですが、そのたびに行っていくことになります。
commitのメッセージは書いておくと、後々自分が助かります。ProjectRealityの翻訳用ファイルはなぜかバイナリ扱いになってるので、gitでは編集履歴が追えません。
なので、commitメッセージでどこの翻訳をしたか程度でも書いておくと良いんじゃないかと思ったり。
ちなみに直近の私が書いたcommitメッセージはこんな感じです。
pull requestの用意
ファイルを編集し終わったら、pull requestの用意です。
まずは、jp_transブランチからmasterブランチへ移動します
$ git checkout master
そうした後に上流の更新をmasterブランチに取込みます。
$ git pull upstream master
そうして、もう一度jp_transブランチに移動し、upstreamの更新をjp_transにも適応します。
$ git checkout jp_trans $ git rebase master jp_trans $ git push -f origin jp_trans:jp_trans
この状態でもpull requestを投げられる状態ではあるのですが、これをやると先方さんに取込んでもらうときにトラブルになる可能性があるので、commitを一つにまとめます。
$ git rebase -i
これを行うとテキストエディタでどうしますかという問いが発生すると思います。
以下のような感じです(適当に再現してるので、多少違うと思います)
pick 674b8d6 New Japanese Translate add pick cf3ab69 LOCALIZATION: Merged the PR:Falklands localization files. pick 2ce45ed LOCALIZATION: Updated localization fb #4338 # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell
これの2、3行目のpickをsquashに書き換えてセーブするとcommitが一つになります。
これを行うとテキストエディタでどうしますかという問いが発生すると思います。
以下のような感じです(適当に再現してるので、多少違うと思います)
pick 674b8d6 New Japanese Translate add squash cf3ab69 LOCALIZATION: Merged the PR:Falklands localization files. squash 2ce45ed LOCALIZATION: Updated localization fb #4338 # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell
こうして 上流の最新状態 + 自分の編集した1commit な状態になったら、pull requestを行います。
pull requestのちょっと前に
普通はこのタイミングでpull requestするのですが、PRの翻訳ファイルはもう一手間かけることになります。
githubのWebサイトでjp_transのブランチを表示している状態で、``Download ZIP"でファイル一式をダウンロードしてきます。
zipファイルを伸張した後に、check-localization.exeを起動して、文字コードなどが正常な状態になっているかを確認してください。
これは文字コードのエラーが多かったために、確認のために公式で作成されたツールです。
github再び
とはいえ、まずrebaseしたのちに、それをpushしておきます。
$ git push origin jp_trans:jp_trans
その後にpull requestを行って取込んでもらってください。
まとめ
以上がPRを翻訳した後に、pull requestするまでに行ってる作業です。
案外簡単に取込んでもらえるので一度やってみてください。何か分からないことがあれば、@ltakeshiまで。
Fastladder
残念なことに、livedoor Reader と LDR Pocket をよろしくお願いいたします。【撤回】 livedoor Reader サービス終了のお知らせ｜LDR / LDRポケット 開発日誌 という事になってしまった。
LDR->Fastladder->LDRと使い続けて来た身としては寂しい限り。おまけに移行のお勧めとしてあげられてるfeedlyはとてもじゃないけど代用できる様なサービスじゃ無い。(単に同じような使い方が出来ないという意味で有り、別のサービスなので当然である。)
とはいえ、RSSリーダーが無いと困ってしまうので、OSS版のFastladderをRaspberryPiにインストールするという手を使うことにしたので、今回はそれの記録。
Rubyとかはインストールしてある前提でいく。
基本はSebupに書いて有るとおりなんだけど、多少変えてる。
$ git clone git://github.com/fastladder/fastladder.git
$ cd fastladder
$ vim Gemfile
Gemfile中の
gem 'therubyracer', platforms: :ruby
を有効にする。
その後に
$ bundle install
$ cp config/database.yml.sqlite3 config/database.yml
$ RAILS_ENV=production bundle exec rake db:create db:migrate
$ bundle exec rake setup # Setup files for development
といった感じで設定を行う。
その後で、
$ bundle exec rake secret
$ vim config/secrets.yml
で生成された文字列をconfig/secrets.ymlに設定して
$ vim config/environments/production.rb
で
config.assets.compile = false
をtrueに変えておく。そうすると、とりあえずは動く様になる。
#!/bin/sh
cd /path/to/fastladder/
sudo /path/to/bundle exec script/crawler --daemon -e production
といった感じのスクリプトを書いて、/etc/init.dに設置。
$ sudo update-rc.d crawler.sh defaults
でとりあえずは動く様になる。クローラーはかなり無理矢理っぽいんで、なんか良い方法無いかしら。
後はpassengerをインストールするだけなんで略。
とはいえ、ラズベリーパイでの注意点として一点。
タイムアウトの秒数は多めにしておくこと。ラズベリーパイだと反応に時間かかってタイムアウト食らいやすいので。
私は
PassengerStartTimeout 240
といった感じにしてます。120で試したらタイムアウト食らうこともあったのでそれくらいに。
そういった感じでうちのRaspberryPiでFastladder動き始めました。どうもクローラーの動きが怪しいので、当分様子見つつ場合によったらまともな鯖確保しようかなと。
ラズベーリーパイ
ちょいと前にラズベリーパイなるおもちゃを手に入れたので、それの初期設定メモ
OS(Raspbian)のインストールはマニュアル通り。インストールしてログインした後
$ sudo raspi-config
で初期設定。基本的にはパーティションの拡張とロケール、タイムゾーンいじっただけ。
次にするのはレポジトリの設定。http://www.raspbian.org/RaspbianMirrors を参考にして
$ cat /etc/apt/sources.list deb http://ftp.jaist.ac.jp/raspbian wheezy main contrib non-free rpi
こんな感じにしておいた。でもって、そのあとは普段使うユーザの作成とsudo使用許可
$ adduser USERNAME $ sudo vi /etc/sudoers
USERNAMEでログインできることと、sudo使えること確認したら
$ sudo vi /etc/passwd
で、
pi:x:1000:1000:,,,:/home/pi:/bin/bash
の行を
pi:x:1000:1000:,,,:/home/pi:/dev/null
に書き換えて、piでログインできないようにしておく。
これで最低限の設定は終了。
