Oozaru is a browser-based implementation of Sphere, coded in JavaScript and designed to work in modern browsers without plugins.  It is currently in beta, but is planned to implement the entire Sphere v2 API so that it'll be able to run any game the desktop implementation, neoSphere, can.

Like neoSphere, Oozaru's source code is hosted on GitHub and is licensed under the terms of a BSD-style license.

Oozaru 0.7.0 - December 18, 2024 - Release Notes - GitHub Repo
Works with the Oozaru Support plugin included with Sphere Studio.
by Where'd She Go? LLC

• Oozaru 0.7.0 Web-ready distribution (.zip, ~193 kB)

If anyone's curious about the name, it's another Dragon Ball Z reference:
http://dragonball.wikia.com/wiki/Great_Ape

These are basically obligatory for minisphere-related projects now.  If Debian can have Toy Story characters then I can have DBZ ones dammit

Besides a platform-neutral editor, this is one of the things I have been looking forward to most when it comes to Sphere. You're doing awesome work.

Yeah, implementing the Dispatch API was the tipping point.  With that implemented, the goal of Sphere-in-the-browser was suddenly in sight and I jumped on the opportunity.  I know I may have scoffed at the idea of a WebSphere in the past, but mostly that was just me being a grinch and not wanting to learn Web development.  I'm much more comfortable with JavaScript now (and I've been keeping up with the latest features even if Duktape doesn't support them , so... well, why the hell not?

I haven't worked on this in a while; module support complicates things, as browser JS doesn't support them at all.  It's even more of an issue now that ES2015 modules (import/export) are first-class citizens in Sphere v2.  What I'll probably have to do is add a special mode to Cell that combines all the scripts into a single file, like what Browserify does for Node.js modules.  One more reason for Sphere developers to write a Cellscript, I suppose.

I see how that can complicate things! I've recently gotten a little more excited about Sphere again, even though I barely have time to work on anything like a game. Would definitely like to contribute on the simpler elements once you got that figured out though!

Good news: Browsers are finally starting to get support for ES6 modules:
https://jakearchibald.com/2017/es-modules-in-browsers/

That will remove a big barrier for Sphere v2 in the browser, since .mjs is now the preferred way to write v2 code.  Otherwise you end up needing Babel/TypeScript + a require() shim.

So after having left this project to languish for a year and almost giving up on it entirely, I picked it back up about two weeks ago and started hacking away... and now it can run the kh2Bar demo!

It currently requires an up-to-date version of Chrome or Safari but this serves as a very nice proof of concept.  The entire Galileo API is implemented (I think), the Keyboard API somewhat works, and it even reads the data from
game.json.

If anyone wants to test it out you'll need to checkout the Git repo and set up a local web server; I'll see about posting it online eventually.

https://github.com/fatcerberus/oozaru

This makes me wish HTML5/Canvas was a more feasible option back when I was working on JavaSphere. If that had been the case, I wouldn't have even bothered with Java. I'm very happy to see that things are starting to come along well with Oozaru, and that miniSphere will finally be getting a proper platform-independent option. When it's more stable, it would be pretty cool to see it uploaded to the server to directly showcase miniSphere instead of pictures alone.
Now if only they would add (better) support for Android to ChakraCore...

It's funny you say that because a big part of why I shelved Oozaru for a while is that, a year ago, the Web technology wasn't quite there yet.  WebGL was a thing (which I didn't realize at the time--Canvas2D is an awful API to use for game development), but the missing piece, ES module support, wasn't actually a feasible option since browser makers were only just starting to implement it.  I would have had to use a require() shim, which didn't seem ideal since you don't really want to be blocking your code while loading things on the web.  The user will hate you for it, and most likely so will the browser.  And I was just starting to push use of ES modules for Sphere at that point too, so forcing require() for Oozaru felt like a step backwards.

But now that stuff I need is finally widely available, Oozaru will finally see the light of day!  Or, well, the light of a full moon, as the case may be...

I wonder if it would be possible to add Oozaru-only (for now) API functions and objects to make games for mobile browsers.

What kind of functions do you have in mind?

I finally got SoundStream working today!  It took me forever to get it right and in the process I had to learn how to do sample rate conversion, but now Oozaru can run the sphere-mp3 demo (with a couple small code tweaks to accommodate for the lack of synchronous file loading).

Next I'm going to see about getting this thing to work in other browsers besides just Chrome.  This isn't the late 90s/early 2000s after all.

What kind of functions do you have in mind?

One thing I can think of is accelerometer support. You see it in use in stuff like racing games, where your phone becomes a steering wheel, or even just simple stuff like Pokémon GO, where putting the phone upside down will turn the screen black to save performance.

I imagine that Oozaru will be able to do more anyway, if we can have access to the JS DOM API.

What kind of functions do you have in mind?

One thing I can think of is accelerometer support. You see it in use in stuff like racing games, where your phone becomes a steering wheel, or even just simple stuff like Pokémon GO, where putting the phone upside down will turn the screen black to save performance.

Stuff like this, or handling swiping. Though I guess it would technically be possible for a game to do that, but a runtime ES6 helper module would be nice.