Zenn
Open8

Butabako 開発日記 - インパクトと成果物の完成度重視のビジュアルプログラミングツール

ツール
Three.js
プログラミング教育
rapier
開発日記
KorangeKorange

概要

https://u22procon.com/
このコンテストに応募予定の作品として、Scratchのような感じのプログラミング学習ツールを作成する。
後から制作過程を振り替えれるようにここに過程を記録していきます。
途中で諦めてやめるかもしれませんが、よろしくお願いします🙏

（他のユーザーの投稿も歓迎しているので、何か意見などあれば気軽に投稿してくれると嬉しいです）

KorangeKorange

詳しく特徴や決めていること（予定）

まず一番重要なのはユーザーのモチベーション維持だと考える。

  • 3D空間
    • ビジュアルのインパクトが重要だと考え、3D空間を使った作品を作るものにする。Scratchなどは2Dステージの中でスプライトを動かすものなので、差別化（というより別物？）になる。
    • 3D空間内で簡単に作業（操作）する体験をMinecraftのクリエイティブモードの操作体験から参考にする。ユーザーは空間内で浮遊してオブジェクトを配置したりできる。
      • 個人的にBlenderやUnityのような中心を中心に回ったりズームしたり、中心を動かすような操作はちょっとやりずらい
    • 技術的には、Three.jsなどで実現できそう
      • ちなみに、Web上でThree.jsを使ったプロジェクトを調べた結果面白いものを見つけた:
  • プログラミング自体の要素
    • Scratchのようなブロックベースのプログラミングを採用する予定。タイピングの時間を省略しすぐできるのは良いと思う。
  • コミュニティ機能
    • 自分の作品を見てもらえることはかなり重要だと思うので、作品を公開できるコミュニティ機能を搭載する。
    • また、ランキングなどで格差ができるのではなく誰もが自分の作品を見てもらえるような仕様にしたい。
KorangeKorange

Three.js お試し

https://www.youtube.com/watch?v=sPereCgQnWQ
この動画などを参考にThree.jsでキーボードで動ける環境を作った。

まだ物理演算が無いので落下したりはしない。次は何らかの物理演算ライブラリを導入して物理演算するようにしたい。（やっぱりThree.jsって単なる3D描画エンジンってことなのね）

物理エンジン 選定

調べてみた感じこの２つが有名そう。

ただどちらも最終コミットが２年前くらいなのが気になる。どうしたものか

KorangeKorange

物理エンジン

  • Rapier.js
    これを使ってみる。元はRust製だがWASMによりJavascriptから使えるらしい。
KorangeKorange

思いついたアイデアを記録する

< ステージ(Stage)と舞台裏(Backstage) の概念 >

ゲームなどの開発では起動時に静的に画面に出しておきたいオブジェクトと、動的にプログラムで出したいオブジェクトがあったりする。また弾などは同時に複数個出したかったりするケースが有る
（Scratchは表示/非表示とクローンの概念でこのようなことができるようになっている）

→ このプロジェクトではこれを実現するためにステージと舞台裏の概念を導入する予定。
作品で使うオブジェクトは全部舞台裏に配置しておき、手動で事前にステージにドラッグして配置しておくと起動時に最初から出てくるようにする。
ステージに配置するのはプログラムから動的にもできる。また少し分かりづらいかもしれないがステージには無限に配置できるし、配置しても舞台裏に残る（未定点かも）

（ただこれを実装した場合表示/非表示の機能と少し見た目分かりづらくなるかも？）
※ 思いついただけなので変えるかも

KorangeKorange

やっぱりStageに出してもOffstageに残るのは分かりづらそうなので、単純に動画編集ソフトのメディアプールみたいな感じで「アセット」みたいにするのが良いかも

KorangeKorange

プロダクト名

プロダクト名をButabako<ブタバコ>とする。 もしかしたら変えるかもしれないが、とりあえずこれで決める。

ロゴデザイン仮

没ロゴ


没理由：可愛い感、子供向けっぽさが強すぎるかも

Font: Rubik

KorangeKorange

難しいポイント

Three.js のシステムはそれなりに複雑で、それを理解したうえで Three.js のシステムを自作のレールにうまく落とし込む必要がある。

例えばブラウザのウィンドウのサイズを小さくして画面に表示すべきサイズが変わった場合、
resizeイベントを受け取る -> canvasのサイズを変える -> threeのwebGLRendererのアスペクトを変える -> threeのscene内のcameraのアスペクトを変える
と情報を伝播することになる。この流れがスムーズにできるように設計するのが難しい。

一度に全部を完成させることはできないのでコードベースが仮止めだらけになっている。

サイト側の集客とかUXとかチュートリアルとか様々なアイデアが浮かび上がって入るが、そこに手を付けるのはしばらく先になりそうだ