Gamasutra: The Art & Business of Making Gamesspacer
Moving Hardcore Gaming To The Web: Making History
View All     RSS
October 20, 2014
arrowPress Releases
October 20, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Moving Hardcore Gaming To The Web: Making History

January 5, 2010 Article Start Page 1 of 3 Next
 

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.

Rendering 3D Games in a Browser

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.


Article Start Page 1 of 3 Next

Related Jobs

Monochrome LLC
Monochrome LLC — Aptos, California, United States
[10.19.14]

Senior Programmer
Gearbox Software
Gearbox Software — Plano, Texas, United States
[10.17.14]

Server Programmer
Digital Extremes
Digital Extremes — London, Ontario, Canada
[10.17.14]

Generalist Programmers
Petroglyph Games
Petroglyph Games — Las Vegas, Nevada, United States
[10.17.14]

Network / Web Programmer






Comments


Shakeel Shafiq
profile image
2D games on social networks was great fun but now 3D will take it to highest level. Piracy can be handled easily on PC games using this method.

Megan Fox
profile image
why did you go with a custom Java solution over something more standard, like Unity 3D? Licensing costs?



(that is - as far as I know, Unity meets most of your requirements and is widely used, though maybe in practice it did not?)

Greg Jandl
profile image
@megan - That was covered in the article"



"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."



Also, though I think Unity is interesting, I don't see how you could possibly refer to it as "standard" - most especially not as "more standard" compared to Java! The Java plugin's penetration is (depending upon version and who's numbers you trust) between 85% & 90%. Unity is in the single digits.

Anatoly Ropotov
profile image
Unless you are doing it in Flash, you are doing it wrong.

Java penetration is as sub-par as Silverlight is. Unity and other custom plugins = puke. Do you want your game to be played by 95% of people visiting web page or by 10%?

Kirill Vainer
profile image
You can use hardware accelerated graphics in Java using OpenGL, using LWJGL or JOGL libraries. Have you considered it? There are also game engines built on top of those, like jME: http://www.jmonkeyengine.com/

Matt Hackett
profile image
The development process for this sounds like quite a beast, and from what I could gather, the following technologies are required:



C++, Java, JavaScript, Python, XML



Is it just me, or is that too complex?

Tim Carter
profile image
I always thought Muzzy Lane wanted to specialize in being a history-driven game company. So why is it acting like a technology company?



Aren't people figuring out that if their core speciality is content-oriented, why waste time creating new technology?

Mike Wuetherick
profile image
You can install standard 'mozilla-style' plugins in both IE & Firefox without a refresh of the browser - this works 100% of the time and is what both GameCore (a 'Unity-alternative' that the company I am the CTO for produces) and Unity do. Having the extra runtime requirement of Java (which is a technical nightmare and is hideous from an end-user perspective) just adds yet another layer of complexity to what is already a difficult process. Debugging anything in a browser is extremely painful - and having to jump from C++ to Java and THEN to the browser just sounds like a nightmare waiting to happen. Too many dependencies for my liking. To each their own however...



Game sounds cool though ;}

Dave Mariner
profile image
OK - maybe it's just me being dumb, but I don't see a difference between creating a custom java extension that has to be installed, and using a third-party plugin such as Unity. If anything, the user distrust is going to be far greater for the custom extension. You're asking the user to install specific piece of software to enable them to play a *single* game *in-browser*. You're not starting from a plugin penetration of 85%-90%, you're starting from an effective penetration of 0%. No-one is going to be able to simply land at your site and play the game.

Additionally, you're opening up a potential security hole within someone's java plugin. Execution of native, non-sandboxed code from within a browser where the plugin is a means not an end for the developer. How is this better, or more trustworthy?



I can see that it made sense for you to wrap an existing codebase to enable you to get to market sooner within the "browser-based gaming" sphere, and it doesn't sound the worst way of doing it, but I just don't buy the reasons set out in your article.



But best of luck with the game, and thanks for sharing your experiences :)

Eric Hardman
profile image
I am surprised by the backlash against this idea. Yes, it's complicated, but it's also an area in which Flash has failed repeatedly. There is no question, IMO, that 3D in a browser that hits the hardware is an inevitability. The question is how do we best get there and who will win?



There are terrific plays out there by Unity, and to a much lesser extent, Torque. So far, nothing in Flash compares or even comes close to the immersive experience of a real game engine. Users want 3D, but they also like the ease of Flash, having already installed it. I think we are at a tipping point, a moment of great opportunity. It astounds me that Flash hasn't been able to capitalize on this yet since they are poised for the greatest potential success. But even if they win, how's Flash for debugging? How is it for collaboration and version control? Getting better, yes, but still inferior.



Ever notice how the only way to play Farmville is in low quality mode? If you haven't, you probably haven't tried the kind of hardware most people have access to. If Farmville is pushing the boundries of Flash, well, I just tremble...



Believe it or not, I am not anti-Flash, quite to the contrary. I've done the bulk of my work with the tech since the very first version, completely sold by the fact that it came from the "Dark Castle" guys. But it bothers me to see blind fanboidom applied to it: it's not the best solution to every problem.



As for the argument that "everyone uses Flash, anything else is an instant fail!"... I guess I would reply that it would have been insane for a search engine to compete with Infoseek, Yahoo, and AOL at one time. Good thing the Google guys weren't paying attention. By that standard, Apple should stop making computers today, instantly! Less than 10% of the market? Pshaw.

Peter Dalton
profile image
Thanks for the article, I greatly appreciated it. We are looking at creating web based games in the future and currently we come from a console background, so hearing how you solved the problem was very informative. Thanks for taking the time to share your experience.

Dave Mariner
profile image
@Eric: I don't think anyone is really against 3D games in the browser. Any backlash against the article was down to the method employed and/or the reasoning behind it.

I was arguing that the percieved user acceptance of this method was a fallacy. A solution provided my a middleware company is more trustworthy, basically because their aim is to get maximum plugin penetration, so security is disproportionately high on their agenda. Muzzy Lane's aim is to produce a game that people want to play, so plugin security will be comparatively lower on their agenda.

Mike was saying (excuse me for paraphrasing you here) that even with their goal of simplifying the development / deployment process of a unique browser-based game, the added complexity introduced through the java layer outweighed the benefits of not tweaking the plugin for each browser.

Matt Seegmiller
profile image
@Megan Fox - Unity does the 3D in the browser part, but we had other requirements, mostly involving distribution and communication with web sites that aren't even touched by something like Unity.



@Kirill Vainer - We have looked at the Java based solutions. Primarily, we had a rich C++ codebase to start from, and were not looking to rewrite the world. We instead wanted a thin wrapper on top of our existing C++ code. Honestly, those Java engines were the inspiration for creating a Java plugin.



The other problem with the Java engines is that they are all OpenGL, and we've learned the hard way that OpenGL on Windows, at least, is a nightmare. It's not too much to ask the end user of a commercial PC game to update to the latest graphics drivers, but it's a lot to ask of someone who only plays your game through a website. In our experience, a large percentage of initially released OpenGL drivers do not have much more than OpenGL 1.1 support, even though the cards themselves support all the latest OpenGL features. I've seen way too many debug logs from end users that say "OpenGL 1.4 not supported" despite the presence of a less-than-one-year-old graphics card. This exact issue drove us to switch to a Direct3D renderer.



@Matt Hackett, @Mike Wuetherick - Yes, it's a complex solution, but as Eric Hardman was pointing out, it's a complex problem. There are all the end user headaches of 3D games (hardware incompatibilities, driver issues, graphics bugs) coupled with the end user headaches of browser compatibility coupled with the deployment headaches of a web service stack. We've tried to use the best tool to solve each problem we've faced: C++ for the game engine, Python for back end web services, XML + JavaScript for in game scripting, etc. We've been able to do this through a large amount of modularity. Our game programmers and content people almost never run the game in the browser, because we have a clean interface to launch games. They develop the game then run and test locally. Eventually official builds get put into our web ecosystem. These get tested through the browser and game services. We've rarely had bugs running in the browser that were game bugs or crashes due to game code. More often than not, it's a bug in the interface code, and the number of these has been going down steadily.



As for the choice of Java, it's definitely not the only answer. However, I've been very pleased that I can start up random browsers (Chrome and Opera in particular) and it seriously has just worked. No extra work to try the plugin there. That's definitely worth something.



@Tim Carter - Muzzy Lane is a technology company. It's rare for a technology company in the game industry to succeed without producing real games on its own technology, so here we are building Making History II.



@Dave Mariner - If the Java Extension mechanism worked as well as it claims to in the documentation, it would be a much cleaner system. The end user would get something that basically looks like "Java wants to add a feature, do you want it to?". Obviously, there is an entire side argument here about whether or not that's a security hole in the Java Plugin or not. Anyway, the reality of the Java Extension mechanism is that it is not user friendly at all. It generally just disappears into a black hole, showing a sometimes animating Java logo while your extension is downloaded and/or installed. By the time we figured that out, we decided it was better to stick with the Java shim than to write plugins from scratch. This has worked out pretty well for getting it to "just work" in new browsers.



As for installing a plugin for a *single* game *in-browser*, Sandstone is a technology that enables any number of games to be played. We have our first commercial release upcoming on it, but we've developed several more serious games with partners, and plan future releases using the same technology. And if all works out, others will eventually be using it for their own games as well. As has been pointed out, penetration is always the issue, but we have to start somewhere.

Jerome Russ
profile image
To those who are all about Flash and their installed percentage... I don't think this is intended for the casual crowd who doesn't understand how to install some plugins.

Tom Higgins
profile image
@Matt Seegmiller: can you elaborate a bit more on this statement:



"Unity does the 3D in the browser part, but we had other requirements, mostly involving distribution and communication with web sites that aren't even touched by something like Unity."



What distribution/communication issues did you find that pushed you away (in full or in part) from Unity? And for reference I'm the Product Evangelist for Unity, I just want my "angle" to be clear and transparent and I'd like to better understand what kept you away from our tool and player.



FWIW, I applaud the effort, we're all in the games industry trying to find ways to bring better, more engaging 3D experiences to end users so kudos for that, despite not using our tool in particular! :)

Anatoly Ropotov
profile image
Some facts from MMO publisher side:



- Enormous marketing efforts. If I'd be your publisher, I'd say "make it downloadable, it doesn't make sense to be inside the browser with a custom plugin or Java".

- A web-based version with a custom plugin has less chances to be played than a downloadable game, unless it has existing prominent branding or free (or careless) marketing or unless you are in Korea (where IE ActiveX plugins are a de-facto launch kick-start standard for casual MMO games).

- In reality, those plugins are a huge disaster to support. New browser versions, compatibility hassle, weeks of debugging for developers instead of focusing on the game, endless complaints from players who've updated their computer or try to migrate.



There are very very few cases besides Quake Live and FreeRealms where plugin-based product have reached great heights. Name another Unity or other custom-based plugin product please that have achieved some success.

Anatoly Ropotov
profile image
2Tom: We have an alpha version of Unity mmo game (www.jagger.ru), yet we have a backup 3d flash rendering technology just in case Unity will have too many problems in our region. Please ping me at anatoly d0t ropotov d0t com.

Todd Berkebile
profile image
I would be incredibly concerned about the security of a Java extension designed to allow the download and execution of arbitrary code. I certainly would never be willing to install such a thing myself, and I wouldn't be surprised if such a thing found itself in the virus definition files for major anti-virus products.

Anatoly Ropotov
profile image
2Todd: A funny fun fact. In the last 6 years, the only virus that got me was... through Java.

Anatoly Ropotov
profile image
Oh, btw, there's a live JNI/D3D product out there from http://www.splitscreenstudios.com/

And I'm still waiting (as a strategy/civ genre fan) for Call of The Kings: http://www.callofthekings.com/screenshots.php which is Java as well!

John Ingrams
profile image
Isn't this technology for technologies sake?! I mean, if a game's hardcore it needs a decent manual. On-line help just won't be enough, so why not just be able to download it with a pdf manual and play it on your PC? I don't see what benefits playing in a browser brings when it's a hardcore game.



Certainly indie developers producing hardcore sim or strategy titles have one major problem, gamers don't like 200 page pdf manuals. They wanted printed manuals that they can have open while their learning the game.



Digital Distribution is generally going to dumb down gaming unless indie publishers have a system where they can send a printed manual to their customers.

Douglas Rae
profile image
John:



I personally do not want to be able to play a game within minutes and have to wait for snail mail to arrive with my manual, if at all. I think most "hardcore" games have solved this issue by providing online help; in game tutorials / encyclopedias / very good in game help / built in play and learn content.



The whole point of having browser-based games moving to the next level is the problem of distribution / community. Get more copies out there, get their friends playing = $$$. It makes it easier for the consumer to lift their card out of their wallet.



One could put it into this rough timeline



1. Going to your local game shop (hours / other factors, lose the cd/dvd/media and your up the creek, install and hope it works and you can get access to online features)



2.Steam / Direct2Drive (Still time dependant downloads are big! always available incase you lose it, multi computer, semi-cloud settings, good but limited community / web integration)



3.Browser (Time varies, but it will always be available and compatible with a lot of PCs, a lot more stuff stored in the cloud, native integration with communities / web services).



Hell i played QuakeLive for 5 minutes, within 20 minutes i had about 10 friends playing with me! If they charged $5 per user or per month they would be raking it in!



Or we could live in your world... and go have a long bath until the manual arrives.. maybe write a scroll to our friends to play as well and have penpals to share our experiences.

James Hofmann
profile image
This is interesting technology, but as others point out, getting market acceptance is the main problem with any novel browser technology. Everyone's hamstrung by that requirement - not just with games but any app. Everyone would like to make apps that you can just browse over to start using, but can make good use of the hardware and integrate well with the desktop all at the same time.



My own strategy, as a solo developer, is a defensive "follow-the-market" one:



1. Flash is what's there right now, and I don't have the resources to push anything else to users; I want the assistance of the portals to promote my game! Therefore I use Flash.

2. Develop Flash games in haXe. haXe is a VM-portable compiler, and has a strong likelihood of compiling to whatever becomes the standard after Flash. (My money is on JS/WebGL/media extensions.)

3. When the time comes, port to the new standard and be automatically ahead of the game because, presumably, less code will have to be rewritten.



Despite "only" doing a 2D game, I've still found a lot of areas that can use better tech, mostly in tools and gameplay logic. My goal is to make Flash as convenient for 2D prototypes as a tool like Game Maker. I still have a ways to go, but give me another year... :)



edit: webGL, not Canvas3D(canvas3D was a prototype)

Anatoly Ropotov
profile image
Summarizing:



Basic HTML/AJAX. 100% penetration, basic visualization. Harder to bring casual players in. Think Mafias, MUD.

Flash. 95% penetration, awesome 2D visuals, basic 3D.

Java, Silverlight, Unity3D, Shockwave, better custom plugins, various endless "web players". 1%-50% penetration. Endless compatibility problems.

Everything else. javascript canvas webgl svg and other stuff that will never catch up. Non-existent.



Game genres:

Casual games = Flash only.

Social = Flash, AJAX.

Core = It's easier to get stable game when it's downloadable, than inside the browser.

Hardcore = custom plugins (InstantAction, Quake Live, FreeRealms launcher).



Note: you could make any tech or plugin acceptable by putting a lot of expensive marketing into it.

Matt Seegmiller
profile image
Wow... thanks for all the response. It's great to hear so much feedback.



Something that probably didn't come across in the article is that this technology was not developed specifically for Making History II. We additionally have about a half dozen serious games currently in production using this same technology, including a DARPA funded project to create games for middle school science. We were originally founded on the idea that 3D multiplayer games could teach people something. To that end, we found integrating our games with the web almost a necessity, allowing for much more intuitive multiplayer lobbies and much easier install paths. Plus you end up with integration into existing web infrastructures, like social networks and learning management systems.



Also, it's important to note that rendering 3D in the browser is only a small part of creating a game that integrates with the web. Additionally, a user-friendly way of distributing the content is necessary, since 3D game content is HUGE compared to anything else, and is very difficult to stream. Plus, there needs to be some way for the game to report information about the game play experience back into the website. Finally, for a multiplayer game, having a way to manage game server instances from the web makes things like multiplayer lobbies much easier to deal with, and much more cleanly integrated into the website.



That all being said, MHII is not a browser-only game. It will be sold on CD, downloadable as a separate installer, available through other game download services, etc. etc. The Java plugin will not be required to play, only to take advantage of the integration of the game with the social website surrounding MHII.

Tom Higgins
profile image
@Anatoly Ropotov: Email sent



@Matt Seegmiller: Any chance of hearing how Unity didn't measure up as per my Qs above? Either here or via email would be great if you have time, thanks! (tom -at- unity3d.com) Otherwise rock on good man.

Matt Seegmiller
profile image
@Tom Higgins - From what I've seen of Unity, there are two main things it lacks that we've placed a lot of importance on. The first is some ability to manage the download process. The Unity games I've played all seemed to download only on the page that you played the game on. There wasn't any ability to manage that process across multiple pages from HTML and JavaScript. The other is some ability to communicate from the game into the backend web infrastructure, sending out messages from the game that can be interpreted by the web server or vice versa. I'm sure this could be done with custom code in a Unity game, but we've felt it's important enough to warrant a builtin solution.

Tom Higgins
profile image
@Matt Seegmiller: you can manage incremental downloads via our Asset Bundle feature and that will work across multiple pages as they're stored in the browser's cache just fine. Optionally we do have a feature (licensed separately) that allows for storage of large collection of files outside the browser's cache but that's a pay-to-play feature only needed in extreme cases. On the communication with back-ends, that's actually dead simple in Unity either via our built-in WWW class (allows HTTP get and post calls) or by using .NET sockets, it's really a trivial thing to do.



Thanks for taking the time to explain and as noted above, kudos on the effort regardless. I'm always pleased to see others pushing for better web delivery of 3D experiences so keep at it and I wish you all the best! Rock on brother.

Vikas Maini
profile image
this technology is going to be great in coming future.



with C++ can do anything.

KOJEN KU
profile image
Does the game require constant internet connection in order to play, like some hot titles? I don't like social features so I can live without it. To me, social means going to a club or friend's home and have fun. BBQ, ball game, fishing, ....



The hurdle of 3D web gaming with hardware acceleration is the security issues of browsers and applications. This is more of the social psychology then gaming technology. After all if the players don't trust the stuff they are running they will not buy and play the games and all these wonderful technologies will sit and waste over time. Win the trust and games will be sold fast. Call me a socialist or of a worse kind, I do think that the internet should be deeply regulated like real world in order for online businesses to win consumers' trust. At its current state, the internet is far from it.



From javascript to Java to C++ DLL to gameplay and AI, no wonder the development cost is so high. Gaming in web browsers are certainly good. I do like, however, a off-line browser gaming option when the player wants to play alone.


none
 
Comment: