OK, first things first: There is no April Fools related material in this blog. I'm having enough fun pranking those around me. :P
Secondly, yes, I changed my CSS. Yes, it's still in ugly phase. It'll get better eventually. (On that note, what class do comments use? Trying to find it in the Inspector is a pain in the ass. Also, 3D view looks horrendous. Style sandwich.)Anyway, this blog isn't about my page… it's about networking, or 'network code', specifically. This is a topic I've stayed away from, mostly because it's mundane in comparison to the other things I could be messing around with. OS development doesn't count. But recently on IRC I was mentioning that I may or may not try my hand at creating something that'll stand in for 64DRPG. A standalone client and a simple C++ based server with the ability to run in a Linux environment as well as Windows. Of course, I've never actually made a game that has any semblance of network connectivity, not to mention actual real-time multiplayer. Fortunately, the problem is well documented, and even though I've never written netcode before, I know how to set up a simple virtual connection system that allows for an unlimited number of individual connections.So the result is this:A simple message exchange. Realtime. The server distributes messages between the clients (The clients don't respond to them, except for the client code transfer). The name of the 'server', Legend Online, was thought up at 3AM. As proven by science, I may as well have been drunk. :3Anyway, as simple as this looks, there are a few important things to note: > The server and clients are synchronized using a 'heartbeat' counter, to 'fight' packet contests (Determining order of operations when calculating game related stuff, basically). > The server has a very low CPU footprint, as it's only working on small sets of data. > It works over a LAN network, and can handle severe load and maintain it's low CPU footprint, and maintain order of receipt.Of course, I'm using UDP for this, and have built a 'virtual' connection system (Using OOP). Anyway, I've now determined that the system is fast enough, even if just locally; now I want to test it with one of my games. For that purpose, I'm building a simple client DLL, and shall use one of my complete GM games, and add a second player that operates through the network.Side note: Yes, I'm building my own networking DLL. 39DLL is horrible.Anyway, just decided to write something again. Also, Team Fortress 2 just finished downloading… Time to try it out…
Oh, and if nobody has seen this yet: https://www.google.co.za/intl/en/landing/nose/
Gotta love Google.
I didn't even see this blog. :/
Probably because it was posted at an obtuse time, and then eaten alive by April Foolery.You should add a second ninja to your ninja game, a red one. I'm not sure what the point would be, but the attack button would have a use! You could do time trials or something.Funny, I was thinking along the same lines.
Though I really want to test up to 32 players. Though in any of my games, that'd be beyond chaotic.DUDE 32 NINJAS! They need to be 32 different colors, too.
A 64RPG successor would be brilliant.
Have you considered implementing a feature that uses P2P to bolster bandwidth?Also:GmailBlueHoly cow that'd be madness…. If I get this done, I'll host a server…
Then we can all try running through the levels, stealing keycards, stabbing each other in the back… and probably get locked in at the end… :3EDIT: A P2P networking system would potentially make everything run faster, or increase the apparent bandwidth. But the potential for one person's bad connection screwing everything up…There are some networking projects that have been being worked on for some time now behind the scenes. *Sneaky eyes* you know who you guys are.
I would suggest, if you were using .NET, using Lidgren Network. It uses UDP and has an entire, simple, API for creating buffers and handling connections, disconnections, etc.
Neat project though. I love networking, lots of fun. Good luck!