ツール系ソフト全般に言えますけど、プレイする時間当たりのコストパフォーマンスに換算するとムチャクチャお得。 使いこなせる様になるまで投げ出さなければの話ですが。

自分はプログラム中で生成したキャラクターの個別データを別ファイルとして保存したい時は、UNIT[管理番号]みたいな配列を作ってそれぞれのステータスの数値の取り得る範囲から使う分のビットをやりくりして合計32ビットに収まる様にして、シフト演算でビットの桁を調整して合算して一つの変数に複数のデータを混在させるようにしてますね。丁度RGB関数が各色成分を合算して一つの数値データとしている感じを想像してもらえればいいかと。 読み込みはAND演算でマスク処理をして取り出してシフト演算で桁を戻すみたいな感じで。 どっちにしろ、みき★さんの方法の様に適当な変数を介してプログラム中で圧縮・展開してやる必要があると思います。

覚えることは買ってから考えた方がいいんじゃないですか？ 案ずるより産むがやすしですよ。 外国語と同じで、ぶっちゃけ慣れちゃえばなんとでもなりますし。

natto-/プチ3さんはスプライトの移動処理は書けますよね？ コンソール画面で表示位置を指定する命令もLOCATEを使うというところまではOKですよね。 コンソール画面で文字を移動させる処理で気を付けるのは、前に表示した文字はCLSで消去するか、空白で上書きしないとずっと表示されたままなので、消す処理をPRINTで表示させる直前にする必要があるんですけど、CLSを使わないのであれば前の表示座標を保持しておく変数を用意して退避させておく処理も必要になることですね。 X1=表示したい座標(X):Y1=表示したい座標(Y) LOCATE X0,Y0:PRINT "消したい文字数分の空白" LOCATE X1,Y1:PRINT "表示したい文字列" X0=X1:Y0=Y1 こんな感じでどうでしょうか。

２点間にGLINE命令で線を引いた後に、GLINEで使った２つの点の座標のうち終点を始点に、終点に新たな点の座標を代入する処理を書いてやれば大丈夫だと思います。 具体的に書くと @LOOP GLINE X0,Y0,X1,Y1 X0=X1:Y0=Y1:X1=X2:Y1=Y2 X2=次の数値:Y2=次の数値 GOTO @LOOP こんな感じの処理ですね。 でもこのままだと無限ループなので、実際はカウント変数で制御した方がいいですね。

重ならないという事は、移動先に既に他のスプライトがあったら移動をキャンセルする処理をすればいいわけですね。 SPHITRCで当たり判定を取ってから表示座標を変える命令を実行するかしないかを判定してやれば上手くいくかも。

LOAD命令で読み込み先リソースを指定して読み込めばプログラム内で使える様になりますよ。 スプライトならLOAD"GRP4:ファイル名" テキストデータがもしかしてフォントのグラフィックデータの事ならば、GRP4の所をGRPFに変えてやればOKですね。

先ず最初に言うとプチコンは同時に２つの事は出来ないです。 凄く早く順番に処理してるので時間的な差を感じないだけなんですね。 複数の処理をそれぞれ一つの項として扱い、一つの式にまとめる事は出来ますけど、「順番」を意識した方が色々と役に立ちますよっと。 と言う事は、自分と敵を動かす命令（表示座標を操作する命令）をループ内で間にWAITやVSYNCを挟まないで書いてやれば・・・・。 コンソールならLOCATE、スプライトならSPOFSやSPANIMですね。

プログラムって意外と専門用語多いですからね。 電子取り扱い説明書やヘルプでも単語の説明まではしてませんから、分からない語句があったらミーバースを活用してみたらいいんじゃないでしょうか。 まだ理解してない概念について質問する時は「こんな物に例えて説明してください」みたく、げんさんさんから注文を付けるのもアリですよ。

正統派の改造ですね。 つなぐ線は２回だけ曲がれるっていう取り方のルールだけ流用して、例えば絵を原子番号にして分子の組み合わせを作って取るようにしたり、取る順番に順序を設定してしりとりみたく取るようにしたり、ルールがシンプルだと改造しやすくて奥が深いですね。

プチコンって「遊び方」を作るソフトだから別に間違ってないですよ。

プチコンのグラフィックってアニメのセル画みたいに幾つかのフレームを重ねて表示してある感じなので、GPRIO命令やBGOFS命令でグラフィック画面のZ値を変化させて表示の優先順位を変えてやれば出来ますよ。

プログラムってキーとなる概念を理解しちゃえば後は芋づる式にスルスルと上達したりするので、焦らずに分からない点を整理してみたら良いと思いますよ。 で、分からないポイントが分かったなら他の人にアドバイスを求める。 分からない事を聞くのは全然恥ずかしい事じゃないですから、同じところで詰まっている人のトピックに便乗したり、トピック連投で他の利用者に迷惑が掛からない様にだけ気をつけて、先ずは聞き上手になっちゃいましょうよ。

えー、勿体ない。 折角同じ方向性のプログラムを作っている人を見つけたのなら色々質問して、とうどうしゅんすけさんの公開してたプログラムをバージョンアップさせるチャンスじゃないですか。 全然恥ずかしく無いですし、身を引くなんて起因になった人も悲しまれると思いますよ。

口調や表現の仕方は「人の振り見て我が振り直せ」ですね。 受け取る側と使う側では言葉に対する感覚が違ったりしますし、 自分は相手にもこういう言葉遣いをして欲しいという思いを込めてコメントするよう心がけてます。 フランクな意見を求めてる時はフランクな言葉遣いで、歯に衣着せぬ核心を突いた意見を求めてる時は辛辣な言葉遣いをする。 キャッチボールって相手にちゃんと届くと嬉しいし楽しいですよね。

コミュニティを膨らませようとするなら細かい粗探しより議論の方向性が問題になるんじゃないですか？ 例えば風船をコミュニティとして個々人の意見を中の空気の分子の運動とすると、 尖った強い主張は風船自体を壊しちゃうし、特定の方向性（意見）に偏ると膨らまずにコミュ自体が何処かへ行っちゃう。 でも強い主張が無いと膨らまずにしぼんじゃうから、フォロー入れるのは風船の壁の保護のために必要。 フォローする壁役はぶつかり合うパワーを無駄に熱くなってロスしちゃわない様に上手く方向性の違いに変換して、個々人の意見があっちこっち飛び交いながらもパワーを失わないってのが理想ですかね。

COLOR命令を使ったらPRINT命令の後に元の色に戻す処理もセットにしとくと便利かも。 特定の文字だけ特定の色にするってのを自動化してみたら面白いかもですね。

別の方法でクリアっていうのだとこんなのもアリ？ 飛び地を作ると繋がってる牌の数が少ない方が消えて、消える牌といっしょに牌の上を動き回っているキャラを全部消したらクリアとか？

ツール系ソフトが面白いと思える人って、その人自身が面白い人だったりする場合ってありますよね。 見た目じゃなくて中身が。

嘘を言わせるプログラムっていうのも面白そう。 相手の嘘を見破るダウトっていうゲームの対コンピュータ戦を数当てゲームを下地にして作ったら作り易いかも。