Jump to content

You Don't Need to Hide Your Source Code

Peer Reviewed by jjd, CRFaithMusic, jbadams

source code open source free software DRM modding support
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.

4: Adsense

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.


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.


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

About the Author(s)

Julian is an amateur game developer and FLOSS advocate. He has developed a handful of games, various small utilities, and a general-purpose 2-D game engine, all released under FLOSS licenses.


Public Domain


Dec 20 2013 02:30 PM

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

Dec 20 2013 02:51 PM
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.
Dec 20 2013 03:24 PM

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.

Dec 20 2013 04:49 PM

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. 

Dec 20 2013 05:51 PM
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.
Dec 20 2013 09:38 PM

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.

Dec 20 2013 10:27 PM

"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.
Dec 20 2013 11:18 PM

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.

Dec 21 2013 02:06 AM

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. 

Dec 21 2013 02:47 AM

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

Dec 21 2013 10:29 AM

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.

Dec 21 2013 09:47 PM

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.
Dec 22 2013 09:48 AM

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. 

Dec 22 2013 01:04 PM

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.

Dec 22 2013 03:43 PM

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.

Dec 22 2013 03:52 PM

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.

Dec 23 2013 02:26 AM

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.

Dec 23 2013 04:13 AM

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.

Dec 23 2013 10:16 AM

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.

Dec 23 2013 06:41 PM

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.

Dec 23 2013 07:55 PM

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.

Dec 24 2013 12:44 AM

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

Dec 24 2013 02:57 AM

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.

Dec 24 2013 04:52 AM

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?

Dec 24 2013 07:29 PM

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. 

Note: GameDev.net moderates article comments.