It’s been a fairly busy few weeks since the last post, and you may be disappointed to hear it’s not ‘all about Dom’ either.
The great ‘Project Management Housekeeping‘ exercise led me to check up on the status of my past and incomplete/shelved/abandoned projects to see if anything is worthy of inclusion into the shiny Redmine instance.
On my travels back in code-time, I stumbled over my attempts to get a networking stack into the 666 engine, imaginatively titled ‘NET’. I started this back in 2000 when I first got into C/C++, and have bumped up against it from time to time, on and off, over the intervening years. I was never that full on with developing it, as I know networking is a royal pain in the and there are lots of existing third parties (such as RakNet) which I’ve put on the ‘consider list’ should I ever get to needing them.
After firing up the project in VS2015, I was quite dismayed to find I’d actually left it in a working condition! I thought I’d parked it years ago because I’d got stuck. The last I recalled, I had established a remote connection across my Server/Client pair, but the data sent through was all a tad squiffy.
Well, lo and behold, it worked! So much for organic based memory eh?
‘Of what relevance is this to Dominium?’ I hear you cry!
Well, Dominium will be an online MMOG type affair, at some distant point probably beyond my mortal life span (providing I’ve been able to transfer my mind to the Vox Constans and forego true death). So I have an idea in mind on how to achieve this networked wonderment all by my lonesome, and that requires a robust networking stack to base it on. Going through my past projects prodded some ideas, and I was wondering what would be involved in getting NET back up and running, and instead I find it already running and ready to go!
Dominium will need to maintain a goodly number of live clients all in the same space, in realtime with lots of interactions (such as shooting each other)… and I have an idea on how to achieve this. Now, don’t get me wrong, I am not blase, I am not conceited, I am not stupid. Software Engineers can devote their entire lives to such and still not achieve ‘the perfect solution’. Predictive positioning, lag, error correction, packet lost, et al – there are any number of concerns and woe’s to overcome. Fortunately, modern day ‘internet gamers’ are a hardy breed – by and large – and used to the faux paux, errors and whims of a slightly overtaxed networked game. But with modern day bandwidth creeping up (finally) and also processing technology ever increasing in threading capacity/speed/on-die caching, it’s getting easier to ‘fill in the gaps’ where things go wrong, and also easier to reduce the duration of those gaps so that the error correction doesn’t have quite so much of a ‘jarring user experience’ as it used to back in the day. (Such as playing Quake on a 100Mbps LAN with Pentium CPU’s and watching someone easily avoid your RPG to their face by simply no longer being where you just shot them, but ten metres to the left of you and shooting you with a lightning gun instead. No offence meant to id’s networking code as it was then, it was pretty darned awesome and did the best it could, but really, that experience did kinda suck on the rare occassions when it happened.)
Dom will need two ‘network’ streams – as such. One for all the realtime goodness of players shooting stuff and each other, and another for the persistent universe. The latter won’t be realtime, but more ‘query/response’ based… because getting an answer to it’s demands is not so time critical. Consider your browser roaming the internet across various fast/slow servers. You ask a question (i.e. hit a URL), and at some point you get an answer (you get the web page served up). It’s not realtime sensitive. Yes it’s annoying, but you didn’t get frag’d whilst waiting. With luck.
With that in mind, I can really cut down on the kind of data needed to communicate real-time changes from client to client. I hope 🙂 Of course, I will need to consider ‘player contexts’… you can only have so many players in a server instance, and something needs to balance how many are in each, which means defining rules for who is in which one… etc. Busy busy!
My initial aim is to get a small ‘100 moving sprites’ thing on the go, where each sprite is controlled by a client, and the client sends it’s location/orientation to the server. The all the other clients get an update, and so on. The whole server/client will be data/game-agnostic, it provides connection, authentication, lobby, transmission and security and that’s it. The actual game data going through is irrelevant, and it doesn’t care as long as the packet sizes are honoured. Of course, I can’t see any sleepers across the upcoming tracks, but they are probably there waiting…
I’ve now got it working remotely, so I can hit my Server running on Mac OSX from my Windows laptop anywhere in the world where I can get an internet connection, and they both happily chatter away. That is a major ‘feel good’ factor right there, I can tell you 🙂
From Dom’s perspective, this would then be easily extended to allow ship positions and orientations to be sent back and forth, providing the (very) basics for a true ‘MMOG’ universe.
So – after derailing myself on a brief trip through ‘Happyland’, I will now bring my sights back onto Dominium proper, and get cracking. I’ve already fixed an issue I’d introduced into the graphics pipeline, where I’d applied some very cool shiz to the depth buffer – but more on that in an upcoming post. And from a game developer point of view, I can tell you, it’s just truly awesome, awesome, awesome shiz provided by a kind soul on t’net. And I’m going to credit them good and loud, because it’s just stupidly, simply amazing (for a techy graphics coder that is 😉 )
Stay tuned!
Comments are closed.