Nuclear Network - Multiplayer Service
Community Forums/Showcase/Nuclear Network - Multiplayer Service
| ||
 Fast and furious multiplayer service. Free and paid (for pros) options are available. Visit the NN page for full details: http://www.nuclearglory.com/nn Here are the basics (copied from the webpage): (A) You signup for free (at the bottom of the webpage) (B) You setup your game on the member control panel (visible after you signup) (C) You download the network plugin for your game (from your control panel) (D) You program your game to use the plugin (with easy commands) Then, depending on your plan and preference, you can either use our subscription service (where we will charge the players on your behalf) or use your own methods of charging the players. As far as programming goes, wrappers are ready (with documentation) for C++, Blitz3D, DBP, and DBC. You will have access to these downloads after you signup (for free) at the website. If you have any questions, feel free to contact us or post. |
| ||
| how long would it take an average person to make his game multiplayer if it was say a FPS |
| ||
| Depending on your game structure weeks to forever. A game needs a quite different structure for multiplayer than for singleplayer |
| ||
| I think this is what Slenkar was getting at, but how much knowledge is required? How easy/difficult is it for a novice, newbie, useless programmer like me? |
| ||
| newbie: next to impossible to create a network game. You need some basic understanding on message management, data interpolation and other stuff which is not even nearly next to "beginner" or advanced beginner level |
| ||
| How easy/difficult is it for a novice, newbie, useless programmer like me? Compared to standard network programming it's a breeze. If you signup, and surf to the "ReadMe" section of the control panel you can download the full manual detailing the full command set. There are examples prepared to show basic framework of a multiplayer game using our service (ie: a chat application with source included). You're not bothered with huge amounts of "connection protocol" jibberish. For example, there's a single command that connects you to the network and gets everything started (command: LoadNetworkEasyNGN()), you join the net game of your choice, you send/receive messages to the other players, and that's it. Packing commands were created to turn numbers into 2 to 4 byte (character) strings to reduce the bandwidth when you send messages. And unpacking commands were created to expand these back into numbers again (for the machines that receives them). This may sound complicated, but hey, you don't have to write it yourself, so that makes things easier right? The only thing that can seem a bit daunting are your access keys. They are a requirement to both identify and secure your account, so we couldn't throw those out. The short version is: we aimed to make it as simple as possible without losing power/control/security for the programmer. |
| ||
| One tip, get zlib and compressing outgoing packets. It's Very fast and you get about 800% more bandwidth. (Group off all messages in the same direction and compress, decompress on the recieving end.) I think it's needed for games with high bandwidth requirements like physics based ones...this is a great idea btw..I've been put off doing multiplayer games because of the lack of a centralized server(other than gnet) any support for mmorpg like games planned? (I.e a set amount ofroom of your servers hd for local player info etc) I'll buy it right now if it has that ;) Perhaps people could say buy room? Like 10 dollers for 10 mb or similar..since it only needs text files mostly..but those who need big update files can buy more space of you..just an idea. |
| ||
| zipping the output is a bad idea. Firstly, the server will be zipping on average 16 packets 10 times a second at modem rates. Secondly, the server will also have to deal with AI. Thirdly, modems already compress data. These savings do not help a thing over broadband connections... I think zipping would help if you had to send a large amount of data across the network. The overhead of zipping and unzipping on the fly is fairly slow... |
| ||
| Well I did it for multinet and it was easily fast enough. (Zlib .dll can decompress something 10 or so mb a sec even o n slows cpus iirc) And as for adding compression, one of ad's friends suggested it was a good idea, and he was coding pro network code when you and I were still watching rainbow..;p so don't dismiss it without trying it. |
| ||
| I did try, and dismiss it. |
| ||
| One tip, get zlib and compressing outgoing packets. All outgoing data is simply set as a line of bytes through the server. So... if the client apps zip the outgoing data before sending it to the server. The line goes through the server and it gets relayed. The receiving computers decompress it. It would work beautifully and fairly fast I imagine. any support for mmorpg like games planned? (I.e a set amount ofroom of your servers hd for local player info etc) The high bandwidth of a mmorpg (and the necessary direct integration because of this) requires us to design a network script to integrate specifically with the mmorpg. A "generic mmorpg" structure doesn't work too well as you might create a sudden mountainess bandwidth burst if a bunch of people huddle together, etc... For something of that scale (at this time) we would have to work with you directly and do a custom job for your game. We're very good with price and are happy to work with you. HD space isn't currently part of the generic system, but we could set something up for you. :) Secondly, the server will also have to deal with AI. Actually, AI can be handled on the client-side machines and the "thought patterns" relayed to the other connected computers. This is actually a lot easier than server based AI because the server doesn't need it's own copy of the game world running. In conclusion, I think it's safe to say we're willing to do a custom job for anything if you're willing to cover the costs. Just give us a buzz, let us know what you want, and we'll get back to you with a price (a good one). |
| ||
| The most important part of networking is having every player see what everyone else sees. For example I could move forwards and then left. Thats a lot more important than what you're offering. I send to server, and server sees me move forwards and left. Server sends to other clients, that I have moved forwards and left. So whats the problem? round trip and interpolation. On an average connection I will be sending to the server at 10 frames per second. So each hop, we need to guess where I will be in the future for the clients. Does your system compensate? |
| ||
| On an average connection I will be sending to the server at 10 frames per second. So each hop, we need to guess where I will be in the future for the clients. Not necessarily. That's one form of multiplayer that has been experimented with although it does have a common flaw of "guessing" the wrong way and creating a bit of an "over steering" problem. With average connections you're looking at lag measured in fractions of a second, which is an issue all multiplayer games have to deal with in one way or another. You send a message that you moved forward and left and within a fraction of a second you've moved forward and left on everyone else's machine. The fact that you're sending 10 messages per second doesn't have much to do with it except for bandwidth reasons. And... you don't necessarily have to send 10 messages per second. Send a message whenever a player's state changes. Or/And you could send the player coordinates so the other machines know precisely where the player is (no guesswork). In short, most of it is left up to your client program. Our service simply connects you all together so you can write your client program. |
| ||
| I did try, and dismiss it. I believe,'I did and failed' would sum it up better, as when testing blitzNet(Which is complete but for the router) even when two clients were connected a server on a local machine, and all using compression, I could update network variables in real time(I.e a lot more sends per second than a game would ever need), using the above method. It works because you pack all packets into a single buffer and compress that..so it's only 1 compression job per client..no matter how many messages you send in one interval. - Nuclear, yeah i realise mmorpg server would be handled by player, but i mean some simple file funcs that work directly on say the hd space you guys would offer. like, nuclear_createfolder("players\") nuclear_writefile("players\jeff.txt") nculear_readFile("players\jeff.txt") I.e your server is only used for this. dunno what kinda bandwidth you'd need..but you could restrict to like 1k per client..it's only text. |
| ||
| Yes, it's definitely possible and we're likely to include such functionality in the future. Being able to keep records for each player has been one of the largest requests so far. We're waiting to see how the service picks up first :) |
| ||
| There is nothing on your site that gives the network capabilities. What down/Up speed do you have How many games are you going to run off the same server etc. When a service neglects to reveal important info like this on their site, I am always suspicious, because usualy it means they have something to hide. |
| ||
| nuclear glory, with respect I have to say that you are not giving this issue the attention it deserves. Carmack and Sweenie cannot be wrong in insisting on prediction. And their SDK's allow us to send a rotation or movement and it will accuratly arrive compensated for time. |
| ||
| What down/Up speed do you have. How many games are you going to run off the same server etc. We hadn't counted the information relevant assuming that most users would test the system (for free at no obligation) to demonstrate the usability and speed of the system. In any case, I'll work on having the information added to the website at least for verification purposes. @BloodLocust This is something that can be programmed on the client's end without need for the server to do it. When the client app receives the incoming movement data, have the client machine do its prediction calcs to compensate for time. |
| ||
| Hi nuclearglory, So in effect you are only offering server bandwidth, because there are many stable netlibs for blitz? I am just curious. Not only this, the further we are away from you, the slower your server will be. I curious how this will perform to me in the UK. |
| ||
| So in effect you are only offering server bandwidth Server bandwidth, network software for data management, client libraries to get the job done, and live online interactive control panel. I curious how this will perform to me in the UK. Signup and try out the free version. That's the best way to get your results. |
| ||
| Im a firm believer that in a large Multiplayer Environent, any and all AI, player movement related stuff should be done by the server. why? because its very easy to hack a client and modify the code to give the player some form of advantage in that area. Players cant modify the code that runs on the server so it should offer a much greater protection against 'cheaters' and the likes. |
| ||
| I'm about to check this out. We're working on a multiplayer game right now and I'm not sure if we're going to use your services or create our own which I've been planning on. |
| ||
| OK, first question? What about demo games? I guess that would come under a bandwidth account, but what if a developer wants a demo and also wants you to charge the players? |
   |