DIARY

そろそろ内容の話


絶賛制作作業中のオリジナルカードゲームですが、
いまはひたすらカードの個別の能力を作っています。

今回はとりあえず、カードを50種類ほど、能力的には40種類ほどを実装する予定です。
属性が6種類あるので、各属性で8種ほどしかカードがなくて、
物理的に単色デッキが組めなかったりして、ちょっと問題ですが^^;


↑実装ホヤホヤ(カード絵は間に合わせです)

現在、やっとこさ9種類目の能力を実装したところです。
開発状況としては20〜25%程度といった感じでしょうか。
4月末くらいまでにはなんとか能力の実装は終らせたいところです。

そんなわけで、そろそろ内容の話をしていってもいいかなと。
ルールや中身などについて、少しずつ書いていこうと思います。


最初は軽めにタイトルの話。

「Worlfard」というタイトルをつけていますが、仮題ですw
いままで、あまりタイトルについて言及してこなかったのは、
あんまり気に入ってないので、変えたいなぁと思っていたからです^^;

なぜ、Worlfardなのかというと、「the World of Card」(カードの世界)からきています。
アナグラムでいい感じの響きの単語にしようと思ったんですが、
なかなかいい語感にならないんですよねぇ。

そろそろタイトルくらい決めておかないとカッコがつかないと思ったので書きましたけど、
そのうち、何事もなかったかのようにタイトルが変っているかもしれませんw

なんかいいタイトルないかなぁ〜。
2010年03月30日(火) No.214 (Worlfard)
Comment(0) Trackback(0)

SOPHIAライブ活動休止


SOPHIAより ファンの皆様ならびに関係者の皆様へ大事なお知らせ
http://www.sophia-eternal.com/news/?id=1269169648

SOPHIAのキーボード都 啓一さんがろ胞性悪性リンパ腫と診断されたため、
現在行っている全国ツアー終了後、ライブ活動を休止するということらしいです。

SOPHIAは一番好きなアーティストグループなだけに非常に心配です。
都さんは治療に専念し、残りのメンバー四人でSOPHIAとしての楽曲制作等は
行っていくとのことですが、やっぱり5人のSOPHIAの曲を聴きたいです。

都 啓一さんの病気が完治することを願っています。
2010年03月27日(土) No.213 (雑記)
Comment(0) Trackback(0)

アメザリ


http://www.youtube.com/watch?v=wSruMg3n_-s



アメリカザリガニの平井さんがJ-Waveのラジオ番組のPLATOnのために制作したフラッシュアニメで、
番組中にアメザリさんとアンジャッシュの渡部さんが生放送でアテレコされてました。
芸人さんなのにかなりクオリティーが高いですね(;゚;Å;゚; )

しかし、相方の柳原さんの声優の経歴の方がびっくりしましたよ。
遊戯王とかエリンとかのキャラは普通に見て聞いて知ってたしorz
違和感なく演じられていますね、全然気付きませんでした。
レイトンのハムスターの声も柳原さんとか、
言われてみると、たしかに柳原さんの声ですけどw

アメザリさんもう芸人じゃないね、コレw
2010年03月25日(木) No.212 (雑記)
Comment(0) Trackback(0)

ゲームでIMEを制御して日本語入力を行う方法2


昨日の続きです。

IMEでの日本語入力対応は昨日ので出来ると思いますが、問題はまだあります。

1つのゲーム画面内で入力を受け取る部分と受け取らない部分が混在している場合です。
チャットなどに日本語入力を使う場合、そういう状況は多分にあると思います。
そういう場合、正しくIMEを切り替えないと面倒なことになります。

入力を受け取らないところで日本語が入力されると、
勝手にデフォルトのコンポジションウィンドウが作られたりします。
それを放っておくと入力を受け取る部分にフォーカスを移しても、その処理が完了せず、
IMMから正しくメッセージが送られなかったりします。

下記のソースがそれに対応するための処理です。


<C++でのIMM系のAPIを使ったIMEの切り替えサンプルソース>
---------------------------------------------------------------------

//入力フォーカスを外すときの関数
void CIme::OnFocusOut(void) {
HIMC hImc = ImmGetContext(m_Handle);

//入力中の文字があれば、キャンセルしておきます
if (ImmGetCompositionString(hImc, GCS_COMPSTR, NULL, 0) > 0) {
ImmNotifyIME(hImc, NI_COMPOSITIONSTR, CPS_CANCEL, 0);
}

//復帰するときのために現在の状況を保存しておく
ImmGetConversionStatus(hImc, &m_Conversion, &m_Sentence);
m_Open = ImmGetOpenStatus(hImc) != 0;

ImmReleaseContext(m_Handle, hImc);

//IMEを"無効"にし、現在のIMCを保存しておきます
m_ImcReserve = ImmAssociateContext(m_Handle, NULL);
}

//入力フォーカスを受け取るときの関数
void CIme::OnFocusIn(void) {
//保存しておいたIMCで、IMEを有効にします
ImmAssociateContext(m_Handle, m_ImcReserve);

HIMC hImc = ImmGetContext(m_Handle);

//入力中の文字があれば、キャンセルしておきます
if (ImmGetCompositionString(hImc, GCS_COMPSTR, NULL, 0) > 0) {
ImmNotifyIME(hImc, NI_COMPOSITIONSTR, CPS_CANCEL, 0);
}

//前回保存しておいた状況を反映させます
if (m_Open) {
ImmSetOpenStatus(hImc, true);
ImmSetConversionStatus(hImc, m_Conversion, m_Sentence);
}

ImmReleaseContext(m_Handle, hImc);
}

---------------------------------------------------------------------

基本的に、チャットボックスなどをクリックしたときにOnFocusInを呼び、
その他のエリアをクリックしてフォーカスを外したときにOnFocusOutを呼ぶ、
という使い方を想定してあります。

これで入力フォーカスを持つときだけ、IMEを有効にして、
持たないときはIMEを無効にするという対応ができると思います。



IEとかだと入力フォーカスを受け取らないときに、
入力ロケールインジケーターのボタン等が無効になっているのですが、
これはどうやれば再現できるのでしょうか?
ImmSetOpenStatusでIMEをオフにするのとも、
ImmDisableIMEで無効にしているのとも違う気がするのですが...。
まだ、他にもIMEを操作する方法があるのでしょうか?
知っている方がいたら教えて欲しいです。
2010年03月22日(月) No.211 (プログラム)
Comment(0) Trackback(0)

ゲームでIMEを制御して日本語入力を行う方法1


※2010/06/11 追記

ゲームで日本語入力を行おうと思うと、独自のエディットコントロールを作り、
IMEを適切に処理しなければなりません。
以前にもDXUTを使って取り掛かろうとして、一度挫折した機能。
かなり大変だったので、とりあえずIMEを処理する部分のソースだけでも晒しておきます。
そのうち、ちゃんとまとめて1コンテンツにしたいな。

ただし、フルスクリーンのゲームではないので、
入力コンポジションの描画処理は基本的にIMEに任せてあります。

フルスクリーンでの処理については、MSDNの方にぴったりな資料がありましたので参照してください
ゲームでの IME の使用
http://msdn.microsoft.com/ja-jp/library/bb206300%28VS.85%29.aspx


C++でのIMM系のAPIを使ったIMEを操作するソースコード
----------------------------------------------------------------------

//imm32.libのリンクとimm.hのインクルードを忘れずに
#pragma comment(lib, "imm32.lib")
#include "imm.h"

//ウィンドウに送られてくるIME関係のメッセージだけを受け取るプロシージャです。
//CImeはオリジナルクラスです。
int CIme::MessageProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) {
static char buffer[BUFFER_MAX];
LRESULT result = 0;

switch (uMsg) {
//アプリケーションのウィンドウがアクティブになったときにIMMから送られてきます。
//lParamに描画する必要のあるウィンドウと描画しないウィンドウをIMEに通知するフラグが入っています
case WM_IME_SETCONTEXT:
//lParam = 0で描画をオフにできるが、フルスクリーンではないので描画はIMEにやってもらう
result = DefWindowProc(hWnd, uMsg, wParam, lParam);
break;

//ユーザーのキーストロークの結果として IME コンポジションを開始するときにIMMから送られてきます
case WM_IME_STARTCOMPOSITION:
//入力処理に対応するモノがあるかで対応を変える
if (SearchFocus()) {
//後々使うので、ハンドルを確保して、入力中のフラグを立てておく
m_Editing = true;
m_Handle = hWnd;

//入力コンテキストにアクセスするためのお約束
HIMC hImc = ImmGetContext(hWnd);

//コンポジションウィンドウの位置を設定
COMPOSITIONFORM info;
info.dwStyle = CFS_POINT;
info.ptCurrentPos.x = m_Focus->GetCaretX();
info.ptCurrentPos.y = m_Focus->GetCaretY();
ImmSetCompositionWindow(hImc, &info);

//コンポジションウィンドウのフォントを設定
ImmSetCompositionFont(hImc, m_Focus->GetFont()->GetInfoLog());

//入力コンテキストへのアクセスが終了したらロックを解除する
ImmReleaseContext(hWnd, hImc);

//STARTCOMPOSITION時の処理自体はIMEに任せる
result = DefWindowProc(hWnd, uMsg, wParam, lParam);
}else {
//入力処理を行いたくないときの対応です
HIMC hImc = ImmGetContext(hWnd);

//入力をキャンセルして、
ImmNotifyIME(hImc, NI_COMPOSITIONSTR, CPS_CANCEL, 0);

ImmReleaseContext(hWnd, hImc);

//IMEにはSTARTCOMPOSITIONが来たこと自体を伝えないようにします
return 0;
}
break;

//キーストロークによってコンポジションが変更されたときに送られます
//変更内容はlParamに取得できる情報の種類が入っています
case WM_IME_COMPOSITION:
//処理中でなければ、無視して、IMEにも伝えない
if (! m_Editing) return 0;

//GCS_RESULTSTR は文字列が確定したときに送られますので、
//以下で、確定文字列を受け取ります
if (lParam & GCS_RESULTSTR) {
HIMC hImc = ImmGetContext(hWnd);

//まずは文字列のサイズを確認
int len = ImmGetCompositionString(hImc, GCS_RESULTSTR, NULL, 0);
if (len >= BUFFER_MAX) len = BUFFER_MAX - 1;

//bufferにlen分の文字列を受け取ります
ImmGetCompositionString(hImc, GCS_RESULTSTR, buffer, len);
//受け取った文字列にはNULLがついていないので、終端をつけておきます
buffer[len] = '\0';

//受け取った文字列は御自由にw
m_Focus->AddText(buffer);

//※2010/06/11追記
//文字入力中に変換を行った後、エンターで入力を終了せず、
//そのままキー入力を続ける場合、コンポジションウィンドウの位置を変更しなければならない。
COMPOSITIONFORM info;
info.dwStyle = CFS_POINT;
info.ptCurrentPos.x = m_Focus->GetCaretX();
info.ptCurrentPos.y = m_Focus->GetCaretY();
ImmSetCompositionWindow(hImc, &info);

ImmReleaseContext(hWnd, hImc);
}

//文字列の横取りがすんだらIMEの方にも渡しておく
result = DefWindowProc(hWnd, uMsg, wParam, lParam);
break;

//IMEコンポジション操作の終了時に送られてきます
//ユーザーがEnterやEscを押したときですね
case WM_IME_ENDCOMPOSITION:
//基本的にすることはありません。
if (m_Editing) {
m_Editing = false;
}else {
//これはIMEに渡さなくてもいいかもしれません。が、いちよう渡しています
//return 0;
}
result = DefWindowProc(hWnd, uMsg, wParam, lParam);
break;

//確定した文字が1文字ずつ送られてくるらしいです
case WM_IME_CHAR:
//WM_IME_COMPOSITIONの方で横取りしているので無視してしまいます
return 0;
break;
}
return (int)result;
}

---------------------------------------------------------------------

ところどころにオリジナルの処理がありますが、雰囲気で理解してください。
m_Focusは独自のエディットコントロールへのポインタです。

これで、文字入力の日本語変換の機能をIMEに任せ、
確定した文字列を受け取って処理できるようになると思います。



※2010/06/07追記
実際にこれを使ってみると文字の変換を確定させた後、
変換候補ウィンドウが閉じるときなどに、ちらつきが見られた。
これはウィンドウが閉じるときにIMEからWM_ERASEBKGNDが送られて来ており、
これが原因でウィンドウが重なっていた部分を背景色で塗るため、ちらつくらしい。

対策としては、ウィンドウのメッセージループでWM_ERASEBKGNDを適切に処理すればいい。
独自の描画ルーチンを組んでいるのなら、DefWindowProcにまわさないようにするだけでいいと思う。

IME側の問題というわけでもないのですが、ちょっと躓いたので追記しておきます。


※2010/06/11追記
えーまた不具合がありました。
文字入力を行っているときに変換を行い、エンターキーを押して入力を終了せずに、
続いてキー入力をすると、WM_IME_STARTCOMPOSITIONが送られてこないようで、
コンポジションウィンドウの位置が最初の入力時の場所に表示されてしまい、
実際の入力位置とズレてしまうようです。

対策としては、WM_IME_COMPOSITIONで文字を受け取ったときに、
コンポジションウィンドウの位置を正しくキャレット位置に移動するようにします。
2010年03月21日(日) No.210 (プログラム)
Comment(3) Trackback(0)

マシンスペック


今の標準的なマシンスペックってどのくらいなんでしょうね?
開発者の作業マシンとプレイヤーの一般マシンとで性能差が大きいと、
あとあと困るような気がします。


現在制作中のゲームでは、高度な演出も3Dとかもいらないだろうということで、
DirectXとかは一切使わず、描画処理や入力処理等も全てWin32APIでやっています。
ある程度、お手軽にプレイできることを目指しています。
しかも、画像処理はDIBではなくDDBで。
ここはDDBでとりあえず作ってみて、どこまでいけるのかな?というのもあるのですが。

んで、今回透過処理を実装しました。
今まで、αブレンドなんてDIBで直接ピクセルデータを
ガリガリ書き換えないといけないと思っていたのですが、
DDBでもAlphaBlendなんて便利な関数が標準で用意されているのですね。
案外簡単に実装できてしまいました。


カード詳細表示ウィンドウを半透明にしてみたの図


それで、本題はここから。

いま私が作業しているマシンが↓こんな感じです。
OS : WindowsXP SP3
CPU : AMD Athlon 64 3000+ 2.00 GHz
RAM : 1.00GB (512MB x 2)

これでゲームを動かしてみると、いままでCPUの使用率がだいたい30%を超える程度だったのですが、
透過処理をやらせてみるとやっぱり少し上がるみたいで、40%くらいはいくようです。
画面サイズが800x600でFPS60出して40%なら、十分軽い部類に入るとは思うのですが、
問題は今の標準的なマシンスペックがどのくらいなのか?ということ。

カードゲームでそこまで絵が動き回ることもないので、必ずしもFPSを60出す必要もないし、
透過処理をDIBでMMX辺りを使って処理するなど、
処理を軽くできる部分はまだあるとも思いますが、このくらいの重さなら大丈夫なのでしょうか。

うちのPCは5年も前の機体で、OSももう2世代前のものですから、
このぐらいのスペックは、PCでゲームをするくらいの人達は十分持っているのでしょうか。
ノーパソとかだと、きついのかなぁ。
2010年03月18日(木) No.209 (雑記)
Comment(0) Trackback(0)

紹介動画その2


制作中のゲームの紹介動画をまたアップしました。
埋め込みプレイヤーのサイズが小さいと画質の悪い方が再生されるようなので、
今回はビックサイズのプレイヤーにしてみました。

↓が見難い人はYoutubeのサイトの方でどうぞ。



今回のは、CamStudioでキャプチャして、超録で録音。
ムービーメーカーで編集して、Subtitle Workshopで字幕を付けました。
しかし、やっぱりCamStudioは音ズレするんですね。
音ズレというか、映像の方が伸びているんでしょうけど。
なんとか別取りして切り貼りして合わせてはいますけど、結構編集作業も面倒なので、
次回は別のキャプチャを考えた方がいいかも。


しかし、結構いろいろ実装したからと思って、動画をアップしたんですが、
前のと見比べると、あんまり変ってないですね orz

絵と音を作ってくれる人がいないと見た目的にはもう限界ですね。
中途半端に演出をつけても、なんか厨っぽさがムンムンで逆効果な気がしますよ(;´Д`)
とりあえず、グラフィックスとサウンドを担当してくれる方、大募集中です。

演出の方は置いておいて、中身の方はもうすこしで、一通りの対戦システムは実装できそうです。

ソコまで行けばテスト版を上げることもできるんですが、どうなんでしょうね。
これまでどおり動画のアップだけでもいいけもしますけど...。
まぁ、できたときに考えますか。
2010年03月15日(月) No.208 (Worlfard)
Comment(0) Trackback(0)

お茶碗を持つ方


ゲームの先攻後攻を決めるためにじゃんけんを作ろうとしてます。
プレイヤーとしては、じゃんけんはあいこになったりしてめんどいので、
コイントスの方が好きだったりするのですが、
コイントスのアニメーションを作るのがめんどくさそうだったので、じゃんけんにw

んで、Inkscapeで楕円を組み合わせてサクサクッと作って見ました。



あー、パーがビミョー...。

………。

んん!?あれっ?
じゃんけんって普通 右手!?


自分の左手見ながら右手で作ってたから、左手になってるよ orz


うぅぅん、もうこのままでいいか。
だれも右手、左手なんて気にしないよね(;´Д`)
2010年03月13日(土) No.207 (グラフィック)
Comment(0) Trackback(0)

そろそろ更新


今年もそろそろ更新の時期が来ました。うちのドメインの話です。

なにげにこのサイトも5年になるんですねぇ。
あいだ2年ぐらい欠落してますけどw

この前、日記のバージョンアップのために昔の記事を読んでたら、
スーファミで遊んでたりしたんですな、いい思い出ですw


しかし、最近Googleの広告を付けましたけど、サイト5年やって初の収入がついてましたよ。
広告で収益を上げるのが目的のサイトではないと言っても嬉しいものですね。
Amazonの広告リンクは結構前から張ってましたけど、うんともすんともいわなかったし。
クリック報酬型と成果報酬型との違いなんでしょうけど。


とりあえず1年分は更新したので、あと1年は続けていければいいな。
1年あれば、ドメイン代くらい広告で捻出できるようになっているかな?
ま、数ヶ月後に今度はサーバーの更新が来るのですが、そっちはたぶん無理だなw
2010年03月11日(木) No.206 (雑記)
Comment(0) Trackback(0)

れありてぃ



最近ちょこちょこ、PSPのカードゲームをやっています。
「THE EYE OF JUDGMENT(アイ・オブ・ジャッジメント)神託のウィザード」というゲームです。
こちらはPS3で発売されていたゲームの移植版で、
PS3版ではカメラでカードを読み込み、
テレビ画面上では、遊戯王のソリッドビジョンさながら、
カードから3Dのクリーチャーが飛び出して見えるという特徴を持ったゲームでした。

まぁ、移植に際してそこらへんの特徴は一切無くなっているんですがねw

とりあえず、ストーリーモードを1回クリアしてみたのですが、
いまいち、面白さがわかりませんでした。
このゲームは詰め将棋やパズルに近いタイプのカードゲームで、
私はそのタイプのカードゲームが好みでなかったり、
まだ、対人戦をやってなかったりするので、評価については言及しません。
やりこめば面白いのかもしれません。


面白いかどうかはとりあえず置いておいて、本題は『レアリティ』の話。
このゲームにはウルトラレアという最上級のレアリティを持つカードがあるのですが、
そのレアリティを持つカードが他のレアリティのカードより数段強く設定されています。

デッキからサーチする効果からそのウルトラレアが除外されていたり、
デッキに入れられる枚数が制限されていたりして、
ゲーム全体としてのバランスはとられては居るのですが、
カード1枚の価値を見たときに、かなりの差があります。

個人的にカードゲームでのレアリティは入手難度への影響程度に留めるべきだと思っています。
レアリティでカードの能力に差が作られるとしても、せいぜい効果の大きさ
(ハイリスクハイリターンやローリスクローリターンなど)の違いくらいにすべきで、
カードの強さを変えるようなことをするべきではないと思います。

対人戦前提で考えて、相手がどれだけ苦労してそのカードを手に入れたか、なんて事は知ったこっちゃないです。
相手が強いカードを使ったから負けたなんて、一番ゲンナリする事だと思います。

カードを集める側からしたらそういう差があったの方が楽しいのでしょうかねぇ。
2010年03月09日(火) No.205 (ゲーム)
Comment(0) Trackback(0)

紹介動画アップ


YouTubeに開発中のゲームの紹介動画をアップしましたよ。

http://www.youtube.com/watch?v=etV7WZVq4iA



まぁ紹介動画っていっても、現状のを見せているだけですけどね。
なんとなく、雰囲気は文章でだらだら書くより、
どういうの作っているのかよくわかるかなとw

まだまだ、開発途中で素材とかも適当で、見た目残念な感じだけど、
いまのところは生暖かく見守ってください<(_ _)>



しかし、動画をキャプチャしたのも、動画をようつべにアップしたのもコレが始めてですよ。
ちゃんとできてますかね?(;´Д`A ```

だれか、キャプチャした動画を半分の画像サイズに加工する方法を教えて。
2010年03月06日(土) No.204 (Worlfard)
Comment(0) Trackback(0)

ルール制定


ゲームのシステムやルールを考えるとき、
悩むことは多いけれど、カードゲームの場合は特に悩む事が多い。


今、カードの効果について作っているところなのですが、
効果が重複したときの処理について、どういう仕様にするかを悩んでいます。

例えば、「攻撃力に+1の修正を与える。」(以下、効果A)という効果があり、
その効果を2回重ねがけするということなら簡単である。
「+1」+「+1」で攻撃力を+2すればいいだけで済む話。

しかし、「攻撃力を3にする。」(以下、効果B)というような効果が加わると話は変ってくる。
クリーチャーに効果Aと効果Bが重ねがけされている場合が問題である。
攻撃力を3にしてから、その後+1するのか、
攻撃力を+1してから3にするのかという疑問が生まれるわけである。


この場合、仕様は2つくらいは考えられる。
1つ目は、それらの効果が掛けられた順番に処理するというタイプ。
この場合、効果A、効果Bの順に掛けられたときは、攻撃力は3になり、
効果B、効果Aの順に掛けられたときは、攻撃力は4になるわけである。

2つ目は、二つの効果を別の種類の効果であると区別して処理するというタイプ。
効果Bのような「攻撃力を○○にする。」という値そのものを変える種類の効果と、
効果Aのような「攻撃力に+○の修正を与える。」という現在の値に対して修正を加える種類の効果を区別する。
そこで、効果Bのような種類を効果Aのような種類の効果より、優先して処理をするという仕様にするわけ。
この場合、効果Aと効果Bのどちらが先でどちらが後に掛けられたとしても、
効果Bが処理されてから、効果Aが処理されるので、攻撃力は4になる。

2つ目の仕様はMTGで使われているタイプの処理方法で、
1つ目の方はどちらかといえば遊戯王タイプの処理。
(遊戯王の場合、結構ルールがカードごとに変るので、違うこともままある)


これまでは、ゲームのルールに迷ったときなどは、
どうしたほうがゲームとしてより面白くなるのかとかで決めてきたわけなのだが、
今回ははっきりいってどちらでも面白さ的には変らないだろうから、余計に悩む。

ルールとしてのわかり易さ的にいうと、どちらの方がわかりやすいのでしょうか?
2つ目のタイプは、文章にするとたしかに長いけれど、最終的に得られる結果はわかりやすいのでは?とも思う。
攻撃力=3になる魔法を受けて、攻撃力が1上がる剣を装備していたら、
普通、最終的には攻撃力は4になっていると、思わないだろうか?
逆に、「3になる。」と言っているのだから、3になるんじゃないの?ということも言えるのでしょうけど^^;


どういう基準でこういう判断を行うといいんでしょうねぇ。
2010年03月05日(金) No.203 (プログラム)
Comment(0) Trackback(0)

ブラウザとの戦い


昨日からこの日記の修正とバージョンアップをしてました。


このサイトを見ているみなさんは、ブラウザはなにを使っているのでしょうか?

やっぱりIEがwindowsのデフォルトブラウザとして最初から入っているから、
そのまま使っている人も多いんでしょうかね。
たぶん、いままでIEだと表示が崩れていたと思います(;´Д`A ```
サイドバーとかが↓にいってたり、重なって表示されてたりしてたとか・・・。

今はどうでしょうか?ちゃんと表示されているでしょうか。


しかし、この修正作業がイッライラしましたよヽ(`Д´)ノ
IEにはけっこうバグがあるらしく、
float指定をするとmarginが2倍になる不思議現象があったり、
hasLayoutとかいうよくわからない謎システムがあるようです。

私は普段FireFoxを使っているのですが、
ちょこちょこと修正してFirefoxでちゃんと表示されるようになったと思って、
確認のためにIEで見てみたら、まぁ見事にレイアウトが崩れまくり。
よくわからないバグが相手なので、結局トライ&エラーを繰り返すしかなくて、
ほんと無駄に時間を使ってしまいましたよ。

MSさん、ちゃんとバグフィックスしてください orz

もうね。IEなんかいらね。なんでハンゲやミクシはIEオンリー?
IE互換がよければ「Sleipnir」
そうでなければ、「FireFox」あたりにさっさと乗り換えましょう。
2010年03月04日(木) No.198 (雑記)
Comment(2) Trackback(0)

うるう年?


昨日は、PS3にとっては2月29日だったらしい。

・PlayStation®3にて発生していた障害について
http://www.jp.playstation.com/info/support/sp_20100302_ps3.html

本当はうるう年ではないのに、うるう年と勘違いしていろいろと不具合が出たらしい。


うるう年の扱いを間違えるなんて、かなり情けない。
興味が無い人からしたら、「フーン」程度のことだろうけど、
ちょっと知っている人からしたら、

「うるう年間違えるとか、ちょwwwwバロスwwwwwwwwwww」

とか言われちゃうくらいだと思う。
例えるなら、円周率を3.15とか言っちゃうレベルかな。

おそらく、プログラムした人が、「うるう年なんか間違わねーしw」って感じで、
ちゃんと確認しなかったケアレスミスみたいなことなんでしょうが、
スーパーコンピューターにも使われるくらいのポテンシャルを持っているPS3なのに、
なんか悲しくなりますね。


がんばれ、ソニー!
がんばれ、日本の大企業!


2010年03月02日(火) No.195 (雑記)
Comment(4) Trackback(0)

スクリプト言語


うーん、コレは限界を感じる。

今回はカードゲームを作っているわけですが、
(あ、題材について言及してなかったw まぁ、また今度書く事にしよう^^;)
カードゲームの特徴としては、カード1枚1枚の効果や能力がさまざまで、
ときにはゲームのルールを超える程のバリエーションがあるということ。
例えば、普通は相手のHPを0にすれば勝ちなのに、
カードの効果を上手く決めれば問答無用で勝ってしまうとか(゚Å゚;)

で、そういうのを表現しようと思うと、カード1枚1枚について、
それぞれ個別の処理を実装しなければならなくなる。
それ自体はあえて言えば、不可能なことではないと思う。

しかし、そこにNPCの思考ルーチンとかを組み合わせることを考え出すと、
スパゲッティ化は目に見えている。)'д`)グハァ
ある程度共通の処理もあるだろうから、うまくパターンを作ってまとめれば、
100種類のカードに100種類の個別の実装、なんてことにはないだろうけど、
まぁまず、近い将来破綻することになるだろう。

それに、カードのパラメーターやゲームの設定データみたいなものを組み込みたくないのと同じように、
あまりCPUのロジックやカード別の処理の流れなんかはハードコーディングしたくないし。

そこで解決策として登場するのがスクリプト言語なんだろうなぁ。
データ部分を外に切り出せるし、個別の処理をデータみたいな形として扱えるようになる気がする。
開発作業も、トライ&テストでいちいちコンパイルし直さなくてもよくなるだろう。

そこで、スクリプト言語をゲームで使うとなると、「Lua」辺りが有力なんでしょうか?
個人的にはC++と相性がより良さそうな「squirrel」なんてところもアリかなと思うのですが。
しかし、いまからこれらを使うとなると、システムを1から考え直さないといけないわ、
スクリプト言語自体の習得オーバーヘッドも相当な気がするとか、かなりしんどい。

処理を設定ファイルの読み込みとか処理フローの解析、構築みたいに限定して、
実際の個別の処理はいままで作ったC++に担当させるようにすれば、
簡単な独自スクリプトを組むだけでも、実現可能なのだろうか。
それともやっぱり、ちゃんとLua辺りに対応するよう組替えた方が、
急がば回れで、いいのだろうか。

うーむ、悩ましい(-ω-;)
2010年03月01日(月) No.194 (プログラム)
Comment(0) Trackback(0)