You Don't Need to Hide Your Source Code

Published December 20, 2013 by Julian Marchant, posted by diligentcircle
Do you see issues with this article? Let us know.
Advertisement

The Case Against Proprietary Software Games

For decades now, it's been fashionable for game developers, along with other software developers, to withhold their games' source code, keep it secret. But why? As far as I can tell, people do this not because of any inherent benefits they see to withholding the source code, but because everyone else (well, almost everyone else) does it. In truth, there is no reason for people to be doing this. Don't misunderstand me: I don't just mean to say that there's no reason for people to be doing this with non-commercial games. Keeping source code a secret is unnecessary for commercial games, too. Commercial games are perfectly viable without keeping their source code secret. In fact, I am going to argue that not only is there no harm in the public having access to the source code; there is not even any harm in putting the source code under a Free/Libre and Open Source Software (FLOSS) license.

The Point of Source Code Secrecy in the First Place

"What?!" I hear you say. "How can there be no harm to my business in making my game FLOSS?" To understand the answer to this question, you must first understand what the point was in keeping source code secret in the first place. Understand: keeping source code secret does not by itself do anything to stop unauthorized copying. A binary distribution of a game can be distributed just as easily as source code. Therefore, there must be some other reason this trend of keeping source code secret started. The practice of withholding source code came about in 1969. IBM was the first party to charge for its software and withhold the source code to it. One has to wonder why IBM refused to provide source code, though; after all, copyright law already gave IBM a legal monopoly over the distribution of that program. So what was the purpose of keeping the source code secret? The answer is simple: the point of withholding the source code was not to make money from distributing copies of the program, but to have an additional monopoly on support services. Because only IBM had access to the source code to its software, any time users of the software needed a new feature added or a bug fixed, they had to go to IBM, and IBM could charge more for the services because of this. So in fact, the original reason for keeping source code secret, gaining a monopoly on support services, is not even applicable to video games. Video games aren't even tools, and video game developers don't sell support services. People who play the games just buy them once and play them, or pay a regular fee for continued access to a server.

The New Point of Source Code Secrecy: DRM

More recently, a new reason to keep source code secret has arisen: DRM, which proponents say stands for "Digital Rights Management", though I prefer the more clear and accurate term, "digital restriction mechanisms". Basically, a digital restriction mechanism is a mechanism which intentionally restricts what a user can do. Put another way, it's the function of refusing to function. Keeping source code secret is essential to making digital restriction mechanisms work. If the user has the means to remove the feature that restricts them (the source code), the restriction can't work reliably. But even if small video game developers were able to put effective digital restriction mechanisms into their games, and even if the public was not strongly against restriction mechanisms, it has been shown time and time again that digital restriction mechanisms just doesn't work. There is a reason DRM use has died in music: it has been clearly demonstrated that it doesn't stop unauthorized copying. All it does is inconvenience legitimate customers and encourage them to obtain unauthorized copies that will actually work instead of buying authorized copies that won't work. In short, source code secrecy is needed for digital restriction mechanisms to work, but such mechanisms are not any good in the first place.

Game vs. Game Engine

So it's clear that keeping the source code to a commercial game is completely unnecessary, but perhaps you think that, while it would be fine to distribute the source code to your games, it would be suicide to release that source code under a FLOSS license such as the GNU General Public License. After all, if you did that people would be able to just share copies of the game freely; how would you make money in that situation? In fact, it might still be possible to make money in that situation. Crowdfunding can theoretically earn you money upfront to pay for the full cost of developing the game plus a good paycheck for the developer(s). It's also been shown that people will pay for quality entertainment such as games voluntarily; the Humble Bundle is a good example of this in action, and there are even some FLOSS games such as Sleep Is Death which use this model. But these ideas have not had thorough testing, so let's assume that while these methods may work for some developers, they won't work for every developer. To understand why the most widely-used method of making money from game development, selling copies, would be unaffected by releasing the source code under a FLOSS license, you must understand and be fully aware of the distinction between the game and the game engine. You may tend to think of the game as being one piece, but in fact it's made of two parts: the game engine, and the game data. The game data further consists of two major parts: the art assets, and the scenario. The art assets are, obviously, things like sprites, 3-D models, sounds, and music. What exactly the scenario is depends on the game. In many simple games, the scenario will be a collection of levels. In some scrolling shooters, the scenario might be a list of what attack patterns to use at what times. In RPGs, the scenario will be a combination of the world, the quests, and the story. The other half, the game engine, is the source code: the software that allows users to play the game. With this distinction kept in mind, it is fairly obvious how one might make money from a game that uses a FLOSS game engine: simply leave the game data or even just the scenario proprietary.

Benefits of FLOSS Game Engines

You might be asking now, "OK, but what's the point in releasing my game engine as FLOSS, anyway?" There are currently four main benefits: Additional Exposure Hopefully this is temporary, but currently, there are thousands and thousands of proprietary software games out there. There are far fewer FLOSS games. Being a part of this smaller pot as well as the larger pot of all games gives your game more exposure. Benefiting from Other Developers When several game developers release their engines under FLOSS licenses, this means that code reuse is possible on a much larger scale than when everyone keeps their own game engines to themselves. This makes it possible for faster and easier game development by all FLOSS game developers. Easy Cross-Platform Compatibility (if you use the right libraries) One major weakness of proprietary software games is they will only run on platforms you specifically support. With FLOSS games, you don't need to worry about it; just provide binaries for some popular platforms and users of all the other platforms will do just fine compiling the source code themselves. Volunteers May Help (though they probably won't) It is popularly claimed that releasing a program as FLOSS will cause a lot of people to come over and fix bugs. In fact, this is false most of the time, but one thing that is certainly true is that it is possible for volunteers to contribute to a FLOSS game, and some may do so if the game is sufficiently popular.

Counter-Arguments

I can think of three major counter-arguments against the use of FLOSS game engines: "If I release the game engine as FLOSS, someone is just going to easily make their own game data and outcompete me." In fact, for most games, making a whole new scenario is hard work, and most people just can't be bothered to do it. Take Freedoom, for instance; Freedoom is a project that has been in development for much more than five years as of 2013, and yet it is still in alpha. This can be attributed to a combination of lack of interest (everyone wants to play Doom or Doom II, not Freedoom) and the amount of work that needs to be put in for it to be done. This contention is true enough for some games; Minecraft, for example, doesn't have any creative scenario to speak of (the scenario is entirely randomly generated), and in fact there are already suitable replacements for the art assets of Minecraft in a FLOSS clone, Minetest. But most games are not like Minecraft; most games have a significant enough scenario that any free replacement for it is not likely to cause a loss of profit. "I won't be able to benefit from other people's engines, but other people will be able to benefit from mine without giving anything back to me." This would be true if you released your game engines under permissive licenses, such as the Expat License (often ambiguously called the "MIT License"). But fortunately, this is not the only option. The thought of proprietary software benefiting from his work freely, giving them an unfair advantage, was the very reason Richard Stallman pioneered the concept of copyleft, which ensures that anyone who uses the FLOSS code in question does not do this. The most popular copyleft license, and the best choice in most cases, is the GNU General Public License. "I don't want to share my source code because I think it's art (or some other similar reason)." To be frank, I think this is as delusional as claiming that a DVD player is art because it's playing a wonderfully artistic movie. Most game engines simply are not art. They are simply an interface to allow players to play the game. It's the actual game, the scenario, which is art. If there is no scenario to speak of in the game, that doesn't make the game engine art, either. It rather makes the game more analogous to a simple toy than a DVD player playing a movie. Much like simple toys, such simple games don't tend to qualify as art. Don't get me wrong; I appreciate code as much as the next guy. I'm a programmer, after all. But there's a difference between appreciating code and mistaking it for art. "My source code is sloppy and/or inflexible; there's no way people would find a use for it." The assumption that people won't be able to re-use your code might be unjust. Statistically speaking, no matter how good your code is, most of it isn't going to be re-used. But every program has a potential for re-use, including sloppy ones. If there is enough love for a game, that sloppy code will eventually become less sloppy. Even if no one is interested in re-using your code for something else, that doesn't make the release of the source code meaningless. It is something the free/libre software community will appreciate, which gives you more exposure, and it makes it possible for the game to run on any system without you specifically supporting that system, assuming the game's dependencies run on those systems.

Conclusion

As you can see, not only is keeping the source code to your games unnecessary, you may be missing out on useful benefits because of it. Of course, you can continue to make your game engines proprietary. It's your choice. But I hope you will make the wise choice: choose FLOSS, and don't look back.

Article Update Log

5 Dec 2013: Initial release 6 Feb 2014: Added an objection
Cancel Save
0 Likes 39 Comments

Comments

Yours3!f

my thoughts exactly :)
also take into account anti-cheat measures and stuff like that.

December 20, 2013 08:30 PM
kop0113
Great article!

Expanding on one of your points. If players like your game, volunteers will be more than happy to port your game to their platform of choice (Linux, BSD, Plan9, Android). This saves a lot of work!
This is the only reason why Quake 1 is still playable on modern machines / OSes and something like Unreal 1 is not.
December 20, 2013 08:51 PM
wicked357

Yeah except one example MMO's... If I have full access to the source to build my own client, what would stop me from programming in game hacks instead of using 3rd party hacks? My example would be I programmed a hack for multiple MMO's that teleported me wherever I wanted. There would be no need to tamper with the memory cause it would be built right in the client.

Thus making it easier for anyone to write a hack for a game and ruining the game cause all you have to do is release the hacked client and everyone now has the hack wtihout effort or the hardcore cheaters who want to pay a subscription which in turn lowers the amount of hackers in game.

December 20, 2013 09:24 PM
SelethD

I have to agree with wicked357, I think the most logical reason to be careful with sharing your source would be to help prevent cheating... Granted, I have done my fair share of that, in my day, and I know from experience, that not having the source made hacks, and bots extreamly difficult to create.

Also, if your source is server code, it could have database information that could compromise the security of user accounts or other important things on your system.

But for small games, single players, or just a stripped down framework, there is no reason to worry about sharing.

December 20, 2013 10:49 PM
Wrathnut
I think any game with an online component would suffer from this. Including games that allow for micro-transactions. You can be compromising your customer's security by giving away the keys to the kingdom so to speak. This issue of fraud should be a much larger concern than cheating. But cheating will devalue your game to the point were it is unplayable also.
December 20, 2013 11:51 PM
colossal

The only thing delusional I have seen suggested regarding sharing source code is this entire article. There are plenty of avenues where sharing of source is appropriate, but this is simply not the case in terms of entirety for modern games. Games with ANY online component would completely fail under this nonsense for two obvious reasons. 1) Cheating 2) Private Servers.

Perfect example, NCSoft's Lineage 2. Take a look at this website: http://www.gamesites200.com/lineage2/ This site is a collection of all of the most popular private servers that are operated in the world for Lineage 2. NCSoft is not affiliated, nor receives any sort of compensation from these servers. In effect, all of these instances of Lineage 2 are pocketing money from NCSoft's work, resulting in MILLIONS of potential revenue lost. All of this was the result of NCSoft accidentally losing the source to the game server code some time ago into the public. Feel free to look into this http://news.mmosite.com/content/2006-11-20/20061120190829155.shtml.

This article is completely out of touch with reality.

December 21, 2013 03:38 AM
Hodgman

"If I release the game engine as FLOSS, someone is just going to easily make their own game data and outcompete me."

This really depends on which segment of the industry you're in.
For example, I was licensing a bit of middleware to a work-for-hire developer who makes pitches to publishers to acquire contracts to produce console sports titles under milestone payments. That's a very particular market, with a bunch of known competitors all pitching for the same contracts. When supplying middleware, I was asked for an exclusivity deal, where I wouldn't also supply the same middleware to the client's competitors. Any edge they can get, such as using secret/hidden technology, they'll take to stay afloat.
December 21, 2013 04:27 AM
alnite

I disagree with a lot of points in this article.

First, to say that Game Engine is the code and Game is the resources (level files, textures, models, sound) is incorrect. Unreal Engine is a game engine, a collection of code and tools designed to create and run games. But to say that, for example, Legend of Zelda's code is a game engine is a mis-statement. There are plenty of game logic sitting inside these games that only apply to that particular game and nothing else. Just because someone makes an RPG, does not mean he can claim that the code is an RPG engine. Try making another RPG with a whole different style (eg, from Skyrim to FF). Most likely, the developers would need to rewrite from scratch, unless they have designed the code to cater to both styles. If it can't produce anything else, you can't call that an "engine".


With FLOSS games, you don't need to worry about it; just provide binaries for some popular platforms and users of all the other platforms will do just fine compiling the source code themselves.

I am sorry but this is delusional. The amount of work to make the game cross platform is not just about switching libraries. The game itself have to be built with portability in mind. PS3 control schemes are not the same as PC, are not the same as Xbox, and are not the same as Wii. And we have only talked about control scheme. There's vast sound, graphics, and architectural differences between these platform that needs to be taken into account. So to say that you gain portability by open sourcing your code is false.

I think the author meant to say "You Don't Need to Hide Your Game Engine Source Code", and need to be explicit by what game engines mean. Stripping out resources from a game and just leave out the code certainly does not qualify as a game engine.

December 21, 2013 05:18 AM
ahmedismaiel

protecting your source code is not just about the support. it is about protecting the IP (this new fast technique, or this stream friendly file format) to have longevity( be able to make V2,V3,..) of this software. really cryptic code without useful example of how the assets and resources fit together to compose a game will probably do more harm than good.

December 21, 2013 08:06 AM
Semeii

One serious point missed is that if everyone would start throwing floss around, the amount of developers that can actually do stuff would decrease and there would be significant increase of people who only develop by mostly 'cut-and-paste', making games look and feel generic and flood everything with generic-remake-of-generic-remake type of stuff. You would probably even see some game mechanics, and overall rendering looks copied all over everywhere, heck, I can even tell every single game that uses unreal engine apart just from a single screenshot and I don't think that's good at all.

If I were a little bit funky conspiracy theorist here, I would say that you are conspiring to make indie games all feel generic, while the big AAA's would not floss and gain edge as indie game would become another name for 'that generic nonsense'.

December 21, 2013 08:47 AM
AbandonedAccount

This article ignores the legal risks involved in releasing source code. That is the reason a lot of developers opt not to release source code.

I also suspect keeping the engine separate from game logic would be quite a bit harder than the article makes it sound. Real-world code is messy.

December 21, 2013 04:29 PM
slicer4ever

The practice of withholding source code came about in 1969. IBM was the first party to charge for its software and withhold the source code to it. One has to wonder why IBM refused to provide source code, though; after all, copyright law already gave IBM a legal monopoly over the distribution of that program. So what was the purpose of keeping the source code secret?

The answer is simple: the point of withholding the source code was not to make money from distributing copies of the program, but to have an additional monopoly on support services. Because only IBM had access to the source code to its software, any time users of the software needed a new feature added or a bug fixed, they had to go to IBM, and IBM could charge more for the services because of this.


citation please.

this article is not very good at convincing me to release my source code imo. you are blatantly ignoring many cases where source code being available does more harm than good. online components would be easily compromised(one of the biggest problems with exploiting a system, is finding that exploit, which would be made 100x easier if a person had access to the code.) security is tossed out the window. all games are effectively made free to play, and now rely on the good will of users to buy them. even free to play game models are severly at risk, why work so hard to get things, when i could recompile my client to have that kickass model skin?

then let's gloss over the fact that company's shell out millions to build some of the most state of the art engines, and your asking them to throw out all that investment for free. you claim that they should then use licenses that prohibit others from copying that work, but what happens when people stumble upon the same idea/solution to a problem? now because that person released the source code, they are at legal risk simply for having figured out the same thing as another person. the world is already littered with these landmines, some company's exist solely to search for those whom violate their patents, and sue the daylights out of them. now you've just asked every developer to open themselves up to that risk.

what prevents person A from developing game, releasing the source, then trys to sell the game. but person B takes the source, recompiles it(making just a few minor changes to make them look like the author), and starts selling it for themselves? yes person B is illegally selling that game, but i'm pretty sure laws don't work the same everywhere.

There are so many problems with releasing commercial work as open source(hell even free work is at a potential risk), i really don't know where to begin, but if you can't see why being open source has problems, then good for you i guess.
December 22, 2013 03:47 AM
DaBono

I think the main flaw in the logic in this article is that it presumes that a complete game is the only revenue source, and therefore releasing the game engine code is harmless.

In my opinion, this would only be true for the 'game logic' of a specific game. People would still need the resources to play the game.

However, companies like Epic (the ones from Unreal) make huge amounts of money by licensing their game engine. Open-sourcing that would mean lots of revenue missed that would not go towards new engine development.

Side note, I feel quite some opinions in this article are (mis)represented as facts.

December 22, 2013 03:48 PM
DevilWithin

I think the thing to consider about source code releases is that doing it will create a chance to get trouble, while leaving it in the safe box will be probably be safer in many ways.

The two worst things I can think of are the risk of having someone else compile your code and sell it as their own( This has happened before, and while it can be dealt with, its always a major inconvenience, for example, Lugaru from Wolfire).

Also, when you spent hundreds of hours coding some feature that makes your game completely unique and spetacular, you don't want to share it for free with other developers. There will be probably a fellow developer checking out your code, drawing all the good ideas and snippets from it and implement that feature in his own technology.

Even game technology like SpeedTreeRT have a evaluation trial using their code, but don't just release their source to the public with a legal binding.

So, my opinion about this article is that in many many cases, its completely okay to release source and it may or may not bring any benefits.

But in games where special mechanics are the major selling points, holding the source might be very important for the company.

December 22, 2013 07:04 PM
Lesan

DRM does work. Sure, many games will be cracked; but if the developers can a few weeks with DRM intact, they'll get a lot of money.

This ("Someone is just going to easily make their own game data and outcompete me.") is a very valid counter-argument. It's akin to modding, except that you can sell and market the "mods" as an original game, not requiring the original.

December 22, 2013 09:43 PM
Postie

You mentioned MineTest, (a Minecraft clone), which reminded me of the story of Infiniminer, the game which inspired Notch to make Minecraft as we know it today.

Infiniminer was primarily multiplayer, and a month after release the source code leaked. Players took it upon themselves to make little balancing mods to the game and re-released them so others could also play. Community-involved development. Great huh? Well, no. The mods made the binaries incompatible with each other, so the once singular community fractured into many sub-communities that preferred certain gameplay.

Realising he couldn't put the genie back in the bottle, the developer gave up on it and moved on to other projects, which effectively gave Notch the greenlight to make Minecraft. Which is a positive I guess, but losing control of your project is a real risk.

December 22, 2013 09:52 PM
dilyan_rusev

Others have said it, but protecting your IP is the major reason why code is not released. If your game's edge is new technology, and there is little competition that simply doesn't get it, open sourcing the game will most probably kill your business. This means the competition can be as good as you, or that you can't release new versions, or content packs or in-app purchases, content packs, etc. Plus, you might be legally obliged to hide some of the source code.
I strongly disagree with this article.

December 23, 2013 08:26 AM
Carsten Germer

I love the discussion this article spawned! Kudos for keeping the discussion friendly and on topic!

Most of the arguments are as old as the first computer people could hook up to their TV and load a "game" up to and both sides had then and have now _very_ valid points.

It depends on so many factors around the individual project, I think it unwise to search for a general answer.

In my projects I have came to know both sides over the years and I mostly aim for a vanilla compromise nowadays:

No, I almost never give out the games sources. In most projects that's not even feasible, because the source is owned by a legal construct, not me. In a situation like that, the paperwork alone could kill by looking at you...

And, downright "cloning" can be a very real threat, just ask Vlambeer ;-)

But, how to give back to the community, how to help fellow game creators, how to get into professional discussion about the techniques you used?

After a project I look over the game design and the code and think about what's in there that is interesting or solves a problem I myself had to look up on e.g. stackexchange?

If something is really not trivial I write about it, in my blog, here, on gamasutra, etc. explaining the idea and the solution in text and protocode. That way it can be found by search engines and does not tie to a specific language or engine or whathaveyou.

Plus, I set time aside to go back to discussions, boards, articles etc. which I used to solve non-trivial problems on the way and post a few lines how I used the presented solution, giving kudos where I hadn't done it before.

December 23, 2013 10:13 AM
meeshoo

I kind of disagree with the article. Let's say I make a game, an IAP based one, and then I release its source code together with the game. The 1000 talented and hard working employees company in a country like India picks up the code legally as FLOSS, recreates a new content for the game and releases their own version. New brand, new everything, but the same game. You can't sue them for this, Zynga wasn't sued when they did pretty much the same, but they have to do their code too. From that moment on they can make things 1000 times faster than you and you are broken.

Of course they can do what Zynga did and imitate my game but that would at least give me a head start on the market.

December 23, 2013 04:16 PM
Ravyne

I'm sympathetic to the article -- it might not be viable for bigger, AAA games but I think for more niche markets its probably more palatable.

Indies and small games, for the most part, thrive because of their content and because of the niche markets they serve and how to serve them -- not because of revolutionary programming or bleeding-edge features.

The security/cheating angle is a reasonable one to make but lets also not fall into the trap of citing obscurity as security -- I admit that the real-time requirements of games make really strong crypto difficult, but in the crypto world no method is considered secure until it and its source are vetted in detail by the crypto community.

On the topic of clones, its a very regrettable situation that copyright law is just catching up to software cloning, but there have been some promising court decisions lately where courts have held that 1-1 clones, even if artwork has been changed (which is tentamount to claiming a new copyright on an old song by changing the octave), constitute a violation of copyright. That doesn't terribly help the fact that many of the clones come from overseas, but one could argue that the tractability of overseas clones might strongly reflect ones own ability to serve those markets -- e.g. If your game becomes popular but isn't localized, a localized clone can really clean up.

On the positive side, for games with a smaller but enthusiastic community, enabling them to mod your game, help squash bugs, or port to new platforms can be a boon. Such things help to expand and maintain your base, at low cost to you. Minecraft's popularity can be attributed in no small way to this exact kind of community and give-and-take.

On the issue of someone else using your hard dev work to compete with you using their own unique and deep content (rather than a shallow clone), it certainly can suck to be the first one into the pool because your stand to lose with no guarantee of reciprocal gain. However, in a thriving community of such individuals, you stand to benefit from their hard work as well should you ever wish to create an original work that is similar to something someone's already done.

Some of the issues can be worked out through licensing -- for example, by making the source free for non-commercial use, or use which benefits your community of users directly. Another option would be a license which explicitly grants commercial access to your source by an entity, so long as that entity agrees to reciprocate with their own source (say, limited to other game development, with a time-limit, or with means of negotiating an escape-hatch if they really do need to keep future development closed). This would be similar to how many competitors in other industries enter into such pacts (and sometimes pool covered IP into a nuetral, IP-holding company).

There are potholes to be sure, this notion is largely unexplored in games and in software in general, but its neither easy to dismiss or embrace out-of-hand.

I do really enjoy the discussion this is prompting, with well-opinioned views on all sides.

December 24, 2013 12:41 AM
paprik

This article is a joke. You clearly haven't done much thinking if you came up with a single disadvantage - DRM - and a few debatable tiny advantages.

- You're basically offering every single algorithm, shader or subsystem that makes your game different from others for free.

- You kill any hope for a sequel/expansion/dlc. You'd essentially be racing with the fan created free versions that are going to be better anyway.

- Multiplayer hacks and account safety issues.

The one single advantage is that others could learn from your code. Sadly, half the time this would be a copy & paste - few lines in the better case, entire files in the worse scenario.

This concept of sharing could realistically only be used in small indie single-player games, which kills the sole advantage. While you could possibly learn a little from such games, it would just lead to cloning and unnecessary piracy.

December 24, 2013 01:55 AM
3Ddreamer

Monopoly is a word being misused here.

For some companies, use of their created code by pirate developers to make software without giving credit to the original creators just does not sit well with their consciences. Pirate developers often save themselves thousands of labor hours for coding by pirating and some are making money at it.

Many people do not want to condone pirating PERIOD

December 24, 2013 06:44 AM
SaurabhTorne

Source can be given only to the trusted few. Everyone cannot have source.

Developers are giving the game anyways, and mostly games are free to download. Why give the source.

And if there really is something good to be published about the code, just release a whitepaper. The smart, dedicated and cunning will learn from it.

Game and Game engine , are basically same. Larger games can have separate modules but the most outstanding games are outstanding because gameplay is governed by great coding. Be it movies or games, piracy is distinct of medium. Art and code both are copied.

Id software did release its game engines like quake and Id Ttech, but its Electronic arts who actually got the lead later in the line with good marketing and wider market reach. But I wonder what would have been the todays state if, IdSoftware did not have released the source of their engines.

December 24, 2013 08:57 AM
4thworld

There are several things on which i disagree, most of all "Most game engines simply are not art". This is not true. The gameplay is in the code.

I have to admit that id job on realesing its code is wonderful and I'd like that more software house would do the same: this helps rookies more than stupid tutorials on the net.

A question : When you are working with console code that is using for example Microsoft/SCEE libraries or in general code meant for the PS4/XboxONE, can you release it on the net with a FLOSS/GNU license?

December 24, 2013 10:52 AM
Postie

I think there are other ways to "give back to the community" than handing over your entire source code. Adding modding capability into your game and then letting your community run with that still ensures you have ultimate control over the game, but your fans are free to go in interesting other directions if they like.

Since I used Infiniminer as an example in my previous post, it seems fitting that I use Minecraft as an example of a well thought out modding strategy. Initially, Minecraft didn't support modding, but some clever fans figured out how to inject some code into the game that would allow them to tweak things and create some crude mods. Rather than shut that down completely, Mojang engaged with the community and built a rich modding capability into the game engine itself.

December 25, 2013 01:29 AM
markr

There are a lot of other reasons games developers might not want to release source code:

* It's a dreadful mess - yes, really

* It includes lots of incompatibly-licenced components, in source form, its own source tree, possibly with undocumented modifications

* Nobody would *EVER* be able to compile it anyway. The build system is far too arcane and relies on countless other in-house build-time components from the studio, which would also have to be released, modified etc, to give any third party any chance to build the game from source. We don't have time to do all this extra work.

* Therefore, nobody would actually be able to benefit from it

* Cleaning up the code-base for release, preparing documentation and getting appropriate clearance from legal team etc, takes up time that we don't have when trying to make a game!

Basically, the source code of a real, commercial game is huge, messy and held together with string and duct-tape. Much of it isn't documented. A lot of it is from third parties. The build system is arcane.

Anyone who actually wanted to licence the source code to title X, would have to gain IP authorisation from all the dependency libraries (do-able, if it was another game dev house), buy licences for all the commercial tools required to build it, and get considerable support from the original dev team.

This is not going to happen for a A+ title. It might happen for a small mobile game or something, but it's fairly unlikely.

December 26, 2013 08:07 PM
GnomeTank

As soon as you said code wasn't art I kind of tuned you out.. The best programmers in the world will all tell you that programming is part science and part art. Writing clean, beautiful code that functions at peak efficiency with minimum amounts of code is absolutely 100% an art form. This isn't structural engineering, there isn't some book we can use to look up the "strength of concrete" as it were. Every software solution has to be crafted from a toolbox of a million tools, no different than a painting has to be made from a million colors. Sure there are theories and best practices and methodologies that help give some structure, but art has all of those as well. Go look up art theory sometime, it's an incredibly complex and scientific subject, yet it doesn't mean that art stopped being art.

The best programmers in the world are absolutely Van Gogh's with a text editor.

December 27, 2013 08:18 AM
Wavarian

As others have mentioned, there are many reasons for why you wouldn't want to release your source code:

1. People aren't going to learn much if anything from looking at your code. If they're looking at it then they're a) wanting to make a cheat for your game, b) are just curious about the number of lines it takes to make a game, or c) are looking for something they can sue you over.

2. To elaborate on 1.c. above, if you happen to use any patented code in your game, regardless of whether you came up with it on your own or not, you're giving other developers an open invitation to send you a cease and desist - hell, you're giving them an invitation to drag you into court for making "THEIR" code available to the public without permission... Good luck fighting that case.

3. Let's say you develop a game for Windows, but haven't gotten around to porting it to a mobile device (which your fans are demanding). You release the source code and the community makes their own port. Not only do you lose all of those potential sales, but you'd piss everyone off if you tried to shut it down.

December 28, 2013 05:58 AM
metsfan

I should send this to my boss, he'd get a good laugh. Good luck getting anyone to invest money into your game if your source code is open source. The premise of this article is flawed, and that is demonstrated by this statement:

"Understand: keeping source code secret does not by itself do anything to stop unauthorized copying.".

Businesses do not keep their source code a secret to prevent unauthorized copying. There are other measures built into software and sometimes even hardware to prevent this sort of thing.

The purpose of keeping source code a secret is all about equity. Source code is an asset. Businesses spend anywhere from tens of thousnads to hundreds of millions of dollars building source code. The applications themselves are valuable, yes, but the real value is in the source code itself. By exposing the source code of their applications, a business would essentially be inviting competitors take what they spent their hard earned cash on, and put you out of business. Additionally, sometimes in business the only thing you have on other competitors is a head start, and by giving out your source code, you forfeit that advantage as well.

I understand where you are coming from, and it is noble, but naive. Businesses take OSS every single day, brand it as their own, and give absoutely nothing back to the community, and snicker "those open source idiots, they saved us millions, and we dont have to give them a dime". I'm not saying OSS is bad. I love OSS and contribute to it myself. But the way us idealistic software developers think of OSS is not how the majority of the world, especially the MBAs, think of it.

TLDR - OSS is great, but sometimes its best to keep things to yourself, especially if you are trying to make money and/or have competition.

December 29, 2013 04:47 PM
Quasimojo

Two words: intellectual property.

I don't understand the purpose of this article. Why *should* the source code be expected to be included with commercial software??

January 02, 2014 03:49 PM
jmX

As you can tell by all the replies so far, this article clearly isn't written by somebody in the video games industry. It's misleading, ignorant, and just plain wrong. Having it on the front page of gamedev.net for over 2 weeks now is doing this site a disservice.

At some point an editor needs to step in.

PS. I've been on a commercial game that had to undergo a code audit due to an patent infringement lawsuit. In the case of the lawsuit, the company merely suspected we'd infringed, and that was enough for the courts to require us to give up the code. It turned out fine for us, but other developers didn't fare as well. To freely open yourself up to one of these things every time you release a game is insanity.

January 04, 2014 08:37 PM
Extremophile

Suppose you worked hard on a very unique game feature that makes your game feel different (for example, the gravity in Mario Galaxy), would you really want to share that with Zynga ? And saying that programming is not art is totally wrong especially in object oriented design.

January 05, 2014 06:11 PM
NikolaNS

I would only like to point out what happend to Wolfire with Lugaru on the Apple App Store.

In short they were selling their game for 9.99, and somone submited the same game for 0.99.

You can read the whole blog post from Wolfire here.

January 08, 2014 11:23 AM
diligentcircle

I'm glad my article has generated so much discussion. I just want to answer some objections.

I think there's a common misunderstanding: I never said that FLOSS games would be better business for large companies. I only said that it can work, and I was speaking mostly of indie games.

I'm seeing some objections which simply don't apply to indie games, most notably licensing engines. Yes, licensing engines makes a lot of money for big companies, but indie games rarely become that popular to begin with, and even if they do, their authors have nothing to gain by licensing use of the games' simple engines to other developers.

I am also seeing ignorance of copyleft. For example:

Businesses take OSS every single day, brand it as their own, and give absoutely nothing back to the community, and snicker "those open source idiots, they saved us millions, and we dont have to give them a dime".

Businesses can only do this with permissively licensed software. That's why Richard Stallman invented copyleft licenses. If a business chooses to use your copylefted software as a part of a program they are developing for distribution to others (like a game engine), it has to give back any additions it makes to the community.

Someone mentioned patent lawsuits being a potential problem, but this isn't a legitimate reason to hide source code. Software idea patents are such a huge problem that someone is bound to be able to sue you for patent infringement without ever needing to see your source code. You aren't made safe from patents by hiding a few algorithms and equations. The only way to be truly safe from software idea patents is to never develop or use any software, or live in a country that forbids such patents.

Some people are seriously over-estimating the amount of creative competition that would result from everyone being able to make a variant of your game. I gave the explicit example of Freedoom, but let me put it a different way: have those of you making the claim that this kind of stuff is going to prevent a sequel from being possible, ever tried sorting through all the user-created crap, just looking for something that's kind of fun? There's practically zero confidence in a bunch of anonymous enthusiasts making a fun game that you would like to play even in the rare case that a large number of people make games to begin with. If the original game's scenario is fun, there is going to be confidence that official scenarios are going to be fun.

On the other hand, some people are seriously under-estimating the effort volunteers will put into making a game they enjoy run on their preferred system. Project: Starfighter is a simple 2-D space shooter game that I really liked. At one time, I really wanted to play it on the OpenPandora Pandora. Project: Starfighter had pretty much every display element's position hardcoded with an assumption that the game window was 800x600 pixels, and the Pandora's resolution is only 800x480. I dived right into the mess, converted all the values so that it would run nicely at 800x480, and shared my port with other Pandora users.

Some have suggested that FLOSS online games are more susceptible to cheating. I can't think of any FLOSS online game that has a cheating problem. The only one I have played a lot is Minetest, which I know is basically completely immune to cheating, while ironically I hear that it's possible to cheat on at least some Minecraft servers because of client-side mods. If you host a server for any multiplayer game, you have the power to stop people from cheating. Even in cases where cheating is technically possible, it's trivial to simply make a rule forbidding cheating, and kick or ban anyone who is caught breaking the rule. For example, AssaultCube has no technical cheat prevention mechanisms at all, and yet I have never once had a problem with people cheating. Also keep in mind that most people are playing games because they want to have fun, and cheating isn't fun.

Some have pointed to server competition in MMORPGs. The factor being ignored here is that it costs money to run a server. Nobody is going to step in and host a server voluntarily unless the official server is unsatisfactory enough for the cost to be worth it, and the game is popular. Commercial competition, on the other hand, wouldn't work unless it grabs players' attention somehow; fulfilling a particular niche an official server doesn't, adding a great new feature, etc. If something like that does happen, and the server software is under the GNU AGPL, any improvements have to be released, meaning official servers can then incorporate some or all of these improvements.

Some have pointed out the difficulty of licensing code. But that's existing proprietary code; designing source code to be FLOSS from the beginning is much easier.

Again, I'm glad there has been so much discussion here; it's much more than I expected. Sorry I missed it when it was happening, too; I didn't know this article was published already.

January 10, 2014 07:15 AM
mjnhfgbdsafbxhg

Well, I find it disrespectful to say that a programmer thinking that his work is art is delusional.

Programming is an art, like drawing or composing musing, and thus a program source code is a work of art as much as the game assets to me.

I think that the DVD player too is art, but it does not have anything to do to the movie it plays.

January 11, 2014 11:40 AM
AVR

Most games aren't open source because code reveals algorithms and techniques, which can be very valuable and easily exploited (to make convincing trojan horse "add-ons," for example).

January 20, 2014 04:44 AM
DanielKruyt

Do you not make games so that they can be played and enjoyed? Games will always be pirated, copied and distributed; there is nothing you can do about that.

On the case of multiplayer hacks: if you do not write proper multiplayer code, the hacks will pop up anyway. Might take a few months longer but it will still happen. Client-side anti-cheats are worthless as well, rather do sanity checks on the server.

January 24, 2014 01:16 PM
vassapa

A powerful polygon bot, made to drive you to outstanding results in a passive mode. It uses multiple Trailing Stop orders to ride up and down market movements and generates higher income than any staking!

April 08, 2023 08:51 AM
vlad5

Hi, I recently learned about this website from a friend. It features a list of crypto influencers that you can organize according to specific criteria.

December 06, 2023 12:36 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!

It's fashionable these days for authors of video games to keep the source code to these games a secret, but this is entirely unnecessary for commercialism and detrimental to players. Learn why here.

Advertisement

Other Tutorials by diligentcircle

diligentcircle has not posted any other tutorials. Encourage them to write more!
Advertisement