Game Development Reference
In-Depth Information
Future Work
There are many avenues for future work in browser-based tools. One possibility is a video streaming solution that
makes more efficient use of bandwidth while minimizing the CPU load during encoding. It would be interesting to
see the game engine and the game play completely isolated from each other. The game play code would use ET-API to
remotely script the engine, although latency could make this difficult. Finally, I'd like to extend this approach to offline
asset baking. The engine could be notified over ET-API when an asset is baked and could be reloaded.
Conclusion
I am proposing that your engine define an API for engine tools (ET-API). ET-API is exposed as a JSON-based remote
procedure call sitting on top of the WebSocket protocol. With ET-API in place, all engine tools are built as browser
applications. The engine should support multiple simultaneously connected tools. I have offered examples of a
remote viewer, live editing, live performance monitoring, asset preview, and testing. Each of these applications can be
cloud hosted, providing a central location for all tools used in a game studio. If these tools allow content to be created,
players could be allowed access to them to create add-ons for the game. These examples are just the tip of the iceberg.
Although much of this chapter has been devoted to exposing a game written in C/C++ to browser tools, this approach
is applicable to game engines written in any language—even a game written for a web browser.
