My First Game Jam: Summer Editionに参加した
久しぶりにゲームジャムやりたいなと思ってIndie Game Jamsを眺めていたら，My First Game Jamっていう初心者向けのゆるそうなイベントを見つけたので参加してきた．
自分は以前にGlobal Game Jamに参加したこと（参照）があるので"My First Game Jam"ってわけじゃないんだけど，今回使ったprocessingでゲームを作るのは始めてだったのでまあ初心者ってことで．
My First Game Jamとは
- 初心者向けのゲームジャム
- ルールはかなりゆるい
- 期間は2週間
- 一人で開発してもよし，チームを組んでもよし
- 普通のゲームジャムと同様，開催直後に発表されるテーマに沿って開発する．
開催までの色々
一人で作るのも寂しかったので，普段から素晴らしい楽曲を書いているOtObOx先生をサウンド回り担当として誘った．「やる？」「やる」的な二つ返事でコトが進んだ記憶がある．フットワークが軽くて素敵だと思う．というわけで，自分がプログラミングとグラフィック担当，OtObOx先生がサウンド担当って感じでチームが決まった．
開催後前半
どんなゲームを作っていくか，SlackとTeamSpeak3で作戦を練った．今回発表されたテーマは"a spin on a popular story/myth"．スピンオンってなんだ．ググりまくった記憶がある．とりあえず日本の昔話系をリストアップした．自分はゲーム作りやすそうだったので因幡の白うさぎをゴリ押しした気がする．サメから落ちたらゲームオーバーみたいな．最終的に竹取物語ベースのシューティングを作ることになった．この時はまだ，月からの使者を迎撃する普通のインベーダ的なゲームを想定していたのであった...
開催後後半
1週間が経過した．「そろそろつくろっか．まあ1週間もあれば余裕っしょ．ハンデハンデ笑」という気持ちで開発が始まった．とりあえず2日間ぽちぽちドットを打ち，もくもくコードを書いて叩き台が完成．設計や実装の美しさを無視した，とりあえず動けばいいコードを乱暴に書き上げていく作業は，背徳感とスピード感があってとても気持ちが良かった．あとは楽曲や効果音を組み込みつつ，難易度を下げる方向に調整していった．
最終日は，時間ギリギリまでテストプレイのフィードバックでクオリティを上げていく作業をした．朝ごはんとして温めた角煮肉まんを電子レンジから取り出す暇が無いほどエクストリームだった．（テスターのみなさんありがとうございました！）13時の提出直前は，バージョンを一つ戻すかどうかで決断を迫られる体験ができた．git rebaseのコマンドをド忘れして激焦った．提出も，イベントのページと別でアカウントが管理されている都合，無事にアップロードできてるのか分からなくて激ヤバだった．
最後は，すっかり冷えきった角煮肉まんをもう一度レンチンしなおして笑顔でおいしく頂けたのでよかった．
できあがったもの
月から地球にやってくる使者のウサギから，かぐや姫を守るシューティングゲーム．前半1週間でOtObOx先生が「弓飛ばそう弓」と言ってた気がするが，実際に実装されたのは，タケヤリにロケットブースタをポン付けした星間ミサイルと，それに作用する重力場であった．射出後に加速するタケヤリミサイルを地球の軌道に上手く乗せて，飛来するウサギを迎撃していく．真上に打ち上げるだけだと，重力が作用してすぐに落下してしまうため慣れが必要．また，タケヤリの残弾数は地上のタケを刈り取ることで回復できる．WindowsとLinux対応．（Macは適当にprocessingでビルドして動かして下さい．）なお，開発途中で名前が"taketori war"から"taketori wars"に変わったため，表記ゆれが非常に激しい．あとdision氏のスコアがオーバーフローしたプレイ動画乗せておきます．
得られた知見
- 相手の作業風景を直接見れないのでリモート難しい．くだらない内容でも良いので連絡をこまめにとると，お互いの開発状況がなんとなくわかって安心．
- 少ないメンバーで迅速な意思決定ができたのでよかった．多くても3人とかがよさ気？
- 実際に作業する人手が不足している．自分がプログラミングとグラフィック両方やるのはちょっと厳しい．どちらかできる人がもう一人いれば...．
- ゲームの難易度は，開発者自身が実装の過程で慣れてしまうため，調整が難しい．自分が思っている以上に下げる，あるいはコアメンバ以外の人にテストプレイをしてもらう必要がある．
- 爆発エフェクトは白黒の点滅を入れると視覚的に威力が上がる．
- 適当なバネモデルで画面を揺らすと激しい肌触りになる．
- 早めの提出
ある日の環境構築
まとめ
linuxで，Radeon(HD5850)+xf86-video-atiでKMSが有効な状態でstartxを実行すると画面が真っ暗になって落ちる，そういうときは，カーネルパラメータにradeon.dpm=0を指定すると解決する場合がある．
ポエム
ある日のこと，メインの開発機のArchでyaourt -Syuでアップデートを行った後，dlangで書いている自前のプロジェクトのビルドを終え，実行したところ以下のエラーが出た．
X Error of failed request: BadMatch (invalid parameter attributes)
— tanitta (@trit_techne) 2016年7月2日
Major opcode of failed request: 42 (X_SetInputFocus)
GLまわりのエラーのようなので，とりあえず可能性として以下の原因が思い浮かんだ．
- グラフィックドライバまわりのエラー
- glfwのライブラリのリンクまわりの不具合
出力の前半にDRIまわりの警告があったため，まず，グラフィックドライバについて調べた．この環境では，プロプライエタリのcatalyst-testをドライバとして使用している．導入の際，要求される他のパッケージやデーモンの設定等で苦労した記憶があるため，このあたりが怪しいと判断した．そこで，オープンソースドライバであるxf86-video-atiによるcatalyst-testの置き換えを試みたが，パッケージの依存性の解決が難しそうだったため，予備として用意していた，グラフィックドライバやxorgを導入する前まで設定を済ませておいた別のパーティションのArchlinuxで，オープンソースドライバのxf86-video-atiを用いた新しい環境を立ち上げることにした．
ところで，今回問題が発生したメインの環境でcatalyst-testを使用していたのは，最初の環境構築の際に，他のドライバの，catalyst，xf86-video-atiでは上手くRadeon HD5850が動作しなかったためであり，また，今のcatalyst-testの導入後に何度か他のドライバでの動作を試みたが全て失敗していた．そのため，今回の試みも正直ダメな予感がしていた．
さて，さっそく新しい環境を整える．まずは，arch wikiにある通り，カーネルパラメータにnomodesetを設定してKMSを無効化，xf86-video-atiを入れる．ここまでは順調だが，その後，KMSを有効にした状態でstartxによりXWindowを立ち上げると，スクリーンに何も表示されなくなる（情弱感）．また，キーボードのcaps lockのランプも，普段は切り替えを行うと点滅するのだが，その反応もなくなってしまう．これまで何度か試みた際もこの挙動が原因でドライバの導入を諦めており，フォーラムを覗いても同様の症状のスレッドはxorg.cfgまわりに原因があるものばかりで，XWindowまわりが怪しいんだろうなーと予想していた．ところが，生成されたXorg.0.logを眺めていると，どうやらnomodesetでKMSが無効になった状態で起動を試みていることを示すメッセージを見つけた．これはnomodesetが指定されていた時に誤ってstartxを実行してしまった時のログであり，タイムスタンプを確認すると，KMSが有効な状態での起動に失敗する以前のものだった．つまり，それが上書きされずに残っている，ということは，startxのログが生成される以前で何らかの障害が発生している，あるいは，startxの処理の中でエラーログが生成されないような派手な落ち方をしている，この2つに原因を絞り込むことができる．そもそも，linuxではシステムがいきなり停止するような場合，ハードウェアに原因があることが多く，また，上で書いたcaps lockのランプが反応しなくなるのも，システムがコケていることを示し，startx後に画面に何も表示されなくなった際にハードに近い部分が不具合を引き起こしている説を補強する．
そこで，カーネルパラメータまわりについてフォーラムを検索したところ，radeon.dpmについて設定すると上手く起動する，とのポストを見つけた．このオプションは，"Dynamic Power Management"と呼ばれるGPUの使用率にあわせて動的に周波数と電圧を変更する機能についてのもので，radeon.dpm=0を設定するとあっさり動いた．最初にxf86-video-atiの導入を試してから2年近くが経過していており，正直なんともいえない気持ちになった．あと，余談だが最新のcatalystでcatalyst-testを置き換えるのも依存が大変なことになったが成功した．ただ，プロプラなので更新が遅く，さらに最近のオープンソースドライバも熟成してきたので，個人的にはxf86-video-atiの方に分があると思う．
無事に念願のドライバが導入できたところで，そもそもの今回の環境構築のきっかけを思い出したい．それは，自前のプロジェクトが実行時にグラフィック回りの警告とエラーが出た，というものであった．この新しい環境でコンパイラや依存ライブラリを整え，実行すると，警告は消えたが同じエラーが表示された．どうやら，グラフィックドライバとは別の，もうひとつの可能性であるglfwまわりについても考えねばならないらしい．ところが，こちらはドライバの問題よりずっとスムーズに解決したので，事の顛末は以下のツイートをもって代えさせていただきたい．
PKGBUILDを書き換え: glfwのsourceを以下のforkに指定して解決https://t.co/qKXoQJaLdq
— tanitta (@trit_techne) 2016年7月2日
これと同様の対応を元々の環境で行ったが，エラーは表示されず上手く動いた．早急にこのPRがmergeされることを祈る．
結局のところ，問題を解決するために新規に開発環境を立ち上げる必要は無かった，という話です．
Global Game Jam Sapporo 2016に参加した
夜にはレッドブルおねーさんが徘徊する会場で，初めて会う人達とチームを組んで，48時間以内にゲームをつくる，そんな素敵なイベントのGlobal Game Jamに，2ヶ月前，参加してきた．
きっかけ
GGJは去年あたりにツイッターで見かけて興味を持った．本当はその年のGGJ2015に参加するつもりだったが，自分のスキルセットが中途半端で見送り．それから一年が経過して，ある程度簡単な言語やライブラリ等を要求されても1周間くらいの学習期間が確保できればそこそこ使える感じになってきたので今回は参加することにした．
できたもの
GGJのサイトはこっち
ゲームとしてはローグライクっぽい方向を目指した．カーソルキーでロボットを操作して，バッテリーを取りながら右下のゴールに到達するとゲームクリア．デザインは，移動や敵との接触でバッテリーが減少するリスクと，マップに散らばるバッテリーを集めることで残量が増加するメリットとのジレンマが生じるデザインにした．
チームの決定
GGJ Sapporoでは，申し込みをする際，手元の開発環境と主なスキルセットをアンケートに入力して提出し，それを元に運営の方がチームを決定する．自分は普段Arch Linuxを使用しているため，共同で開発するとなるとクロスプラットフォームな何かに縛られてしまうのが不安であった．神頼みでアンケートを記入して提出，チームの発表日を待った．
チーム分けが発表されると，自分は「UNIX☆Webチーム」に配属された．キャプションには"OSS好きやオールラウンダーが織り成すUnix衆、ここに結成！ その可能性、外部からは予測不能！"と記されていた．
開発
今回はgithubを軸に開発を行った．全員が既にアカウントを所有し普段から使用していたためぴったり．自分は，作業のルートとなる，ゲームとしてギリギリ遊べるレベルの叩き台をマッハででっち上げる作業をした．プロトタイプを開発するのが昔から好きなので，この作業は本当に楽しかった．その後は，新機能の実装，バグ潰し，ドット絵をぽちぽち打つなどをしていた．他のメンバーについては，ちゃんとスタートからゴールまでたどり着ける迷路生成とゲーム機能，細かいバグのfixなどはyassu氏やnasa9084氏が，レベルデザインといくつかの効果音はhomomaid氏，ランキング等の処理を行うsinatraのバックエンドはmktakuya氏とtosiemon18氏，GGJ終了後も耳に残っていた印象的なBGMと効果音はmanzyun氏が制作．全員に良い具合にタスクが割り当たり，チームとしてガンガン進捗を叩き出せたのでスピーディーで楽しかった．
ドット絵は最近界隈でアツいらしいasepriteというエディタを使用．普通のペイントソフトには無いような，ドット打つのに特化した機能が沢山実装されている．購入に際して，Windows/Mac版で提供されるバイナリは有料だが，よく調べたら自前でgithubからcloneしてビルドする分には無料．正直購入する気満々だったのでdonateしたい．そのくらいオススメ．
会場の様子
自分のチームは部屋がひとつそのまま割り振られた（部屋によっては2チームで共用のところも）．部屋には電源タップが大量に用意されており，タップ持って行こうか迷っていたので安心．ネットワーク環境はそこそこ速かったので良かった．ciscoの機材が転がっており，運営のエンジニアの方曰く，チューンを煮詰めればまだ速度を上げられるらしい．
なお，毎晩レッドブルガールが出現し，缶を開封した状態のレッドブルがもらえる．そのため，背中に羽が生えた状態での作業を余儀なくされ，開発が大変捗った．ちなみに余談だが，それでも会場の自販機のレッドブルは売り切れになっていた．
まとめ
チームが最高で楽しかった．ぜひ来年も参加してみたい．
Linuxの自宅鯖に時報機能をつけてQoLのブチ上げを試みた
生活にリズム感が欲しかったので，自宅サーバのsystemdサービスとして動く，指定の時間にアラームが鳴るアプリをつくった．（ポモドーロの既存のタイマーアプリでも良かったんだけど，いつのまにかアプリのプロセスを消してしまったり，そもそもPC，スマートフォンをいちいち操作して立ち上げるのがめんどくさかったりで，イマイチうまく使いこなせていなかった）今のところ10時から22時までの間，0分と45分にアラームが鳴るのでそれを目安にして45分間作業を，15分休憩って感じで活用している．
とりあえず動いたので記事を書く．
中身
めんどくさいのでrubyで書くことにした．スケジュールを読み込み，mpg321を叩いてアラーム音を鳴らす．
指定の時間にコードを実行するため，systemdのタイマー機能を用いる．このへんの設定はsystemd/タイマー - ArchWikiを参考にして.serviceと.timerを書いた．
なお，リアルタイムタイマーの.timerでのn分毎に実行する設定は
OnCalendar=*:0/n
でできる．
cf. systemd timer every 15 minutes - Unix & Linux Stack Exchange
アラーム音
Windows立ち上げてDAW開いて色々するのがめんどくさかったのでブラウザで動くaudiotoolで3OSCのアナログシンセをいじって適当に作った．騒々しい音だと疲れるので，ゆるめに仕上げた．（audiotoolいろいろ遊べるので暇つぶしにオススメ） www.audiotool.com
future
- スケジュールとコード本体との分離
- googleカレンダーと連動させたい
memo
- 休憩を忘れて無駄に消耗してしまいがちなので，これで改善されてもっと進捗できればうれしい．
- 実生活をHackしていく系，QoLも上がるので良い．
- あと久しぶりに記事書いた．
オープンソースカンファレンス2015 Hokkaidoにちょっとだけ行ってきた
滞在時間20分
この後も予定があったので急いでいたため，適当に地図を見てたら道を間違えて迷子になった．ちなみに帰りも迷子になった．汗をかいて完全に濡れオタク． 展示ブースでは，どこかで見たことのあるかのんくん(@HOMOMAID)にハグされそうになった．ローカルさんの売り子？してたっぽい．元気そうでなにより．あとsapporo.cppなるコミュニティの方とお話した．つよそうだった．最後に，帰ろうとしたらえむけーくん(@mktakuya)から電話で呼び出しをくらってポメくん(@pome_11)とふっくん(@fk2763owl)とお話した．めちゃ楽しそうだった．
感想
OSCに参加するのは初めてだったけど，こんなにたくさんコミュニティがあるとは思わなかった．熱かったです．今後もし機会があったらまた参加したいかも．
まだSlackのサイドバーで消耗してるの？
Slackのサイドバーが邪魔だったしウィンドウを狭くしたら文字がはみ出てたので，そのへんを改善するChrome拡張を作った．
機能
Slackを開いてCtrl+Yでサイドバーを出し入れできる． ウィンドウ幅を狭くしてもテキストが自動改行される．
経緯
Slackのサイドバーが，どこからどうみても消せる機能を搭載してる雰囲気だったので，調べたら以下のページが出てきた．
Slack「Nope, not at the moment at least. Maybe in the future!」
実装まで待つのもだるいので作った．githubで公開した後，サイドバーまわりの挙動を修正するプルリクを@lempiji氏からいただいて，とても快適になった．感謝！久しぶりにgithubした気がする．
