2012年3月25日日曜日

vim-itunes開発メモ1

最近,VimからiTunesを操作するためのプラグインを作り始めたので,その際に参考にしたことなどなどをメモ.とりあえず,VimからiTunesを操作する方法について,MacとWinでの方法を.Uniteとの連携はまた今度書く.

こちらからダウンロード可能.
vim-itunes

neobundle.vimを使って ryutorion/vim-itunes でもインストール可能.
現状,:Unite it_track で曲一覧を表示して,選ぶと曲が再生できるくらい.
あとは,ドキュメントに書いてあるようにトラックを進めたりする関数も用意しています.

VimからiTunesを操作する方法

Mac OS Xの場合

Mac OS Xの場合,AppleScriptを使ってiTunesを操作できます.例えば,
tell application "iTunes" to play (track 1 of user playlist 1)

これを,AppleScriptエディタで実行するか,osascript -e '上の内容'とコマンドラインで実行すると,ミュージックの1つ目の曲が再生されます.

で,このAppleScript,日本語情報が少ない.英語でもなかなか情報が見つからない.既存のスクリプトの使い回しならいいんだけれど,Uniteと連携するために情報引き出したりとかやり始めると途端に分からなくなる.

AppleScriptについて

AppleScriptについては,次のドキュメントを参考にしました.


このドキュメントをざっと読んでおかないと,AppleScript書くの大変でした.
ちなみに,iThiefというコマンドラインからAppleScriptを使ってiTunesを操作するものがあるようです.作り終わってから教えてもらいました.Uniteと連携するのにどっちにしろ独自実装必要だった気がしますが,先に知ってたら無駄に苦労しなくて済んだかも,という気がします.

そして,AppleScriptを書く上でAppleScriptエディタの辞書は必須です.Command+Shift+Oで開いて,アプリケーションを選ぶとAppleScriptから呼び出せるコマンドやプロパティなどが書かれています.これを見ながら必要なAPIを探して叩きまくるわけです.

後はひたすら欲しい情報を得るために試行錯誤です.

Windowsの場合

Windowsの場合,JScriptを使ってiTunesを操作します.VBScriptとかC#も使えるようですが,諸事情によりJScriptを使います.これまた,JScriptからiTunesを利用する方法でまとまった情報がなかなか見つからない.とりあえず,WSHの本を片手に,次のドキュメントを参考にしました.

iTunes COM for Windows SDK (ダウンロードページトップなので検索してください)

一応サンプルスクリプトがついているものの,名前の大文字小文字とかどうなっているの,とか分からなくて,とりあえずif(API名)で存在を確認しながら徐々に作っていきました.
ただ,ある程度はAppleScriptと同じインターフェースを採用しているようなので,調べるためのキーワードはある程度分かっていたのが幸いでした.

以上
AppleScriptはなかなか面白いので,そのうちまとめを書いても良いかもなぁ.

2012年3月16日金曜日

ゲームプログラマとしての一年目のまとめ

もうそろそろ社会人,そしてゲームプログラマになって1年目が終わるので,この1年を振り返りつつ,まとめてみようかと思います.

入社前

とりあえず,入社前のスペックを整理.どこが成長したか分かる・・・かも?

Cは,プログラミング言語Cを一通り読んで,適当に書き散らしている程度.
C++は,ある程度有名どころの書籍には目を通している程度.
Javaも触れなくはない.Android関係も多少は弄った.
Perlは,joinとmapとgrepがあれば大概の処理が書けるよね,と思う程度.
JavaScriptは,Definitive Guideで勉強した程度.
C#は,プログラミングC#を買ってざっと目を通した程度.
シェルスクリプトは,書けなくも無いような.
PowerShellも本は読んだよ,という程度.
VBAは,15年くらい前にVB触ってたし何とかなるはずという程度.
サーバー関連は,研究室で管理者やってた程度.Apacheとかも軽く触れるよ.

Luaは,本は読んだ.
四元数は,本を買った.ついでに三元数なんて怪しい本も買った.
関数型言語は,LispもMLもHaskellも触ったことはあるけど,程度.
iOS関係も本のコードを書き写してみた程度.


ゲームプログラミングというか,描画関係は本を読んではいたけど,実際にコードを書いたことはほとんど無いという状態.DirectXのコードをすらすら書くことはできないし,OpenGLのコードもまともに書けない.ましてやシェーダーなんて.
こんな自分は,周りのゲームプログラミングなら任せろって人たちについていけるのか不安でした.

4月,5月,6月

まずは研修ということで,プログラマだけで社内のコードを弄り回して慣れる,という作業をしていました.CUIで生きてきた自分にとって,Visual Studioはコードを書くのが面倒でした.Vim使いたいんですけど,って言って導入許可をもらうまでが苦でした.

この頃は,既存のコードの使い回しだったので,描画関係のコードを弄ることもなく,純粋に言語の知識の差や,他人のコードを読んで理解する力が重要だったと思います.あと,人数が少なかったので,こういうことやったよ,と周りと話をしながらコードを弄っていたのですが,これが後で同じようなことをするときに役立ちました.

7月,8月,9月

新人プログラマだけでなく,新人デザイナーも交えての開発が始まりました.

このタイミングから,バージョン管理などのためのサーバー管理なども必要になってきます.基本的な知識があったため,最初の立ち上げをスムーズに行うことができて良かったです.また,プログラマ同士で開発していたときは,こういう手順でやって,と伝えるだけだった作業も,デザイナーにとっては難しいというのもあり,バッチなどを作るようになりました.この頃は,PowerShellを使おうという発想が無かったので,普通のbatで書いていました.PowerShellを使おうと思えていたら,効率も違っただろうなぁ,と思います.

この時既に自分は,知識の幅的に周りのサポート担当の位置付けになっていて,システム部分やバグ修正などを担当していました.そのためもあって,直接デザイナーとやりとりをすることも少なく,作ったものが使いやすいかといった聞き取りもほぼ出来ていませんでした.また,誰も聞いてこないから,とドキュメントの作成もあまり行えていませんでした.この点は非常に問題で,後々実際に問題になってきます.

開発が進んでいくと,どうしても自分だけでやっていては間に合わなかったりする部分が出てきた.そのタイミングになってようやくドキュメントを作成し,周りに仕事を投げるということをし始めました.ただ,ドキュメントを書くということにも慣れていなかったので,おせじにも読みやすいものができあがったとは言いがたいです.それもあって,周りもあまりドキュメントを読んでいなかったように思います.まぁ,そもそもドキュメントを読まない人も結構いた気がしないでも無いですが.

また,デザイナーに提供していたツールなども使いにくい面もあったのか,あまり活用してもらえていなかった気がする.どちらも新人ということで,何が分からないのか分からないという状態だったのかもしれないけれど,もっと積極的に話をすべきだったと思います.

9月以降

実際の開発チームに配属される.新人同士で馴れ合いになってしまってた部分もあった気がするので,実際の開発はそんなに甘く無いだろうな,と最初はちょっと緊張していた.
しかし,実際には非常に親切に色々と教えてくれるため,すぐにチームに打ち解けることができました.このチームに入れて良かったなと思っています.

この頃から,PowerShell Scriptを書くようになりました.バッチとして配布しつつ,何かを特にインストールしてもらう必要が無く,かつ楽にXMLを弄れる,という理由からでした.しかし,LINQを使い始めた今となっては,PowerShellよりC#でさっと書いた方が楽かも,とも思います.ただ,やはりいくつかのコマンドを組み合わせていって一つの作業を達成する,という手順になれているので,PowerShellも便利です.

更に,デザイナーに使ってもらうツールでGUIが必要,ということでC#でWPFを使ってみました.色々面倒でしたが,なかなかに面白い経験になりました.作ったものをデザイナーの方に見てもらうと,こういうデザインにした方が良い,などアドバイスがもらえて良いですね.

新人同士でやっていた頃と違うなぁ,と感じたのは,プログラマ同士よりもデザイナーとのやりとりが多いなぁ,ということです.デザイナーの方から,このツールが使いにくいんだけど,こういう風にできないか,と言った提案がしっかりと出るので,それに答えるためにこちらも色々と考えて,と良い循環ができている気がします.

最近

ちょっとずつやっていた描画周りの勉強も徐々に自分の中で消化できてきたのか,最近は何となくですが,描画関係の問題が発生したときも対処方法などに気づけるようになってきました.最近は,OpenGLの仕様を読んだりしています.過去から徐々に進めていって,変化を把握したり.仕様を読んだ方が自分の勉強方法には合っている感じです.

ただ,まだまだドキュメントを作ったりといった部分が後回しになりがちなので,今後は作業効率を上げていき,ドキュメントを作る余裕も作りたいです.

ドキュメントについて最近気付いたのは,プログラマはどうしても専門的な言葉で,かつ,そのツールの個々の要素の解説という形で説明を書いてしまいがちです.でも実際には,こういうことをやりたい場合は,こういう手順でやれば良いよ,と言う逆引き的なものを多く用意した方が喜ばれるようです.プログラマ的には個々の要素が分かれば,それを組み合わせてやりたいことが実現できることが分かるよね,と思ってしまうのですが,そうでは無いようです.

まとめ

入社前は,ゲームプログラマは描画関係のコードをバリバリ書いているんだろうなぁ,と幻想を抱いていました.実際には,そういった見た目の部分の多くはデザイナーの手によるものでした.描画関係のコードが書けた方が良いけれど,書けなくても十分仕事はあります.むしろ,描画しか出来ないくらいなら,他のことを色々できた方が良さそうな感じです.もちろん,描画関係の知識はあった方がデザイナーと話が通じやすくなるので必要ですが.

それと,需要は重要ということを学びました.具体的にやりたいことが出てくると,今まで知識だけだったPowerShellやC#も色々触ってみて,周りに提供できる程度のクオリティのものは作れるようになりました.あと,これVimでもっと楽にできないかな,と思うことが増えたので,Vimも色々と覚えた部分が増えた気がします.

デザイナーと話して,需要を見つけ,勉強して,提供して,改善案を話し合い,新しい需要を見つけ,お互いに効率を上げていく,という良い循環を作るのが重要だと思います.

ここまで書いて読み返して,主に内向き,開発内な話で,ゲームのおもしろさ的な部分,つまり外に向けての話が無いなぁ,と思ったのですが,ぶっちゃけそんなものは作ってみないと分からない部分が多いと思うのです.実際チームに入って,作る前はこれで良さそう,と話していたものが作ってみるとそうでもなく,変更するということは何度かありましたし.

ゲームプログラマとして大事なことは,早く試せる形にして,意見を吸い出せる状態にして,おもしろさの部分を育てられるようにすることだと思います.そのために,早く試せる形にするための技術が必要なんだと思います.必要な技術や知識は日々変わっていくので,必要になったら勉強する,とかじゃなくいつか必要になったときのために,日々色々な技術に目を向けておくのが大事だと思います.

そもそも,この技術は必要でこの技術は必要無い,なんて判断できるほどの知識も経験も持ち合わせていないのだから,やれることは何でもやった方が良いのです.

無駄に長くなりましたが,思い返すと一年を通して色々と成長できた気がするので,今後も精進していきたいと思います.

2012年3月13日火曜日

OpenGL事始め1

OpenGLを弄るのに毎回調べ直している気がするので,まとめておこうかと.

仕様を手に入れる

ちょこちょこと気になると本当にそうなの,と調べてしまうので最初から仕様を手に入れておく.幸いOpenGLは仕様が公開されている.

OpenGL最新仕様
OpenGL Shader Language仕様
GLUT仕様

一通り揃えてiPadへ.

とりあえず,最小の部分から始めていこうかと.環境は,Mac OS X Lionで.Windowsでの手順もそのうち書こうかな.寒く無くなって,デスクトップに向かう気が起きたら.

OpenGLでウィンドウを表示する場合,基本的にはGLUTを利用することになる.まずは,このヘッダファイルを開けるかの確認.
// main.cpp
#include <GLUT/glut.h>

int main(int argc, char * argv[])
{
    return 0;
}

このコードをビルドしてみる.

$ g++ -o main main.cpp

特に何もしなくても,Lionの場合開発環境さえ入っていればGLUTまで入っているみたい.で,GLUTの初期化をする.

// main.cpp
#include <GLUT/glut.h>

int main(int argc, char * argv[])
{
    glutInit(&argc, argv);
    return 0;
}

そして,ビルド.

$ g++ -o main main.cpp

今度は失敗.GLUTライブラリをリンクしていないから仕方無い.で,Mac OS Xの場合便利なのが,-frameworkオプションで名前指定するだけで色々よしなにしてくれるってところ.

$ g++ -o main main.cpp -framework GLUT

これでビルドが通る.実行してみてもちゃんと特に何も起きずに終わる.GLUTの仕様によれば,glutInit()を実行する前に,glutInit系(glutInitWindowSizeなど)以外のglutの関数や,OpenGLの関数を呼び出してはいけない,とのこと.で,glutInitにargcとargvを渡す理由としては,いくつかのコマンドライン引数をGLUT側で処理してくれるから,ということ.例えば、-iconicでアイコン化(最小化?)で表示される,とか.

で,次はウィンドウを作ってみる.
// main.cpp
#include <GLUT/glut.h>

int main(int argc, char * argv[])
{
    glutInit(&argc, argv);
    glutCreateWindow("hello");
    return 0;
}

ビルドして実行すると,何事も無かったかのように終わる.GLUT仕様曰く,glutMainLoop()に入るまではウィンドウの表示状態が変わらない,とのこと.ということで,glutMainLoop()を追加する.

// main.cpp
#include <GLUT/glut.h>

int main(int argc, char * argv[])
{
    glutInit(&argc, argv);
    glutCreateWindow("hello");
    glutMainLoop();
    return 0;
}

すると,ウィンドウを描画するための関数が設定されていないよ,と文句を言われる.このウィンドウを描画するための関数は,glutDisplayFunc()で設定する.というわけで,さっそく登録してみる.仕様を見ながら関数の型だけ合わせて空の関数を作って登録する.

// main.cpp
#include <GLUT/glut.h>

void display();

int main(int argc, char * argv[])
{
    glutInit(&argc, argv);
    glutDisplayFunc(display);
    glutCreateWindow("hello");
    glutMainLoop();
    return 0;
}

void display()
{}

しかし,これをビルドして実行しても,さっきと同じ文句を言われる.仕様を読むと,ウィンドウが作成されたときには,描画関数が設定されておらず,表示するまでに設定するのがプログラマの責任,と書いてある.つまり,glutCreateWindow()で作成してから,glutMainLoop()に入るまでの間にglutDisplayFunc()で描画関数を登録する必要がある,ということ.というわけで,順番を修正する.

// main.cpp
#include <GLUT/glut.h>

void display();

int main(int argc, char * argv[])
{
    glutInit(&argc, argv);
    glutCreateWindow("hello");
    glutDisplayFunc(display);
    glutMainLoop();
    return 0;
}

void display()
{}

とりあえず,これでビルドして実行すると,無事ウィンドウが表示される.
今日はこんなところかな.