Web Plugin

Michalis Kamburelis edited this page Jan 24, 2017 · 3 revisions

You can create web browser plugin (NPAPI) to run your game inside a web browser. Besides making your game visually a part of the web page, it also allows to integrate with the webpage environment --- for example, your game can communicate with Facebook, when being run inside a Facebook game canvas.

Note that the NPAPI support is removed, or planned to be removed soon, from all the major browsers: Google Chrome, Firefox, even Internet Explorer. So, unfortunately, you should not depend on this technology for new projects. We're all waiting impatiently for JS or WebAssembly compilation from FPC (maybe through LLVM) to port our engine to HTML5 and WebGL:)

If you'd like to try the web plugin (NPAPI) support in our engine anyway, go ahead:

Test it NOW

  1. Get the latest engine sources from SVN or GitHub (links on http://castle-engine.sourceforge.net/engine.php).
  2. Compile the latest castle-engine "build tool" https://sourceforge.net/p/castle-engine/wiki/Build%20tool/ . This adds a --plugin command-line option, and support for plugin_source in CastleEngineManifest.xml, in the build tool.
  3. Enter the castle_game_engine/examples/plugin/cge_3d_viewer/ directory.
  4. Compile the plugin with "castle-engine compile --plugin" command. Add "--mode=debug" if you want:) This creates a DLL (Windows) or SO (Linux) file with plugin code. You don't need to install any special tools to build a plugin, a standard FPC installation is cool! (In case of compilation problems in CastleWindow, just "make clean" inside castle_game_engine/ directory to force recomplation of CastleWindow for the plugin. The need for this will disappear soon.)
  5. Install the plugin (useful command to continously compile + test) by "castle-engine install --plugin". On Windows, this installs by adding appropriate registry keys. On Linux, the plugin is installed by simply copying it to $HOME/.mozilla/plugins/ . You can now confirm that it's installed OK by looking at "about:config" (Firefox) or chrome://plugnis (Google Chrome). On Google Chrome, remember to turn on NPAPI flag (see the instructions at the bottom of https://support.google.com/chrome/answer/6213033?hl=en ).
  6. Finally, see the plugin in action! Simply open the file ...examples/plugin/cge_3d_viewer/index.html in your browser.

Supported browsers

The plugin works on Windows and Linux (and other Unix systems using X11). Supported browsers are Firefox and Google Chrome. For Google Chrome, you now need to enable the NPAPI flag (see the bottom of see the instructions at the bottom of https://support.google.com/chrome/answer/6213033?hl=en).

The plugin should work in any browser supporting NPAPI plugins. As for the operating systems, it can be made to work on any system supported by our engine --- in particular it can be adjusted to Mac OS X with relative ease (you just need to implement CastleWindow backend for Cocoa, see http://castle-engine.sourceforge.net/macosx_requirements.php).


What about WebGL?

"WebGL" means compiling code to JavaScript (asm.js) and then using WebGL (OpenGL-like API for JavaScript) for rendering.

Yes, we plan to have WebGL support in the engine. But it depends on support from the compiler (FPC) to compile to LLVM. Once it's ready, we could use Emscripten to compile our code to asm.js (with LLVM in the middle). Good news is, LLVM generator in FPC is in progress (search fpc-pascal and fpc-devel mailing lists for details)!

Alternatively, a direct translation of Pascal to JavaScript would also do the trick. This project is also in progress, as part of FPC project, using fcl-passrc as far as I know. Although it's unsure whether it will be suitable for converting a large project like CGE --- but we'll watch it closely of course!

Once we have that (Pascal -> LLVM or Pascal -> direct JS) compilation, finishing the job on our (engine) side should be easy. WebGL API is like OpenGL ES, and we already have it implemented perfectly:)

Why choosing NPAPI technology?

In short: For web browser integration, it's the only technology available for us, right now. This will dramatically change when LLVM or some other way to compile to JavaScript will be possible. Also, it seems that NPAPI is quite alive, used by a lot of applications (see various technologies used for games on Facebook Canvas, see FireBreath, see Unity WebPlayer...).

More in-depth analysis:

  1. One alternative is PPAPI. But it's not supported by anything except Google Chrome (well, and other browsers based on WebKit, like latest Opera it seems), so it's not a cross-browser solution anyway.

    Also, it's not possible for us without FPC compilation to LLVM (to work with NaCL, as far as I understand).

    So, PPAPI is not possible for now, and it's doubful whether it would be a sensible choice anyway.

    • Maybe it would be fast (NaCL promises quite good speed, rumouredly almost native),
    • for sure it would be secure,
    • but when only one browser (Chrome) is devoted to it, it's not really a long-term solution.
  2. Another alternative is to compile to JS (like asm.js), and use WebGL for rendering. See the above question "What about WebGL" --- it short, we want it, but it waits for FPC LLVM generator. It's clearly the way of the future. Even if there's still some work to be done on the browser side to make asm.js really performing nicely (and reliably) for large codebases. I dream that JavaScript gets replaced with some sensible "browser assembler" language at some point, and it seems that WebAssembly may achieve exactly this.

    So, WebGL is not possible for now, it would loose some performance, but it is a way of the future --- something I will keep my eye on.

Do we install a single plugin, handling all games developed using CGE, or is every game a separate plugin?

Depends on the game.

  1. If your game is a VRML/X3D world (with possible scripting), then users need only to install a "view3dscene plugin" to run it on a web. view3dscene is our VRML/X3D browser (and a viewer for many other 3D and 2D formats). See http://castle-engine.sourceforge.net/view3dscene.php . This plugin will be able to run any VRML/X3D world.

  2. But if your game has logic implemented in Object Pascal, then your game is a new plugin that must be installed by the user.

Unlike Flash (or Unity WebPlayer or Java Applets), we don't have a sandbox to run Object Pascal. So if you write Object Pascal code, it's compiled to a new plugin, and users need to install it. In theory, we could create a "Castle Game Engne plugin" that can dynamically link with your game code (thus creating a CGE plugin architecture within an NPAPI plugin:), but that would be very bad from a security point of view.

I hope that it will not be a huge problem. I'm looking at Unity here, where "Unity WebPlayer" is not something universal, and yet people install it to play games. So hopefully plugins using CGE will be able to live too:)