The IOs of Game Netcode #1 – A Few Rules of Thumb

This is part of a series of posts revolving around game netcode development, the introduction and links to the other posts can be found here.

 

First of all, welcome to the series! 🙂

This first instalment of The IOs of Game Netcode will cover a few rules that I’ve come to follow whenever I approach a new netcode project. Now, as I’ve been writing this I’ve come to realise that because netcode is mainly backend code, there isn’t going to be a whole lot to look at except large walls of text. I’m afraid I can’t do much about that. Hopefully, you find the posts interesting enough to persevere 🙂 So, without further ado, here are my rules of thumb…

 

Text is BAD

What I’m referring to here is text-based netcode serialisation is bad and you shouldn’t do it. If you do it, then you are a bad person and should feel bad. Of course, there are exceptions to this rule. The first being web services, which in all fairness is a pretty big exception. Turn-based games can get away with it as well. Also, you may not have a choice if you’re developing a mobile game due to unreliable Internet connections and are forced down the RESTful web-service route here too. I’ve played a few real-time multiplayer mobile games and they’re alright, if you’re on wifi, otherwise it’s a terrible experience.

So, if you don’t fall into one of the above exceptions, you’re going to want to go with object serialisation at least otherwise you’re going to get a lot of overhead on parsing your netcode into usable formats. Now, for a lot of you this is pretty obvious and you may be asking yourself “Why would any sane person try and implement a real-time game’s netcode with text-based serialisation?” Well, for some of the more inexperienced developers out there, it may seem like a good idea to use a flexible text format like XML or JSON for your netcode because “everything can read it” and “other people can write clients to consume it like a web service”. Just save yourself the headache and stop yourself now.

If you haven’t guessed, yes, this is something I chose to do while developing Root Access. This was a long time ago now and what roped me in was the flexibility, you don’t need to deserialise everything you receive and different clients can select only what they need, but this was an inexperienced train of thought. Of course you want to deserialise everything, if you don’t you clearly don’t have efficient netcode. Even though it did work, and pretty well at first, it got progressively slower the more data we shoved through it. Eventually, I went back and recoded all of the netcode to use Java’s object serialisation framework, which took a long time and was a massive headache. So save yourself the trouble and don’t do it! 🙂

 

Everything is Multiplayer

It is my firm belief, that if you are making a game with multiplayer, you should bite the bullet and make your singleplayer multiplayer. What I mean by this is your singleplayer is actually a private multiplayer session consisting of one player using the system’s local loopback interface. Of course, this basically means you need to START with your netcode framework before you can make any kind of progress. Yes, this does slow down the initial project start quite considerably and also makes developing the singleplayer aspect of the game a bit slower and require more effort, but I believe the benefits are definitely worth it.

For starters, you’ll finish your game faster. If your singleplayer and multiplayer modes use exactly the same code, then you’re killing two birds with one stone. All you have to do is flip a switch and you go from singleplayer to multiplayer and vice versa. Writing two separate systems to manage singleplayer and multiplayer will just be a maintenance nightmare down the road. There shouldn’t be any latency issues running singleplayer through the loopback interface. If you are experiencing any kind of noticeable delay while playing a local singleplayer, this just points out that there may be an issue with your netcode design / implementation, forcing you to fix it and resulting in a better multiplayer experience as well! 🙂

Lastly, and this is the big one, you’ll avoid the gargantuan headache that is retrofitting multiplayer into your game. If you focus on singleplayer only to get your game out as soon as possible, with the idea of multiplayer coming much later on, you’re in for a world of hurt. I’ve seen so many game developers do this as well, and it basically appears that they’ve hit a brick wall in terms of progress because they are so busy behind the scenes refactoring, debugging and generally rewriting a huge portion of their game. I was actually impressed when the guys at Mojang managed to retrofit Minecraft’s singleplayer into a multiplayer system to support LAN play, but it required huge changes including the way their singleplayer stored its map and player data. So, if you’re planning multiplayer at ANY point during a game’s development, DO IT FIRST! You’ll thank me later 😉

 

Stand Alone, Together

Now this one may not be as obvious and a lot of people may actually disagree, but I think it’s something that can help a game’s design, development and maintainability. When writing your multiplayer framework for your game, separate the game client and server into separate projects, and also build them as separate binaries. It may be tempting to implement your multiplayer server into your game client as it’s easier to work in a single project, especially if the game doesn’t really require a dedicated server. Do it anyway. The reason I say this is because you’re going to end up with a lot of duplication, particularly in regards to the game data (which is understandable due to the client and server’s own knowledge of things). If you’re not careful you’ll start cross-referencing data without going through the netcode properly and before you know it, your multiplayer isn’t truly multiplayer and it’ll be a development and maintenance nightmare.

If you do separate your client and server into separate projects, but plan to compile and distribute together as one application, then I don’t really see a problem with this. I just prefer to go all the way and build as two separate applications, then you have a dedicated server from the beginning. Then for locally hosted games, you just get the game client to launch the server in the background, telling the server that the player is the host / has admin privileges by providing a player’s token or account ID to the server process. This also works for singleplayer games as mentioned in the Everything is Multiplayer section raised above, just you keep the game private, skip the game lobby screen and launch straight into the game.

What I have suggested so far makes the assumption that your client and server are written in the same language. If they’re not, then you’ll probably never encounter these issues, but there is also an advantage of working in a single language and that is shared projects. Back in the day when we were very much Java, Java, Java we usually started a new game with the same triad of projects. Client, server and shared. The client and server were dependent on the shared project, which housed all common functionality between the client and the server. It included the netcode framework, netcode commands and data structure classes. This removed a whole tonne of duplication in the projects and is something that worked very well for us while we worked in a single language. It’s a lot harder to do when you work in Unity and C++ :). Anyway, since those days, I’ve refined my thinking a bit and come to the conclusion that sharing the netcode framework and potentially the data structure classes is potentially a bad idea, and that only the netcode commands should be shared.

If you share your netcode framework you have to start writing in special cases depending on whether the process using the framework is the server or the client, as well as identifying the source of a netcode command (whether it is the server or a client and how to handle it). I actually saw someone tweet a code snippet that made reference to this exact check recently and, to be honest, I don’t think it’s needed. Of course, there’s always an exception to the rule. If you’re developing a peer-to-peer model, then you may not have a choice, depending on how your client gets its peer list. Anyway, the reason I mention that you shouldn’t be sharing a data model either is because your client should never know everything your server knows. The client should only know portion of your server’s game data, only what is relevant to it. Also, you should only be sending client required data for each entity class. Your server versions of the entity classes will contain a lot more and some of it may be sensitive. Your server’s game data classes will also contain a tonne of functionality regarding how the entity behaves, that the client should never need. If it does, then your design is wrong as your server is not fully authoritative and then you have another whole lot of problems, such as players being able to headshot everyone in the server with a press of a button or players setting their own stats (Yes, I’m looking at you Battlefield).

Some of you may be thinking “I don’t see the problem, I’ll just create pure abstract data classes with only the common data between the client and server, with no behavioural functionality. Then subclass in each of the client and server projects”. By all means, you can do this. I just find this to be a pain because you end up maintaining three data structures.

 

Anyway, this post has gone on far longer than I thought it would so wrapping it up now. Sorry for that, I’ll try to keep future posts more concise and maybe provide code snippets to illustrate my points 🙂

If you have any questions or just want to chat netcode, just comment below or fire me a tweet at @Jargon64.

Thanks for reading! 😀

The IOs of Game Netcode #0 – Introduction

I’ve done a lot of coding over the years and learnt a substantial amount, either through reading tutorials, looking at examples, trial and error, reverse engineering, etc. So I’ve come to think I have a wealth of knowledge regarding the subject these days.

For a long time I’ve been thinking that I’d like to give back in some way. So after some thought on what I could share I’ve come to realise that nearly all of the games and other projects I have worked on have networking implemented in some form or other, and for the most part, this has all been developed from the ground up with very little library use (you can take this as good or bad, probably a bit of both). Also, it hasn’t just been the same type of networking. Infact, it ranges all the way from XML serialisation to binary serialisation, and everything in between.

Now, I don’t consider myself a guru on the subject, but I’d like to think that I have an advanced level of knowledge on it. So, I’ve decided to create a series of posts based on my experience on game netcode development and what I think is the best way of implementing game netcode as well as the issues that I ran into that led me to think this way. Hopefully, some of the game devs out there will find what I will be sharing useful and maybe beneficial to their current projects!

I’ve decided to call the series The Ins and Outs of Game Netcode or shortened The IOs of Game Netcode. Now remember, these are my opinions based on my experiences, so don’t take it as fact. I don’t think there is a single right way to do it, but I’ll be sharing what works for me and how I do it.

This introduction post will also serve as a contents page (with links) for the series. So stay tuned 🙂

Contents

Merry Christmas!

We hope everyone is having a great day so far!

Looking back over the past year it’s amazing to see how much has happened to Rogue Vector. We can’t help but review what has past and wonder what will come.

Rogue Vector entered the year as Deadworld Studios. After a trademark dispute we decided to change our name to Rogue Vector. In hindsight it was a very good decision and we feel very settled and happy with the name less than one year in.

As the year went on we worked with Mr Dog Media to develop Banshee. With that wrapped up 7 months later and being released next year, we took some much needed rest.

So, what does the new year bring for us? Well, we’ve started development on our next in-house game. It’s really early days so we don’t have a whole lot of information to give out on it yet but we’ll be starting to expose the development process as we ramp up our work. Needless to say, we’re very excited that we’re finally able to build this game as it’s been a project in our minds for a very long time in one form or another.

So once again, from us here at Rogue Vector, Merry Christmas!

Mechadroids – Round 15

Quarionaid

Round 14 has just come to an end ended with Quarionaid on top of the scrap head, congratulations! There he is in all his glory on the right. Runners up this round ElSnoopere and guima, coming in at second and third place, respectively. Congrats to those guys as well!

As always, you can visit the Hall of Champions to view all previous rounds’ winners in their fully customised awesomeness!

Round 15 has just started, good luck everyone!

Mechadroids – Round 14

DarkN

Round 13 has just ended. Congratulations to DarkN for his place on top of the scrap pile podium, with SuperAndroid09 and KRONOS just slightly behind!

Please visit the Hall of Champions to view all previous rounds’ winners in all their customised glory!

Round 14 is commencing immediately, another 2 month round, so let the fighting begin!

Mechadroids – Round 13

Round 12, another 2-month long round, has just concluded! Congratulations to chicoteRAW for clawing his way to the top of the scrap heap and obtaining first place!  He can be seen in all his glory to the right 🙂

Additional congratulations are also in order for KAOTTICO and lmn for 2nd and 3rd place, respectively.

As always, you can check out all previous round’s winners by visiting the Hall of Champions!

Round 13 is commencing immediately, so get in there and make some more scrap metal!

Kickstart Banshee!

Some of you may know that we’ve been working closely with Mr Dog Films over the last few months on a transmedia project called Banshee.  We’ve made excellent progress so far, but now the time has come to get Banshee the funding it needs to become the game we want it to be.

As of today, Banshee is now being crowd-funded via Kickstarter with lots of excellent pledge rewards.  It would mean the world to us if you supported us by pledging.

Everything you need to know about Banshee can be found on the Kickstarter campaign site and the Banshee Facebook page.

Thank you!

Wales Games Development Show 2013

Rogue Vector will be at the Wales Games Development Show 2013 again on June 26th this year! We attended last year as Deadworld Studios so we’re looking forward to christening Rogue Vector with another great show!

We’ll be showing off some gameplay footage of our current project, Banshee, as well as the other games we’ve developed over the past few years.

At time of writing, there are only 22 free tickets left so you better be quick!

You can grab a free ticket at http://walesgamesdevelopmentshow2013.eventbrite.co.uk

Hope to see you there!

A New Game Announced! Banshee!

We are very proud to officially announce that we have teamed up with Mr Dog Films to develop the game for a new transmedia project called ‘Banshee’.

Banshee

Over the past two months we’ve been hard at work creating an experience that brings true horror to Facebook in the form of a real time, multiplayer game. Banshee is about survival and discovery, with the indirect result of territorial conflict, involving two teams – the emergency services and the spirits. The two teams will try to take control of areas of the city with the use of light and darkness, while discovering the lore of the world!

The game will be a first of its kind in eventually delivering the full length horror film, made by Mr Dog Films, via the game. We’re using Unity for development as we felt it was the best fit to achieve the level of immersion required for such an experience.

We’re really excited about this project and we’ll be releasing more information as we develop the game. Expect to see live streams and developer video blogs from us as the months progress!

For more information please see the Banshee Facebook page and website!

Mr Dog Films logo Unity logo

Unity Development: Monitors – Part 2

This is part two of an article series for Unity Development on an interactive computer / monitor system. See part one here.

Over the past two months I’ve been slowly continuing with the Monitor system that I’ve decided to name ‘Farseer’. My last blog post ended with some open questions regarding the various design choices I faced, such as how to lay out the monitor’s view in the scene space. To quickly sum up I had two choices.

  • Place the monitor views outside the viewable scene space
  • Place the monitor views on the actual monitors but on a non-viewable layer

After some thought I decided to go with the second option. I felt this would ultimately be the best approach as it kept things spatially together. I discussed my choice with a few of our community members and they seemed share my opinion.

Now that the above issue was decided on… what was next? I felt that I had taken the current approach as far as I could and it was time for the next step. With this, Farseer finally was elevated to its own project! (I tend to prototype in a common project as it saves some time setting things up again).

farseer

My intention for Farseer has always been for it to be used in a procedurally generated game. The system will need to work well being accessed by various game systems, however, I didn’t want to limit how the system could be accessed. I wanted Farseer to be useable in the Unity editor too and so, with those thoughts in mind, I set off again!

As soon as I had made my mind up to make Farseer as flexible as possible, I hit another design choice. Should I use prefabs for the monitor objects, or not? Think of Prefabs as a ‘here’s one design made earlier!’ approach within Unity – a design of an in-game object previously set up by the developer. Unity development tends to encourage heavy use of prefabs and with good reason. They make development a lot less complex and messy. If I decided to use prefabs I would create ‘monitors’ of various sizes for use. A developer could then create one of these monitors that best fit their needs. My only concern was that I had previously encountered some issues involving the interaction of prefabs and RenderTextures (the flat 2D ‘live’ image view of what the monitor is looking at). In the end I had two choices – use prefabs or use a non-prefab, more code based approach.

Prefabs

I initially decided to pursue the prefab approach but I hit various issues that made me backtrack. The issue I encountered was that the Unity Material (something that helps define how an object is displayed in game) assigned to the monitor prefabs and Mesh (effectively the 3D model) seemed to be shared between all prefab instances (an instance being a ‘constructed’ version of a prefab).

In hindsight it was probably user error on my behalf. I was sharing a lot of Meshes for the monitors and this was probably causing the problems I saw. Ultimately, this meant that if I tried to changed a Shader effect on a monitor instance, it would change it for all instances of that monitor prefab. I realised that to make Farseer as flexible as possible I shouldn’t create monitors of various sizes as this approach is inherently limited.

So… with my new found knowledge (or so I thought) I took the more code based approach. I would generate the monitors as and when required using the required dimensions. This involved a bit more work but it was more flexible in the end, and by using Unity Editor plugin coding I was able to use Farseer in the Unity Editor too!

Menu

I plan to have preset monitor types that can be quickly created without a lot of effort but I also wanted to provide finer control over the system. I thought a two stage system of ‘Create Monitor’ then ‘Create View’ satisfied that need.

CreateMonitor2

CreateMonitor

Looking at the pictures above, ‘Create Monitor’ concentrates more on the creation of the Plane / Mesh (effectively the 3D representation of the monitor) and it also generates the most suitable RenderTexture to fit the custom monitor size / dimensions. Once created you can see the beginnings of a monitor!

CreateView2

CreateView

Again with the above pictures, the ‘Create View’ concentrates on creating the actual ‘View’ and linking it to the 3D monitor.

Taking a deep breath… that’s where I’m up to right now. It has less ‘pretty’ functionality than where I was at in the last post but my next step is to reintroduce the interactive sections I already have working. I don’t have any real blockers right now other than finding the time in between our contract projects to dedicate to Farseer. I’ll post another update once I’ve made more progress!

Until then – thanks for reading!

Interfacing with UI #4 – Coherent UI

February 5th, 2016

This is part of a series of posts revolving around user interface design and development, the introduction and links to the other posts can be found here. Last I wrote about user interfaces I discussed the new Unity UI system and I wrote about our process of porting from Daikon Forge to it. That was a year and a half ago and a lot has changed since then. To keep things interesting we decided to move from Unity UI (yet another move?!) to Coherent UI and I’ll explain why we did it. Why Move… Again?!... (read more)

@RogueVec: And so it begins! #RebootDevelop

19/04/2018 @ 8:05am UTC

@RogueVec: We'll be at @RebootDevelop this year. We can't wait! If you want to hang out just give us a shout! #RebootDevelop2018 #GameDev

16/04/2018 @ 12:06pm UTC

@SolitudeGame: Fullscreen terminals allow you to hook into your ship's guns for fine control! Moddable gun modules, terminals and UI! https://t.co/B5N01jrA70 #GameDev

8/12/2017 @ 4:58pm UTC

@CWolf: Woo! And, now we have a cross-compiled (nix --> win64) @SolitudeGame server in our build and deploy pipeline #RV #GameDev

28/11/2017 @ 3:39pm UTC

@CWolf: CI love #GameDev #RV

21/11/2017 @ 4:06pm UTC