アットウィキロゴ

ソルジャーへの道

いつまでもグダグダやってられないので、本気の本気で作品完成を目指そうと思う。




提出日(もとい納期)が7月3日。
あと1ヶ月でゲーム1本完成させるのか。
望むところだ、追い詰められてからが俺の本領発揮。



ともかく企画は固まっている。PCを初期化したからまずは環境の再構築からだ。




大学から再びVisualStudioを借りようと思ったら、研究室仲間の土井が2008ProのCDを持っていた。
なんでこいつがこんな高いもの持ってるんだ・・・。

しかしほしい。俺は新しいものに目がない。



「ちょっとそれ・・・」
「ん?」
「借りていい?」
「おお、いいよ」



アッサリと2008Proを手に入れた。

あれは土井のモノじゃない。教授が土井に貸したものだ。絶対そうだ。
決して変なルートで入手したものじゃない。



そう自分に言い聞かせながら帰宅。ノリノリでインストールを始める俺。
GW+豚インフルのせいでしばらく開発には触れてなかったな。




どっちも人を遊びに走らせる悪魔のウィルスだ。









その数時間後、俺は目が覚めた。

腕に大量の涎をたらしながら。




い・・・いかん。やっぱりこうなったか。


そそくさとパソコンの前に座る俺。
デスクのすぐ隣にベッドというポジションは最悪だと思う。

さっきからベッドが「おまえはここでとりあえず寝ていればいい」と催眠をかけてくる。



負けない。負けないぞ。







なぜか作業が進まないので風呂に入ってきた。


なぜ本気でやろうと思っても本気が出せないのか。
というか自分はいったい何をやっているんだ。

あれこれ試しながら作って、試しながら作っての繰り返し。


いろいろ考えてみると、プログラムを作る工程が乱雑すぎるのでは?という推測が浮かぶ。

企画書とか設計書とか仕様書とか、インターンシップのときに聞いたことのある単語だが、
実際自分がゲームを作るときはそういうのを一切無視してひたすら開発していた。



無論、完成したことがない。



昨日借りてきたゲーム作りの本を読んでいると、やっぱり企画書からプロジェクトが始まっている。


俺は面倒なのが大嫌いだが、もしかしてこの企画書とやらを作らないと、






いつまで経ってもゲームなんて完成しないんじゃないか・・・?






さっそくネットで設計書を作り方を調べてみる。









ふむふむなるほど。ゲーム作りの練習とかメンバーへの説明とかは後回しにして、
企画書を作る目的のうち、このプロジェクトで重要視される点を並べてみる。



再確認>>自己の能力の証明>>>実現性>>>>>記録



俺としては再確認が一番重要ではないかと睨んだ。

なぜなら、今までの俺は作っている最中に「あれはどうだ、これはどうだ」と
機能を追加したり消したりしながら作っている。


よくよく考えてみると、そんなんで完成する方がおかしいな・・・。



企画の内にキッチリと案を固めておく。

そうか俺は浮気性なんだな・・・。



次の自己能力の証明は、まあ就活ということで。




次の実現性。これも再確認と同様に、
「こんな機能がほしいけど作れるかな」と試行錯誤する段階がすでに開発中であり、
「頑張ったけどなんか作れなさそうだからやめよう」となるケースがある。


これでは無駄に時間を浪費するだけなのだ。


さて、企画書を作る重要性が、無知な俺にもようやくわかってきた。
なんだVisualStudioなんてまだぜんぜん使わないじゃないか・・・。




ではさっそく作っていこうと思う。





できたぞ企画書!

おおまかなストーリーを書けばいいんだよな。

あとシステムとか、ゲームの流れとか。
ちょっと仕様書との違いが把握できてないけど、これでよしとしよう。



さて次は仕様書だ。何を作るかを書けばいいらしい。
今度はおおまかではなく、しっかり完全に書かなければ。

メニュー画面ならレイアウトを図にしたりとか、
画像データはこれ使ってくださいとか、
ここでキャラがどう移動して、どのサウンドを鳴らすとか、
そんな感じでいいのかな。



      • 企画書とは量がぜんぜん違う。

脚本家よりずっと苦労しそうだ。
シナリオを完結させたかったけど、
体験版クオリティの域をこえることはできなさそう。


そこでふと疑問が浮かんだ。


俺は一人で作ってるから、



1日目
グラフィック→サウンド→プログラム 全部俺

2日目
グラフィック→サウンド→プログラム 全部俺

3日目
グラフィック→サウンド→プログラム 全部俺

4日目
...




こんな進行方式になるのか・・・?

それとも、



1日目
グラフィック 俺

2日目
サウンド   俺

3日目
プログラム  俺

4日目
グラフィック 俺




な、なんてことだ。一人ってこんなにハードだったのか・・・。
スケジュールなんて考えたこともなかったから気づかなかった。


すべての作業を自分でこなさないといけないから、大変なプレッシャーだな。

これで3Dアクションアドベンチャー作るとか・・・
ソルジャーを越えてコマンダーになれるぞ。





仕様書を淡々と書いてみるものの、どうも進まない。

俺はこういうキッチリしたことが苦手だ。
キャラ設定とかシナリオとか、こんなものは作りながら考えればいいと、今までずっとそうしてきた。

これを仕様書の中で完結させるなんて・・・。



しかし考えてみると、


今までのやり方だと、いわゆる「仕様変更」がほぼ常にある状態だったということだ。

プロジェクトにおいて仕様変更は、強制的にスケジュールを遅らせる危険要素である。
だから異様に進むのが遅かったのか・・・。


でもどうしようキッチリを想像すると何か生理的に手が止まってしまう。

どうすりゃいいんだ・・・。




おおう?
ゲーム制作の本を読んでみると、どうやらそこまで詳しく書く必要はないらしい。




なんとか仕様書ができた。といってもおおまかなシステムの構想と、人物設定とシナリオくらいだ。

まあこれだけでも少しは後が楽になることを信じ、改めて作業を開始する。



それから数時間後、俺はベッドの上で目が覚めた。


こうして悪魔が3匹に。



いろいろ苦労して作ったメソッドなのに、Seleneの中に同じものがあった。

こんな単純なのはないと思ってたけど、親切に作られてある。


ただこのライブラリのマニュアルを細かく読んでる暇はないので

「こんな関数あったらいいのに」


と思ったらまずはライブラリ内を探す、という認識は持っておこう。



GTA風の交通関係(パス上を自動走行する車)を作っている。

キリがついたらそのプログラムを公開しよう。

立て続けにやってると、さっき書いたばかりの計算式でさえ頭からすっ飛んでしまい、

「これどういう計算してんだ?笑」

となることがたまにある。それを明示的に書き留めておくためにこのサイトを作ったわけだが。



そんなことより衝突判定のアルゴリズムがやばい。



自宅のPCで車50台を総当たりで衝突判定させてみた。

お、おもい・・・。


俺はてっきりSeleneの衝突判定はすごく軽いものだと思っていたが、重い。

軽くするのはプログラマの技量に依存するのだ。このままではいかん。


そう思ってさっそく衝突判定アルゴリズムでググってみた。




なんだこれ。まったくわからん。


言いたいことは分かるけど何をどうすればいいか分からない。なにい・・・これが定番だと・・・!







どう頑張っても実装法が理解できなかったので、知恵をふるってこうしてみた。

「車の位置から半径x以内に入ったら衝突判定しる」


おお!軽くなった!けど3FPSくらい。



よく見ると今の条件式を書いてる場所がおかしい。衝突判定の準備をするコードの中に書いてしまった。

ということでやってみると・・・。







これはすごい。







30FPS以上も軽くなってるぞ。

こんなに軽くなったら逆に気持ち悪い。けど車同士が近付いたらちゃんと判定してくれてる。




うーん、これでいいのか。まあ理論的には正しいけど・・・。





なんかゲームというよりゲームツクール系を作ってるような気がしてならない。


ユーザがゲーム内のモデルをマウスで配置したり、セリフを入力したり・・・。





やってしまった。


データが・・・



なぜか古い方のデータを新しい方に上書きしてしまい、1日分の作業がパーになった。物事の繰り返しというのは何か結果があるから持続する。つまり結果を消してしまったのでむちゃくちゃやる気が失せた。ただでさえめんどくさがりの俺には大打撃である。





戦意喪失し、10時間ほど睡眠をとって再開。


プログラムの設計書なんて書いてないので、前の内容が思い出せない。ここで設計書のありがたみを知った。

とにかく大まかに記憶してる部分をもとに作り直そう。




すると、以前よりも出来のいいコードができた。

俺の中で言う「出来のいい」というのは、まとまっている、融通がきく、といった感じだ。あくまで俺の稚拙なレベルでだが。



とりあえずどっかで聞いた、サイヤ人は瀕死状態から回復すると戦闘能力が上がっているというのを思い出した。




睡眠をほとんどとらなくなった。

気晴らしにメタセコイアでモデリングしていたのがきっかけである。


そのときの気分に合わせて何かキャラクターでも作ってやろう、と思い立った。


そしてどっぷりハマってしまう。







1時間後、でかくて毒々しいクモが完成した。

ちなみにこのときの気分は眠気と焦りと、日の光を浴びていない陰険である。実におもしろい。


しかも完成度が高いときた。俺ってデザイナーでもいけるんじゃないか?と思って友達に見せると、



「うわあ、すごいねこのカナブン」


カナブンじゃないです、クモです。



今日の作業は研究室。広くてクーラーがきいてて画面も大きくて最高の環境!

というわけでもない。


部屋が広すぎるし、教授がいきなり顔を出してくるので集中できない。

それに自分の後方にドアがあって、たまに誰かに見られているのがすごく気になる。


ドアの窓にカレンダーでも貼っといてやろう。



現在使用しているゲーム開発エンジンSeleneのリリース版(旧版が進化したようなやつ)が近頃よく更新されているのでいじってみたが、やっぱり俺には何が何だか。

すごいなあプロは。プロじゃなくても一般人がこれを使っているだけでもすごいと思う。というかこれが分からない俺ってむちゃくちゃ底辺にいるということか。

「ああなんだこういうことか、簡単じゃないか」と、いつか言ってやりたい・・・。



今日は主人公のモーションを完成させ、イベントのカメラワークの動作を実装する予定。

モーションはこれまで幾度となく作ってきたが、走る動作が未だに不自然だ。人間観察を怠らないようにしよう。





主人公は超ミニスカ女子高生である。ちょっと足をあげただけでパンチラを拝めるくらいの。

なぜそうしたかというと・・・自分の好みもあるけど、まずモデルを変形させたときにスカートの一部が足にめり込んでしまう。衣類に物理を実装するなんて高度なことは俺にできるはずないので、ギリギリまでスカートの面積を小さくして違和感をなくしている。おとなしくズボンにしとけって?それは俺のプライドが許さない。

まあこれにしたって足を曲げる大きさによっては無意味なわけだが。何かいい方法はないものか。



今日はまず文字出力関連を実装。業界スタンダード(?)で1文字ずつ表示されるようにした。その手法をぐぐるといろんなサイトで解説があったにも関わらず、このライブラリの文字出力関数とどう組み合わせればいいのか分からない。結局グダグダと半日を費やしてしまった。


もうそういうのは極度の寝不足だったということで開き直ろう。あとはテキスト形式に羅列した文章を読み込んで、自動で流すようにすればOKだ。



次はパーティクルである。というかなんていう名称なのか分からない。ようするに剣にオーラが出たり、キャラの周りを気が覆ったりする演出のことだ。魔法使いがいるゲームには必須とも言えるが、俺のゲームに登場する予定はない・・・。


でもなぜか作りたかった。使わなくても作りたかったんだ。まあ強引にどっかに使うんだろうけど。



雨のエフェクトができた。

雨量と早さと範囲を調整できる。ちゃんと主人公の周りにだけ円状に降ってくれる。

#ref error :画像を取得できませんでした。しばらく時間を置いてから再度お試しください。

高校で数学3点とった俺がやっと人並みのものを作れたぞ。嬉しくて仕方ない・・・。

こいつはぜひ覚書しておかねば。というかプログラムについて誰も指摘してくれる人がいないから、主観的に評価するしかないんだよな・・・。



今日こそイベントクラスを完成させよう。

キャラの音声と、文章と、フェードイン、アウト、そしてカメラワーク。カメラが一番難しそう。ただ固定位置にポンポン切り替えるだけにはしたくない。

てかフェードってどうやるんだ・・・。



死亡フラグ



結局あれだな、俺たちの言うゲーム作りってのは、いかにゲームを作りやすくするかってことだ。



たった今気づいたが、かつて俺がここに書いてた覚書とほとんど同じことを書いてる人が既にいた。断然俺よりデキる人物みたいだ。うーむ負けてられん。



やっとこさソフトウェア企業から正式な内定をもらった。この企業とはホント長い戦いだった。
これで夏休みにスーツ着て汗だくにならなくていいと思うと、どれだけ気が楽か・・・。



char型のタイプライタ表示ってこんなにめんどくさいのね・・・。



定期試験も無事に終わり、あとは卒研のことでまだちょっとゴタゴタ中。



ああ卒研、卒研、卒研めんどくさい。

そんなことより俺もリリース版使いたい・・・。ってことで、


旧版サンプルの[OverPass]を今からものすごい勢いで移行して覚書してみる。



おk。とりあえず研究室行ってこよう。



だ~~!
リリース版は何なんだ、どうなってしまうんだ。



もうベータ版でいいや、という気になりつつあるこの頃。

SEKIHEKIというオンラインゲームをやってて、オートランという機能の便利さを改めて実感した。
お使いばかりさせるオンゲーは全部これ実装しろと言いたい。



このサイト、どーも編集しづらいな。俺の性格に合わない。
まだぜんぜん内容がないからどうだっていいが。いやもしかしてそのせいで内容が薄いのか・・・?



自作オートラン実装まであと7割といったところ。まだまだ先は長い。



あと6.5割。



やばいBorderlandsにハマった。面白いにも程がある。



やばいprototypeにハマっ


いかん、こんなことしてる場合じゃない。

というかベータ使ってるの俺だけなの?みんなリリースに行っちゃったの?
そっちじゃアニメーションの切り替えすら出来なかったんです。
出来なかったってのはseleneができないんじゃなくて俺の頭がアレという意味で。



もうこれじゃ就活は無理だな。潔くソフトウェア企業に収まるか。



研究室に4日ほど泊まってきた。
まともなベッドがないので疲れが半端なくたまる。



週末か…。
今日こそは家で寝よう。



帰宅。
眠いけど俺はまだやれる…。
愛しのベッドが俺に「おかえり、さあ来て…」
そんな誘惑には…のら…のら…



俺は確かに・・・生きてる・・・



そうだトップページに現在の進捗状況を画像で貼っとけば殺風景じゃなくなる。

と思ったのでこれからそうします。



てかVisualStudioのダイアログとか使わんでも、SeleneそのものでGUIを作ればいいんだよな。
とか考えてたら文字入力関連にIMEのAPIを使わないといけないのね。
さすがに俺には無理…か…。




いや、案外いけるかも。





無理だった





マルチスレッドやってるときに、

共有のリソースをいじる行にブレークポイント置くだけで重度のフリーズが起こるんだが。
いやリソース関係なく新たなスレッド内に置いたらフリーズするんだが。



Sleep(100);


でちょっとばかり間を入れてやるとブレークポイントが正常に使える。



送信・受信・描画で3スレッド用意して通信してみるが、
シングルコアとマルチコアで挙動が違うので同じようにしたいところ。



あと1台でクライアント複数起動するのと、違うPCで起動するのも挙動が違う。
モデルデータが表示されなかったり。なぜだ…。



もう12月か。



<stdio.h>

int Recv[10];


int main()
{
Recv[0] = 0;

int *Send = *&Recv;

Send[0] = 1;

printf( "%d", Recv[0] );

getchar();
return 0;
}

無意味だが、*と&を一緒に使えるなんて知らなかった。



1週間経っても熱が下がらん。
微熱なのに、意味わからん、なにこれ。


<stdio.h>
<vector>
<windows.h>


class PLAYER
{
public:
int a;

PLAYER( int Number )
	:	a	( Number )
{}
};

#define
MAX_COUNT 100
std::vector<PLAYER*> vPlayer;

PLAYER *Player[MAX_COUNT];


void main()
{

Player[vPlayer.size()] = new PLAYER(10);
vPlayer.push_back( Player[vPlayer.size()] );

Player[vPlayer.size()] = new PLAYER(20);
vPlayer.push_back( Player[vPlayer.size()] );



for( int i=0;i<vPlayer.size();i++)	printf("%d\n", vPlayer[i]->a);



for( int i=0; i<vPlayer.size(); i++)delete Player[i];
vPlayer.clear();

}



プレイヤーとか敵とかって、最初に最大数決めないとどうにもならんのかね。



ネットワーク対戦を実装中。

てかいろいろやりすぎて収拾がつかない。



パケットの送受信について分からないことがある。

最初から全員分のデータを含んだクラスをやりとりするか、一人分のデータをその場にいる人数分だけ連続でやりとりするかだ。

class DATA
{
int Number[PLAYER_MAX];
int KeyCode[PLAYER_MAX];

public:
DATA()
{
}
~DATA();
};

データを配列にするかしないかの違いなんだが、どうなんだこれ。

  • クライアントは最大人数分のデータを受信し、自分のデータのみを送信
  • サーバは一人分のデータを受信し、最大人数分のデータをクライアントへ渡す



サーバ、クライアント共にML115にメモリ2GとGeforce8400GSという中途半端なスペック。

自クライアントのキー入力情報を渡し、最大人数100人分の座標データその他もろもろが詰まったクラスを受け取って3Dモデルを描画するプログラムでどれくらいの速度が出るのか試したい。

なんてことはローカルな環境でできるはずない。
協力してくれる人を募りたいがどうだろう。
完成物ならともかく、作り始める状態から協力してくれる人なんて…。

近いうちに、1台で100個のクライアントを立ち上げてみよう。



できましぇ~ん。
6個立ち上げるだけでかなりきつい。
いやプログラム自体のFPSは60維持なんだが、起動するまでの時間がどんどん長くなっていく。



トップページにメールアドレスをのせておきますので「おまえそれ間違ってるぞ勘違い乙」とか全力で指摘しやがれ!



シーケンス遷移ってのを半分学んだ。残り半分は何が言いたいのかわからなかったので自己流。


BaseSequence *pSequence = new TitleSequence;
while ( pCore->Run( true ) )
{
     //内部でNULLが返されたらプログラム終了
if( pSequence->Update( pSequence ) == NULL )break;
}

ループ内にはこれ1行書くだけで済んでいる。
で、たとえばタイトルシーケンスを簡単に書くとこんな感じ。

BaseSequence* TitleSequence::Update( BaseSequence *pSequence )
{
if( pKey->GetKeyData( SELENE_VK_RETURN ) )
{
	delete pSequence;
	pSequence = new GameSequence;
	printf("ゲーム画面に移動します\n");
	return pSequence;
}
if( pKey->GetKeyData( SELENE_VK_ESCAPE ) )
{
	delete pSequence;
	return NULL;
}

return pSequence;
}

ベースとなるシーケンスを継承して仮想関数をオーバーライドだっけ。そこは全部参考書から学んだ。
切り替えの方法とかは思いつきでやってるので心配だ。
前のシーケンスを開放して、新たに作り直したポインタを代入してそれを戻り値として返す。戻り値がNULLなら終了と。




おかしいな、あれがないぞ、列挙型のTITLEとかGAMEとか。



もう今年も終わりか。
俺たちは来年何をやってるだろうな。

バリバリのゲームプログラマになってたらいいな。
それとも社会の波に翻弄されているだろうか。





みんなは夢とかあるか?





俺はプログラミングしているときいつも思う。

俺の技術はまだまだ幼稚、誰よりも劣っている。
今更頑張ったってしょうがない、と。

それで何かを挫折したことは少なくない。


基礎レベルより先に進めない病みたいな。


基本的に何にでも挑戦してきたが、全部基礎レベル。
何でもできる素質があるように見えるが、実際は何もできない。

つまり、今もその途中にあるのかもしれない。
プログラミングという分野で、また一定基準を越えるか否かの地点で挫折。


繰り返し。
何も変わってない。


だが、今までと違うことがひとつだけあった。

その分野の職についたこと。



社員が20数名。



必然。

必然の努力。


上を目指さない人間は必要ない。
そう言われた。


俺はもうその土俵に立つ手続きを終えたのだ。


その違い。

どれだけ違うのかは分からない。




頑張りたい。
プラス、頑張らないといけない。


この2つは、俺を変えてくれるだろうか?


もちろん変わらなければ無職になるだろう。

変わっていない俺が、IT業界のストレスに耐え続けられるはずがない。

体をナイフでそぎ落とされるかのようなストレス。
油断すれば、ゆっくりと、自分を失ってゆく。



極寒のような冷たく厳しい世界。




それがコンピュータの世界。

それが俺たちプログラマの土俵。




そこで生き抜くことが、俺の夢。




イヴ(笑)とか。



どういうわけか俺みたいなバカでもIMEを実装することができた。
まあチャット作るわけでもないから変換候補ウィンドウは考慮してない。

ウィンドウ生成せずにあれをやるとなると、

何かしらスプライトを用意して、
変換候補リスト取得して、
スプライトを表示する位置を決めて、
文字列の最大の長さ分だけスプライトを横に拡大し、
文字列の表示数分だけスプライトを縦に拡大し、
スプライトを表示して、
リストを表示して、
スクロールは・・・さすがに無しで、
リスト内で選択されている候補を網掛けして、
確定したらリストとスプライトを消す。


ああこんなこと考えるから実装したくなるんだよ。
これは何らかの種に共通して起こる性癖だ。



バックスペースで消すの忘れてたのでその実装に2時間費やす。
なんかいろいろあって編集中にそれを押すと編集文字列は全部消える妥協仕様に。



なんというか、別にここまでやる必要はまったくなかったんだけども、
メッセージを受け取らずに処理することに無理が出てきた(前述のような)ので何とかしたい。

これってゲットなんたらで簡単に取れるんかね。
ウィンドウは常にひとつだけ開いてる状態にしたいし。ダイアログがポンポン出てくるようなソフトウェアは、作る方は楽かもしれないけど使う方はなんかもうだるい。


てかSelene本体の方がいつまで経ってもビルドできねーよ!
ってことはメインのプロシージャが弄れないってこと・・・!?









    //--------------------------------------------------------- IME表示抑制
case WM_IME_SETCONTEXT:
       lParam = 0;
	break;

//--------------------------------------------------------- IME表示抑制
case WM_IME_STARTCOMPOSITION:
case WM_IME_ENDCOMPOSITION:
case WM_IME_COMPOSITION:
    return 0;

//--------------------------------------------------------- IME表示抑制
case WM_IME_NOTIFY:
    switch ( wParam )
	{
	case IMN_OPENSTATUSWINDOW:
	case IMN_CLOSESTATUSWINDOW:
	case IMN_CHANGECANDIDATE:
	case IMN_OPENCANDIDATE:
	case IMN_CLOSECANDIDATE:
		return 0;
	}
	break;
}




これは一体…。



なんだ、これってビルドしてdllを吐きだすためのものだったのか。
俺こういう知識ほとんどないんだが(理論抜きでやってきてるので)、
風邪ひいてるおかげか、人間冷静になれば知識の吸収って早いんだな。

ともかくこれで改造しまくったる!









まずはコアにメッセージを送る関数を外に出して、
Seleneにあらかじめ設定されているウィンドウプロシージャに新しいものをセット。
その中にメッセージ送信関数を書く。
これを書かないだけで致命的なエラーになるが、まあ作るのは俺だけだし時間もないってことで良しとしよう。

これでウィンドウメッセージに関しては完全オリジナルのものを実装できる。

とりあえずIME無効だったものを有効にするとこうなります。

imageプラグインエラー : 画像を取得できませんでした。しばらく時間を置いてから再度お試しください。

見るべきは左上。

海外のFPSで、特に数字とかTabとか押しまくるゲームだと幾度となくお目にかかる。
「てかこれコード数行書くだけで解決できるんだから、日本でこれが起きたゲームの技術を疑うわ~~~」って表面上だけで決めるのは良くない。

IME設定とか言語設定とか、
何かいろいろ開発側が考慮できないこともあるかもしれない。

      • しかし、Seleneのサンプル弄ってる限りではこの現象は起きない。

それは事実ではあるが、
設定を変えまくって弄ったわけでもないのだから・・・


リリースするに至っては、そういうところもよく検証しないといけないってことね。








ああああああもうだるい。
風邪菌まじで死んでくれ。
数日徹夜して弱ってるときに母親が風邪というタイミングの悪さ。
もろに移りました。
マスクしとけばよかった。
今までカップ麺だけの夜ごはんなんて無かったからな。
贅沢してたんだな。
俺こんなんでプログラマやっていけるのかな。



今年ももう終わりか。
なんと風邪のまま迎えつつある新年。


新しい生活が始まる新年。

楽しくても哀しくても、
朝日がやってくることに変わりない。

明日があるってのは、いいことだ。


自分にとっての明日はないかもしれないけど、
誰かにとっての明日はある。

そして思うだろう。
次は何をしようかと。

また新しいことが始まる明日。

俺も見たい。
みんなと一緒に。



まだ見たことのない明日。




それならいっそ、明日の明日も見たい。


がんばって、先に進みたい。


そこに光があれば、ラッキー。
なければ、また新しい明日を探すだけ。


それくらい単純でいいと思う。
俺たちは若いんだから。



俺たちって誰のことだ。


ここを見てる人が何歳かは知らないけど。


やる気がある人は誰だって若く見える。

外見がいくら汚くても。
輝いて見える。






だからがんばろう。







まだ見たことのない明日を目指して。







最終更新:2009年12月30日 22:53