クイズ大会の得点表示プログラムを作る上で、気づいたこと等を自分の備忘録も込めて投稿します。
あくまで私が実施している方法です。ここをこうしたほうがいいんじゃないか？というアドバイスなど有りましたら、ご教授頂けると有り難いです。
これからクイズ大会の得点表示を作ってみたい、Excelから次のステップに行きたい、みたいな方にも分かるように書きたいとは思いますが、なにぶん私も大した技術者ではありません。その辺にいるようなただの大学生が少しプログラミングの能力を得た程度です。
今回は得点表示をプログラムで作ってみたい、という方の力に少しでもなれればという気持ちで筆を執らせて頂きました。何様だよと思われる方もいるかも知れませんが、なにぶんご容赦ください。
また、大会をまとめる方なんかも得点表示がどんなことをしているのか知ってもらう意味で読んでもらえるのは嬉しいです。
大前提
- ここでいうクイズ大会の得点表示プログラムというのはExcel（VBAも含む）を使用したものではなく、アプリケーションとして得点表示画面を作るものです。
- そもそもとしてクイズ大会の得点表示プログラムはGUI（グラフィカルユーザーインターフェース）アプリケーションを作ることが出来る言語やライブラリ・フレームワークなど、及びそれを扱うための開発環境を使えることが前提です。
- ちなみに私は.NET FrameworkでC#+WindowsForms/WPFを使用しています。どの言語が得点表示に最適なのかは知りません。ご存知の方は情報をください。
- 得点表示専用のライブラリがあるとかないとか……そんなお話を耳にしたこともありますので、それを利用するのも手かと。
- また、得点表示を作るためのソフトウェアを開発されている方もいらっしゃいます。それが一般的になれば、この記事もきっと用済みになることでしょう。
と、大前提が「プログラミングできること」と書くと、これからやってみたい人には敷居が高く感じてしまうかもしれませんが、これは得点表示を作る上で「プログラミングできる＆GUIアプリケーションが作れる」以外に必要なものはそこまで多くないためにこのような書き方をしています。ですので、まずは普通に言語等々をしっかりと学ぶことが先です。
言語を学んだ上で、得点表示を作るためのスパイス的な部分を今回はまとめたいと思っています。
様々な「得点表示」の利点・欠点
得点表示をするのには様々な方法があります。abc・STUはじめ大きな大会では基本的にプログラムが使われていますが、すべての場合においてプログラムが最適とは全く思えません。
まずはそれらの比較をします。
プログラムの場合
利点
- 見栄えがいい
- アニメーションが使えるので目でも楽しませられる
- ソフトウェアを作ることになるので実質どんなことでも出来る（使うモノによる）
欠点
- 時間がかかる
- 作れる人が少ない（習得難易度が高い）
- バグが発生する可能性がある（技術力・バグチェックの余裕次第）
Excelの場合
利点
- プログラム程は行かずとも、ある程度見栄えのいいものが作れる
- 制作方法の習得が容易
欠点
- アニメーションは使えない
- どうしても枠が微妙に残ってしまい、見栄えにこだわるなら煩わしい場合も
- 関数すら使えない人は作れない
手書き（ホワイトボードなど）
利点
- 誰でも出来る
- 簡単
- 準備がほぼ不要
欠点
- 見栄えは良くない
- 複雑なルールに弱い（特に面倒な計算が必要となるルール）
このように、得点表示のやり方に依って、利点欠点は様々です。
例えば、サークル内のミニ企画程度にプログラムを一から作るのは流石に大げさですし、何百人も来るような大会でホワイトボードにちょこまか書いているだけというのは見辛すぎます。
そのような点で、規模に合わせた物が作れるExcelの利点は大きいようにも思われます。
Excelの得点表示に関しては、Lesothoさんのブログ「Excel得点表示道」で作り方を非常にわかりやすく紹介してくださっています。また、Excelでもここまで出来るのか、という例も紹介してくださっていますのでぜひ一度訪れてみてください。
それを見ても尚、プログラムによる得点表示が必要な方はこの記事を参考にして頂けると有り難いです。
いざ作る、となったあと
「得点表示をプログラムで作るぞ！」となったとき、まず何をするかです。
あくまで、私の場合ですので適当に飛ばすなり、足りないところがあれば各自で補ってもらえるといいかと思います。もしも補った場合は私も参考にさせていただきたいのでぜひどのようなところを補ったか教えてください。
作る必要があるもの
そもそもとして何を作る必要があるのかです。これについては、
- 操作パネル
- 表示画面
の2つとなるでしょう。基本的にはまず操作パネルを起動し、その上での操作により表示画面を出すという流れになります。
もちろん、利便性を挙げるために操作パネルを全ラウンド連携させるなんてことやTwitter連携なんかもできますが、それは一旦置いておきましょう。
今回は最低限この2つが必要ということで話を進めます。
三原則
得点表示を作る上で、私は、
- デザイン
- 可読性
- 操作性
の三点を大事にしています。
これはあくまで私が考える「得点表示三原則」のようなものです。人によって大切にするものは違うと思いますので参考までに。軽く解説します。
まずデザイン。これに関しては特段解説も必要ないような気がしますが、デザインが良ければ見ている人に見応えを与えられます。正直センス命なところがあるので、私が一番苦手とするところです……
無いものをねだっても仕方ないので、無いなりに最大限努力しています。
次に可読性。デザインが良くても表示すべき名前や得点などが見にくかったら存在意義を失います。文字が目立つように背景には補色を使うなど、出来る限りの工夫をして行くと良いでしょう。
最後に操作性。これは表示画面自体に関わるわけではありません。むしろ、**時間通り大会を終わらせられるか？**という点はここにかかっています。具体的に言えば「Undo機能の有無」「緊急時の対処のしやすさ」なんかに気を遣っていきましょうね、というような感じです。
得点表示は大会の運営上、トラブルが起きたときに一番時間を食いやすいポジションです。つまり、大会を時間通りに終わらせられるかという議論の上で最も重要になるでしょう。そのため大会の実施という点に重きを置けば、三原則の中で最も大切なものとなります。
表示画面を作る
まずは表示画面を作って行く流れです。おそらくコードを書いていくのは操作パネルと並行して作っていくことになるとは思いますので、それを頭に置きながら読んでいって頂けると良いかと。
基本的に表示を変えるのは操作パネルから行うこととして話を進めるので、ここではデータの変更ではなく、あくまで表示させる画面の作り方についてです。
テーマを決める
もちろんいきなりコードを書き始める人も居るんだと思いますが、私はそれだとバランスが悪くなったりしてしまうので、まずはなんとなくのテーマを決めます。
例を挙げるなら、
- 第26回高校生オープン → ロゴに合わせたシックなイメージ、カラーはモノトーンめ
- KSC the eighth → プレートの色が冠位十二階だからテーマは和風、勘亭流なども使って和を最大限にアピール
といった感じです。私としてはこれが決まっていると各ラウンドごとの表示デザインも決めやすいので。
大会によってはサクッと決まることもありますが、私はここに一番時間がかかることが多いかもしれません………発想力がない………………
各ラウンドごとのデザイン・レイアウトを決める
テーマを決めてもまだコードは書かずに、先にデザインを決めます。多くのアプリケーションを作る際はそのようにされている場合が多いと思います。
コードを書きながら決めていくのも有りなのだと思いますが、私はやっぱりそれも出来ないので紙に書きます。場合によってはPhotoshopを活用したり、PowerPointで作ったりすることもあります。
部屋の特徴に合わせて得点を上に表示するのか下に表示するのか、そのようなことについても気にして行かなければなりません。
実際に作り始める
テーマに合ったデザインが完成したら、そのデザインに合わせた表示をいよいよ作っていきます。
ただ、コードを書いていく中で「そもそもそのデザインの実装は非常に手間がかかる」ということに気づいたり、より良いデザインを思いついたりということもあると思います。そのような場合は手直ししながら進めていきます。そのため、私は最初のデザインがそのまま実装される場合はあまりありません。
ここに関しては各言語ごとの特徴を活かして作っていくことになるので、特別なことはありませんが、オブジェクト指向言語の場合はしっかりとクラスを作っていくほうが吉です。
特に2Rなんかは人数が多くなりやすいので、これをしてあげないととても面倒くさいことになります。（高校時代、まだ技術力が乏しい頃に面倒くさいのをやってしまっているので本当にやめておいたほうがいいです。病みます。）
操作パネルを作る
操作パネルの作り方としては
- 表示画面とほぼ同じインタフェース（縮小画面など）にして、その上に操作ボタンを設置する
- まるで違うものにする
という2つに大きく分けられると思います。私は後者の場合が多いです。ここに関しては好みでしょうか。
前述したとおり操作性に関わる部分なので、各々が操作しやすいものを作るのが一番です。
使う上での大まかな操作の流れ
大会で実際に使うプログラムの操作の流れです。これをイメージしながら作ると当日使いやすいプログラムにしやすくなります。ここで挙げる流れはあくまで一例ですので、各自でまず考えてみるといいかもしれません。
- プレイヤーデータを取得する（CSVより）
- 取得したデータを表示画面に送信
- 表示画面を表示
- ラウンド開始、正誤ボタンとスルーボタンでラウンドを進める
- 得点に動きがあると、そのたびに表示画面を更新
- ラウンド終了、必要であれば次ラウンドに持ち越すようなデータなどを保存
だいぶ雑多な書き方をしていますが大まかにこんな流れです。
このような流れを意識していけば自然と操作パネル上に必要なものは分かってくると思います。
プレイヤーデータを取り込む
操作パネルはまず最初にプレイヤーデータを取り込む必要があります。これについては言語によらず、CSV（Comma-Separated Values）ファイルを使用する事が多いです。知らない方は本当に知らないかもしれませんが、以下のようなファイルです。
1,文蔵,高２,笹島 学人
2,開城,高２,大蔵 邦光
3,開城,高２,深見 誠司
4,赤河田,高３,新名 匠
5,宮浦,高３,芦屋 洋介
6,麻ヶ丘女子,高３,苑原 千明
一行に一人のプレイヤーデータが記載されています。そのデータもカンマ(,)で様々な情報が区切られており、この場合は左から順に「順位」「所属教育機関名」「学年」「名前」という形で記載されています。
例えば1行目の1,文蔵,高２,笹島 学人であれば、1位の文蔵高校2年笹島学人さん、というプレイヤーであることを示します。
これをリストや配列の形で管理するのが一般的です（選手ごとにオブジェクトにするともっと楽）。このCSVをリストや配列にする方法については言語ごとに先駆者のみなさんがまとめてくださっているでしょうので割愛します。ライブラリが豊富な言語であればほぼ確実にライブラリはあると思うのでそれを利用すると良いでしょう。
言語や各々の技術にもよりますが、tab区切りのTSVというファイル形式もあります。もしも余裕等ありましたら、こちらを使うことも考えてみてください。
操作パネルを作る上で注意していること
基本的にはレイアウトを決めてから作るという感じで、手順は表示画面と大きくは変わりません。ただ、レイアウトについては非常に注意して作っていきましょう。
意識すべきは、**自分以外が操作しても迷うことなく操作が可能か？**という点です。
多くの場合製作者と操作者は同じである場合が多いです。だとしても、誰にとっても使いやすいプログラムを作っておくことは不慮の事態に備えられる以上に、自分にとっても使いやすくなってくれます。
実際に前日に体調を崩した際に別の方に操作いただいたことも有りましたが、このことを意識しておくことでそんな場合も無事に大会を終えることができました。
また、操作効率についても考慮は大切です。
例えば、正誤ボタン（各々の正解／誤答時に押すボタン）とスルーボタン（ボタンが押されず誰も解答しなかった際に押すボタン）が操作パネルで離れているのは、操作性を考えた上で良いことでしょうか？
基本的に正誤ボタンを押す回数が多いわけですので、その付近にポインタを置くことが多いでしょう。その点を考慮すれば、スルーボタンはその近くに一緒においておくほうが操作の上での効率は高まります。
さらに、正解と誤答で色分けしておくのは誤操作を防ぐ上で良い手段であったりします。色情報というのは人間にとって非常に重要なもので、文字で得る情報より感覚的にボタンのイメージを得ることが出来ます。これにより、正しく色分けすることで直感的な操作を実現することが出来ます。
操作パネルと表示画面の連携
多くの場合、操作パネルは表示画面と独立して動き、得点表示プログラムの核をなします。ただ、人々の目に触れるのは当然表示画面です。こちらが動かなくてはそもそもの意味をなしません。
この点については適当な関数をつくって、「正解」「誤答」「スルー」等、データを反映させなければならない挙動が起きた際にすぐに呼び出せるようにしておくといいでしょう。
タイマー等を設置する際は別スレッドで動かす方が望ましいです。同じスレッドだとやはり限界があります。
データの保存
ラウンド終了時にそのラウンドの順位等を保存しておく必要があるのであれば、そのためのコードを書く必要があります。これについても特段の理由がなければCSVファイルでいいのではないでしょうか。
読み込みと同じく、ライブラリで簡単にできる場合が多いです。ライブラリがないなら、ファイルを書き出す関数でカンマ区切りで書き出してやれば良いです。
配列やリストをまんまバイトファイルなんかにしてくれるものもあったりはしますが、記録として確認しづらいというところもあります。読むためのプログラムを書くのも面倒ですし、その点を考えて私はCSVを使いがちです。
ちなみに、CSVファイルは一般にMicrosoft Excelで扱うことができますが、そのためには文字コードをShift-JISで作る必要があります。でないと日本語が文字化けしてしまう可能性があります。
UTF-8が基本的な文字エンコードとなっている言語もあります。この点文字化けしてしまうようなら出力の文字コードを確認すると良いかと思います(もちろんUTF-8でも閲覧可能なものもあります→Excelでも設定によってはできたかな…？)。
また、これを応用して全問題の正誤なんかを記録することもできます。記録集作成と連携させればスムーズに記録集が作れるかもしれませんね。私は構想だけでまだやったことがありませんが。
まとめ
大雑把にまとめたつもりが割と大きくなってしまいました。
ところどころ偉そうに書いているかもしれませんが、正直大したプログラマではない私です、あくまで参考までにしてもらえると嬉しいです。
得点表示とクイズ大会の未来
ここからは持論です。得点表示をやる人というか、大会長ポジションやそれに準ずる方とかが関わってきそうな。
現状、多くの大会でプログラム式の得点表示が活用されています。小さめの大会でもホワイトボードではなく、Excelを使ったものが増えてきているでしょう。文系の多いクイズ界の中で理系的な能力も必要とされてきているというわけです。
そんな中で、このようなプログラムを作るとなると、やはり理系の人が抜擢されがちです。とはいえ、クイズの得点表示は普通に外注すれば数万円～数十万円はくだらないような代物です。ほとんどの人がボランティアで開催される大会においては、はっきり言って求められるものが大きすぎるところがあります。
勿論、プログラムを作る経験としては非常にいいものなんですが……これを分かっていない人は本当に多いんだな、ということを近年痛感しているところです。
もしもこれを読んでくださって、クイズ大会の大会長などになられる方がいらっしゃるのなら、その大会の得点表示の方をしっかりと労ってあげてください。
大会後はもちろんですが、開催前も積極的に連絡を取り合って、当日の流れにあったものになっているかをしっかり確認するようにしてください。直前になって急な変更が利かない可能性も十二分にあります。ただそれは得点表示だけの責任ではなく、どのような表示が必要であるかの連絡不足によるところが大きいかもしれません。これを失敗して、直前にも関わらず「ここをこうしろ」と指図するのは間違いなくタブーです。それは最初にどういう流れで使うのかを伝えておけば防げたはず。
流れを変更するなり別の対応もできる中で、本当にプログラムを変える必要があるのなら、下手に出て謝りながら何とか変えてくれないかと頼んでみるのはいいかもしれませんが……その方があまりに不憫でなりません。
善意でスタッフをやっていたはずが、それをきっかけにその方がクイズをやめる、なんてことが起きてしまったら、冗談じゃ済まないです。人ひとりの趣味を奪ってしまうことになるのですから。
そんなことを思いながら、得点表示の立場の向上を願ってやまないこの頃です。