日記

2013年8月17日

とりあえずブログをはじめてみました。
アクセス解析で使っている忍者ツールにあるブログをそのまま使ってみました。
たぶん、コレ以降の日記はそちらへ書くと思います。
ブログ

2013年8月16日(0時)

肘の裏側が痛い。
上腕三頭筋の付け根あたりが痛い。
今朝起きたら妙に痛い。筋を痛めたかな。とりあえず湿布をはってる。
なので今日の日記は少し短めにします。

ブログの件だけど日記をやっぱりブログにしようかと思う。
どこがいいんだろ。
今使ってるレンタルサーバーのブログにするか、アクセス解析で使ってる忍者ツールのブログにするか、
他に評判のよさそうなやつがあればそれにするかもしれない。
ただアップロードできるファイルの種類が限定されていたりするのが面倒だな。
なんかやや大きめのファイルでも置ける場所とかもちょっと探してみる。

HaskellのHOpenGLでBlenderで作った3D画像を表示させようと思ったんだけど、
とりあえずオブジェクトを表示させることを考えてみた。
blenderでエクスポートできるファイルの種類でx3dというファイル形式を選ぶ。
3xdはxmlで記述されていて、そこからIndexedFaceSetのタグに記述されている情報のうち、
pointから座標のリストを得られる。（3つごとに分ければ点のリストが得られる。） coordIndexでリストにある点を使って、面を作っているから（-1が区切り）
それを用いてrenderPrimitiveで面を表示させる。
これで一応いけそうな気がする。
まだ全然やってないけどね。

2013年8月4日

実はちょっと迷ってることがあって、日記だけブログとかにしたほうがいいんだろうか？
いや個人的にはブログ形式でないサイトが結構好きなんだけど
ただこの日記は色々な話題をごった煮にしているのでカテゴライズしたほうが後で確認する場合私自信にとっても便利なんですよね。
カテゴライズする仕組みを作ればいいだけ、と言われたらその通りなんだけどちょっとそれも面倒なので
他はそのままとして、日記の部分だけブログにするかもしれない。

Haskoreをちょっとだけ触ってみた。
Haskoreは音楽を生成するHaskellのパッケージの一つ。
なんかよく分からないままつついていたら出来た。
haskell_prog_haskoretest.zip(Zipファイル)
ソース
katyusha3.txt(ソース)
exeファイルを実行するとmidiファイルが出来ます。

2013年7月24日（深夜）

前回アップしたのを少し変更というか更新。
上のカウントが1000で固定だったんだけど分割数に応じて変化するようにした。
haskell_prog_puzzle2.zip(Zipファイル)
変更したソース
main.txt
MainState.txt
ProgInit.txt
States.txt

importした関数はimport側にも記述したほうがいいかもしれない。使っている関数がどのモジュールから来たのか分からなくなりそうだから。

ソース書いていてふと思ったことなんだけど新しいData型を定義したとき、
その型コンストラクタを使う場所を制限したほうがよさそう。
それは型コンストラクタの定義を変更したとき、型コンストラクタを使っている箇所すべてを変更する必要が出てきて面倒だから。
今回はmainとStatesにしか登場させていない。
たとえばRPGとかを作っていて、キャラクターを扱う型としてCharaを作ったときを考えてみる。


data Chara = Chara{chPosition 	:: ChPosition 
		  , chPara     	:: ChPara
		  , chStatus	:: ChStatus
		  , chTex	:: KeyTexObj
		} deriving (Show ,Eq)

data ChPosition  = ChPosition {   chPos	:: (Vector2 GLint)
				, chMap	:: KeyMapName 
		} deriving (Show , Eq )

data KeyMapName = MFieldA | MFieldB | MTown | MCastle	deriving (Show , Eq ,Ord) -----Mapを指定するキー（左のMapはData.MapのMapという意味ではない）

data ChPara = ChPara { chHp 	:: GLint
		      , chStr 	:: GLint
		      , chDfn	:: GLint	
		      , chAgl	:: GLint
		} deriving (Show , Eq)

data ChStatus = ChNormal | ChDead | ChPoison | ChSleep deriving (Show , Eq , Ord)  

data KeyTexObj = KeyTexMap | KeyTexChara 	deriving (Show , Eq ,Ord) ----Textureを指定するキー

みたいな感じで定義した後、ChParaにchMPを付け加えたいと思ったらChPara型コンストラクタの部分をすべて修正する必要が出てくる。
そこで、新たにChParaを生成する関数をすべてStatesにおいてしまえば、変更が比較的楽になりそう。
あと上のChara型の定義でKeyのためにわざわざ型を作ってるけど、
String型を当てていてもよかったんだけど、キーが自由に定義できる状況にすると、
わけが分からなくなりそうだから型にして最初から制限した。（まぁちゃんと整理して定義すれば問題ないんだろうけど）
あとData.MapのキーになるにはOrd型クラスでなければならないのでderivingにOrdを加えている。
どうやって順序が入るのかは知らないけどおそらく型の名前に対して辞書式順序が入ってるのかな…
確かめればすぐに分かるかもしれないけど、まぁまた機会を見て調べてみよう。

おまけのしょうもない問題

上の図のように半径10の円上に異なる4点A,B,C,Dを AB =8 , CD = 12 , 弧ABと弧CDが交わらないように動かしたとき、
図の灰色の部分の面積が最大となるようなA,B,C,Dの位置関係を求めよ。
ただし単にAB,CDと表記した場合、それぞれ線分AB,CDの長さをあらわすものとする。

実はそんなに難しくないです。やり方は色々あるだろうけど中学生でも解けると思う。
まぁ暇つぶしにでもどうぞ。

2013年7月23日（深夜）

今回作ってみたHaskellプログラムは15パズルみたなやつ。

左下の数字はタイルを置くべき位置。
resetボタンでresetボタンの上の数字の値に分割したパズルを作る。

Cキーで終了。
ウィンドウ拡大には対応してません。

openGLにクリックしたときに得られる座標が左下を(0,0)としていることを知らず、結構手間取った。
前回は具体的な値はどうでもよくてマウスカーソルが動いたか否かが問題だったので
値については気にしなかったため気づかなかった。
まぁ途中で色々考えを変えながら書いたので一貫性のないプログラムです。
あとTextureの集合を以前はtype TexObjGrp = [[TextureObject]] みたいな感じにしていたんだけど
ちょっと今回はData.Mapを使ってみた。
まず　

data TexObjKey = KeyTexTiles | KeyTexReset | KeyTexLine | KeyTexNum | KeyTexAdd   deriving (Show , Ord , Eq)

といった感じにテクスチャを指定するキーのデータ型を作って、

type TexObjGrp = Map.Map TexObjKey [TextureObject]

としている。
TexObjKey とテクスチャのIDでテクスチャが決まるようになってる。
たとえばKeyTexNumで得られるテクスチャのリストは0から9までの数字のテクスチャと×が描かれたテクスチャが入ってる。他にもData.Mapを色々使ってみたんだけど、もっといい構造もあった箇所もあるけど、Data.Mapに慣れていないから積極的に使ってみた。

前書いた気がするけど、偶置換で配置されたものじゃないと解けないので
Resetおよびスタート時のパネルのシャッフルは偶置換になるようにしてる。
つまり互換を定義して、その互換を偶数回にやってる。

あと前回の使いまわしのvectorAddとvectorSubtractとvectorScalarはもしかしたらapplicativeファンクターを使えばよかったかもしれない。

あとボタンをクリックしたかの判定なんだけど

 ((&&) <$> ((<) <$> (vectorSubtract cPos' bPos) <*> (Vector2 bWidth bHeight)) <*> ((>) <$> (vectorSubtract cPos' bPos) <*> (Vector2 0 0))) == (Vector2 True True)

となってて、ちょっとわかづらいんだけど　cPos'　がクリックされたときのカーソルの位置を表すVector2 GLint 、bPos'　がボタンの位置を表すVector2 GLint
((<) <$> (vectorSubtract cPos' bPos) <*> (Vector2 bWidth bHeight)) でcPos'bPosがそれぞれbWidth ,bHeightより小さければ(Vector2 True True)を返す。
後ろの部分も同様にして得られた、(Vector2 b1 b2 ) と　(Vector2 b3 b4)に対して

 ((&&) <$> ((<) <$> (Vector2 b1 b2 ) <*> (Vector2 b3 b4 )

を実行してこれが(Vector2 True True)と一致するかを判定してる。
無理やり一行で書いたらこんな感じになってしまった。
ちょっとまた夜中になってしまったのでまた明日書きます。

2013年7月22日(深夜)

新たなHaskellプログラム。
haskell_prog_puzzle.zip(Zipファイル)
ソース
Cube.txt
Display.txt
DisplayState.txt
EventFlags.txt
Idle.txt
KeyboardMouseC.txt
KeyboardMouseState.txt
main.txt
MainState.txt
PositionMaps.txt
ProgEnd.txt
ProgInit.txt
Random.txt
States.txt
Texture.txt
TipTileMaps.txt
VectorMaps.txt

流石に夜も遅いので続きはまた後で書きます。

2013年6月24日(深夜)

今回の更新で以前のプログラムと結構大きく変更してみた。
IORefを用いる部分を限定してみた。
つまりプログラムの状態を表すDStateという型を作り、newDState :: DState -> DState によって新しいDStateを作って　idleCallbackの部分で新しいDStateを代入する形。
newDStateより先はIORefは出てこないようになる。
その後、キーなんかの情報のためにKStateやCState,WStateといった型を作って、最終的にnewDState :: DState -> KState -> CState -> WStateとなった。
衝突は3次元で設定しているのでその気になれば3次元の物体のバウンドにも出来る。
ただテクスチャとかが面倒なのでやってない。

マウスを移動させると終了させるようにしたかったんだけど、
起動した直後のマウスの位置(クリックや移動を一切やっていないカーソル位置)をどうやって求めるのかで困って、いまだに分かっていないんだけど、
カーソル位置をMaybe Positionとして扱って、初期値をNothingとして、1フレームあたりのカーソルの移動量の判定の関数の引数をMaybe Positionとしてみると解決した。

今回は質量を同じにしているので、速度がvとVの物体が完全弾性衝突すると、それぞれ速度がVとvになる。
衝突面は中心間を結ぶ直線方向を法線ベクトルとする平面としている。
その法線ベクトル方向の成分で完全弾性衝突を考えることになる。
速度ベクトルvを法線ベクトルに射影するには法線ベクトルを正規化(つまりノルムを1にする)したベクトルnを考えて、
vとnの内積を考える(以下(v,n)とあらわす)とコレが法線ベクトル方向への速度の成分の量となる。
つまり衝突にかかわる速度のベクトルは(v,n)nとなる。
つまり衝突すると速度はvの法線ベクトル方向の成分(v,n)nが(V,n)nになるのだからv - (v,n)n + (V,n)n となる。

衝突に関しては[BObject]に含まれる任意の2つのBObjectに関してチェックしないといけないんだけど、
どうやろうかなぁと考えてみてとりあえずすぐに思い浮かんだのは次の2つ。
1つは再帰関数を使う。
bObj:rbObjs に対して、bObj と rbObjsたちの1つずつと衝突させて、新しいリストを得るという関数を使って
bObj':rbObjs'を得て、rbObjs'に対して、上と同様にheadの要素とtailの要素たちを衝突させていく。
このようにして再帰を作る。
今回はこれを採用。
Collision.txt
もう1つはBOBjectに名前かID(数値)を持たせて、そこから順序を導入する。
[(a ,b) | a <- bObjs , b <- bObjs , a < b]といった[(BObject , BObject)]というBObjectのペアのリストを作る。
a < bの条件から bObjs :: [BObject] から2つを選んだペアとなる。順序を入れ替えただけのものは除外される。
[BObject] ->(BObject , BObject) -> [BObject] という衝突するペアとBOBjectのリストを受け取って、
衝突後のBObjectのリストを返す関数を作る。1
その関数を作って先ほど得た[(BObject , BObject)]で畳み込ませるといけそうな気がする。

あとどうでもいいけど g :: a -> (b ,c)に対して (fst . g) :: a -> b が定義できるのかと思ったら上手くいかなかった。
間にタプルを挟むと関数合成が上手くいかないのかな。

苦労したのはテクスチャ関連。
なんかhaskell関連の情報がやたら少ないので正直まだ良くわかっていない。
正直試行錯誤で、HOpenGLのソースファイルや他人のプログラムを見ながらなんとか書いてみた。
ソースプログラムを見ても全体像がつかめていないとやはりなかなか分かりづらい。
ソースの例(横のsourceからソースへ飛べる)
これはプログラムに限らず全体像が分からないと細部をごちゃごちゃ説明されても分からないというのと同じ。
とりあえずOpenGLには画像を読み込む関数はないようで、BMPなどから画像のデータを読み込む関数を自作するのも面倒なので、stb-imageなるパッケージを使った。
テクスチャ関連は最初、よく分からなかったので色々試したりしていたんだが、とりあえずRGBAの情報の配列(Haskell以外の関数を使う)から
対象にテクスチャを貼り付けることに成功。
[0.1::Float , 0.2 , 0.8 , 1 , 1 , 0 , 1 ,0.2 , 1 , 0.3 , 0 ,1, 0.9 , 0 , 0 ,1]というリストから得た配列を使うと次のようになる。
textes5.zip(Zipファイル)
textes5.txt(ソース)
まだテクスチャの指定関連が上手くいってないけど。
たとえば、pallet8 :: [Int] -> [GLfloat]という、
1から8までの数字にRGBAのデータを対応させて、1から8までの数字のリストからRGBAの情報のリストを返す関数を作る。
0および9以上の数は[0.0 , 0.0 , 0.0 , 0.0](透明)に対応させる。リストを配列に変換して、テクスチャとして張り付けるようにすれば、
8色ドットのテクスチャを張るようなプログラムを作れそう。

一応スクリーンセイバーみたいなものを作ろうとしているんだけど、多重起動の防止とかどうやるんだろ。
ちょっとすぐに思いつかないな。

あとまだちゃんと分かっていないけど、Haskellでモナドという概念が出てくる。(もともとはカテゴリー論の概念)
それを言う前にモノイドという二項演算と集合に関する概念があって、集合Aと二項演算* の組(A ,*)で以下が成り立つようなものだ。
a * (b * c) = (a * b) * c (結合則)
a * e = e * a = a (単位元の存在)
まぁ結合則は自然な関係だと思うけど、それに単位元があるようなものだ。
たとえば自然数(0を含める)における加法の単位元は0になる。
実数において積の単位元は1となる。
XからXへの写像全体の集合と写像の合成においては恒等写像id　(x をxにうつす、すなわち値を変えない写像)が単位元となる。
それでモナドっていうのはファンクターにモノイドみたいな構造が入ってるということ。
たとえばIOファンクターで考えると、
a ->IO b への写像を考えると、これを持ち上げるとIO a -> IO (IO b)となるんだけど、
ファンクターにおけるモノイドみたいな構造のおかげで IO IO を IOにできるじゃないかな。
そこからIO a -> IO bを誘導される。
おそらくHaskellのモナドの定義(>>= と returnの定義)と、μx: MMX -> MXというとηx: x -> Mxという関数を定義するのと同値になるんだとおもう。
まだちゃんと検証していないけどね。

2013年6月23日(深夜)

前回のHaskellプログラムを更新してみた。
haskell_prog_bound5.zip(Zipファイル)
下はソース付きver
haskell_prog_bound5withsources.zip(Zipファイル)
なにかキーを押すかウィンドウ上でマウスを動かすと終了します。
ソースコードは下のような感じ。
Action.txt
Collision.txt
Cube.txt
Display.txt
DisplayState.txt
EndProg.txt
KeyboardMouseC.txt
KeyboardMouseState.txt
MouseMoveC.txt
ProgInit.txt
RunBound.txt
scrmain.txt　(メイン)
States.txt
Texture.txt
TextureObjects.txt
VectorMaps.txt
ちょっとDisplayStateというファイル名はよくなかったかもしれない。

もう夜も遅いので続きは今日の晩に書きます。

2013年5月24日

そういえばちょっと前、Windowsの更新をやったらPCが上手く起動しなくなった。
調べたらどうやら更新プログラムKB2823324にバグがあったらしい。
http://www.itmedia.co.jp/enterprise/articles/1304/13/news009.html
それでその更新プログラムを削除してみたら、上手く起動するようになった。
起動しなかったとき少しあわてたが無事解決できた。

また前回に引き続きHaskellとOpenGLでプログラム
ちょっとスクリーンセーバーでも作ってみようかなと思い、まずスクリーンセーバーのアニメーションのプログラムを作り始めた。
まずバウンドさせるようにした。
hogehoge.zip(Zipファイル)
bdmain.txt(ソース)
Action.txt(ソース)
Display.txt(ソース)
Cube.txt(ソース)
最初、Action.txtのnewVelocity3の定義でパターンマッチで定義しそうになったんだけど、Vecter3を調べてみたらFuncterだったので
1次元の場合のnewVelocity1からVecter3へ拡張することができた。
Functer fに対して、a -> b　を f a -> f b に持ち上げるにはfmapを使えばいいんだけど、
3つ以上の引数の場合はどうやるんだっけなぁと思ってちょっと調べなおしたらApplicative Functerで出来た。
一応liftA2やliftA3といった2つや3つの引数の場合の持ち上げのための関数もあるんだけど、それ以上の引数の場合でも出来るやり方がある。
たとえば g:: a -> b -> c -> d に対して f a -> f b -> f c -> f d を定義しようと思うと、
g <$> x <*> y <*> z
として定義できることが分かった。
<$>を今までなんとなく使っていたけど、これはfmapとほぼ同等で、
(( g <$> x ) <*> y ) <*> z として部分適用を考えると、(x , y , zの型はそれぞれf a , f b , f c)

( g <$> x ) 			:: f ( b - > ( c -> d ))

(( g <$> x ) <*> y ) 		:: f ( c -> d )

(( g <$> x ) <*> y ) <*> z 	:: f d

とこんな感じ。

そのあと、とりあえずフルスクリーンにして何かキーを押すと終了するようにした。
hogehoge2.zip(Zipファイル)
ただプログラムがなんか汚い。
openGLのチュートリがベースにあるんだけど、DisplayCallbackとIdleCallbackを使うとなんか微妙だな。
コールバック自体が代入みたいな感じになってしまうし、
さらにDisplayCallbackの引数がグローバル変数っぽい感じになる。
なんとかならんもんかな…

2013年5月11日(0時)

久しぶりの日記。
実は2ヶ月前くらいに体の状態が悪かった。
最近いい感じだった分ショックが大きい。
最近また良くなってきたので切り替えていこう。

最近痩せてしまった。身長177なんだけど60kgを切った。
結構よく食べるタイプなんだけど、まだ足りないのかな。
昔から太らない体質なんだけど、油断するとすぐに痩せる。
以前入院中病院の食事だけだとガンガン痩せて、2ヶ月で15キロくらい落ちて48キロになったこともある。
もちろん入院中はどうしても筋肉がおちるのでその分があるにしても、ちょっとひどかったな。
最近、無理し過ぎない程度に筋トレしているけど、痩せている状態じゃ体も筋肉よりエネルギー確保重視だろうから
筋肉もつかないだろうな。
うーむ、困ったもんだ。

最近haskellを勉強してみて、
The Haskell School of Expression (以下SOE)なる本にフラクタルっぽい例が載っていたんだけど、(三角形を3回くらい繰り返す例このChapter 3あたり)
せっかくなのでマンデルブロ集合とジュリア集合を描画させるプログラムをhaskellで打ち込んでみた。
haskell_prog_fractal_SOE.zip(Zipファイル)
最初複素数のデータ型を定義しようと思ったんだけど、複素数くらいになるとmoduleがあるかもと思って調べてみたら案の定Data.Complexあった。
ジュリア集合の場合、x座標とy座標で条件を満たす点をしらみつぶしに調べるので繰り返しになるわけだけど
これを再帰関数で定義しているのでstackがヤバイ。
各点で数十回再帰させて定義するのでますますヤバイ。
結構容量の限界に近い。
あとなぜかSOEのパッケージのgetKeyが反応しない。
どうもghcのコンパイラでは上手くいかないようだ。
せっかくなのでSOEのパッケージではなくOpenGLを使って、ジュリア集合の描画をプログラムしなおしてみた。
haskell_prog_fractal_OpenGL.zip(Zipファイル)
gltes5のソース
ソースにコメントアウトが全然ないけど、実はちょっと前までHaskellにおけるコメントアウトの仕方を知らなかったから。
gltes5.exeの場合は最初に複素定数の実部と虚部を入力すると描画します。(たとえば実部0.65、虚部-0.3など)
ただ実軸上の点の表示がなんかおかしい。
今度は、再帰用に関数を複数定義するのではなくリスト内包表記で表現している。
さらにせっかくなので、多項式を受け取ってそれからジュリア集合を作るようにしようと思った。
多項式を文字列として受け取って、そこから文字列を解釈して関数を作ってそれに適用するわけだ。
多項式に限定してそれ専用の入力法をさせれば簡単なんだけどせっかくなので普通の多項式表記から
ツリーを作って、そこから関数を作るようにしてみた。
最初は別口に多項式から関数を表示させるプログラムを作ってみてghciで試してみて、それを組み込んでみた。
ghciで試したソース
ただ…、これでジュリア集合を描画しようと思うと尋常じゃないくらい重くなる。
なぜならば、関数を使うたびにツリーを作ってそこから関数計算しているからだ。
うーん、ちょっとまずいねコレは。
しかたがないので"a,b,c,d,e"みたいに入力すると"a + b*z + c*z^2+ d*z^3+e*z^4"の多項式を作ってそれをもってジュリア集合を作ることにする。
まず文字列から多項式を生成する関数makePolynominalを作ってみる。
makePolynominal(ソース)
ghci上で動かしてみると実数の場合は上手くいくが、変数に虚数を含む数を代入すると挙動がおかしい。
どうやら括弧でくくらないと複素数として上手くいかないようだ。
たとえばmakePolynominal "1,0,1" 2.0:+1.0が上手くいかない。
画像
(Data.Complexで定義されている複素数はa:+bでa + b*(-1)^(1/2)をあらわす。)
どうやらmakePolynominal "1,0,1" 2.0:+1.0というのが(makePolynominal "1,0,1" 2.0):+1.0と解釈されているようだ。
なるほど、:+は演算子として解釈されているから関数適用より後になるのか。あと私は忘れっぽいのでここに書きとめておくと、Complex Floatなどの複素数の型にreadするには" _ :+ _ "の形じゃないとghcでエラーを返される。
つまりread "2.0" ::(Complex Float)だと read :: no parseとエラーメッセージが出るけど
read "2.0 :+ 0.0" ::(Complex Float)だと問題なく扱える。
それはさておき、結果としてこんな感じになる。
gltesx(ソース)
haskell_prog_fractal_OpenGL2.zip(Zipファイル)
あとおまけにマンデルブロ集合のほうもOpenGLでやってみた。
gltesmandelbrot_(ソース)
haskell_prog_fractal_OpenGL3.zip(Zipファイル)
ただこちらも実軸上の点の表示がおかしい。どこがまずいのかいまだによくわからない。

そういえば、四元数とかhaskellであるんだろうか？
四元数というのは感覚的にいえば複素数の拡張版でa+bi+cj+dkとあらわされる数でi^2=j^2=k^2=-1となりij =k,jk = i,ki =j,ji=-k,kj=-i,ik=-j となるようなもの。
四元数全体Hは非可換体になっている。（例ijとjiは異なる）
体の定義に可換性をいれるかどうかは流派によって違うんだけど、入れるほうを採用すると
可換性のない体なので斜体(skew field)と呼ばれる。
四元数全体の集合はHamiltonの頭文字をとってHであらわすことがある。
ちなみに八元数なるものもあって（Cayley数ともいう）実は四元数においては多項式の根が無限に存在することがある。
これは可換体でないことに起因する。
余談になるけどちょっと前に四元数で遊んでいて見つけた定理。
定理::実係数の多項式f(x)の四元数における根の集合はfの複素数上における根の集合をAとすると
{a+bi+cj+dk ,(a,b,c,d)∈ R^4 |a =α, |bi+cj+dk| = β , α+βi ∈ A }
つまり実部がα、虚部の絶対値がβになるような四元数の集合となる。
証明:: 四元数における虚部をXとするとXX= -|X|^2となる。このことからXを|X|Iとおく(II = -1)
f(x)の四元数における根をa+|X|I (aは実数)としてあらわすと
f(a+|X|I) = A+BIとして、A=0,B=0となるのはa=α |X| = βのときのみである。
逆に任意のIに対して、a= α |X|=βとしてf(α+|X|I) においてそれぞれIを含む部分とIを含まない部分に分けて考えると
f(α+|X|I) = 0とわかる //
あっさりいったけどXX = -|X|は最初Xi = -iXとなることからj,kでも同様にいえて、
i,j,kの実な線型結合のXでもXX = -Xになると分かったので、そこから応用したらこうなった、
周知の事実なのかどうかは知らない。

2013年2月13日(0時)

以前、友達が人間の体を分子に分解して構成を調べて、離れた場所で、その構成通りに組み立てればワープできるんじゃないか
という話になったんだけど、
それって、クローンを作って、元の人間を消滅させるというのを高速でやってるわけだよね。
これをワープと呼んでいいものか微妙なところだ。

すごく個人的な話題になるけど
先日、祖父が自分の親の名前をはっきり知らなかったようなのでうちの親父がわざわざ因島の役所にまでいって戸籍を調べてきた。
祖父は幼い頃、両親を亡くしていて、そのままどこかの商人の家で奉公とかやっていたらしいので
両親のことはあまりよく覚えていないらしい。
意外と辿れるもので、祖父の父親(つまり私にとって曽祖父)はもちろんのこと、
祖父の曽祖父まで分かった。
つまり私にとって…あれ、なんていうんだろう。
まぁ要するにひいひいひい爺さんにあたるわけだ。
祖父はどうも自分の祖父(つまり私にとって高祖父)のことは少し覚えているらしく、
名前も一応知っているようだった。
名前を出してもたぶん支障はないだろうから出すと、私の高祖父は源左衛門さんだった。
祖父は小さい頃、源左衛門さんのところを尋ねたことがあるらしい。
ちなみに生まれは弘化元年(1844)だったかな。天保の改革が終わった翌年にあたる。
9歳くらいのときにペリーが来航していることになる。
そしてその前の戸主が惣左衛門だった。生まれは不明。
意外と色々わかるもんだ。

先日見つけたyoutubeの動画。ヤギの動画。(どうやらシロイワヤギらしい)
http://www.youtube.com/watch?v=jFt7VeKRfj0

あと以前作ったRPGツクールのスクリプトでセーブデータに画像などを表示するやつを公開。
画像
 Ex_Scripts2.zip
先日公開したやつのスクリプトね。
とりあえずセーブ関連だけなんだけど、ロード関連に使ったやつがそのままになってるかも知れんけど、
とりあえず、呼び出されないやつは放置してる。
それから、以前書いたように一応セーブデータの画像は圧縮されて保存されている（はず…）。
もし使いたいという人がいればご自由に。
改変改造すきにどうぞ。
ただ私も仕様をよくわからないまま書いているので、バグとかあるかもしれんから
あくまで自己責任で。
なんでこういう風にしたかというと、デフォルトの状態だとコンティニューの画面を見てもどこのデータなのかがよくわからないので
とりあえず画像と場所くらいを表示させとくと分かりやすいだろうってことでそれらを表示させた。
ちなみに前回アップしたやつでロードの画面の背景がセーブと違ったのは誤操作の防止のため。
ロードしようとして上書きセーブとかになると悲惨なので、一目でセーブロードが分かるようにした。

2013年1月21日

ちょっとサボってたので久しぶりの日記。
特に何か特殊なことをやっていて更新が遅れたわけではない。せっかくなので前に行ってた新九玉伝のtips。
まぁ正直いまさらこのゲームをやろうとする人がいるかは不明だけど、
googleで新九玉伝と打ち込むと候補に新九玉伝、攻略とでるのでもしかしたら需要がわずかにあるかもしれない。

もうかれこれ10年位前にラジオで聞いたバンブーオーケストラジャパンのCDを何を思ったか手に入れようかとしてamazon調べたら1つしかなかった。
バンブーオーケストラとあるように純邦楽に近い邦楽の演奏ね。
で、googleで普通にバンブーオーケストラと検索したら、あっさりそういうのを扱っている店が見つかった。
私が小さいころは、こういうものを手に入れるのは極めて難しいものだったんだけど便利な時代になったもんだ。

前、RPGで作ったオセロはそのまま投げっぱなしだけど、とりあえずソース公開。
改変改造自由にどうぞ。上手くコピーできてなくて動かなかったらごめんなさい。
Ex_Scripts_Reversi.zip(Zipファイル)
正直、仕様を把握していないまま作っているので、かなり汚い。
あと今回RPGツクール触るまでrubyを全然使ったことがなかったので文法的にも怪しい箇所が多いと思う。
終盤が弱いんだけど、これは私があくまで完全読みにこだわっている結果で、そこそこ強い終盤ならそんなに難しくないと思うので
作りたい人は作ってください。
ホントのことを言うとHaskellあたりでプログラム作ってそれを読み込ませることとかできないものかなと思ったんだけど
RPGツクールのヘルプに
"RGSS は C 言語で書かれた Ruby の拡張ライブラリをロードすることができません。このため、以下の拡張ライブラリは例外的に組み込み扱いになっています。"
とか書いてあるので厳しいかもしれない。

2012年12月14日

最近、RPGとかでのバランスブレイカーは防御力じゃないかなって気がしている。
レベルアップで防御力が上がるせいで、レベルを上げると極端に難易度が下がるという現象が起こっているんじゃないかな。
思えば、最大HPが上昇すれば相対的にダメージ量が小さくなるので、結果的に耐久力の上昇になっている。
そこに重ねて防御力の上昇なので、敵の攻撃の被害が極端に小さいものになってしまうんじゃないだろうか。
回復アイテムにしても回復魔法にしても、ダメージが減ったほうが回復しやすいという大きなメリットがあることもあげられる。
そこで個人的にドラスレ英雄伝説がいいなと思ったのが防御力が防具固定ということ。
つまり、レベルがどんなに上がっても素の防御力は0のままになっている。
このおかげでゲームの自由度に幅をもたせることができたんじゃないかなって気がしている。

前回作ったRPGだけどRPGツクールVXシリーズのシステムでshift押しながら移動キーでダッシュになる。
これなんかもシステムみたいな項目を作ってデフォルトでダッシュできるようにしたら便利な気がする。
あともともと魔王の城につかまった王子と王女が自力で脱出するゲームにしようとしていたので
お金が魔力の欠片になっているのはその名残です。

RPGツクールを使ってオセロを作ってみた。画像
 RPGゲーム(Zipファイル)
ただ終盤はまともにAIを入れていないので弱いと思う。
AIの部分で残り10手くらいから完全読みをさせようかなと考えてプログラムさせていたんだけどちょっと詰まってしまった。
完全読みというのは相手が最善の手で来たとして最もこちら側の石が多くなるという手のこと。
最初はいろいろ考えたんだけど、選択肢はツリー状の構造になって、
最終的に最大になるものを見つけるのに、上から見ていくと難しい、下から見ていけば簡単ということに気づく。画像
そこで次のように再帰的に定義すれば上手くいくんじゃないかと思ったんだよね。
引数として、色(int)、ボード(array)を持つ関数(complete_calculate(color , board))として
まず、colorが打てないならば、colorを変更する。(op_color(color)でcolorの反対の色)
どちらも打つことができないならば、プレイヤーの石の数 - CPUの石の数を返す。
colorとboardから打てる場所を探す。
打てる場所ごとにai_boardという配列を作成して、色がCPUの色ならcomplete_calculate(op_color(color) , ai_board)の最小値を
色がプレイヤーの色ならcomplete_calculate(op_color(color) , ai_board)の最大値を返す。
という形にして再帰的に定義してみたんだけど、complete_calculate(op_color(color) , ai_board)の最小値(または最大値)の部分で上手くいかない。
complete_calculate(op_color(color) , ai_board)がnil(cでいうNULL)なんで比較できん！！というエラーメッセージがでるので
どうも上から読んでいく際に、complete_calculate(op_color(color) , ai_board)の中身を検証する前に最小(最大)を求めようとしてエラーが起こってるようだ。
本当にそうかまだはっきりわかってないんだけど、もしそうならばどうしたもんかね。
できれば最大、最小を求めるのは後回しにしてもらいたいんだが…。
結局、ツリーを作りながら、下までいって、そこから上に戻りながら評価していくというプログラムを作ったつもりだったんだけど
先にツリーを作る関数と、下から評価する関数を分けたほうがいいのかもしれない。
ツリーなんだけど、どうやってつくろうかなと考えたんだけど、配列の配列の配列の…配列とするのはさすがに扱いにくい。
そこで思いついたのがそれぞれの節の部分に番号(以後節番号)をふっておいて、子の節の部分に親の節番号の情報を持たせておくようにすればいけそうな気がする。
いわゆるリストみたいな感じで配列[節番号、節の色、節の値、親の節番号]と配列を作ればいけそうな気がする。
後ろにリストで言うポインタを配置するような感じ。
もしかしたら節番地をわざわざ書かなくてもいわゆるポインタを使ってもっと簡潔に書けるかもしれないけどね。
または配列の配列を作って配列の何番目の要素かというのを節番号とみなして実現できるかもしれないけどね。
それはまだ実装していない。

あとオセロのAIでいくつかの座標を使っているんだけど、
今思えば、座標クラスみたいなものを作ってもよかったかなって気もする。
1つは、普通の座標。
次に、各辺ごとに定義されたedge_coordinate。
そして各角ごとに定義されたcorner_coordinate。
画像
あとそれぞれ座標系の変換とかを定義してそれを使っているんだけど
edge_coordinateの場合、縦向きか横向きかによって幅がボードの縦と横になってしまうんだよね。
まぁ普通のオセロだと縦(BOARDHEIGHT)と横(BOARDWIDTH)は同じだけど、一応、縦横サイズ変更ができるようにしているので、
幅(edge_width)が座標系の向きによって、BOARDWIDTHになったり、BOARDHEIGHTになったりして、辺座標の関数ごとにこれを定義して使っている有様になってしまった。
だから座標クラスみたいなものを作って、継承として辺座標クラスというのを作って、それに幅の情報を持たせたほうがすっきりしたかもしれない。

2012年11月19日

常識なことをいまさらながら気づいた。
ユーラシアってEulopeとasiaをくっつけただけなんだな。
なぜかいままで気づいていなかった。

最近PCの調子が悪くて、どうにもならなくなってきたので、
新しいPCにしました。
で、いろいろと設定をしなおしたりしていたんだけど、
Gimpのダウンロードする際に、最新版の2.8がでていた(今まで使っていたのは2.6)ので
2.8をちょっと使ってみたんですが
うーん、だめだな、これは。
スライドバーが絶望的なくらい使いにくい。
慣れとかの問題じゃなくて、スライドバーと入力用のボックスが重なっているため
スライドさせている途中で、入力モードに入ってしまう。
基本的にソフトなんかはなるべく新しいバージョンを使うようにするんですが今回は以前の2.6を使うことにしました。

あとblenderなんだけど、一応、毛の生やし方が分かった。
ただ、凝った髪型にしようと思うと、なかなか操作が難しいなと思ってたんですが、
ひとつの髪として扱うんじゃなくて、複数の髪に分ければうまくいきそうな感じ。
つまりvertex groupという、点の集合を決めて、そこから毛を生やすんだけど、
そのvertex groupを頭部全体にするんじゃなくて、部分に対応させれば複雑な髪形も表現できそう。
ただちょっと髪の動きが固いけど、もしかしたらウエイトとかの問題なのかもしれない。
私も忘れっぽいので備忘録として書いとこうかな。
ところで以前紹介したblender入門サイト。
久しぶり使うこともあって、ちょっといろいろ忘れていたことがあったんだけど、
blenderのサイトに行ったら、リンクが張られていて、公式チュートリアル扱いされてた。
ココのBlender Beginners Courseね
ちなみにここの入門サイトのチュートリアルを見ようと思うと、
Vimeoという動画サイトの動画を見ることになるんだけど、
このVimeo、Firefoxだと見れないかも。うちのだと見れなかった。
新しいPCにしてからブラウザは専らChoromeを使っているので自分は問題なかったんだけどね。

RPGツクールってソフトがあるけど、ちょっとアレに手を出してしまって、
セーブの際にその場面の画像を保存して、ロードの際に描画したいなと思って、ちょっとスクリプトをいじって
そういう感じにしたんだけど、画像ファイルをRGBの要素に分けて(アルファ値は無視)、BMPの各点ごとに数値を取り出して、保存したんだけど
ちょっとファイルのサイズが大きくなるので(１つのセーブデータの画像で200kb以上)
隣り合う数字が同じのときはひとつにまとめるようにして、データを圧縮して出力するようにしてみたら140kbくらいにはなった。
大体隣り合う色は近いことが多いんだけど、色数を減らすを、より圧縮効率がよくなるので、
それぞれの色要素(0～255,float)を取り出した際に、整数化して16で割って 16*16*16の色数にして圧縮してみると40kb未満まで減ってた。
うん、まぁまぁうまくいったかな。
本当はたて方向も色が近いので、そのことも使いたかったんだけどね。
あとツクールの話になってしまうけど、イベントの際にRubyスクリプトを挿入できるようになっているんだけど、
あれはイベントごとにスクリプトを挿入するんじゃなくて、
もっと根幹の部分を改変して、スクリプトと対応するキーワードを作っておいて、
イベントのスクリプト挿入部分をそのキーワードをトリガーにして発動するようにしておいたほうがいいような気がする。
参考画像
 参考画像
どうでもいいけどＲＰＧツクールのアイコン。

普通の人には城に見えるんだろうけど、私には丸出だめ夫のボロットがクワを持って畑に突っ立っているように見えて仕方がない。
まぁこんな馬鹿なことをいっているのは私だけでしょうけどね。
サンプルゲーム(zipファイル))
使用にはRTPが必要。
http://www.famitsu.com/freegame/rtp
難易度はやや高め。ストーリは考えていない。まぁ偽王子に国をのっとられた王子が主人公
改造した点はたくさんあるけど、書くのがめんどくさいのでおもな部分だけ。
戦闘はキャラごとにターンが回ってくる(素早さが高いとよくターンがくる)。いわゆるドラスレ英雄伝説形式。
装備の属性やスキルに熟練度がある。熟練度が高いと武器属性の場合はクリティカル、命中率に関係。スキルの場合は威力に関係。
訓練という項目があって、敵の出るマップ上を歩くだけで訓練経験がたまって、能力アップする。(要するにBURAIのシステム)
レベルアップすると、能力増加値を上昇させることができる。画像
宿代は可変。(HP減少量 + MP減少量 * 2 + ステート異常治療追加料金)
敵のHPとかが見える。
パワー(腕力)というパラメータがあって、武器を持つのに必要なパワーがないと武器が装備できない。
知力というパラメータの作成。
TP(特技を使うための数値。空の軌跡のCP、格ゲーのゲージみたいなもの)の最大値はパワーと知力によって決まる。
MaxTP = 20 + (パワー + 知力) / 2
TPは敵からのダメージでは一切溜まらない。攻撃や防御など能動的な行動でたまる。(防御がもっとも上昇する)
強ガード(防御版クリティカル)、ガードくずしがあって、物理攻撃にはパワー、魔法攻撃には知力が相手より高いと発生しやすい。
TPボーナス、回避で + 10、クリティカルで +10、強ガード成功で +10 、ガード崩しで +5（受ける対象は-5）
状態異常の魔法の成功率は対象の魔法防御と使用者の魔力で決まる。
会心、痛恨は運のよさが関係。回避はすばやさが関係。
マップ上でF5を押すと最後にセーブしたデータに対してロード、
マップ上でF7を押すと最後に出た町までロード。(メモリデータなのでゲーム終了で消滅)
タイトルでpageupでチートコマンドモードに入る。("おわり"とか"〆"とか"КＯＨＥЦ"を打ち込むとゲーム終了、"The Weakest"で貧弱なパーティ)

上のゲーム、バグがあるかもしれんけど、いつもの如く自己責任でよろしく。

2012年10月17日

前回書いたまぶたの腫れはほとんどなくなった。
ちょうど左の頬骨の辺りにちょっとできものができていたので、そこから飛び火したのかもしれない。
というかそのできものもなかなか酷くて、先々週の土曜の晩に急に顔の辺りがヌメッとしたので、
鏡を見たら裂けて膿が出て頬を伝ってきていた。
化膿していたんだろうけど、ここまで派手にやったのは初めてなのでちょっと驚いた。

ちょっとblenderで作った歩行アニメーション。
gifアニメ(大)gifアニメ(小)
久しぶりに触るので、ちょっと要領を忘れていたんだけど、
最新版に更新した後、適当に調べながら作ってみました。
というか前から作ってるアクションゲームのキャラのモーションを作ってみようかなと思ってやってみた。
もしかしたらgifアニメを直接作れるのかもしれないけど、よく知らないので、
とりあえず、blenderで作ったアニメを5フレームごと取り出してレンダリングした画像をGimpで編集して
gifアニメを作ってみた。
で、実際ゲームに導入したりしてみたんだけど、最初上手くいかないので何でだろうなぁと思って
ゆっくりアニメを動かすようにしたり、画面上にアニメパターンの番号を表示させたりして色々チェックしていたんだけど
なかなかわからなかった。
実はいままで歩行は2つの画像だったのに今回は16個の画像を使っているので
各グラフィックハンドルを入れておく配列が足りていないだけだった。
で、修正したら、一応上手くいきました。
まぁこれはあくまでテスト用なので、これをそのまま使うわけじゃないんだけどね。

同じくblenderなんだけど、もうちょっとこのキャラをいじってみた。
正面
 側面
 背面
 斜め上
これが意外と粘土細工みたいで面白い。
もともと女性を意識して作っていたので、一応女性を作っているつもりです。
まぁまだ、肩周りから上や手足なんかはちゃんとつくっていないんだけどね。、

ここから下、例の如く妄想入った戯言なので注意
この間、寝るとき布団に入って考え事をしていたんだけど、
人間の致命的な急所を分散しているのはなんでだろうということ。
人間、基本的に脳と心臓が要なんだけど、それなら脳と心臓を同じ位置に配置したほうが安全に思える。
それに首が細いのも太いほうが安全なんじゃないかなと思ったりしていた。
首に関しては細くない動物もいるんだけどたぶん人間の場合頭部を旋回しやすくして周囲を確認しやすいからだろう。
そこで思ったのは目の近くに脳が配置されているんじゃないかということ。
そして聴覚、嗅覚、味覚をつかさどる耳鼻口は全て脳の近くあることにも気付く。
感覚をつかさどる器官は脳の近くにあるほうが都合が良かったんじゃなかろうか。
目のそばに脳あり、その脳の近くに耳鼻口があるという感じ。
まぁ、全てが脳の近くにあるといったけど、進化の過程で人間になる前は口の近くに目があったほうが都合が良さそうだし
口の近くに臭いを確認する鼻があったほうが都合がよさそうだから、その名残かもしれないけどね。
あと三半規管というのが耳の奥の辺りにあるけど、これは目とセットなのかもしれない。
つまり上下を判断する器官は目とほぼ同じ位置に配置しておいたほうが都合がいいということ。
目の映像に対して上下の判断をするのにほぼ同じ位置で固定されていないと、判断しにくいからじゃないかなと思ったりする。

2012年10月4日

なんか左目のまぶたが妙に腫れてる。
まぁ少し様子をみて、酷くなりそうなら眼科へ行ったほうがいいのかな。
薬の関係で抵抗力が落ちてるので、こういうのにはなりやすいんだろうけどね。
右目と左目の状態の違い

そういや、先日、新元素に日本(japan)から名前をとってジャポニウムと命名されるみたいなニュースがあったけど、
あれ自体はかなり前から話はあって、私もそのうちここの話のネタにしようかと思っていたんだけど
こう決まった感じになるといまさら感があるので止めにしました。
ネタはもったいぶらずに早めに書いたほうがよさそうだ…。

この間から作ってるゲームの更新
HogeX_v2x12.zip
魔法のバグを修正
イベントのバグを修正
モーションを外部から読み込みにした。
モーションの設定とか現段階である程度できるんですが、(攻撃範囲や発生、硬直の設定、モーションアニメの変更、アニメパターンの数の調整)
説明が面倒なのと、飛び道具関連にまだ不備があるので説明はまた今度
魔法のバグというのは、Healを選択すると、他の魔法の効果が出てしまうというのがあったんですが、
あれは魔法を実行する際に、Select Caseで分岐するんだけど、breakを入れ忘れていただけだった。
なんというかバグもしょうもないミスでおこってるのが多い。
あと、イベントの数はまだ増やせません。
実はステージに読み込むイベントの数の情報を持たせているので、
その辺の設定はまた今度。

以下数学ネタ注意。
前回、双対する多面体の展開図の数が等しいという話題を出したけど、
なんかグラフ理論で説明できないかなと思って、ちょっと調べてみて、
マトロイドにおけるホイットニーの定理が使えそう。
グラフとかマトロイドの説明は面倒なので書かないけど、もしかしたら今度書くかもしれない。
定理
グラフGから定まるマトロイドM(G)の双対マトロイドM(G)*がグラフ的である必要十分条件は
グラフGが平面グラフであることである。そしてその時、Gの双対グラフG*に対して、
M(G)* = M(G*)が成り立つ。
GのマトロイドとしてGの木(サイクルをもたない極大な部分グラフ)全体の集合を取れるので、
それがちょうど展開図に対応するんじゃないかな。
それで、定理にあるようにGが平面グラフであることを言えばいいんだけど、
どうやって正多面体が平面グラフであることをどうやっていえばいいのかなと
ちょっと考えてみて、最初は、多面体の下の辺を広げたりする操作を地道に考えたりしたんだけど、
落ち着いて考えてみれば、球から平面への射影を使えばいい事に気付く。
(つまり北極Nと球面上の点Pを結ぶ直線と赤道面との交点P'として、PとP'は1対1に対応)
例の射影の図
つまり正多面体を辺の部分をちょっと膨らませて、正多面体に外接する球に辺がくるようにグラフを変形する。
もちろんもとのグラフと同型だけど、さらに、球の北極と頂点が重ならないようにして、例の射影で平面に写す。
北極を除く球面と平面は1対1に対応するので辺が重なることはありえない。
これで正多面体は全て平面グラフとなることがわかる。
これらを使えば展開図の数が等しいこともいえる。

2012年9月18日

以前書いたものを見直していると不等号とかを半角で書いた部分なんかがタグとブラウザが誤認して
上手く表示されていない部分があるのを発見。
今後不等号とかつかうような文脈で文字が消えている感じの文章があったらソースなんかを確認してみてください。
たぶん文字が消えていたりします。

この間から作ってるゲームの更新。
HogeX_v2x11.zip
(Zで攻撃、ESCでメニュー、Xで飛び道具)
更新内容はゲーム本体じゃなくて、キャラクターの設定の一部も外部からの読み込みにした。
Motionなんかもそうしようかと思ったけど、ちょっとめんどうなのでまだしてない。(単純に書く量が多いから)
[Chara]～[Chara]の間で定義する。
[Status]～[/Status]の間でパラメータなどの定義
Name=でキャラクター名
MaxLife=で最大HP
Sp=で魔法の能力値
Defence=で防御力
Jump=でジャンプ力

以下戯言
双対なものって色々あるけど
正多面体なんかにも双対性があるよね。
面←→頂点として、隣接する面に対応する頂点は辺で結ぶものとする。
たとえば正六面体(立方体)の面の中心に点をとってみて、隣接する面の点を結んでみると正八面体になる。
さらに正八面体の面の中心に点を取ってみて、隣接する面の点を結んでみると正六面体(立方体)となる。
これにより
正四面体←→正四面体
正六面体(立方体)←→正八面体
正十二面体←→正二十面体
と対応関係がある。
正十二面体の頂点の数は20個だし正二十面体の頂点の数は12個。
立方体の頂点の数は8個だし正八面体の頂点の数は6個。
で、余談だけど、サッカーボールの形(例の白黒のやつ)なんかは正十二面体と正二十面体の中間みたいな感じだよね。
まぁ別のものを出せばフラーレンC60みたいな感じ。
C60の場合は辺の長さが厳密には違うかもしれないけどね。(具体的には知らない、構造的に共鳴とかおこってるだろうけど)
ちょうどサッカーボールの形は正二十面体の頂点の部分を切り落とした感じで、面の数は12+20=32となる。
それで話を戻すと、対応する正多面体の展開図の数は等しいということをきいたことがあったんだけど
なんでだろうなぁと昨晩布団の中で考えていたんだけど、
ちょっとひらめきました。(そんなに難しいことじゃないけど、少しひっかかっていたので)
展開する際に切る辺←→展開したとき隣接する面
とすることで展開図が1対1に対応する。
いや実は最初、展開する際に切らない辺と展開したときに隣接する面を対応させようとしたんだけど
正四面体で考えてみると展開図の中には1つの頂点の周りの全ての辺で切り落とす場合があって、
その頂点に対応する面が孤立してしまって展開図にならないのでおかしいと気付いた。
で、その場合の展開図を考えるとちょうど1つの面が全ての面と隣接した状態であるのに気付いたので
これは展開する際に切る辺のほうを対応させれば上手くいきそうだなという考えになった。
画像
実際グラフ的な考え方をすると、多面体の面を頂点、隣接関係を辺にもつようなグラフで考えて、
展開図ってのはグラフの辺を取り除いていって、ツリー状にしたものになる。
今度は多面体の頂点をグラフの頂点にして、それを結ぶ辺をグラフの辺にしてみると、
展開する際に切断する辺がサイクルになってはならない。(サイクルになると孤立する頂点が出てくる)
それでツリーになる。
そういうわけで2つのグラフのツリーをそれぞれ対応させることができるので、展開図に対応関係ができる。

2012年9月10日

この間から作ってるゲームの主な更新。
HogeX_v2x10.zip
(Zで攻撃、ESCでメニュー、Xで飛び道具)
更新内容は、敵が地面にめり込むバグの修正、敵が消滅するバグの修正
移動イベントを作成。緑の四角に触れると移動します。
あと表には出てないけどBGM関連システムを色々と変更しました。
移動イベントは外部ファイルから読み込む形。
stage/event.datから読み込みます。
前、外部ファイルからの読み込みに関して、xmlを使おうかなといってたけど、
それを止めて、読み込むプログラムを作りました。
[Event]～[/Event]の中身がイベント定義となります。
最初htmlのタグみたいにしようかと思ったけど、説明をhtmlで書こうとすると、
ブラウザが誤認してしまう可能性があるので、Bracketな括弧を使いました。
EventID=で定義するイベントIDを指定します。
ID重複しても問題ないと思うけど、最後に書いた奴に上書きされると思います(試していない)
StageID=でそのイベントが存在するステージIDを指定します。
EventType_Move=で移動イベントかどうかを判別します。(1で移動イベント、0でその他)
PosX=でそのイベントのマップ上の座標をしていします。ただしstage01.datのデータの座標になるので、画面の座標は32倍したものになります。 PosY=は上のY座標。
ChangeStage=で移動イベントの場合の移動先を指定します。移動先のX座標,移動先のY座標,移動先のステージIDとなります。
たぶんスペースを空けるとエラーになります。
音楽関連の更新というのは今までStageクラスにBGMの情報を持たせていたんだけど、
それだとステージが違えば同じBGMでもいちいちBGM情報をもたせることになってなんか無駄な感じがしたので、
使うBGMの分だけSound構造体みたいなものを作って、Stageクラスには、そのSoundを使うかを指定するような感じにしました。
ポインタみたいな感じ。

なんとなく描いたもの

2012年8月26日

よく怖い話をするとひんやりするとか、心霊スポットに行くと気配を感じるとか聞くけど
最近私が思うには周りに何かいないか警戒して神経を集中させた結果なんじゃないかなと思う。
普段は気にも留めない空気の流れや外気の温度なんかが神経を集中させているため過敏に反応しているんだと思う。

この間から作っているゲームはしばらくつついていなくて、最近再開したのでアップはまた今度。
一部のバグは修正。

ちょっとした数学ネタ
ネタ

2012年7月30日

トップ絵を久々に更新。
トップ絵

ところで、バターロールとかの袋なんだけど、あれを開ける時、
たまに開きにくい時とかあるよね。
で、そのときつい力を入れすぎて、パンッと破裂するような感じで下のほうまで袋が裂けてしまうことがある。
ちょっと力の入れ加減が難しい。
そこでいつも袋の止め具(なんていうのか知らない)をとってから開いてたんだけど、
あれを外さずに開けば間違いが起こりにくいと最近気がついた。

例のプログラム更新
HogeX_v2x9.zip
(Zで攻撃、ESCでメニュー)
主な更新は
Xキーで飛び道具
スペース+(A or S or D)でそれぞれ魔法を使える。
スタート時に魔法を3つ選択できる。(同じものを何度も選択可能)

魔法をとりあえず3つだけ作った。
効果時間とかもそのうち作るつもり。
スペース+ASDみたいなことをしたけど、面倒だからASDだけでもよかったかもしれない。
ゲーム本体でおかしなところもあるので、そろそろその当たりを修正しといたほうがいいかもしれない。

ここからはいつもの妄想、読みとばし推奨。
遊びって生物としてはカロリー消費ばかりして無駄な行動に思えるんだけど
なんでそれを人はしたがるんだろうなぁと先日布団の中でぼんやりと考えていたんだけど、
もしかしたら脳の調整かなにかなのかもしれない。
基本的にある程度以上に知能の発達した動物が遊びをやるんだけど、
脳は基本的に使わないと衰えていくと思うんだけど、遊びという刺激のもとで
脳(神経、もしかしたら筋肉なんかも)で必要なものと不必要なものを整理したりしているんじゃないだろうか。
理由が楽しさを得るためだけなら、それこそ、脳が適度にそれらを感じる物質でも分泌させればいいわけだ。
逆に遊びを楽しいと感じさせるあたりから脳にとって必要な行為なんじゃないかなと思ったりする。
おそらく、環境などへの適応などの必要性から脳だけで必要なものとそうでないもののを判断できないので
行動を通じて、判断しているんじゃなかろうか。
暇というのが苦痛に感じることなんだけど、必要不必要の判断できないことによるストレスなのかもしれないし、
必要なものも不必要と判断してしまうことへの脳の危険信号なのかもしれない。
子供なんかは遊びが必要でそこから発達していくものも多いんだろうけど、大人なんかでも
脳の維持というかメンテ的な感じで必要なんじゃないかなと思ったりする。
まぁあくまで妄想だけどね。

2012年7月17日(0時)

前から作ってるアクションゲーム、飛び道具とか作ったんだけど、
ちょっとゲーム全体の挙動がおかしいので、アップはまた今度。
あと、はしごみたいなのを作ろうと思う。今表示しているステージの上に、さらにチップを配置できるようにしたい。
RPGツクール的には上層マップみたいなやつ。
実際できるんだけど、ただ管理や編集がいまの2つのdatファイルだとめんどくさいので
わかりやすく編集できるツールみたいなのを作ったほうがいいのかもしれない。

ところでコマンド型RPGもこのアクションゲームとほぼ同様にできそう。
重力をなくせばフィールドマップになるし、戦闘モードとフィールドモードに切り替わるように設計していれば何とかなりそう。

ところで3D画像を表示させるプログラムなんだけど
カメラの位置のようなことは適当な線形変換かましておけばなんとかなりそう。
ただ3Dっぽく表示するのに問題になりそうなのが、光の強さによる色の変化。
なんか法則があるのかもしれないけどちょっとすぐにはわからない。
たとえば視線の向きからθだけ面が傾いていて、表面できれいに反射しなくても、大体元の強さのsinθ倍が来ると仮定しても
sinθ倍の光の強さだと、元の光の場合に比べて色がどのくらい暗くなるのかがよく分からない。
ただその関係なんかは実験とかすればわかるだろうし、たぶんデータとかがどこかにあるだろうけどね。
以前3Dのデータを表示させるのに平面で近似させるのはともかく張り合わせが面倒とかいったけど
落ち着いて考えてみれば3次元の映像を取り込むならともかく、3次元のデータを描くのなら点から先に配置して面を作っていけばいいんじゃないかなって気がする。
4点以上で平面を作ろうとすると、平面にならないケースが出てくるので、
3点で三角形の平面の張り合わせを基本にすると無難そう。
または平面となっているものを分割して四角形を作ることもできそうだけどね。
そうすると多角形分割したような図ができるわけだけど、それを表示する段階でもう１つ、視線の角度をパラメータにもつ変換をかまして
表示する際に滑らかに見えるようにドットを表示する感じだろうか。
面は2つベクトルの外積（ベクトル積）とって法線ベクトルを求めて、それで光の反射具合もわかりそうだ。

そうそう、属性みたいな要素もつけようかどうか考え中なんだけど、
属性についてふと思ったのは2つの種類の属性の掛け合わせにすると、少ない種類の属性で多くのタイプの属性を作ることができる。
つまり25種類の属性を用意するより、(火、水、土、金、木)と（赤、青、黄、白、黒）のペアにすると
5+5=10通りを元にしてで25通りの属性を作ることができる。（属性のペアの場合単純に性質を足し合わせるものとする）
25通りもあったらプレイヤーとしてみると覚えるのが大変なんだけど、10通りなら比較的楽に覚えられる。
自由度自体は若干減るけど(25通り個々に設定した場合は25通り自由に組める)、
複雑性を減らして同時に種類を増やせるという意味では使えそう。
M+Nコの組み合わせでmnコの種類を作るわけね。
他にも元の種類が十分多くあるときは、組み合わせを使うことで少ない元からたくさんの種類を作れそう。
たとえば10通りの元から3通りを選ぶようにするとか。
まぁ今回のやつはそこまでたくさんの属性を用意する必要があるのか微妙だから、5通りくらいで済ませるかもしれないけどね。

日記 ぼる11