Hey
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.
Buying existing code to lower costs?
You won't find a lot of companies which just license out parts of their game's code for others to use, but there are companies which offer middleware libraries which you can license for these purposes.
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.
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.
I think it's rather uncommon for companies to simply sell part of their source code.
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.
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.
Estimate what value you put on your time/your development team's time. Estimate how long it would probably take you to do this yourself. Now double it, because that's how reality works 
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.
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.
Yes, buying a ready-made library that solves exactly the problem you want to solve can save money.
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!"
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!"
I think COHO, Starcraft 2 and W40k Dawn of War 2 all use the same underlying engine in their games (if not then color me surprised) but as far as not prebuilt engines I think the best you're going to do is the more framework kind of things like enet and boost::asio that merely make it easier for you to do your own system.
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).
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).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
