GIUを支える技術
この記事は KMC Advent Calendar 2019 - Adventar 7日目の記事です。
6日目の記事は id:dnek さんの推し絵文字・キャラデザ・モデラー・グループから探せるVTuber検索サイトを作った - DNEKです。
これからVTuber界隈をウォッチしてみたい！という人にはオススメのサイトとなっています。是非足を運んでみてください*1。
ごあいさつ
こんにちは。kmc-id: kata です。普段はゲームを開発したり、絵を描いたり、研究は大変だなあって思う事をしています。
本日は、部内専用のイラスト共有アプリケーション、God Illust Uploader(GIU) についてのお話をします*2。
あまりこういった記事を書く機会が無いため少し読み辛いかもしれませんが、お付き合いいただけると幸いです。
God Illust Uploader
God Illust Uploaderとは、3年前の2016年に僕が開発したWebアプリケーションであり、イラストをサーバー上にアップロードし、また、サーバー上のイラストをWebブラウザ上から簡単に閲覧できるアプリです*3。 主に部員が利用する事を想定しており、現在部内で動作している物は実際に部員しかアクセスできないようになっています。
現在では約80名の部員がイラストを実際にアップロードしており、アップロードされたイラストの総数は約1400枚にのぼります。
このアプリによって部内でのイラストの投稿や、イラストを介したコミュニケーションが盛んになると良いなと思って開発を行いました。
構成
GIUは次のような構成で開発されています。
- フロントエンド : jQuery(!!!!?!??!?)
- バックエンド(サーバーサイド) : sinatra + ActiveRecord
- データベース: SQLite
また、このサービスが立ち上がっているサーバーや、部員である事を確認する認証基盤は部内で既に使用されている物に乗っかっています。
jQuery
jQueryは言わずと知れた有名javasciptライブラリですが、フロントエンドの話をしている記事だとよくレガシーだのもう捨てようだのとやたらこき下ろされている印象です。
僕もどこかのタイミングで何らかのフレームワークを導入したい*4なと思ったまま、気づいたら3年が経っていました。とはいえ現在のこのアプリの規模だとわざわざそういったフレームワークを導入せずとも十分に書けるという所もあり、難しい所です。この辺りはただ勉強したいから、というような別のモチベーションで組み替えても良いかもしれませんね。
sinatra + ActiveRecord
sinatraはRubyで動作するWebアプリケーションフレームワークです。
類似の物で有名な物としてRuby On Railsというものもありますが、このsinatraというフレームワークはRoRと比べて構造を気にせずサクッと書けるのが特徴(のハズ)です。開発当初あまりその辺の知識が無かった僕に kmc-id: nonylene くんがオススメしてくれた事が使用したきっかけです。この場を借りて感謝申し上げます。
ActiveRecordは後述のSQLiteやMySQLといったSQLを用いたデータベースをRuby上から操作する際、あまりSQLの事を意識せずに操作できるRuby用のライブラリです。Ruby On Railsとの兼用が有名だと思いますが、sinatra上でも機能します。便利。
SQLite
部員のGIU上での情報だったり、イラスト毎の様々な情報を永続的に記録する為のデータベースとして、SQLiteを採用しました。この辺は特にこだわりが無く、当時の僕が知ってただけという感じのノリで採用を決めています。こちらも現在の規模感だとここまで厳格にする必要はなく、MongoDBのようなイマドキの気軽にイジれるDBの方が良いかもしれません。
KMCのサーバーと認証基盤
正直な所僕が書いた箇所はやればできるといった感じでそんなに重要では無く、こっちの方がよっぽどGIUを支える技術と言えます。気になる方は是非入部をご検討下さい。
他
KMCではSlackというチャットツールを用いて部内のコミュニケーションを図っているのですが、GIUにはイラストをアップロードすると任意でSlackの指定したチャンネルに自動的に投稿できるという機能があります。
これによりアップロードされたイラストに対してコメントをすぐ書いたり、SlackのReaction機能で"よさ"を表明したりと、イラスト周りのコミュニケーションが盛んになりました。 実はGIU本体にもコメント機能やいわゆる"いいね！"機能があるのですが、Slack上でのやり取りの方が気軽で素早いので、全く使われなくなってしまいました。まあSlackを用いるなら要らないかもしれません。
ちなみに、投稿の際にはGyazo gemを用い、Gyazo経由でサムネイルの投稿を行っています。
また、現代では当然と言っても良いかもしれませんが、バージョン管理サービスとしてGitとGitHubを利用しています。
ずっと僕一人が管理しているようなリポジトリでしたが、ここ最近になって先輩部員の方や後輩部員の方からPRが飛んでくるようになり、様々な問題を抱えていたこのサービスも少しずつ改善されていっています。とても嬉しいですね。
あとがき
さて。これまでは僕がそんなGIUを管理*5していたのですが、気づけば僕も6年目という事で卒業が近づいてきております。 卒業後もスキを見つけてGIUを管理していく事はできなくもないかもしれませんが、せっかくなのでさっさと後輩に委譲したいなあと思い、この記事を書くに至りました。
KMCの後輩の皆様には是非この記事を読んでいただき、GIUの維持、あるいは新たな部内専用イラスト共有アプリを開発していただけたらなあと思います。現代では参考になるサイトはいくらでも見つかりますし、周りには頼れる部員もいますので、初心者でももっと良い物を十分に作り上げる事ができると思います*6。是非挑戦してみてください。
今年の記事は以上になります。
KMCM
KMCの入部資格に制限はありません。受験生や社会人でももちろん入部できます。遠方にお住まいの方でも入部できます。Slackでおしゃべりするだけでも大丈夫です。コミュニケーションしませんか？ 興味がある方はメールやDMで入部希望の旨を連絡してください。見学もできます。
あと、Slackの共有チャンネルのお誘いもお待ちしております。 優秀な人材が集まる学生団体とコネクションを張りませんか？
次回予告
次回は kmc-id: kyp さんの「何か書けるはず……」です。この方は部員の中でも屈指の人生経験の持ち主ですので、記事の内容が楽しみです。よろしくお願いします。
あわせて読みたい
KMCでは今年、他にも二つのアドベントカレンダーを進行中です。
是非ご覧下さい。
現在開発中のゲームの話
これはKMCアドベントカレンダー22日目(？)の記事です。気付けば今年のアドベントカレンダーももう終盤ですね。
はじめに
はじめまして。kmc-id:kataです。京大マイコンクラブとあくあたん工房というサークルに所属しています。
最近はアドベントカレンダーに嬉々として登録し、直前になって書く内容が無いと周りに漏らし、結果記事を落とすという超絶厄介な活動をしています。ごめんなさい。
また、現在Clocklockというゲームを開発しています。デジゲー博2018に参加したりもしました。
Clocklockとは？
Clocklockとは、一言で言うと時を止めて障害を突破しながら進む2D横スクロールアクションゲームです。
プレイヤーは主人公を操作し、様々なギミックや敵が配置されたステージを駆け抜けていきます。
開発にはUnityを使用し、サークル内の10人程のメンバーと共に開発しています。
今回は、そんなClocklockというゲームを開発する上で困った点とその改善方法を一つ書けたらなと思います。
開発上の問題
今回、Clocklockというゲームを作る上で一つ重要な仕様として掲げたのが、「ステージは全て繋がっている」という点です。 つまる所、某のカービィや某ーパーマリオブラザーズで用いられているような、扉や土管といった暗転等を要する移動手段をなるべく用いず、なるべくステージ内でのプレイヤーの操作不能時間を減らそう、という事ですね。 某ックマンを想像して下さると良いかもしれません。
この仕様の善し悪しについてはひとまずこのお話の対象外として、Unityでこの仕様を実装する為に最も簡単な方法といえば、ステージに存在するオブジェクトを全て1つのシーン上に置く、という事が考えられます。
……まあ、そんなテキトーな感じで管理できる訳がありませんよね。
1ステージが非常に小さい場合はともかく、今回の様に数画面必要とするようなステージを開発する場合は、ゆうに百を超えるオブジェクトが一つのシーン上に配置される事となります。 さらに、それぞれのオブジェクトは異なる挙動を持ち、それぞれのオブジェクトに対して当たっているかどうかの判定や物理演算を行います。 到底人間が全てを管理できるはずもありません。
他にも、処理速度の問題があります。 処理速度とステージの規模はトレードオフの関係にある、と決め付けてしまえば楽ではありますが、この状態ではあまりにもすぐステージの規模に限界がきてしまい、十分にレベルデザインを行う事ができません。
解決
この問題を解決するために、我々はUnityのマルチシーンエディティングという機能を利用する事にしました。 マルチシーンエディティングとは、複数のシーンを同時に読み込む事が可能となるUnityの機能の事です。
参考にしたのはこちらの記事です。(Unity5.3時点での記事なので注意)
今回の開発において、一つのステージは、唯一のシーンによって構成される訳ではなく、ある程度のオブジェクト数毎に分割したシーンを複数読み込む事によって実現される、というように定義しました。 また、そのシーン毎に分割する単位の事を、セクション、と呼びます。
で、このセクションを複数読み込む事でステージを表現するのですが、何も考えずに全て読み込むと結局元のままですよね。 そこで、進行状況に合わせてセクションを逐次読み込む事によって、同時に存在するUnity上のオブジェクトの数を減らし、処理を軽くしようとしました。
と、こんな感じに逐次読み込みしています。
この機能が実装された事によって、我々はステージを開発する際に、一つのステージ単位で開発を行うのではなく、一つのセクション単位で開発が可能になりました。 例えば、一つのステージが八つのセクションによって構成される場合、一度に管理しなければならないオブジェクト数は単純に計算して8分の1となるのです。文明の進歩です。
また、処理速度の面に関してもこの試みはある程度は成功していて、多くのオブジェクトを含む、規模の大きいステージにおいても、適切にセクションが区切られてさえいればフレームレート等が落ちる事なく動作するようになりました。
今後の課題
先程の章で「ある程度は成功」と書いたのですが、まだまだ改善しなければならない点はあります。
上記の他セクションの読み込みや破棄はセクション切り替えの際に行われるのですが、その際に少しだけカクついてしまうのです。
なんとなく察されている方も多いとは思いますが、つまり、次セクションの読み込みや必要無くなったセクションの破棄にかかるオーバーヘッドが誤魔化しきれていない、という課題が残されているんですね。
雑に調べた感じではリソースのキャッシュ周りを良い感じにしてやればもうちょっとマシになるのかなーと思います。 まあ、他の作業もまだまだ残っているのでいつ取り掛かれるのかはちょっと分かりませんが、体験が向上する事は間違いないので頑張りたいですね。
余談
この機構を採用する事によって得られた利点がもう一つあります。 それは、それぞれのセクションが独立して開発可能になった、という事です。
たとえば、セクションA -> セクションB -> セクションCという状態の中セクションBの長さを変更した場合、 一つのシーン上に全てのオブジェクトを配置するこれまでの設計では、セクションBに引っついているセクションAとセクションCについても調整が必要となっていました。
しかし、この機構を実装した事により、セクションBでの変更が、接続されている他のセクションに影響を与える事が少なくなりました。
この事により、既に完成しているセクションを編集する際のコストが大きく減り、また、一つのセクションの開発者が他のセクションの事をあまり気にしなくとも良くなった為、チーム開発による並列開発の利点をより享受しやすくなりました。 開発をしている身としてはいっその事管理のしやすさや処理速度うんぬんというよりこちらの方が嬉しかった事かもしれません。
まあ、今思えばそんな地獄みたいな環境で開発を続けていた事自体がウソのようですが……。
おわりに
さて、そんな感じで現在開発中のClocklock、遅くとも来年中には何らかの形で公開できると思いますので、楽しみにお待ち下さい。今後開催されるゲーム系のイベントでも少しずつお見せできればなと思います。
明日の23日(？)はkmc-id: kazakamiさんによる、今作ってるゲームエンジンの話です。 ……おや？何と既に記事があるようです！素晴らしいですね。
また、KMCではお絵描きアドベントカレンダーもやっています。僕は参加していませんが、こちらもよろしくお願いします。
あ、あくあたん工房アドベントカレンダーもよろしくお願いしますね。僕の記事は読み飛ばしていただいて結構です。
それでは。
ツイートで振り返る自転車で琵琶湖一周
この記事は KMC Advent Calendar 2017 - Adventar の1日目の記事です。このカレンダーの内容はkyp(id:kypa)さんの尽力によって下の記事に逐一まとめられるので、良ければ参照してください。kyp(id:kypa)さん、がんばってくださいね。
昨日の記事はkyp(id:kypa)さんの国際音声記号を爆速で打ち込むウェブアプリ（もどき） - 蛍光色に浮かばない寿司です。
ソースコードを見てみると、
/ どうにかしたい /
/ コピペ あとでどうにかする /
といった心温まるコメントが点在しており、Webアプリ開発者としての苦悩が感じられます。
ごあいさつ
みなさんこんにちは。KMC4回生のkataと申します。
今年もアドベントカレンダーの季節がやってきましたね。
12月、年末ともなると身の周りから忙しい忙しいという声がよく聞こえるようになりますが、自分も例に漏れず、 卒論やその他の原稿でてんやわんやとなっています。
とはいえ大学生というものは不思議なもので、こういった様々な締切が差し迫っている時にこそ、息抜きを求めてしまいます。
そんな訳ではりきって書いていきたいと思いますので、よろしくお願いします。
さて、私事ではございますが、自分は今年、古くなった自転車を処分し、自転車を買い替えました。
普段だったら安めのママチャリをまた購入する所ですが、 大学に入ってから様々な都合で自転車に乗る機会が多くなったので、これを機にクロスバイクにしました。 購入した時には何よりもその軽さに感動したものです。
こうなると、自分は新しい物を買うとすぐに使いたくなってしまう人なので、このクロスバイクで何かしたいなーと考えます。
当時は10月。夏が終わり、風が心地良い涼しさを運んでくるようになってきた季節。 研究にも行き詰まり、どこか自分探しの旅にでも出てしまいたい気分。しかし遠くに行ける程のお金も無く、あるのは新品のクロスバイクのみです。
自分には、琵琶湖一周、通称ビワイチしか思い浮かびませんでした。
そんなワケで、ビワイチを2度完走した経験のあるmurataくん(id:chy72)を誘い、ビワイチへと出発したのでした。
一日目
10月8日の午後1時。 僕らはスタート地点である大津港を出発し、ビワイチへの挑戦をスタートしました。
当日二人とも寝坊をしたり、琵琶湖へと向かう道を間違えたりとトラブルが多発した結果、予定の午前7時スタートからおよそ6時間遅れてのスタートです。 先行き不安ではありましたが、まあ二日あればゴールはできるだろうという甘い考えの元に強行を選択しました。
スタート直後のツイートです。軽い冗談も飛ばし、非常に元気そうですね。
途中ピエリ守山でたまたま近くに来ていたななさん(id:nna774)や動物に癒されながら、8時間後の午後9時、初日の宿に到着します。
出発当初の元気はどこへやら、愚痴ツイートの連発です。 想像以上の過酷さに、完全に身も心もノックアウトされてしまったようです。
というのも、完全に日が沈んだあとのビワイチのコースというのは、街灯がほとんどなく、頼れるのは自転車に搭載した頼りないフロントライトと、時折車道を通る車のライトだけ。 さらに、対向車線から自動車が来た場合は、その迫ってくる光のお陰でほとんど何も見えません。 走った事の無い道で、どこに危険があるかも分からないので、日没後の走行は常に精神を摩耗しながら行っていました。
ビワイチの走り方指南サイトでは必ず、日没後の走行は危険なので止めましょう！と書いてあった理由を、ここにきて初めて文字通り痛感したのです。 皆さんもビワイチに挑戦する際、日没後の走行は避けるようにしましょう。
ところで、この一連のツイートで触れられている道端コーディングというワードについてですが、これは相方のmurataくんが行なったものです。
彼はビワイチと同じぐらい競技プログラミングも嗜む多才な人なのですが、なんと、不運な事に、今回のビワイチととある競技プログラミングの大会のオンライン予選が被ってしまったのです。
しかし、我々には、スターバックスなどに代表されるコーディングに最適な場所を探すような時間はありません。 そこで、彼はビワイチの途中、予選が始まったタイミングで一度自転車を降り、どのような場所であってもその場で参加を行うという決断を致しました。
結果、運悪く山中の道端でコーディングを行うという事になってしまったのです。
とはいえなんとか無事にホテルに辿り着いた我々は、部屋に備えつきのバスタブでお風呂に入り、ホテルの自販機で購入した氷結で明日に向け乾杯を交わし、就寝しました。 疲れ果てて動く気力もない僕の代わりにmurataくんの入れてくれたお風呂は、燃えるように熱かったです。
二日目
二日目はとにかく無言で必死に自転車を漕ぎ続けました。 というのも、予算の問題でこれ以上の泊まりは厳しいという事、また一泊二日で一周するにしては彦根は中継地点として早すぎたからです。
結局の所、全行程の三分の二程度はこの二日目で走り切る事となりました。
滋賀県には琵琶湖以外にも様々な観光スポットがありますが、スケジュールの都合上、我々はそれらを堪能する余裕はありませんでした。
手首は度重なる振動でボロボロ、脚部はペダルを一踏みする毎に痛みを訴え、口からでるのはこのような愚痴ばかり。murataくんは、そんな僕の横で笑いながら自転車を漕いでいました。
そして10月9日午後3時45分、ついに琵琶湖大橋の両端を制覇しました。
昨日のピエリ守山から見ていた琵琶湖大橋の反対側に辿り着いた、という事実は、我々が琵琶湖大橋で区切られた琵琶湖の北側部分を完全に周り切った事を意味します。
後は大津港まで一直線に走り切るのみ。
終わりが見えてきた嬉しさに、上がらない肩を無理して上げ、凄く嬉しそうなツイートをしています。murataくんは、そんな僕を笑いながら祝福していました。
そしてビワイチ挑戦開始から約28時間後の10月9日午後4時39分、我々はスタート地点であり、そしてゴール地点でもある大津港へ到着しました。
道中、あまりにも疲れというものを見せないmurataくんに時折恐怖を感じる事もありましたが、 一緒に走ってくれる人がいたからこそ走り切る事ができた、という事実には間違いはありません。 恐らく、一人であれば、ピエリ守山に到着した時点でやっぱり北はいいかな……と琵琶湖大橋を渡っていた事でしょう。
ありがとう、murataくん。次はちゃんと二泊三日で計画を立ててビワイチに行きましょう。
それでは、最後に二人のビワイチ完走後の感想ツイートを並べて今回の記事を締めようと思います。
長文をお読みくださり、ありがとうございました。
次回予告
KMCアドベントカレンダーの2日目は、utgw(id:utgwkk)さんで内容は「はい」です。 平仮名ではい、と言えば皆さんは何を思い浮かべるでしょうか。
私は、やはりFC版wizardryです。
自分はそもそも全くもって世代では無いのですが、かつてレトロゲームにハマっていた頃に触っていた記憶があります。手塩にかけて育てたキャラたちが、些細なミスで灰になり、そして運次第でロストする。インパクト溢れるそのシステムに、当時のゲーマーはこんなものをやっていたのか……と衝撃を受けたものです。
しかしきっと、それだけ印象に残るようなシステムだったからこそ、現代でもフォロワーが登場するほど愛されるゲームになったのだと思われます。
そんなワケで、明日の記事にはutgwくんのwizardryプレイ日記あたりを予想しておきます。よろしくお願いします。
PR
KMCでは、もう一つグラフィック班を中心にアドベントカレンダーを行っております。2日目の担当はrmasakiさんで、なんと5日目まで5日連続で担当が入っているようです！とても楽しみですね。
ちなみに僕も12月23日に参加しています。
また、KMCではあらゆる部員をいつでもどこでも募集しています。屋外でコーディングをしたことがないあなたも大歓迎！年齢も所属も性別も人種も何一つ問われない素敵な団体ですので、少しでも興味を持ったあなたは今すぐ下のリンクから入部案内をご覧ください！
