New Articles

Recent Comments

  1. Storekeeper 設計編(1)
    1. 09/11 : by ?尚男装
    2. 08/04 : by チャンルー
    3. 07/11 : by 男性用水着 ビキニ
    4. 09/12 : by ヒーハー!!!!
    5. 09/05 : by ついつい・・・
  2. Seesaaで自作HTMLカスタムしてみたの
    1. 08/02 : by 吸引力の変わらないただひとつの…
    2. 08/13 : by テレビ電話 エッチな女の子
    3. 10/29 : by Kelvin Perry
    4. 10/26 : by Emma Erickson
    5. 10/24 : by Vince Shepard
  3. 作るモノ・課題 募集中!
    1. 02/11 : by ポロリン
    2. 02/01 : by PC自作男
    3. 01/27 : by タソタソメソ
    4. 01/27 : by ちょろ毛
    5. 01/19 : by まろゆき
  4. トラックバックのテスト
    1. 10/03 : by english amatuer porn
  5. Storekeeper 設計編(3)
    1. 10/03 : by mature women amatuer

Recent TrackBacks

  1. 12/02 : Seesaaで自作HTMLカスタムしてみたのまげフ
  2. 11/29 : Seesaaで自作HTMLカスタムしてみたのふりす
  3. 11/22 : Seesaaで自作HTMLカスタムしてみたの犬コロ
  4. 11/08 : Seesaaで自作HTMLカスタムしてみたの花びら
  5. 10/25 : Seesaaで自作HTMLカスタムしてみたの暴走

Log

  1. May 2005 (1)
  2. Apr 2005 (10)

RSS

01 May 2005 :: 作るモノ・課題 募集中!

Storekeeper が一段落ついたので、そろそろ違うものも作りたくなってきてしまった、ムーディーな名無し屋です。
はてさて、ゴールデンウィーク中に何を作るべきか。

落ちモノはどうでしょうか。テト○スは他の言語で作った事があるのですが、Java ではまた一味違う面白さがありそうです。でも、2つ続けてパズル系になってしまいますが。

ボードゲームなんてのも。リバーシは作った事があるので、それ以外がよさそうです。

RPGとかSLGとかSTG… 大規模なものは無理です… orz
あくまでも個人で作れそうなものがいいですね…。

というわけで、作るモノ・課題を募集中です。m(_ _)m
ゲームに限らず、Javaで作れるツールなんかもありかも。

Posted at 19:43 / 21 Comments / 0 TrackBacks / Category : Task

29 Apr 2005 :: Storekeeper GUI版デキタヨ!

SwingやらJava2Dやら紆余曲折を経まして、出来ますたGUI版。
一応説明しますと、StorekeeperとはJavaで作った倉○番です。

Storekeeper20050429.zip

コマンドラインに "cui" と指定すると、CUI版も遊べちゃうという。
何も付けないとGUI版です。ちゃんとウィンドウが出ます。
本当にどのプラットフォームでも動くのかはわかりませんが、動くはずです。
一応ModelとViewを切り分けられたって事かな?

Swingは、LayoutManager やら Container やら、最初は複雑さばかりが目についたのですが、
蓋を開けてみれば、意外とすいすい書ける。
リスナーの使い方とか、イベントとの対応さえ覚えてしまえば、なんとかなるっぽいです。
ActionListenerとかMenuListenerとか、たくさんあるので覚えるのが大変ですけどネ。

ゲームの描画は、JPanel を継承して paintComponent() メソッドをオーバーライドしてます。
毎回毎回ゲームの状態を取得して、描画してたんじゃ遅くなりそうだったので、BufferedImage をオフスクリーンとして持っておいて、ゲームの状態が更新されたら、その都度オフスクリーンを更新。
paintComponent() で、オフスクリーンを画面にコピー、となかなか速くていいぞこれ。

そこで、気になるのがGUI版のメモリ使用量。
メモリ1GB超の時代ですが、やっぱりリソースは節約するべきです。

CUI版と比べるとメモリ消費はさぞかし… と思ってタスクマネージャを見たら、2倍以上だった。orz
…いやいや待てよ、と。
BOSUKEさんのβえんどるふぃんのネタ帳にあるタスクマネージャーメモリ使用量の怪の記事を思い出す。(無断リンクごめんなさい m(_ _)m)
つまり、本当のメモリ使用量を見たければ、仮想メモリサイズを見ろという訳なんですよ!
見ると、CUI版とGUI版の違いは 5MB ぐらいだった。GUI部分は5MB程度のメモリを使用するのか。意外と少ないのね。

どちらにせよ、たかが倉庫番に20MB以上ってメモリ使いすぎだよ orz

Posted at 03:17 / 0 Comments / 0 TrackBacks / Category : Product

26 Apr 2005 :: Storekeeper CUI : Memento パターン

くだけた文体に飽きてきたので、少し堅めの文体で書いていきたいと思います。

結城先生の本とにらめっこしつつ、Memento パターンで、Storekeeper(倉○番)の「一手戻る/進む」「一番最初に戻る」を実装してみました。

Storekeeper20050426.zip

Memento パターンを使う上で難しかったのは、Memento(記念品)の役に、どのように、また、どのぐらい、情報を出し入れするインターフェースを提供させるか、という点です。
同じパッケージ内だからと言って、あまりに情報を公開しすぎるのも、なんだか気持ちよくありません。依存性を高める結果にならないのでしょうかね。それとも、気にしすぎなんでしょうか。

今回のケース(Storekeeper)では、保存する必要があるのは、主人公の座標・歩数と、全ての箱の座標なので、Memento の中は、座標のArrayListなどを持たせています。
Memento を作成するタイミングは、「ゲーム開始時」「主人公が移動した時」なので、この辺りは、Game クラスに簡単に組み込めました。Observer パターンが効いているのかしらん。
でも、移動の度にオブジェクトが増えるとなると、気になるのはメモリ使用量。
といっても、Memento の中身が同じになるのは、ほとんどありえないので、Flyweight パターンも使えないし… 一時ファイルとかに退避させればいいのかな… この辺りのノウハウがよくわかりませんです。

例えば、ドローイング(絵を描く)ソフトを作る場合、UndoやRedoなどは、どう実装するんでしょうね。こういった場合、ポイントとなるのは、「何を保存するか」なのでしょうけど。
それでも、恐らく情報量が半端じゃ無いと思うので、やっぱり一時ファイルを作ってるのかな。ページファイルみたいなもの?

と、結局、気になりつつも放置してしまう出不精な私。特に重くならなければ、まあいいや。
なんだか、Javaを使ってるとメモリの使用量に疎くなってくるような… (^-^;

Posted at 01:22 / 0 Comments / 0 TrackBacks / Category : Product

25 Apr 2005 :: Javaで大体出来ましたStorekeeper CUI版

色々作ってたら遅くなってしまいました。
結局、まずコンソール版で作る事にしちゃったり、
クラス階層を分けてみたりと、色々弄ってみました。

ソース入りアーカイブ置いておきます。

Storekeeper 2005/04/25

※実行には JRE 5.0 が必要だと思われます。
 あと、「一手戻る/進む」機能については、未実装です。Memento パターンでやる予定。

うぅ… 眠くてヤヴァイので、肝心の中身については、次回…で…… zZ

Posted at 02:48 / 0 Comments / 0 TrackBacks / Category : Product

22 Apr 2005 :: Storekeeper 設計編(3)

設計編(2)で Field.judgeCleared() を用意する、なんて書いたけど、

よくよく考えてみると、Box→Fieldのメッセージは必要ないか。
つまり、画面を更新する時に、クリアしてるかチェックしちゃえばいいのだった。

そして、画面の更新のタイミングを考えてみると、主人公が動いた時だけだね。
って事は、むしろ必要なのは Keeper→Field のメッセージなのでわ。
ここを、ObservableとObserverにするべきか。

そろそろ整理する必要があるな。Observer と Observable のメッセージ関係。
()が継承、実装してるクラス、インターフェース
[]がメッセージの引数
→がメッセージを送信(Observable→Observer)
←がメッセージを受信(Observer←Observable)

Key(Observable)
→ Keeper [移動方向] : 「入力があったよ」

Field(Observer, Observable)
← Keeper : 「移動したよ」
→ ビュー : 「内部状態が更新したんでビューを更新してくんろ」

Keeper(Observer, Observable)
← Key [移動方向] : 「入力があったよ」
→ Field : 「移動したよ」

…あれ? これだけか。結構シンプルでした。

Key は、ウィンドウ(フレーム)に持たせる予定。
Field のコンストラクタに、ステージデータが書かれたファイル名を渡す。つまり、Field が Keeper や Box を生成するので、Keeper を Key に接続するのは Field の役目。
って事で、Field のコンストラクタは、
public Field(Key key, String filename)
という事になるかな。
Keeper へ Field を接続するのも、Field のコンストラクタでできる。
ビューを、Fieldに接続するのは、Field を生成したクラスに任せるって事で。

改めて UML 勉強しなくちゃいけないなって思った。さすがに。
週末に UML で描いてみます。

Posted at 03:33 / 1 Comments / 0 TrackBacks / Category : Study

22 Apr 2005 :: Storekeeper 設計編(2)+実装編(1)

うー。とりあえずGUI部分は後で考える事にして、Storekeeper のエンジンを書き始めてみたものの。
やっぱり慣れないJava。頭でわかってるつもりでも、書いてみると出てこない!
本に書いてあるコードは読めるのに、自分では書けない!
と、軽いノイローゼと、軽い痴呆症が入りつつ、がむしゃらに書いてみる。

あと、やっぱり実装の段階で、設計を修正する事も何度か。
うぅ… 設計が甘いとこういう事になるのね… この辺は経験値をつむしかなさそうだ…。

開発は eclipse + J2SE 1.5(Tiger) でやっています。
eclipse はすごいなぁ。こんなIDEが無料ってありえなーい。
JDKは、最初1.4.2系で始めたんですが… おおーい! 列挙型無いのかよ!! とすごい勢いでつっこんでしまったので、乗り換えますた。列挙型無しには生きていけない私。

Tigerのenumは、タイプセーフなので Delphi の組み込み型の列挙型に近いですね。
でも、ちゃんと java.lang.Object のサブクラスになってるのがすごい。驚き。

他にも、ジェネリック(C++のテンプレートみたいなモノ)とか、アノテーション(メタなデータを記述できる)とか、オートボクシング(プリミティブ→ラッパの自動変換)などなど、やべーぜTiger!さすが虎!タイガースのファンになっちゃいそう!!

とまあ、Javaリスペクトはこの辺にして。…えっ!? リスペクトって死語なの?
設計で、ObserverとObservableをアフォみたいに使ってたけど、例えばBoxには、コンストラクタでFieldを渡しちゃうので、Observableじゃなくてもいいかな、と。
Fieldに、クリアしたかどうか判定する judgeCleared() メソッドを用意して、Boxが移動した時に呼んでもらう。
Boxのpush(Direction)メソッドは、実際にはprotectedでabstractなdoPush(Direction)メソッドを呼ぶテンプレートメソッドにして、doPush が true を返したら、field.judgeCleared()を呼ぶって事で。

おおお、デザインパターンが自然に出てくるようになってきてちょっとカンドー。
結城 浩先生の「Java言語で学ぶデザインパターン入門」(ソフトバンクパブリッシング)のおかげです。勝手にリスペクト先生!!(死語らしいけど)

Posted at 02:45 / 3 Comments / 0 TrackBacks / Category : Study

21 Apr 2005 :: Storekeeper 設計編(1)

んでは、Storekeeper(倉○番)の設計を始めてみようかな、と。
設計なんて言っても、そんな大それたモンじゃなく、どんなモノが出てくるとか、それぞれのモノがどう動くかとか、どういう風に関連しあってるかとか、全体的な流れなどなど、整理してみるわけですよ!(サンボマスター風に)

まずは、キー入力をどう受け取るか考えてみる。
それぞれのモノが、各々キー入力判定をしてみてもいいんだけど、こういうシステム依存的なコードは、なるべく一箇所に集中したいのココロ。なので、キー入力を受け取るクラスを作る事に。

■ Key
キー入力を input() メソッドで受け取るクラス。
倉○番では、方向キーしか使わないので input(direction) にするべか。
それぞれのオブジェクトにキー入力があった事を通知するのは、Observer パターンを使う事にする。
というわけで、Key は Observable(Subject) を継承して、input が呼ばれたら、接続してる Observer を、入力された方向を引数に update するってことで。

次に、倉○番の「舞台」が必要ですな。何しろ舞台が無いことには、主人公も倉庫の荷物も置けません。

■ Field
舞台となるクラス。1つの主人公と、複数の荷物を持っている。
複数の荷物は、リストか何かで管理するとして。
あと、大事なのが地形。ステージがどういう形なのかを、ここに持たせる。つまり、ここに移動できるかとか、ここには荷物があるか、などはこれに問い合わせればわかるって事で。
さらに、ゲームの終了を判定しなくちゃいけない。終了条件は、全ての荷物がゴールにある事なので、これじゃないと判定できない。荷物が移動したかどうかは、教えてもらわないとわからないので、Observer を継承して、Update してもらう事にする。
主人公の初期位置とか、ステージの形とか、荷物の数・位置は、ファイルに書いておいて、読み込むようにするべさ。
Model-View の Model にあたるクラスなので、Observable も継承して、View に通知できるようにしておく。
なんか、役目が多いな… しょうがないけど。

今度は、荷物クラスだけど、色々な種類の荷物を作れるようにする為に、荷物抽象クラスを作る事にする。荷物って英訳すると何だろ。Baggage …だと、手荷物って感じだし… Package だと、java.lang.Package とかぶっちゃうし… Box でいいや。箱〜。

■ Box(abstract class)
荷物(箱)を表す抽象クラス。
コンストラクタで、初期位置を設定。位置は、ゲッタだけ提供して、動かすには「押す」。「押す」のはどんな荷物でも出来るけど、実際に動くかどうかは押してみないとわからない、というわけで、「押す」は、実際に動いたかどうかを bool で返す。引数には押す方向かな。
あと、移動先に移動できるかどうか知る必要があるので、コンストラクタで Field を渡す事にしましょ。依存しちゃうけど、しょうがあるまい。
んで、移動した時に Field に伝える必要があるので、Observable を継承して、接続できるようにしておく。

具体的な箱としては、「押せない HeavyBox」「押すとその方向に1つ動くけど他の荷物があると押せない StepBox」「押すと壁や他の荷物にぶつかるまで動く箱 SlipBox」「押すとその方向に1つ動き他の荷物がある場合は飛び越えて2つ進む JumpBox」などが考えられる。どれも「押す」メソッドは共通。

…あれ? ちょっと待てよ。って事は、Field がファイルを読み込んで舞台を構築する時に、それぞれの荷物の種類に応じてインスタンスを作らないとだめだぞ。
…ここは、Javaお得意のリフレクションの出番ですか!(リフレクションを使えば、クラス名からインスタンスを生成したりできるみたい)
Class.forName("StepBox") で、StepBox のクラス型クラスをゲッツ! んで、getConstructor(Class[])で、コンストラクタをゲッツゲッツ! そして newInstance(Object[]) で、インスタンスを生成してゲッツゲッツゲッツ!

はぁ… はぁ…

すげーぞJava!これ便利すぎ!ぶっちゃけありえなーい!!
という事で、Box に追加。

■ 追加: Box
static な getBox(String classname, Field field, Point pos) メソッドを持つ。classname の Box を、field と pos を使ってコンストラクタを呼んでインスタンスを返すファクトリーメソッド。
つまり、Box の派生クラスは (Field, Point) のパラメータで呼べるコンストラクタを提供する。

次に、主人公。まー、主人公はほとんど考える所ないか。

■ Keeper
主人公(倉○番)を表すクラス。
コンストラクタで、初期位置を設定。荷物と同じく、位置はゲッタだけ提供して、動かすには Move(direction) で。Key に接続できるように、Observer を継承。Key から Update されたら、渡された方向へ Move する事にしませう。
Move する時に、移動先に Box があれば、Pushしてみる。true が返ってきた(動かせた)ら、移動する。
Box と同じく、移動先の問い合わせを Field にするので、コンストラクタで Field も渡す必要があるな。

このぐらいでしょうか。あとは、GUI部分だけど、この辺は後で考えるとして。
interface の使いどころが思いつかなかったのが心残り。実装の時に思いつくかも知れないですけども。
ってか、UMLで描くべきか…。ごめんなさい、UMLは勉強中で、描くのに時間がかかりすぎです。orz
何か良いアイデアがあればコメントください。戯言

Posted at 00:28 / 30 Comments / 0 TrackBacks / Category : Study

20 Apr 2005 :: Javaで倉○番らしきものを作ります宣言

デザイン弄りも切りがいい所まで出来たので、そろそろ本格的に始動せねばなるまい!
というわけで、課題を決めてしまう事にした!
追い込まないとやらない自分だから!!

……と、ハイテンションでお送りしたわけですが、
ここでふと筆が止まる。

なにつくろっかなー

使う言語はJavaでいいとして、GUIかCUIか。
やっぱり言語に慣れるには、GUIをやるべきなのだろう。黒字に白いものがチラチラ動いたって面白くとも何ともない!(DOS時代を全否定)
しかし、GUIだけでかなりの苦戦が予想される。つまり、ゲーム自体は単純なものがいいかも。リアルタイムで動くような物は難しそうなので、次の機会に。
理想は、GUIで面白くてすごくて、全米が泣いて、都市伝説とか作っちゃうぐらいのゲームがいいんだけどー…… 無理な話なので、「倉庫○みたいなもの」。

「倉○番」なら、GUIで作れるし、構造・アルゴリズムは単純だし、ルールを知っているから形にしやすいし、キープッシュによるイベント駆動で作れるし、作るクラスも少なそうだし。

んで、何でその「○庫番」を伏字にしているかっていうと、商標がありそうだから。なので、ゲームのタイトルは、安易に英訳して「Storekeeper」にしてみる。

Storekeeper が英語的に正しいかどうかは確かめない。めんどいから!
実際の設計は明日から始める。眠いから!!(そして元のテンションへ)以下、戯言

Posted at 00:03 / 0 Comments / 0 TrackBacks / Category : Task

19 Apr 2005 :: トラックバックのテスト

というわけで、トラックバックのテスト。
こんなドマイナなブログにトラックバックが来るわけ無いので、じさくじえーん。
それにしても、デザインいじるのは、結構楽しいなぁ。

Posted at 23:10 / 1 Comments / 0 TrackBacks / Category : Mutter

18 Apr 2005 :: Seesaaで自作HTMLカスタムしてみたの

Seesaa のヘルプでは、さわりでしかHTMLの自作について触れられておらず
サーバーサイドスクリプトの文法がわけわかめな状態で、
試行錯誤、五里霧中でここまでいじった。すげーしんどい。
もうちょっとまともなリファレンス用意してくれよな。プンプン。

なーんか、よくあるブログのデザインは個人的に好きじゃないので、
原型をとどめないほど弄っちゃいました。テヘ☆
まだまだ弄ってない部分とか、やりたい事はあるけど、とりあえず満足してみる。

工夫したところ。
・もーいっそのことカテゴリは上に置いちゃえ!という投げやりな工夫
・こうなったら検索フォームも上じゃーい!という投げっぱなしな工夫
・カレンダーも(ry
・カレンダーは一列にしてみた。まあ、曜日がわからないので、カレンダーとは
 到底呼べない代物なわけだが。
・カテゴリーを使って、色分けしてみた。(前の記事は緑だけど、これはオレンジ)
・そのほか色々。

えー、ウェブデザインなんて大嫌いだー!
な、自分なので、画像を一切使わず、スタイルシートでお茶を濁してみる。

パトラッシュ… 僕、なんだか疲れたよ……

Posted at 16:16 / 19 Comments / 9 TrackBacks / Category : Study

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。