Comments
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.
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.
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.
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.
This really depends on which segment of the industry you're in."If I release the game engine as FLOSS, someone is just going to easily make their own game data and outcompete me."
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.
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.
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.
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'.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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?
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.
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.
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.
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.
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.
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??
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.
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.
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.
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.
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).
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.
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!
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.
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.
my thoughts exactly :)
also take into account anti-cheat measures and stuff like that.