競技部門について

さて、今日で高専生最後の日です。

高専生なうちに競技部門について感じたことを書いてみようと思います。
2010年の競技部門からなので来年のためになるかは別。
メンバーは出来れば3人。
今年は自分が至らずほぼ自分一人で作るという失礼な結果になったのでその辺の分担についてもちょびっと。
アルゴリズムについては当然全員で話しあうこと。

とりあえず流れ。

まず、4月に公開されるであろう要項をよく読むこと。
ここでちゃんとルールを把握するように。
そして、要項には競技の評価方法とかが書いてあるはずなので、自分たちでその評価ができるツールを必ず作ること。これが一人必要。

コーディングを始めるときには、アルゴリズムを決定するまえにプログラムの構造を先に考えること。
アルゴリズムなんてどうせ試合前5分とかまで変更し続けるんだからコードが肥大化しても自分が扱いやすく変更しやすい物にする。
コーディング担当は一人で結構。チームで相談して決定したアルゴリズムをできるだけすべて実装すること。下手にアルゴリズム同士を組み合わせない。
組み合わせるのは実装して評価してある程度煮詰めた後で。
そしてこの評価を残った一人が行うこと。
コーディングしてる人疲れるから休ませてあげて。
逆に言うとコード書く人はテストとするのが嫌になるほど気合入れてコードを書くようにしないとダメ。
ずっと考えてずっと書き続けることで微妙な修正点と飛躍的な改善方法が生まれる。かもしれない。

まあそんな感じで試合まで頑張る。
試合終われば寝れるから大丈夫だ。

次にアルゴリズムとかコーディングについて。
まずはルールを把握して、ある程度コードを書いて最低限動くものを作ること。
2010年で言うと「配水」「チャージ」「移動」ができるってとこまで。
そこからアルゴリズム。
ちょっとやると改善したくなるしする方法もすぐわかる。
でもその前に競技内容で一番勝ちにつながることを考える。
2010年では「水の配水量」がそのまま点数で、相手の邪魔をしても点数にはならない。
つまりいかに水の配水を効率よく行っていくかが勝ちに近づく方法だったわけで。
中途半端に「あれもしよう」「これもしよう」「これ付けたら強いんじゃね」とか絶対にしない。
たとえ計算量とか非現実的でも、まずは勝ちに一番近づける部分を可能なかぎり煮詰めること。
動きさえすれば絶対勝てるっていうものはどんなゲームでも必ずありますのでそれを見つけられるように。

そして、いらんもの作らない。
競技結果発表前に自分たちの順位がわかるものつけちゃったりとかしない。
(ちなみに2010年長野高専競技プログラムは正常終了しないプログラムでした。)
そんなことしたって結果発表のドキドキが失われるだけなのでそんな時間あったらチョコ買いにいくとかカラオケ行って気晴らしするとかしてください。

あとちょろっと評価について。
まあ、評価したときに順位が出る物であれば、一つ下の順位とのスコアの差を常に気にするように。
順位が上がるように改善できなくても、この差が増えていればきちんと改善されていると考えて良いと思います。

以上ですが、一番大事なことは「一見無理そうに見えるけどこれできたら絶対勝てる」を諦めないで作れってことです。
それに必須でない機能は付けない。
例えば相手のスコア計算するものとか、いらないでしょ?

そんなわけで来年から競技出る人頑張ってください。
そろそろ長野高専にも競技1位欲しいです。
あと、うちの学校1位とか2位にならないと入賞してないのとあんま変わらない扱いなので頑張ってくださいね。

来年度のクリエイターズ同好会

 来年度(平成23年度)のクリエイターズ同好会の活動について次々と決定されています。

現在、来年度はプロコン出場者とそれ以外の人で活動を分けていこうと思っています。
プロコンに出場しない人は主に新入生になると思われます。


・来年度のプロコン
 来年度のプロコンの大まかな予定は以下の通りです。募集期間までに作品をどうするか決めなくてはいけないのであまり時間はありません。
募集期間:5月20日(日)〜27日(金)
予選:6月25日(土)
本選:10月15日(土)・16日(日) 場所:一関文化センター
今年もプロコンメンバーを集めて予選突破を目指します。

。プロコン以外の活動

 Processingと呼ばれる言語を用いてプログラミングの基礎を学びます。本年度の反省を活かして来年度は教材、教える側の人間をきちんと用意して、活動が止まらないようにしていきます。
Processingを選んだ理由ですが、この言語はとても簡単にグラフィックを扱えるので成果が出やすく、「コマンドラインだけを見て絶望→挫折」ルートとならない可能性が高いためです。一通りプログラミングの基礎を学んだらゲームなどの作品を作ってもらうような方向性で考えています。

以上が来年度の予定ですが、現在Processingの代わりにツクールを使ったらどうかという案が出ているなど、ほとんど未定です。