ゼミ課題でボードゲームを考案してアプリを作るまでの話 ③

HICHAIN プログラミング ボードゲーム Processing

総コン Advent Calendar 15日目です。
今回は以前の記事の続きで、HIchain Prototypeの開発に関する話です。
2015年12月～2016年6月の約半年に及ぶアプリ開発について振り返ります。

前記事: ゲームマーケット2016春出展まで tkw.hateblo.jp

作戦会議: データ構造 (12月中旬)

アプリ開発グループの第1回会議

最初のプロトタイプをサークルのメンバーと遊んだときからアプリ開発は考えていました。
そして2015年12月にはアプリ開発のメンバーは私を含め3人が集まりました。
その中でもアルゴリズム担当やUI担当などあらかた担当を決めました。
最初に開いた会議ではデータ構造の構想を練りました。

f:id:tkww:20171215164351j:plain
文字のデータ構造案

HICHAINの文字は点と辺の要素があり、それらの接触が着手できるかを判定する基準になります。
点と辺はそれぞれ8つあり、それらを一緒くたに考えるため点を奇数、辺を偶数に割り当て長さ16の配列として構造化することにしました。
また文字と文字の向きは番号で表すことにしました。
プロトタイプ版においてこの構造はほぼ変わりません。

他にアプリにどんな機能が必要か、クライアントサーバーモデルにするなど決定しました。 これらの構想はのちにP演習発表作品として開発するCHAIN REVERSIでも生きてきます。

とりあえず実装してみた (3月下旬)

かなり飛んで2016年3月末になりました。
というのもCHAIN REVERSIの開発、ゲームマーケットの準備、春休みの怠惰もあって開発が停滞していました。
とりあえず主要な機能を実装したv1.0ができました。
この頃実装できたのは置ける条件判定や得点換算などCUIではあるものの、とりあえず動くコードではありました。

int [][][][][] can_set_card = new int[200][200][2][27][4];

ただやばそうな配列を使っていて可読性は最低…

またUIのイメージも固めました。UIでどんな機能か必要か列挙して方針を立てていきます。

f:id:tkww:20171215163934j:plain
UIのイメージ

流石にクラスを導入する (4月下旬)

2016年度に入り、阿原研に所属したことでHICHAINのアプリ開発はゼミの研究としてもスタートしました。

そしてあまりにv1.0がカオスなコードだったので、習ったばっかりのクラスを使うことにしました。

f:id:tkww:20171215172811j:plain
従来の構造

f:id:tkww:20171215172828j:plainf:id:tkww:20171215172247j:plain
クラス構造案

このときは候補3の構成要素ごとに分割するレイヤー構造が採用されました。
しかしこの後開発するJava版では候補2に近い構造にシフトしています。

また並行してUIも開発しています。
まずは盤にカードをはめるだけの機能を実装しました。

f:id:tkww:20171215174902p:plain
UI第1弾

ゲームの流れや構造を確立していく (5月上旬)

本当は初めに決めておくことですが、この段階でゲームの流れを決めました。

またクラス構造もこの段階で固まってきます。

f:id:tkww:20171215180955p:plain
クラス構造

構造とアルゴリズムの見直し (5月下旬)

さて、この辺から1歩進んで2歩下がるような状況になってきます。

実装していく過程で現在のデータ構造では不便が生じることに気づきます。
点・辺の構造において順番が右回りだと置ける条件判定のときに不都合が生じてしまいました。 そのため構造を見直し、またアルゴリズムもより効率のいいものにするため一から考え直しました。
この時点で配列を使うアルゴリズムから、ビット演算を使うものにシフトしました。

このようにこの辺から右往左往する時期に突入します。

魔の6月: ルール実装

さて6月に入り頭の中はほぼHICHAINで埋まってました。
暇があればアルゴリズムを考え、紙にまとめ、実装し、テストするというアジャイル開発に近いことをやっていました。
授業中もずっとやっていたような記憶があります。

この頃最も悩んだのが、文字のつながりを得点に換算する部分です。
特にCHAIN REVERSIでもつまずいた得点重複問題には苦戦しました。
あらかた正しく動作するのにある特定の状況でうまくいかず、苦戦する部分はほとんど例外処理でした。

そしてついにルールの実装を終えます。

6月中のリリースを目指していたのでギリギリの状況

魔の6月: UI実装

ルールを実装したら、UIの実装に取りかかります。
この頃はUI担当の人に付き添って作業していました。

ルール部分とUI部分は別々に実装していたため、それを統合することは非常に手間がかかりました。
さらにたびたび仕様変更を重ねていたため、ルールとUIで構造が異なりルール側に合わせる作業が最も時間がかかりました。

そしてついに2016/6/30、最初のバージョンであるr1.0.0をリリースします。

なんとか6月中のリリースに間に合う

振り返り

Prototype版では開発が進むたびにデータ構造やアルゴリズムを変えてきました。
先のことは読めないので、これに関しては仕方がない部分もあります。

しかしPrototype版にも関わらず効率化を求めすぎた気もします。
もちろん効率化は大事ですが結局後々そのアルゴリズムがあまりよくなかった場合、無駄になってしまうので初期段階では拘る必要はないと思います。
また効率化はしばしばアルゴリズムを複雑化するので、共同開発のときは効率より分かりやすさを重視した方がいいかもしれません。

Prototype版の開発はアルゴリズムを考える練習になりました。
特に参考にできるゲームや使えるアルゴリズムも見つからなかったので、全て自分たちで考えることは良い経験になりました。
なお半年もかけて作ったPrototype版ですが、後に開発するJava版ではほとんどのアルゴリズムを作り直すことになります…

次回

このシリーズはこれにて完結ですが、番外編として現在までのアプリ(プラットフォーム)開発について進捗報告をしたいと思います。