-- / --
--
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

09 / 28
Sat

ちょっと Java を触ってたので、 いろいろメモしておきます。

まず、 真偽値 (Boolean オブジェクト) の値の反転なんですが、 最初はこんな感じで書いてました。

if (boolean) {
  boolean = false;
} else {
  boolean = true;
}

はい、 長くて鬱陶しいですね。 ということで、 良い方法はないかと調べてみたのですが、 普通に良い方法がありました。

boolean ^= true;

そんな演算子を使おうなんて思いつきませんって。 あ、 boolean = !boolean っていう記法もあるんですが、 これは変数名が長くなったとき鬱陶しいですし、 同じ変数名が 2 回も出てきて見た目が悪いので、 私は使いません。

さて、 もう 1 つなんですが、 FontMetrics クラスの getAscent メソッドが正しい値を返してくれないみたいです。 調べてみると Java 1.0 の頃からのバグみたいで、 どうやら getMaxAscent メソッドと同じ値を返しているようです。 仕方なく私のコードでは、 手動で値を加算したりして修正してますが、 あまり良い方法ではありませんね。 これは結構困ってます。 コードの美しさ (自分なりの美しさですが) にもこだわってるので、 こういうのがあると落ち着けないんですよ。


スポンサーサイト
comment ×0
09 / 27
Fri

さっき描いた樽がどうも納得がいかなかったので、 何が原因か考えていたんですが、 色の使い方なんじゃないかと思いました。 そこで、 パレットの配色を少しずつ変えてみて、 印象がどう変わるか実験してみました。 結果がこれです。

614_樽パレット変え

1 個目が最初に描いた樽です。 2 個目は、 赤を強めにして再度を上げ、 さらに黒のコントラストを上げました。 3 個目は、 全体的に彩度を下げて淡い感じにしてみました。 最後の 4 個目は、 樽の明度を落とし、 箍 (っていうらしい) を金色にしてみました。 Google で樽の写真を調べたら、 ここが金色になってるやつがあったんですよね。

みなさんはどれがお好みですか。 ちなみに、 変えたのはパレットだけで、 ドット絵の打ち直しは一切行っていません。

思い返すと、 色については結構適当に決めてたんですよね。 今度からは、 描いた後に色の調整もきちんとやってみますか。


comment ×0
09 / 27
Fri

Java の話が続いたので、 ドット絵を。 ニコニコ動画をちょっと眺めたら、 タイムラインにドンキーコングの動画があったので、 樽を描いてみました。

616_樽

下手ですねぇ・・・。 いや、 丸みとか陰影とか色合いとか難しいかったんですよ。 にしても、 他のに比べると格段にクオリティーが劣っていますね。 これは描き直しかなぁ・・・。

そのうち描き直します。 あ、 ピアノも少し修正入れないと・・・。


comment ×0
09 / 25
Wed

キーボードからの入力を検出しなきゃいけないなーと思って、 その方法を調べてみました。 KeyListener インターフェースを実装すれば良いみたいです。 そうすると、 キーが押されたときや離されたときに特定のメソッドが呼ばれ、 キー入力が検出できるわけです。

んー、 StarRuby では、 Input モジュールを使ってコードの好きな位置でキー入力の検出ができたんですが、 Java じゃ無理みたいです。 ということは、 キー入力の検出だけまとめなきゃいけないんですね。 全然問題はないんですが、 慣れてないだけに違和感を感じます。


comment ×0
09 / 23
Mon

Java でゲームを作ることになって、 これまで勝手にやってくれていたことを自前でやらないといけなくなりました。 例えば、 FPS の維持とか。 StarRuby では、 メソッドの引数に FPS の値を渡してやるだけでよかったんですが、 Java では全部自分でやらないといけないんですよね。

ということで、 FPS を一定に維持してくれるクラスを作ってました。 仕組みはそんなに難しくないです。

クラスのフィールドとコンストラクタはこんな風になっています。

private Integer idealFps;
private Long realFps = 0L;
private Integer idealSleepTime;
private Long oldTime = 0L;
private Long errorTime = 0L;
private Long sleepTime = 0L;
public FpsSleep(Integer fps) {
  idealFps = fps;
  idealSleepTime = 1000000 / idealFps;
  oldTime = System.currentTimeMillis();
}

idealFps は設定する FPS、 idealSleepTime は 1 フレームの待ち時間 (ミリ秒) の 1000 倍です。 固定小数点数を扱うため、 時刻や時間を扱う変数には全て 1000 倍された数値が入れられます。 errorTime は待機時間の誤差です。 これについては後で説明します。

さて、 クラスの使い方ですが、 画像の描画やオブジェクトの更新を行う前に、 以下の start メソッドを呼び出します。

public void start() {
  oldTime = System.currentTimeMillis();
}

処理前の時刻を oldTime に保存してるだけです。 そして、 1 フレーム分の処理が終わったら、 以下の finish メソッドを呼び出します。

public void finish() {
  Long newTime = System.currentTimeMillis();
  sleepTime = (idealSleepTime + errorTime - (newTime - oldTime) * 1000) / 1000 * 1000;
  if (sleepTime < 1000) {
    sleepTime = 1000L;
  }
  errorTime = (idealSleepTime + errorTime - (newTime - oldTime) * 1000) - sleepTime;
  if (errorTime < 0L) {
    errorTime = 0L;
  }
}

まず、 現在時刻を newTime に代入します。 次に、 待機すべき時間を sleepTime に代入しています。 処理にかかった時間は newTime - oldTime で得られるので、 この分を 1 フレームの待ち時間である idealSleepTime からひいてやれば、 待機すべき時間が求まります。 最後の / 1000 * 1000 というのは、 百の位以下を切り捨てて 1000 の倍数にしているだけです。 実際に待機するミリ秒数は整数ですから、 1000 の倍数にしておかないといけませんからね。

さて、 では errorTime は何なのかというと、 1000 の倍数に切り捨てられた誤差が格納されています。 例えば FPS が 60 に設定されているとすると、 処理と待機を合わせて 1 フレームは 16.666 ミリ秒になります。 しかし、 実際に待つのは 16 ミリ秒なので、 1 フレームごとに 0.666 ミリ秒の誤差が生まれます。 この誤差によって、 FPS が正確に 60 に保たれなくなってしまうわけです。 そこで、 誤差の 0.666 ミリ秒を errorTime に保存しておいて、 次のフレームの待ち時間を計算するときに、 1 フレーム分を 16.666 ミリ秒ではなく、 誤差をたし合わせた 17.332 ミリ秒として計算するわけです。 すると、 ここでは 1 フレームは 17 ミリ秒となり、 誤差 0.332 ミリ秒がまた次のフレームに持ち越されます。

さて、 これで理論上はうまくいくはずなんですけどね、 FPS を 60 に設定して動かしてやって、 実際の FPS を計測すると 57 くらいで安定するんですよね。 何でですかね。 ちょっとよく分からないんですよね・・・。


comment ×0
09 / 17
Tue

ちゃぶ台描きました。 よくひっくり返されるあれです。

604_ちゃぶ台

もの寂しかったんで、 丸い方には植物を載せておきました。 いや、 Wikipedia のちゃぶ台の写真に植物置いてあったんで・・・。

全然関係ない話ですが、 「ちゃぶ台」 の 「ちゃぶ」 って語源よく分かってないみたいですね。 一説には、 中国語でテーブル掛けを意味する 「卓袱」 が由来らしいです。 ちなみに、 英語では 「low dining table」 というらしいです。


comment ×0
09 / 16
Mon

本棚と箪笥に続き、 収納シリーズです。

603_収納器具

扉を開くタイプの収納家具。 もの足りなかったので、 上によく分からない箱らしき何かを置いてみました。 箱というか、 本にも見える。 何でしょうね。 特に何かを描こうというわけでもなく描いたので、 あまり意味はないです。


comment ×0
09 / 16
Mon

何の変哲もない木です。

7250.png

木の葉っぱの部分の表現をいろいろなサイトで学んできました。 いろいろありましたが、 自分にしっくりくるもので描いてみました。 これは広葉樹っぽい感じです。 針葉樹っぽい感じの木も描きたいですね。


comment ×0
09 / 15
Sun

これまで描いたドット絵を並べてみました。 1 マスは 24×24 です。

602_表示テスト

こうして見ると、 何だかもともと 24×24 用に描いたんじゃないかってくらいしっくりきますね。


comment ×0
09 / 15
Sun

やっぱり、 マップの 1 マスを 24×24 にしようかなーと考えています。 これまで描いた本棚とかピアノとかは、 横のサイズが 20 なので、 1 マス 20×20 にすると隣接しちゃって窮屈なんですよね。 実際に並べてみて確かめたりもしたんですが、 やっぱり 24×24 の方が良いですね。

メジャーな 24×24 にしなかったのは、 このサイズでうまく描ける気がしなかったからなんですが、 何とかなりそうなので 24×24 にしましょうかね。


comment ×0
09 / 14
Sat

ということで、 横 2 マス分のピアノ描きました、 いや、 描いている途中です。 40×30 の 15 色です。

7401.png

難しすぎますよ。 というか、 ほとんどが黒なんで部分の強調が難しすぎます。 どこが譜面台でどこが支柱なんだか、 微妙です。 それに加えて、 奥行きとかも表現するのが難しいです。 5 色じゃきついって・・・。

え、 黒鍵の配置がおかしい? 気のせいですよ、 気のせい。


comment ×0
09 / 13
Fri

最初のエントリーで、 ゲームの開発は Ruby 1.9 を用いて行うと言いましたが、 Ruby はやめようかなと思います。 というのも、 ライブラリに StarRuby を用いてるんですが、 機能が多いとは言えず、 更新がおそらく停止していて今後の機能追加はないと思われるためです。

そこで、 何を使うか。 Java です。 ちなみに、 Java でゲームを作ろうとするのは 5 回目ですが、 過去 4 回は完成に至るというか作成開始にすら至る前に挫折しました。 Java の文法がどうも合わなくて、 どうしても Ruby でやっちゃうんですよ。 まあ、 今回ももしかすると Ruby に戻るかもしれませんが、 Java でやっていこうと思います。

そういえば、 家具アイテムとしてピアノとか追加しようと思ったんですが、 横幅 20px (1 マス分) じゃどう考えても入りきらなくて、 どうしようか考えてたんですよ。 そしたら、 そもそも 1 マスに抑える必要ないじゃないですか。 横幅 2 マスとか使ってもいいわけですよ。 まあ、 家具が重なった場合とか、 いろいろと内部の処理が面倒になるのは確かですが、 大きい家具は 1 マスに詰め込むのは不自然ですからねぇ・・・。


comment ×0
09 / 11
Wed

今さらながら、 マップチップの 1 単位を 24×24 にしておけば良かったと後悔。 16×16 じゃ小さすぎるし 24×24 じゃちょっと大きいかなーとか、 そんなこと思って 20×20 という微妙なサイズにしてしまったんですけど、 24×24 でも別に良い気がしてきました。 24×24 なら、 そのまま素材として配布もできるかもしれませんし、 一石二鳥じゃないですか。 20×20 とか需要なさそうですしねー。 といっても、 24×24 に直す時間がないですし、 このままにするでしょうけどね。

さて、 久々に武器アイコンに戻ってきて、 弓です。

598_長弓

弓の曲線って難しいんですねー。 最初適当に描いたら、 円弧に弦引っ張っただけのよく分からないただの図形になってしまって焦りました。

さて、 このまま弓と銃を描いていこうかな。


comment ×0
09 / 10
Tue

十字架の置物です。

597_十字架

前に描いた本棚と同じサイズという。 そう考えると大きい・・・、 のかな。 あ、 人間と同じ 20×30 サイズだから結構大きいですね。

これまで自分で打ったドット絵見てると、 なんか雰囲気がやわらかいんですが、 どうしてでしょうね。 他のゲームとかにでてくるドット絵に比べて、 こう、 何というか、 やわらかい雰囲気というか・・・。 まあ、 感じ方は人それぞれでしょうけどね。


comment ×0
09 / 10
Tue

前にいちごを描いたので、 フルーツをそれなりに揃えました。 描いたのは今日じゃないんですけどね。

597_フルーツ

みかんとりんごとレモンを追加しました。 りんごはよく見れば分かりますが、 色数が足りなくてタイルパターンを使ってます。 素直に 1 色追加しても良かったんですが、 けっこううまくいった気がするので、 そのままです。 原則、 1 色相に 5 色で描いていこうと思っています。

次はどうしよう。 それより、 描く時間がもうなさそうだな・・・。


comment ×0
09 / 08
Sun

メダルというか硬貨というか、 を描きました。 いやー、 これまでで一番うまくいかなかった。

595_ゴールド硬貨

メダルって表面に絵とか数字とか彫ってあるじゃないですか。 それを、このドット数で表現するのって至難の業だと思うんですが。 今回描いたのは、 どうやら額面が 5 のようです。

剣とか硬貨とか、 金属が絡んでくるもののドット絵って難しいですね。 金属の光沢をどうやって表現するかとか。 あと、 影もつけるのが難しい。 で、 両方あるのがこのメダルってやつで、 難しすぎます。

仕様上、 もう 2 種類メダル描かないといけないんですけどね。 あまりやりたくないです。


comment ×0
09 / 08
Sun

弓描くとか言っときながら、 本棚を描きました。 ドット絵難しいなぁ・・・。

595_本棚

あ、 あとちょっといじって箪笥。

595_箪笥

基本となる茶色を 5 色だけで描こうとしたら色が足りなかった・・・。 何となくごまかしてみたけど、 どうでしょうかね。 それと、 光の具合とか難しいですね。 他の人が描いた素材とかを参考にしつつ描いてるんですが、 うまくいかないです。 最初は 5 色なんてこだわらずに 7 色とか 10 色とかで描いた方が良いんでしょうかね。

あ、 いちごを打ち直しました。 ・・・というか、 パレットを変えただけですが。

595_いちご描き直し

明度の差異を結構大きくしても良いんだなー、 とか思いました。 むしろ大きくしたほうがそれっぽいかもですね。


comment ×0
09 / 06
Fri

前に描いた武器アイコンを描き直しました。 色数がちょっと多くてよく分からなくなったので、 色相 1 つに 5 色を目安にして色数を減らしています。

593_武器アイコン

パッと見だと何が変わったのか分かりませんね。 剣の剣身の部分が 7 色から 5 色になってたりしますが、 まあよく見ないと分からないです。

あ、 ついでにいちご描きました。 あまりうまく描けなかったけど。

593_いちご

次は弓とか銃でも描くかな・・・。


comment ×0
09 / 05
Thu

ゲーム作るのってプログラミングだけじゃだめじゃないですか。 プログラミングができるだけじゃゲームできないんです。 つまり、 グラフィックをどうするかってことです。

困ったことに、 絵が描けないんですよね。 だから、 せめてドット絵でもと思って、 最近ドット絵を描いてます。

はい、 微妙ですね。 描き続ければうまくなるものなんですかね。 今はプログラミングをするまとまった時間が取れないので、 ドット絵をちまちま増やしていくつもりですが。

構想中の RPG では、 アイテムアイコンが 500 個とマップチップが 100 個ほど必要なんですが、 できるものでしょうか・・・。


comment ×0
09 / 01
Sun

Ziphil と申します。 Ruby 1.9 を用いてゲームプログラミングをしようと思い、 このブログを設立しました。 よろしくお願いします。

過去にいくつかゲームを作ったことがあるのですが、 どれも微妙な感じで終わってしまったので、 今回は 1 つ大作を作ろうと思っています。 ジャンルは RPG で、 最近見つけた 『Elona』 という RPG を目標にしようと思います。


comment ×2
back-to-top
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。