1人でゲームが作れるように修行します。

アクセス規制、やっと解除〜！

>>921
ゴール画像表示直前で強制終了する事からその可能性が高そうなのでもう少し粘って探してみます〜。
>>922
実は今までバックトレースの存在に気付かずにプログラムやっていたような感じ。コンパイラの画面には出ていたのかも…。
>>923
使用しているのはVC++2008で、デバッガはあまり活用できてないです…orz
>>924
どうもです〜。これで今までに比べ、バグ発見度が上がりそうです〜！

バグメッセージの一部「ハンドルされていない例外が発生しました: microsoft c++ の例外: std::out_of_range」でググってみたら、
ttp://www.play21.jp/board/formz.cgi?action=quote&resno=39962&id=dixq&lognum=122
にも参考になるページを発見。

>>925,928,930
画面切り替えの確認出来ました〜！
状態の管理？のような処理には自分も悩んでいて、本も調べたりしたけど、
なかなか理解できないので（…orz）今は、テクニック不在のif文で処理を分けてみる方法でいこうとしてるところです。

ttp://github.com/happana/srpg/downloads
SRPG version 0.0.8

マップ切り替え時のワイプアウト・フェードインと日本語表示ができた。
そろそろ敵を出したいけど、リソース作りが面倒…

もう日本語表示、す…凄い進捗速度な感じ。

こちらは例のバグがどこで出てるのか判明。
グラフィック表示の処理関数のところで止まっている。
しかし、そこを見る限り問題はなさそうだが、何度か眺めている内に画像表示のループ回数を設定する数値が
１０にしたはずが１になっているのに気付き、よくよく調べると、
メインループで各オブジェクトの画像データをロードする関数を一括して呼び出す処理の部分で
ゴール画像のロード関数だけが呼び出されていなかった…orz
それでアサーションとかがひっかかっていたのかもしれない…。
そんな間違いしてると思わなかったから発見に異常に時間がかかってしまった…。
コンパイラに関するアドバイスが効いてどうもです〜みたいな感じ。

次はゴールのあたり判定について検討の予定。
コの字型のゴールにボールが入ればゴールの判定、それ以外はボールが跳ね返るようにしようと思うものの
かなり難しそうな予感。

規制解除(・∀・)

キーコンフィグをぼちぼちつくる
ついでに文字を管理するクラスを改良
もうちょっとでモチベが上がるSTGゲーム本体の部分にとりかかれそう

規制解除オメ！（←２ちゃん風に）です。

こちらは進捗０でゴールは早くても来週になりそう。
ゴールとボールのあたり判定とゴール（得点）の判定を同時に考えるとこんがらがりそうなので、とりあえず前者の判定の実装だけを考えてみる予定。

ジョイスティック対応、リファクタリングと見た目には進捗なし。
ここまで適当にコーディングしてきたツケが回ってきた感じ。

そろそろ戦闘画面を作る。

こちらは当たり判定に「線と線のあたり判定」が使えそうだ（ゴールは３本の線で出来てるともいえるから）と思い、検索してみたけど内容がよく理解できず。
どうやら数学の素養が必要なのかもという気がしてきたけど、今からそれをなんとかするにはかなりの時間を要するのではと悩んで終了。
判定できる理由が理解できなくてもプログラムに書けそうならブラックボックス的にやってみるしかないかもしれない…orz

>>941
ゴールを矩形、ボールを点と考えるのはどうですか？
ボールの速度が速すぎると突き抜けたり
横からねじ込めたりしてしまうけど。

>>942　どうもです〜！
そうですね。改めて考えてみるとゲームの処理の流れを作る事の方が優先事項だと思うし、ボールがゴールに入ったかどうかの判定の実装は今は諦めて、
ゴールはコの字でなく矩形と考えて、ゴールにボールが当たったら得点したという事にしてやってみようと思います。

また色々バグが出ると思うのでプログラムをコピーして、プログラムファイル名の数字をひとつ増やすところまでで今日の作業終了。

ttp://github.com/happana/srpg/downloads
SRPG version 0.0.9

とりあえずのやっつけで戦闘画面、エンカウントを追加。
後、適当にジョイスティックに対応。
右奥から行ける2つ目のマップでエンカウントできます。

画面の動き、確認できました〜！

こちらも頑張ろうと思い、コンパイラでソースを開いてみたものの、
ちょっとでも見てないとすぐ中身を忘れてしまう自分。
土日があっても何ともいえない状況だけど、まだ諦めないつもり。

半月も経っていないのにマップデータの作り方を忘れていてびびった。
ソースコードにコメントを、ってのはよく聞くけど
データの作り方とかもドキュメント化しておかないとやばそう。

自分はソースを１日見なかっただけでも中身を結構忘れてしまう方なのでいつも苦労してます。
以前にプログラムの構造を図にしてみたけど、中身もだいぶ変わってしまったので、
また区切りが付いたら図にしてみようかな〜と思ってます。

こちらの進捗についてはやっぱり１日単位ではなかなか進まないのが現状な感じ。
ゴールの得点処理の実装の前に時間の経過に合わせて前半、ハーフタイム、後半の状態遷移的な
処理をするためにif文でそれを書こうとして途中までの段階。

戦闘時の攻撃を作ろうと思って長考。
武器ごとにモーションって変えたいですよね。剣と槍じゃ全然違うモーションになりそう。
全武器種ごとのモーションをキャラクタデータに入れちゃうと
キャラクタデータが大きくなりすぎるので困りそう。
後、モーションの呼び出しも大変になりそう。
if(剣装備中) {
　　chara->start_motion(剣攻撃モーションID);
}
else if(槍装備中) {
　　chara->start_motion(槍攻撃モーションID);
}
みたいな。できれば
chara->start_motion(攻撃モーションID);
にしたい。で、武器側にモーションデータをくっつけて
武器を装備した時にその武器用の攻撃モーションを読み込むようにしたらいいじゃないかと妄想。

*キャラモデル
*汎用モーション(待機、歩き等)
*剣攻撃モーション(モーションID:10)
*槍攻撃モーション(モーションID:20)
*...攻撃モーション(モーションID:30...)
＋
*武器モデル
↓
*キャラモデル
*汎用モーション
＋
*武器モデル
*攻撃モーション(モーションID:10)

みたいな。武器変更しても常にモーションID10を流せばOKみたいにできそう。

問題はキャラごとに攻撃モーションも変えるかどうか。
男/女用で変えることはありそう。

*武器モデル
*攻撃モーション(モーションID:10)

が

*武器モデル
*男用攻撃モーション(モーションID:10?)
*女用攻撃モーション(モーションID:10?)

とかになって、もうちょっと考えないといけない。

でもモンスターハンターとかって男も女も一緒のモーションだったっけか？

とりあえずシンプルなRPGなんだから全キャラ攻撃モーションは統一でいいような気がしてきた。

なんかがんばって長文書いたら改行が多すぎとか言われて色々説明削った。
こんなことはチラシの裏にでも書いていた方が良かったかも…
スレ汚しごめん。

通常攻撃のこと考えてるみたいけど
ワザとか使うことを考えると、モーションなんて行動毎に毎回違うものになるんじゃないかと
って個人製作じゃそこまでモーション作るのが無理かｗ

確かに通常攻撃も一種の技(MP消費なしの物理ダメージを与える技)として管理すれば
こんなことしなくても良いかも…

そう考えるとまず、戦闘システムを考えた方が良さそうだな。
つかまだステータスも考えてなかった…

王道でいくと HP,MP,攻撃力,防御力,魔力,すばやさ とかか。
適当に RPG ツクールとかを参考にすればいいのかな。

RPGツクール2000,VXの体験版を落としてみた。
初めて見たけど、こういう感じなんですね。
まだまだ色々と作らないといけないことが分かった。
先は長いな。

自分の方は選手の移動パターン１つだけなので将来増やす時に悩みそうな予感です。
進捗はまだゴール得点処理と状態遷移関係実装を書いたり考えたりしてる状態。

前半から後半に切り替わる時に選手のデータの座標だけ左右入れ替えるような初期化したいのに
他のデータも全部一緒に初期化してるのが我ながら変な感じだな〜と思いつつ、他にいい方法も浮かばないのでそのままプログラミング中。
コンパイル開始出来るのは早くても明日…だといいんだけど自信なし。

なんとか一通り書いてコンパイルしてみたけど失敗。エラーは８０個程。
if文で条件分岐させる為に色々と定義した変数がソースの各所にちらばってしまい、
それがうまく認識されていないのが原因のひとつになっている様子…。

ttp://github.com/happana/srpg/downloads
SRPG version 0.0.10
仮ステータス,装備変更実装、まだ戦えない。

装備変更画面はまだで、装備をタイトルから選べるようにした。

HP,STR(力),VIT(体力),AGI(素早さ)などを実装。
体格(Physique)という値を用意した。
体格は大きいと HP,STR,VIT は大きくなり、AGI は下がる補正値。
今は敵の体格値50-150で変動。

のちのちはマップごととかに体格範囲を決めれるようにしようかと思ってる。
体格値がやたらとでかいのばかり出る、巨人のダンジョンとか
逆の小人のダンジョンとか作れたらいいなあ。

体格はモンスターハンターとかペルソナ4あたりの
時々大きさが違うのがいたのを参考にした。

動き、確認できました。場所によって２体の敵キャラの距離感が変わるのも確認出来ました！。
これが体格値変動の効果かも。

こちらの方は、昨日のバグはなんとか取れました。バグの大半は、

「　'0x3000': この文字を識別子で使用することはできません　」というメッセージで、

これは全角を使ってるのがいけないという事を言ってるらしく。
最初気付かなかったけど、空白部分に空白の全角文字が使われていたのが原因。
（以前にも似た事あったからか今回は早く気付いた。）
では何故全角になってたのかというと、switch文を書くのが面倒だったので、
どこかのホームページからコピペしてcase：以降の中身だけ書き変えてすまそうとしたら、
そのコピペした部分に含まれている空白が全角だったから。

ということで現在は得点が０対０で右上に表示されるところまで進んだところ。
バグとれたのになんで画面の遷移がないのかというと、if文の条件を満たした時の中身はまだ何も書いてないから。
コンパイルが通ったという事は、今回新しく用意したいくつかの状態遷移に使うための変数がとりあえず認識されてる様だな〜というレベル。

今日はあまり進まず。
１５秒後に状態が前半からハーフタイムに切り替わり、その切り替わった時の時間カウント表示が、
再び０から開始するようにしたかったのにうまくいかず。その後、運よく気付き、解決〜！

if(matchstate == FIRST_HALF){　略　}
のenum型変数matchstateをゲーム開始時にif文に処理が来る前にFIRST_HALFに初期化しておく必要があり、
そのように初期化してたと思ってたところが間違っていた。

自作の初期化関数initStage()の中で、
matchstate==FIRST_HALF;と書いていたのが間違い。
正解は、
matchstate=FIRST_HALF;
これで動いたのでたぶん今のところは大丈夫かも。

デバッグも兼ねてステータス表示画面とかを作ろうと思ったが
画面レイアウトが面倒くさい。
ハードコーディングはしたくないんだけど
2Dレイアウト用ツールとかあるのかなぁ。
Inkscapeでsvgを吐き出してどうにかならんかなと調査中。

何かいいツールが見つかるといいですね〜。
自分のサッカーゲームは、ソースとデータが混在しててかなり分かりにくくなってマス…orz

今日は、前半でゴールした時に「ＲＥＤ　ＴＥＡＭ　ＧＯＡＬ！」と表示されるように出来た（まだ赤チームの方しかゴールできない）けど、
その表示がいつまでも消えない…。今日はここまで〜！

2Dのレイアウトの前に単なる画像表示をしていなかったことに気づいた。
一枚の画像にいくつかの絵を敷き詰めて
x,y=0,0から32x32の領域を表示。みたいにしようと思った。
一枚の画像に絵を描くのはいいんだけど、座標と幅、高さの指定が面倒だった。
Inkscapeの勉強がてら矩形のIDと左上の座標、幅、高さを
出力するExtensionを書いてみた。
Inkscapeに画像をドラッグアンドドロップして
矩形で切り出す領域を囲っいつつIDを振っていく。
そして下記のようなJSONを出力できるようにした。
[
{'id': 'title',
'x': 0, 'y': 0, 'width': 128, 'height': 64},
{'id': 'menu',
'x': 0, 'y': 64, 'width': 128, 'height': 64},
]
後はパースしてゲームで表示するときは
Sprite.draw(ID);
みたいな感じで表示できるようにした。

Inkscape、Extension、JSON、ググってみたけど、後者２つは難しすぎて解りませんでした〜orz

こ…こちらは、バグの話しか出来ない状態…。

error C2440: '=' : 'bool' から 'GOALSTATE' に変換できません。
（誤）if(goalstate1 =! goalstate){略}
（正）if(goalstate1 != goalstate){略}

error C2143: 構文エラー : ';' が '}' の前にありません。
（誤）
switch (goalstate) {
　　　　（　略　）
default:
}
（正）
switch (goalstate) {
case RED_GOAL:
　　　　（　略　）
default:
break;
}

これの解決だけで昨日はかなり時間を消耗…orz

そして最後にもうひとつ、
、
error C2653: 'SoccerGame' : 識別子がクラス名でも名前空間名でもありません。

というキツいのが出て、昨日の夜には解決できなかった。

>>961
ExtensionはInkscapeの機能を拡張するための仕組みです。
Inkscapeの保存形式とかを自分の好きなように拡張できる仕組みがあるんです。
情報が少なくて苦労しました…

JSONは単なるテキストのフォーマットです。XMLとかCSVみたいなもんです。

今帰宅で明日も嫁の来客の対応などで日曜まで何も手をつけれない予感。

なるほど！どうもです〜！（たしかにExtensionは検索してもあまり出てこなかった感じ）

こちらはほとんど進まずだけど、一応バグは取れた感じ。
やろうとしていた処理は、GOAL！という文字表示の経過時間を覚えさせておくための変数を宣言、定義して、
５秒後に消えるようにする内容だけど、この変数のところで昨日のバグメッセージが出てた。
大雑把に書くと、
soccergameクラスのヘッダファイル、soccergame.ｈの中で
static unsigned int timer;
static unsigned int s1;
static unsigned int e1;
と書いて、soccergame.ｈに書いてあるsoccergameクラスの宣言の外側で、
unsigned int timer=0;
unsigned int s1=0;
unsigned int e1=0;
と書いてた。これは静的変数なんで外部で値を定義しなければいけないみたいな事が書いてあって、
実際、目的は同じで名前の違う変数もソースに含まれててそれはバグになってなかった。
だから、それとの違いを見つければバグも取れるだろうと思い、よく見てみると、

private：かpublic：の違い←これは関係なかった。
変数の定義をするときに変数名の前にその変数がメンバになっているクラスの名前が付いていたのでとりあえず同じように書きなおす、
unsigned int SoccerGame::timer=0;
unsigned int SoccerGame::s1=0;
unsigned int SoccerGame::e1=0;
しかし、これでもバグが消えない。
そして、よ〜く見てみるとうまくいってる方の変数は、ヘッダファイルではなく
定義を書いているファイルの方に書いてあることに気が付く。
soccergame.ｈではなく、soccergame.cppの方に書くと動いた〜！
原因を理解した上での解決ではないので今後の不安が残るもののこのまま作業を進めることにするつもり。

言語レベルのことで引っかかりすぎだろｗ

た…確かに！
プログラマじゃないので要領がつかめず、なかなか前に進まないのがつらいところです。（汗；）

今日も少しだけ作業…。
ゴール得点後にボールがまだゴールに接したままなのでさらに得点がカウントされてしまう問題を直す。
ゴール判定直後から５秒間までは、ゴールの状態を表している変数をNO_GOALにしておいて、五秒後に
選手とボールの座標を初期位置に戻すようにプログラム！
ここまでを前半戦の処理については一応実装出来た感じ。
あとはハーフタイムと後半戦にも同じようにするだけ。
書くとわずかな内容に見えるけど、頭こんがらがった。（苦笑）

試合開始から結果表示までの処理の流れの実装がなんとか完了。
テキストっぽい文字が表示されるだけなので見栄えは今までと変わらないように見える…orz
とりあえずこれで休める〜！

次の小目標は、
今まですべての選手が一斉にボールを追いかけていたのをやめて、
ＦＷは前１／３、ＭＦは中１／３、ＤＦは後ろ１／３の範囲にボールがある時だけ
ボールを追いかけるようにプログラムを直す。
…にしてみる予定。

それとプログラムソースの方は作業ペースを少し落としてもやむを得ないので、
ネット、３Ｄ、ＡＰＩの勉強にも少しずつ並行作業で挑戦してみよ〜かな〜という気もしてマス。
ちなみに３ＤとＡＰＩについては、ゲームプログラムの勉強を始めたばかりの頃に
一度挑戦してすぐに挫折した経験あり…orz

かじってみて挫折したものは必要に迫られてからやり直せばいい。
必要でもないのに再挑戦したってまた挫折するだけ。

わき道にそれすぎ。

2D描画とツール探しでプログラミングが停滞中。
3Dはモデリング、オブジェクト配置、アニメーション、全てblenderで作れるが
2Dでオブジェクト配置、アニメーションができるツールが見当たらない。

ファイルフォーマットでいえばSVGが限りなく答えに近い気がしてて
InkscapeがSVG Animationに対応すれば完璧なのに！

ツールでいえばFlashが一番近いと思うんだけど有料ソフトは一切使いたくない。
とりあえず wysiwyg できないけどテキストでアニメーションデータ書くか…

>>968
そ…そう言われたらなんとなくそんな気もしてきました。
２Ｄで作れなければ結局その先の事を考えても意味が無いかもしれないと考えてみれば、
まずは２Ｄをどこまでやれるか試す方が先かな〜とも思うので、やっぱり２Ｄを優先する方針でいきます。
>>969
自分も何か知ってれば書きこみたいのですが、実はそのジャンルのツールを使用した経験が無くて…orz

適当に2Dの配置+アニメーション用データを定義してみた。
タイトル(ID:title)のy座標が0〜10フレームの間で-50.0から10.0に変化し、
項目0(ID:item0)のx座標が30〜40フレームの間で340.0から230.0に変化する場合だと
[
　{"id": "title",
　　"animation": [
　　　{
　　　　"name": "y",
　　　　"type": "ease_out",
　　　　"begin": 0, "end": 10,
　　　　"from": -50.0, "to": 10.0
　　　}
　　]
　},
　{"id": "item0",
　　"animation": [
　　　{
　　　　"name": "x",
　　　　"type": "ease_out",
　　　　"begin": 30, "end": 40,
　　　　"from": 340.0, "to": 230.0
　　　}
　　]
　}
]
みたいに書く。
まだ色々機能が足りないけど、とりあえず動くところまでできた。

GWはしっかり休めるのでゲーム作りに励めそう。
さっそくVS2010EEが出てたけど、
今回のゲームが落ち着くまでは2008で行こうかと思う。

>>971
自分も何かテクニックを使ってみたいけど、まだ自分には無理そうな感じです〜。
中身を見てそう言えば自分の選手データにはＩＤに相当するものが無かったと気付き、
後々不便が起きるかもしれないので、今すぐ使わなくてもとりあえず選手データ初期化するときに
ＩＤも入れておこうかな〜と思ってみたり…。

一応>>967で言っていた選手の動きを実装する前に選手の動きの種類を切り替えるしくみとして使っていた
ストラテジーパターンというやつを無くすことができないか考えているところ。
これもテクニックなのかもしれないけど、もともと１４歳シリーズの本がこのやり方を使っていたので
やむを得ず良く分からないまま使っていたのが現実なので、このまま続けると後々苦労する予感。
何故かというとどうもこのやり方だと動きを切り替える事ができるといっても
入力と出力の形は同じでなければならないという制約があるようだから…。
ちょっとだけ考えてみていい方法が思いつかないなら、このまま進めてその制約で出来る範囲の動きで我慢するか、
またifとか使って対応するかのどちらかでいくつもり。

>>973
デザインパターンにこだわらずに作ったほうがいいと思います。
switchを全部strategy patternにする必要なんてないんだし。
自分が作りやすいように作ったほうがいいんじゃないかな。

メニュー操作周りを作ってます。ドラクエみたいな
コマンド一覧->使用者一覧->まほう一覧->対象一覧（まほうを使うとき）
のように選択対象が切り替わっていったり、キャンセルで戻ったりの仕組みを考えていた。
なんとなくスタックでいけそうな気がする。
開いたメニューをスタックにpushしていって、topの奴が操作対象になる。
キャンセルでpopして前のやつに戻る。みたいな感じで。

僕も修行していいですか？
Cのポインタでつまるレベルなんですけど
テトリスとかオセロとかのミニゲームをなんとか作ったけれど、基礎を固めていくのは性に合わないのかいよいよ限界です。

タクティクスオウガを初めてやったとき目ん玉飛び出るくらい楽しかったので
クォータービューのマップを使ってなんかやれたらいいなと

>>975
どぞどぞ。

>>976
がんばりやす。

初心者らしくVC++2005とDXライブラリで作ります。

簡単に変数を表示できる簡易デバッグ用のクラスや、FPSを取得する関数がミニゲームつくりの段階で作ったのがあるんで
これを使ってしばらくは負荷テストに終始する予定です。
何も考えずに作ってみたらどうやらクォータービューはマップの描画だけでかなり負荷がかかるみたいなので。

今日までのテストでわかったことは

マップチップを長い逆三角形のように並べてマップを動かして負荷の推移を調べた
・マップチップが画面に多く表示されている部分は高負荷で、チップが少ない部分は低負荷だった
　→画面からはみ出た部分に関しては描画処理を行わない仕様っぽい。

同じマップでマップチップのサイズを大きくしてみた
（はみ出た部分は処理を行わない事がわかったのでチップを大きくし、面積当りの処理の回数を減らした）
・負荷が軽減した
　→描画面積より処理の回数の方が負荷に与える影響は大きい。

クォータービューの醍醐味である高さ方向へチップを重ねてみた　とりあえず単純に全てのチップを２段３段と重ねて厚くした
・負荷が一気に大きくなった
　→描画に関しては、画像が上書きされて見えなくなった部分も描画が行われていると考えられるため単純に２倍３倍の描画の負荷がかかっていると推測

次のテスト予定
３次元配列と構造体配列マップデータとしてどっちが適してるか
僕の環境で１画面にいくつまでチップを表示させても良いのか
馬鹿でかい画像と、ウィンドウと同じサイズの画像とで、ウィンドウいっぱいに表示したときの負荷は同じなのかどうか

こんな作業がしばらく続く予定です。

>>974
なんとなくそのような気がしてきた感じ…。
ストラテジーパターンで書かれているところを普通にifとswitchに書き直してみようかな〜と思います。
>>975
ど〜ぞヨロシクです〜！。自分はいつも言語段階で躓いてます！！

ttp://github.com/happana/srpg/downloads
SRPG version 0.0.11
キャンプメニュー追加。簡単な装備切り替えを実装。

今回は2D周りのアニメーション実装でかなり時間がかかった。
結局2Dのアニメーションは手書き…
1.テキストで座標とか書く
2.バイナリ化
3.ゲームで確認
を繰り返すことに…面倒臭い！

メニューはかなり面倒臭いことが分かった。
画面遷移からレイアウトやら表示すべき情報やら
考えないといけないことがいっぱいある。

>>978
どうもよろしくお願いします。僕も言語レベルで躓きます
分岐なんてifとswitchとあとなんか関数ポインタとか言うのがあるというのを聞いたことがある程度で
ストラテジーパターンなんてはじめて聞きました。そんなレベルです。



クォータービューを軽く描画するための残りの負荷テストが大体終了
まだあるけどキリがないんで

ふわっふわと実装へ向かってます
複数の画像を組み合わせた画像を新たな単一画像としてメモリにロードできるような方法があれば
画像をたくさん用意しないでも済むんですけど、色々さがしてみまーす

>>979
キャンプメニュー、見れました〜。
自分は、状態の遷移でifやswitchのスパゲティになってます。
>>980
もしかしてこのスレで紹介されてた>>822の事だとか…。


前半後半の遷移実装版をアップしようとして、
VC++でreleaseモードでコンパイル（デバッグ実行）したらなぜかバグ。
debugモードなら問題無くコンパイル出来るのにという謎に遭遇。
場所は画像を表示する部分で登録してる数よりもはるかに大きな数の
配列が用意されてしまってるところまではわかったけど、原因わからず…orz
もう１年ぐらいかけてもいいからＣで書きなおすのが良いかもと思いかけた時、
なんとなく「リビルド」してから、コンパイルしたら出来た！
でもこの調子だといつの日かＣで全部やり直し！なんてことになるかもと少し心配な感じ。
とりあえず、うｐしてみます〜！

ttp://gamdev4.hp.infoseek.co.jp/cgi-bin/up/No_0100zip.html

>>981
ソースコードも上げてれば困ったときに誰かが教えてくれるかもしれない！
とか言ってみる。

そんな希望を持ちつつ僕の場合はソースコードも上げてます。
みんなでソースコードとかも見せ合って
バグとか技術とか教え合ったりできたらいいなぁとか思ってます。

外野だけど887にアドバイスできるレベルの人はたぶんほとんど居ないと思うの

>>981
おおっと日向君強引なドリブルからのぉ・・・ゴォオオオオオオオルッ！！面白かったです。
サッカーゲームはAIも難しそうですね。サッカーやってましたけど人間の僕もよくわかんないで動いてましたし。

DerivationGraph　は近いんですけどやりたいことはこれとまったく逆の処理で
DXライブラリでいえばGetDrawScreenGraphが該当するんですけど透過情報が消えてしまうのが困り物です。
透過情報でなく、透過色指定をDXライブラリで出来た気がするんでその線で行ってみます


プログラムだけではアレなんでドット絵も晒して行こうかと思います。
憧れのタクティクスオウガ風のキャラ雛形です。
本音では解像度的にもう少し大きいサイズがいいんですけど大きすぎると一人で作るには作業が大変なんでとりあえず小さめに
ttp://www.gazo.cc/up/10455.png