kugi's notebook

やったこと、思ったことなどつらつらと書きます

JPHACKS2020参加レポート~Miro大活用とフラクタルスプリントへの挑戦~

はじめに

こちらは

の記事です。(片方遅刻してしました...ごめんなさい🙇‍♂️)

今回は10月末から11月末にかけて行われたJPHACKS2020の参加レポートになります。

昨年に引き続き、2年目の参加です!!昨年の参加レポートはこちら💁‍♂️

kugi-masa.hatenablog.com

昨年はCammelリーダーのtyanioと私の2人で出場していました。 今年度は私にとって学生最後の年、Cammelみんなでハッカソンに出たいという私の強い想いもあり、チーム7人で出場することになりました。

(完全に余談ですが、最近Cammelのページが公開されました🎉)

今年はオンライン

今年のJPHACKS(ジャパンハックス👈ジェーピーじゃないですよ!!ここ重要)はCOVID-19の影響もあり、フルオンライン開催でした。

今年に入ってオンラインのハッカソンに参加したり、主催したり(笑)オンラインハッカソンは初めてではありませんでしたが、参加者およそ400名のここまで大規模な学生ハッカソンをオンラインで実現できるのは、やはりJPHACKSだからこそだなと感じました。

オンライン開催とのこともあり、昨年とは異なり、Hacking Sprint(実際にプロダクトを開発する期間)は2Dayではなく1Weekに。そして、Hacking Spritの前には運営のみなさんによるLearning Sprintという環境構築やチーム開発などの学習イベントが開催されました。

アイディアソンワーク

私たちCammelはアイディアソンワークに参加し、Miroを使ってアイディアの分散・発散・収束について学びました。

f:id:kugi_masa:20201217000630p:plain
ハッカソン」を中心にマンダラートを作成しました。(草が生えたw)

また、出たキーワードから9つのキーワード(転用、応用、変更、拡大、縮小、代用、置換、逆転、結合)を元にさらに発散させる「オズボーンのチェックリスト」はとても学びになりました。全く想像していなかったアイディアが出るので、既に出たキーワードやアイディアからさらに発展させる指標としてとても良いなと感じました。

オズボーンのチェックリストとは?|経営キーワード集 | オンライン創業スクール・Zoomセミナーの講師をお探しならジャイロ総合コンサルティング

その後は、アイディアを収束へ。出たアイディアを元にイメージ図やターゲットユーザ(ペルソナ)について考えていきました。

f:id:kugi_masa:20201217001945p:plain
なんだこれは...

準備期間としてこのようなワークイベントを開いていただけてとてもありがたかったです。日程の関係で参加はできませんでしたが、他のワークにも参加してみたかったです。

1Weekの開発

Best Team Collaboration Award

受賞項目がたくさんあるJPHACKSですが、 今年からBest Team Collaboration Awardという賞が追加されました。こちらの賞は「チーム開発実践入門」という書籍を元に採点項目が設けられ、それらの合計点数の最高得点を獲得したチームに送られる賞でした。

アジャイルの理念を取り入れて開発すること目標として掲げ、これまで開発を行ってきたCammel。 そして、そこでスクラムマスターのような立ち位置でこれまでアジャイルをチームに共有してきた私としては非常に獲得したい賞でした。

採点項目として以下のようなものがありました。(以下の項目は一部)

  • [バージョン管理] チームメンバーの複数人がリポジトリに登録された(チームメンバー)
  • [バージョン管理] 一度でもチームの誰かがリポジトリのmain(master含む)にソースコードをコミットした
  • [チケット管理] Issueが登録されている
  • [CI/CD] SlackにGitHubやCIのログ等をインテグレーションしている

毎日その日までのチームの点数がslackのリーダーボードチャンネルに流れるようになっていて、コンテスト感がありとてもワクワクしました。

f:id:kugi_masa:20201217004340p:plain
slackのリーダーボードチャンネル

各チームのプロジェクトの情報は全てGitHub上に公開されています。 その日の上位のチームが何をしているかの調査をするためにも、上位チームのリポジトリ情報をチームのチャンネルに流すなどしていました笑

f:id:kugi_masa:20201217005057p:plain
前回からの変動に+をつけました

結果的には4位と受賞は逃してしまいましたが、今回のBest Team Collaboration Awardを期に挑戦してみた内容(CI/CDなど)もあったのでチャレンジできてよかったと思います。

Miroを活用してデザインのモックを作って共有したり、うさぎ組のkyonさんのフラクタルスプリントを参考に開発に取り入れてみたりしていたのでそういった点もアピールして評価してもらいたかったなとも思いました。 (自動採点で無くなったら運営のみなさんが鬼大変になってしまうとは思いますが...笑)

kyon-mm.hatenablog.com

Miroを活用

今年は各チームごとにMiroのボードを用意していただきました。 普段の開発でもMiroは使っているのでみんな使い方には慣れていましたが、1週間の開発でフラクタルスプリントにも挑戦してみたので、より使いやすいように以下のような決まりを作りました。

  • 付箋のサイズは基本的に「Mサイズ」!!!
  • 背景パネルは必ず「ロック
  • 付箋の「」に意味合いを持たせる
  • エリア」を分けて活用

f:id:kugi_masa:20201217011901p:plain
付箋のサイズはM!!!

Miroの付箋のサイズは任意に変更できますが、明示的にS・M・Lと固定することもできます。Miroは割と広めにスペースを取れるので、必ずMがいいというわけではありませんが、サイズに基準を作っておくことに意味があると感じました。これはボードを見ている時の倍率(右下の%)を自然と合わせるためです。Miroは簡単にマウスのスクロールなどでズームイン・ズームアウトができてしまいます。他のメンバーのカーソル位置は表示されているのでどの位置で作業をしているかわかっても、付箋のサイズがバラバラであれば、同じ視点から見たボードが共有しづらくなります。

f:id:kugi_masa:20201217012551p:plain
背景パネルはロック

普段Miroを使うときは領域を分けるために「背景パネル」を置いています。ここで重要なのが錠前マークでロック🔒することです。ロックをしておかないと付箋などの移動の際に背景が動いてしまってフラストレーションが溜まってしまいます😤。

f:id:kugi_masa:20201217012849p:plain
自分の色はコレダァァァァ!!!

1週間同じボードを使うため、毎回「コレ誰の?」とらないように自分の使う色を予め決めて付箋を使うことにしました。

f:id:kugi_masa:20201217015350p:plain
エリアを分けて活用!!

また、今回は進捗管理やモックの共有、バックログ管理などもMiroで統一して行ったので作業場所をわかりやすいように分けました。

フラクタルスプリントへの挑戦

基本的に開発はDiscordで通話をしながらGoLiveでのモブプロやペヤプロ、デザインチームはMiroを使ってモック作成を行いました。

f:id:kugi_masa:20201217020215p:plain
1Dayボード

今回のハッカソンでは、1WeekSprint >> 1DaySprint >> 1HourSprint のフラクタルスプリントで取り組んでみました。

1HourSprint

まずは最小単位の1HourSprintでは、1時間ごとにできそうだと見積もったタスクをTODOに列挙し、1時間終わったら振り返りします。ハッカソン中は学業との両立もあるのでこの1HourSprintは作業できる人ができる時間にバックログからタスクをとってやっていきます。

実はハッカソンの序盤が学会と丸かぶりしてしまい、最初の数日は開発できませんでした。 その分空いた時間でMiroを覗いたり、夜の進捗共有には参加して困り事を洗い出すなど、本当にスクラムマスターのような立ち振る舞いをしていました。(意外と見るだけならスマホ版のMiroも良さげでした👀)

今回1HourSprintに挑戦したいと提案してくれたメンバーからは以下のような前向きな意見がでています。

  • 1時間で強制的に手を止めるので気持ち新たに次の1時間に挑める
  • 途中で参加した人も何をやっていたかがすぐにわかる

1DaySprint

1日の区切りとしてだいたい18:00~18:30の時間でDailyScrum(朝会ならぬ夜会)を開きました。DailyScrumでは以下のようなことを行いました。

  • 進捗共有
  • 困り事、心配事の解消(ここでモヤっと🦠をスッキリに✨)
  • バックログリファインメント
  • 次の1DaySprintですることの確認

DailyScrum後にそのまま作業することが多かったですが、一応1Dayの区切りはDailyScrumとして、DailyScrum以降は次の日の1Dayボードに移動して作業しました。

1WeekSprint

この1DaySprintをHackingSprintの七日間繰り返すことで1WeekSprintとしました。

作ったプロダクト name_it

ここまではチームとしての1週間の取り組みについてでしたが、ここからは作ったプロダクトについてお話ししたいと思います。

まずは、デモ動画をご覧ください。

www.youtube.com

name-it-38fb8.web.app

name_itは自分が悩んでいる変数名やメソッド名を投稿し、 みんながアンケートに投票や更なる選択肢の追加などを行ってよりよいネーミングを共有していくエンジニア支援サイトです。

元々は気軽にコードレビューをもらえるサイト感情日記という自分のその日の感情を色として日記に記録できるアプリの2つでアイディアがわれていました。そこで、挙げられていた3つの評価基準([問題着眼点・着想点]、[実行・実現可能性]、[完成度・動作性])に着目してさらに深堀をしていく中で、変数命名を投票で決めるというアイディアが生まれました。

「感情どこ行った...??」という声が聞こえて来そうですが、 感情日記はハッカソンで作るのではなく、時間をかけて普段の開発で作りたいねという話もありコードレビュー寄りのアイディアになったという裏話もあります。

f:id:kugi_masa:20201217022956p:plain
投票で最終的に変数命名投票サイトに

Twitterで実際に変数の命名などで時間をかける人がいるかなども予め調査をしました。

結果としては、予選落ちでFinalistAwardへは進出できませんでしたが、動くものを1週間で作りきれたことフラクタルスプリントという新しい取り組みに挑戦できたことは私たちチームとしてとても価値のあることだったと思います。

フィードバックでもいただいたように、「回答を投票する側のメリット」や「命名に悩む人はすぐに回答が欲しいのに待たなくてはならない」といったユーザの視点、実際使ってもらう人の視点を踏まえた機能を早い段階で取り入れるべきだったと思います。

f:id:kugi_masa:20201217024517p:plain
1週間のバックログ

まとめ

これまで2年間Cammelでアジャイルの手法を取り入れ開発を行ってきて、スプリントをまわす習慣やモブプロ、振り返りなどは身についてきたと今回のハッカソンで実感できました。そしてハッカソンを通して、私たちのチームの弱点は私たちのプロダクトを使うユーザプロダクトをどのように、なぜ使うのかという点を踏まえて開発する力が弱いことだと感じました。開発が進んで行くにつれ、私たちのプロダクトのペルソナが「プロダクトを求めるユーザ」ではなく「プロダクトが求める、プロダクトありきのユーザ」になってしまっていたと感じます。(今回の例だと、私たちのユーザは「回答が来るまで辛抱強く待てる人」と思ってしまっていた)

これは特に最初のペルソナ定義が曖昧のまま開発が進んでしまうと、尚更陥りやすいことだとも思いました。 時間のないハッカソンの場合は最初に時間をかけて物事を決めたり、途中で手を止めてプロダクトの根幹の部分を見つめ直して手戻りするということはなかなかやりにくいと思います。しかし、使ってもらうものをユーザに届けるためにはプロダクトのペルソナを考えて開発することは非常に大切です。早い段階で一度手を止めてプロダクトについて見つめ直す時間(ドッグフーディング🐶)ユーザについて考える時間をとることがハッカソンでは重要になってくると改めて学ぶことができました。

また、今回挑戦したMiroの活用法やフラクタルスプリントのエッセンスは今の開発にも活かせていると思います。

Finalistに2連続で進出できなかったことは悔しいですが、結果が全てではありません。 今回メンバーには少々無理を言って全員参加に踏み切りましたが、全員参加できてよかったと言ってくれて嬉しかったです。 学生としてのCammel最後の年度に(先日引退はないよと言われました笑)本当にいい思い出ができたと思います。 メンバーには感謝です。

そして運営のみなさんも本当にありがとうございました!!! (オフ会わいわい楽しかったです笑)

私は今年度で修了しますが、残り5人は来年度まで学生です。 来年もJPHACKSに出場するかはわかりませんが、私としては出て欲しいですね笑

やったこと

  • チーム全員でハッカソンに参加してname_itといい思い出を作った

わかったこと

  • チームの弱点が見つかった

次やりたいこと

  • チームの弱点をチームで補っていく

unity1weekにチームで参戦するために2monthかけて準備した話

はじめに

こちらの記事は Unityゲーム開発者ギルド Advent Calendar 2020の11日目です。

(本日アドベントカレンダー2回目笑)

私はUnityゲーム開発者ギルド(通称: UGDG)に2ヶ月ほど前に参加しました。

ギルドに参加したことで今まで以上にUnityに触れる機会が多くなり、メンバーの方から刺激もたくさんいただいています。また、気軽に話しかけてくださる方が多く、コメントにスタンプで反応してくださったり、とても暖かいコミュニティだと感じています。また一緒にゲームしたりDiscordで雑談したりすることも増え、いいことづくしです!

UGDGのアドカレなので、この記事では「unity1weekにチームで参戦するために2monthかけて準備した話」について書きたいと思います。

チームaojilu

f:id:kugi_masa:20201210211427p:plain
チームaojilu

チームaojiluは同じ大学のaojiluくん、SilCilさんと私の3人からなるチームです。

aojiluくんのツイートがきっかけで集まりました。

f:id:kugi_masa:20201210202359p:plain
3人集まるきっかけとなったaojiluくんのツイート

aojiluくんとSilCilさんはGSD(大学のゲーム制作同好会)に所属していて、aojiluくんは私がメンターをしていたときのenPiT2019で一緒、SilCilさんはu1wでTwitterのFFという関係性でした。

初日はZoomで3人で顔合わせをしました。 Zoom無料プランの40分制限があったので、40×4回笑笑。「第4回ミーティングよろしくお願いします〜」と回を重ねるごとに初日で3人の心理的距離は縮まりました。

それ以降は主に以下のツールを使ってミーティングをしていきました。

  • Discord: 通話用
  • Miro: アイディアボックス(オンラインホワイトボード)
  • UDGDのScrapbox: 議事録とギルドへの知見共有
  • GitHub: コード共有、タスク管理
  • Slack: チームチャンネルでわいわい🙌

私たちは3人ともプログラマなので、ゲーム制作におけるプログラマ分業という修羅の道への旅が始まろうとしていました...。

unity1monthやってみる

一緒にチームで開発したことのない3人でいきなりu1w挑戦となるときっと大変だ!!と思ったので、まずは1weekを1monthにのばして3人でアイディア出しからゲームを作るところまでやってみることにしました。お題をTwitterで募集したところ、「重力」というお題をいただきました。 ひとまず次のミーティングまでに各々考えて、アイディアを持ち寄ることに...

f:id:kugi_masa:20201210203245p:plain
お題をTwitterで募集

aojiluくんとSilCilさんはこれまでGitHubあまり使ってこなかったとのことだったので、Miro & GitHubハンズオンを行いました。 その後、いただいたお題「重力」を元に持ち寄ったアイディアを深堀していく形で作るゲームの企画を固めていきました。

f:id:kugi_masa:20201210202720p:plain
アイディア出し

画像からもわかるようにMiroでわいわい絵や図を書いたりして盛り上がりました。 しかし、企画を決めるにあたって何を軸に決めたらいいかわからず、アイディアが分散してしまいかなり時間がかかってしまいました。 (アイディア出し自体はわいわいできてとてもよかったと思っています)

最終的に、「迷わずに答えられる面白さ」がはっきりしている企画、3人が話し合ってこのゲームの「面白さ」はここだよね、と言えるものを軸に考えることにしました。

f:id:kugi_masa:20201210204054p:plain
迷わずに答えられる面白さ

そうして決まったのが

「アイテムを集めながら星から星を飛んで移動しゴールの星を目指すゲーム」

Gravity Planet

です。

github.com

結論から先にお話しすると、このGravity Planetは最終的にゲームにはなりましたが、unityroomにリリースするまでには到達できませんでした。

ここでは最終的に出来上がったものと、取り組み方や反省点などを、unity1monthが終わったタイミングに戻った気持ちでKPT(KEEP・PROBLEM・TRY)で振り返りたいと思います。 (現在の振り返りではありません)

KEEP

  • モブプロベースで進めることで知見の共有ができた(Cinemachineはじめて使ってみた!!)
  • ミーティング中に疑問点や進め方にモヤッと感じたタイミングで疑問点の解消、モヤッとをすっきりにもっていく合意タイムが取れてよかった(aojiluくんモヤッと報告ナイスでした👍)
  • CloudBuildでビルドコストをなくせた
  • メンバー間の心理的距離が縮まった

PROBLEM

  • コーディング規約が曖昧で設計、依存関係が大変なことに...
  • 企画決めに決まった流れが欲しい
  • 今の感じだと1monthでも厳しかったので、1weekもつらいことになりそう...
  • Issueでタスク管理はコストの割に旨味がない(u1wだと特に)

TRY

  • 設計の指標がほしい(TRYか...??🤔)
  • Gravity Planetの設計を見直す会をしたい
  • 企画決めの流れを作りたい
  • 1週間をという期間を踏まえてもう一度企画からやってみたい

SilCilSystem導入

さて、Gravity Planetの振り返りが終わりTRYでも出た「設計を見直す会」をやりました。

SilCilさんが用意したクラス図をもとにSilCil'sオススメ設計を教えていただきました。

私たち3人の中では明らかにSilCilさんが設計マスターです。

f:id:kugi_masa:20201210213558j:plain
設計の話をしよう

それから何回かミーティングを重ね、SilCilさん主導で設計の指標となるテンプレートリポジトリ(Unityプロジェクトのテンプレート)SilCilSystemを作ることになりました。

なんとSilCilさんお手製のドキュメントもあります!!!!

u1w以降、落ち着いたタイミングでSilCilさんの方からもSilCilSystemの振り返りブログを書くとお聞きしているので詳しい内容はこちらでは割愛します。 (というより、私は説明しきる自信がありません...😂)

aojiluくんと私はというと、このテンプレートリポジトリを使って実際にゲームを作ってみて使い方に慣れようとしています。

実は別のイベント(LT駆動開発。発表はMomijiLT#3にて。12/13(日)18:30〜です。YouTubeLiveにて配信します)で作って昨日しれっとunityroomにアップしたこちらのゲームもこのSilCilSystemをテンプレートにして作ったものです✨

チームaojiluにおける理想的な一週間の流れ

そしてSilCilSystem制作と同時並行で残りのTRYである「企画決めの流れづくり」「一週間を踏まえてu1wの素振り」に取り組んでいます。

まずは理想の1weekの流れについて話しました。

f:id:kugi_masa:20201210220452j:plain
チームaojiluにおける理想的なu1w

unity1monthでは、CloudBuildを使うことで、main(master)ブランチにマージされたタイミングでビルドが走りDiscordのCloudBuild用のチャンネルにビルドがアップされるようしたので、u1w本番でも同じようにするのが望ましいです。

f:id:kugi_masa:20201210221530j:plain
CloudBuildはいいぞぉ

しかし、それぞれ一週間ずっとつきっきりというわけにもいきません。 一週間の流れの画像にもあるように、チームaojiluでは毎日夜集まり以下の流れでu1wに取り組むことにしました。

  1. お題が出てから初日のミーティングまでにお互いアイディアを持ち寄る
  2. 初日のミーティングで企画を決め切りやるべきタスクを洗い出す
  3. 初日以降はそのタイミングでの最新のビルドを遊んでどうゲームをカイゼンしていくかを決める
  4. タスクを洗い出して次のミーティングまでコミット(コミット内容は同期が取れるようにslackで適宜共有)
  5. 最終日まで3. 4. を繰り返す

こう見てみるとなんかu1wやっていけそうな気がしますね!!!

とはなりませんよね笑

KPTPROBLEMでも出たようにunity1monthのアイディア出しでは決まった流れがなく、話が分散し時間がかかってしまいました。そこで私たち3人は理想の企画決めの流れを探るべく、ジャングルの奥へと向かいました。

企画決めの流れ

まず前回お題の「重力」をもとにそれぞれ事前にアイディア出しをし出たアイディアを共有するということをやりましたが、フォーマットがバラバラでアイディアの説明も人によって時間をとったり取らなかったりとまちまちでした。

一週間しかないu1wにおける共同開発(チーム開発)では意思決定の早さが非常に大切になります。そこで私たちは、EMS フレームワークを持ち寄ってそれを共有することにしました。 (EMSフレームワークのついては以下を参照) gamebiz.jp

そして、素振りの試行錯誤を2回繰り返し、最終的にこれならいけそう!!という流れにたどり着きました。(ジャングルの奥に宝はあった!)

f:id:kugi_masa:20201210230515j:plain
割とうまくいったアイデア出しの流れ

付箋の左の時間は実際に素振りをやってみて妥当だと見積もった時間です。

f:id:kugi_masa:20201210230544j:plain
お題「打つ」でEMSフォーマットでアイディアを書いていき、共有、選定を行った図

EMSフォーマットを導入したことでアイディアを発散収束させやすくなりました。 またオズボーンのチェックリストにならって事前に用意したEMSフォーマットからミーティングの時間で新たなEMSフォーマットを作る時間も用意しました!! jairo.co.jp

f:id:kugi_masa:20201210230524j:plain
1回目の素振り(お題は「はずす」)の振り返りをした図
この章の頭でも書いたように実は素振りは2回行いました。もともと初めに想定していた流れのもと進めていましたが、意外と早く決まり過ぎてしまいました。早く決まったけど、もやもやが残る状態だったので一度振り返りを入れ、今の流れにカイゼンされました。 (ナイスモヤッとストップaojiluくん)

このようにしてできたTETOR<I\E>VERのペライチ企画書が以下の画像になります。

f:id:kugi_masa:20201210232618p:plain
ペライチ企画書

パッとみるとあまりゲームシステムが伝わりづらい企画書ではあります。しかし、この企画書はあくまで3人の共通認識を揃えるためのものとしました。なので企画書の完成度よりは一緒に話しながらすり合わせをして企画書を作る時間に重きをおいています。

現在はu1wまでの残りの時間でこの企画書をもとに一週間の一部を切り取って(3. 4. の部分)SilCilSystemの運用練習も兼ねてTETOR<I\E>VERを制作しています。

kugiが思うこと

こうして2ヵ月を振り返ってみるといろんなカイゼンを行って来たなぁと感じます。

個人的によかったと思うのはaojiluくんがモヤッとしたときにすぐに言ってくれることです。

チーム開発の経験がある私が主にミーティングのファシリをしていたのですが、進め方に対する疑問点やモヤッとしたところをすぐに投げてくれるので、一旦手を止め(ここではミーティングの流れを止め?)3人で合意がとれるようになっていると思います。

また、SilCilさんからの学びも凄まじいです。3人のなかでUnity経験も知識も一番あるのでシステム面で引っ張っていただける分、私はチームビルディングに集中することができたと思います。

また、u1wのチーム開発で今までのチーム開発とは違うなと感じたのは、ユーザーストーリーベース([例]駒を盤面に置くことができる)でIssue(タスク)を立ててしまうとどこまで実装すればいいかわかりづらくなるという点です。このようなタスクだと「盤面はどこで用意すればいいの?」や「駒は何を置くの?Sphere?Cube?それとも...」といった疑問が生まれます。

Issue(タスク内容)を見ただけでチームみんながタスク内容を理解できるようにするにはタスクを具体的に書き出す必要があります。長期開発だと問題はなさそうですが、u1wではやはりスピードが大切。時間をかけてIssueを書いていてはゲームは完成しません。そのため、チームaojiluではIssueは雑めで、着手する人にある程度はお任せという方針でいこうと考えています。また、ユーザーストーリーベースよりはロジックベースのIssueが良さそうです。

まとめ

さて、u1wまであと一週間弱。 こうやって2monthかけて準備したことが全てうまくいくとは思いません。 むしろ、うまくいかないことの方が多いかも知れません。 良いチームが絶対良いゲーム(プロダクト)を作ることができるわけではないと思います。

ただ、この2month行ってきたカイゼンは決して無意味だとも思いません。カイゼンを重ねることで少しでも良いゲームが作れる可能性が増えるなら私は最後の最後までカイゼンを続けたいと思います。

と大きなことを言ってしまいましたが、 ゲームを評価するのはプレイをするみなさんです!

このチームaojiluからどんなゲームが生まれるか...!!unity1weekでお見逃しなく!!!

(今回は長い振り返りなのでYWTはお休み)

干し芋🍠に欲しいもの🎁を書くと干し芋🍠が届くって本当ですか!?!?

はじめに

干し芋🍠に欲しいもの🎁を書くと干し芋🍠が届くって本当ですか!?!?」 というとんでもないタイトルで書き始めてしまいましたが、

こちらの記事は広島大学ITエンジニアアドベントカレンダー2020の11日目の記事です。

なんでこんな題で書きはじめてしまったかというと、本日12/11は私kugiの誕生日です。

その日誕生日の人がAmazonの欲しいものリスト(通称:干し芋)をTwitterなどで公開しているのを見たことがあります。

ということで今回私も自分の干し芋🍠を公開しようと思います。

www.amazon.jp

ただ、単に公開して終わりだと、せっかくのアドベントカレンダーなのに面白みがないので今回の記事では

「ふーん、kugiは今こんなものが欲しいんだね〜」(他意はないです...??)

と思ってもらえるように私の欲しいものについて紹介していきたいと思います。

Books

ゲームグラフィックス 2020 CGWORLD特別編集版

2019〜2020年のコンソールとスマホゲーム のグラフィックス制作メイキング集です

今年に入ってCGWORLDを毎月買って研究室に(勝手に)置く人になっているのでCGWORLDに掲載されたゲームグラフィックス技術の特集はとても気になります!!!

www.amazon.co.jp

UniRx/UniTask完全理解 より高度なUnity C#プログラミング

「リアクティブプログラミング、非同期プログラミングを学んでつよつよプログラマ(表紙より抜粋)

になりたい!!

www.amazon.co.jp

画づくりのための光の授業 CG、アニメ、映像、イラスト創作に欠かせない、光の仕組みと使い方

光っていいですよね!

CGの研究をしているので光のシミュレーションをするのですが、光の物理的な性質についての理解を深めた上でデザインができるようになると理にかなったデザインになると思うんです。

人間が認識しているも、目が光(波長)を情報として受け取って脳で処理して見ています。

う〜ん奥が深い...

www.amazon.co.jp

リアルタイムレンダリング 第4版

鈍器です🧱

www.amazon.co.jp

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

ラボのものをずっと借りパクしているので自分用が欲しい。

www.amazon.co.jp

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

持っていると思ってたけど持っていなかった本その1

www.amazon.co.jp

テスト駆動開発

持っていると思ってたけど持っていなかった本その2

www.amazon.co.jp

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

チーム・ジャーニーは持っているんですが、カイゼン・ジャーニーはまだ持っていませんでした。

www.amazon.co.jp

ゲームメカニクス大全 ボードゲームに学ぶ「おもしろさ」の仕掛け

絶対面白い!!!!

www.amazon.co.jp

Games

PlayStation5

現在在庫切れです。

www.amazon.co.jp

UNDERTALE(アンダーテイル)

ずっと気になっていたゲーム🎮

www.amazon.co.jp

ゼルダの伝説 夢をみる島

ゼルダ好きなのに買うのを忘れてしまっていた...

www.amazon.co.jp

マイク

Blue Microphones Yeti USB コンデンサー マイク Blackout Edition イエティ ブラック BM400BK

いいマイクが欲しいんですよね〜 結構お勧めされてたので気になっています👀

www.amazon.co.jp

干し梅

私は干し芋より干し梅の方が好きです。 最近は特に男梅にハマっています。

まとめ

ここまでお付き合いいただきありがとうございました🙇‍♂️ これを見て「お、良さそう!」と共感していただけるものがあれば私も嬉しいです!

やったこと

わかったこと

  • 干し芋🍠に欲しいもの🎁を書くと干し芋🍠は届かない
  • 欲しい本たくさん

次やりたいこと

  • 干し芋🍠より干し梅🌸食べたい

就活中に出会った『彼』の話

はじめに

こちらの記事は広島大学ITエンジニアアドベントカレンダー2020の7日目の記事です。

今回の記事はこれまでの記事とは異なり、走り書きのようなものになってしまいました。なので、YWT(やったこと・わかったこと・次やりたいこと)もありません。

うまく言語化できているかは分かりませんが、最後までお付き合いいただけたらと思います。


本文

これは就活中に出会った『彼』の話だ。

ちょうど就活直前か始まったぐらいで、Twitterでアウトプットをしたり、イベントに参加する機会が増えてきた時期。 ちょうど世界の広さを知ると同時に、他人と自分を比較して少し気持ちが落ち込んでしまった時期。

発言力があってアウトプットも凄まじい、同じ業界志望で21卒の『彼』をTweetを通して知った。

「本当に同じ就活という戦場で戦えるんだろうか…」

そんなすごい『彼』と自分を比べ、メンタル的に苦しくなる。 これが『彼』との出会いだった。

画面越しに一方的に存在を知っている程度だったが、偶然同じ就活逆求人イベントに参加することになる。 そのときの参加者は20人程度で『彼』がどこに座っているか、なんとなくわかった。

ただ、当時一方的にフォローしていたので向こうが自分を知るはずもない。 就活逆求人イベントではTwitterアカウントと中の人が一致したぐらいで終わった。

もう会うことはないと思っていたが、なにかの縁なのか、インターン、説明会、就活イベントなどその後2、3回会うことになる。 会うと言っても、ただすれ違うという感じではなく、席が前後とか隣とかのレベルだ。実際に話をする機会もでき、そこではじめてお互い知り合いになった。

そのときの話から、第一志望の会社がお互い同じことがわかった。 それを知り、さらに焦りと自分へのマイナスな感情が生まれていくのを感じた。

ただ、就活を進めるにつれ、いろんな方と話をしたり自分への理解が深まるにつれ、マイナスに考えても意味がないことに気づいた。 『彼』と比べて、「『彼』のようになりたい」と思うのではなく、「自分は自分の強みで頑張る」

そして、「同じ会社で一緒に働けたら最高だ!!」と思うようになった。

この頃から少し気持ちも楽になり、他人と自分を比べるのではなく、自分の強みを大事にしていきたいと思うようになった。 気持ちが少し晴れたおかげか、選考が近くなると「お互い頑張ろうね!」と自然とDMを送っていた。

そんなこんなで、お互い最終選考まで進み、結果的には自分は落ち、『彼』は受かった。 結果として同じ会社で働くという道にはならなかったが、来年からはお互い同じ業界だ。

今振り返ると『彼』の存在があったから、就活最後まで頑張れたと思う。

「あなたがいたから今の私がある」

というフレーズがあるが、就活に関して言えば本当に『彼』がいたから今の自分があると思う。

最初は一方的に意識していた存在が、最後までお互いを励まし合う「戦友」になれてよかった。 自分の憧れの人になることはできないけど、その人との出会いやその人と関わった出来事は必ず自分を形成する大事な何かになっているはずだと思う。

そんな彼と学生でいるうちに一緒にゲームを作るプロジェクトが始まったのはまた別の話。

ハッカソンを主催してみた話

はじめに

卒業するまでにやりたかったことの一つであるハッカソンの主催をCammelで行ったので今回はその話をします。

f:id:kugi_masa:20200926214331p:plain
CammelデザイナーのDaigoくん作ハッカソンロゴ

HU hackathon オンラインハッカソン 2020 - connpass

そもそもなぜ主催??

私の初参加ハッカソンは昨年6月頃です。 connpassを使うようになって偶然見つけた「広島エンジニアハッカソン」が私の初ハッカソンでした。

広島エンジニアハッカソン Vol.1 - connpass

ちょうどCammelでの開発が始まりアウトプットを意識するようになった時期で、

「自分では何ができるかわからないけど挑戦してみよう」

という気持ちで参加したのを覚えています。

実際参加してみて、最初のアイディア出し以降は技術的に全く貢献できず、同じチームの現役エンジニアの方がすごくて圧倒されっぱなしでした。

そして、「何もできなかったな〜」という気持ちから「次はもっと頑張りたい」と思いました。

それからこれまでいろんなハッカソンに参加してきました。

賞を受賞できたり、決勝まで進出できたときもあれば、思うようにいかず悔しい思いをしたこともあります。 ただ、どんなハッカソンでもその期間はアドレナリン全開です。そして、成果発表やデモでいろんなチームのや人のプロダクト、作品に触れてとてつもなく刺激を受けることができます。

このようにハッカソンにどっぷりつかれたのも「広島エンジニアハッカソン」のFIRST STEPがあったからだと思います。

さて、前振りが長くなってしまいましたが、今度は私自身がハッカソンを主催、運営する側として「アウトプットする機会」「チームで何かを開発する経験」FIRST STEPとなるようなイベントを企画したいと思ったのがきっかけです。

開催にあたって

企画したい!という思いから開催そして1人で運営までなんとか走りきることができましたが、 私1人の力では開催はおろか、企画倒れで終わってしまったと思います。

結果的にコロナもありオンラインにはなってしまいましたが、当初は学内ハッカソンにしたいと思っていました。

そのため、学内のコンピュータサークルHiCoderさんとチームのCammelには事前に声をかけていました。最終的にconnpassでも募集ページを用意し広島内外合わせて9名の方が参加してくださいました。ありがとうございます!!!

f:id:kugi_masa:20200927002135p:plain
スライドより抜粋

また、大学起業部の代表をしている後輩に審査員をお願いして、審査員賞として後日開催されるビジコンの参加権をいただけることになりました。

オーディエンス賞としては就活でもお世話になった株式会社ジースタイラス様より受賞チームメンバーそれぞれに好きな技術書1冊を協賛いただきました。

みなさん本当にありがとうございました。

これまで多くのオンラインイベントでDiscordを活用していたので、今回もDiscordを使うことにしました。

事前に以下のチャンネルを用意してチームビルディング会、ハッカソン当日がスムーズに進むように準備を進めました。

  • 「はじめに」チャンネル : Discordの軽い使い方や今回のハッカソンサーバーの各チャンネルの使い方を説明
  • 「タイムスケジュール」チャンネル:チームビルディング会、ハッカソン当日の流れ
  • 「大部屋」チャンネル:メインホールのようなもの
  • 「[id]チーム」チャンネル:各チームのチャンネル

f:id:kugi_masa:20200927030428p:plain
「はじめに」チャンネル

f:id:kugi_masa:20200927030751p:plain
「タイムスケジュール」チャンネル

チームビルディング会

さて、「チームビルディング会」という言葉が出てきましたが、いきなりはじめましてからの開発は辛いなと思っていたので

(特に初ハッカソンだとさらに辛い...)

アイディア出しも兼ねてチームビルディング会を開催することにしました。

オンラインでのチームビルディングをスムーズに進めるにはどうすればいいかを考えたときに、

ちょうどコロナによる自粛期間が始まった5月ごろから数回参加をしていた「分散アジャイルチームについて考える会」でのkyon_mmさんのファシリが頭に浮かびました。

distributed-agile-team.connpass.com

このイベントはDiscordとZoomそしてMuralを使ってLTやOST(オープンスペーステクノロジー)を行うイベントだったのですが、

(OSTについてはTAKAKING22のスライドをご参照ください...!!)

はじめにMuralのハンズオンとしてkyonさんが「お立ち台」を用意されていたのを思い出しました。 ハンズオンからの流れがそのままMuralを使うアクティビティにスムーズにつながっていたので、 私も同じように「お立ち台」を用意することにしました。

Cammelのミーティングでは主にMiroを使っていたので今回のチームビルディング会でもMiroを使うことにしました。

まずSTEP1として、付箋を出してテキストを書くことに慣れてもらい

STEP2で「お立ち台」を活用して、自己紹介をしました。

実際に話す人が「お立ち台」に立って(付箋を置いて)自己紹介を行い、他の人がその横に並んで(付箋を並べて)待つというようにして進めました。

「お立ち台」はオンラインでも付箋の場所並ぶという行為で存在を示せるという点でとても優れものだと改めて思いました。 また、付箋の動きや絵文字でリアクションを付けてワイワイしているうちに、Discordがミュートでもだんだん盛り上がっていくのがわかりました。

f:id:kugi_masa:20200927025000p:plain
Miroのハンズオン

そして、アイディア出し、チーム発表、チームごとにアイディアを具体化というように進めていきました。

ここでの振り返りとして以下をあげます。

  • 良かった点
    • 最悪アイディアが出なかったときのことを考えて予めCammelのミーティングで案を何個か考えておいた
    • (結局使われなかったけどそれで良し)
    • チームビルディング会からの1週間の使い方について参加者に聞いてみた
  • 悪かった点
    • 「キーワードからブレスト」をした後「実際作るもの」を考えましょうという流れにしてしまった
    • その間に「出たアイディアから課題について考えてみよう!」があった方が良かった
    • テーマが「広島大学」... 広島外からの参加者を募っていたにもかかわらず、明らかにアウェーになるようなテーマにしてしまった...

テーマに関しては、広島大学生を必ずチームに含めるようにしてはいたものの、このように差が出るテーマにはするべきではなかったと反省しました。

運よく参加していただいた広島外のお二人は積極的に参加してくださったので本当に救われました。

土日でチームビルディング会、ハッカソンとせずにあえて1週間あけたのは少しでも開発までにチームで交流する時間を増やすためと考えていましたが、その間で開発を進めていいかについては明確に決めてはいませんでした。

なので実際に参加者の意見をそのまま反映することにしました。

f:id:kugi_masa:20200927033624p:plain
実際に聞いてみたところ...

過半数が開発は1Dayでとのことだったので、ルールをはっきりさせました。

f:id:kugi_masa:20200927033846p:plain
当日までのルール

実際にハンズオンまでするチームもいたので1週間あけたのはやはり正解でした。

ハッカソン当日

ハッカソン当日は各チームごとに時間を取ってそれぞれのボイスチャンネルにいようかと思っていたんですが、 チームビルディング会と当日までの各チームでのコミュニケーションのおかげか、 どのチームもおおかたスムーズに開発が進んでいました。

そこに甘んじてしまったところもあったので、

反省としては、「初めてのハッカソンを意識してもう少し積極的に各チームのサポートをしても良かったなと思いました。

各チームの成果物

広福 「西条交通確認LINEBot」 github.com

カラス 「食堂メニュー決定アプリ」 github.com

ちゃにまつ太郎 「ひろだいさんぽ」 github.com

広島戦隊和久レンジャーズ「Kinder」 github.com

どのチームも1Dayで作ったとは思えないできのものばかりでした!!!

割と手が空いてしまった運営は何をしていたかというと...

github.com

結果

成果発表後に投票、審査にうつり審査員賞オーディエンス賞が決まりました!!!

f:id:kugi_masa:20200927035303p:plain
オーディエンス賞

f:id:kugi_masa:20200927035324p:plain
審査員賞

オーディエンス賞の「ちゃにまつ太郎」のみなさん、審査員賞の「広島戦隊和久レンジャーズ」のみなさんおめでとうございます!!

(表彰状はもちろんDaigoさん...!!ありがとう!!!)

まとめ

ハッカソンを主催、運営してみました。 オンラインそして初めての試みということもあり、大変だと感じることも多かったですが、 学生の今だからこそできることをやれてよかったです!

また、私の「ハッカソンを開催したい」というワガママを聞いて協力してくれたCammelのメンバー、参加者のみなさん、審査協力してくださった起業部のみなさん、協賛企業の株式会社ジースタイラス様、改めて本当にありがとうございました!!

次回があるかは今のとこ未定ですが、前向きに検討したいと思っています!

やったこと

わかったこと

  • 事前チームビルディングからの流れはとても良い
  • 何事も FIRST STEP は大事

次やりたいこと

  • 卒業までに自作キーボード作る
  • 卒業までに3Dプリントする

unity1week online共有会 #2-B📘 視聴メモ

はじめに

またまた前回の記事からだいぶ時間が空いてしまいました。

今回はunity1week online共有会 #2-B📘の視聴中に書き残したメモをここでまとめたいと思います。

f:id:kugi_masa:20200920014209p:plain

https://www.youtube.com/watch?v=SS_2VbdzSL0&feature=youtu.be

unity1week共有会とは

青木ととさん(@lycoris102)が開催されているunity1week参加者による共有イベントで、 1週間の流れ、ゲーム作りへのこだわり、アイディアの出し方、といったお話が開発者本人から聞ける素晴らしいイベントです。

実は私も第一回に参加をしていて「作りたいものを作りきる」という題でお話をさせていただきました。

speakerdeck.com

youtu.be

登壇される方が「ふえた」ということで今回は #2-A📕 #2-B📘 と2週に分けての開催でした。

今回#2-Bはリアルタイムで視聴ができたのでメモを取りながら視聴していました。

(#2-Aも視聴はしていたんですが、別の用事と被ってしまい途中からの参加だったので視聴メモは残せていませんでした...)

視聴メモ

発表を聞いて得た学びや感じたことは人によって違うと思うので、これはあくまで私が感じたこととして捉えていただけると幸いです。 また、発表全てを要約したものでないことはご了承ください。

SilCilさん 「技能向上のためのunity1week」

専門用語を「知っている」 = 「検索できる」

ある技術や知見に対して「詳しく」なくても、「知って」いれば「検索する」ことはできる。

もちろん習得するためには

"調べて" => "学んで" => "習得する"

という流れだとは思いますが、まず何よりもそのことについて「知る」がないといけません。 そのためにはこういった勉強会に出て情報を取りに行くことが大事だなと改めて痛感しました。

「100日後〇〇できる」= 99日間は「失敗」、「毎日30分〇〇する」の方が安全

捉え方にもよるとは思いますが、確かにロングスパンでのゴールでなく、短い時間での(毎日30分やり切ったといった)成功体験を感じながら何かを学ぶことでモチベーションにもつながるなと感じました。

SilCilさんはBlenderの進捗をTwitterに投稿されていて、私も投稿を密かに追っていました。 日を追うごとにどんどんリアルさを追求されているのがわかって凄かったです! (PCの光がしっかりキーボードに照り返されているのとか凄かった...)

発表時のバーチャル背景もレンダリングした画像になっていて、言われるまで気づかないほどのリアルさでした!

NightS/ナイトレイさん 「斯くて世界は創られる」

見た目から世界を創る - 記号化と対比

キャラを色とモデルで視覚的に対比させ自然と敵だと認識できるように創られていてすごいなー!と感じました。

音楽から世界を創る - インタラクティブミュージック

ストーリーや演出に合うように音を出すタイミングや曲調をコンポーザーである九藤 周(くどう あまね)さんとしっかりすり合わせをして創られていました。

何故ゲームを創るのか? 世界を創るため

ゲームを「作る(Make)」ではなく「創る(Create)」というNightSさんのクリエイターとしての熱い気持ちが伝わってくる締めの言葉でした。

今回もNightSさんの周さん愛を感じる発表でした。 発表とBGMが同期していたのが最高にエモかったです!!!

まっともぉんさん 「大切な技術検証 ~本当にそれ動く?~」「大切なモチベーション〜本当にそれ続く?〜」

発表のテーマを前半後半で2つに分けて発表されていました。 すごい!!

モチベーションを保ちながら開発を進めるには

  • タスクの可視化してしっかり見積もる
  • ブレない面白さを意識する
  • SNSに進捗を投稿してフィードバックを得る

ドッグフーディングで「面白さの軸」を早めに固めて、他の人からのフィードバックを得ることでその「面白さの軸」がちゃんと立っているかを確認する。 ハッカソンでは特に時間がないので早めに軸を固めることで手戻りも少なくなりますね。

(まっともぉさんのイントネーションは🍿と同じらしいです笑)

zizoさん 「7日間でこうなりました」

ゲームを作られたゲームの流れを紹介されていました。

ゲームの方向性をなるべく早く確認する

これはまっともぉんさんのお話でもありましたが、「本当に面白いの?」という方向性をやはり早めに固めることが重要だなと感じました。

やはりコアな部分での手戻りはツラいですよね...。

「2割の時間で8割の全体像を確認する」が目安とのことでした。

「タイトル画面(仮) 仮なのよ」がツボでした笑

ベコタイジさん 「なんとなくチームで参加したら1weekデスマになった話」

ドット絵調のUnityで作られた発表スライドで凄かったです! 冒頭はチームの紹介で、みなさん「各分野のスペシャリスト勢揃い」でした。

そんなスペシャリスト集団のチームがデスマに陥ってしまった話をされていました。

原因として以下をあげていました。

工数の見積もりの甘さと進捗管理を怠ったため。作業能力に対して制作物の難易度が高かった。仕様に関してその場しのぎで変更しながら作ったため。

確かにハッカソンだと見積もりが難しいと常々感じます。 作っているときは楽しくて、あれもこれもと詰め込んでしまいたくなって後半「えいやー!」とオールでやってしまう経験を何度もしています...

作りたいものを作りきることはもちろん大事で今後もそのモチベーションで作っていきたい気持ちは変わりませんが、 一歩引いて「やらないことリスト」を作る余裕を持って開発することも大事だなと学びました。

idealさん 「Unityインターハイ入賞クリエイターが語る!モチベを1週間維持するコツ」

10分タイマーを使ってみる

ポモドーロ・テクニックのように、10分間全力で集中してタスクをこなす、休憩する、10分間全力で集中してタスクをこなすを繰り返す。 ハッカソンという特殊な期間でモチベを維持して生産性をあげるためにはこのような取り組みを取り入れるのも一つの手だなと感じました。

わけんさん 「自分的Unity1Weekでの企画の考え方」

アイディアをたくさん出したしとしてもその中で本当にいい案を見つけるのは難しい。 そこで指標にすると良いわけんさん流の「10つのリスト」のお話でした。

大量の案から良い企画を引っ張り出す10つのリスト

  • 実現可能性 (自分のスキルと照らし合わせて)
  • 仕様に曖昧さはないか(核はしっかりしているか)
  • 革新的か(u1wだったら「斬新さ」につながる)
  • 既存ゲームの劣化版になっていないか(ただの二番煎じは避けたい)
  • 「面白そう」を提供できるか(スムーズに面白さが伝わるか)
  • 「面白い」を提供できるか(リスク・リターン、メカニクスの衝突はないか)
  • 「面白かった」を提供できるか(やりごたえ、バズり)
  • ターゲットユーザーにマッチするか(まずはペルソナ定義しっかりする)
  • マネタイズできるか(資金的にOK?広告など)
  • 直感的に良さそうか(自分の感性を信じる)
"面白そう" => "面白い" => "面白かった"

ユーザ感情の流れを「面白そう」から「面白かった」まで持っていくには どういう企画でないといけないか抑えられていてとても勉強になりました!

さちぎょϵ( 'Θ' )϶さん 「1weekでかわいいアメーバを?できらぁ!〜デザイン奮闘記〜」

スライドの雰囲気がめっちゃくちゃ可愛かったです✨ 今回はデザイナー担当のさちぎょϵ( 'Θ' )϶さんがデザイン側とエンジニア側をまとめてお話をされていました。

UI = ロジック

色、大きさ、位置には理由がある。(言語化できる)

発表を聞いているとどれも本当に理にかなっていてめちゃくちゃ納得できました。

「色を考える」:色の"対比"で情報の優先度を伝える

ゲームの中で優先度の高い情報にはコントラストが強い色を使う。 一旦ゲームシーンをモノクロにして確認している様子がスライドに載っていて「天才か!?」と思いました。

「位置を考える」:プレイヤーの行動に合わせて自然な位置に配置する。

キーボードとUI配置の整合性をとることで、プレイヤーが違和感なく自然に遊べる。

UI/UXは本当に奥が深いなと感じました。

うにうにちゃんさん 「レトロ風ゲーム、作ってみませんか?」

発表がめちゃくちゃ素晴らしかったです! 某ネズミーランドのスタッフさながらの喋りで聞いていてワクワクするプレゼンでした。

レトロなグラフィックのゲーム

  • ドット絵がにじまない・劣化しない => スプライトの設定でバイリニアフィルタはかけない、圧縮もかけない
  • ドットが潰れない => Pixel Perfect Cameraを使う
  • 1スプライトあたりの色数が限られている => Asepriteを使え!

Asepriteはたったのうま○棒約200本分らしいです!!!

先日ギルドの方で拝見したうま○棒のドット絵がここにつながるのか!!と思いました笑

さいさん 「『スライム牧場』でそこそこ頑張ったゲームデザインと設計」

ゲームデザインについてのお話でした。

1weekでの自分のルール

さいさんの場合だと一番遊んでもらいたい一般ユーザー(多くはスマホユーザ)のことを考えて「左クリックのみでできるゲーム」といったルールを決めているそうです。 遊んでもらいたいターゲットはどこなのかと、そのターゲットユーザに遊んでもらうためにはどういったゲームデザインにするべきか。 とても勉強になりました。

ゲームの言語化

さちぎょϵ( 'Θ' )϶さんの発表の「UIを言語化する」と同じように、ゲームそのもの自体を言語化することで面白さの確認にもつながるんだなと感じました。

まとめ

今回はunity1week online共有会 #2-B📘 の視聴メモを整理してみました。 発表者のみなさんお疲れ様でした!そして何よりこの会を開催されている青木ととさんありがとうございます!! 今回も本当に学びの多い会でした。

(#2-Aの発表も余裕できたらまとめたいと思います...!!!できないかもしれない...そのときはごめんなさい...)

やったこと

  • unity1week online共有会 #2-B📘に参加した

    わかったこと

  • UIやゲームの面白さを「言語化」することはダイジ
  • ドッグフーディング + 他の人からのフィードバックで早めに「面白さ」のコアを固める

    次やりたいこと

  • 次回のu1wでは今回得た知見を少しでもいかす(特に操作性やゲームのわかりやすさの部分)
  • 自分の振り返り記事も書きたい(書かないと...)

Mitsuba 2 導入(macOS Catalina)

はじめに

以前macOSでのMitsuba Renderer導入についてまとめました。

kugi-masa.hatenablog.com

今回は新しくなったMistuba 2の導入についてです。

♧Mitsuba 2♧

リリースノートを見ると2020年3月3日にMitsuba 2.0.0がリリースされたようです。

3月3日→♧月♧日

狙った日付だったのでしょうか...?👀

SIGGRAPH Asia 2019で論文としても発表されています。

rgl.epfl.ch

Merlin Nimier-David, Delio Vicini, Tizian Zeltner, and Wenzel Jakob. 2019. Mitsuba 2: A Retargetable Forward and Inverse Renderer. In Transactions on Graphics (Proceedings of SIGGRAPH Asia) 38(6).

今回からかなり見やすいドキュメントも用意されているので、もしかしたら導入ブログは不要かもしれません💦

が、自分も記録として残しておきたいので早速やっていきましょう。

mitsuba2.readthedocs.io

GitHubからfork

ドキュメントでは本家のmitsuba-renderer/mitsuba2リポジトリからcloneするような手順になっていますが、私は本家に影響を及ぼしたくないのでfork🍴します。

ではforkしたリポジトリをローカルに持ってきたいと思います。 (私のようにforkする場合は[yourname]を変更してください)

$ git clone --recursive https://github.com/[yourname]/mitsuba2.git

ただ、forkしてしまうと本家にコミットが追加されてもfork先には変更がないので、ローカルに適宜本家からpullしてfork先に反映するのが良いようです。

以下で本家の情報を取ってきましょう。

$(master) git remote add upstream https://github.com/mitsuba-renderer/mitsuba2
$(master) git fetch upstream
$(master) git merge upstream/master

しかし、このままでは最新版に追従できていません。 Mitsuba 2ではgitのSubmodulesという機能を使っています。

--recursiveオブションをつけることで他のプロジェクトの連携までを管理してくれるためセットアップが楽になるとのこと

git-scm.com

Submodulesをつかっているため通常のpullコマンドのみではダメみたいです。

ドキュメントにしたがって以下のpullallコマンドを追加しましょう

$(master) git config --global alias.pullall '!f(){ git pull "$@" && git submodule update --init --recursive; }; f'
$(master) git pullall

pullallコマンドを実行することでforkしたリモートリポジトリのmasterブランチも

This branch is even with mitsuba-renderer:master.

になっているはずです。 (もしかしたらpushが必要だったかも...)

バリアント(Choosing Variants)

Mitsuba2ではビルドする前にRGB、スペクトル、偏光レンダリングなど、どのようなレンダラーとしてビルドするかを指定する必要があるそうです。

その種類はなんと36通り!! 以下のようにRGB、スペクトルなどを選んで組み合わせることができるようです。

  • Computational backend
    • scalar
    • packet
    • gpu
    • gpu_autodiff
  • Color representation
    • mono
    • rgb
    • spectral
  • Polarization
    • polarized
  • Percision
    • double

まずは以下のコマンドで設定ファイルをmistubaのルートディレクトリにコピーしてきましょう。

$ pwd
<your mistuba root directory>
$ cp resources/mitsuba.conf.template mistuba.conf

コピーしたmistuba.confenableのところでバリアントが指定されています。

"enabled": [
    # The "scalar_rgb" variant *must* be included at the moment.
    "scalar_rgb",
    "scalar_spectral"
],

コンパイル

macOS では以下がインストールされている必要があります。

また、Pythonについてもversion 3.6以上が必要です。 macOSのデフォルトのPythonversion 2.7.16でした。(2020/07/28時点)

$ which python
/usr/bin/python
$ python --version
Python 2.7.16

このままではコンパイルが通らないので、Python3をデフォルトにします。

以下の記事がとても参考になりました!!

opensource.com

pyenvを使ってPython3をデフォルトにします。今回はmistuba2のドキュメントに合わせてversion 3.7.3をインストールします。

$ brew install pyenv
$ pyenv install 3.7.3
$ pyenv global 3.7.3
$ pyenv version
3.7.3 (set by /[Your Directory]/.pyenv/version)

ここではまだ、macOSデフォルトのPythonです。

$ which python
/usr/bin/python

なのでパスを追加しましょう。macOS Catalinaからデフォルトのシェルはzshになったらしいので以下を.zshrcに追加します。 (詳細はコチラ)

if command -v pyenv 1>/dev/null 2>&1; then
  eval "$(pyenv init -)"
fi

新しいターミナルを立ち上げて、最後にもう一度確認をしてみましょう!!

$ which python
/[Your Directory]/.pyenv/shims/python
$ python --version
Python 3.7.3

ヤッター!!!🐍 🐍 🐍

CmakeやNinjaについては、それぞれhomebrewでインストールしました。

$ brew install cmake
$ brew install ninja
(--- If you haven't installed the xcode command line tool ---)
$ xcode-select --install

では、ビルド用のディレクトリを作成してコンパイルしましょう。 (Python3をデフォルトにする前に以下を実行してしまった場合は一度buildディレクトリを削除しましょう)

mkdir build
cd build
cmake -GNinja ..
ninja

mitsuba2 を動かしてみる♧

mitsuba2のルートディレクトリにあるsetpath.shを実行することで、mitsubaコマンドが使用できるようになります。

$ pwd
<your mistuba root directory>
$ source setpath.sh
$ mitsuba scene.xml

mistubaレンダラーはシーンファイルにxmlファイルを使用しています。

コチラのサンプルを参考に金色のドラゴンをレンダリングしてみました。 Stanford Dragon reference

http://graphics.stanford.edu/data/3Dscanrep/

f:id:kugi_masa:20200728170022p:plain
金のドラゴン

まとめ

今回はmacOSにおけるMitsuba2の導入をしてみました。

かなり長くなってしまいましたね...

冒頭にもあるようにドキュメントが整っているのでそちらも是非!!

やったこと

  • mistuba2をfork
  • Python3をデフォルトに設定
  • mitsuba2をコンパイルして動かしてみた

わかったこと

  • 導入は前のバージョンよりも遥かに楽
  • ドキュメントが素晴らしい

次やりたいこと

  • いろんなシーンでレンダリングしてみたい
  • 実際に中身をいじってみる