Hatena::Groupgamehell

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

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

2008-10-27

[]音楽素材を公開しました 11:18 音楽素材を公開しました - ゲームプログラムめも日記 を含むブックマーク はてなブックマーク - 音楽素材を公開しました - ゲームプログラムめも日記 音楽素材を公開しました - ゲームプログラムめも日記 のブックマークコメント

最近、暇さえあればACIDでループ作って遊んでたのですが、

それなりに数がたまってきたので、公開します。

  • 音楽素材

自作のゲームなんかに、自由に組み込んでやってくだちゃい。

改変も自由です。

まあ「これ、使えるのか」なんてのもありますが。

DK_alphaDK_alpha2008/10/27 12:30おお、聞かせてもらいます。

kenmokenmo2008/10/27 13:21あまり単体で聴くものではないんですけど、気に入ったものがあれば嬉しいですね

masa_no_pagemasa_no_page2008/10/27 18:54お邪魔するの2度目の者です。
やわらかライセンスの作品から"改造したりイジったバージョン"を作った場合はやわからライセンスに準拠しなければならないのでしょうか?自分の著作物として扱うことはできますか?

kenmokenmo2008/10/27 19:33うーん、やわらかライセンスはその部分が良く分からないですね、、。
今回の音楽素材は、自分の著作物としてOKですよー、
としか言えないです。スミマセン

DK_alphaDK_alpha2008/10/27 20:44手を入れた物のライセンスは自分で決めてよいと思っています。自分の著作物についてあれこれ言わないから自由にやっていいよ、というライセンスなので逆にこちらから指定する事もしないつもりです。

masa_no_pagemasa_no_page2008/10/28 00:46なるほど、了解しました。

o_megao_mega2008/11/01 16:24僕も同じ方針です。派生した場合も制約はつけてないので、ライセンス変更でもどうぞどうぞという感じです。

2008-09-08

回転回転るーぷるーぷ by 鏡音リン 09:49 回転回転るーぷるーぷ by 鏡音リン - ゲームプログラムめも日記 を含むブックマーク はてなブックマーク - 回転回転るーぷるーぷ by 鏡音リン - ゲームプログラムめも日記 回転回転るーぷるーぷ by 鏡音リン - ゲームプログラムめも日記 のブックマークコメント

ボカロ買いました。

とりあえず、実験がてらにムービーを作ってみたよ。

DK_alphaDK_alpha2008/09/08 11:44また新しい事始めましたね。

kenmokenmo2008/09/08 12:17押忍ッ! 日々精進します。

wang-zhiwang-zhi2008/09/08 22:48ボーカロイドでアレンジとは、考えてませんでしたよ
歌詞を考えるとこで挫折しそうです

kenmokenmo2008/09/09 11:19作詞は、のせたい歌詞があってもリズムにのらなくて、泣く泣く削ったりとかして大変ですよね~。

あと、聴音できない人なので、ピスコラのデータがあって助かりました。ありがとうございますー o(. .)o

2008-08-08

[] ゲームのはこづめVol.7 15:30  ゲームのはこづめVol.7 - ゲームプログラムめも日記 を含むブックマーク はてなブックマーク -  ゲームのはこづめVol.7 - ゲームプログラムめも日記  ゲームのはこづめVol.7 - ゲームプログラムめも日記 のブックマークコメント

今年も出ますよ、ゲームのはこづめVol.7。

http://maglog.jp/alpha-secret-base/Article349074.html


kenmoは、えぐぜりにゃ~の改造の「えぐぜりにゃ~BOOST」で参加させていただきます。

かなりやっつけで作ったのですが、

D.KさんやOMEGAさんの力を借りて、何とか形になりました。

ありがとうございますー。


あと、ニコニコにプレイ動画をアップしておきましたので、

気になる方はチェックしてみてくださいなー。



以上、宣伝でちた。

DK_alphaDK_alpha2008/08/08 18:10実はあの後BOOSTの再調整版、BOOST_Rも収録しました。
なれないHSPで作成したのでkenmoさんも楽しみにしていてください。

kenmokenmo2008/08/08 20:41なんと、D.Kさん自ら!
はいー、楽しみにしていますよー

2008-03-16

[]レベルデザインの手順 19:12 レベルデザインの手順 - ゲームプログラムめも日記 を含むブックマーク はてなブックマーク - レベルデザインの手順 - ゲームプログラムめも日記 レベルデザインの手順 - ゲームプログラムめも日記 のブックマークコメント

昨日、D.Kさん宅でレベルデザインの話を色々としてました。

で、思ったのが、ある程度決められた手順で作業を行えば、

ある程度のクォリティを保てるのではないかと。

 

D.Kさんによると、レベル作成の手順としては、

  1. レベル作成
  2. レベルそのもの調整
  3. レベルの前後関係の調整

というフローになるのかなと。

 

レベル作成とは、「アイデア出し」の段階。

あまり極端な制限をかけずにレベルを作成します。

(※システムエラーになるとか、ステージコンセプトから外れるとかでなければある程度許容する)

 

そして、次に、作成したレベルを調整する段階。

プレイヤーの移動量に対してステージが広すぎるので、コンパクトにする、とか、

ステージギミックの視認性が低いので、分りやすいところに移動させるとか、

細かい調整をします。

 

最後に、レベルの前後関係の調整。

複数人にレベル作成を依頼した場合、難易度曲線がバラバラになることがあります。

また、どうしてもレベル作成にのめりこんでしまうと、

前後関係が不自然なつなぎ方になったりします。

 

なので、それらを自然につながるように、調整・もしくは並び替えします。

 

 

このフローは1回で終わりではなくて、

何回も繰り返すようにするとクォリティは上がっていくのではないかと思います。

 

……まー、あまりやりすぎてもコスト(作業)に対する効果は低減していくので、

ほどほどに止めておくのがいいのですがー。


[]影之伝説感想 19:12 影之伝説感想 - ゲームプログラムめも日記 を含むブックマーク はてなブックマーク - 影之伝説感想 - ゲームプログラムめも日記 影之伝説感想 - ゲームプログラムめも日記 のブックマークコメント

影之伝説 -THE LEGEND OF KAGE 2-

影之伝説 -THE LEGEND OF KAGE 2-

アイテム探索

  • アイテムがどこにあるか目印がない
    • 見つけたとしても「偶然」発見しただけなので達成感が薄い
    • 回復アイテムが「全快」しかない

ステージ(マップ)

  • 全体的に密度が低く、単調。明らかに調整不足
  • マップが広すぎる
    • 全体の構造がつかみにくい
      • 一定の区切りで雰囲気を変えたり、目印を置くべき
    • 移動時間(=何できない時間)が多くなり退屈になる
  • プレイヤーの移動量に対して、極端に狭い足場がある
    • 足場に乗りづらい

ステージ()

  • スコアコンボをつなぐしかやることがない
    • なので大ジャンプ+空中ダッシュ or スライディング連打で、倒さずに通り抜ける、の1択になる
    • を倒してHPが少し回復するアイテムとかあれば、を倒す意味がでてくるのですが……
  • を配置しすぎ
    • ここはを配置せず、ジャンプアクションを楽しませても良いのでは? というところがいくつかある
    • 特に瓦礫が降ってくるところでも、が多く配置してあり、情報量が大きすぎて対処できなくなる
  • 飛び道具(特に手裏剣)の視認性が低い
    • サイズが小さい、色が目立たない

クリア評価

  • スコアコンボでしか評価されない
    • コンボゲー
    • つまり、コンボ以外の行動が評価されない
      • コンボ以外やることがないので、単調で退屈
        • かっこいいアクションを決めたら「○○ボーナス!!」とか出せば、目標を提示できたはず

  • 攻撃系の術が多いが、使い道のないものが多い
    • 補助系の術安定というのは地味
    • 雪華でコンボを増やすとかマニアックすぎw たいていのユーザーをそんなことに気がつくことはないはず
  • 術合成
    • 作成して今使える術の一覧がないのが不便(一覧性がない)

スキル

スキル取得条件がプレイヤーに全く知らされない。ので、取得しても理由が分らず達成感が薄い。

(理由が分らないのに褒められて嬉しいのか? ということです)

ただ、スキル取得条件は、「特定の行動回数の蓄積」なので、

原因が分ったら分ったらで、ひたすらジャンプボタン連打とかで作業になるので、

条件は隠しでよかったのかもしれませんが……。むー。

  • 分身
    • 法力が継続的に減る。コストのわりにあまり使い道がない
  • 影の手裏剣が弱い
    • 攻撃力の比率として、手裏剣1:刀5ぐらい
    • 手裏剣5回当てるのが、刀1回当てるのと同じでは、手裏剣を使う意味があまりないのでは、、。
      • (つまり、手裏剣を4回当てるよりも、刀1回当てる方が評価が高い)
  • 千尋の分銅の初期能力
    • 射程が伸びると強いのだけれども、
    • 初期能力では射程が短く使い続ける動機が弱い
      • (使い続けると射程距離が伸びる)

ボス

  • 全般的に硬すぎ
    • 千尋(攻撃力が高い)ベースで体力が決まっているような感じ?
      • ボスを攻撃したときのHPバーの減りの少なさに、げんなりしてしまう
    • ボスラッシュがしんどい(体力半分にしても良かったのでは?)
  • 天守のお面のナパーム弾が、、
    • 炸裂する方向が分りにくい
    • 分っても回避が間に合わない
  • 雪乃介だけ空中コンボが入る
    • 入るのはいいのだけれども、空中コンボが入るのを知らないと勝てないのはどうかと、、
  • 妖四郎の攻略がわかりづらい
    • 分身の攻撃や突進のスピードが速く対処しづらい
    • ①刀で剣をはじく⇒②はじいた剣をさらに刀ではじく⇒③妖四郎にダメージ、というのは手順が複雑すぎる
      • 最初は刀で剣をはじいたら、そのまま妖四郎に飛んでいってダメージ、でもよかったのでは

 

面白いところ

  • プレイヤーの起動性能が高く爽快
    • パラメータ(攻撃の硬直や攻撃ヒット感、慣性の働き方)がかなり調整されている
  • なんだかんだでボス戦は、パターン・弱点を見つけるのが楽しい
  • 術合成はいい意味で悩む
    • 置くことができる元素の玉の数が多すぎず少なすぎず
  • コンボゲーと割り切れば、楽しい
    • できることはコンボしかないが、よけいな要素(パズルとか)がないので、それに没頭できる
  • 音楽がよく考えられている
    • 初代影の伝説のメインBGMのコード進行が多くの場面で使われていて統一感がある
    • 道中のBGMとボスのBGMで同じ伴奏が使われていたり(メロが違う)と、シーン前後のつながりがスムーズ

ekieki2008/04/25 04:35DK氏がどう言っていたかは知らないけど、もともと提案したのは俺の案のはず。そのうち語りましょう。

2008-01-23

うねうね

[]多関節の作り方 00:43 多関節の作り方 - ゲームプログラムめも日記 を含むブックマーク はてなブックマーク - 多関節の作り方 - ゲームプログラムめも日記 多関節の作り方 - ゲームプログラムめも日記 のブックマークコメント

多関節を実現する方法は、

  • CCD
  • インバースキネマティクス(IK)

などの方法があるみたいです。

まあ、シューティングゲームアルゴリズムマニアックス (C magazine)

IKでの実装方法がのっているので(w

IKでやってみます。

インバースキネマティクスとは?

末端部分の位置を先に決めて、
その関節の末端位置を実現するための
親となる関節の角度を
簡易的に逆計算する手法

とのことです。(Wikipediaより)

多関節の目的

例えば、触手みたいなものを作るとします。

f:id:kenmo:20080124003803p:image

丸いのを関節とします。

「根元」は壁に固定されています。


で、やりたいのは、

「先端」をプレイヤーめがけて移動させる方法です。

ここで、「先端」をそのままプレイヤーに移動させてしまうと、

関節と関節の間の距離が離れてしまいます。

まあ、触手であれば、それでもいいのですが、

これが人間(か何かの生物)の場合、不自然に腕が伸びてしまい、

リアリティがなくなってしまいます。

つまり、

  • 関節と関節との「距離を固定」したままで、目標めがけて移動する

のが多関節の目的です。

IKの処理手順

  1. 「先端」から「根元」に向かって、
    1. 「先端」の位置を動かしながら、
    2. 各関節の「角度」を決める。
  2. 1-2によって決まった角度を元に、「根元」から「先端」に向かって、各関節の「座標」を求める。

というのが大まかな手順となります。

f:id:kenmo:20080124003830p:image


1は、「先端から回転させる」ということです。

「? 根元から回転させてもいいのは?」

と思うかもしれませんが、例えば、机にあるリンゴを取る動きを考えたとき、

f:id:kenmo:20080124003854p:image

人は、①の関節を回してリンゴを取ろうとするよりも、まずは②の関節を回してリンゴを取ります。

そのほうが運動量が少なくて済むからです。

(②の回転のみで届かない(回転角度の限界を超えたなど)場合に、①を回転します)

つまり、自然な動きをするためには「先端」から回す必要があります。

(※注:ちょっとこじつけ入ってます。たぶん計算の負荷を低くするためらしいのですが、kenmoにはよく分りませんでした……(´Д`;)


2は、「根元から座標を決めていく」ということです。

各関節の「角度」が決まった際、「先端」から座標を決めると、

各関節よりも先端の方にある関節の座標を再計算する必要が出てくるからです。

f:id:kenmo:20080124003921p:image

角度を決める

先端にある関節の方から、「先端」を除いた全ての関節について「角度」を求めます。


と、その前に、念のために……。

関節の「角度」というのは、根元に近い関節との角度に対する相対的なものです。

f:id:kenmo:20080124003938p:image

2の関節の角度とは、1と2を結んだ線(緑色)と、2と3を結んだ線(赤色)からなる角度のことです。


回す方向の候補は3つあります。

  • 回らない
  • 右に回す
  • 左に回す

f:id:kenmo:20080124004009p:image

これら3つの操作によって、「先端」が最も目標に近くなるものを選択します。


で、計算ですが、真面目に座標を回転させて、距離を求めて、、

というやり方でもいいのですが、内積を使うと簡単に決めることができます。


f:id:kenmo:20080124004032p:image

まず、関節から目標へのベクトルを求めます。(赤い線)

これをXベクトルとします。


次に、関節から先端へのベクトルを求めます。

「回らない」「右に回す」「左に回す」それぞれのベクトルをA・B・Cベクトルとします。

(※「回らない」のベクトルを求めれば、回転行列をかけることにより、ベクトルを回転できます)


そして、A・B・CベクトルとベクトルXとの内積をそれぞれ求めて、

最も値が大きい(作られる角度が小さい)操作が、目標に一番近いものとなります。


そして、、、

ここが大きなポイントですが、

決まった角度を元に、「先端」だけ動かしてしまいます。

この時点では、関節は角度だけ決めて動かさずに、「先端」だけは動かしてしまいます。


そんな感じで、先端にある関節の方から、「先端」の座標を動かして、

その座標を基準に、根元にある関節からみて、より目標に近い方へ回転して、また「先端」の座標を動かす、、、

という作業を繰り返して、それぞれの回転角度を決めていきます。

関節の座標を決める

関節の角度が全て決まったら、それに基づいて、関節の「座標」を求めます。

まあ、これは簡単で、単純に直前(「根元」に近い側)の関節の座標と角度から、

自身の座標を決定するだけです。


ソースコード

D言語で実装すると、こんな感じです。

(Hell_sin()/Hell_cos()は、それぞれmathライブラリのsin/cosと同じです)

/**
 * 多関節ノード
 */
class Node
{
public:
	float x;   // 座標(X)
	float y;   // 座標(Y)
	float rad; // 回転角度
	this(float x=0, float y=0, float rad=0)
	{
		this.x   = x;
		this.y   = y;
		this.rad = rad;
	}
}

/**
 * 多関節用ベクトル
 */
struct JointVector
{
	float x; // X成分
	float y; // Y成分
	float n; // 内積の結果
	/**
	 * 内積を求めて結果を保持する
	 */
	void dot(float dx, float dy)
	{
		n = x*dx + y*dy;
	}
}

/**
 * 関節の移動(Inverse Kinematics)
 * @param nodes    関節([0]根元~[$-1]先端)
 * @param vRad     関節の回転角度
 * @param lRad     回転角度の限界値
 * @param distance 関節間の距離
 * @param x        目標座標(X)
 * @param y        目標座標(Y)
 */
void MoveJoints(Node[] nodes, float vRad, float lRad, float distance, float x, float y)
{
	{
		float cos = Hell_cos(vRad);
		float sin = Hell_sin(vRad);
		// 前半の処理(回転角度を求める)
		Node nTip = nodes[$ - 1]; // 先端ノード
		// 先端⇒根元
		// リバースイテレート。先端ノードは処理しない
		for(int i = nodes.length - 1; i >= 0; i--)
		{
			Node n = nodes[i];
			// 関節から自機へのベクトルの計算
			float dx = x - n.x;
			float dy = y - n.y;
			// 関節から先端へのベクトルと内積の計算
			JointVector jNode;
			jNode.x = nTip.x - n.x;
			jNode.y = nTip.y - n.y;
			jNode.dot(dx, dy);
			
			// 右回りのベクトルの計算
			JointVector jRight;
			if(n.rad + vRad <= lRad)
			{
				jRight.x = cos*jNode.x - sin*jNode.y;
				jRight.y = sin*jNode.x + cos*jNode.y;
				jRight.dot(dx, dy);
			}
			else
			{
				// 限界を超えたので回せない
				jRight.n = jNode.n;
			}
			
			// 左回りのベクトルの計算
			JointVector jLeft;
			if(n.rad - vRad >= -lRad)
			{
				jLeft.x =  cos*jNode.x + sin*jNode.y;
				jLeft.y = -sin*jNode.x + cos*jNode.y;
				jLeft.dot(dx, dy);
			}
			else
			{
				// 限界を超えたので回せない
				jLeft.n = jNode.n;
			}
			
			// 回転方向の選択
			// 内積を比較して、回転を3通りのなかから選ぶ
			// 先端を回転させて、新しい先端の位置を求める
			if(jRight.n > jNode.n && jRight.n > jLeft.n)
			{
				// 右回り
				n.rad  += vRad;
				nTip.x =  n.x + jRight.x;
				nTip.y =  n.y + jRight.y;
			}
			if(jLeft.n > jNode.n && jLeft.n > jRight.n)
			{
				// 左回り
				n.rad  -= vRad;
				nTip.x =  n.x + jLeft.x;
				nTip.y =  n.y + jLeft.y;
			}
		}
	}
	
	// 後半の処理(座標を決める)
	float px = distance;
	float py = 0;
	// 根元⇒先端
	// 根元は移動しない
	for(int i = 1; i < nodes.length; i++)
	{
		Node n1 = nodes[i-1];
		Node n2 = nodes[i];
		float cos = Hell_cos(n1.rad);
		float sin = Hell_sin(n1.rad);
		float dx  = cos*px - sin*py;
		float dy  = sin*px + cos*py;
		n2.x = n1.x + dx;
		n2.y = n1.y + dy;
		px   = dx;
		py   = dy;
	}
}

ついでに成果物も置いておきます。

http://www5f.biglobe.ne.jp/~kenmo/dest/d/multi-joint001.zip