SPCOLORを使うと、スプライト全体に色が乗ってしまいます。 この仕様だと、通常キャラクタの頭髪や鎧だけ色違いにするとか事実上対応ができません。 問題を解決するには、頭髪や鎧だけ別に書いて、SPLINKで分割したキャラクタを結合すれば、比較的簡単に対応できるような気がするのですが、なかなか自分で確認できないので、アイデアだけ投稿しておきます。 RPGとかスプライトの数に余裕があるゲームに向いている気がしますし、どうでしょうか、と。

けいさん＞ まずは滑り込みで遊んでいただき多謝です。 後半の難易度は、レトロゲームが現役だった時でも、 相当に無茶苦茶な難易度と思うので、なぶられたり屠られたりするのは「しようがない」というか。全ては私の不徳の致す限りで。 提案ありがとうございます。 提案といいますか「基本をキチンと実装する」レベルのご指摘ですね。料理で言えば「さしすせそ」の段階といいますか。言われて初めて気が付きました。 ご指摘部分は修正する方向です。 が、せっかくのインディーなゲームなので、ご提案以外の解はないか考えながら進めていこうと。 そういえば、けいさんが猫ゲーを最初に公開した時点で、既に猫の動作を作り込み始めていたので、焦った事を思い出しました。 ハードルは上がりきって、そろそろ大気圏ブチ抜いているでしょう。多分。 ハードルというか、既に棒か塔なので、気にする必要はないかと。

スーさん＞ 情報ありがとうございます。 がっつり長く遊ぶゲームではないので、思い出した時に遊んでいただければと。それまでに改修版公開 出来ればorz 当たり判定は本当に奥が深くて、作るときに調べてみたのですが、みなさん色々と試されているみたいですね。 「猫と銀魚」も４点で当たり判定をして、キャラクタ種類別に、無駄に細かく補正をしています（妖精が曲がり角で１０点入るときは、補正された合図です）。 焦ったときに納得のいくコーナリングができず、心象悪いのも確かなので、ゲームとして納得のいく落とし所を探ってみようかと（自然にうまく曲がれるように、テクニックを付けて頂けるような細工をするのがベストかなぁ...） 猫は色で分けるのではなく、スマホゲームの「つみネコ」みたく大きさ、種類で描き別けしたいんですが。なかなか。

既に書きましたが、想定より遊んでいただいています。 結果、難易度調整をしきっていないステージまで遊んで頂いてるようで本当に申し訳なく思います。 皆さんが詰まってるステージは、製作者もクリアできるか正直怪しいです。 とりあえず公開は止めませんが、もう少し今ある要素を磨き、再度公開させて頂こうと思います。

omusubi▲さん> 今回初めて当たり判定も含めてBG処理を組んだのですが、奥が深い処理なんだということを改めて感じました。 ２周目に関しては、スーさんのレスにも書かせていただきましたが、バランス調整がされておらず申し訳ないです。 本当に想定外なんで、最後までいって頂いても困ってしまうというorz

スーさん＞ まずは謝らなければいけません。 ２周目のバランス調整が不完全です。 初日で１周目クリアの報告が来るのは想定外でした。 魔女のバグ報告と、的確な改善点提案、有り難う御座います。 致命的なものから順に、考察と対応をして、ストレス要素を減らしていければと思います。 さて「ワープホール」と「通路の引っ掛かり」の件ですが、 多少の対策として、このような解決もあります。 ゆっくり歩くとワープホールに捕まらない（素通りできる） LまたはR +移動で、引っ掛かりにくくなる（４方向移動） 遊んで頂いて、本当に有り難う御座いました。

けいさん＞ 猫ゲーは本当に多くの方が作られていて。 けいさんのゲームと発表が被ると、私のは確実に埋もれるので、裏でこっそり発表時期聞こうと思ってました。割と真面目に。 さて、ホラー風の雰囲気ですが「化け物に追いかけられるゲーム」の需要があるようなので、少しはウケが良くなるかな、と。やたら早い猫が少し青いのは、そういうわけです。 開発時はハロウィン雰囲気にしたく「黒とオレンジと紫」でBGを書き換えてみたのですが、なかなか良い雰囲気にならず、諦めました。 プログラムは、いろいろと設計せず、書きながら決めていったので、整っているとは言いがたく...お恥ずかしいかきりで。 少しでも楽しんでいただいたら、公開した甲斐があります。

想定より多くの方に遊んでいただいてるようで、有難いやら嬉しいやら申し訳ないやら。遊んでいただいた皆さんに感謝です。

【公開キー:43XES3N3】 試しに作っていた1画面固定のアクションゲームが遊べるレベルになったので公開します。 内容は「妖精を操作して、追い掛けてくる猫を対処する」というもの。 冗長的なプログラムの割りに、地味な作品ですが、地味に色々機能を試したので、何かの参考になるかも知れません。 感想等頂けると励みになりますので、出来れば御願いします。

物理キーボードは「あると便利かも」と思う反面、タッチペンでのプログラミングに慣れてきて「下手なレイアウトの物理キーボードつなぐより快適かも」とか思ってきている私です。 （プチコンの仮想キーボード良く考えられてますし） 腱鞘炎にはならないでしょうが、コーディングしてペンだこが出来そうなのが最近の悩みのタネだったりしますorz そういえば初代プチコンから同様の話題はあって、プチコン書籍で「レゴマインドストームでプチコンを入力を自動化させる」って言うのがあったのを思い出しました。

３号、64ビットの浮動小数点数型（Cで言う所のdouble 型）が使えるんですね。精度的には整数部で15桁程度。すごいなプチコン。 さて問題を切り分けてみました。 1.指数表記になる件 A=1000000000 B=1000000000 ?"1:";A+B ?"2:";STR$(A+B) ?"3:";FORMAT("%D",A+B) 2の方法は確かに指数になることを確認。 2.大きな桁での計算について 「64ビットの浮動小数点数型」以外の精度が必要な数値を扱う場合、「高い精度の数値型を扱う」関数を自作する必要かもしれません。

以前、同じような事で悩みました。 調べたら１２月２８日に投稿していました。 私の活動から見て頂くと何かしら役に立つかもしれませんので、良かったらどうぞ。

なるほど、中断時に変数の値が残っているので、デバッガとして使えるんですね。 デバックに難航しているので、凄く有難い情報です。

SPANIMで直接指定から、ラベル文字列を指定してDATAで読み込みに変更。 「DATAの先頭に要素数が必要」なのを知らず、動かなくなったのは良い思い出（?）です。 '動く SPANIM 0,3,8,896,8,897,0 '動かない SPANIM 0,3,"@D1",0 @D1 DATA 8,896,8,897 '動く SPANIM 0,3,"@D2",0 @D2 DATA 2 DATA 8,896,8,897

キー方式で問題解決したようで何よりです。 別スロット方式の採用も視野に入れますか。 ふと、別スロット方式であれば、 「コメントにバージョン管理情報を埋め込めば、開発プログラムとバージョン管理情報が分離できて嬉しいかも」と思いついてしまった。 ‘バックアップ設定はソースの先頭コメントとかルール決める ‘@text:test.prg ‘@grp:test.grp EXEC “PRG3:BK" 'ここから開発プログラム ACLS:… 決め事が多いと窮屈で、プチコンのカラーではないですね。

次は誰かがDIFFを作ってくれると....

ご無沙汰しております。 DIRECTモードでは再現できない、スマイルボタン使用を回避すると、あとはソース自体の扱いに細工が妥当では、と。 単体駆動はヒロブミさんが提案されているので、別のアプローチを考えました。妥当性は、やや度外視です。 数週間前に「ソース先頭で自身ファイルsaveする」ことでsave漏れを防ごう　という啓蒙がありました。 同様に「プログラムの先頭で、slot3に管理プログラムを読み込んで、バックアップを自動化する」というのは、どうでしょうか。 検証はしておらず申し訳ないのと、起動時、必ずダイアログが表示されるので、バックアップファイル名に日時等を振ってローテートとsave制御タイミングを考える必要が有る、かも。 ついでに、その他の画像等リソースはどうするんだ、と。

お話終わっていますが、便乗して。 奇遇にも本日「PETIT.DOC」というツールを公開開始。 本日中に「PETIT.DOC」から「P3DOC」に変更しました。 「PETIT」の方はバグをだして引っ込めたという理由もあるんですが、だいたい皆さんと同じ思考にいたり「PETITもPUCHIも判りにくいならPでいいや」という斜め下の結論で、自分に決着。 あれです、引き算の美学です＞たぶん違う

忘れてた。関数と変数の一覧が表示出来るよう機能拡張しました。 製造中のゲーム読み込んでみたら大変な事に

変更点 * ツールの名称を「P3DOC」に変更。 * コメントを書かなくても関数、変数を検出するようにした。 （ある程度、制限はあります） * Smile Toolの起動を制限した。 * RELOAD機能を削除。SCOPE機能に変更した。 * その他細かい不具合。