軽量ライブラリを作成することにしました。ゲームの企画制作が進んでいる間に、ただただひたすらにJSライブラリの制作してnpmにpublishの作業が続きました。その当時の記事がこちらの記事となります。Private導入して、1ヶ月で8個ほどパッケージ作成したお話。こちらの開発環境は、Webpack、Gulp、TypeScript、Sass、mocha、chai、etc..と言った環境でありました。10個ほど作成し、ある程度揃って来たので「HTML5ゲーム本体」の方も作成を開始しました。web(HTML5)ゲーム制作10個ほど作成し、ある程度揃って来たので「HTML5ゲーム本体」の方も作成を開始しました。こちらの開発基盤は、Webpack、Gulp、TypeScript、Sass、Vue.js、JsonServer、mocha、chai、etc..と言った感じでした。JSフレームワークは、以前から、Angularを扱っていましたので、Angularを導入するか迷いましたが、やはり2.0になってフルスタックフレームワークになりすぎていて、スマホHTML5ゲームを作成するには容量がでかいのと、1.0の時のように気軽に導入できなくなっている印象だったので、「Vue.js」を選定しました。今ではすっかり定着している「Vue.js」なのですが、当時は今みたいに日本語ドキュメントやプラグインもまだ多くない時期で、なにかに行き詰まり、Googleさんで検索しても英語または中国語の記事にヒットしていました。1の時みたく、実装のしやすさを兼ね備えていて、導入(勉強)コストも高くなく、容量も多くないのでスマホHTML5ゲームを作成するには問題ないと感じたからでした。できると感じたからでした。スマホHTML5ゲームとなると、所謂一般的な「Webサービス」や「Webアプリケーション」などと比較しても、かなり多くのRPC通信を必要とされる事もあって「MVVMフレームワーク」の方が、圧倒的に実装が楽(時間短縮)であります。実際に、1ヵ月〜2ヶ月ほどで、スマホHTML5ゲームのリリースを求められ、スケジュールの遅延もなくリリースできました。あと、TypeScriptはもう4、5年程使用していて、ないと不安なところがあり必然的に導入されていますが、やはり型の導入は、フロントエンドエンジニアだけでなく、それ以外のエンジニア(サーバー、クライアント(ネイティブアプリ)エンジニア)に好かれる傾向がありますね。最低限のHTML5ゲーム制作の開発環境は整って来ました。あとはひたすら、ゲーム本体であるコンテンツ制作。ゲーム本体であるアーキテクチャは、CSSはアトミックベースである「APBCSS」で、JSはModel層、Component層、Class層、Service層となります。ViewModelレイヤーを設けず、Service層でRPC通信を行い、Model、ClassのFactoryを介しデータを整形、それらのModelをComponentに渡すと言った比較的シンプルな設計になります。基本ゲームロジックなどに関しては、フロントで抱えることなく、ゲームサーバーとのRPC通信し、アプリ側の情報が必要な際は専用コマンドを叩くRPC通信を介して、フロントはそれらの変更をレンダリングする事に注力しています。S3は静的コンテンツ(ファイル)のみ扱う事になりますので、SSRではなく初期リクエストが発生してしまう設計になります。過去にAndroid下位端末で、ルーティングのハッシュが正しく動作しない。言った事例を経験していたので不安要素もあってルーティングを使用しない、部分的なSPAの作りとなっています。おかげさまで、「これ、web(CanvasではないDOM)なの?」反応をいただく事ができ、長年やってきた技術を再びご披露することができました。毎度ながら、この反応は、恥ずかしながらいつまで経っても嬉しいものですね。S3の静的コンテンツ(ファイル)のみ扱える環境となります。故にずっと気になっていたところもありました。それは、「viewport」です。Canvasベースで作られていたら特に問題にならないかも知れませんが、「DOM(DHTML)ベース」で制作された「Web(HTML5)ゲーム」となると、コンテンツ表示の拡縮を容易に行うことができません。縦横の解像度のデバイスが様々存在します。これら縦横の解像度様々なAndroidデバイスにきちんと横縦幅いっぱいに表示するとなると、レスポンス対応にするか、拡縮するならCSSのscaleか、viewportで行うか..と言った選択肢になります。480pxだと狭すぎる)との意向もありましたので、iPhone5のサイズ固定で縦横拡縮。縦比率がベースより少ない場合は、縦基準でいっぱいになる拡縮率を設定。横比率がベースより少ない場合は、横基準でいっぱいになる拡縮率を設定。これが、横のみだったり、webもAutoLayoutが手軽にできる環境であればそんなに悩むことはないのですが、そうも行かないのがwebですね。いうわけで、ゲームUIを作成する上で、レスポンス対応は非現実、CSSのscaleを行うとevent発生のpositionがずれるバグが発生したりする。いう事で、viewportで拡縮を行う選択肢となります。静的コンテンツ(ファイル)のみ扱える環境なので、viewportを動的に変更するのはJavaScriptで行うこととなるのですが、こちらJavaScriptでviewportを変更すると、機種やOSによって適切な表示にならない事が発生する事例は以前から把握していて、今回は致し方なしに行っていたのですが、やはりその事例は発生してしまいました。詳細は忘れましたが、iPad(OSバージョンで発生した)やAndoroid機種で発生して、やはり以前から行っていたようにサーバーサイドレンダリングが必要となったのでした。いう事で、AWSのEC2の導入を検討したのですが、やはり運用コストがかかってしまうのがネックでした。そこで、運用コストのかからないサーバーレス環境であるAWSのLambdaの導入を決めました。言語はPython3系、webフレームワークは無難にDjangoを選択しました。枠をインフラチームに用意してもらい、ガリガリと構築。ここで、通常であればDjangoの方にフロントのAssetsファイルを配置してLambdaのみで完結するのですが、それだと今までの構成と大幅に変更されるのと、万が一、サーバーレスの方で問題が発生した際に回避できるように、フロントのAssetsファイルはそのままS3に格納しLambda側でファイルを取得したいな。思って調べていると、APIGatewayが必要なのでそちらも準備しました。構成は以下のような感じとなりました。S3の方にそのままアクセスしても表示し、APIGatewayのURLを叩くと、Lambdaを介してS3のファイルを取得し、viewportの処理を行いレンダリングする作りとなっています。URLは「〜/dev/」で開発用(S3)環境のAssetsを取得、「〜/prod/」で本番用(S3)環境のAssetsを取得するようになっています。Django使う必要もないなと思いつつ、時間があったら見直そうかと思っております。1アプリのwebビューで表示される「Web(HTML5)ゲーム」つまり、1コンテンツのお話であって、それ以外にもWebで表示するコンテンツもあるし、また会社が提供するiOS、Androidアプリもこれ以外も存在し、そこにもWebビューで表示するコンテンツや、公式サイトなどもあります。お仕事は比較的楽だったかもしれませんが、そんなに若くもないので、年齢的、立場的にも、自然とその他のWebコンテンツを見ることを求められてきます。WordPress環境移行この頃から、メンバーも増え自分一人では時間確保できず、やりたくても行えなかった環境整備も行えるようになってきて、「lintとかも入れたいんだよねぇ。」と相談すると、バッチリ入れてくれたりして、更にHTML5ゲーム制作の開発環境もパワーアップしてきたのでした。追加されていきました。やっていると、インフラチームからご相談が来まして、「WordPressの運用コスト(費用も)が高い」と言った内容でした。WordPress利用しているのは把握していたのですが、きちんと数や費用まで把握していなかったのですが、そこそこの数のWordPressを利用していてかなりの費用もかかっている様子でした。PHPのバージョンを上げるにも大変なのでなんとかしてほしいとの事で、色々と検討した上でクラウドサービスである「WordPress.com」への移行を決定しました。こちらも、メンバーの方に行ってもらい、無事ほぼほぼ全部移行することができました。運用コストもなくなった訳ですが、運用にかかる費用もびっくりするぐらい安くなりました。複数WordPressを運用していて、運用の費用が嵩んでいる場合、WordPress.comの移行を検討しても良いかもですね。「Web(HTML5)ゲーム」制作に集中していたのもあって、周りがどんな環境で、どういった構造で作成されているのか把握できていなかったのが正直なところでした。「Web(HTML5)ゲーム」以外の環境で、当方もコンテンツ制作を行うことによって、色々と問題点も把握できてきました。複数のアプリが存在して、webビューで作られたコンテンツも存在する形となります。単純なお知らせ系のページであったり、イベントの結果ページであったり、アプリ側と少し絡んだページだったりと、大小複数のページが存在しています。そのページは、カテゴリ別にディレクトリで切られている状態となります。以下のように、1レポジトリにカテゴリ別に複数のディレクトリが存在する状態です。そのディレクトリ毎に、gulpfileが存在してしまっている状況だったので、1つのwebpackにまとめられないかメンバーに作業を相談いたしました。packageですが、「Web(HTML5)ゲーム」で使用のみならず、こちらのページ用でもinstallして使っていただけるように作成したのですが、きちんと使用されていない状況でした。npmでもきちんと管理出来るようにその辺も整備していただきました。SCSSのコンパイルもwebpackに含め、(packgejsonのscriptと絡め)完全にgulpに頼らない方向でお願いしました。上記の記述したように、お知らせのみの完全にJavaScriptの必要ないページだけなら良いのですが、JavaScriptが必要な、RPC通信後DOMの書き換えするページなどもあるため、良い効率よく制作出来るように、「lodashのテンプレート」や、その他のテンプレートエンジンで効率よく制作できないかも検討しました。結果、テンプレートエンジンには「pug」を導入しました。configファイル1つでそれぞれのコンテンツをビルドする仕組みをメンバーがピシャリ作ってくれました。以下の様な形となります。いざ、自分も制作作業に入ってみると、いくつか改善したほうが良さそうな点が出てきました。Module化しているが、他プロダクトなどで使用するとなると、コピペで適応となってしまうので、管理性が良くない。EntryPointにしているJavaScriptファイルが必要となってしまう。・lodashのテンプレートを用いたとしても、そこそこscriptを書かないといけない。(いうほど効率化を計れない)と言った点でした。Module化していただきました。Moduleが存在する形です。変更の度に「差分見て適応。」みたいな作業が発生してしまいます。これを避けるために、npmプライベートに登録することに決めました。こちらは、現在も選定中で作業はまだ終わっていない状態です。続いて、「SCSS」問題です。wevpack本来の1つのファイルにbundleする理念とそれてしまうのですが。上記でも書いたように、カテゴリによっては、JacaScript無しのページも存在するので、SCSSのみ使用のみ使用したいのにJavaScriptファイルも用意しないといけないとなると、何かと煩わしいです。そこで、よりWebpackを「静的コンテンツジェネレーター化」するために、SCSSは別のconfigを設けbundleすることにしました。詳細はどこかで書ければとは思っております。最後に、lodashのテンプレートですが、こちらを用いたとしてもあんまり効率化が図れていないな。感じましたので、「Web(HTML5)ゲーム」でも使用している「Vue.js」の導入を決定しました。こちらも、ページによってはそんなにJavaScriptの処理が必要ないページもあるのと、もし仮にもっと優れJavaScriptフレームワークが登場した際に、容易に乗り換えなど行えるように、Vue.jsを別ディレクトリとして設けました。以下の様な形となります。通常のJavaScriptと、Vue.jsは別々のbundleファイルが出力される形となります。各プロダクト(アプリ)の中には、グローバルでリリースしているアプリも存在し、言語も各国の言語で表示しております。webコンテンツの方も同様で、各国の言語別に表示する必要があります。i18n(国際)化の対応まではできていなく、各言語別に静的なHTMLが存在する形となっておりました。AppsScriptをメンバーが書いていましたので、そのままJSON形式としました。こちらも、近日まとまる形となりますので、楽しみでもあります。Configファイルのテンプレート化と、ここまで色々と開発基盤の作成を行ってきたのですが、また問題が発生しました。Config系のファイルの管理です。packge(private)」でも複数存在するし、「各プロダクト(アプリ)のwebコンテンツ」でも、アプリ別に存在する状態となります。template」のレポジトリも設けました。cherry-pick」で更新していく運用を取り入れております。「config」リモートを追加。コミットID最後にというわけで、今回は1年ちょいゲーム制作しながら開発環境の構築を行ってきたのを振り返ってみました。振り返って見ると、当初よりも色々と揃ってきて開発環境も大分整ってきました。いえ、前々まだまだ構築しないといけない箇所は存在していて、一緒に構築していってくれる仲間も募集しております!w(いきなり募集)何度か「無理かな。