The Khronos Group - a non-profit industry consortium to develop, publish and promote open standard, royalty-free media authoring and acceleration standards for desktop and handheld devices, combined with conformance qualification programs for platform and device interoperability.

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Re: Content protection.

Actually, no. By content, I am referring to all content, including artwork, and it's certainly not a non-issue. There are many uses for WebGL besides games. Imagine a small company that wants to put together a snazzy 3d website and use clip art (3d models) that they purchase online. As I implied in one of my posts, a lot of the companies that supply 3d clip art stipulate that you have to take steps to prevent it from getting stolen and used elsewhere. I wasn't sure that obfuscation is enough, but after a bit of research I do believe it will be enough to discourage all but the most determined of hackers.

Re: Content protection.

The point of obfuscation is to make it more difficult to read the code than it is to write something new from scratch. Something like Google's Closure tool turns readable code into mush. Sure - the bad guy can take the mush and run it in unmodified in their own application - but unless they are flat out stealing the entire application, it'll be an absolute bitch to figure out what they have to do to use it. IMHO, any programmer with enough ability to understand this mess would be perfectly capable of writing whatever he needs himself - and probably in less time.

When you compile C++ code for a 'conventional' game into machine-code binaries and package it on a DVD, you're really just obfuscating the C++ and delivering it in a way that lets the bad guy un-obfuscate it.

There are other strategies:

* Put most of the critical code on the server...this is the ultimate defense. The majority of the code never leaves your control.

* At the outset, offer to release the source code in (let's say) a year from now. It would take a real fanatic to spend all that effort to understand all of this obfuscated code - in the sure and certain knowledge that it's a total waste of time because you're going to give it away anyway. This kind of thing buys you more time to make money.

* Maybe offer a competition to make modded versions - for some small prize money, you get to find out all of the people who want to mess with it. "Know your enemy"...and "Keep your friends close and your enemies closer still".

* Follow a path of continuous improvement. If you have multiple programmers working on the product - they can outperform the (typically) lone bad guy who is de-obfuscating your code for whatever purpose. By the time he's gotten something moderately useful out of it - you are already lightyears ahead.

* Get lawyers. Just as you can't truly hide your code - the bad guy can't truly hide what he does with it. If he's going to make any inroads into your business, you'll surely know who he is - and be able to compare his code to yours and sue the pants off him if it's a ripoff.

There are some exceptions to that which are hard to defend against. Notably, shaders. These are short chunks of code - and they are generally packed with clever tricks that might well be worth un-obfuscating - or even using in their obfuscated form. You don't need to literally steal the code - the ideas themselves are generally the payback. I can't imagine a defense against this because even shipping machine-code binary shaders is giving away the farm.

Art (both 3D and 2D), music, sound effects - these are easy to steal - but this is really no different than being able to steal it from a conventionally delivered DVD-based game.

My plan is to put very little of the game code into the client-side software - push as much as possible back into the server. The client will be little more than a dumb renderer...following instructions about what meshes to draw where and with what animations.

Right now, something like 70% of my source code is server-side...but that percentage will increase dramatically as the project moves to completion.

This makes sense from an architectural perspective too. Writing hundreds of thousands of lines of industrial-strength game code in JavaScript is just too painful to contemplate...especially without access to middleware like Morpheme and PhysX.

I regard WebGL as a happy medium between a conventional client-side game and the radical idea of cloud-rendered games such as On-Live are promoting where all of the game AND the renderer live on the server and the player is essentially watching a streaming video of the action. Here we are avoiding the high bandwidth and insane computational/latency requirements of rendering on the server - but maintaining all the benefits of having a pirate-proof game where almost all of the code lives on the server.

Looked at like that, you have very little to lose by letting people see the code for the client-side renderer.