One debate that comes up in game development is the use of any language other than C/C++.  The C/C++ languages have been almost the exclusive language for game engines since its beginning.   While developers my also adopt scripting languages (many times to offload work to less technical game designers) the core that makes the engine do its magic is in C/C++.

With the advent of new technologies does this still make sense?

Microsoft has for some time been promoting an hier to the thrown in C# which is built on top of its .Net platform.  Why not C#?  I honestly like C# and believe that it is in many ways a step up that can help with productivity. C# has many of the advantages of Java without being as bloated.  It is more secure by nature and protects programmers from common mistakes.

That said, in some cases C# does not make business sense.  If you invest 10-20 million into a game, you expect the best return on that investment. The ability to release that game on multiple platforms (PS3, Wii as well as XBOX) can double your returns for small additional development time… if you program it in C or C++.

That may change.  One of our favorite small game engines Unity3D is scheduled to be release on other consoles.  When it does it will bring it’s version of the .Net runtime along with it.  Since the main engine is already in C++ it preforms significantly better than C# for most of the heavy lifting, leaving game logic to C# which is significantly faster than most scripting languages.

If your target is XNA or Unity3D then C# is the obvious choice.  To go beyond those use cases Microsoft will have to work to make the CLR a lot more open. Releasing the core of .Net under a BSD or MIT license (rather than the more restrictive GPL/LGPL for Mono) would allow developers to integrate C# on any platform and modify it to perform efficiently for their games.  Till that happens  (or Unity3D becomes a real competitor on all platforms)  console development will belong to C and C++.

http://www.youtube.com/watch?v=YMdKdzqanmw

It was a great panel put together by Rita Turkowski of Intel and featured Remi Arnaud, Johannes Berh, Mimi Harris, Doug Twilleager, Christian Renaud, Vladimir Vukicevic and Mark Young.

I still like X3D for the sheer boldness of trying to define a standard that can completely describe 3D in XML for the web.  It is a bit heavyweight for many applications and the tools are still rudimentary for general consumption, but is still the only standards compliant 3D implementation for the web.

I think we are a bit too early for Web3D standardization.  At this point “competition is good” as evidenced by Unity3D and others coming up under the radar.  It is great to see it mature and evolve.

Kudos for a fun panel to Rita and the gang!

While there are many less restrictive licenses (MIT, BSD, MPL, etc.) the GPL is perhaps the least understood and most feared by business. To an extent this confusion shouldn’t be a surprise. The FOSS ( Free and Open Source Software ) movement is made up of an array of activists that have slightly different ideals. Since to an extent law relies heavily on intent and consistent treatment, the inconsistencies in this approach muddy the waters. When over time the leaders of the movement make contradictory statements regarding the scope and intent to the GPL, this injects Fear Uncertainly and Doubt (FUD).

Making matters even more confusing, copyright law is also in sad shape in relation to basic tenants that the GPL relies. For software, what constitutes Fair Use and Derivative works are at odds within case law. On one extreme, case law infers that a product is derivative even if you have copied no code from the system it interacts with. On the other, conflicting case law infers that it is Fair Use to reverse engineer a system to utilize it without worrying being considered derivative.

Which of these precedents we think will play out is potentially random and depends a lot on the way we use the code. Without explicit exclusions set down from developers we have to go back to the intent of the authors of the license itself. In this case the Free Software Foundation specifically spells out its beliefs. In their interpretation of the GPL your program IS derivative if you include GPL code or link to GPL code in any way (dynamically or statically).

There are several acknowledged exceptions to this rule such that your program may NOT be considered a derivative work.

1. You may dynamically link against a standard interface where other existing libraries may be substituted.
2. You may execute a GPL program via fork() or execute().
3. You may communicate with a program via standard network and IPC mechanisms.*
4. You may distribute your program and a GPL program in aggregate (on the same medium) provided they are still represent separate programs and the terms of the GPL are observed.

These exceptions give us enough rope to use GPL’d programs and libraries in conjunction within a larger closed source systems. On top of these some developers may add additional explicit exceptions like allowing dynamic (LGPL) or static linkage. In some cases it may also be possible to contact the developers and negotiate a closed source license that removes the limitations of the GPL all together.

There is one other notable loophole. The GPL only kicks in when you distribute the derived program. If you do not distribute a derived program to people outside your company you do not have to distribute your closed source. You may even use GPL derived software as a service and charge money for it without releasing any code.

In practice this loophole does have a couple gotchas. The first is that you cannot sell or give the derived program to another company or person. The second that many do not consider is that during some M&A transactions the company is selling the assets rather than merging the companies and selling the assets may also be considered a distribution.

Of course as with any software your license (FOSS or commercial) you should be cognizant of the patent issues, indemnification, additional license restrictions (e.g. GPL3 restricts DRM) and the total cost of ownership related to maintenance and support. As with anything we do as companies there is more to the bottom line than the price tag coming in the door.

The other thing to consider is the perception of the public and the FOSS movement. You are using FOSS software and the implied contract is that you will participate in the community and contribute improvements. It is not enough to use FOSS, you should adopt a policy that states how you use FOSS and how you support it. Working with FOSS developers and being a good citizen goes a long way.

References:

http://www.gnu.org/copyleft/gpl.html
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html
http://www.fsf.org/licensing/licenses/gpl-faq.html
http://www.bu.edu/law/lawreview/v85n5/Stoltz.pdf
http://www.linuxinsider.com/story/38089.html?welcome=1202601329&welcome=1202602307
http://en.wikipedia.org/wiki/Free_software_licenses
http://en.wikibooks.org/wiki/FOSS_Licensing/Scenarios