子供向けプログラミング学習サービスQUREOの開発裏話

by yasuiro

Slide 1

Slide 1 text

子供向けプログラミング学習サービスの開発裏話アルゴ

Slide 2

Slide 2 text

自己紹介鈴木康弘（すずきやすひろ）@yasuiro ・Web制作会社を経て2014年Cyberagentグループに入社・2016年よりApplibotにてQUREOの立ち上げに携わる・元Flashエンジニア。現在はFrontend界隈を中心に活動しています。・最近の興味はfacebook の instant gameとか

Slide 3

Slide 3 text

話すこと・QUREOってどんなサービス？・開発体制とシステム構成・ブロックプログラミングの実行について・画像同士の衝突判定について具体的なコードの説明等は、ほとんどありません新規開発におけるトライ&エラーを中心にお話させていただきます

Slide 4

Slide 4 text

QUREOってどんなサービス？

Slide 5

Slide 5 text

https://youtu.be/zOk9o1fB0e4

Slide 6

Slide 6 text

・子供向けオンラインプログラミング学習サービス・ゲームを作りながら、プログラミングの基礎を学んでもらう・ビジュアルプログラミングによる学習方法を採用・現時点で300レッスン程あり、最終500レッスン位になる予定 https://qureo.jp 「簡単で」「おもしろく」「学べる」

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

開発体制とシステム構成

Slide 10

Slide 10 text

フロント2名〜5名サーバーサイド1名〜2名デザイナー1名プロデューサー1名ディレクター1名カリキュラマー3名〜4名開発体制 1年開発期間

Slide 11

Slide 11 text

システム構成図

Slide 12

Slide 12 text

使用ライブラリー React,Redux,webpack,express,pixi.js,tone.jsなどなど

Slide 13

Slide 13 text

ブロックプログラミングの実行

Slide 14

Slide 14 text

ビジュアルプログラミング用のブロック表示部分は Google Blocklyというライブラリーを使用していました。 https://developers.google.com/blockly/

Slide 15

Slide 15 text

・文字列として様々な言語を書き出す仕組みが備わっている・プログラムを実行する機能は備わっていない・独自のブロックを定義することも可能・表示はSVGで行われている・ブロックの形をカスタムする機能は備わっていない Blocklyとは Googleが開発しているビジュアルプログラミング用のライブラリ

Slide 16

Slide 16 text

ブラウザ上で実行できる言語って？

Slide 17

Slide 17 text

Javascript ブラウザ上で実行できる言語って？

Slide 18

Slide 18 text

なんとかしてJavascriptを実行できる形にしないといけない。

Slide 19

Slide 19 text

Try1

Slide 20

Slide 20 text

生成したJSをscriptタグで差し込む方法 Try1

Slide 21

Slide 21 text

生成したJSをscriptタグで差し込む方法差し込んだjsをリセットするのがしんどい Try1

Slide 22

Slide 22 text

Try1 生成したJSをscriptタグで差し込む方法差し込んだjsをリセットするのがしんどい

Slide 23

Slide 23 text

Try2

Slide 24

Slide 24 text

js-interpreterと呼ばれるライブラリーを使用して実行する https://github.com/NeilFraser/JS-Interpreter Try2

Slide 25

Slide 25 text

js-interpreterと呼ばれるライブラリーを使用して実行する実行自体は良い感じカスタム定義のメソッドの実行ハンドリングがしにくい数が少なければまだなんとかなりそうですが、今回の要件では数も多くなりそうなので厳しそう https://github.com/NeilFraser/JS-Interpreter Try2

Slide 26

Slide 26 text

Try2 js-interpreterと呼ばれるライブラリーを使用して実行する実行自体は良い感じカスタム定義のメソッドの実行ハンドリングがしにくい数が少なければまだなんとかなりそうですが、今回の要件では数も多くなりそうなので厳しそう https://github.com/NeilFraser/JS-Interpreter

Slide 27

Slide 27 text

Try3

Slide 28

Slide 28 text

独自言語を開発する Try3

Slide 29

Slide 29 text

独自言語を開発するスケジュール的に無理 Try3

Slide 30

Slide 30 text

Try3 独自言語を開発するスケジュール的に無理

Slide 31

Slide 31 text

Try4

Slide 32

Slide 32 text

scratch-blocksとscratch-vmを使用した実行環境 https://github.com/LLK/scratch-blocks https://github.com/LLK/scratch-vm Try4

Slide 33

Slide 33 text

scratch-blocksとscratch-vmを使用した実行環境これが一番安定・scratchのオープンソースなコードということもあり、　実装したかった基本的なメソッドは、ほぼ定義されている・ブロックの見た目もわかりやすい https://github.com/LLK/scratch-blocks https://github.com/LLK/scratch-vm Try4

Slide 34

Slide 34 text

scratch-blocks ・MITがBlocklyをベースに開発している　ビジュアルプログラミングライブラリー・scratch-vmを使用することを前提としている。 scratch-vm ・scratch-blocksと連動してscratch-blocksのブロックコードを　実行するVirtualMachine ・jsで作られているためブラウザ上で実行できる scratch-audio、scratch-rendererなどもありますが、そこは別のライブラリーに置き換えて使用しています。 Try4

Slide 35

Slide 35 text

Blockly ↓ Javascript文字列に変換 ↓ 何かしらの方法で実行できる形にする ↓ 実行文字列に変換しているフローがないため evalなどを使用する必要がなくセキュリティ面でも安心 scratch-blocks ↓ AST（内部的には配列として扱っている） ↓ scratch-vm ↓ 実行 Try4 今までの流れ

Slide 36

Slide 36 text

導入するにあたって問題点・まだ正式リリースしているバージョンがない・当時、変数・リスト・関数の実装が　まだされていなかったので、　自前で実装する必要があった・自分たちの要件に合わせてチューニングする必要があった Try4

Slide 37

Slide 37 text

最終的にたどり着いた構成現時点ではこれらを採用しています　block部分　scratch-blocks(Blockly) 　vm部分　scratch-vm 　renderer部分　pixi.js 　audio部分　tone.js Try4

Slide 38

Slide 38 text

scratch-blocks pixi scratch-vm

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

画像同士の衝突判定

Slide 41

Slide 41 text

要件1 透過部分は衝突させたくない要件2 今後専用のお絵かきエディタを実装する予定があり、ユーザーが自由に素材を作成できる機能が入る要件3 画像は縦横比を保ったまま拡大縮小される

Slide 42

Slide 42 text

↑事前に判定用のパスデータ等を作成しておくことができない要件1 透過部分は衝突させたくない要件2 今後専用のお絵かきエディタを実装する予定があり、ユーザーが自由に素材を作成できる機能が入る要件3 画像は縦横比を保ったまま拡大縮小される ←やっかい

Slide 43

Slide 43 text

矩形同士の判定であればすごくシンプル

Slide 44

Slide 44 text

透過部分が重なっている場合でも判定されてしまう

Slide 45

Slide 45 text

案1 事前に判定領域をパス情報として用意する

Slide 46

Slide 46 text

判定領域用のパスを保持するようにしようと思いましたが “ユーザーが自由に素材を作成できる機能が入る” という要件があったため厳しそう

Slide 47

Slide 47 text

判定領域用のパスを保持するようにしようと思いましたが “ユーザーが自由に素材を作成できる機能が入る” という要件があったため厳しそう

Slide 48

Slide 48 text

判定領域用のパスを保持するようにしようと思ったが “ユーザーが自由に素材を作成できる機能が入る” という要件があったため厳しそう

Slide 49

Slide 49 text

案2 ピクセルレベルでの判定

Slide 50

Slide 50 text

ブロードフェーズとナローフェーズに分離

Slide 51

Slide 51 text

ブロードフェーズは矩形領域での判定

Slide 52

Slide 52 text

ブロードフェーズは矩形領域での判定当たった

Slide 53

Slide 53 text

ナローフェーズで重なった領域のみピクセル単位で判定

Slide 54

Slide 54 text

処理が重いナローフェーズで重なった領域のみピクセル単位で判定

Slide 55

Slide 55 text

処理が重いナローフェーズで重なった領域のみピクセル単位で判定

Slide 56

Slide 56 text

案3 前処理&判定エリアの簡略化

Slide 57

Slide 57 text

リアルタイムピクセル判定は厳しい一度だけ前処理をすることでリアルタイム判定を軽くできないか？

Slide 58

Slide 58 text

ブロードフェーズの判定はそのままに一度だけピクセルデータを解析する方法に変更ピクセルデータはWebGLのreadPixelsで参照可能です

Slide 59

Slide 59 text

画像をロードしたタイミングで正方領域に分割し領域内の透過ピクセル数の比率で、領域を衝突判定領域とするかを決定するこの時、分割最大数を決めることで画像のサイズに応じて分割数が多くならないようにしています。

Slide 60

Slide 60 text

判定領域としない判定領域とする画像をロードしたタイミングで正方領域に分割し領域内の透過ピクセル数の比率で、領域を衝突判定領域とするかを決定するこの時、分割最大数を決めることで画像のサイズに応じて分割数が多くならないようにしています。

Slide 61

Slide 61 text

判定領域を算出

Slide 62

Slide 62 text

計算しやすいように判定領域を矩形ではなく円にする

Slide 63

Slide 63 text

隙間を埋める

Slide 64

Slide 64 text

円同士の衝突判定をする距離関数（三角関数）で判定できるため、計算量が少なくなります

Slide 65

Slide 65 text

判定領域を円にすることで拡大縮小や回転への計算も対応しやすくなる行列を使用することで容易に対応できる

Slide 66

Slide 66 text

こういった場合は衝突とみなさなくなった

Slide 67

Slide 67 text

この場合は衝突とみなすようになった良い感じの判定

Slide 68

Slide 68 text

この場合は衝突とみなすようになった良い感じの判定

Slide 69

Slide 69 text

・パフォーマンスと判定のバランスが良い・精度的には落ちる部分はあるが　問題ないレベル

Slide 70

Slide 70 text

・パフォーマンスと判定のバランスが良い・精度的には落ちる部分はあるが　問題ないレベル

Slide 71

Slide 71 text

最後に

Slide 72

Slide 72 text

サービスならではの特殊な部分が多かったと思いますが何か少しでも参考になる点があれば幸いです QUREOの立ち上げは手探りな部分が多く、本当に大変でした。スケジュールとの戦いで、何をどこまで力を入れていくかなどの、取捨選択を迫られる部分も多くありました。

Slide 73

Slide 73 text

QUREOではこれからのプログラミング教育を共に考え、未来のスーパーエンジニアを輩出できるようなサービスを作り上げていく仲間を募集しています！ https://www.applibot.co.jp/recruit/

Slide 74

Slide 74 text

ご静聴ありがとうございました