Jewel-mmo開発日記

[開発ログ]タスクチェンジ

全面的にタスク処理を取り入れるべくオブジェクト指向で実装を試みるがなかなかうまくいかない。

まず難しいのがタスクチェンジ。経験上、シーンの切り替えくらいにしか使わないからタスクチェンジはいらないかと思ったが、例えばサッカーゲームのオフェンスとディフェンスの CPU の思考ルーチンの切り替えに使ったり、シューティングゲームの武器の切り替えにも使ったりできそうなのでやっぱり実装することにする。

• どうやって自分自身でクラスを差し替えるか
  • 実際には直接は無理なのでラッパー的なものをかます
• メモリ使用量の問題から旧クラスを破棄してから新クラスを生成しなければならない

で考えたのがタスク本体クラスを生成したときに内部でラッパー的なクラスを作成するようにして（……やっぱりラッパーという言い方は違うな）そのラッパーの方で本体を差し替えて……のような方法。これで一見うまくいったかと思ったが全然ダメ。はじめに生成したインスタンスが破棄されたことになるのはいろいろ困る。いろんなところが参照してるから。やっぱり本当のラッパーにしないとダメか。

--

いや、うーん。

小一時間考える。やっぱり武器が勝手に変わるのは変じゃないか？

class Man
  def init
    @wepon = WeponA.new
  end
  def proc
    at = @wepon.at
  end
end

武器が変わるタイミングがあるはずで、武器自身が自分の判断で持ち主の知らないうちに変化するとは考えにくい。

場面の切り替えは自身で判断して切り替わる実装を今までしてきたが、場面切り替えだったら、

class SceneLauncher < Task
  def init
    @scene = TitleScene.new
  end
  def proc
    klass = @scene.next_scene
    if klass
      @scene.delete
      @scene = klass.new
    end
  end
end

このように場面生成のタスクを設ければ解決する。場面は外から参照しないのでこれでいい。でもやっぱり、すぐには思い浮かばないが、外から参照されるものが勝手に切り替わるのが有効な場合もあるのかも知れない。その場合はインスタンス変数は維持したまま特異メソッドでメソッドを置き換えればいいケースなのだろうか……。つまりタスクチェンジは特異メソッドで可能な変化に限ると。

こういうの考えるの苦手なんだろうか。

[アイデア]ポーズ スローモーション リプレイ

ER の設計でこれらを意識しておかないといけない。 あらかじめ考えておけばポーズは簡単。 ER でもポーズの対象となるオブジェクトを共通の親にしておけば親を停止することで子はすべて停止する。

問題は格闘ゲームにあるようなリプレイ。リプレイを行いには常時何かしらのデータを記憶しておく必要があるが、何を記憶するかによってデータ量が大きく変わる。 ER ではデバッグ用に起動直後からの映像データをすべて後から再生できる機能を実装する予定だったので、それをリプレイにも使えるように考えておけばよさそうだ。

[blog]GameProgramTips

国内のコンシュマーゲーム開発固有のテクニックについて記述してあるページ。今までこういう資料を見たことがなかったのでかなり衝撃的。

自分はプログラムでは人の下についたことがないので、こういうテクニックは間接的にしか知らないが、やっているうちに自然とこういうスタイルにはなっていた。今考えてみると PS のサンプルソースをハックして身につけたものだったのだろうか。

大手の実装を見たことがないのでたいへん勉強になる。

特にタスク。即時復帰と明確な実行順序は必須の概念。こういうのを見ると ER の設計もこの点を自然と意識してはいたが、まだまだ甘いと実感。 ER をコンシュマー機で使うことも踏まえて設計することにしよう。

このページで紹介されているテクニックはアセンブリ言語での開発していたころに生まれてきたものだろうが、いまだに使える。データ構造と実装が明確なので、曖昧に見えるオブジェクト指向よりも、自分にとってはよっぽど扱いやすいのかもしれない。

オレに扱いやすいなら他人にもわかりやすいはずで、こういう至極現実的なノウハウが日本のゲーム開発力を支えているのだろう。

[パソコン]プログラミング

（プログラミングカテゴリがほしい）

最近やっとオブジェクト指向がわかってきた。 5 年くらい前からオブジェクト指向に取り組んでいたのだが、オブジェクト指向とは何かという問いには答えられなかった。今でも答えられないのだが、あと少しというところまでは来ている気がする。

今後勉強していきたいのは XP とか。 XP はまったく勉強したことがない。 特にテストとリファクタリングに興味がある。 最近はここでのゲーム開発に DB を使うようになってきたので DB を使ったテストなどもできたらいいなと思うのだが、さっぱりわからない。

デザインパターンは難しそうだからやらなくてもいいだろうか。

[開発ログ]サッカーゲーム

とりあえず ER のクライアントとして暫定的に書き始める。 オブジェクトの生成に関してはだいたいこれでいいだろう。 あとは当たり判定とか、移動処理をもっと深く考えないと。

@er = ER.new 'localhost', 9999
@screen = ER::Screen.new @er, nil, 640, 400

BALL_POSS = [[0,0,0]]
GOAL_POSS = [[0,0,-200], [0,0,-200]]
MAN_POSS = [
  [-100,0,-100],
  [   0,0,-100],
  [ 100,0,-100],
  [-100,0, 100],
  [   0,0, 100],
  [ 100,0, 100],
]

@balls = []

@goals = []
@mans = []

BALL_POSS.each do |pos|
  ball = Ball.new @er
  ball.position = 0,0,0
  @balls << ball
  @screen.add_obj ball
end

GOAL_POSS.each do |pos|
  goal = Goal.new @er
  goal.position = 0,0,0
  @goals << goal
  @screen.add_obj goal
end

MAN_POSS.each do |pos|
  man = Man.new @er
  man.position = pos
  man.start_autorun
  @mans << man
  @screen.add_obj man
end

@balls[0].a = [0,-1,0]
@balls[0].v = [0,10,0]

600.times do
  @screen.loop_proc

  (@balls + @mans).each do |o|
    o.local_proc
  end

  @goals.each do |o|
    if o.hit? @balls[0]
    end
  end

  @er.sync
end

[生活]風邪

仕事を休む。こんなに辛いのに平熱とはどういうことだ。

[アイデア] ER のテスト用にサッカーゲーム

とりあえず、ただ考えるより作りながら考えたいので、まずはサッカーゲームでも作ってみようかなと。

すごくシンプルなもので

• フィールドがある
• 2 つにグループ分けされたキャラクターがフィールド上に存在する
• キャラクターは円柱で当たり判定を行う
• キャラクターは勝手に動く
• ボールがひとつ、ゴールが 2 つ
• キャラクターがボールに体当たりするとボールが動く
• 壁があってボールはフィールド外に出ない

ざっとこれくらいの仕組みがあればまぁゲームっぽく見えそうだ。

5 対 5 にすればフットサル。

[るびま]概要提出

編集者用のページに今回の記事のページを設ける。 Ruby/Tk を扱っている部分に特に不安があるサンプルスクリプトを編集者 ML へ投げた。これをもって概要提出とし、第１段階終了。

幸運にも永井さんから返信を頂く。 （実は少し期待していたのだけど。）

パッチをまで頂いてしまってとってもラッキー☆。

[るびま]記事書き遅れてる？

今月で仕事が一段落するはずが、新たな仕事が発生。納期は今の仕事が終わってから 2 週間後。予定が狂った。

既に概要の提出期限が過ぎている気がするが、怖くて確認出来ない。週末までにはなんとか……いや、週末は記事そのものの締め切りだ。うーむ。

[パソコン]Mixi

前の会社内のコミュニティを発見。少しお友達が増えた。

職場のひと誘ってもなんか怪しいものに思われてみんな反応薄いし、 Mixi の面白さがまったく体験できていなかったのだけど、この発見で少し面白くなるかも。

先日写真も新しくした。

[blog]よくつかうフレーズ

丁稚な日々 ⇒ 自分マイニング！ - Blogでよく使うフレーズは？より。

68 かもしれない
58 もしれない。
50 インストール
46 クライアント
40 オープンソー

移転前の 11 月までの結果。まあ、こんなもんです。

[アイデンティティ]絵が下手になった

最近絵が下手になった。元が小学生レベルだし（中学生以降はほとんど絵を描いていない）絵を仕事にするつもりもないので別にどうでもいいことではあるのだが、少し気になっていた。

ゲーム制作の仕事を 10 年近くやってきたので、その物作りの経験は別の分野にも生かせる何かがあるらしく、絵を描こうとするとなんとなく器用に描けたり、器用に描こうとする癖が出てきた。この『器用』がくせ者で変に表面上をうまく仕上げることにばっかり集中して、結局どうしようもない絵ができあがる。これがダメ。よくわからないがすごくダメな流れな気がする。もっと泥にまみれて苦労しないと。下手でいいから直接的に描かないと。

そんな気がする。これはゲーム開発でも同じ事が言えるかもしれない。うまく見せなくていい。

[生活]フットサル第一回

職場のメンバーを中心に仕事帰りに 2 時間。面白かった。日頃から走るようにしていたため、フル出場したが思ったより疲れなかった。 3 、 4 点決めたもののディフェンスを全然やっていないと指摘される。

[アイデア]ゲームプログラミングを考えるページ

ゲームプログラミングのページを作ったらどうか。 人に教えるようなページじゃなくて、同じようなことを考えている他の人と一緒に考えていけるコミュニティ。こういうのやっていれば一緒にゲーム作る人も見つかりそうだし。

まぁこういうサイトは他にたくさんあるんだろうけど、こっちは Ruby を使うということで。

まず、自分で Ruby を使ってゲームを作ってみて、そこで感じた事をまとめて置いておくみたいな感じでどうだろうか。

あとは、 HSP ユーザのための Ruby 入門とか。

[生活]朝食に赤いきつね

奥さんがダウン中で朝ご飯が食べられなかったので、出勤するなり職場に置いてある赤いきつねを食べた。

こういうの食べ放題なのもお金のないオレには非常に嬉しい。

[開発ログ]Ruby で簡単に 3D

Ruby で 3D をぐりぐり動かしたいだけ。それで HSP を勉強しはじめた。 自分の得意なプログラミングは、やっぱりグラフィカルでリアルタイムのアクショーンゲームをゴリゴリ実装する部分だと思うので。そういう仕事ずっとやってきたし、ゴリゴリ書くの超早いから。再利用する必要ありませんから。自分にはミドルウェアとか作れませんから。

最近 CGI とか DB とかネットワーク関係とかそういうのばっかりで開発が停滞気味だったので、表面的な部分からもアプローチしてみたいなと。

さっくとやるために HSP を選んだわけで、今日中に Ruby から何かしらのオブジェクト（表示物）を動かせるようにすることを目標にする。

あ、あと 3D ゲームプログラミングやるのに Ruby の遅さはあまり関係ないはずです。それはそうのうち実証します。

--

ウィンドウ生成、カメラの生成、ライトの生成 dx ファイル読み込みと表示、オブジェクトの回転くらいはテストできた。 HSP の文字列処理で苦戦した。動的に文字列バッファのメモリを確保してくれないのも辛い。

次は er の具体的な仕様を決めないと。

[HSP]Makefile を使う

標準のエディタを使って実行するのが面倒だったので、先日掲示板で質問をしたところ、コマンドラインで使えるコンパイラがあることを教えていただきました。

hcc というやつを使ってみました。使いやすいです。

HSP で書いたサーバーに Ruby で書いたクライアントから接続するプログラムを開発しているので、 Make を使って同時に起動するようにしたらとても便利になりました。

そういえばいつも　Makefile を使っているものの、詳しい書き方は知らないんですよね。もう少し勉強しておいたほうが楽ができそうです。

[blog][パソコン]横着プログラミング

ふと見つけたページ。

• 第1回: Unixのメモ技術

を読む。

[HSP]ドキュメントが豊富

HSP 基本セットについてくるドキュメントの完成度がすばらしいですね。実装されているすべての機能が丁寧に解説されているのでしょうか。

これが普及の原動力の一つなのでしょうね。

Ruby/Tk を使っているときはドキュメント探しに苦労します。結局見つからないこともしばしばあります。

--

HSP のドキュメントは初めてプログラミングする人を基準に書かれている点も特徴的ですね。

[るびま]入門記事第 4 回 (2)

サンプルプログラム（ビジュアルノベル）のプロトタイプを作成。 each はなくしたい。他にもまだまだ難しいところが残っているので修正が必要。 前回からの流れでスムーズに理解できるようにすることも意識している。

guiutil の中では tk を使っている。

require "guiutil"

def init
  create_screen("game book", 640, 480)
  create_img_button(0, 640-32-16, 320, "exiticon0.gif", "exiticon1.gif")

  start_gui
end

def mainloop(tbl)
  scene = 'opening'
  fonts = []
  while true
    fonts.each{|f| f.delete }
    fonts = []

    scene_data = tbl[scene]
    message = scene_data[0]
    fonts.push create_font(message, 32,32)
    (scene_data.size-1).times{|i|
      idx = i+1
      ch_msg = "#{idx}. #{scene_data[idx][1]}"
      fonts.push create_font_button(idx, ch_msg, 32, 320+i*32)
    }

    exit if scene_data[1] == nil

    input_value = get_button_id.to_i # ここでブロック！
    exit if input_value  == 0

    scene = scene_data[input_value][0]
  end
end


# このテーブル構造の説明（理解）が最大のポイント
Tbl = {
  'opening' => [
    "３本の分かれ道があります。どの道を進みますか。", 
    ['right', "左の道"],
    ['right', "真ん中の道"],
    ['right', "右の道"],
  ],
  'right'   => [
    "しばらく歩き続けると\nもとの場所にもどってしまいました。",
    ['opening', "次へ"],
  ],
}

init
mainloop Tbl

やっぱり、朝ごはんを食べながらさくっとこういうのが書けてしまう Ruby はすごく好きだ。てゆーか、オレってすげー感？

あとは、背景を表示画像できるようにしないと。

font 生成のあたりがまだまだ複雑すぎる。

[るびま]入門記事第 4 回

今回で最終回。ゲームブックプログラムを GUI にしてビジュアルノベルにする。 GUI プログラミングには Ruby/Tk を用いる。

Ruby/Tk はいくつかの簡単なメソッドで完全に隠蔽してしまう。

コンセプトはグラフィカルなプログラムもこれまでのコマンドラインで動作するプログラムと本質は同じだということを解説すること。

今回は特に新しいことは解説しない。

執筆の手順としては、まずは最終的な完成ソースを作る。そしてその解説を書く。 Ruby/Tk が不安なので動くソースを書いたら ML へ投げて意見を仰ぎたい。

[HSP]最近はまってます

HSP 、勉強してます。といっても入門書を電車の中で読むのと、あさ家を出る前に hsp-dev の過去ログを読むくらいです。

Windows のプログラムを知らないのでわからない話が多いです。

ちなみに Windows のプログラムを知りませんが、同様に Linux のプログラムも知りません。プレステのプログラムなら知ってます。

Ruby の勉強をしているときはどんどん Linux の知識が増えていった気がするのですが、 HSP の場合は Windows プログラミングの知識が必要ですね。

HSP には次の 2 点について特に興味があります。

• HSP のライブラリを Ruby で扱うことはできないか
• HSP のどんなところがプログラミングの初心者に向いているのか

HSP の言語仕様を初心者の理解のし易さを損なわずによりよくすることは可能なのか、ということにも少し興味があります。これは専門外でしょうかね。でも興味あります。

それと、自分はゲーム屋なので、自分が人様に提供するものは HSP 以上にユーザに対しての敷居を低くする必要があるわけで、その辺、これだけ受け入れられている HSP には見習うべきところが多いです。

[アイデンティティ]Ruby/HSP

Ruby 、 HSP 、ゲーム開発、プログラミング入門。これらが頭の中でぐるぐる渦巻いている。

[パソコン]Haskell が気になる

最近 Haskell が気になってきた。RHG 読書会をはじめとするオフ会で Haskell の話題を耳にすることが多く、はじめのうちは手を出すつもりはなかったのだが、どうも気になってきた。

山下さんの翻訳したやさしい Haskell 入門 (バージョン98)を少しだけ読んでみた。

読書会が Haskell 関係になったら真面目に勉強してみようかと思う。

[HSP]HSP はじめました。

HSP にはまりつつあります。ついにカテゴリを新設してしまいました。

hsp-dev に入って過去ログを読んでいるのですが、面白いです。私は今まで開発コミュニティーというと ruby-dev しか知りませんでした。 ruby-dev のほうはとっても難しい話ばかりです。 hsp-dev には私でも議論に参加できそうな話があったりしてとても身近に感じられます。

進められている開発プロジェクトの中に「HSP to C コンバーター」というのがあって、この辺の話を中心に読んでいます。 HSP の言語構造は命令と単純な制御構造できているからこんなの簡単に作れるんじゃないの？という気がしているのですが、まぁこれは単に私が無知なだけで実際はいろいろ大変なんでしょうね。その辺を勉強していければいいなと思っています。

HSP が C になるなら簡単に Ruby の拡張ライブラリになりそうなので、その辺の可能性にも魅力を感じています。好き勝手に書きましたが現時点での私の理解にはかなり間違ったこともあるのでしょう。その辺いろいろ考えていきたいと思います。

[blog]hatena_style.rb はどこに…？

掲示板を設置したことがあるくらいのひとがはまる例のひとつ。自分も使い始めの頃はこの手のものによくはまった。

今だったら自分で Wiki に書き足しちゃっていいのかなとも思うんだけど、最初の頃はその辺の判断もつかないのでドキュメントを書き足したりはしないから、結局ねぇ。

[アイデンティティ]Ruby にない HSP の良いところを知りたい

HSP とそのコミュニティは Ruby のそれと全然違う。双方に良いところと悪いところがあるはず。

Ruby にない HSP の良いところ、これがとても興味深い。それがほんとに良いところなのかどうかも含めて興味深い。

[開発ログ]グラフィックス処理

しかし、 HSP よりいいツール本当にないのか？

[開発ログ]HSP でプログラミング開始

ソケットを使ったサーバー部分の基本部分はなんとなくできた。あとはひたすらコマンドを作ってその描画処理を追加していく。

Ruby なら無意識で実装してしまう文字列の加工も <URL:http://www.onionsoft.net/hsp/hspsamp.html> こういうサンプルを見ながら地道に書いている。

いつの間にか考え方がオブジェクト指向になっていたんだなあと認識する。

[本]HSP プログラミング入門

これで勉強中。お金がないので立ち読みですませようと思っていたのだが、とてもよい本なので買ってしまった。

[アイデア]3D プログラミング (?)

結局やりたいのは空間にモデルを表示することと、それを動かすこと。 動かすのはモデル自体のキーフレームアニメーションと位置と角度の変更。ライトは最初に設定して終わり。あと当たり判定か。これで十分。

で、これを発動するトリガーがプログラム中で書ければよい。

実際はそれ以上の細かい制御が必要になるのだけど、それはゲームのロジックとは関係のない演出的な部分だろうから、その辺の実装をコアに持ち込むべきでない。コアに持ち込まないための強制的な手段として別プロセス。プロセスを分けることは本質的でない気はするが、今の自分にとってはそのほうがイメージしやすいから。

[Ruby]新年会

今回も面白い人がいっぱい。

今年のメソッド

• each 、 てゆーかブロックつきメソッド（を作れるようになりたい）
• あと、 HSP を覚えたい（ Ruby と HSP の架け橋になりたい。うそ）

[アイデア]Jewel-mmo 構想メモ (2) 具体的なコマンド

クライアント⇒サーバーの具体的なコマンドを列挙してみる。

• ログイン
• 移動
• エリア移動
• 話す
  • say
  • shout
  • tell
• NPC に話しかける (ask)
• アナウンス
• アクション
  • 攻撃
  • アイテム
  • スペルカード
• ステータス
  • 能力値表示
  • アイテム一覧
  • 装備する
• 取引
  • 買う
  • 売る
  • 渡す
• 育成系

--

書きかけ。

[アイデア][ゲーム論]栽培と略奪

1. 土地がある
2. 種をまく
3. 芽が出る
4. 育てる
5. 小さな実がなる
6. 育てる
7. 育てる
8. 育てる
9. 育てる
10. 育てる
11. 大きな実がなる

栽培すること収穫すること略奪すること守ること。

[アイデア]Jewel-mmo 構想メモ

今まで勉強した範囲で考えられる構成はこれ。

サーバー

• Apache + CGI(Ruby) + MySQL … コア
• ircd + Nadoka … チャットサーバー

コアは CGI で実装する。高速化には mod_ruby 。 問題はコアからクライアントにコマンドをプッシュする手段。 コアからプッシュするケースは少ないし、おそらくはすべてが視覚的な情報なので何らかの方法でチャットサーバーを経由させればよさそう。

クライアント

• ランチャー … 以下の 3 プロセスを起動
  • クライアントメイン(Ruby)
  • Nadoka
  • Easy Rocket( 自作映像表示サーバー )

少し変わったのは Nadoka を別プロセスにしてクライアントメインプロセスと dRuby とかで繋ぐようにしたところ。Nadoka　の ircd を経由するデータのパース、クライアントメインとのやり取りは bot として実装する。 bot で実装すれば Nadoka に変化があっても bot のインターフェースだけ合わせればいいことになる。

あとクライアントにチャット機能を実装するのが面倒なので、一般的な IRC クライアントを使うのもありかなと。その場合、

• ircd( サーバー ) → ローカルの Nadoka → LimeChat
• LimeChat → ローカルの Nadoka → クライアントメインプロセス

のような流れになる。

その他メモ

• コア（メイン）はシンプルなゲーム仕様にする。これが一番難しそう
• サーバー側ではサーバープログラムを自作しない。ソケットとかを使わない。

--

今日は疲れたので簡単なメモ程度で。より具体的な考察は後日。

[雑記]休肝日の記録

飲まなかった日を記録しておきたい。

1/7 日 前日が会社の新年会で 16 時から 1 時まで飲み続けて、○野君の部屋に泊めてもらった日。次の日飲む気がしなかった。

最近、仕事から帰ってきた後、そんなに飲みたいわけでもなくなってきた。飲む量も減っている。

[Ruby]YARV 0.1.0 リリース

YARV: Yet Another RubyVM 0.1.0 がリリースされた。姉の Nadoka さんに日頃からお世話になっている関係で、 YARV君 が成長してゆく様をわりと近くで拝見させて頂いていたので個人的な親近感もある。

yarv 、構想は結局今年の前半で殆ど終わっていて、あとは気付かなかった難しい部分をちょろちょろと。あとは作業だけなんだよな。

去年末とても印象に残った言葉。やっぱりこういうの作っちゃう人はすごい。

拡張ライブラリだったとは。前に一度インストールを試みたことがあって何となくそんな感じかなという気はしていたのだけど。そう、あのときは svn を使えるようにする時点でかなり力尽きたんだった。

--

yarv 1.0 == Ruby 2.0

となってくれる事を期待して密かに応援。

[アイデア]Easy Rocket インターフェース案 (4) 破壊的動作をする + ってのはちょっとどうかと

なかださんからツッコミを頂く。ありがたや。

ただ意味がわからなくて一晩考える。やっとわかった気が。これでよいかな。

class Vector3D < Array
   def x ; self[0] ; end
   def x=v ; self[0] = v ; end
   def +dpos
     Vector3D[self[0] + dpos[0], self[1] + dpos[1], self[2] + dpos[2]]
   end
end

class Ball
  def initialize
    @pos = Vector3D[0,0,0]
  end
  def position
    @pos
  end
  def position=pos
    #@pos.replace pos
    @pos = Vector3D[*pos]
  end
end

ball = Ball.new
x = y = z = 100
dx = 10
dpos = 1, 2, 3

ball.position = x, y, z
ball.position.x = x
ball.position.x += dx
ball.position += dpos
pos = ball.position
x, y, z = ball.position

p pos
p x,y,z

[雑記]ドラゴンボール魔封波のアニメが静止画

いまドラゴンボールのアニメがやってて、シェンがピッコロに魔封波を使ったのだけど、アニメが半分静止画に。あれ？と思ったけどたぶん「ぐるぐるばりばり」するアニメが危険だから静止画にしたのだろう。

あのシェンが渦に吸い込まれていくシーンがすごく好きで楽しみにしていたのに残念。

しかし、今見るとアクションシーンのアニメーションとかすごくよくできている。

[アイデア]Easy Rocket インターフェース案 (3) 衝突判定

話がそれた。衝突の考察を続ける。

3D 衝突判定は平面、球、直方体、円錐でとればだいたいの場合大丈夫。 凹凸のある地面を歩くとかはまた別の話になりそうだが、それはやったことがなくてよく知らないので置いておく。

さっきチラッと書いたけど、衝突用のオブジェクトを作って、それを描画オブジェクトに登録していく形でどうだろうか。

e = 0.8 # 跳ね返り係数
ground = ClashObj.new "y=0"
ball.add_clash_obj ground, e

衝突オブジェクトの初期化はとりあえず。

これでできないのはボール同士の衝突か。いや、それ以前にこのスクリプトじゃボールのサイズなどの衝突情報が設定されていないか。

ball.clash_state "r=2", e
ground = ClashObj.new "y=0"

難しいのは、 a, b, c のオブジェクトがあったときに

• a と b は衝突する
• a と c は衝突する
• b と c は衝突しない

となる場合。うーむ。これをどう書けばいいか。

a.add_clash_obj b, e
a.add_clash_obj c, e

a.clash_all e

clash_mg.set a, b, e
clash_mg.set a, c, e

clash_mg.set_all a, e

実際にいくつかのオブジェクトを生成して考えてみよう。

• ボール 10 個
• 人間 2 人
• 地面
• ゴール … ボールとだけあたり判定をとることにする
• コートの境界線 … 人間はこれより外に出ることができない

10.times {
  balls << Model.new 
}
man1 = Model.new
man2 = Model.new
ground = Model.new
goal = Model.new
border = ClashObj.new

そうか、この場合動くものに着目しそれが何に衝突するかを考えればよい。

balls.each{|o|
  balls.each{|bsll| o.add_clash_obj ball, e}
  o.add_clash_obj ground, e
  o.add_clash_obj man1
  o.add_clash_obj man2
  o.add_clash_obj goal
}

[man1, man2].each{|o|
  balls.each{|bsll| o.add_clash_obj ball}
  o.add_clash_obj man1
  o.add_clash_obj man2
  o.add_clash_obj border
}

ボールと人の関係はすべてが無駄に相互リンクするがそれはいい。こうすればもう少しわかりやすいかも。

balls.each{|o|
  o.add_clash_objs balls + [ground], e
  o.add_clash_objs balls + [man1, man2, goal]
}

[man1, man2].each{|o|
  o.add_clash_objs balls + [man1, man2, ground, border]
}

とりあえずこれでいい。

跳ね返らない衝突

それと衝突時に跳ね返りが起こるとは限らない。 例えば壁に向かって斜めに進んだ場合は壁に平行なベクトル成分だけは残して壁に沿って移動したほうがいい。 キャラとキャラが衝突した場合もこの処理になること多い。 上のコードでも跳ね返り係数が指定されれば跳ね返りということにしている。 この衝突なんていうのだろう。

[アイデア]Easy Rocket インターフェース案 (2)

よく考えたら Easy Rocket インターフェースはサーバーへの接続とその操作だ。

requre 'er'
er = ER.new 'localhost', port
screen = ER::Screen.New er, nil, 640, 400
prim = ER::PrimImage.new er
prim.position = 100, 100, 0
screen.add_obj prim 

prim.delete
screen.delete
er.close

それともこうだろうか。

requre 'er'
er = ER.new 'localhost', port
screen = er.createScreen nil, 640, 400
prim = er.createPrimImage
prim.position = 100, 100, 0
screen.add_obj prim 

prim.delete
screen.delete
er.close

後者のほうがいい気がする。違うかな。うーむ、これ考えてどうなる問題でないな。

一瞬、プリミティブはコネクションを使わずに生成してもいいかと思ったが、それはどっちの意味でもなさそうだ。

ループ

ループ部分を含めるとこんな感じだろうか。それと、今後は A.b の書き方を使うことにする。

requre 'er'
er = ER.new 'localhost', port
screen = ER.Screen.New er, nil, 640, 400
prim = ER.PrimImage.new er
prim.position = 100, 100, 0
screen.add_obj prim 

vx = 1
vy = -10
ay = 1
while true
  prim.x += vx
  prim.y += vy
  vy += ay

  er.flush
  ER.sync 0
end

prim.delete
screen.delete
er.close

er.flush でサーバーに対して命令がまとめて送信される。

描画処理はサーバーで行われているので、別プロセスであるクライアントとの間でうまく同期を取らないと微妙におかしくなりそうだが、その辺の考察はとりあえず置いておく。内部的に解決できそうな気もする。

物理シミュレーション

Easy Rocket では簡単な物理シミュレーション機能でオブジェクトの座標を操作したいと思っている。今までは上記のように毎フレーム座標を設定し続けていたのだが、今になって考えてみると、こうした方がクライアントの実装がシンプルになる気がする。

例えば格闘ゲームの停止、歩く、停止というアクションの場合、方向キーが入力されている間だけ座標を加算するという実装が普通だ。この場合、キーが押されたタイミングと離されたタイミングの間では等速直線運動になっているので、キーが押されたタイミングで加速するという実装にすればもっとシンプルになるのではないかというアイデア。

上記のループ部分は次のようになる。

prim.speed 1, -10, 0
prim.acceleration 0, 1, 0
while true

  er.flush
  ER.sync 0
end

キャラの X 方向の移動は次のようになる。

while true
  if 右が押された?
    prim.speed.x = 1
  elsif 右が離された?
    prim.speed.x = 0
  end

  er.flush
  ER.sync 0
end

衝突判定

3D のモデリングの衝突はおいて置いて、ここでは格闘ゲームで「方向キー上」が押されたときにジャンプする処理を考えたい。 例えばこんな感じか。

prim.acceleration 0, 1, 0 # 重力加速度の設定
jump = false
while true
  # 地面とキャラの衝突判定
  if jump && prim.y <= 0
    prim.speed.y = 0
    if 右が押されている?
      prim.speed.x = 1
    elsif 右が離されている?
      prim.speed.x = 0
    end
    jump = false
  end
  # アクション開始判定
  if prim.y == 0
    if 右が押された?
      prim.speed.x = 1
    elsif 右が離された?
      prim.speed.x = 0
    end
    if 右が押された?
      prim.speed.y = -10
      jump = true
    end
  end

  er.flush
  ER.sync 0
end

着地時の加速度設定が余分な気もするが、実際のゲームだと着地時にアニメーションの変更などのイベントが入るだろうからこれはいいか。で、この着地判定を自動処理にしたかったのだけど、イベントが入るからこの例がよくないな。ボールで考えてみよう。

むずかしい。とりあえず思いつくままに書いてみる。あれ、 vx メソッドと speed は同じものか。 velocity で統一しよう。

e = 0.8 # 跳ね返り係数
ball.acceleration 0, 1, 0 # 重力加速度の設定
ground = ClashObj.new "y=0"
ball.add_clash_obj ground, e
while true
  if key_on?
    ball.velocity.y += -10
  end
  er.flush
  ER.sync 0
end

イメージとしてはこんな感じか。"y=0" とかかなり適当だけどこんなことできるだろうか。

座標クラス

オブジェクト指向的にというか Ruby 的にというか次のような書き方できるだろうか。

ball.position = x, y, z
ball.position.x = x
ball.position.x += dx
ball.position += dpos
pos = ball.position
x, y, z = ball.position

試してみよう。

position の型は何なのかという話か。 Vector クラスというのがあったが遅い模様。ここで使うのはそもそも間違っているのかも知れない。

Vector3D というクラスを自作したほうが速度以外の意味でも正解かも。

class Vector3D < Array
   def x ; self[0] ; end
   def x=v ; self[0] = v ; end
   def +dpos
     self[0] += dpos[0]
     self[1] += dpos[1]
     self[2] += dpos[2]
     self
   end
end

次のようなコードが動いた。

ball = Ball.new
x = y = z = 100
dx = 10
dpos = Vector3D[1, 2, 3]

ball.position = Vector3D[x, y, z]
ball.position.x = x
ball.position.x += dx
ball.position += dpos
pos = ball.position
x, y, z = ball.position

p pos
p x,y,z

[アイデア]Easy Rocket インターフェース案

適当に書きながらイメージを固めていきたい。

2D

まずウィンドウの生成と 2D 表示。 とりあえずウィンドウ生成のオプションは置いておく。

requre 'er'
screen = ER::Screen.new

prim = ER::PrimImage.new screen
prim.position = 100,100,0
prim.disp

次のような実装もありかと思うがどうだろう。違うかな。

prim = screen.create_image_prim

3D

次に 3D オブジェクト。

requre 'er'
screen = ER::Screen.new

model = ER::Model.new screen, data
model.position = 100,100,0
model.disp
model.anim anim_id

シンプルだけどモデルをグループ分けしてソートしたり、ライティングを考慮してない。あ、視点のコントロールができない。カメラも追加しよう。

requre 'er'
screen = ER::Screen.new
ot = ER::OT.new screen

camera = ER::Camera.new
screen.camera = camera

model = ER::Model.new data
model.position = 100,100,0
model.disp
ot.add_obj model
ot.disp

model.anim anim_id

OT は任意で生成すればいいか。カメラは複数存在する可能性があって、切り替える場合はスクリーンの設定を変更すればよい。

画面分割

画面分割する場合を考えてみる。例えば、画面を上下に分けて対戦できるマリオカートとか、レースゲームのバックミラーのような処理の場合。

まずモデルオブジェクトは複数の画面でもひとつのものを使いまわすべきだろう。む、 カメラと OT はどうだろう。難しい。あくまでクライアントの都合だけで考えよう。そう考えると使いまわせてもいいし、別々のものを使ってもいいがいいかな。

screen1 = ER::Screen.new
screen2 = ER::Screen.new
ot = ER::OT.new screen1

あ、これだと OT が使いまわせない。そうか、 OT と Model はポリモルフィズムというやつでないとダメだ。 2D プリミティブもこの「描画オブジェクト」の仲間だ。スクリーンがこの仲間に入るかどうかは微妙。

screen1 = ER::Screen.new
screen2 = ER::Screen.new
ot = ER::OT.new
screen1.add_obj ot
screen2.add_obj ot

とすればいいか。以下のように続けて、

camera1 = ER::Camera.new
screen1.camera = camera1
camera2 = ER::Camera.new
screen2.camera = camera2

カメラはこれで OK 。ひとつのカメラを使ってもよい。

model = ER::Model.new data
model.position = 100,100,0
model.disp
ot.add_obj model
ot.disp

ここまではいいか。いや、よくないな。ウィンドウがひとつなのか複数なのかが明示されていない。

win = ER::Window.new
screen1 = ER::Screen.new win, rect
screen2 = ER::Screen.new win, rect

のようにすればいいか。 Window.new は省略できる方向で。

OT 単位でソート

次に OT 単位で描画の優先順位を設定することについて考えてみる。

screen = ER::Screen.new
ot1 = ER::OT.new
ot2 = ER::OT.new
screen.add_obj ot1
screen.add_obj ot2

ot1.z = 0
ot2.z = 1
#ot1.position = 0,0,0
#ot2.position = 0,0,1

単にこれでいいか。

OT を省略

screen = ER::Screen.new
prim = ER::PrimImage.new screen
prim.disp

最初にこう書いたけど、これまでの考察で行くと次のようにならなければいけない。

screen = ER::Screen.new
prim = ER::PrimImage.new
prim.disp
screen.add_obj screen

前者の方がいい気がするが。次のようなパタンもありか。

screen = ER::Screen.new
prim = ER::PrimImage.new
prim.parent = screen
prim.disp

むむむ。こんがらがってきた。親と子は相互リンクだろうか。少なくとも子は親を知っていなければならないはず。子オブジェクトから階層関係を考慮してワールド座標を取得するときとか。親は子を知る必要があるだろうか。描画プライオリティは階層関係を超えて設定したいから内部的には描画オブジェクト自体から……まあ複雑な話は考えてもあまりあてにならないからいいか。

下の図を考えていたら気づいたが、描画プライオリティは階層関係を超えてはいけない。スクリーン内に描画されたウィンドウの表示順序を帰るときに不便だし、そもそも OT の意味がない。

クラス階層図

これまでの考察を踏まえると、こんな感じだろうか。

DrawObject(OT) …… position(x,y,z),disp,hide
 |
 +--DrawPrim …… size(w,h,d)
     |
     +--Window
     |
     +--Screen …… camera 
     |
     +--Prim2D
     |   |
     |   +--PrimImage
     |
     +--Model3D

この中で new の引数に parent をとれないのは Window だけ。Window 生成の省略系があるからその限りではないか。

省略なし

win = Window.new nil
screen = Screen.new win
prim = PrimImage.new screen

win 省略

screen = Screen.new
prim = PrimImage.new screen

ただ実際はスクリーンサイズくらいは設定したい。

screen = Screen.new 640,400
prim = PrimImage.new screen

としたいけど確か Ruby でこういうのできない。

def ER.CreateScreen w,h,x=nil,y,nil
  screen = Screen.new DefaultWindow,640,400
end

を用意しておいて、

screen = CreateScreen 640,400
prim = PrimImage.new screen

とすればいいか。

これは画像表示 new にも言える事だな。難しい。

まとめ 1( 間違い版 )

2D プリミティブ表示。

requre 'er'

screen = ER::CreateScreen 640,400
prim = ER::PrimImage.new screen
prim.position = 100,100,0
prim.disp

3D モデル表示。disp はデフォルトでいいか。

requre 'er'

camera = ER::Camera.new
screen = ER::CreateScreen 640,400
screen.camera = camera

ot = ER::OT.new screen

model = ER::Model.new ot
model.position = 100,100,100
model.anim anim_id

次に画面分割。あれ、このクラス構造だとダメだ。むむむ。カメラが描画するというアプローチが必要か。いや、スクリーンは描画オブジェクトじゃなくて表示領域だ。ウィンドウとスクリーンを描画オブジェクトに入れたのが間違いだ。

まとめ 2

2D プリミティブ表示修正版。

requre 'er'

screen = ER::CreateScreen 640,400
prim = ER::PrimImage.new
prim.position = 100,100,0
screen.add_obj prim 

3D モデル表示修正版。

requre 'er'

camera = ER::Camera.new
screen = ER::CreateScreen 640,400
screen.camera = camera

ot = ER::OT.new
screen.add_obj ot

model = ER::Model.new ot
model.position = 100,100,100
model.anim anim_id

画面分割

win = ER::Window.new
screen1 = ER::Screen.new win, 640,400
screen2 = ER::Screen.new win, 640,400

ot = ER::OT.new nil
screen1.add_obj ot
screen2.add_obj ot

camera1 = ER::Camera.new
camera2 = ER::Camera.new
screen.camera1 = camera1
screen.camera2 = camera2

model = ER::Model.new ot
model.position = 100,100,100
model.anim anim_id

--

あ、ライトを忘れてた。ライトはカメラと同じようにスクリーンに追加すればよさそうだ。ただライトは複数設定することができる。

light1 = ER::Light.new
light2 = ER::Light.new
screen.lights << light1
screen.lights << light2

こういう書き方できただろうか。

screen.push_light light1
screen.push_light light2

ダメならこれで。

クラス階層図 ( 修正版 )

Window
Screen …… camera,lights 

DrawObject(OT) …… position(x,y,z),disp,hide
 |
 +--Prim2D …… size(w,h)
 |   |
 |   +--PrimImage
 |
 +--Model3D

[アイデア]チリカコーン

長女がカリフラワーのことをそう呼んでいた。面白い名前。

[開発ログ]HSP 入門

朝から HSP 関連のホームページを見ていた。機能がいろいろあって楽しそう。 簡単なサンプルソース見てもなかなか内容が理解できなくて苦しいけど、がんばって飛び込んでみるか。

作者の基本的な思想にはすばらしいものがあって、それが実現されていて、それでここまで流行っているだろうなという印象。

--

まずはプロセス間通信のインタフェースをどうするかから。 確実そうなのは、 C で拡張機能として実装してしまうこと。これならきっとなんでもできるのだろう。まず、そのあたりを調べてみよう。

--

開発版（ HSP Ver3.0 β）もあるのか。いまからはじめるなら新しいほうを使おう。

HSPによるTCP/IPサーバー・クライアント通信のスクリプト発見。

初めてソケットに挑戦するプログラムが HSP になるとは。

いろいろ変わっているようなのでやっぱり安定版にする。

サンプルを少し改造して、エコーサーバーを作ってみた。 HSP 以前にソケットをよく知らないのでかなり怪しい。

#include "hspsock.as"
	title "エコーサーバーテスト"

*main
	port=999
	mes "ポート"+port+"で接続を待っています..."
	sockmake 0,port
	if stat : dialog "Socket error": goto *bye

	a=0
	repeat
	  sockwait 0
	  title "CHK="+stat+"/"+a
	  if stat>1 : dialog "Socket error": goto *bye
	  if stat=0 : break
	  a+
	  wait 10
	loop

	mes "接続しました。("+refstr+")"

	;
	repeat
	  msg = ""
	  sockget msg, 256
	  if stat : dialog "Socket error": goto *bye
	  sockput msg
	  if stat : dialog "Socket error": goto *bye
	  ;mes msg

	  str msg0:msg0=msg:poke msg0,1,0
	  if msg0="q" : break
	loop
	;
*bye
	sockclose
	mes "終了"

ruby からこんな感じで接続してみると 0.15 sec とかで終わる。ネットワークは遅いというイメージをもっていたけどこれなら申し分ない。

t = Time.now
1000.times{|i|
  sock.write "#{i}\n"
  sock.gets
}
p Time.now - t

とりあえず通信することはできたのでこれで次に進める。もっといい通信方法があれば後で最適化すればよい。

--

HSP の dll の ruby binding なんてよさそうだなあとか思ったり

これはとっても面白そう。でも今回はサーバーのプロトタイプを HSP で実装してみるということでやってるから、これはまた別の話。まぁ、それにしても、この方法がとても有効な気もするけど、 dll のバインディングなんて実装方法がさっぱりわからない。

[栽培日誌]ブロッコリー収穫

ブロッコリー初収穫。かなりしっかりしたものが収穫できた。煮物用に大根も収穫。白菜はもう少しで収穫できそうだ。追肥もしておく。

全体的にはこの時期でも緑がいっぱい。十畳ほどの小さなアパートの庭だけど、それなりに収穫できるようになってきた。今年は本格的に収穫できそうな予感。

[開発ログ]Ruby と HSP でプロセス間通信

Ruby で

hsp = Hspscreen.new
hsp.print "hello"

とかして、 HSP の画面に文字を表示する方法を考えないと。たぶんこれがプロセス間通信というやつだと思う。

[雑記]サッカー練習開始

危ない、また無秩序にカテゴリを作るところだった。新カテゴリは雑記で実績ができるまで作らない方向で。

先月のキャッチボールに続いてサッカー部も発足。今日が初練習。昼休みに 30 分間ボールを蹴る。 キャッチボールとうまく両立したい。ちなみにキャッチボールの方は特別な理由で参加出来ない限り毎日続けている。

前からフットサルに誘われていたのだが、次回からは参加する予定。

[アイデンティティ]慣れ

Ruby を知れば知るほど「不親切になっていく自分」を何となく感じていたのだけど、HSP を勉強しているうちにそれが何なのかが自覚できた。

[雑記]休日出勤当日

うわ、バカ往くに引用されていた。近づきがたかった一番の原因はホームページだったのかもしれない。最初は何のことが書いてあるのかさっぱりわからなくて、 Ruby を使い始めて半年以上立ってから意味が少しずつわかってきた。そういえばそうだった。こんなこともう忘れてた。

今日も出社前に小一時間ほど HSP の勉強をして、定時通りに出社。

今のところ HSP には驚かされてばかり。いろんな意味で。

[雑記]休日出勤

気が付いたらかなりやばめ。明日も出る事に。

[パソコン]IMAP

POP で取ってきたメールを IMAP で管理できないのかなあ。

[アイデア]3D プログラミング

ライブラリを探しているがどれもいまいちパッとこない。ドキュメントが重要だと思った。

まずひとつの決断。マルチプラットフォームを捨てる。現時点ではどうせプロトタイプの作成なので Windows で動けばよい。さくっと開発できることが重要。とにかく動くものを作ろう。

ああ、これで身軽になった。

---

現在の最有力候補は HSP 。

「拡張プラグインという形で機能を追加していくことが可能です。」

らしい。これは大きな動機付けになる。

---

HSP のサンプルスクリプトを動かしてみる。なかなかよい。気に入った。

最近は慣れてきたが、自分は最初 Ruby とかそのコミュニティには近づきがたいものを感じていた。 HSP はまるで逆のイメージ。

Ruby は Unix のシェルで、 HSP は DOS プロンプトという印象。自分は MS-DOS から入った人間なので DOS プロンプトタイプはそういう意味ではなじみやすい。

[アイデア]今年の実装計画 (2)

少し考えてみた。 5 分間くらい。

あれこれちょこちょこと手を出しているとどれも進まない。やっぱりオレはやるときはガッと一気にやらないとダメなタイプだ。そしてもっと明確に方針を決めたほうがいい。

基本方針

• Rails での実装は見送り
• むらさまのリニューアルと 3D プログラミングを平行作業
• 他はやらない

うん、わかりやすい。これで十分だ。

[アイデア]今年の実装計画

具体的に書いてみる。

1. むらさま更新 … セッション管理、サーバー移行
2. Jewel-mmo
3. ……

うーむ、詳しく書けない。まず、計画を立てるための考察が必要だ。考察のための手順は、

1. Esay Rocket を実装するためのグラフィックライブラリを探す
2. Rails を試す
3. 仕様をもう少しだけ具体化する

あたりからかな。

[運営ログ]Rank 4

引越ししてからずっと 0 だったグーグルランクがいつの間にか 4 になっていた。

[サーバー]gp6 に gentoo をインストール (2)

昨日からの続き。

システムのブートストラップには 6 時間かかった。

stage1 と stage3 の違いは手順的にはほとんどないようだ。放置する時間は違う。

---

システムのビルド

emerge system

2 時間半ほどで終了。

---

タイムゾーンを選択。 JST( 日本時間 ) を使う。

ln -sf /usr/share/zoneinfo/Japan /etc/localtime

よく知らないので gentoo-sources を選択。

emerge gentoo-sources

20 分もかからずに終わっていた。

emerge genkernel
genkernel all

作成されたカーネルイメージとinitrdの名前を確認する。

ls /boot/kernel* /boot/initrd*

実行結果は次の通り。

/boot/initrd-2.4.26-gentoo-r14  /boot/kernel-2.4.26-gentoo-r14

hotplugをemergeして有効にする。

emerge hotplug
rc-update add hotplug default

---

lsmod >> /etc/modules.autoload.d/kernel-2.4
nano -w /etc/modules.autoload.d/kernel-2.4

---

nano -w /etc/fstab

# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
/dev/hda1               /boot           ext2            noauto,noatime          1 1
/dev/hda3               /               ext2            noatime                 0 0
/dev/hda2               none            swap            sw                      0 0
/dev/cdroms/cdrom0      /mnt/cdrom      iso9660         noauto,ro               0 0

none                    /proc           proc            defaults                0 0
none                    /dev/shm        tmpfs           defaults                0 0

---

echo gp6 > /etc/hostname

---

nano -w /etc/conf.d/net


iface_eth0="dhcp"

defaultのランレベルにnet.eth0を追加。

rc-update add net.eth0 default

---

nano -w /etc/hosts

以下のように書き換える。

127.0.0.1       gp6 localhost
192.168.1.xxx   xxxx

---

passwd

---

nano -w /etc/rc.conf

---

emerge metalog
rc-update add metalog default

---

emerge vixie-cron
rc-update add vixie-cron default

---

emerge dhcpcd

---

GRUBのインストール

emerge grub

nano -w /boot/grub/grub.conf

default 0
timeout 30
splashimage=(hd0,0)/boot/grub/splash.xpm.gz

#genkernelを使った場合の例はこちら
title=Gentoo Linux (genkernel)
root (hd0,0)
kernel (hd0,0)/boot/kernel-2.4.26-gentoo-r10 root=/dev/hda3
initrd (hd0,0)/boot/initrd-2.4.26-gentoo-r10

/etc/mtabの更新

cp /proc/mounts /etc/mtab

grub-installの実行

grub-install --root-directory=/boot /dev/hda

---

自分用の設定

rc-update add sshd default

useradd xxx -m -G users,wheel,audio -s /bin/bash
passwd xxx

---

システムの再起動

exit
cd
umount /mnt/gentoo/boot /mnt/gentoo/proc /mnt/gentoo
reboot

無事に起動。

[サーバー]gp6 に gentoo をインストール

マシンを組み立てる。先日まで Windows マシンとして活躍していた Gateway PC(440BX CEL800) のビデオカードとハードディスクを交換して起動。

マシン名を gp6 とすることに。

---

<URL:http://mirror.gentoo.gr.jp/releases/x86/2004.3/livecd/install-x86-minimal-2004.3-r1.iso > を CD に焼く。

今回はステージ 1 に挑戦する。

---

LiveCD でブートして

passwd
/etc/init.d/sshd start

sshd 起動。

ifconfig

で dhcp に振られた ip を確認。

移行の作業はノート PC から ssh 経由で行う。

---

fdisk /dev/hda

fdisk 起動後に以下を実行。

d
1
d
2
d
3
d
4

n
p
1
1
14

n
p
2
15
80

n
p
3
81
4865

a
1

t
2
82

p

w

fdisk 終了後以下を実行。

mke2fs /dev/hda1
mke2fs /dev/hda3
mkswap /dev/hda2
swapon /dev/hda2

mount /dev/hda3 /mnt/gentoo
mkdir /mnt/gentoo/boot
mount /dev/hda1 /mnt/gentoo/boot

---

cd /mnt/gentoo
wget http://mirror.gentoo.gr.jp/releases/x86/2004.3/stages/x86/stage1-x86-2004.3.tar.bz2

md5 を確認。

wget http://mirror.gentoo.gr.jp/releases/x86/2004.3/stages/x86/stage1-x86-2004.3.tar.bz2.md5
md5sum -c stage1-x86-2004.3.tar.bz2.md5

tar -xvjpf stage1-x86-2004.3.tar.bz2

--

コンパイルオプションの設定

nano -w /mnt/gentoo/etc/make.conf

<URL:http://www.freehackers.org/gentoo/gccflags/flag_gcc3.html> を参考に書き換える。

# Celeron (Coppermine) aka Celeron2 (Intel)

CHOST="i686-pc-linux-gnu"
CFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer"
CXXFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer"

---

mirrorselect -a -s4 -o |grep 'GENTOO_MIRRORS=' >> /mnt/gentoo/etc/make.conf

mirrorselect に 30 分以上かかる。

cp -L /etc/resolv.conf /mnt/gentoo/etc/resolv.conf

mount -t proc none /mnt/gentoo/proc

chroot /mnt/gentoo /bin/bash
env-update
source /etc/profile

---

Portageツリーの更新。

emerge --sync

長い。 5 時間ほど放置したらいつの間にか終わっていた。 （追記：後日試したら 1 時間くらいだった）

---

USE変数の設定

よくわからないので触れずにおく。

<URL:http://www.gentoo.org/doc/ja/handbook/handbook-x86.xml?part=2&chap=2> ここを読んでおくことが必要か。

---

システムをブートストラップする

cd /usr/portage
scripts/bootstrap.sh

---

明日に続く。

[日記]箱根駅伝

子供を連れて箱根駅伝を観戦に行く。

生まれたときから正月は前橋か横浜にいるので、正月の駅伝は身近にあったのだが、見に行くのは今回が初めて。

歩いて 5 分の国道平戸で応援。角度が悪くて運悪くテレビに映れなかった。

[映画]カンフーハッスル

久しぶりに 2 人で観に行った。少林サッカーがすごく好きなので元旦に観てしまった。とても面白かった。

[生活]群馬から帰る

昼過ぎに向こうを出て、関越が練馬を先頭に渋滞しているというので、川越で下りてふらふらとさまよいながら、旧 17 号を南下して、戸田橋を渡ってデニーズでご飯を食べて、東京タワーを見ながら内堀を走っていたら、いつの間にか 1 号線を走っていたのでそのまま帰ろうと思っていたら、横浜駅付近で道に迷ったものの親切なおばさんの運転席から出た手で合図してもらって、 1 号線に戻って 19 時過ぎに家路に付く。

気が付くと時間はかかっているけど初めての道を地図を見ながら、しかも家族 5 人で走っているから、まあ大丈夫。単純にいつもの道を渋滞しながら帰るよりは面白かった。

[tDiary]カテゴリ分け

カテゴリが無秩序に増えてしまった。今後は計画的にカテゴリ分けをしたいものだ。今度も使えそうなカテゴリを考えてみる。

• 開発ログ … Jewel-mmo 開発に関する開発メモ
• アイデア … Jewel-mmo に関するブレスト的アイデア。または企画原案。
• ゲーム論 … ゲームデザインのネタや考察
• 生活
• 家族
• アイデンティティ … 自分について
• 日記 … 昔ながらの日記
• サーバー … サーバー管理全般
• tDiary
• Ruby
• パソコン … コンピュータネタ全般
• blog
• 栽培日誌
• 雑記 … どのカテゴリにも当てはまらないもの
• ゲーム
• マンガ
• 映画
• デザイン … art の方が汎用性があるかも

うーむ。こんなものだろうか。