Buying existing code to lower costs?
Members - Reputation: 107
Posted 23 September 2012 - 05:35 AM
Let's say you found a game studio which has a game with the exact type of multiplayer functionalities that you want for your own game. Games like starcraft, league of legends and most of the strategy games now a days tend to have a similar hosting, matchmaking and ladder system. If your looking to keep your own production costs down, could it be a good idea to license or buy the multiplayer part of an existing game?
I might be completely off here as my programming skills is very limited.
Crossbones+ - Reputation: 2550
Posted 23 September 2012 - 08:09 AM
I'm not all too experienced with networking libraries so I couldn't give you any example of such a company/library, but I bet that some kind of game-oriented networking solutions exist.
Software Engineer - Skybox Labs
Crossbones+ - Reputation: 1547
Posted 23 September 2012 - 08:33 AM
Furthermore, as modular as their engine might be, there is a big possibility that the network code still depends on other parts of their game.
That said, there are a lot of usable, affordable network libraries out there. Chances are the company you want to buy network code from is already using one of those.
Edit: One more thing. I guess most companies won't give out network code for security reasons also. If they published their netcode it would make life for hackers and cheaters all too easy. OTOH, reverse engineering is still done. So that would most likely just hold back the cheaters for a little while.
Edited by Madhed, 23 September 2012 - 08:36 AM.
Members - Reputation: 245
Posted 23 September 2012 - 02:41 PM
Contact them and tell them you may be interested in licensing it, ask how compartmentalized it is and some other details you need.
Is it possible they'll say "no"? Yes. But it's also very possible they'll be thrilled to get thousands of dollars for basically nothing above what they've already done. This is especially true if you're contacting a company that is not one of the juggernauts.
"You can't say no to waffles" - Toxic Hippo
Moderators - Reputation: 3967
Posted 23 September 2012 - 03:26 PM
However, several things need to be true for this to actually pay off:
1) The cost to learn and use the code has to be lower than the cost to simply develop the parts that you need. Programmers tend to over-estimate the cost of learning, and under-estimate the cost of developing and debugging code, but there still are cases where rolling your own is cheaper.
2) The library has to be used by a number of other customers already, and has to be designed as a general-purpose library, rather than just be "a part of an existing game." The reason is that parts of an existing game will unavoidably have all kinds of game-specific assumptions and even hacks in it, that will go against what your game needs.
3) The component is not integral to what makes your game "yours." It makes no sense for Rock Band to buy the part that matches up player button presses with the displayed fret board, for example -- that's a core feature of that game.
Now, when it comes to networking, that is generally tied to your gameplay in a very intricate manner. This is because the internet introduces latency, and most of the challenge of game networking is to artfully hide that latency in a way that works well with your particular game. Thus, networking tends to be very tightly integrated with the way that physics, and game presentation (graphics, audio,) and game controls work for your game.
This is why you find complete networking solutions in two ways:
1) The simple "connectivity and matchmaking" libraries. Libraries like ENet, RakNet, and Lidgren fall in this camp. They do connecticity, but they do not solve the difficult "integrate with gameplay" bit -- you still have to do that.
2) The full-on "game engine" solutions. Unreal Engine, Crytek CryEngine, C4 Engine, and many others, all pick a particular kind of game that they work best for (first-person shooter, or action-adventure, typically) and deliver a networking solution that is tuned for that kind of gameplay, and integrated deeply into their engine. This means that, if your game is fundamentally different (such as an RTS,) you will actually have two problems: One is that you'll still need to do your own integration, and the second is that the networking that's already there may actually get in the way.
So, the answer is, as always: "It depends, and your best bet is to have people on the team who know what they're doing from lots of experience!"
Members - Reputation: 350
Posted 23 September 2012 - 06:05 PM
Really, there's two different levels for the networking code: The part that shovels data around and the part that takes that data and turns it into game play. That second part is the killer, and depends entirely on the game itself since it's poking around directly in the game state (or, better yet, sending it's translated data directly to the input system).