いい加減何か1本でもゲームを完成させよう、と思っているのですが、ひとりでは到底完成させることはできそうにありません。 このトピックでご協力いただける人を募集したり、ここに進捗を書きこむことで完成に繋げて行きたいと思います。 おそらくなめくじの歩みくらいの速度で進みます。

【ゲームの内容】 ・3DSの下画面にひと筆書きができる図形が表示されます。（お手本） ・お手本を記憶して、記憶を元にその図形を描きます。 ・描いたものがお手本に近いほど高得点 これを3セットCPUと対戦するゲームです。 動作サンプル…というかイメージ的なプログラムを作りました。ゲームとしては動作しません。 公開キー:R27N23CJ

現在図形の判定システムはMIKIさんに作っていただいてます。 （完成したらおそらくテストプレイをお願いすると思います） ので、とりあえずそれ以外のところでできることを進めていこうかな、と思います。 プログラムはもとより、数学もわかりませんが、それでも協力してやるよ！って人がいたら嬉しいです。 こめのこ歓迎、クソリプ冷遇の方向。 以下にネタバレでゲームの設定的なものを入れておきます。

(期待作なので、コメント残しておきますね)

主人公（プレイヤー）はどこにでもいるけんだま少年。 ある日幼なじみと一緒に、店舗公認（?）けんだま大会に出場することに。 この大会に勝ち抜いて、去年の優勝者と対戦し、チャンピオンを目指せ！ と、いうありがちなストーリーです。 けんだまの技を｢芸術点｣として競いあうので、CPUと同じ図形を描くのではなく、得意な技（図形）を出すタイミングを選び、相手より高得点を狙う、のが目的です。 この辺のバランス調整とかすごく難しそうなんですが、そういうのは動くものができてから考えます！！！！ キャラとか技とかも完全に決定している訳ではないのでその辺からぼちぼち…。

こめのこ共感ありがとうございます！ 一応進捗がなくても書きこんで行こうと思います。放棄してません的な意味で。 サンプルのプログラムは200×200の四角の中に15px程度の直線を引いていますが、これをまず正確な位置に引けるのかどうか知りたいです。 図形を覚えるだけならそんなに難しくないと思うんですが、絶対的な位置を覚えるのは難しいような気がして。 今のところこれを元に左右にキャラクターのイラスト、四角（フィールド）はもう少し上にあげて、その下にスコアなどを入れる配置が良いかな、と思ってます。

評価関数組み込みました。 file=mc_kndm2.prg key=R58X58KE 348行目の k を大きくすると判定が辛めに、小さくすると甘めになります。 お手本軌道は 89 行目で読みます。"@DATA2" てのが読み込むラベルです。 ユーザー入力は 112行目 判定は 132行目です 分からないことがあったらなんでも聞いてください。

MIKIさん ありがとうございます、お疲れ様です。 ユーザー入力と判定は、サンプルにあった見た目だけの命令を実際動く関数（自作命令）に置き換えている、って感じですよね？ 89行目の@DATA2を他のラベルに書きかえるとどのデータでも読み込むことができる、で、OKですよね。 348行目はいくつか数字を入れ替えてみましたが、確かに数字が大きい方が厳しい…？くらいの違いしかわからなかったので、なにかもう少し距離のとれそうなもので試してみます。 まず図形データを作らないとですが…。 いくつか作ってテストプレイしてもらえる形に持って行きたいですー。

全部合ってます。 データの作り方ですが、現在は画面の座標そのまんまになってますよね。 これだと将来に禍根を残すと思うので、画面中心(160,120)を中心とした方が楽ちんです。 例えばエクセルなんかで円の軌道作る時、中心座標が (0,0) の方が作りやすいでしょう? 現在の @data3 は(160,120)から開始してますが、これを(-160,-120)して data -15,0,0 と書きましょうってことです。 spanime 使うのは難しくなるので、85行目のループで read a,x,y: spofs 0,ox%+x,oy%+y と指定することになります。 79行目の gpset は gpset ox%+x, oy%+y,rgb(..) みたいにします。

なお判定処理では全部画面中心を原点とする座標系になってます。 ので、data 文を画面中心座標系にした場合、 course 命令の 339,340 行目を push x,b push y,c と修正してください。(-ox% と -oy% を消す)

とりあえず作っていただいたサンプルに組み込むDATAを…書きだすプログラムを用意したというか、いろいろな方に手伝ってもらって作りました。 それからちょっと自分でやってみたんですが、これ図形の形考えないと、難しいというより無理ゲーになってしまう可能性…。 絶対的な位置を覚えるのに200×200の四角は広すぎ、というのは間違いない…。 ちょこちょこ修正しつつ、MIKIさんの書きこんでくださった座標を中心座標に持っていく作業に移ります。 今日中というか夕方くらいまでにもうちょっとゲームに見えるようなの出したいと思います。

位置を覚えやすくしたりするために、 ・入力範囲にグリッドを表示する ・内部的な解像度を下げる というのはどうでしょうか

クッキーさん グリッドはいい感じかもしれないですね。 内部的な解像度を下げるというのは…？ 今200×200の枠なんですが、データとしては100×100とかで、拡大表示にするっていう解釈で合ってます…？？ とりあえず枠は160×160に縮めてみました。多分これくらいならなんとか覚えられそうな気はします。 あと図形は直線の方が曲線より覚えやすい？個人差？？ 早くテストしてもらえるようにしなくては…。

＞拡大表示 はい、そんなイメージです。 入力エリアの大きさはそのままで引伸ばす感じです。

とりあえずテストプレイしてもらえそうな感じのものができました！ 公開キー【5E837W4E】 最初に技を選べるような表示になってますが選べません。Aボタンを押すと進みます。 本当はキャラのグラフィックも配置してみようと思いましたが時間切れでした。仮のものですが描いたものは同梱してあります。 キャラは四角を挟んで左右に、ゲージとスコアは四角の下に配置予定です。 まだイメージの段階から出てない気もしますが、伝われば嬉しいです。

MIKIさん と、いう訳で書いていただいた点は修正してみました。これで合ってます…よね？ 中心から座標を作っておくと、四角を移動させた場合でも、四角の中心と座標の中心が一致するのでデータの作り直しが必要なくなる（ので調整が楽）という事ですよね？ ox%とoy%を四角の中心座標に書き換えれば良いのでしょうか。 クッキーさん 了解ですー…と言っても多分そこはMIKIさんに作っていただいた部分なので自分ではどうしようもないかもです。 今回適当に描いたこの図形でも記憶するのが難しいという反応が多かったらまた何か…ってところでしょうか。 と、いうわけで、適当に作った画像がひとつ入っているだけですが、プレイしていただければと！ 実際のスコアより、体感的なものが知りたいかな…？

合ってます! ただ一点だけ、@data2 には座標のデータ数が必要なのでした。 多分 spanime の仕様なのでしょう(使ったことないからよくわからない) なのでお手本として 15 点しか読まないのでおかしな判定になってたようです。 file=KNDM_IMG03A.PR KEY=TSNNX3JJ データ数を読む代わりに、座標の終わりマークとして data 1e9,1e9 を書くようにしました。ホントは NaN がいいんだけど、NaN 書けないので。 data も x,y だけにしました。 データ数が多い場合、比較のために前後見る幅をデータ数に比例して多くするようにしました。

> 移動させた場合でも、四角の中心と座標の中心が一致するのでデータの作り直しが必要なくなる その通りです!! 拡大・縮小するのも座標を c 倍するだけで済むのです。 得点 = 100 - 誤差*K という計算で 誤差 = 手本の座標とタッチ座標の距離(の平均値的な値) [ドット単位] になってます。 のでクッキーさんの解像度下げる案は、評価関数で K をいじるのと同じことになります。 解像度半分⇔K=0.5 解像度二倍⇔K=2.0 体感的なものでいうと、何度もやっているとお手本の動作待ちがイライラします。 Rボタンでスキップするようにしてしまいました。 (スキップよりは高速化がいいのでしょうね)

上画面の妙なにょろにょろですが上から 水色: x座標の差 (ドット単位、ずらしたの含め 5 本)プラスマイナスあり 黄色: y座標の差 (同上) 白: 距離 (同上) プラスのみ 緑: 距離の最小値 (白グラフの一番下側に等しい) 緑の平均値的な値(RMS)を「誤差」として 得点=100-誤差*k とします。 サンプルだと最後の直線が速いのでニョロニョロの最後の方、差が大きくなると思います。 けど、ずらして評価した最小値を選択することで、速度差を吸収できるのがわかると思います。

MIKIさん プログラムの改良ありがとうございますー。 調べたらspanimはデータを32セットまでしか読まないとなってて、実際エラーがでてどうしようかと思っていたので、対応してもらえて助かりました。 ループはこういう使い方もできるんですね。データの数数えなくていいし、スマートな感じです。 NaNというのは何でしょう…？？ 確かに何度も同じお手本見せられるのはあまり良くないなーと思うので、やはり図形を何種類か選べるという選択は良かったかもしれないです。実装されてませんけど！ 前にカーソルで選択するメニュー作ったので多分なんとかなるとは思います。 そして飛ばすのよりは高速化の方がいいと自分も思います。 ゲームにするならボタン操作とか、そういうのもだんだんと考えて行かないとダメですね。

上画面のニョロニョロは… この波打ち具合が大きいほど座標のズレがおおきくて、直線に近いほど点数が高いって見方でしょうか？ 確かに何度かやっても緑のグラフは後ろの方が前よりニョロっとする感じです。 ずらして評価した最小値というのがわかりにくいんですが（すいません）ゲームの判定としてはこれで救済入れてますって意味でしょうか。 最後の方速いのは座標のデータの飛びがあるので速く動いてしまってるので、飛びのないデータを作らないとです(-ω-；) 今回やった感じだと、それなりに元の形に近くなぞった時と、故意に何もないところをなぞった時の点数差が前より大きくなっているので、判定は前よりイメージに近いです。 評価関数=解像度っていうのは｢へー｣って思いました。（もはや日本語も怪しい） 数学的？な事は全くわからないので、説明を聞いてなんとなーく理解するだけですが…。

ゲームとして今考えてること ストーリーモードっていうか対戦モード でもこれは同じ図形を書く訳ではないので今のレイアウトのままだとCPUがなにを書いているのかわからない問題。 3DSなので上画面に表示できるけど、しないとGB時代の相手の様子が見えない対戦モードのパズル的なのを感じてしまう…。 練習モード キャラごとに最低3つの図形（技）を設定する予定なので、ストーリーモードで勝ったキャラのところまではその図形を使って記憶ゲームができる。脳トレ的な。 クリアできたらCGがおまけで見られるとか？？ …にするとCGの需要があるようなキャラを作らないとダメなのでは？？ エディットモードモード 任意の図形のデータを読み書きできる。他人のものと交換可能。そんなに遊んでくれる人がいるか不明だけど！ でも特に変わったシステムでもないかなとは。

NaN は Not a Number (数でない) を意味する特別な値です。 よく「0 (とか -1) を入力したら終了します」みたいなのあるじゃないですか。 でも 0 も -1 も 99 も -9999 も、およそあらゆる数を扱いたいって時に、特別な値として使える便利な数です。 普通のプログラミング言語だと 0.0/0.0 や √(-1) log(-1) などが NaN になります。 プチコンの場合、例えば ? pow(2,1024)-pow(2,1024) が NaN になります。定数で書けないので data 文に入れることはできません。 高速化は後で wait2 命令書き直します。

バグがありました。 514行目 K0%=-DK%*2 を k0%=-Dk%*(M% DIV 2) 同じく 514行目 R[K%,N%] を R[M%,N%] に直してください。 あと 503行目の 5-DX も 50-DX が正しいです。 ニョロニョロは 0 ラインがないので分かりにくいですが、0 から遠いほどずれてるってことです。 ずらして評価は、以前書いた「軌道の見た目が完全一致してるのに(時間軸が合ってないせいで)減点されてしまう」という納得いかない感の救済目的です。 同時刻の手本座標だけでなく、前後 2 点ずつの手本座標と比較し、一番近いのを採用します。 ただし手本の座標数が多いと、ちょっとだけずらしても意味無いので、データ全体の 10% と 5% 分前後の座標と比較するようにしました。 514行目 M%=5 を M%=1 にすると救済なしになるので試してください。

うう、長らくレスしてなくてすいません…。 やはり全く進捗なしだったり何もできない日でもできないとか書いておいたほうが親切ですね、すいません…。 そしてネタでなく進捗が何もない…('∀`)

MIKIさん NaNの解説ありがとうございます。 そういう特別な数値っていうのが存在するんですね。確かにあったほうが便利というか、たくさんデータを扱うならないと困るようなものなのだろうなあ、と。 プチコンにもそんな特別な数はあるんですね。プログラムわからないのでdataに入れないとなるとまた使いドコロは自分には不明ですが…。

バグの場所は直しておきました。動いたので多分間違ってはないと思います（不安）。 たしかにニョロニョロに基本になるような線はなかったですね。上下の振れ幅が大きいほど、みたいな感じ…？？ 救済は時間軸の方の救済なんですね。試しに数字を入れ替えてみましたが、だいたい同じような形を描いてもわざとゆっくり描いた時のほうが確かに点数が低い感じがしました。 （まったく同じ形を描けてる訳でないので体感ですけど…） お手本の高速化もしていただけるということでありがたいのですが、もしこちらのレスがあまりにもゆっくりになるようでしたら、優先度は下げていってください、本当にすみません…！

今週は多分ヒマ（だと思う）のでせめて画像的な面だけでも進めたい…。 ちょっと発熱他が続いてて、そのせいでヒマはしてるんだけども頭を使うこと（=プログラム）はとてもじゃないけどって状態なのです。 だらだらネットとかはしてるんですけど…。 プログラムじゃなくてお絵かきツールで画面の構成何パターンか描いてみようかなあ。というか、それとタブレットのお絵かきでキャラのデザイン詰めるくらいしかやれないような('∀`) 人間身体が資本ですぞ…！！

やまなさんのペースでやればいいと思います。 ここに書くことが負担になると楽しくないし、長続きもしません。 私はすれ違い第 3 段にハマってて(第1段や第2段もクリアしてないのに) すれ違いを求めてあちこち出歩いてます。 体は重要ですね。つくづくそう思います!!

file=KNDM_IMG03A.PR KEY=DBK35W8E R で高速移動します。 評価ニョロニョロのX軸(y=0の線)書くようにしました。 小数対応の waitf はけっこう使い勝手がいいかもしれません。

MIKIさん ありがとうございます。 のんびり？自分のペースでやりたいと思います。 完成させることが大事ですし！ 書きこむことは負担ではないのですが、ミーバースはかなり公共の場所というイメージなので少し緊張します＞＜ あとは体が悪いアピールしまくってるので、書きこんで無事を知らせておかないとという感じです(-ω-；) 最近はミバ以外にあまり活動もしてないので（といっても誘導したら怒られますけど）。 すれちがいの新しいのでましたね！1本もらえるの…もらってDLしてる最中に寝てしまったような。か、確認しておこう…。

高速化ありがとうございます、DLしました。 線を引くときかなり短いフレームなのにこれが速くなるんだなあ、とぼんやり思ってましたが、小数にしてしまうんですね。 前から何度もどうするんだろう…？て思ったところを改善してもらってるので、数学の知識があればプログラムってなんでもできるんだなーって思ってます。 グラフも基準になる線があると一気に見やすくなりました、というか、ズレ具合が実感できました。やはり後ろの方がズレが大きいですね。

このトピックは想像より早く流れてしまったので、少し図形を足して一度プレイ日記でテストプレイを募ってみようかなあと思います。 まずそれを目標にしよう。 実は最初のカーソルを動かさなくてはいけないところで大きな勘違いをしてるようなので、動くメニューを正確に作るところから…！

うーん、すいませんけどしばらく作業をお休みしようと思います。 正確には休むわけではなくて、当分見えるところに自分が作ったものを置きたくない、という感じです。 楽しく作業できなければ意味ないですし。 もちろん完成させるまでやるトピックなのでトピックは閉じませんし、完成させる気もあります(｀･ω･´)ゞ 質問するトピックにものを出さないということはサポートも望めないのでさらに遅くなりそうですが。 まあBIGがでてwiiコン対応にしたらけん玉感もっと出るかも？とか思うとそういうのは楽しみです。

ただMIKIさんにこれだけしていただいたのに申し訳ないとそれだけが心残り…って完成させますけど！！ものすごく失礼だなあと。 本当にすいません。しばらくひっこませていただきます。 何かミーバース以外の場所で公開できれば良いんですけど…。 ミーバースはみんな優しいから作品を公開するということは、それを否定されることもあるということ忘れてしまってた！！うっかりだ。 ミーバースやめるわけでもプチコンやめるわけでもないので、みんなの作ったゲームはどんどんあそぶゾ〜！！

やまなさん、了解です。 提案ですが、一度このトピ閉じた方がいいのではないですか? 当初は完成させる事を目標に据えていましたが、計画が変更されることはよくあることで、IT業界では日常茶飯事です。 やまなさんとしては自分の言葉に責任を感じることと想像します。が、そもそもソフトウェア作成が予定通りいくなんてことはまずめったにないことです。 やまなさんがこの点に負い目を感じる必要は 1mm ほどもありません。 このトピが残り続けることがミバ活動の心理的負担になるようではそれこそ本末転倒です。

> 楽しく作業できなければ意味ないですし ほんとにその通りです。別に仕事でやってるわけじゃないですから。 私の事は気になさいませんよう。 私はたくさんのフリーソフトを愛用していて、その作者達に巨大な恩を受けています。 プチコンコミュで質問に答えるのは、実はその恩返しの一環なんですね。 もちろん寄付といった直接的な報恩もしていますが、そんなことより、未来のプログラマの手伝いをする方がよほど恩返しになっていると信じているところです。

プログラムはたくさん書けば上達も早いのです。 一つの作品を作ると、学習曲線はS字カーブで向上します。 てことは、同じ作品に関り続けても、上達は頭打ちになってしまうということです。 ある程度で見切りを付けて、新たな製作に向かった方がまたS字で向上できるので、ぐんとスキルアップできます。 そうやってスキルをつけたら、いずれまたこの作品に戻ってくればいいのです。 そんな感じで、よろしくお願いします。 あと私が公開してたやまなさん向けの公開キーは削除しました。

MIKIさん いろいろお気づかいありがとうございます。 トピックが負担になってる…ことはあんまりない…と思いますけど、続けないなら閉めることも検討します。 確かいつまでも同じプログラムやっていても上達しない、次やった方がいい、というのは以前もこのコミュでもどなたかに言われた記憶。 システムの基本は作っていただいたし、もう少しゲームとしての何かを（表にでなくても）考えたりして過ごすのもいいかもです。

教えていただいた側としては教えていただいたことを形にして出すのが恩返し（？）かなと思うので、何かしら形にしたい気持ちはあります。 たまたま今はその時じゃなかったんだと思うことにします、ありがとうございました！ MIKIさんがいろいろこちらに理解できる範囲で手を加えてくださった部分だけでも、こんな使い方がー！と目から鱗でした。これを覚えて活かす方に向けたいと思います！