そこそこの学生ゲームプログラマによる、コードの書き方やその技術に関する考察。あとGGJ

プログラミングの世界では特に「車輪の再発明はするな」と言われる。
まあ賛否両論あることはそうなんだが、ちょっと待ってくれ。

そもそも再発明できるのか？

自己紹介

はじめまして。おさむもやもやしいです。
情報系の学部にいますが、ゲーム作ったりプログラム書いたりしてます。
(情報学に関してはほぼ独学みたいな不思議なところですが…)
今回は、最近コーディングに関する本を2冊読みつつ、
いくつか読み返したときに考えたことについて書いてみようと思います。
具体的な技術どうのこうのはできる限りやらない方向で頑張ります。

ことの発端GGJ2021

2021/1/29
グローバルゲームジャムと呼ばれる祭りがオンラインで開催された。
詳しくは調べてもらったほうが早いかもしれないが要するに、
48時間でゲームを作ろう
という祭。しかも大抵その場で初めて会った人とチームを組んで、である。
幸か不幸か同じ大学の人4人に別の大学の人2人というお友達の集まりのようなチームで開発することになり、結論めっちゃ楽しかった。
興味があればぜひ遊んでみてほしい。
(48hクオリティということは忘れずに…)
https://globalgamejam.org/2021/games/colorcode-b-3

光の三原色とコード

今年は"Lost And Found"
をテーマにゲームを考えて制作する。
(基調講演のムービーも感動的なんでぜひ見てほしい)
色々ありつつ、光の三原色を基本のシステムとしていくことになった。
例えば、赤と緑が混じったら黄色の効果が発動！
みたいな。
さて、このゲームシステムを実現するに当たり、重要になってくるのが
三色のうちどれが光っていて、結果何色になっているのか
を判定するスクリプトである。

簡単。しかし手は動かない

簡単である。なにせ2の3乗で8パターンしかない。
ifでも書いておけば良いし、switchでも良い。
ちょっと格好をつけてクラスを作ってみるという選択肢はまだ持っていなかったが、いずれにしろ大した問題ではないことは想像していただけるだろう。一致していれば処理をする。それだけである。
しかし、しかしだ。その手は動かない。その後の処理はすでに書いてあるにもかかわらず、だ。

"プログラミング初心者を抜けた"
と自称するやつを待つ罠

その当時、そこそこプログラミングはできると思っていた。
いや、別にプロに通用するとかまでは思っていない。
「AtCoder何色？」とか聞かれたら泣いちゃう。そもそもやってない。
ただ、簡単なゲームプログラムなら(unityの偉大なる力と)自分一人で何とかなるとは思っている。友達の中でもまあ割と得意な方であると言っても過言ではなかったように感じる。
そういうことを思っているやつが先ほどの問題に当たると何を思うか。

if文の羅列で全パターン書くのはダサい

全パターン書く、というのはあまり推奨されていないように感じる。
コードの行数が増え可読性・保守性が落ちるといったことや、単純な抜け漏れなどを心配することもある。
何よりダサい。書いてしまったら数日は心に残る。

そんなことを考えていると、ふとロマンあふれる方法が浮かぶ。

「2進数使えるんじゃね？」

まあ確かにonとoffだしそんな気もする。
実際2の何乗とか考えてる時点で2進数の考えは使っている。
そう考えると、すべてのパターンを数字に置き換えたくなり、XOR使ったらなんかできんじゃね？とか考えたりし始める。
この間、コードは一行も進んでいない。

後でもう一度触れるが、別に設計に時間を使うのは悪いことではない。
ただ、この場合は時間制限を考えると素直にifを羅列したほうが早い。
実際、途中であきらめて素直に実装することにした。

       if (gMScript.backR && gMScript.backG && gMScript.backB)//1
       {
           if (Red && Green && Blue) wall.isTrigger = true;
       }
       if (!gMScript.backR && gMScript.backG && gMScript.backB)//2
       {
           if (!Red && Green && Blue) wall.isTrigger = true;
       }
       if (gMScript.backR && !gMScript.backG && gMScript.backB)//3
       {
           if (Red && !Green && Blue) wall.isTrigger = true;
       }
       if (gMScript.backR && gMScript.backG && !gMScript.backB)//4
       {
           if (Red && Green && !Blue) wall.isTrigger = true;
       }
       if (!gMScript.backR && !gMScript.backG && gMScript.backB)//5
       {
           if (!Red && !Green && Blue) wall.isTrigger = true;
       }
       if (!gMScript.backR && gMScript.backG && !gMScript.backB)//6
       {
           if (!Red && Green && !Blue) wall.isTrigger = true;
       }
       if (gMScript.backR && !gMScript.backG && !gMScript.backB)//7
       {
           if (Red && !Green &&! Blue) wall.isTrigger = true;
       }
       if (!gMScript.backR && !gMScript.backG && !gMScript.backB)//8
       {
           if (!Red && !Green && !Blue) wall.isTrigger = true;
       }

期間が終わってから、1週間ほどした深夜にふと
「あれはmod(剰余)かもしれない」
などと考え深夜テンションでチームのプログラム班にチャットを送ったのは別のお話…
え？そんなことせず単純に比較してあげればいいじゃないかって？
まあいいんですよそんなことは。

また別のチーム開発にて

さて、GGJが終わってもチーム開発は続く。
今度は大学の人たちと1か月くらいでプロトタイプの発表を目指した。
詳しいゲーム内容などは話がずれるので端折り、主にプログラミングの面に焦点を合わせたい。

コードがめちゃくそに汚い
コード単体もそうだし、それぞれのコードのつながり、
俗にいう設計段階からすでに汚い。
ちなみに設計を担当したのは私。一応エンジニアリーダー的な立ち位置になったので。

確かに、この開発は難しかった。
オンラインで動くゲームを、完全オンラインで開発しなければならなかった。今でも半分以上のメンバーと直接会ったことがない。(記憶がないだけかもしれないが)
それぞれのプログラミング能力も違うし、誰がどれくらい書けるのかもわからん。後で先生から聞いてみると実はめっちゃプログラムできる人でした、っていうパターンもあった。(その人には申し訳ない…)

しかし、それにしても汚い。
設計には時間をかけたつもりで、(実質一人だったかもしれないが)一応話し合って考えた。
が、今振り返るとその1時間かけて考えた設計はもはや設計ではなかった。
ふんわりとしか決まっておらず、詳細がよくわからないところも多い。
その結果、プロトタイプ発表までの2週間以上悩まされることになる。

コーディング技術に関する本

当然、なんの努力もしていなかったわけではない。
大学のプログラミングの授業はそこそこ真面目に受けていたし、
自分でコーディングの本も買って読んでいた。
そのうちの一冊はチームリーダに貸しつつ、自分は新しく買った本を読むなんてこともした。
(ちなみに「良いコードを書く技術」と「リーダブルコード」　両方良い本)
しかし、理解できていなかったのか意識できなかったのか、
少なくともチーム開発において生かされたようには思えない。
いや、読んでなかったら更にやばかった可能性はあるが。

なんやかんやありつつ、チーム開発は一区切りつき、少し時間ができた。
先日、先生の研究室に呼ばれ、そのついでにまた新しく本を(許可を得て)パクってきた。
読んでいてふと、今までの本と少し毛色が違うように感じる。
著者の主張が強いな、と。
どうやらこの本を書いた方はif文やswitchがあまり好きではないらしい。

確かに、なぜコードが汚くなるのかと言われればその原因の多くはそいつらかもしれない。また、代案として示される例に関しても納得できる。
一部本当に知らない技術も出てきて恥ずかしいが、大半の項目は
「まーそうだよね～」という気持ちになる。

基本的に、こういった類の本(あるいは記事)に書かれることは似ている。
丁寧に名前を付けよう、というところから始まり、スコープを小さくしたり関数を分けたりとそれほど目新しい情報も出てこない。
見方を変えると、それだけ重要な技術がはっきりとしていて、とりあえずやれ！という気もしなくはないが、ここで、新しい見方を提案したい。

考察：技術そのものは大切ではない？

たった3冊しか読んでいないやつが何を言う、と思われるかもしれないが、少し聞いてほしい。
中級者気取りが本読んで得た小手先の技術で何とかなる問題ではなくないか？
あくまでそんな気がする、という話に過ぎないため、ここまでだらだらやって最後それかよ？という話かもしれないが。
どちらかというと初心者がもう少し設計ができるようになるには、技術よりもその心の部分を気にしたほうが良いのではないだろうか。
単に技術を得ようと本を読むのではなく、

なぜ、それをすることが大切なのか考える

という作業のほうがむしろ大切な気がする。
そのこころがしっかりと染みついてようやく、実現するためにはどのような技術が使えるのかを考えることが可能になるように思える。
とりあえずと本を読み漁ったところで、使えるようにはならないようだ。

もう一度GGJを振り返る

ここまでを踏まえて、もう一度GGJを振り返ってみたい。
コードに対してロマンを求めること自体を悪だとは断言できない。
というか善も悪もない気がする。
正しく動作するものが、期限内に完成すればそれが全てかもしれない。
問題はゲームが思った通りに動かないことであり、
少なくともゲームジャムにおいてはコードは汚くてよい。

結論

独学(というか技術系の本を一切読まない状態)でプログラミング技術の向上を目論むのは少々無理がある。少なくともここに関しては車輪を最発明する前に一般人なら本を読む。
その際、技術ばかりに注目するのではなく、その「こころ」を感じることも念頭に置いてみると幸せになれるかもしれない。
また、プログラミングの授業なるものを大学で受けていたとしても、そこでSをとる能力と今回考えているコーディングの能力はベクトルが違い、絶対値もずいぶん差がありそうだと感じている。

自分から本を読むって大事ねホント。

というお話でした。
しょうもない結論でしたが最後まで長々と読んでいただき、ありがとうございました。