Hatena::Groupgamehell

ゲームプログラムめも日記 このページをアンテナに追加 RSSフィード

けんもほろろ  / オススメゲームプログラム本  / 作ったもの置き場  
ゲーム開発のデザパタまとめ  / めも日記まとめ  

2007-09-28

アスキーコードマップエデ

[]アスキーコードマップエディタ 21:34 アスキーコードマップエディタ - ゲームプログラムめも日記 を含むブックマーク はてなブックマーク - アスキーコードマップエディタ - ゲームプログラムめも日記 アスキーコードマップエディタ - ゲームプログラムめも日記 のブックマークコメント

前々から作ってみようと思っていた、アスキーコードマップを作れるエディタを作ってみた。

いや、まあ、作ったと言っても、Platinumのプラグインですがー。

 

http://www5f.biglobe.ne.jp/~kenmo/dest/tool/ascii.zip

 

この中のDLLをPlatinumの「Plugins」に入れて、ascii形式の「書き出し」をすると、

例えば、こんな感じのテキストファイルが出力されます。

SIZE=400
WIDTH=20
HEIGHT=20
CHIP_WIDTH=32
CHIP_HEIGHT=32
LAYER_COUNT=1
BIT_COUNT=8

####################
#                  #
#                  #
#                  #
#   +              #
#  +++  B A        #
#   +              #
#                  #
#                  #
#      HELL        #
#      2000        #
#                  #
#                  #
#                  #
#                  #
#                  #
#                  #
#                  #
#                  #
####################

 

これで、Platinumを使って編集してもいいし、

テキストエディタを使って編集してもいい、ってなわけです。

追記

改行文字の書き込みがおかしかったのを修正。

// 改行文字書込み
bool WriteFileCRLF(HANDLE hFile)
{
	int val = 0x0D0A;
	DWORD dwWriteBytes;
	if (!WriteFile(hFile, &val, 2, &dwWriteBytes, NULL) || 
		dwWriteBytes != 2)
	{
		return false;
	}
	return true;
}

リトルエンディアンなので、こうですね。

	int val = 0x0A0D;

o_megao_mega2007/09/28 01:06@の不思議なダンジョン!

kenmokenmo2007/10/01 09:33@の冒険が、今、始まる……。

2007-09-27

当たり判定エディタ

[]当たり判定エディタ 12:27 当たり判定エディタ - ゲームプログラムめも日記 を含むブックマーク はてなブックマーク - 当たり判定エディタ - ゲームプログラムめも日記 当たり判定エディタ - ゲームプログラムめも日記 のブックマークコメント

なんか思いつきで、使う予定もないのに作ってみた。

http://www5f.biglobe.ne.jp/~kenmo/dest/tool/hiteditor.zip

 

使い方は、

  1. 画像読込」ボタンを押下
  2. ファイル選択ダイアログから、当たり判定を行う画像を選択
  3. 画像を左クリックして当たり判定をつける
  4. 複数付けたい場合、コンボボックスから別の番号を選択して、左クリックする
  5. 完成したら、「保存」ボタンを押下して、設定ファイルを保存する

です。

 

当たり判定の設定ファイルフォーマットはこんな感じ

[HEADER]
IMAGE=nya.bmp # 画像のパス
WIDTH=128     # 幅
HEIGHT=128    # 高さ
[DATA]
DATA1=1,68,7,50,42
DATA2=1,24,66,48,45
DATA3=0,0,0,0,0
DATA4=0,0,0,0,0
DATA5=0,0,0,0,0
DATA6=0,0,0,0,0
DATA7=0,0,0,0,0
DATA8=0,0,0,0,0

基本はINIファイル形式です。

 

ヘッダ部は、画像パスと幅と高さです。

データ部は、当たり判定のカンマ区切りのCSVデータで、

  1. 使用可否フラグ(0:未使用 1:使用する)
  2. 左上X座標
  3. 左上Y座標
  4. 高さ

という順番で並んでおります。

 

 

これを作った後で気がついたのですが、

Platinumのようなマップエディタでも、

当たり判定エディタとして使えるのではないかと。

 

たとえば、こんな感じで、

f:id:kenmo:20070927122200p:image

キャラ画像を再背面に置いて、

レイヤーで当たり判定チップを置いていけば、複雑な当たり判定ができてしまいます。

 

ただ、当たり判定をしない部分に、「何もないよ」という情報を持つので、

少しだけ冗長なデータ構造となりますが。

 

kenmoの作ったエディタとの違いは、

ベクタ画像ラスタ画像の違いのようなものですね。

2007-09-04

[]アジャイル開発はじめました 12:33 アジャイル開発はじめました - ゲームプログラムめも日記 を含むブックマーク はてなブックマーク - アジャイル開発はじめました - ゲームプログラムめも日記 アジャイル開発はじめました - ゲームプログラムめも日記 のブックマークコメント

最近、「アジャイル開発」というキーワードが気になって、

勉強用に本を買ってみた。

まだ読んだばかりで間違っているかもしれないのですが、

「反復型開発」というものがキモになるっぽい。

 

「反復型開発」とは、

独立したプロジェクト(イテレーション)を連続して繰り返すことにより、
ソフトウェアのライフサイクル全体を構築する

というものみたい。

 

個人でゲームを作る場合、

「要望」や「仕様変更」をその場に合わせてモリモリ組み込んでいくから、

ある意味「反復型開発」ですね。

 

ただ、「要求分析」や「設計」といった計画的な開発・指針があいまい(になりがち)なので、

間違った方向に進みやすいし、進んでも気がつかないことが多いような気がします。

 

 

そこでなるほどと思ったのが、

リスク駆動とクライアント駆動の反復型開発」

の部分。

 

要は、開発の「優先順位」の付け方、みたいなものです。

 

個人で漫然と開発していると、

  • 作りたいものから作っていく

という開発手順になりがちな気がします。

 

ただ、それだと間違った方向に進みやすい。

 

そうではなくて、開発にきっちり「優先順位」を付けていくと、

作るべきものが明確になり、品質が上がる、、、ということで、

 

リスク駆動とは、

  • リスクの高い」ものを優先して作る

という優先順位の付け方です。

 

例えば、

  1. キャラの絵を描く
  2. キャラの当たり判定のルールを考える

という2つの作業があった場合を考えると、、

 

1は後回しでもなんとかなる、

しかし2は先に考えないとゲーム的にクリティカルな問題となる、

だから、2を先にやっておかないと、後で大変なことになりますよ、

今考えるのは面倒だけど、先に考えておくと問題点が早期に発見できますよ、

という考え方みたいです

 

kenmo的には、例えば、カテゴリ適当ですが、

(優先順位高い)
プレイヤートークン
V
ゲームルール(トークン)
V
ゲームルール(勝利敗北条件)
V
パーティクル
V
グラフィック
V
サウンド
(優先順位低い)

こんな優先順位ですね。

 

クライアント駆動とは、

  • 「作る価値の高い」ものを優先して作る

という優先順位の付け方

 

例えば、先ほどのkenmoの優先順位では「パーティクル」が低くなってますが、

 

「もりもりパーティクルしたい!!」

 

という要望があれば、それを優先して作って、

それが満足のいくものであるかどうかを確認したほうが、

より自分が理想とするものに作り上げていきやすい、

という考えのようです。

 

 

 

結論。

作業は

  • リスクの高いもの」
  • 「自分にとって価値の高いもの」

の2つの総和から優先順位をつけて作業していく。

 

でした。

2007-08-25

[]やりこみ要素 03:23 やりこみ要素 - ゲームプログラムめも日記 を含むブックマーク はてなブックマーク - やりこみ要素 - ゲームプログラムめも日記 やりこみ要素 - ゲームプログラムめも日記 のブックマークコメント

やりこみ要素について考察してみます。

 

やりこみ要素とは

やりこみ要素とは、

システムが用意している「ゲームクリアとは別」に、
プレイヤーが継続的にゲームプレイを行う(する価値がある)要素

と定義します。

 

「幅」のやりこみ と 「深さ」のやりこみ

やりこみ要素は大きく2つに分類できるようです。

それは「幅」と「深さ」です。

 

「幅」のやりこみ

幅のやりこみとは、

など、

ゲームクリアには必ずしも必要でない、
「システムが用意している」やりこみ要素

のことです。

 

「深さ」のやりこみ

深さのやりこみとは、

など、

ゲームクリアには必ずしも必要でない、
「プレイヤーの挑戦による」やりこみ要素

のことです。

 

考察

で、ここまでは他のサイトに書いてあることをまとめただけなので、

kenmoなりの考察を入れてみます。

 

難易度の高いゲームは、やりこみゲー?

難易度の高いゲームは、死に要素が多く、リプレイを要求するので、

なんとなく、やりこみゲーと言えそうです。

 

ただ、やりこみ要素の定義で、

ゲームクリアとは別」

としたので、単純には、やりこみゲーとは言えなさそうです。

 

ですが、例えば、難易度の高いゲームでも、

というシステムの場合、ライフ探索要素(ゲームクリアに必ずしも必要ない)

が「幅」のやりこみ要素と言えます。

 

そして、その場合、

ライフを取らずにクリアすることが、高難易度の「制限プレー」であり、

「深さ」のやりこみ要素といえます。

 

 

つまり、難易度の高いゲームでも、

それを変えることができないと、やりこみ要素がない、

となり、

プレイヤーがそれを操作できる場合、

やりこみ要素となる可能性がある、

と言えそうです。

 

あと、アイテム探索要素(幅のやりこみ)と制限プレー(深さのやりこみ)は、

同一のプレイでは成立しない関係にありそうな感じですね。

 

「幅」のやりこみ と「探索要素」

幅のやりこみは、「アイテム収集」や「隠し要素探し」などの

探索要素」が相性がいいみたいですね。

 

 

探索要素」の難易度を高くするには、

など、レベルを作る人が意地悪すれば簡単にできてしまいます。

 

難易度が高いほど、それを乗り越えたときの達成感が大きいので、

やりこみ要素は難易度が高いほど歓迎されます。

 

なので、

探索要素」は、やりこみ要素として組み込みやすい、

のではないかなー? という気がします。

 

(ただ、最近ゲームは安易に「探索要素」をやりこみ要素をして組み込みすぎ ⇒ 飽きられている

 のではないかと思ったりしますがー)

 

 

本編あってのやりこみ要素

やりこみは、本編をクリアしたプレイヤーが、

「うーん、まだ遊び足りないなー」

という不満を満たすものが自然であるような気がします。

 

つまり、

の場合、クリア手前でシステムに飽きられていることが多く、

やりこみ要素は必要ないのかもしれません。

(でも、やらないとボリューム不足という批判がくるんですよねーw

 

 

本編でやれない要素をやりこみ要素とする

例えば、作り手が、

というプレイをしてもらいたいとします。

 

これを本編でやると、高難易度すぎてクリアできない!

というような場合、

クリア後の隠しモードとして、ノーミスクリアモードを用意すると、

やりこみ要素として成立するかもしれません。

 

 

参考