お散歩モードのイメージ画(まだプログラムではない…。) 背景はデフォルトのBG素材を加工して作っています。 これだと背景を動かせないので、キャラクターを動かすしかない…。 キャラの位置を固定して、背景を動かしたいと思ったけれど、難しいのでこちらの方式を使って作るしかなさそう…。(この背景は気に入っているので、これを使いたいとは思っているし…。)

人と犬に影がないですね。 まさか… 散歩中に事故にあって… 幽霊!?

できれば影を付けたいけれど、動くキャラの影って難しいですよね…。 ポーズに合わせて影の形を変えるには、複数の影を作らなければならないし、みんなは影をどうしているのでしょう？ そういえば、他人の作品で影をどうしているのか？あまり気にしたことがなかったけれど、動くキャラにしっかりとした影を付けている作品って、どのくらいあるのでしょうか？

例えば、 正面方向に歩くキャラの影なら、 横方向に歩く時の絵を歪ませて作ればいい、 と思います。

45°の影に限っちゃいますけど、 FORで1ドットづつずらせばいいかと。

手を抜くなら回転・着色・伸縮あたりの組み合わせでなんとかならないかなぁ…？

だにえるさんへ なるほど！そのような方法が…。 角度が限定でも良さそうな感じですね。 そのような感じの影を描いて、少し変化させれば、それでも影っぽく見えそうです。

でんぺんさんへ それは影の表現方法ですよね？ さすがに、この背景を動かす方法ではないですよね…。 回転・着色・伸縮を使うのは「手を抜いた方法」なのですか？（焦） 高度な方法としか思えませんが…。（汗）

ちなみに、最初は木の影も描いていなかったのですが、それだと道があまりに殺風景だと感じてしまったため、石ころを追加したり影を付けたりしてみようと描き足していき、現在の状態になりました。 でも、まだ草の部分の影も描いていなく、影を省略した状態にしたほうがラクかな…と思ってみたり…。 雲に覆われて影が目立たない状態にしてしまうのが一番面倒ではないという…。

格闘ゲームの影風なら、ただの黒い楕円(SP)をSPLINKするだけで良いのでは？

確かに、真上からの影なら形をほとんど気にせず、適当に付けておけば良さそうですけど、本来ならキャラが移動するのに合わせて、影の向きや形が変化するのが正しいのですよね…。 ただ、そこまで厳密な表現方法になると、かなり高度な技術が必要になり、市販品レベルの内容を目指す感じに…？ ちなみに、このソフトの主役は犬であり、プレイヤーが犬と戯れて癒されるのを主な目的としていますので、背景や飼い主にはあまり力を入れていません…。 この前に投稿した犬小屋と庭の画像も簡素な感じなのは同じ理由からで、主役の犬より背景が目立ってもしょうがないと考えているからです。 もちろん、あまりにも酷い見た目の背景だと、作品の質に影響しますので、それなりの質に描く必要はあると思いますけどね…。

影をリアルにしようと思えば思うほど他の部分との整合性が取れなくなるし処理速度も遅くなるため妥協することも大切ですね。 簡単でそこそこリアルにしようとするならば影を自動生成するのではなく影のスプライトのドット絵を別途用意するのがベターだと思います。

そうなんですよね……影を考えた時に、木の影も変化しなかったら不自然…とか考え出したら、他の部分も変えなければ…と延々なっていくので、ある程度の表現で良いや…と思うしかないと感じています。 某大ヒットアニメ映画のように、木漏れ日まで表現していたら、凄いでしょうけど、そんなレベルを個人で作るのは無茶ですからね…。

影をどうするかという問題以前に、基本的なプログラムがまだ未完成なのですが、各種ボタンが押された時だけイベントが発生し、何もボタンが押されない状態が続いたら、勝手に行動しているという条件設定をするには、どのような形式で入力すれば上手くいくのでしょうか？ 各種ボタンの入力を待つのは無限ループ内にIF文でできますけど、 数秒間何もボタンが押されなかった場合に分岐させるのが失敗しています…。 1.何もボタンが押されないという条件と、 2.数秒間ボタンの入力を待つ状態を どのようにすれば良いのでしょうか？

IF ボタン変数==0 THEN FLG=1'フラグ ELSE FLG=0 CNT=0 ENDIF IF FLG THEN IF CNT＜60 THEN CNT=CNT'カウント ENDIF IF 60＜=CNT THEN'1秒以上経過している イベント ENDIF

↑をメインループに入れます。 IF FLG THEN～ は数値が上がり続けるのを 防止するためにあります。

だにえるさんへ そのプログラムで行われることを考えた結果、よく分からない点があります。 最初のIFでボタンが押されたかを確認して、押されなければフラグが成立、押されれば不成立でカウントがゼロに戻るというのは良いのですが、 次のIFは数値が上がり続けるのを防止するためと書いてありますけど、CNTが増える部分が無いし、例文では1秒以上経過したらイベントが発生となっているみたいですが、上にCNT<60という条件があると、60<=CNTにはならないのでは？ ちなみに、各ボタンが押されるのを充分に待つためには、押されなかった場合に発生するイベントが早過ぎてはいけないので、4秒くらい待ってもボタンが押されないと自動イベントが発生するようにしたいです。 また、各ボタンが押された場合は、それぞれで違ったイベントが発生するようになっています。

あ、 CNT=CNT+1 の+1が抜けてました。 IF CNT＜60 THENでカウントが増えるので 59の時にも増え、 よって 60＜=CNT は成立します!

»4秒で反応させたい。 60を240に変えれば良いのです。

»各ボタンによるイベント 簡単な方法(初心者向け)なら IF ボタン変数==#リテラル THEN@～ でいいと思いますが?

2番目のIF FLG THENって、IF FLG==1 THENじゃないですか？ ボタンが押されなかった(FLG=1の)場合だけ、カウントが+1されるわけですよね？ 各ボタンで発生するイベントは上記の形式で入力済みです。

横入り。 IF FLG==1 THEN は IF FLG THENと書けますよ。 IFは0か0以外かで判断されるので、省略するのはよくある感じです。とくに変数が真偽（TRUE(1), FALSE(0)）のみを保持している場合や関数が真偽を返す場合などは、省略しても混乱もなく短くすっきり読みやすくなるメリットもあるんです。

あっ！そうなのですか！！ それは良いのですが、実行してみたら、自動イベントが一度発生してしまうと、その後にボタンを入力しても自動イベントが繰り返し発生してしまいます…。 ボタンを入力するタイミングが上手く設定できていないのか、原因がハッキリしていませんけど、何が悪いとそういう状態になってしまうと考えられますか？ WAITの長さに問題があるとか、VSYNCの位置に問題があるとか、原因が分かれば修正できると思いますが…(´・ω・`)。

ボタン変数を更新してますか? してあって、その状態であれば ボタンでGOTO(GOSUB)の行き先を判定 する部分を見せて下さい。

まだ全てのボタンイベントを入力できていないのですが、実行可能なボタンで調べてみた結果、 最初は、各ボタンの判定をループ内の最後に入れていたのですが、それを自動イベント発生判定の前に入れるようにしてみたら、ちゃんとボタン判定がされるようになったみたいです。 他にも、自動イベントの終わりのWAITを60にしてみたり、コマンドを下画面に表示した後のWAITも60にしてみたりと、変更したおかげなのかは分かりませんけど、とりあえず目的の判定方法ができるようになったみたいです♪ これまでに、何もボタンが押されなかった時だけ別の変化をするというプログラムを使ったことが無かったので、戸惑ってしまいましたが、何とかなりそうで助かりました！

解決したのでよかったですが、症状や解決内容から考えると自動イベント発生後の処理でボタン判定に影響する変数を壊してしまったのではないかと思う感じですね。 まあ解決したので問題ないとは思いますが、プログラムの流れや使用変数には気をつけないとよくあることではあります。とくにGOTO、GOSUBやDEF命令でのローカル変数未使用などの場合は変数の上書きは見落としやすいので注意してください。 ではでは。

変数を壊した可能性？！(そーなのですか？) 変数の扱いを間違えてはいないつもりですが、以前に「変数名は正しいのに、代入する数値が少しズレてしまっただけで、別の変数名にまで影響した」という怪現象があったのですが、それのことですかね？ 今回はそういうズレは無かったので、たぶん別の理由のようですけど、「変数名が異なるのに、別の変数に代入したはずのSPが表示された」時はビックリしました！(その時に、変数名が違っても影響することがあることを知りました。)

あ、勘違いさせてしまっていたらすいません。 変数を壊した可能性というのはあくまで自分のミスでということです。（変数名の重複があったりなど） プチコンの場合、配列などは変な扱いで壊れる可能性があるみたいですが、それ以外では通常は変数の値がおかしくなる事はないはずです。 基本的にはおかしな症状はほとんどが自分のミス（プログラムのミス）で、システムのミス（バグ等）は滅多な事ではありません。なので動作がおかしい場合、なんらかのミスをしている可能性が高いです。 公開キーなどを出せるのであれば他の人に調べてもらう事も出来ますが、そうじゃない場合は自分で解決するしかないので、色々と気をつけて調べてみるといいと思います。 あともしOPTION STRICTを使ってなかったら使うのもオススメします。プログラムのミスが発見しやすくなるので…。

OPTION STRICTは、以前に教えていただいた時から、基本的に毎回使っています。 上に書いた怪現象は、正に自分の入力ミスが原因で、「ケーキの文字を変えようとしたら、何故か炎の１つが文字の位置に表示される」という状態になりました！ それは、変数に代入した数値がズレてしまったからで、その影響で別の変数の中身が変わってしまうという現象でした…。

なるほど〜。OPTION STRICTつけているなら単純なスペルミスでのバグなどは防げそうですね。 プログラムにバグは付きものですがたくさんのバグを経験することで、だんだんとバグに関する勘どころも強くなり、バグが少なくなったり、バグが出たときに原因を突き止めるのが早くなったりすると思うんで、それはそれで経験なんだろうなーって思います。 始めからバグの全く無いプログラムが書けたら理想ですが、そんな人はほとんど居ないでしょうしね〜。（一部の天才には居るのか？！） 今って、GOTO、GOSUBは多用している感じですか？　GOTOは出来るだけ通常のループ命令（WHILEやREPEATなど）、GOSUBはDEFに変えていくことでも多少はバグが出にくくなるとも思います。 という感じですが、これからも頑張ってください！

WHILEやREPEATは以前から使っていますが、そこから抜け出して移動するのに、GOTOを多用しています。 GOSUBも多用していますが、二重にできないはずなので、単純に一回で戻って終わりとならない場合は、GOTOでいろいろと移動してから戻るという感じです。 現在、少し困っているのがSPANIMで、アニメが終わるまで次の動きに移りたくない場合は、SPANIMの後にWAITでアニメ終了まで待たせるという方法で良いのでしょうか？ ちなみに、エサをあげて、「待て」を何度も繰り返すと、画像のように悲しみます…。

ループから出るのはBREAKをお薦めします。 無駄にラベルを多くすると プログラムが見にくくなりますから。

WHILEやREPEATから抜けるときはBREAKという命令があるのでGOTOはほとんど使わなくても大丈夫なはず。出来るだけGOTOは減らせるなら減らした方がいいですよ〜。 まあGOTOやGOSUBはBAISCの特徴でもあるので使わないまで極端に制限する必要はないと思っていますが、使わなくても大丈夫な場所に関しては上記のBREAKやDEFなどを利用したりして減らした方がいい感じです。 SPANIMを待つときはSPCHK命令を使った方がいいです。この時に単純にSPANIM開始したらSPCHKで終わるまでウエイトするという方法もありますし、逆にコマンドが実行されたとき（ボタンが押された時など）にSPCHKでアニメが終わってるかもチェックして終わってなければ処理をスキップするという方法もあります。 後者の方がプログラムを並列に動かせるので、慣れればやれることが増えるので便利ですね。

GOSUBの中でGOSUBは使えたような? »SPANIM 間に何も処理を入れないのであれば WAITで問題ないかと。

単純にループから抜けて次に進むだけの時はBREAKを使っています。 GOTOを使っているのは、離れた場所へ移動する場合のみです。

なるほど〜…。 基本的にGOTOで飛び回るのは設計的にはあまり良くない感じもあるんですよね…。まあでもケースバイケースなので使い方によっては問題ないパターンもありますが、それは見てないのでわからないし…。 とりあえずGOTOで飛んでまたすぐにGOTOで戻ってくるようなプログラムがあったらGOSUBにするとか、そんな感じですかねぇ…。

でんぺんさんへ SPANIMを待つときはSPCHK命令を使った方が良いということですが、SPCHKで終わるまでウエイトするという方法と、ボタンが押された時などにSPCHKでアニメが終わってるかをチェックして、終わってなければ処理をスキップするという方法が分からないので、実例を教えていただけませんか？ ST=SPCHK(変数) IF ST AND #CHKI THEN WAIT …という感じにすれば、アニメが終わるまで待ち続けるようになりますか？ なお、コマンド入力で処理をスキップするほうは、どういう形式にすれば良いか？思い付きません…orz。

例えばアニメーションが終わるまでウエイトなら REPEAT:VSYNC:UNTIL SPCHK(管理番号) AND #CHKI みたいな感じですね。ただループとかしていると終わることが無いので、そこは注意って感じです。 コマンドスキップの場合、例えば IF BUTTON(2)==#A && (SPCHK(0) AND #CHKI)==0 THEN 'Aボタンが押されて管理番号0のアニメーション中でないなら実行 ENDIF みたいな感じです。あくまで一例ですけどね…。

公式ガイドやムックを読み直してみましたが、そういう応用のプログラム例は載っていませんでした…。 マニュアル類を読んでも分かりませんでした…という投稿をしている人の多くが、私と同じ状態になっているのでしょうね…。 各命令の説明自体は分かっても、それを使って作る具体的な形式が分からないと、なかなかプログラムを作り出せないんですよね…。 でんぺんさんが一例と仰っているように、あくまで一例であって、他の方法もあるからなのかもしれませんが、初心者には一番簡単な形式を理解させるところから始めるのが良いと感じています。 そして、後から応用できるようになれば良いかと…。

そうですねぇ…。応用と言えば応用ですが命令の組み合わせという意味ではそれほど応用ではないというか、よーするにプログラムなんですよね…。 一例と書いたのは、プログラムには正解がないというか結果が求められればそれは全て正解とも言えるので、一つの例として出しました、という事でもあります。 残念ながら、あとは経験というか、色々とやっていくしかない部分もあります。どんな答えであっても、それを理解しようとする気持ちが大事です。 ある意味、僕のプログラム例は応用というよりは基本に近いです。とくに初心者が分からないように書こうとは思ってませんし、分からない部分はどんどん質問して欲しいと思っています。 そういう意味では、答えに対して「ありがとうございました！」と返事をする人が、ちゃんと理解して返事をしているのか気になる時はありますね。本当に分かっているなら良いんですが…

でんぺんさんの解説は分かりやすくて、いつも助かっています♪ SP関連の命令の基本は、でんぺんさんのおかげで理解できましたし、変数とSPCHRの使い方も質問を繰り返すことで何とか使えるようになりましたし…。 上のアニメが終わるまで待つ命令は、項目が多いアニメの場合は必要になる感じですが、今回のような短いアニメの場合は、WAIT アニメの合計時間分…としたほうが、少ない文字数で簡単にできますね。 今回のアニメでは、途中でスキップされては困るので、別の機会に使いたいと思います。（とりあえず、使い方は覚えておきます！）

アニメーションを実行中かどうかのチェックを行うプログラムをどのように記述するかを考えてみます。 SPANIMを使わず自前で1フレームごとにキャラを変えていく場合 メリット：任意のタイミングでアニメーションを終了可能 デメリット：自前ですべて制御しなくてはならない。（プログラムを書くのが大変、処理が遅くなる） 方法(1)：異なる管理番号のSPを表示する。 方法(2)：SPCHRでキャラの定義番号を変える。 方法(3)：SPDEFでキャラの定義をし直す。 自分で好きなものを選択すればOKです。 今回は「SPANIMを使う」ため(1)～(3)のプログラムについては省略します。

SPANIMを使ってアニメーションをさせる場合 メリット：あらかじめ指定した通りにアニメーションが可能。（速度面でも有利） デメリット：SPANIMの書式を覚える必要がある。アニメーションを途中で終了する方法はない。 SPANIMでアニメーションをするにはいくつかの方法があるけどアニメ対象は"I"を使用するのが最も簡単。 では、SPANIMでアニメ中の定義番号を取得する方法はあるか？→無い できるのはアニメーションをしている最中かどうかの取得だけ。 取得するにはSPCHKを使用すればいい。 SPANIMをヘルプで見るとのbit03がキャラ定義の番号となっている。 bit03というのは2進数だと1000となっている（bit00が1、bit01が10、bit02が100であるため）

これは10進数だと8、定数リテラルだと#CHKIとなっている。これは"CHK"にアニメ対象の"I"を合わせたもの。 以上より、アニメーション表示をしているスプライトの管理番号が0ならば SPCHK(0) AND #CHKI　がtrue（ここでは「1」ではなく「0以外の値」を示す）であればスプライトがアニメーションしているかどうかが分かる。 逆にいえば、この値が0ならばアニメーションは終了している。 しかし、SPANIMにおいてループ回数「0」で無限ループで設定しているとアニメは終了せずずっと続くため「0以外」を使用することになる。 もっとも素早く対応できるのはループ回数は1回のみの場合。

よって「アニメーションを1回分終了した時」をチェックするには以下の方法で可能となる。 @ANIMECHK WAIT IF (SPCHK(0) AND #CHKI)==0 THEN @ANIMECHK これは下記のように記述が可能。 REPEAT 　WAIT UNTIL SPCHK(0) AND #CHKI

でんぺんさんが書かれている「アニメーションが終わるまでウエイト」のプログラムを作る行程はこんな感じです。 毎回こんなにたくさん考えているのかというとそういうことはなく慣れてくるとここまで考えなくてもにあっさりできます。 ちなみにVSYNCとWAITは60fpsで動作しているプログラムならばほぼ同じ動作となります。（詳しくは私のプチコン3号入門講座を参照） VSYNCとWAITは入れなくても動作する場合がありますが、誤動作防止のためループ内ではできるだけ入れた方が良いです。

でんぺんさんも言われているようにプログラムには（特定の）正解はありません。 自分が想定しているように動けばどんなプログラムでも正解なのです。 したがって、自分が何をしたいのかを具体的に考えられるかが重要です。 命令を覚えた状態というのは英単語を覚えた状態、数学で公式を覚えた状態という感じです。 プログラムを作る場合は、その命令をどのように組み合わせるかが重要となります。 これはマニュアルを読むだけでは難しいので実際に自分でプログラムを作って動作させて確かめたり、他の人が作ったプログラムを読んだりするといった経験を積むことで自然に覚えることが可能となります。

返事を書こうと思ったら、おちゃめさんが詳しく書いてくれているので僕の方は割愛します〜。 ちょっと追加で、もしWAITと比べて、 REPEAT:VSYNC:UNTIL SPCHK(管理番号) AND #CHKI が長くて不便、という感じだった場合は、 DEF WTCHK N REPEAT:VSYNC:UNTIL SPCHK(N) AND #CHKI END のようなユーザー定義命令を作れば必要な時に、 WTCHK 0 と書けば良いだけになるので便利ですよ。 こういう事も含めて色々覚えていくと自分の力になるとも思うので、怖がらずに色々と試しながら自分のやり方をみつけていければいいなと思います。

おちゃめさんへ 凄く詳しい解説をありがとうございます♪ おかげで、どういう方法でアニメ終了待機命令が作られたのかが分かりました。 （以前に、おちゃめさんの講座を読み、理解できたこともあります。） でんぺんさんへ 繰り返し使う長い命令はユーザー定義命令にすれば良いということですね。

個人的にはプログラミングは実際に自分で作っていろいろ試すというのが良いと思います。 私も未だに試行錯誤の繰り返しです。 「車輪の再発明」と言われるかもしれないですが、自分の手によって考え出したものは自分の力になると思っています。 プチコンで作ったGRP2軸回転プログラムにしろ、ポリゴンプログラムにしろすべて「自分ならどうやって作るか」という点からスタートしています。 自分で考える前にネットで調べていたら作るのは楽だったかもしれないですが、自分の力としては身に付かなかったと思います。 ただし、ある程度の経験がないと「いくら考えても解決策は出てこない」ため初心者のうちはある程度考えて分からないならば「人に聞く」とか「自分で調べる」というのも良い方法だと思います。 自分で考えることなく最初から他人に丸投げだったら「上達を放棄している」と私はみなしてしまいますが。

以前に、SPANIMを少し研究した際には、まだ分からないことが多過ぎて、きちんと使い方を理解できていませんでしたが、今回学んだことにより、尻尾を横に振りながら、頭を上下に動かすアニメを表現できるようになりました♪ これで骨をかじっている感じが出せていると思えました。(この画像では動かないので、実感が得られないでしょうけど…。) 今作では、複数のアニメを同時に実行することが多いので、SPANIMをきちんと使えないとなりませんでした！

複雑な形の影を表現するのはまだ難し過ぎるので、今回は楕円形の影をつけるだけにしておきました！ SPLINKを初めて使ったため、最初は戸惑いましたけど、スーさんに教えていただいて、何とか使えるようになりました♪ これで影を表現できるようになったのは良いですが、以前に作ったキックターゲットやPKゲームにも影をつけたくなりました…。

難しいことに挑戦するのは良いですが、何も解決の足がかりがない場合は現状の自分にできることで妥協することも大切です。 しかし、影があるのと影がないのとでは雲泥の差です。 影があることで例えばこのカメラアングルでキャラを上にジャンプさせることが可能になります。 この単調な影というのはファミスタ等の見下ろし型2Dゲームで古くから落下位置を示すものとしても用いられているためです。

初期の作品からずっと妥協することで完成させてきたので、全ての作品がリニューアルを必要としています…。 今作ではジャンプシーンはありませんが、ボールにも影をつけたので、空中を飛んでいる感が出ていますね♪