バージョン 1.9
現在の開発中の Ebiten のバージョンは 1.9.0-alpha です。 1.9.0-alpha では以下の変更を予定しています。予定はあくまで予定なので変わるかもしれません :-)
Metal (Issue #621)
macOS および iOS では OpenGL (ES) が非推奨になり、 Metal に置き換える必要がでました。 macOS 10.14 Mojave から OpenGL を使うと警告が出る有様です。
というわけで Ebiten は macOS では Metal を使用することにし、実際に実装しました。 2018-12-20 の時点で master ブランチにコミットされています。
Ebiten は OpenGL に依存した API を幸いにも露出してなかったため、ユーザーには影響がまったくないはずです。むしろ、 OpenGL に由来していたバグが自然と治りました (例: Issue #692)。パフォーマンスも良くなっていると良いですね。
iOS についても 1.9 の段階で実装することを計画中ですが、まだわかりません。 Metal でコンテキストロストってどう扱えばいいんだっけ?
Windows で Cgo を不要にする (Issue #171)
別の記事でも説明しましたが、 Cgo は以下のような問題を抱えていて、特に Windows ユーザーにとって Ebiten 導入の妨げになっています。
- Cgo は C コンパイラを必要とする。
- Cgo はコンパイルを遅くする。
- Cgo はクロスコンパイルを困難にする。
go-gl はなんとか Cgo 依存から脱却しました。あとは GLFW です。これが最大の難関なのですが、 C を Wasm で書いて life みたいな Wasm interpreter を実行してなんとかやれないかなと画策しています。 Universal Binary としての WebAssembly ですね。それがうまく行かなかったらあとは手で移していくしか無いかなあ。つらい。
バージョン 2.0
Ebiten はご多分に漏れず Semantic Versioning を採用しています。ちなみにこれは Go modules の要請でもあります。メジャー番号が同じならば互換性は維持されますが、メジャー番号が異なるならば互換性の保証はありません。 Ebiten が 1.x から 2.0 になる際には互換性のない破壊的な変更が行われる予定です。
1.x から 2.0 になる際には、最低限の API 変更に留める予定です。
- import path が
github.com/hajimehoshi/ebiten/v2になる- これは Go modules の機能です。
- Deprecated となっている API を削除する (例:
IsRunningSlowly,ImageParts)- これについては 1.x の段階で極力代替手段を用意します。つまり 1.x でも 2.x でも通るようなコードが可能です。たとえば
IsRunningSlowlyはIsDrawingSkippedに置き換わります。
- これについては 1.x の段階で極力代替手段を用意します。つまり 1.x でも 2.x でも通るようなコードが可能です。たとえば
- API の非互換な変更を行う (例:
NewImageの第二引数の削除)- API の整理です。
というわけでメジャー番号が上がってもそこまで急激な API 再設計はしません。なるべく緩やかに Ebiten を進化させていきたいと考えています。
ブロッカー
Ebiten を 2.0 にアップデートするということは、 Go modules に完全移行することを意味します。現在の Ebiten は Go modules を使うのも使わないのも両方可能ですが、 2.0 になると使う以外の選択肢はなくなります。 Go modules に完全移行するには、概ね 3 つのブロッカーがあります:
- GopherJS (Issue)
- GopherJS を Go modules 対応するかはずっと議論中。 GopherJS は Wasm の出現以降は「保守モード」にしていこうという雰囲気があり、最近は修正がほぼ行われていません。ただ自分を含めてメンテナの一部は Go modules 対応を行いたいと考えており、未だ結論が出ていません。もし GopherJS が Go modules に対応しないのであれば、 Ebiten 2.0 は GopherJS を諦めることになるでしょう。
- godoc (Issue)
- godoc.org は Go modules に対応していないので、バージョン 2.0 の API ドキュメントが見れません。
- gomobile (Issue)
- 対応検討中の模様。
すべての問題が解消するのは、 Go 1.13 が出る 2019 年 8 月くらいになるのではないかと思われます。
その他検討中の機能
ベクターグラフィックス (Issue #137)
大抵のゲームライブラリには矩形や楕円を描画する機能がついているものですが、 Ebiten にはありません。これはいくつか理由があって、「我々が作るゲームには必要なかったから」というも一つとしてあるのですが、「納得する API セットを定義するのが難しい」というのもあります。まず API セットを決めるためにはどんな問題を解決したいかを考える必要があり、それについてずっと議論が続いていたという状態です。
一応 Ebiten には DrawTriangles という機能があり、これがあれば (テッセレーションさえすれば) どんな図形も描画可能にはなっています。もし Ebiten にベクターグラフィックスを描画する機能が追加されるとするならば、 DrawTriangles を利用したユーティリティ関数集になるでしょう。つまり Ebiten のコアは最小限に保ったまま、別レイヤーで問題を解決するわけです。
シェーダ (Issue #482)
シェーダ機能も非常に求められる機能の一つですが、「シェーダ言語が環境によって異なる」という問題があります。 Ebiten は「一度書いたらどこでも同じように動く」ということを標榜しているので、環境によってシェーダを書き直す、ということは避けたいわけです。
もともと GLSL シェーダ API を作る寸前まで行ったのですが、 Apple の OpenGL 廃止告知直後に取りやめました。 Web も WebGL ではなく WebGPU というのが出てきそうで、統一されたシェーダ言語というのは当分の間は期待できそうにありません。
ちょっとだけ検討していたのは、 Go の構文解析ライブラリ go/ast を使って Go 互換なシェーダ言語を作るというアイデアです。似たようなことを考えていた方は他にもいらっしゃったのですが、その人曰く「関数や演算子のオーバーロードがないと結構つらい」とのことでした。確かにそうかもしれないですね。時間があれば自分もやってみようかと思います。
パーティクル (Issue #607)
Pixi.js のパーティクルみたいなやつです。
パーティクル機能も欲しい機能の一つですが、これもベクターグラフィックスと同じで、「納得する API セットを決めにくい」というものです。 API セットを決めるならまず解決したい問題をはっきりさせないといけませんね。
3D
やらないよ!
おわりに
というわけで 2019 年以降の Ebiten の予定をざっくりと振り返ってみました。アドベントカレンダーは最初一人でやろうかと思っていたのですが、幸いにも有志が記事を書いてくださって、本当にありがたいです。皆様の Ebiten を使ったゲームを非常に楽しみにしております。
来年も引き続き Ebiten の開発、およびそれを使ったゲームの開発を続けて参ります。どうぞよろしくお願いいたします。良いお年を。