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

2018/7/6に行われた、Frontrend vol12 で発表したスライドになります。

Transcript

1. 子供向けプログラミング学習サービス の開発裏話 アルゴ
2. 自己紹介 鈴木 康弘（すずき やすひろ）@yasuiro ・Web制作会社を経て2014年Cyberagentグループに入社 ・2016年よりApplibotにてQUREOの立ち上げに携わる ・元Flashエンジニア。現在はFrontend界隈を中心に活動しています。 ・最近の興味はfacebook の instant gameとか
3. 話すこと ・QUREOってどんなサービス？ ・開発体制とシステム構成 ・ブロックプログラミングの実行について ・画像同士の衝突判定について 具体的なコードの説明等は、ほとんどありません 新規開発におけるトライ&エラーを中心にお話させていただきます
4. QUREOってどんなサービス？
5. https://youtu.be/zOk9o1fB0e4
6. ・子供向けオンラインプログラミング学習サービス ・ゲームを作りながら、プログラミングの基礎を学んでもらう ・ビジュアルプログラミングによる学習方法を採用 ・現時点で300レッスン程あり、最終500レッスン位になる予定 https://qureo.jp 「簡単で」「おもしろく」「学べる」
9. 開発体制とシステム構成
10. フロント2名〜5名 サーバーサイド1名〜2名 デザイナー1名 プロデューサー1名 ディレクター1名 カリキュラマー3名〜4名 開発体制 1年 開発期間
11. システム構成図
12. 使用ライブラリー React,Redux,webpack,express,pixi.js,tone.jsなどなど
13. ブロックプログラミングの実行
14. ビジュアルプログラミング用のブロック表示部分は Google Blocklyというライブラリーを使用していました。 https://developers.google.com/blockly/
15. ・文字列として様々な言語を書き出す仕組みが備わっている ・プログラムを実行する機能は備わっていない ・独自のブロックを定義することも可能 ・表示はSVGで行われている ・ブロックの形をカスタムする機能は備わっていない Blocklyとは Googleが開発している ビジュアルプログラミング用のライブラリ
16. ブラウザ上で実行できる言語って？
17. Javascript ブラウザ上で実行できる言語って？
18. なんとかしてJavascriptを実行できる形にしないといけない。
19. Try1
20. 生成したJSをscriptタグで差し込む方法 Try1
21. 生成したJSをscriptタグで差し込む方法 差し込んだjsをリセットするのがしんどい Try1
22. Try1 生成したJSをscriptタグで差し込む方法 差し込んだjsをリセットするのがしんどい
23. Try2
24. js-interpreterと呼ばれるライブラリーを使用して実行する https://github.com/NeilFraser/JS-Interpreter Try2
25. js-interpreterと呼ばれるライブラリーを使用して実行する 実行自体は良い感じ カスタム定義のメソッドの実行ハンドリングがしにくい 数が少なければまだなんとかなりそうですが、 今回の要件では数も多くなりそうなので厳しそう https://github.com/NeilFraser/JS-Interpreter Try2
26. Try2 js-interpreterと呼ばれるライブラリーを使用して実行する 実行自体は良い感じ カスタム定義のメソッドの実行ハンドリングがしにくい 数が少なければまだなんとかなりそうですが、 今回の要件では数も多くなりそうなので厳しそう https://github.com/NeilFraser/JS-Interpreter
27. Try3
28. 独自言語を開発する Try3
29. 独自言語を開発する スケジュール的に無理 Try3
30. Try3 独自言語を開発する スケジュール的に無理
31. Try4
32. scratch-blocksとscratch-vmを使用した実行環境 https://github.com/LLK/scratch-blocks https://github.com/LLK/scratch-vm Try4
33. scratch-blocksとscratch-vmを使用した実行環境 これが一番安定 ・scratchのオープンソースなコードということもあり、 　実装したかった基本的なメソッドは、ほぼ定義されている ・ブロックの見た目もわかりやすい https://github.com/LLK/scratch-blocks https://github.com/LLK/scratch-vm Try4
34. scratch-blocks ・MITがBlocklyをベースに開発している 　ビジュアルプログラミングライブラリー ・scratch-vmを使用することを前提としている。 scratch-vm ・scratch-blocksと連動してscratch-blocksのブロックコードを 　実行するVirtualMachine ・jsで作られているためブラウザ上で実行できる scratch-audio、scratch-rendererなどもありますが、 そこは別のライブラリーに置き換えて使用しています。 Try4
35. Blockly ↓ Javascript文字列に変換 ↓ 何かしらの方法で 実行できる形にする ↓ 実行 文字列に変換しているフローがないため evalなどを使用する必要がなく セキュリティ面でも安心 scratch-blocks ↓ AST（内部的には 配列として扱っている） ↓ scratch-vm ↓ 実行 Try4 今までの流れ
36. 導入するにあたって問題点 ・まだ正式リリースしているバージョンがない ・当時、変数・リスト・関数の実装が 　まだされていなかったので、 　自前で実装する必要があった ・自分たちの要件に合わせてチューニングする必要があった Try4
37. 最終的にたどり着いた構成 現時点ではこれらを採用しています 　block部分 　scratch-blocks(Blockly) 　vm部分 　scratch-vm 　renderer部分 　pixi.js 　audio部分 　tone.js Try4
38. scratch-blocks pixi scratch-vm
40. 画像同士の衝突判定
41. 要件1 透過部分は衝突させたくない 要件2 今後専用のお絵かきエディタを実装する予定があり、 ユーザーが自由に素材を作成できる機能が入る 要件3 画像は縦横比を保ったまま拡大縮小される
42. ↑事前に判定用のパスデータ等を作成しておくことができない 要件1 透過部分は衝突させたくない 要件2 今後専用のお絵かきエディタを実装する予定があり、 ユーザーが自由に素材を作成できる機能が入る 要件3 画像は縦横比を保ったまま拡大縮小される ←やっかい
43. 矩形同士の判定であればすごくシンプル
44. 透過部分が重なっている場合でも 判定されてしまう
45. 案1 事前に判定領域をパス情報として用意する
46. 判定領域用のパスを保持するようにしようと思いましたが “ユーザーが自由に素材を作成できる機能が入る” という要件があったため厳しそう
47. 判定領域用のパスを保持するようにしようと思いましたが “ユーザーが自由に素材を作成できる機能が入る” という要件があったため厳しそう
48. 判定領域用のパスを保持するようにしようと思ったが “ユーザーが自由に素材を作成できる機能が入る” という要件があったため厳しそう
49. 案2 ピクセルレベルでの判定
50. ブロードフェーズとナローフェーズに分離
51. ブロードフェーズは矩形領域での判定
52. ブロードフェーズは矩形領域での判定 当たった
53. ナローフェーズで重なった領域のみ ピクセル単位で判定
54. 処理が重い ナローフェーズで重なった領域のみ ピクセル単位で判定
55. 処理が重い ナローフェーズで重なった領域のみ ピクセル単位で判定
56. 案3 前処理&判定エリアの簡略化
57. リアルタイムピクセル判定は厳しい 一度だけ前処理をすることで リアルタイム判定を軽くできないか？
58. ブロードフェーズの判定はそのままに 一度だけピクセルデータを解析する方法に変更 ピクセルデータはWebGLのreadPixelsで参照可能です
59. 画像をロードしたタイミングで正方領域に分割し 領域内の透過ピクセル数の比率で、 領域を衝突判定領域とするかを決定する この時、分割最大数を決めることで 画像のサイズに応じて分割数が多くならないようにしています。
60. 判定領域としない 判定領域とする 画像をロードしたタイミングで正方領域に分割し 領域内の透過ピクセル数の比率で、 領域を衝突判定領域とするかを決定する この時、分割最大数を決めることで 画像のサイズに応じて分割数が多くならないようにしています。
61. 判定領域を算出
62. 計算しやすいように判定領域を矩形ではなく円にする
63. 隙間を埋める
64. 円同士の衝突判定をする 距離関数（三角関数）で判定できるため、 計算量が少なくなります
65. 判定領域を円にすることで 拡大縮小や回転への計算も対応しやすくなる 行列を使用することで容易に対応できる
66. こういった場合は衝突とみなさなくなった
67. この場合は衝突とみなすようになった 良い感じの判定
68. この場合は衝突とみなすようになった 良い感じの判定
69. ・パフォーマンスと判定のバランスが良い ・精度的には落ちる部分はあるが 　問題ないレベル
70. ・パフォーマンスと判定のバランスが良い ・精度的には落ちる部分はあるが 　問題ないレベル
71. 最後に
72. サービスならではの特殊な部分が多かったと思いますが 何か少しでも参考になる点があれば幸いです QUREOの立ち上げは手探りな部分が多く、本当に大変でした。 スケジュールとの戦いで、 何をどこまで力を入れていくかなどの、 取捨選択を迫られる部分も多くありました。
73. QUREOではこれからのプログラミング教育を共に考え、 未来のスーパーエンジニアを輩出できるようなサービスを 作り上げていく仲間を募集しています！ https://www.applibot.co.jp/recruit/
74. ご静聴ありがとうございました