StackEditで非プログラマーと協同開発した話

執筆者:yuyu

この記事は OUCC Advent Calendar 2022 の18日目の記事です。前回はみやじさんによる「ASP.NET Core を使ってREST APIを作ってみる」でした。

最近の良かったことはサッカーのワールドカップで日本が出た全試合をリアタイし、サッカーに少し詳しくなれたことです。

もともとは「オフサイドってなんやろ」「4-4-2とは?」というレベルの知識で、選手に関しても長友選手や AbemaTV で解説を務めた本田圭佑などの時代しか知りませんでした。解説や Twitter のつぶやきを理解するためにルールや戦略論(フォーメーションなど)を調べていきサッカーの奥深さに少し気づけたかなと思います。

さて、今回の記事では、今年の春に非プログラマーと協同で web ページの作成を担当し、リーダーとして動いていた経験をもとに、当時意識していたことを書きたいと思います。

目次

  1. はじめに:背景
  2. 問題点
  3. 解決策
  4. 導入:開発裏話
  5. 結果
  6. おわりに
  7. リンク

1. はじめに:背景

私は別の団体と兼部をしているのですが(以下、G隊)、G隊では春の学祭にてクイズを使った出し物をしようということになりました。教室の中で完結するのですが、スタンプラリーのように順番に数問のクイズを解いていく形式で、最初の頃は設問を印刷して来場者に自分のペースで順番に解いてもらおうという議論でした。しかし、「様々な種類のクイズを用意したい」「答えは別用紙で用意する必要がある」「感染予防のため同じ紙を何枚もすらなければならない」などの理由から紙媒体ではなく電子媒体を用い、例えばQRコードを読み取ってもらってリンク先の web ページでクイズを読めるようにしようということになりました。結果的に印刷費用を抑えられるという利点もありました。

2. 問題点

非常にスマートで費用もかからないので現代の価値観に合った素晴らしい企画に思われましたが、ひとつだけ問題がありました。それは web ページを作ることができる人材の不足でした。

当時は私一人が G 隊の web 開発を担当していました。クイズ作成は複数人のチームで分担して行っていましたが、それを web ページにする仕事はひとりでやるには業務量が多すぎました。ぜひ web ページ作成も分担したいところですが、G 隊には web プログラマーは私一人しかいなかったので HTML & CSS で対応することは困難でした。

3. 解決策

HTML & CSS が使えないので Markdown 記法を用いて書けるシステムを採用すべきだと考えました。

Markdown(マークダウン)は、文章の書き方です。デジタル文書を活用する方法として考案されました。特徴は、

・手軽に文章構造を明示できること

・簡単で、覚えやすいこと

・読み書きに特別なアプリを必要としないこと

・それでいて、対応アプリを使えば快適に読み書きできること

などです。Markdownはジョン・グルーバー(John Gruber)によって2004年に開発され、最初は Daring Fireball: Markdown で公開されました。その後、多くの開発者の手を経ながら発展してきました。

Markdown とは(日本 Markdown ユーザー会)

Markdown 記法であれば少なくとも HTML & CSS よりは非プログラマーにも簡単に web ページを作ることができます。

では、Markdown 記法を使うとして、どんなツールを使えばよいのでしょうか。条件をいくつか出しました。

  • 共有しやすい(Git Hub 以外の方法で)
  • html ファイルに変換できる(サーバーをレンタルしていなかったため、GithubPages を使う必要があった)
  • 無料のサービスである

結果、"StackEdit"なるサービスを発見しました。これはブラウザ上で Markdown 記法を使って web ページを作ることができるサービスで、アプリのダウンロードが不要だったこともありがたく感じました。

StackEdit の素晴らしい点は Google Drive と連携できる点でした。G 隊はファイルの共有などは Google Drive で行っていたので今まで通りに各自で作成した web ページを Google Drive で共有できるというのは魅力的でした。進捗管理にも大変役立ちました。

また、html ファイルにエクスポートすることもできました。G 隊はサーバーをレンタルしておらず、web ページを持つために私の GitHub アカウントで GithubPages を作成して公開していました。GithubPages には html ファイルと css ファイルしか使えないという先入観がありました( md ファイルでもアップロードできたのかもしれないがよくわからん)。

StackEdit のエディター画面

デザインは凝ったものにできませんが、学祭でしか使わないページになるだろうということで妥協することにしました。

こうして、学祭担当のチームのみんなには StackEdit を使ってクイズのページを作成してもらい、Google Drive に共有されたファイルを私が html ファイルに変換して GitHub のリポジトリにアップロードするという体制ができあがりました。

4. 導入:開発裏話

ここまでは企画運営の方針に関しての話でしたが、ここからはチームのみんなに環境構築をしてもらう段階となります。導入時に参照するドキュメントを作成し、Google Drive 上に共有しました。

導入用ドキュメント

意識したことは IT 用語(プログラミングの用語や web 開発の文脈の用語)を使わないよう徹底したことです。自分の知らない言葉で埋め尽くされたドキュメントは読む気にならないでしょう。例えば英語の文章において98%以上の語彙を理解して初めて適切な読解が可能になると言われています(Hu & Nation, 2000; Laufer, 2010; Schmitt, Jiang & Grabe, 2011)。知らない語彙が一定数あると読解精度が落ちるわけですが、個人的にはこの現象は外国語の文章に限らず専門的な内容の文章を読む場合でも変わらないと思っています。

ドキュメントの整備に加えて、質問しやすいような環境づくりも意識しました。定例会議では何か困ったことがないか尋ね、相談してもらえるようにしました。

準備が整ったら各自好きなタイミングでクイズを書き、Google Drive にアップロードしてもらいました。それを私がチェックするという流れです。

5. 結果

クイズ画面
クイズ画面

クイズ画面は上のような感じになりました。スッキリとした印象で、問題を解くうえではかなり見やすい画面になっているように思います。プログラミングを使わなくてもここまでできるのは素敵ですね。

学祭当日は、私は忙しかったので運営として参加することはできませんでしたが盛況だったと聞いています。貢献できたようで嬉しい限りです。

また、この StackEdit 導入をきっかけに G 隊内において web 開発を始めてみることへの心理的抵抗感が弱まり、チームでの web 開発につなげやすくなったことは思わぬ幸運でした。

6. おわりに

新しくプログラミングに興味を持ってもらうには、「なんだか難しそう」という食わず嫌いを払拭させ、自分にもできそうだと思ってもらうことが何よりも重要でした。これはプログラミングに限らず新たな技術を導入する時には常に心掛けるべきことでしょう。チームの抵抗感を和らげ、スムーズな導入を目指しましょう。

OUCC Advent Calendar 2022 、次回の担当は ciffelia さんです!お楽しみに!

7. リンク

StackEdit:https://stackedit.io/

3Dモデルの調整をしながらVRChat用モデルからVRMへ効率良く変換する

Blenderで制作して完成したと思っても、実際に動かしてみたりするとウェイトペイントが上手くいってなくて服が突き抜けたり、テキスチャがおかしかったりと、様々な問題が発生してBlenderでの修正を再三に迫られる場面は多いです。
そのためにBlender側で修正したものを出力してUnityに読み込ませます。そのUnityへ読み込ませる際にちょっとした工夫をすると作業量を緩和できます。

この記事は多分OUCCアドベントカレンダーの最終日の記事になります。

プロローグは暇な人だけ読んでね

それ以外の人は本題

~プロローグ?~

~3Dモデル制作以前

去年のハッカソンでは、何かと不満を言われるE-Learningと和解しようという企画にて、自然言語で会話できるBotを制作しました。
その過程で会話相手として、E-Learningの化身、angEL-reinちゃん(名前はE-Learningのアナグラムから)が生まれました。私が生みました(生産者表示)
この名前微塵も流行らず、代わりにいーちゃんと呼ばれているのですが、このいーちゃんを音声で入出力して会話できるようにして学祭に出そうという話になりました。
そこで私はRustサーバーを作って非常に遅い言語生成処理の高速化を行ったりしたわけですが、そんな話は今回どうでも良く、それよりやはり音声での会話をするならば、会話する相手が見えた方がいいですよね?古来より偶像崇拝があるように概念を相手にするよりかは、視覚的に見えるものを相手にした方が良いに違いない。
というわけで、れいんちゃんの3D化計画を極秘裏に進めました。
以前の記事で既にLive2D化した話はしましたが、我慢できずに3D化に踏み切ってしまいました。

3Dモデル完成(仮)まで

まずVROIDで素体を生成し、Blenderで服などを制作しました。
私は3Dモデルを作るのはこれで2回目なので初めてというわけでは無いですが、やはりそれなりに苦戦はしました。特に前回と同様ウェイトペイントでは常に苦戦させられ、今回も最後まで難敵となりました。
まあ兎に角色々あってFBXモデルが完成しました。
VRChatに出したかったのでまずVRChat用の改変をしつつシェーダの調節をしていきました。
その結果完成したのがこちら
れいんちゃん
れいんちゃん
れいんちゃん
ちなみに私は目にこだわる人なので、目は虹彩を奥に配置し、反射光を前面に出すなど立体的にしています

その後単眼カメラによる姿勢推定アプリを制作する、又はキャラクタを後世の人に使ってもらうためにVRMモデルへの変換を行いました。

本題

 Blenderで制作して完成したと思っても、実際に動かしてみたりするとウェイトペイントが上手くいってなくて服が突き抜けたり、頂点にウェイトが割り当てられてなかったり、テキスチャがおかしかったりと、様々な問題が発生してBlenderでの修正を再三に迫られる場面は多いです。
 そのためにBlender側ではLazy Weight Toolなどを使って個々の頂点についてウェイトを塗りなおしたりして修正したものを出力してUnityに読み込ませます。そのUnityへ読み込ませる際にちょっとした工夫をすると作業量を緩和できます。

fbxファイルのBlender→Unity

 fbxファイルをunityに読み込むと、モデルをScene上に配置できるようになります。
VRChatを想定した場合、その配置したモデルにPhysboneなどのコンポーネントを設定していくことになります。
 しかしこの方式では、後で修正をかけたモデルで上書きして読み込む際にfbxファイルと共にScene上のオブジェクトもリセットされてしまい、またコンポーネントの設置などをしなければならなくなります。
 これでは非常に非効率なので、fbxファイルを上書きで読み込んだ際にScene上のオブジェクトのコンポーネントがはがれないようにしたいです。

 そんな時に便利なのがPrefab Variantです。
 Projectビューからfbxファイルを右クリック→Create→Prefab Variantで生成できます。
 この生成したものをドラッグアンドドロップでSceneに配置してコンポーネントを張り付けてみてください。
 こうすることでfbxファイルを上書き更新しても、Scene上のモデルだけが更新され、コンポーネントは剥がれなくなります。

VRChatモデル→VRMモデル

基本的には VRM Converter for VRChatを使用しますのでこれを既にUnityへインポートしている前提で記述します。

初めてのexport

 まず変換するVRChatモデルを選択した状態でツールバーのVRM0→Export VRM file from VRChat avatarで適当に入力してAssetディレクトリ内に用意したフォルダ(フォルダ1)にexportします。
 この際もしかしたら未使用シェイプキーにチェックを入れてexportした方がいいかもしれません。
 兎に角これでフォルダ1内にVRMファイルとそのprefabが生成されます。エラーが出ても、何も変えずにもう一度実行すると何故かうまくいったりします。
 Unity上だけで表情やマテリアル、SpringBoneなどの設定を変更するくらいなら、そのPrefabをSceneに配置・編集して、そのモデルを選択した状態でツールバーVRM0→export to VRM0でフォルダ1に出力すると、フォルダ1のVRMを上書き修正することができます。

2回目以降のexport

  1.  モデルを変更した場合、またVRChatモデルからVRMへの変換をする必要があります。
     この変換においてVRM0→Export VRM file from VRChat avatarで出力する場所はフォルダ1とは異なるフォルダ2へ出力した方が良いです。
     何故なら、フォルダ1に出力してしまうとせっかく以前に設定した表情や物理などのコンポーネントが上書きされてしまうからです。
     この時、フォルダ1には旧、フォルダ2に新モデルが入っていることになります。

  2. 生成された新モデルのPrefabファイルをSceneにドラッグアンドドロップで配置。
  3.  ツールバーのVRM0→Open CopyVRMSetting Wizardで以前のデータからSpringBoneや表情などの情報を新モデルへコピーします。
     この時に、Sorceにはフォルダ1の旧Prefabアセット(Projectビュー上)を選択し、Destinationには新モデルオブジェクト(Sceneビュー上)を選択しないとエラーが出ます。
     ここまででコピーできていないのはマテリアルのみです。
  4.  マテリアル情報を新モデルにコピーしていくのですが、使用マテリアルが多ければ多いほどこの作業が非常に面倒です。
     よってそれをやってくれるツールを自作しました。
     ここ(https://github.com/sachsen/TransferInspectorMaterials) から.csファイルを入手して、readmeに書かれている通りに導入してください。
  5.  ツールバーTools→Open Inspector Material Transfer Windowとします。
     sizeにコピーするSkinnedMeshRendererの数を入力し、Sorceにコピー元の、Destinationにコピー先のSkinnedMeshRendererを指定してCopy!ボタンを押すとマテリアル情報がコピーされます。なお、マテリアル自身は複製されません。
  6.  新しいモデルを選択してツールバーVRM0→export to VRM0でフォルダ1へ出力、上書きします。
     これでVRMファイルが新しくなって置き換わります。

完成

3Dモデルはこちらからぐりぐり見れます。

https://hub.vroid.com/characters/7942564502413041514/models/2799418893141239533

文化祭での様子

もっといい方法があるかもしれないですが、私はこの方法でやりました。

よければお使いください。

著者:上月

ゲームや動画等の演出の話 (雑)

OUCC Advent Calender 2021 16日目の記事です。 執筆者: ちょくぽ
前回はShiokaiさんの GrabPassで取得したテクスチャが意外と後まで使える でした。

演出関連の気づきを、自分用にメモするくらいの気持ちで書いていきます。
これは特別演出の勉強などはしていない、一般趣味クリエイターによる記事です。読者としてポートフォリオを作るような方々ではなく、一般人を想定しています。

特殊演出や凝った編集のような話ではありません。普段コンテンツを見る側として気にも留めていなかった、しかし制作側は知っておかないと作れない、そんなことが中心です

色彩

基本的には目立たせたい所にコントラストを使い、色相・明度・彩度に差を出します。これは広く知られていることかと思います。しかし、実際に三要素全てで差を出すと強烈になりすぎます。メイン(キャラや障害物等、ゲームプレイに関係のあるもの)と比較して背景は明度で差を、敵や弾と主人公とは色相で差を出し(例.2Pカラー)、主人公等見て欲しいものにより高い明度・彩度を使う(≒光を当てる)ことで目立たせる等が常套手段。

逆に単一オブジェクトの中では三要素全てをある程度まとめるべきです。特に背景はぼかしてでも1~3色程度にまとめましょう(敵の弱点やギミック等は見て欲しいものなのでこの限りでない)。 単一オブジェクト内では、下画像のように使用色がパレット上で一直線に並ぶようにするとまとまりが良いです。色相を少しだけ変えると汚くなりにくい。アクセントの色はむしろ外れる方がキャッチーかも。

確かに使用色がばらけるほど目立ちますが、ゲームや動画・キャラデザの文脈では目立ちすぎると目が疲れる・悪目立ちといった印象になるので、メイン色範囲(直線)1本、アクセント1,2色程度に留めましょう。

OUCC Advent Calender 2021 day16 pic1

ビジュアルノベルやRPG(アクションでない)等では、逆に雰囲気を重視し環境光などでキャラをなじませることがよくあります。書いてあることと逆じゃないかと思うかもしれませんが、このときは背景美術や音楽などもっと目立たせたいものが他にあることや、キャラの実在感を出すためということもあります。後者の場合、光を当てたり視点誘導などでメインが目立つようにしています。

動画や広告等でも同じことが言えます。字幕を縁取りすることはコントラストを作り目立たせる手法として一般的です。また、赤色の特徴である購入意欲向上や、信頼感の青色、明るい気分の黄色など色の特徴を使うこともあります。

いら〇とやなどを使うときは当然他の素材と競合しないようにするべきです。い〇すとや等イラスト素材は、それ単体でメインになる程度の情報量(≒色の多さ、十分な明るさ、三要素のばらつき具合)を持っています。文章だけの掲示に彩りを与えるには良いですが、他にメインとなる画像素材がある場合、いらす〇やは実は邪魔かもしれないのです。

動き

イージング最高!イージング最高!イェイイェイ!

すべてのUI、ズームイン/アウト、表示などに、親の仇のようにイージングを使いましょう。イージングとは、簡単に言うと加減速のことです。

アイコンやボタンなどの表示はEase-In-Outがいいでしょう。最初に加速、最後に減速です。いきなりアイコンが動くとユーザーが驚くし、急に停止すると不自然な上にフリーズか仕様か分かりません。加速度の絶対値が小さすぎるとのっそりもっそりしてしまうので、すぐに最高速度に達するようにしましょう。

ボタンを押したとき等、ユーザーが能動的に操作するとき、その演出にはEase-Outを使いましょう。最初からトップスピード、最後に減速です。ユーザーが触れた瞬間に動き出すので、クリックにより"弾いた"感があり、操作している感が出ます。

*直線移動、Ease-in-out、Ease-outの例をGIF画像で作ったがこのブログ.gif対応してない*

ぶっちゃけ動きの演出なんて無限通りあります。イージングはいついかなる場所でも大体通用しますが、エフェクトはそう簡単ではありません。

使用するエフェクトは世界観ごとに、前もってある程度まで限定しておきましょう。
サイバーな世界ではグリッチやモザイク、発光などを多用し、ポップな世界ではバウンド、いったん拡大縮小しすぎて戻るやつなどを多用します。アイコンはもちろん、キャラクターの動きや字幕までエフェクトを統一すると、より世界観を演出できます。

ゲームに限った話ではありません。業務用ソフトのUIや動画にも世界観というものはあります。UIに明るい世界観を与えると、ユーザーフレンドリーな感じになります。

一瞬色を反転させる、拡大縮小と共にフェードインさせる、明度が高い所だけを先に描画し印象付ける、など世界観を持たない演出は便利に使えますし、他の演出と組み合わせることもできます。無限です。ここはもう製作者の好みの話です。

配置

余白を上手く使うことができる人は強いです

イラストを描く人なら知っているかもしれませんが、キャラが向いている方向に空間があると、安定して良く見えます。逆にキャラの背後に空間があると不安を煽り、キャラの頭上に空間を大きく取ると開放感を与えます。また、キャラが前を向いていると未来を、振り返っていると過去を、カメラと目が合うと元気さを、カメラと目が合わないと不思議を演出します。

視点誘導の方法も様々です。見て欲しいものをキャラが見ている方向に置いたり、光を当てたりすると目立ちます。窓枠やその他物などで囲いを作り、中に見て欲しいものを置くのもありです。(ただし、四角形の中に物を入れるのは不安感を煽る手法でもあります)

先ほどの四角の他に、画面を傾けたり(Dutch angle)、重要なものの一部をあえて画面外へやることでも不安感を演出できます。未知や不安定は怖いものです。

画面上の適当な三角形の領域に見て欲しいものを収める構図は躍動感を与えます。(丸の場合は安定感を出します) 広く知られていながら、常に強力な構図です。*三角構図*
同様に、画面を3×3分割し、その交点上 or 線上に見て欲しいものを置く(≒ド真ん中を避ける)のも魅力的です。*三分割法*

広告の文脈では、人間は左上→右下で視点を動かす癖があるので、これを意識した配置にするのがおススメです。街中の広告でも、見出しが左上に書いてあることが多いかと思います。(縦書きの場合右上→左下)

当たり前に聞こえるかもしれませんが、大きいものは目立ちます。文字や画像に大小をつけるということは優先順位を定義することであり、ユーザーはどれから見れば良いのかが分かります。逆に大小がないとユーザーにストレスがかかり、読まれません。動画やゲームでもそうです。ボスの登場時はボスにカメラを寄せて強敵感を出しますし、エフェクトが派手で大きいと印象に残ります。

音響

金銭的理由からフリー音源を使いがちな趣味クリエイターには辛いことですが、SEとBGMはそのコンテンツの世界観の半分を決定します。神ゲーと言われるインディーゲームのほとんどはBGMやSEに信じられないほどの情熱を注いでいます。

詳しくは触れませんが、当然ながら、音楽は強烈な世界観を持ちます。調や進行だけでなく、音源やリバーブですら世界観を演出します。SEもまた世界観を持ちます。

音楽と絵の世界観は、不気味さを演出するのでない限りは合わせるべきです。が、これがなかなか難しい。特定の世界観を持たない演出を多用すれば音楽に合いはしますが、個性が潰れます。DTMを嗜む御仁や絵の描ける御仁は、自分の手の届かない、素材を使うしかない領域を先に作り、その世界観に合わせて柔軟に制作をしてみてはいかがでしょう。

しめ

コンテンツ内容とエフェクト、音楽と絵のように、複数の要素間で世界観を共有するのは非常に難しいことです。ディレクターの大事な役割の一つは、世界観を開発メンバーと共有し調節することなのでしょう。ここがアマチュアとプロの境界であり、マルチクリエイターの強みでもあるかと思います。

さいごに、細かい設定を練った末に出てくる些細なこだわりはオタクの心をくすぐる神演出になるものです。裏の設定を練りましょう。舞台裏を、世界を想像しましょう。

OUCC Advent Calender 2021 次回は izumi104 さんです!