In the upcoming release of Making History II: The War of the World, Muzzy Lane Software is charting a new course for the company by bringing its 3D strategy games into the web browser, and surrounding them with features that make for a more engaging multiplayer experience.
MHII is being built on Sandstone, Muzzy Lane's new platform for the creation of fully web-integrated, 3D browser-based games with social networking features.
The same tech will also power Muzzy Lane's serious games projects, including the Clearlab Project, an initiative to develop games for middle-school science learning.
In building MHII, Muzzy Lane encountered a variety of engineering challenges. How best to render true 3D games in a web browser? How to approach backend services? How to handle content distribution?
This article will explore and discuss the challenges Muzzy Lane faced in implementing them. It will illuminate several of the key design decisions that constitute the Sandstone backbone, and which enable Making History and other Muzzy Lane games to provide dynamic player experiences.
One of the first engineering challenges was determining the best way to run our 3D games in the browser. Truthfully, even though we were firmly committed to building web-based games, it did take some time to fully commit to the idea of games in the browser.
Originally, we had planned to build games that would just launch from a browser, and then run separately. In part, this was because it was easier to implement, and in part because that's just how 3D games have always been done -- full screen, as a separate application. Flash games are played in the browser, sure, but true hardcore 3D games?
However, the more we looked at web content like YouTube videos, podcasts, and e-book readers, the less sense that approach made. 3D games playable in the browser, with an option to go full-screen, just made sense.
Making History II: The War of the World, a browser-based, fully web-integrated WWII Strategy Game, built on Muzzy Lane Software's Sandstone platform.
As it turned out, it was not all that difficult to render hardware accelerated 3D graphics in a browser window. To do so, the basic challenge (in Windows) that needs to be overcome is getting a handle to a window. (This is similar in Mac OS X or in Linux.)
Most 3D-in-the-browser solutions currently solve this issue by writing a browser plug-in. However, there are two drawbacks to this. First, many people distrust custom browser plug-ins (Flash and Java plug-ins being the exception.) Second, each browser plug-in is very browser specific. Even the Mozilla plug-in architecture, that many browsers support, still often needs to be slightly tweaked for each individual browser. This eventually becomes a maintenance nightmare.
Our solution has been to instead create a Java extension. In general, Java applets are run in a very secure sandbox that allows little access to the client machine. This often does not allow running native code, which is necessary for hardware acceleration.
The way around this is to create a Java extension which is installed on the client machine. The classes in the Java extension are assumed to be trusted because the end user installed them. These classes can then load and run native code without issue.
Once the Sandstone Player is installed, including the Java extension, an applet class from this extension is placed on a page. This applet can download whatever content it needs and save it to disk.
Once this content is downloaded, a call is made to C++ from Java which loads C++ code that was just downloaded, essentially loading the game engine. The engine is told which downloaded package to run, whether to connect to a server, etc. Most importantly, it is given a handle to the parent window which was created by the applet in Java and accessed from C++. This gives the engine a place to render, which is actually on the web page in the browser.
This solution, using Java as a shim between the browser and C++, has its own drawbacks. It is dependent on Java being installed on the client machine. While this is usually the case, when it is not, the end user has to install not just the Sandstone Player, but also the Java plug-in.
The Java extension mechanism ostensibly supports installing the extension on the fly if it does not exist, allowing it to be installed without restarting the browser. This always seemed like a great feature, allowing someone to go to a web page, and assuming they already have Java installed, be able to install the Sandstone Player, download the game, and play the game, all without having to restart the browser. This was one of the main reasons we chose this path in the first place.
In practice, it doesn't always work that way. The extension mechanism gives little or no feedback to the user about what it is doing when downloading an extension. To just get a progress bar on the screen quickly, you have to use a very small installer that then downloads the rest of what is being installed.
In addition, the Java plug-in has trouble in some environments running extension installers as administrator, even when all the hoops of UAC are jumped through properly. The result is that for the time being, the Sandstone Player is a manual installer that requires the browser to be restarted as part of installation.
On the plus side, though, the Java plug-in is dealing with all of the browser specific issues for us, so we end up only having to build and maintain something on a per-platform basis rather than on a per-browser basis. As a result, we've had the player running in many different browsers on Windows. IE and Firefox, even Chrome and Opera, have all worked without any special code or extra support.
The Sandstone platform supports true hardcore 3D games, like Making History II in the browser.