サマーキャンプのArduinoでのコンソールのゲーム開発

昨年、私たちは夏のコンピューター学校でArduinoクラブを開催しました。 教師がそこに参加し、その結果、64x64画面の8ビットゲームコンソールが登場しました



ここで、このコンソール用に自分のゲームを作成できるサークルを作ることにしました。 そのミニマリズムのおかげで、コードはほとんどないはずです。 合計で、シフト中にサークルに約14時間が計画されたため、このようなゲームのプログラミングに入るための低いしきい値は重要な機能でした。





4095個のLEDおよびすべてすべてすべて



ゲーム作成API



鉄は1つしかなかったので、最初にエミュレータを作成する必要がありました。 結局のところ、いくつかのチームがゲームに取り組みます。 さらに、ソースコードはすべて1つの* .inoファイルに含まれていたため、新しいゲームの追加が動作とレンダリングをプログラミングすることになったように、それを断片に分割する必要がありました。 実稼働マシンの構成を簡素化するために、Arduino IDEを使用してビルド環境を終了しました。



画面に画像を表示するために、プロセッサは常に画像をスキャンし、ピクセルカラーをシフトレジスタにロードします。 したがって、画面を更新するための正しい手順では、1行のピクセルのみを指定する必要があります。 しかし、このようなインターフェースは不便すぎるため、game_draw_sprite、game_draw_textなどの一連の関数を作成し、すでに内部でどの行を出力するか(および実行するかどうか)をチェックしています。 このため、すべての呼び出しは必要な行だけでなく各行に対して行われるため、オーバーヘッドが発生します。







エミュレータは同じ機能を提供しますが、フレームバッファにすべてを描画し、コンソールよりもはるかに高速に動作します。 したがって、ハードウェアで何が起こるかを常に評価できるとは限りません。 ただし、Visual Studio(またはgdb)を起動してプログラムの動作を確認できるため、デバッグに関する問題のほとんどを解決します。 ここにあるすべてのスクリーンショットは、このエミュレータのものです。



開発者は、ゲームを作成するために、画面のレンダリングと内部状態の更新という2つの機能を実装する必要があります。 更新は所定の頻度で発生します。 描画関数は、画面の各行に対して呼び出されます(実際には、アドレス指定の詳細のため、一度に4行のグループに対して)。



更新機能は、ジョイスティックで押されたキーに応答して、ゲームの内部データを変更します(たとえば、オブジェクトを移動するための座標)。 一度に実行されるゲームは1つだけなので、それぞれで静的変数を宣言することは意味がありません。 結局、2キロバイトのメモリがあります。 したがって、メモリの操作は少し不便です。すべてのゲームデータは、ポインタを介してアクセスする必要がある構造に格納されます。



APIの機能、およびゲームを選択するためのメニューをテストするために、ゲーム「Snake」を実装しました。 彼らは急いでそれをやったので、いくつかのバグが残った。 その後、子どもたちは喜んでそれらを発見しました。







共同開発



まず、プロジェクトをgithubからgitlabのある内部サーバーに配置しました。 連中はこのリポジトリのフォークで作業し、その後プルリクエストを送信してすべてをまとめました。 一般に、すべてがうまくいきましたが、gitの原則を深く説明することはしませんでした。



プロジェクト参加者は多すぎませんでした。 最初は4チームが発表されましたが、最後に到達したのは2チームのみで、彼らはアルゴリズムの研究を始めたばかりのグループのメンバーでした。



掃海艇



最初のチームは、古典的なサッパーを作ることにしました。 鉱山は非常に巧妙に配置されていました(1列に1つ)。1〜3の数字のスプライトだけが必要でした。プログラムは475行で構成されていますが、テンプレートからゴミとコメントが残っています。 プルリクエストのコードでエラーを見つける時間はありませんでした。







サッパーの実装における最大の困難は、ユーザーがクリックした無料のセルに隣接するすべての無料のセルを開くことです。 広く歩くことは説明するのに長い時間でした。 そして、彼は順番に記憶を取ります。 したがって、連中はアレイを数回スキャンし、隣接するセルと開いているセルを開きました。 これはまれな操作であるため、すべて正常に機能しました。



それでも、ディスプレイには問題がありました。フィールド全体を描画しようとするたびに、フィールドが遅くなりすぎて、画面がちらつき始めます。 私は小さな松葉杖を作らなければなりませんでした-スプライトが表示された行に収まらない場合、スプライトから行全体をスキップできる機能です。 さらに、プロセッサをATmega2560にアップグレードして、フレームバッファに十分なメモリがあるようにする予定です。 その後、そのようなゲームのちらつきの問題はすべてなくなります。



ブレイクアウト



このゲームはブレイクアウトと呼ばれます。最初はみんながやりたかったからです。 しかし、彼らはすべてが複雑であると判断し、ポンを得た。 ゲームにはいくつかのモードがあります-二人用ゲーム、コンピューターを使ったゲーム、デモンストレーション(自分とコンピューターを対戦する)。 確かに、コンピューターは負け方を知らない-常にボールを打つことができます。 彼らはもっとcなアルゴリズムを考え出す時間を持っていませんでした。 ゲームの合計ファイルは272行かかります。







ゆるい潜水艦



子どもたちと並行して、スプライトとコントロールの操作方法を示すために「ゆるい潜水艦」を作りました。







これらのゲームはすべて、32キロバイトのプログラムメモリを獲得するのに十分でした。 しかし、ATmega2560にアップグレードした後、256キロバイトのメモリがあるので、来年はすでに作成されたゲームを投げることなくこのサークルを繰り返す予定です。



githubのプロジェクトのソース



All Articles