Touring::Camp - 卒業旅行キャンプ(1)

土曜日と日曜日を使い、私と二つ上である修士二年の先輩二人で、四万十川へキャンプに行ってきました。昔家族でキャンプをしたことがあるような…という程度の経験しかなかったのですが、先輩はキャンプや野宿を経験しているので、安心して行きました。ところが、これがとんでもなく過酷な旅になってしまったのです。

先輩らは朝早くに出発したのですが、私は午前中はバイトがあるため、昼の3時頃に出発することになりました。四万十川まで行くので、私は徳島市から池田へ行き、高知へ行って四万十へ行く、というルートを通ります。室戸岬経由だと遠いので、池田経由にしたほうが良いと先輩に言われました。

池田から高知市へ抜ける道では、大歩危と小歩危を通ります。オオボケってふざけた名前…と思いつつ。前日は、卒業論文の発表があり、その夜は打ち上げがあったため、バイトの時間も相当辛い物がありました。5時間睡眠でまだ酒が抜けきっていません。バイトが終わり、ここで本当は眠ってしまいたい状態でしたが、そそくさと荷物をまとめて出発します。ここで、バッグの中にゴミ袋かなにかで防水処置を施しておくべきだったのですが。

装備品は、寒くないようにスノボ用の靴下、ズボンは二重です。防御力をあげるため、普段は付けない足のプロテクタを着けます。すねから膝までをガードする大きめのプロテクタです。ウインドストッパーも装備し、出発します。

出発した時間では、まださほど寒くなく、むしろ少し暑いくらいでした。徳島市から国道192号線で池田まで行きます。途中、小腹が減ってきたりするとコンビニで軽く食料を買っては食べます。トイレに行きたくなればコンビニか、すいません、道ばたでやっちゃいました。山の中ですし、大丈夫でしょう。多分。

そして、大歩危に入り、コンビニでホットコーヒーを買おうとすると先輩から電話。現状報告ってとこですね。そんな電話をしていると、向こうの方でこちらを見ている人たち。最初は、私と同じくツーリングをしにきているのかと思いましたが、明らかにバイクが小さすぎますし、年も私より若い感じです。マフラーの音、走り方からするにヤンキーっぽいです。そりゃー見られちゃいますよね。はぅぅ。

コンビニを経ち、しばらく走っていると先のバイク集団が。ちんたらちんたら走るのが好きなんでしょうね、やっぱり。すぐに追いついてしまい、信号待ちで並んでしまいました。絡まれとうない！とか思い、スタートダッシュします。ふ、排気量が違うんだよ、と思いつつ、逃げます（笑）

走り続けていると、段々暗くなってきました。もう18時近く。いよいよ車の量も減ってきます。そんななか、前輪からキュルキュル…と異音が。ボルトがゆるんできたのか！？と焦りましたが、ボルトがゆるんできたのならこんな継続的に異音が鳴り続ける物なのでしょうか。ものすごい勢いでボルトが抜けようとしているのでしょうか。風切り音に混じって聞こえてくるので、実際かなり大きな音を立てているのかも知れません。不安に思いつつ、高知市まであと60キロです。（続く）

Laboratory::Complaint - 愚痴続きですが

プレゼン発表練習をする場所が狭いので、大丈夫かという質問を教授からもらい、私と隣の友人がかぶって返事をしてしまいました。

「少人数なら大丈夫です。」と私。

「たぶん～えー、学部生と～ん～・・・修士の先輩方が～数人なら～大丈夫だとぉ思います。」と友人。

私が2秒で答えた内容を、この友人は10秒くらいかけて言いました。

普段からこんな口調なので、イライラする事もしばしば。
頭がよろしくないんだと蔑んで我慢することに…ってひどいですか、そうですよね（苦笑）

Laboratory::Senior - 嫌われていく先輩

研究室で、一個上の代の先輩の話なのですが、卒業論文発表の時期が近づくに連れ、いよいよ学部生に嫌われていく先輩が一名います。

とにかくやたらお節介なわけです。世話好きなのでしょうし、世話をしてくれる先輩をありがたく思うべきなのかもしれません。ただ、行き過ぎるとありがた迷惑になり、さらにはこの先輩自体が嫌いになっていきます。

正直なところ、私はこの先輩の高圧的な口調が嫌いでした。嫌いになったのは、研究室に配属になって2ヶ月後ぐらいだったような気がします。私が徐々に嫌い始めていた頃、この先輩には私が「反抗的」な態度を取っているように見えたようです。「最近反抗的だから」というセリフをよく耳にした記憶があります。「反抗的」と言われると、あたかもこちらに否があるような印象を受けます。あなたにも否があるんですよ、と思い続けてきました。

そして、近々卒業論文の発表があるので、今度発表練習をするわけです。そのときには教授らも出席してくれるということで、作成したスライドの批評がもらえます。が、時期が時期で、その批評を受けたあと、スライドを修正し、修正した内容を教授らに見てもらえないのです。教授らも忙しいですから。

ですので、今度の発表練習の前にも練習をした方がいいと、この先輩は私に言ってきたわけです。いや、「いい」とかいう勧めるような言い方ではなく、むしろ「やれ」という強制的なものです。うーん、他の先輩の中には、何かを勧めるとき、むしろ「強制はせんよ」と最後に付け加える程の方もいるのに。

この先輩のしゃべり方は、あまり印象がよくない、と私自身感じていましたし、話を聞いてみると他の学部生も何人か同意見の様子。はっきりと「うざい」と言い出す友達もいます。この先輩の研究室内連絡メールを見ると、あまりにも冗長であり、個人的な感情や意見がちりばめられており、留学生が読んだら何を伝えたいのかが恐らくわからないという内容。不快を感じさせてくれます。

この先輩は本当に嫌い！と私自身思ったのですが、嫌いだから話さない、避ける、というわけにもいかないので、逆にこの人に従順になることにしました。おとなしく言うことを聞いてあげれば文句は言わないだろう、という考えです。極端な話、「はい」と答えておけば何も文句は言ってこないのです。

このような対応を、今まで取るようにしてきました。昨日の発表練習前の練習では、プロジェクタなどの用意が、思ったよりも遅く掛かってしまい、この先輩のいらだちが募っていくわけです。私からの言い訳をすると、直前までバイトだったため、研究室に来てから走り回って準備をしていたわけです。そんなに忙しなくなるなら他の人に頼めばよかったのですけどね。時間掛かるなら、もっと早めに準備するようにね、と普通に言ってくれれば良い物を。この人は「俺は時間にルーズなのが一番嫌いなんだよ」と言うわけです。この遠回しな表現に、私もかなりカチンと来ましたが、準備が遅くなった事実は変わらないので黙って聞きます。私に怒ってきますが、一言「すいません」とだけ言います。変に言い訳するとまたギャーギャーうるさいですからね。

実際、みなの発表練習に一番口をうるさくして言ったのはこの先輩でした。この先輩が一うるさいだろうなということは予想できていたので、隣の学部生の子と「適当に受け流しておこうな」と話してました。スライドの構成のことをよく突っ込んでくるのですが、この先輩が作るスライドのレイアウトもどうかと思う代物ですし。

ということで、正直この先輩には発表練習に来て欲しくなかったのですよね。この先輩は修士ですが、博士の先輩が来られるので、あなたは別に来なくても…とか思ったりするわけです。

話は変わりますが、バイト先でも徐々に嫌われていってる人がいます。バイト先の人やこの先輩をみていて、自分はそういう立場にならないように、っていうかなってないのかな、とか変に心配になってきたりもします。先輩の場合は自分勝手な世話好きという感じなので、反面教師にしようかとか思いました。

Game::Creation - ツクールXPでの製作順番

１と２で合計３作品作ったとはいえ、使い勝手が異なるRPGツクールXP。しかし、毎日使っているとすぐ慣れるもので、逆にこれだけしか機能がないの？というくらいです。そこのところはスクリプトを書いて補えっていうことなのでしょうけど。

製作するからには、やはり音楽や画像は自作物を盛り込んでみたいものです。しかし、そういうった素材作りに手を出していてはなかなかシナリオ作成が進まず、挫折してしまうような気がしてしまいます。

ということで、１や２は、製作中にシナリオを考えるという行き当たりばったりのような方法を採っていました（世界観などはあらかじめ決めていました）が、今回は先にシナリオの大筋を考えてしまうことにしました。

シナリオの大筋を考える際、登場人物を作ることから始めました。とりあえずこんな奴やこんな奴がいて、設定はこんな感じで、こいつとこいつのつながりはこうで…という具合に。それを元にシナリオを書いていきます。

大筋が三日で出来上がったところで、次はツクールを使って実際にシナリオを書いていきます。容量が１や２に比べて段違いにたくさん使えますから、気持ちよくシナリオが書けますね。マップ作成をしてはシナリオを書いて…の繰り返しです。

現在もシナリオを書いている途中ですが、これが終われば画像作成です。キャラのデッサンなどはすでに多少やってみたりして。画像作成しながら、戦闘システムのカスタマイズですね。スクリプトをいじくりまくって。

一作品を仕上げるのに、一年間･･･で出来ればいいなとかおもっています。

Game::Creation - RPGツクール

昨日RPGツクールXPをAmazonで注文してしまいました。なにやら2003はバグが多いので、2000かXPかでわかれる様子。XPはRubyを使ってシステムをいじくれるようなので、迷わずXPにしてしまいました。私は得意な言語は、Perl、次にC/C++という感じで、その次にRubyを持ってこようかこまいか、というレベルです。…つまりRubyは使ったことはありますが、Rubyで好きなプログラムが作れるかというとそうでもない程度です。一応掲示板のスクリプトや、人工無能スクリプトは書きましたが…Rubyを使ってしばらくしてから、オブジェクト指向なプログラムが書けるようになってきましたから、Rubyには微妙なイメージしか持ち合わせていません。

とはいえ、なにがしかの目標を持てば学習意欲は湧くものです。いいCGは描けなくともプログラミングはできます。XPを選んだ理由はこれだけだったりします。

RPGツクールというと、私の中では3で止まってしまっています。それ以後、何作か出ているようですが、よく把握していません。いわば1であるRPGツクール・スーパーダンテだったでしょうか。2はメモリーパックなどを使い、数作分保存可能だったり、かなで～るのコンバートデータを使えたり。当然のことながら、1よりも作成できるゲームデータは増量されていました。1を初めてみたときは、小学生ながらかなりの衝撃を受けたことを覚えています。

1も2も、自分なりのストーリーを完成させた記憶があります。2は友人にプレイしたもらったりもしました（ちなみに2部作（笑））。かなで～るで作曲し、コンバートデータをゲームのBGMに使う。中学生の頃ですね。去年の暮れ頃にもう一度プレイしようと思い、実家からスーパーファミコンを送ってもらい、2の方で作ったものをプレイしてみました。キャラの喋るセリフがくさいのなんの。3、4時間で前編、後編をクリアしてしまいました。しかしながら、まぁよく作ったもんだなぁと、過去の自分の作品ながら思ってしまいました。

3はというと、プレイステーションになりますが、高校の頃作っていて、途中で挫折しています。2と3とであれば、2の方が作りやすかったのと、若干ネタ切れだというのもあって止めてしまいましたね。3でも、相変わらずかなで～るを買って作曲してましたが。

大学生になり、パソコンでゲームを作りたいと思うようになりました。が、やはり一から全てを作るのは相当大変でした。何より素材がなく、自分で揃えなければなりません。大学の実験の一環で作成したゲームは何とか素材は作りましたが…パズルゲームでしたからね。RPGの素材を作るとなると相当大変です。

プログラムが作れても、素材がなければだめですからね。これまた挫折です。そんなこんなでしたが、最近ふと、RPGツクールのことを思い出しました。3でもう一度チャレンジしてみたいな、と。でも3をもう一度使うくらいなら、最新のやつを買えばいいかも、と考えました。最新のなら結構面白いことできるんじゃなかろうか、と。

そしたらRubyを使ってシステムをカスタマイズできるというではないですか。素材もデフォルトで大量にあるようですし。Rubyの勉強がてら、もりもりゲーム作ってみようかと思いました。

Math::ReccurenceEquation - 漸化式と特性方程式

現在、後一回の授業で契約終了となってしまう、家庭教師の生徒で浪人生の子がいます。理系の子なので、数学を教えているのですが、今のこの時期になるとセンターレベル以上の内容を教えることになります。久しくしまい込んでいた知識を、脳みその片隅から引っ張り出して授業を進めています。

私は数学が好きですが、専門ではないので得意不得意は往々にしてあります。中でも数列の漸化式は、高校の時に不得意な感があったので、今現在でも食わず嫌いのような状態です。等差数列や等比数列など、数列を習う初期の段階の内容は全く問題がありませんが。漸化式の何が苦手だったかと言いますと、特性方程式がちんぷんかんぷんだったのです。例えば、

an+1 = pan + q

という式がありましたら、まず次の特性方程式を解くでしょう。

x = px + q

…何でやねん！と思ってしまい、ここでしこりが取れず終いでした。特性方程式って何？と思ってしまい、しかし、多分こうしておけばオッケーなんだろう、と思うことにして済ましてしまいました。結果、漸化式を毛嫌いさせてしまうことになりました。

ふと、この漸化式の特性方程式について調べてみたくなって、調べてみました。
(http://yosshy.sansu.org/tokusei.htm)
結局の所、普通にanを等比数列と見なして解こうとしたときと、特性方程式を解くときと、やってることはそんなにかわらないのですね。やっと漸化式の特性方程式というものが腑に落ちました。

漸化式の特性方程式について調べようと思ったのは、自然対数の底について調べたくなったからです。というのも、家庭教師をしているとき、自然対数の底の話が出ると、大抵生徒は疑問な顔をします。得体の知れない物を見ているような気持ちなんでしょうね。かくいう私も、自然対数の底といえば、円周率のように特殊な数である、という程度の認識しか有りませんでした。実はネイピアの数という名前があったとは知りもしませんでした
(http://ja.wikipedia.org/wiki/%E3%83%8D%E3%83%94%E3%82%A2%E6%95%B0)。
必要に迫られたときに勉強すると、こういった知識も面白いと感じます。最近はプログラムを作る関係で、プログラムのアルゴリズムの勉強はもちろんのこと、グラフ理論の事も調べたりもします。大学の授業で習ったときは、大して指興味も湧かなかったですけどね。

Programming::C++::Overload - 演算子オーバーロードの嵐

templateをよく使うようになって、同時に演算子オーバーロードもよく使うようになりました。というのも、templateでジェネリックなアルゴリズムを書いていると、演算子オーバーロードしざるをえなくなってきます。単純に、Std.Plusを使うにしても、テンプレート引数に指定する型に対しoperator+ が定義されていなければ、Std.Plusをつかえません。

struct X
{
　X(int _x, int _y) : x(_x), y(_y) {}
　int x;
　int y;
};

void func()
{
　X a(0, 1), b(2, 3);
　int z = std::plus<X>(a, b); // これは不可能！
　...
}

ではStd.Plusを使わなければよいのでしょうか？使わなくて済むなら使わなくて良いでしょう。しかし、使わなければならない状況もなきにしもあらずです。

Std.Plusではありませんが、最近プログラムを組んでいて直面した事態があります。Std.Mapを使いたい状況になり、キーは組み込み型(Plain Old Type)ではなく、複数のデータメンバを持つクラスです。例えば次のようなクラスです。

class X
{
public:
　X(const std::list<std::string>& x, const std::string& y) : x_(x), y_(y) {}
...
private:
　std::list<std::string> x_;
　const std::string y_;
};

ここでStd.Mapのキーとなる型に要求される事は、Std.Less、Std.LowerBoundがつかえる事。要はoperator==()とoperator<()を定義すればいいことになります。

operator==()は簡単です。全てのデータメンバとを比較するメソッドを書いてしまえば良いです。

class X
{
public:
　X(const std::list<std::string>& x, const std::string& y) : x_(x), y_(y) {}
　const std::list<std::string>& GetList() const { return x_; }
　const std::string& GetString() const { return y_; }
　bool operator==(const X& obj)
　{
　　return (x_ == obj.String()) && (y_ == obj.GetList());
　}
...
private:
　std::list<std::string> x_;
　const std::string y_;
};


問題はoperator<()です。"小なり"を意味するわけですが、何を持ってして大小比較するのか？ということです。とりあえず上記の場合、文字列と文字列のリストがメンバとしてありますので、文字列x_と文字列のリストy_を全て連結した文字列とで大小比較する、ということを考えます。しかし、いちいち連結しているようでは非効率ですので、以下のようにします。

// class X内で定義する
bool operator<(const X& obj)
{
　if (x_ < obj.GetString()) {
　　return true;
　}
　else {
　　return (x_ == obj.GetString && y_ < obj.GetList()) ? true : false;
　}
}

Std.Listにはoperator<()が定義されていますので、上記のような比較が可能です。ここで、もしデータメンバy_が文字列リストstd::list<std::string&g;ではなく、テンプレート引数で与えられる、なにがしかのコンテナだったらどうでしょう。果たしてそのコンテナの型にはoperator<()は定義されているのでしょうか。

もし定義されていないとしても、begin()、end()メソッドが定義されており、イテレータが取り出せるならば、operator<()を次のように書き直せばよいことになります。

// class X内で定義する
bool operator<(const X& obj)
{
　if (x_ < obj.GetString()) {
　　return true;
　}
　else {
　　return (
　　　x_ == obj.GetString() &&
　　　std::lexicographical_compare(
　　　　y_.begin(), y_.end(),
　　　　obj.GetList()).begin(), obj.GetList.end()
　　　) ? true : false;
　}
}

Std.Lessは比較する対象となる型にoperator<()が定義されていなければつかえません。Std.LexicographicalComapreはあるシーケンスのイテレータを与えれば大小比較できます（詳細は
http://www005.upp.so-net.ne.jp/episteme/html/stlprog/algorithm.html#lexicographical_compareで）。

こうなってくると、operator<()だけでなく、operator==()内も、文字列のリスト同士を"=="で比較していましたが、Std.Equalを使って書き直したくなります。

　// class X内で定義する
　const std::string& GetString() const { return y_; }
　bool operator==(const X& obj)
　{
　　return (
　　　(x_ == obj.String()) &&
　　　(y_.size() == obj.GetList().size()) &&
　　　(std::equal(y_.begin(), y_.end(), obj.GetList().begin())
　　);
　}


このように、Std.Mapなどジェネリックなライブラリと複雑なクラスを混在させて使うと、どうしても演算子オーバーロードが必要となってきます。演算子オーバーロードは使いすぎるとソースの可読性が下がるとか下がらないとかという話をよく見かけますが、演算子オーバーロードを使うと様々な部品が上手い具合に組み合わさり、動作してくれますね。C++の強力さに驚嘆させられます。