APG4bとSiv3Dを利用して勉強会を開催した

はじめに

今年度,サークル内で,APG4bとSiv3Dを利用して2つのプログラミング勉強会をオンラインで開催しました. APG4bは,AtCoderC++学習用の資料です.

atcoder.jp

Siv3Dは,可視化やインタラクションに関わるプログラムを作成するためのフレームワークです.

siv3d.github.io

本記事では,開催したプログラミング勉強会について,それぞれその目的や内容などについてまとめます. その上で,APG4bとSiv3Dを利用して良かったと感じたことや勉強会の反省などについてそれぞれまとめます.

本記事はSiv3D Advent Calendar 2021の12月19日の記事です.

qiita.com

APG4bを利用したプログラミング勉強会

APG4bを利用して以下のようにプログラミング勉強会を開催しました.

目的

この勉強会の目的は以下の3つでした.

  • 参加者にプログラミングの楽しさを知ってもらうこと
  • 参加者にプログラミングに興味を持つ人と交流してもらうこと
  • 参加者にプログラミングの基礎知識を身につけてもらうこと

期間

2021年5月12日から2021年7月2日まで間,毎週1回1.5時間程度の勉強会を開催しました.

対象者

この勉強会の対象者は,私の所属サークル内で,初心者を含む全ての部員でした.

講師陣

この勉強会には,私を含めて8名が講師として参加しました. それぞれの講師は,最大で2回の勉強会を担当し,司会と解説を行いました.

内容

内容
1回目 1.00.はじめに,1.01.出力とコメント,1.02.プログラムの書き方とエラー,1.03.四則演算と優先順位
2回目 1.04.変数と型,1.05.プログラムの実行順序と入力
3回目 1.06.if文・比較演算子・論理演算子,1.07.条件式の結果とbool型,1.08.変数のスコープ
4回目 1.09.複合代入演算子,1.10.while文,1.11.for文・break・continue
5回目 1.12.文字列と文字,演習
6回目 1.13.配列,演習
7回目 1.14.STLの関数,1.15.関数
8回目 2.01.ループの書き方と範囲for文,2.02.多重ループ,2.03.多次元配列
9回目 2.05.再帰関数
10回目 3.04.構造体
11回目 3.05.ビット演算

APG4bを利用することにした理由

資料がそれ自体で完結している

自分で資料を探して調べながらプログラミングを勉強することは,プログラミングに初めて触れる初心者の多くにとっては難しいことだと考えています. 実際,私も最初は一通りのC言語を先輩から教えてもらうことでプログラミングを勉強しました.

APG4bは,資料がそれ自体で完結しており,後ろで述べるようなプログラミングの基本知識がこの資料だけで学べるようになっていると思いました. ここには,演習問題も含まれており,このおかげで,講師達がオリジナルの資料や演習問題を用意する手間を省くことができると考えました.

また,資料がそれ自体で完結していることにより,参加者が講師の解説を聞かないで自分のペースで進めることも可能となっていると思いました.

プログラミングの基本知識が網羅されている

私は,型,配列,構造体,変数,四則演算,繰り返し,条件分岐,関数のように多くのプログラミング言語で共通して存在するような概念をプログラミングの基本知識だと考えています. APG4bはこれらの基本知識を網羅しており,プログラミングに初めて触れる人が,自分で調べて勉強できるようになるために必要なキーワードを把握できるものとなっていると思いました.

Web上に実行環境が用意されている

プログラミングに初めて触れる人にとって実行環境を構築することは簡単なことではなく,ここで挫折してしまうのは悲しいと思います. APG4bには,コードを書いてプログラムを実行できるコードテスト機能が備わっており,環境構築に手間をかけなくてもプログラミングの勉強を始められるようになっていると考えました.

ここで勉強したC++をSiv3Dによる開発に応用できる

APG4bで学べるC++は,Siv3Dを使った開発にそのまま生かすことができ,相性が良いと考えました.

その他工夫したこと

この勉強会では,APG4bを利用して準備の手間を省いたことの他にも,交流の時間を設けるという工夫をしました. 交流の時間とは,勉強会の後に,AmongUs,麻雀といったゲームで遊んだり勉強会の復習をしたりする時間です. これを設けることによって部員同士が仲良くなれば,部員の幽霊化を抑えることができると考えました.

振り返り

APG4bの資料をそのまま使ったため,準備に手間をかけずにプログラミング勉強会を開催できたと思います. また,元の資料がそれ自体で完結しているため,講師の力量や相性によらず,最低限の質は保たれていたと思います.

交流の時間を設けたことで,部員の幽霊化を抑えることができたと考えています. 昨年度,似たような形式で勉強会を開催したときは,最初10人程度いた参加者が最後には2人まで減ってしまいました. 交流の時間を設けるというアイデアは,ここでのの反省の結果として生まれたものでした. 実際,今年度の参加者は,最初20人くらいで最後は15人くらいだったと記憶していますが,昨年度ほど大きく参加者が減ることは無かったのは,交流の時間を設けた効果が少なからずあっただろうと考えています.

また,AtCoderのコンテンツを利用した勉強会だったため,そのままAtCoderのコンテストに参加する部員も多く,競技プログラミング勢が増えました.

改善すべき点として,参加者の理解度をもっと把握できるようにすることが挙げられると考えています. AtCoderの提出一覧から提出されたコードを確認できるため,これを利用すれば参加者ごとにアドバイスをしたり,参加者がどこで躓いているか把握することができたと思います. そのために,可能なら事前にユーザ名を教えてもらったり,解けない場合にも提出してもらうように言っておけば良かったと考えています.

Siv3Dを利用したゲーム開発勉強会

OpenSiv3D v0.4.3の資料を利用してゲーム開発勉強会を以下のように開催しました.

目的

この勉強会の目的は,参加者に,ゲーム開発など,AtCoder以外のプログラミングにも興味を持ってもらうことでした.

期間

2021年8月27日から2021年8月30日まで間,毎日午前中に2時間,午後に2時間の勉強会を開催しました.

対象者

この勉強会の対象者は,私の所属サークル内で,ゲーム開発などグラフィカルなアプリの開発に興味がある部員でした.

講師陣

この勉強会には,私を含めて3名が講師として参加しました.

内容

内容
1日目午前 構造体と関数についての復習
1日目午後 Visual Studioの使い方,追加の演習問題
2日目午前 Siv3Dのインストール,1. Siv3D の基本
2日目午後 2. 図形を描く(2.1 円を描く,2.2 色を付ける,2.3 背景の色を変える,2.4 長方形を描く,2.5 枠を描く)
3日目午前 3. 動きを作る(3.1 経過時間を使ったアニメーション(Scene::Time(),Scene::Center(),Scene::DeltaTime()),3.2 ストップウォッチ)
3日目午後 4. あたり判定
4日目午前 5. 画像を描く(5.1 絵文字を描画する,5.5 アイコンを描画する,5.6 画像ファイルを読み込んで描画する)
4日目午後 8. フォントを使う(8.1 Font,8.8 フォントのスタイルを変える,8.13 縦書きでテキストを描画する,8.14 指定した長方形の中にテキストを描く,8.15 テキストを 1 文字ずつ表示する)

Siv3Dを利用することにした理由

日本語の公式資料が充実している

Siv3Dの公式資料では,環境構築からライブラリの使い方までが日本語で示されています. 以前にDXライブラリというものを使用した時には,新しいプロジェクトを作成した後に必要な設定の手順が多くて大変だった思い出があります. これに対して,Siv3Dでは環境構築自体もVisual Studioのインストールと,Siv3Dのインストーラを起動することだけで難易度が低めだと感じています. また,Siv3Dの公式資料は,単なるリファレンスではなく,機能の解説がコピペで動作確認できる短いサンプルコードとともに示されており,動かしたり改造しながら勉強できると思いました.

APG4bで勉強したC++を使用できる

Siv3Dを利用すると,APG4bで勉強したC++によるプログラミングの延長として,アプリケーション開発を行えると考えています. そういう点でSiv3DはAPG4bと相性が良いと思いました. これに対し,例えばUnityでは,エディタとフレームワークを利用する中の一部にプログラミングがあるという感じがしますし,また,使用できるプログラミング言語C++ではなくC#です.

その他工夫したこと

この勉強会では,Siv3Dを利用して準備の手間を省いたことの他にも,以下の工夫をしました.

  • 構造体の復習を設けた.
  • 独自のSiv3D演習問題を設けた.
構造体の復習

Siv3Dはクラスベースのフレームワークであるため,構造体への理解が重要であると考えました. そこで,APG4bで学んだ構造体を復習する時間を最初に設けました. 具体的には,APG4bの3.04構造体のキーポイント,細かい話(コンストラクタ)について解説し,演習として,EX24 - 時計の実装に取り組みました.

また,独自の演習問題として以下を解きました.

  • 構造体に関する追加の演習問題

構造体の練習として、和とスカラー倍の定義されたベクトル表す構造体を実装してみましょう。 以下のプログラムの雛形のコメントに従って構造体を実装してください。 github.com

この演習問題は,Visual Studioの使い方に慣れるためにも,APG4bのコードテストではなく以下を参考にしてVisual Studioで解くこととしました.

www.fenet.jp

独自のSiv3D演習問題

2日目以降は,Siv3Dの演習問題を以下のように準備しました.

演習問題
2日目午前 Siv3Dのサンプルを5個選びそれぞれコピペして実行してみる.
2日目午後 5種類の図形を別の色で描画してみる.
3日目午前 マウスカーソルがウィンドウの左側にある間は円を左に動かし,右側にある間は円を右に等速度で動かしてみる.
3日目午後 クリックした円を分裂させる(元の円を消し,少しずらした位置に二つの円を描画する.).
4日目午前 アイコン,画像を拡大縮小,回転させてみる(5.2 テクスチャを拡大縮小して描画する,5.3 テクスチャを回転して描画するを参考にする.).
4日目午後 3人のキャラクタを表示し,クリックされたキャラクタに何か喋らせる.

難易度としては,サンプルコードを組み合わせたり,少し改造することで解けるものを設定しました. 解答例は以下のリポジトリにあります.

github.com

振り返り

Siv3D(Open Siv3D v0.4.3)の資料をそのまま利用したため,演習問題以外の多くの準備の手間を省くことができたと考えています. また,少なくともゲーム開発勉強会を通して,参加者が今後アプリケーションなどを作りたいと思った時にSiv3Dのことを思い出してもらえるようになったかなと思っています.

しかしながら,改善すべき点として,勉強会中に参加者が演習問題をどの程度解けているのか把握できなかったことが挙げられると考えています. 実際,サンプルコードの実行ができていない参加者が何人かいたようだったのですが,勉強会中には把握できませんでした. 勉強会はオンラインで開催されたため,参加者から声がかからない限り講師が参加者の様子を把握することはできません. これに対する解決案として,勉強会中に参加者が質問をしたりヘルプを求めたりしやすいようにするために,演習ではグループに分かれてそれぞれのグループに講師がつくことなどが挙げられるのかなと考えました.

APG4bを利用したC++勉強会で触れることのできなかったC++文法がSiv3Dのサンプルで使用されていることも多いので,これに対するフォローをもっと手厚くするべきだったと思いました.

また,この勉強会は夏休み中に集中して開催されたのですが,せっかくなら合宿らしく,夜にはオンラインでできるゲームをして盛り上がればもっと楽しくなったかもしれないと思いました.

勉強会を開催する中で,私と他の講師の一人がそれぞれ資料中に誤植を発見し,これを修正するプルリクエストを送ってマージされるということもありました.

MacBook Air (M1, 2020)で環境を構築するためには,以下の記事を参考に設定を修正する必要がありました.

qiita.com

まとめ

  • 今年度,サークル内で,以下のプログラミング勉強会を開催した.
    • APG4bを利用したプログラミング勉強会
    • Siv3Dを利用したゲーム開発勉強会
  • 勉強会の資料としてAPG4bやSiv3Dを利用することには,以下のような多くのメリットがあった.
    • 資料が網羅的であり,それ自体で内容が完結している.
    • 資料をそのまま利用することで講師陣の負担を減らすことができる.
    • 環境構築の難易度が高くない.
    • APG4bやSiv3Dの相性が良い.
  • これらのコンテンツを活用するために以下の工夫をした.
    • APG4bを利用したプログラミング勉強会では,交流の時間を設けた.
    • Siv3Dを利用したゲーム開発勉強会では,構造体の復習の時間と独自の演習問題を設けた.
  • 個人的に反省した結果,これらのコンテンツをオンライン勉強会で最大限活用するための工夫として以下のものが考えられた.
    • AtCoderの提出一覧を意識的に活用できるようにする.
    • 演習では小グループに分かれてそれぞれにコーチがつくようにする.

謝辞

  • 素晴らしい資料とプラットフォームを提供してくれているAtCoderに感謝します.
  • 素晴らしい資料とフレームワークを提供してくれているSiv3Dに感謝します.
  • 講師を含めて,勉強会に参加してくれた方に感謝します.

AtCoder反省会してたはずが気が付くと規格読みながらcpprefjpにプルリク投げてた

はじめに

本記事では,私の所属サークルでAtCoderコンテストABC218の反省会していたはずだったのに,気が付くとC++の規格書を読みながらcpprefjpにプルリクエストを送信していた,という話をします. 本記事は,室蘭工業大学 Advent Calendar 2021の3日目に割り当てられた記事です.

adventar.org

本記事の内容は,【LT会】Acompany競技プログラミングLT会 #1で発表したLTの内容をもとにしています.

acompany.connpass.com

経緯

まず,C++の規格書を読みながらcpprefjpの記事を修正するまでの経緯を述べます.

私の所属サークルのAtCoder反省会

私の所属サークルにはAtCoder反省会という会があります. これは,AtCoderのコンテストの時間になったら,オンラインで集合してコンテストに参加し,コンテスト終了後にそのコンテストの問題の解き直し,感想戦,解説などを行う会です. この会は,競技プログラミングをする部員同士で交流することを目的として始まりました.

ABC218

2021年9月11日に開催されたABC218では,100分間のコンテストの内82分経過した時点でA,B,D,Cを解くことができ,残り18分間でEに挑みました.

atcoder.jp

辺を報酬に関して昇順に並べた上で,グラフが連結になるまで,報酬が低い方からまだ連結していないノード同士を繋ぐ辺をグラフに追加していけば良さそうだなあと感じ,DSUを使って実装しました. しかしながら,結果はWrong Answerで,コンテスト中にデバッグを完了することができませんでした.

atcoder.jp

ABC218のAtCoder反省会

ABC218が終了した後,所属サークルのAtCoder反省会が始まりました. Eの解説をチラッとだけ見てみると,コンテスト中に思いついた解法は想定解法と同じっぽい雰囲気がありました. 運の悪いことにサンプルのテストケースは通ってしまっていたので,テストケースをいくつか自作してプログラムの内部状態の変化を確認しました. そうすると,辺を報酬に関して昇順に並べる処理に失敗していることに気が付きました. この処理は以下のようにしてstd::multiset<tuple<ll,ll,ll>>型の変数Cに辺の情報を追加することで実装していました.

/* 省略 */
using ll = /** __int128; //*/ std::int_fast64_t;
/* 省略 */
void solve(){
  /* 省略 */
  auto cmp = [&](tuple<ll, ll, ll> const &t0, tuple<ll, ll, ll> const &t1) {
    return get<0>(t0) < get<0>(t1) || get<1>(t0) < get<1>(t1) ||
           get<2>(t0) < get<2>(t1);
  };
  std::multiset<tuple<ll, ll, ll>, decltype(cmp)> C(cmp);
  /* 省略 */
}

ここで,Cにはそれぞれの辺の情報が次のようなタプルとして格納されます.

  • 要素として報酬,一つ目のノード,二つ目のノードをこの順に持つタプル

また,Cに格納される辺が報酬に関して昇順に並ぶようにするために,コンパレータcmpを指定しています.

このコンパレータは,とりあえずtuple<ll, ll, ll>のコンパレータのデフォルトの実装と同じものを用意しておいて,後で考察しながらいじれるようにするつもりでした(実際にはデフォルトの実装からいじる必要はありませんでした.). しかし,デフォルトの実装のつもりで記述したコンパレータが実際にはデフォルトの実装と異なったものとなっていました. これが,Wrong Answerを解消できなかった根本的な原因であり,ここに誤りがある限りいくら考察を進めてもAcceptedには辿り着けません.

コンパレータの実装の誤りに気が付いたので,以下のサイトの記事を読んで正しい実装を確認することとしました.

cpprefjp.github.io

この記事を読んでいると,記事のコードの中に「`」が紛れ込んでいるのを見つけたため,この1文字を削除するだけのFix typoプルリクエストを軽い気持ちで送りました.

github.com

その時点では,「翌日にはマージされているだろう,また一つ,Fix typoのプルリクエストを送ってしまった」と思っていました.

プルリクエストがマージされるまで

翌日,プルリクエストにコメントが送られました. 私は,コメントの内容を以下の通りに解釈しました.

  • 私がプルリクエストを送る前の説明が,そもそも不完全であったため,それを完全なものとする必要がある.
  • 私がプルリクエストを送る前の説明が,C++17における説明であり,C++20においての説明にする必要がある.

私は,元のプルリクエストの修正範囲を超えていると感じ,プルリクエストを閉じようとしました. そうしたところ,C++17における説明を完全なものとすることにも意義があるため,その修正をこのプルリクエストでやったらどうかという主旨のコメントが追加されました. C++の規格書として参照すべきURLも与えられていたため,これを見ながら修正を行いました. 修正は,基本的に規格書の内容を日本語訳することにより試みました. これに合わせて,プルリクエストのタイトルを変更し,レビューをお願いしました.

これに対して返されたレビューについて,私は以下の通りに解釈しました.

  • 修正内容には問題は無い.
  • コミットの単位をsquashにより修正するべきである.

squashをするのが初めてだった私が少し自信なさげに「やってみます」と返答したところ,なんとレビューコメントにsquashのやり方まで追記してくれたのでした. コミットのsquashを行うと,プルリクエストは無事マージされました.

私のFix typoでないプルリクエストで,個人的なプロジェクト以外のリポジトリにマージされたのはこれが初めてでした.

Fix typo以外でマージされた初めてのプルリクエス

ABC218のE問題のAccepted

コンパレータはstd::tupleのデフォルトの動作で十分であると考察したため,デフォルトのコンパレータを使用するように変更したところ,デバッグも順調に進み無事Acceptedとなりました.

atcoder.jp

誤りのあったコンパレータを,あえて明示的にデフォルトの動作と同様の動作をするように修正すると以下のようになります.

/* 省略 */
using ll = /** __int128; //*/ std::int_fast64_t;
/* 省略 */
void solve(){
  /* 省略 */
  auto cmp = [&](tuple<ll, ll, ll> const &t0, tuple<ll, ll, ll> const &t1) {
    return get<0>(t0) < get<0>(t1) ||
           ((!(get<0>(t1) < get<0>(t0))) &&
            (get<1>(t0) < get<1>(t1) ||
             ((!(get<1>(t1) < get<1>(t0))) && get<2>(t0) < get<2>(t1))));
  };
  /* 省略 */
  std::multiset<tuple<ll, ll, ll>, decltype(cmp)> C(cmp);
  /* 省略 */
}

【LT会】Acompany競技プログラミングLT会 #1

私の友人の所属先が開催するLT会で,競技プログラミングに関するテーマでLTを募集していました. 私も何か発表してみたいなあと考え,上記の内容を5分程度にまとめてLTを申し込みました. LTに対しては,予想していたよりも良い反応をいただくことができ,発表した甲斐があったと思いました. また,LT後の雑談も盛り上がり,Androidアプリの開発やRustをおすすめされたりしました.

私のLTの他に,2つのLTがありました. 一つは,作問をすることにより,解けなくても思考を続ける粘り強さを養いましょう!という内容でした. 解ける解けないといったことの他に,考察そのものの楽しさを忘れないようにしたいと思いました. もう一つは,ICPCに出場しましょう!という内容でした. ICPCに出場したり,コーチとしてついて行ったりしたことを思い出して,懐かしく感じました.

LT会の後で,LTの内容が競技プログラミングと少しずれていたかもしれないと思いました. 友人にそのことを言ってみると,ずらし方が巧妙で気が付かなかったと言われました.

まとめ

やったこと

  • 所属サークルのAtCoder反省会でABC218Eをデバッグした.
  • cpprefjpのtypoを発見してプルリクエストを投げた.
  • 元の説明が不完全だったため,規格を読んで書き直した.

得たこと

  • ABC218EでAcceptedとなるコードを提出できた.
  • C++の規格を読む」という体験をした.
  • コミットの内容だけでなく,形式まで意識してプルリクエストを送信した.
  • Fix typo以外のプルリクが,自分以外のリポジトリに初めてマージされた!

「KurachanActionGame」の開発に関する個人的な振り返り

私は大学で所属しているプログラミングサークルで以下のようなアクションゲームを共同開発しました.

@sakaki_tohruさんには,プレイ動画を公開してくださいましたことについて,感謝いたします.

このゲームでは,プレイヤが「クラちゃん」(クラゲのような生物のイラスト)をクリックすると,クラちゃんは分裂し,プレイヤは得点を得ます. プレイヤはできるだけ高い合計得点を得ることを目指します.

このゲームに関する詳細な情報は,GitHubリポジトリを参照してください.

github.com

以下では,このゲーム開発プロジェクトに関して個人的に振り返ります.

動機

本ゲーム開発を実行しよう思い至ったのは,以下の気持ちが絡まって溶け合い,弾けた結果でした.

  • サークルの同学年の中で進学したのが自分だけで,さびしかった.
  • 前年度,サークル活動が全くできていなかったため,サークルで何かしたいという気持ちが高まっていた.
  • サークルで,既にAPG4b勉強会とSiv3D勉強会が開催されており,ゲーム開発の下地が整っていると感じていた.
  • サークルで,AtCoder勢力に対抗するためゲーム開発勢力を増やしたかった.

プロジェクトの開始

サークルのリモート部会に頻繁に遊びに来る3名に声をかけました. また,これを聞きつけて自分も参加したいと言ってくれた1名も加えて,全部で5名のチームでゲーム開発プロジェクトをスタートしました. サークル内で共同開発する上で工夫した点の一つは連絡手段でした. サークルのDiscordサーバ内のチャンネルの中に本ゲーム開発用の公開スレッドを作成し,本ゲーム開発での連絡は全てこれを利用しました. これにより,以下の効果が得られると考えました.

  • サークル内ではプロジェクト外のメンバにも情報が公開されるため,進行状況がサークル内で共有される.また,後輩が後から参照して参考にすることもできる.
  • スレッドは時間が経つと自動的にアーカイブされるため,プロジェクト終了後はチャンネル内で邪魔にならない.
  • サークル内ではスレッドがそもそも公開されているため,メッセージの送り先を間違えて別のチャンネルやスレッドに送ってしまっても被害が出にくい.

実際,自分も参加したいと言ってくれた1名は,本プロジェクト用のスレッドのやりとりを見たことで本プロジェクトの存在を知ってくれました.

開発期間

2021年9月12日に最初の打ち合わせを開き,2021年10月31日のリリースを行いました. リリースまでの間,毎週2〜4回集まって,毎回2時間くらい開発を行いました. 全員集まれない回もありましたが,集まれる人だけゆるく集まって開発を行いました.

開発場所

開発期間中は対面で集まって開発することができませんでした. そのため,開発はGather.town ( https://www.gather.town ) というビデオチャットプラットフォーム上で行いました. Gather.townは,Discordなどのグループ通話に比べて,「部室に集まってる感じ」があって良かったと思っています.

バージョン管理

学部の頃からずっとGitとGitHubでバージョン管理しながらプログラムを書いてきた私は,バージョン管理されていないプログラムに触わると心が不安に蝕まれるようになっていました. また,複数人で一つの成果物を作り上げる時のバージョン管理方法として,GitとGitHubを利用したものより良い方法が思いつきませんでした.

GitとGitHubを利用したバージョン管理は,慣れていないメンバにとって非常に高いハードルでしたが,GitとGitHubを使ってもらえるように使い方を教えました.

役割分担

開発では以下のように役割分担をしました.

  • 1年生2人,2年生1人:タイトルシーン,ゲームシーン,クレジットシーン,ルールシーンの開発
  • 4年生1人:上記以外のプログラムの作成,プログラミングのサポート
  • 私:イラストの作成,プログラミングのサポート,日程調整

ここでプログラミングのサポートとは,画面共有してデバッグを手伝ったり,設計やアルゴリズムに関する相談を受けたり,レビューと動作確認したり,C++,Siv3D,Git,GitHubVisual Studioなどについて教えたりといったものです. また,日程調整とは,各回の終了時に「次はいつ集まれますか?」と聞いて次回集まる日時を決めるものです. どんなにプログラミングの得意なメンバを集めたとしても誰かが日程調整をしないとプロジェクトは空中分解してしまいます.実際,過去に一度そうして空中分解したプロジェクトに参加したことがあります.

上記ような役割分担にしたのは,以下が理由となっています.

  • 私以外のメンバが,できるだけプログラミングの楽しさに触れられるようにしたかった.
  • 1,2年生をできるだけ手厚くサポートしたかった.
  • オリジナルのイラストが描いて,それがゲームの中で動くさまを見てみたかった.

また,各シーンの開発では基本的にシーン単位で役割を分担しました. 各メンバには,それぞれの担当するシーンについて,動きやデザインの実装を任せました. これにより,それぞれの作業の独立させやすくなり,作業の競合を避けることができると考えました. 欠点として,全体の統一感が損なわれがちになることが挙げられますが,今回の開発ではそれは気にしないこととしていました.

成果物

まず,ゲーム開発の最低限の要求として,遊ぶことが可能な実行ファイルをダウンロードできる状態にする,ということは達成されました. プログラミング経験の浅い1年生もいるチームでゲームを完成させたという成果は,個人的に満足して良いものだと感じています.

一方で,成果物は以下に挙げるような問題点も抱えています.

  • 「パラちゃん」という既存のゲームに類似しており,新規性があるとは言い難い.
  • ハイスコアデータがテキストファイルで保存されるため,プレイヤによる不正が容易である.
  • 全体のデザインなどに統一感が無い.
  • macOS版ではBGMが正常に再生されない.

しかしながら,面白いゲームを作ることや完成度の高いゲームを作ることは私がこのプロジェクトを開始した動機には含まれていないため,これらの問題点については個人的にはあまり気になっていません.

一応,オープンソースとしてソースコードも公開してますので,もし改善案などがあれば,Issue,Pull request,forkなどは歓迎します.

作成したイラスト

個人的な成果として,作成したイラスト「クラちゃん」を以下に示します.

良かったこと

まず,前述の成果物を完成させて大きな達成感を得られたことはとても良かったです. 以下では,このゲーム開発を通じてと感じたものづくりの楽しさと共同開発の楽しさについて述べます.

ものづくりの楽しさ

開発中,ゲームが少しずつ出来ていく様子や自分が描いたイラストがゲーム内で動くようになっていく様子を見ていると楽しかったです. 私の役割の一つであるイラストでは,「クラちゃん」というクラゲのような生物を自分の手によってこの世に生まれさせることが創造的で楽しかったです.

共同開発の楽しさ

今回の開発では他のメンバのプログラミングのサポートもしましたが,イラストの作成に注力することができたと思っています.実際,感覚的には自分の作業時間の50%くらいはイラストの作成をしていた気がします. これは,すなわち,他のメンバにコーディングを任せていたということであり,他のメンバと協力してゲームを完成させたという実感の源泉にもなっています.

また,今回のプロジェクトにはこれまで自分が参加した共同開発ではあまり感じたことのなかった感動もありました. 今まで共同開発は,同学年でチームを組んでいたのですが,このプロジェクトではチームは下級生とチームを組みました. そして,プロジェクトはチームのメンバにプログラミングを教えながら進めました. このような進め方は初めてでしたが,チームのメンバがプログラミングに慣れていく様子やアドバイスしたことが実装に反映されていく様子を見て感動していました.

上級生にプログラミングのサポートに割り当てるという今回の役割分担は,プログラミングの得意なメンバだけが作業を独占してしまうということが発生せず,メンバ全員が開発に関わることができたため,正解だったと感じています.

悪かったこと

プロジェクトの名前の決め方の雑さ

開始時にプロジェクトの名前を決めていませんでした. これはゲームタイトルが決定してから,それをプロジェクト名にしようと思っていたためです. 「パラちゃん」のようなアクションゲームを作ろうということだけは決まっていたため,GitHubに組織とリポジトリを作成するときに雑に「ParachanActionGame」と命名してしまいました. これは良くありませんでした. なぜなら,リポジトリの名前は後から変更できるのですが,組織の名前は後から変更できないからです.

プロジェクト名はゲームタイトルとは独立に最初に決めるべきでした.

プログラミングのサポートの見通しの甘さ

プログラミングの勉強を始めてわずか半年の1年生が2人いる中で,GitとGitHubでバージョン管理しながら,クラスベースのプログラミングを進めていくというのは,振り返ってみると非常にチャレンジングだったと感じています. それでも,プロジェクト開始前は,私がプログラミングのサポートをしながらプロジェクトを無理なく進めることはできるだろうと思っていましたが,その見通しは甘いものでした. プロジェクトを進める中でプログラミングのサポートを実際に行ってみると,一つのことを教えるためにはその背景にある多くのことを教える必要があり,とてもハードであるということに気が付きました.

今回はラッキーなことに,自分から参加したいと言ってくれた4年生がメンバに加わってくれたため,2人で協力しながらプログラミングのサポートをすることができ,何とかゲームを完成させるまで至ることができたと思っています.

まとめ

  • サークルで幅広い学年のメンバで構成されたチームを結成し,ゲームを共同開発した.
  • KurachanActionGameという名前のアクションゲームを完成させ,実行ファイルをGitHubで一般に公開した.
  • プログラミングやバージョン管理に慣れてないメンバのサポートをしながらプロジェクトを進めた.
  • 開発中はものづくりや共同開発の楽しさを感じ,完成時には達成感を味わった.

謝辞

プロジェクトに付き合ってくれたメンバの皆さんには,一緒に開発してくれたことについて大変感謝しております. 本当にありがとうございました! これからもよろしくお願いいたします!

麻雀プログラミング

定義

麻雀プログラミングとは,麻雀をしながらプログラミングをするというもので,具体的には以下の通りに実施します.

  1. 5人以上の参加者を集めます.
  2. 参加者の中から麻雀プレーヤーを無作為に4人を選択します.
  3. 麻雀プレーヤーとして選択された参加者は麻雀の一局戦(または東風戦)をします.
  4. 2で選択されなかった参加者はプログラミングをします.
  5. 麻雀が終了するたびに2から4までを繰り返します.

着想

麻雀プログラミングはカラオケ麻雀という遊びから着想を得ました. カラオケ麻雀とは,カラオケで歌いながら同時に麻雀もするという非常にチャレンジングかつエキサイティングな遊びです. この遊びが生まれたのは,友人と遊ぶ計画を立てていた時でした.カラオケと麻雀のどちらで遊ぶかで迷っていた我々は,大学で培った洞察力と常識に囚われない発想力に基づいて,カラオケと麻雀の二つが背反ではないという天才的な発見をするに至り,さらにカラオケと麻雀を同時に遂行するカラオケ麻雀という革新的なアイデアを導き出したのです. カラオケ麻雀を実行してみると,カラオケも麻雀も楽しめるということの他にも予想外の知見を得ることができました. それは,カラオケと麻雀のどちらか一方だけに集中力を注ぐことができないために,常に不完全燃焼となり,長時間続けても飽きや疲れを感じないということでした.

そして,「複数の楽しいことを組み合わせることによりもっと楽しい時間を過ごせる」という理屈と「あえて過度な集中を抑制することにより飽きや疲れを感じずに長時間続けることができる」という理屈をプログラミングに応用できないかと考えた結果,上記の麻雀プログラミングに思い至りました.

期待できること

麻雀プログラミングによって期待できることを以下に示します.

  1. 楽しい時間:麻雀やプログラミングはそれぞれを個別に体験しても楽しい時間を過ごすことができます.いわんや,麻雀とプログラミングの両方を体験できる麻雀プログラミングをや.なおさら楽しい時間を過ごせるのではないかと期待しています.
  2. 生産量の向上:麻雀プログラミングでは,麻雀とプログラミングを行ったり来たりすることにより,プログラミング(および麻雀)に対する過度な集中を抑制します.また,一局戦(または東風戦)が終了するタイミングで交代となるため,キリの悪いところでプログラミングを中断することができます.これにより,疲れや飽きを感じてしまうことや,達成感を得て集中力を切らしてしまうことを防ぐことができます.以上から,プログラミング(および麻雀)の質は下がるかもしれませんが,それを補うくらい長い時間をプログラミング(および麻雀)に注ぐことができ,むしろ生産量(得られる楽しさの量)は向上するのではないかと期待しています.

検証

実はまだ,麻雀プログラミングを実施したことがありません. 麻雀プログラミングの効果の検証結果については,実際に麻雀プログラミングを実施した後で書きます.

また,もし麻雀プログラミングを実施してみた方がいらっしゃったら,コメントをいただけると嬉しいです.

GitHub人狼 -- みんなでプログラムを書いてカジュアルに遊びたい!

目的

本記事の目的は,みんなでプログラムを書いてカジュアルに遊ぶためのパーティゲームGitHub人狼」を提案することです. 以下では,このゲームの遊び方,提案の背景,期待する効果,懸念点について説明します.

遊び方

ゲームの概要

GitHub人狼」は,ソフトウェア開発プラットフォーム「GitHub」を利用するゲームです.開発チームに紛れ込んだ「人狼」の妨害を回避しながら「村人」達が成果物を完成させることを目指します.

  • 参加人数:3人以上
  • 所要時間:2時間以上

勝利条件

「村人」と「人狼」の勝利条件を以下に示します.

  • 村人の勝利条件は,開発するべき成果物の「仕様」が定義されており,かつ,以下が全て満たされることです.

    1. 最終的な成果物が実行可能である.
    2. 定義した全ての仕様が実装されている.
  • 人狼の勝利条件は,開発するべき成果物の「仕様」が定義されており,かつ,以下のどちらかが満たされることです.

    1. 最終的な成果物が実行可能でない.
    2. 定義した仕様のうち実装されていないものがある.

勝利条件が満たされない場合またはルール違反をした場合には敗北となります.

ゲームの流れ

ゲームは以下の流れで進行します.

  1. 仕様定義
  2. リポジトリ作成
  3. ロール決定
  4. 開発
  5. 成果発表
仕様定義

開発チーム内で相談し,開発するべき成果物の「仕様」を定義します. 仕様は,成果物に実装するべき動作についてスライドなどにまとめます. 仕様定義に割くことのできる時間は,あらかじめ決めておきます.

リポジトリ作成

GitHub上で開発チームのリポジトリを作成し,メンバーはそれぞれフォークして開発環境を整えます.

ロール決定

開発チームを構成するメンバーそれぞれのロールを決定します. ロールは「村人」と「人狼」のどちらか1つをランダムに割り当てます. ただし,村人の人数が過半数以上となるようにします.

開発

村人は定義した仕様を満たすプログラムの実装を進め,人狼はこれを妨害します. 具体的には,以下の手順を繰り返します.

  1. 開発チームのメンバーはそれぞれプログラムを書く.
  2. プログラムを書いたメンバーはプルリクエストを送る.
  3. プルリクエストに対し,メンバーはマージするかどうかについて匿名で投票する.
  4. 投票でマージの得票数が過半数以上になった時,プルリクエストをマージする.

開発に割くことのできる時間は,あらかじめ決めておきます.

成果物発表

開発チームのメンバーは互いにロールを公開し,成果物発表を行って勝利条件を確認して勝敗を決定します. 成果物発表では,村人は成果物発表を行い,成果物が実行可能であることおよび全ての仕様が満たされていることを示します. 人狼は,成果物が実行可能ではないことまたは満たされていない仕様があることを指摘します.

オプショナルルール

  • 人数に余裕がある場合はゲームマスターがいても良いです.ゲームマスターは,時間管理,ロール決定,票の収集,過半数の得票があったプルリクエストのマージ,勝利条件の確認を行います.
  • 全ての人狼が合意した場合,投了した上で開発に協力することができます.この場合,村人は勝利となり,人狼は敗北となります.
  • GitHubを利用するのではなく,GitBucket,GiteaまたはGogsなどを利用しても良いです.

提案の背景

私は,自分が所属するプログラミングサークルにおいて,以下のような部員同士の交流に関する問題を解決し,プログラミングに触れながらカジュアルに交流したいと考えていました.

  • プログラミング:それぞれの興味がバラバラで個人プレーになりがちである.
  • 勉強会:コミュニケーションが一方的になりがちで,なかなか盛り上がらない.
  • チーム開発,ハッカソン競技プログラミング:ハードルが高く,カジュアルじゃない.
  • 麻雀,人狼,AmongUsなどのパーティゲーム:交流はできるが,そもそもプログラムを書かない.

そして,共同開発に人狼やAmongUsのような駆け引き要素を取り入れることはできないかと考えた結果,上の「GitHub人狼」を思い付きました.

期待する効果

GitHub人狼」で遊ぶことにより,以下の効果が期待できると思います.

  • プログラミングを通してカジュアルに交流できる.
  • プログラミングをパーティゲームとして楽しめる.
  • スキルに差があってもゲームとして成り立つ.
  • 共同開発っぽい体験ができる.
  • プログラミングとGitの練習ができる.

懸念点

以下の懸念点が挙げられます.

  • プログラミングとGitの基本スキルが必要となる.
  • 仕様が曖昧だと勝敗も曖昧になってしまう.
  • 現状ではテストプレイが不十分である.

遊んでみた感想

遊んでみてから書きます.