HTML5

HTML5講座 第二講 ~ゲーム業界のHTML5対応とHTML5の利点~

  • このエントリーをはてなブックマークに追加

by [2013年9月20日]

第一講ではHTML5が従来のHTML 4.01からどう変わったのか、何故変わるのか、HTML5はイケていないというのは本当なのか、について見てきました。第二講ではHTML5をめぐるゲーム業界の動向と、HTML5のメリット、そしてHTML5の具体的な変更点などについて扱います。

 第一講「HTML5の変更点とHTML5の意義」
 第三講「HTMLの歴史とタダで使えるHTML5開発環境」

ゲーム業界ではHTML5への対応が急速に進んでいる

Nintendo Web Frameworkの概要に触れた公式ページ(https://gdc2013.nintendo.com/)
2013年8月末の時点ではUnity for Wii Uの情報と共に概要とGDC2013でこれについてのセッションがあることが案内されている程度しか書かれていない。

日本では、やや普及が遅れているHTML5ですが、海外の現状を見ると、HTML5でWebコンテンツ作成を行う/支援するためのソフトウェアの開発発表が相次いでいます。

特にゲーム関係では、あの任天堂が今ひとつ不振のWii Uのてこ入れ策の一つとして、HTML5+JavaScriptでWii U用ゲームアプリを開発するための「任天堂ウェブフレームワーク(Nintendo Web Framework:NWF)」と呼ばれる開発環境を無償提供することを正式に発表し(※Wii Uの標準搭載Webブラウザは現時点で既にHTML5サポートが行われていますが、NWFへの対応として、これとは別に新しいHTML5対応Webブラウザが開発・提供されることが明らかにされています)、大きな反響を呼びました。

また、海外の有力ソフトハウスがC++で書かれた(つまり実行形式として各CPUのネイティブコードによるバイナリファイルが生成される)既存の実績ある3Dグラフィック描画エンジンをHTML5+JavaScript+WebGLの組み合わせにより、半自動的にソースコード変換をして移植、これを利用して書かれたFPS(First Person Shooting:一人称視点によるシューティングゲーム)のデモ展示を行い、同条件のハードウェア環境において、C++で書かれたネイティブコードのアプリと遜色ない速度(最大30~90fps程度)での動作をアピールするなど、この1年、いやここ半年の間にゲーム開発のプラットホームとしてのHTML5を取り巻く状況は一変しつつあります。

前者はともかく後者は、その前提となるHTMLブラウザの動作する環境、つまりスマートフォンやパソコンなどの(特にCPUおよびGPUの)急速な性能向上による下支えあればこその結果ですが、Webブラウザ上において動作する、HTML5を用いて書かれたWebアプリとしてのFPSゲームがネイティブアプリに全く遜色のない、実用に足るパフォーマンスを発揮できるようになった、というのは「WebコンテンツとしてのゲームはFlash技術を用いないと駄目だ」という風潮を打ち消しHTML5の普及を推進する上で、非常に大きな朗報でしょう。

実際問題として、ハードウェアの性能さえ十分ならばHTML5で書かれたWebアプリでもネイティブアプリに充分対抗しうるパフォーマンスが得られる様になってきている、というのは特定のCPUの命令セットに依存しない、という1点だけでもHTML5を開発のターゲットとする大きな理由(※開発者の学習の必要性の軽減)となりえます。

任天堂 Wii U
任天堂が開発した現行最新の家庭用ゲーム機
決して突出した高性能ではないが、HTML5対応ブラウザが提供されるなど、Web環境で最新の仕様を充足する。

なお、PlayStation 3では未だに標準搭載のWebブラウザのHTML5対応が進んでいない(※もっとも、PlayStation 3用標準搭載Webブラウザは、HTML5を無視する一方で、Flash技術には当初から対応しています)ソニー・コンピュータエンタテインメントでさえ、PS Vitaの内蔵WebブラウザではHTML5への対応が行われ、ヨーロッパでHTML5版PS Storeのテスト公開(https://store.sonyentertainmentnetwork.com/#!/)を行うなど、水面下でHTML5対応への準備が急速に進んでいることを示唆するような状況となっており、ゲームアプリにおけるHTML5への対応は、メーカー・機種を問わず本当に急速に進んでいると言えます。

このあたり、ゲーム業界では「考えてから走る」よりも「走りながら考える」タイプの開発方針、つまり可能な限り早く(未完成のものを含めた)新技術・新規格のキャッチアップを図る策が採られることが多く、それが更に状況を混沌とさせている面があるのですが、ことこのHTML5については、開発スタートのタイミングを逃すと、技術的なノウハウの蓄積あるいは市場占有面で先行組に追いつき追い越すのが難しくなる阻止限界点は、もう目前まで迫っているように見えます。

HTML5の重要なメリット

それでは、通常のWebコンテンツでHTML5を導入することによるメリットにはどのようなものがあるのでしょうか。

最も大きな恩恵となるのは、HTML5+Javascript+CSS3を適切に解釈・処理できるWebブラウザさえ用意できさえすれば、特別な機種判定のためのコードを埋め込んで特定機種以外を排除するような設計にしない限り、原則的にどのようなハードウェア上でも動作が期待できることと、既存のApp storeやGoogle Playなどに対応した各OSネイティブのアプリとは異なり、この種のアプリはWebアプリとなるため基本的にはOS開発元の支配から自由である(つまりアプリの配布・公開にあたってOSメーカーから課金されません。ただし、パッケージングを行ってApp StoreやGoogle Playで販売するアプリとして構成することも可能です)、ということの2点です。

少なくとも、iOSやAndroid OSの上でHTML5対応のWebブラウザが存在する限り、それらのブラウザ上でHTML5で書かれたWebアプリの動作を妨げることも、OS開発元の都合で公開を禁ずることもできません。

HTML5でアプリを作成する場合、特定のプロプライエタリなプラグインソフトの導入を要求せず、またアプリの開発言語がJavascriptとなるため、特定のCPUの命令セットに依存しないHTML5は、対応機種を局限して開発リソースの集約が図れ、また後述するように開発工数を減らすことができる、という点で開発者にとって大きなメリットがあると言えます。

具体的に言えば、この技術に対応するブラウザが搭載されたXbox 360でもWii UでもPS VitaでもAndroidスマートフォンでも、それからWindowsパソコンでも、CPUや各OSの提供するAPIのばらつきなどを考慮せず、原則的には同じように動作・表示されることが期待できる、ということです。

WebGLの規格策定にかかわっているKhronos Groupが開設している公式ページ(http://www.khronos.org/webgl/)
「OpenGL ES 2.0 for the Web」とWebGLの本質をストレートに示した表記が目を引く。

ただし、現状ではこのメリットを享受するのはまだまだ難しく、筆者がチェックしてみた範囲でも、各OS、各ブラウザごとに大きな挙動差が残っていますし、例えば3Dグラフィック描画にはWebGLの導入・サポートと、これに対応するGPU環境(※OSのデバイスドライバなどを含む)が用意されていなければ、そもそも正常な動作が期待できません。また、WebGLには当初、仕様上回避のできない深刻なセキュリティホールが存在した(これは概ねブラウザ側の対策で解決されました)こともあり、先に挙げたWii UのNWFは最初のバージョンではこのWebGLをサポートしない、つまり3Dグラフィック描画をサポートせずグラフィック描画が実質的にCanvasによる2Dグラフィック描画に限定されることがアナウンスされています。

そのため、アプリ側でWebブラウザがどの機能をサポートするのか、どのバージョンのOS上で動作しているのか、などは必ずチェックしておく必要があります。

このあたりの動作環境側の互換性問題はネイティブアプリでもかなり厄介なもので、機能的にはサポートされていても、実用上十分な速度が得られないケースも多々あるのですが、それでも互換性問題をブラウザレベルに落とし込んで

もちろん対応Webブラウザと必要な拡張機能のサポートがなされていても、そのアプリを利用したいマシンがアプリの要求する画面解像度やプロセッサの処理能力など、といったハードウェア的な必要条件を満たさない場合(※これは通常のネイティブアプリでも同様ですが)には正常動作を期待できません。

HTML5への移行による工数削減効果は予想以上に大きい

冒頭でも触れましたが、HTML5は様々な歴史的経緯から煩雑になっていたDOCTYPE(※HTMLの母体となったSGMLの仕様を引き継ぎ、定義の際にDTD(Document Type Definition:文書型定義)の参照が必要だったことに起因します)をはじめとする各種定義やJavascriptの宣言などを中心に、タグの記述が大幅に簡素化されました。

これは直に手でHTMLのタグを打っている人間にとっては非常に有り難い改良ですが、それだけではなくWebページ作成ツールを使用している場合でも、ページが意図通りに表示されない場合のソースコードチェック時の見通しが大幅に改善される、という点で有用な改善です。

また、従来はその機能が標準で用意されていないためにJavascriptなどで別途書式チェックのためのコード記述を行わねばならないことの多かった、入力フォーム機能が大幅に強化されて、書式チェックもガイド表示も、それに文字の補完入力を行うオートコンプリート機能も、ことごとくHTMLのタグだけで実現できるようになりました。ことに、誤入力されやすく様々なシチュエーションを想定してコードを用意する必要があったemailアドレス入力の構文チェックがinputタグへの属性一つの追加で済むようになったのは、感動的ですらあります。

このため、よほど特殊な場合を除くと、入力フォームについてはHTML 4.01時代よりも格段に簡潔なコード記述で、それも多機能なフォームが構成できるようになっています。

タグや属性の整理・削除が断行されたHTML5

HTML5での重要な変更点として、従来のHTML 4.01以前で問題となっていた、同一の動作が得られるタグが複数存在している、あるいはhtmlファイル本体のタグやその属性とスタイルシートの制御内容とがバッティングすることがある、という問題の解消があります。

まず、文字修飾で用いられていたタグ(※basefont・big・center・font・strike・tt)
が削除されてスタイルシート(CSS3)による制御に一本化され、これまで何かと問題になっていたフレーム定義に用いるタグ(frame・frameset・noframes)が廃止されました。

これらは互換性維持のために恐らく今後長期間にわたってWebブラウザでのサポートが続くものと思われますが、少なくとも、HTML5で書かれたページについては、既存ページへのスタイルシート導入時などに悩みの種になっていたこれらのタグとの干渉の問題は考慮しなくて良い、ということになります。

次にcommandとmenuに関連した各要素が最新版の勧告でばっさり廃止となりました。これらはここまででも「at risk」つまり、使用にはリスクが伴うよ、という注記つきで残されていたものなので、廃止は順当と言えます。ただし、HTML5の次バージョンとなるHTML5.1では再検討と整理再編の上でこれらと同様の機能を実現する新要素の策定が進められており、これはその間の経過措置としての廃止、ということになるようです。

さらに、色々問題のあった略称表示のためのacronymが廃止されて同目的ではabbrの使用が推奨され、applet、isindexそれにdirの3タグについても代替手段がある(※同目的のタグのないisindexはフォームコントロールで代用することが示されています)ことから削除されています。

また、属性では文字修飾にかかわる属性が、CSSでの制御内容とバッティングすることから綺麗さっぱり削除されており、タグの場合と同様、文字修飾に関してはスタイルシートで全部行うことが大前提となっています。

このあたりの整理は基本的に同一の動作を得られるタグや属性、あるいは機能が複数ある場合に、構文や機能分担上の整合性が可能な限りとられるような形で、残すべきものの選択が行われています。

一般的なプログラム言語でもそうですが、全く同じ内容の動作が複数の命令で得られる、というのは処理系をいたずらに複雑化させるだけ(機能のバッティングの危険性が常に存在する、というのはある意味悪夢です)で、トラブルの元にしかなりません。その意味では、HTML 4.0でスタイルシート導入に伴う経過措置として残されていた文字修飾タグや属性(※個人的には、スタイルシートなしでhtmlファイルが手軽に構成できたので、便利だったのですが)が今回のHTML5で削除されたのは、当然といえば当然の話でしょう。

第三講では、HTMLそのものの歴史と、Webアプリとネイティブアプリの間にある相違とそれに伴う諸問題、そして無料で使えるHTML5の統合開発環境などについて扱います。

(以下、第三講に続く)

コメントは受け付けていません。

タグ:
PageTopへ