# How do you allow networking code to be written in the later stages of the development?

I'm currently in the early progress of writing a game which I eventually will want to improve in most aspects.
How can I skip out on writing network code yet leaving it fairly easily implemented, that is, not having to rewrite the entire game just to add it.
What do I have to keep in mind?

I have a component pattern where I separate physics/collision-detection, game logic, data types and animating/rendering from each other.
How do I write a client and server that doesn't have any network code implemented yet can be tested locally?
What should I do in the client and what should I do in the server? Should I sort of just pretend I have network code finished and send messages between server and client and account for delays etc. even though there will be none?

Edit: It's planned to be a top down RPG. Simple multiplayer where you host a server for your friends is what I'm thinking, so cheating isn't that much of an issue (who would like to play with cheating friends?). Still I'd like to go with a "The server is always right"-approach.

Edit 2: I guess I'm looking for some pointers on what my mind set should be like. How should I handle keyboard input, animating, etc, instead of just applying every effect/change instantly. Hmmm, I may need to read up properly on networking before going anywhere after all, which was what I had hoped to get away from by making a network skeleton of some sort that could work locally.

• That depends very heavily on how you plan to implement your network code once you do get there. Quake (or some later id title maybe, my memory is slightly fuzzy), for example, took the approach of always being client/server. Even the single player option is actually connecting to a server at 127.0.0.1 and not inviting other players - meaning even the single player game runs entirely via network code. – LLL79 Jul 15 '15 at 13:11
• That's sort of what I had in mind. Maybe some inter process communication so that you don't need to connect when you want to play alone or maybe a class that has the same functions as the client but handles it like the server right away. – Ghork Jul 15 '15 at 13:23
• The best practice has been "don't" for quite some time. Unless you're writing a turn-based game, you simply have to design things differently to handle networking. If you care about latency, correctness and cheating, there simply isn't a way around that. If you don't, you don't really need to think all that much about it - if you don't have the experience, you're not going to predict the proper design well enough anyway. The best way is to get yourself started on a couple of networked prototypes to gain networking experience, really. – Luaan Jul 15 '15 at 16:44
• If you think of it, minecraft has a local server even in single player games. The server is the engine, the client is just a presenter. – SparK Jul 15 '15 at 18:33

Without knowing more about the exact game you're writing, and how you're writing it, it is very difficult to say generic solutions to your problem.

However, you may want to consider this decision you're taking of leaving the networking code to the end, depending on how crucial networking is for your game.

What I mean is that, if you're writing a network heavy game, such as an MMORPG, it may not be wise to leave networking to the end.

That considered, if the impact you expect for networking code is low (as in, not having networking code at all is not game-breaker), then it could be appropriate to leave it for a later (but not too late) stage.

Remember that -writing- networking code is not the same as -thinking- about it. As you make decisions about how your game is made, you should consider how this would affect networking decisions, and if the expected impact is high, maybe implement it as a stub that gives some generic information, and then when it's time to write the networking code, it is just a matter of plugging it in where you left the stub.

So, for instance, if you're making an online chess game, you may have a function called ExecuteMove() which is called in some way when a move is input by mouse, and in another way when a move is input by keyboard. At this point, you may want to think about creating a networking stub which, after getting the required data from the other host (this is what you write at a later part), calls ExecuteMove().

That way, as you create your game, you will know which parts are affected by networking code, and when it is time to actually write the networking code, you're several steps ahead.

If this is your first time writing a networked game, consider not thinking too much about anti cheating and stuff like that. Making a networked game is complex enough to require an entire team of highly experienced people to do so for an AAA game, so take it slow, and first make a game that does work, before focusing on more complex topics.

Finally, if this is your first time making a game, don't make it networked, please. Making a game is so complex, that each requirement you add to your game will make it exponentially more complex.

• Well, it's not MMO so it's not going to be THAT heavy on the networking. However it's not a stale board game where it's okay to take seconds before a move is made either. I feel networking should be thought of early on because, in my experience, adding multiplayer in the last stages isn't going to work out. However I don't want to be writing network code and debugging that before I can make my character move around and collide with objects. – Ghork Jul 15 '15 at 13:17
• @Ghork: Ah, you want to see your product do pretty things as soon as possible! Well, yes, we all do. But succumbing to that temptation is not going to lead to a well-designed and well-thought-out program. – Lightness Races in Orbit Jul 15 '15 at 16:46
• I'll accept this answer, though I like the other answers as well. Specifically the comment by @Luaan – Ghork Jul 20 '15 at 5:42

I'm in a similar situation, but I'm trying to do a networked simulation more than a game; but I think that my approach may help your design process.

My approach is along the line of your comment on IPC (inter-process communication).

First, as background I am studying the book "Networked Graphics" by Steed and Oliveira. This provides a good background on various network architectures for games depending on various criteria and game types. It provides a tool to help you decide your game architecture and what exactly you want to put on the network, and what you want to occur locally.

Second, separate the network components into a separate background thread so your initial game development can have the component coded locally, but you are forced to deal with the thread separation. Do not combine them with any other features that will later be "local background" but force them into "potentially remote" background threads.

This should help keep your logic separated and also allow you to simulate network delay factors into the process so you can also see the impact of latency.

• Guess I'll have to check that book out then! It sounds promising being able to do what you said. – Ghork Jul 17 '15 at 6:16
• @Ghork: The key is figuring out your architecture, what you want local and what you want on a server; or how you want peers to communicate and interact. That book should help. Then put everything that you want remote on the other side of an IPC message call through a set of client-server code which (for now) all stays local but keeps "remote" stuff on separated threads. In the IPC message passing component, artificially add any latency you want to simulate. Good luck! – Joe Van Steen Jul 17 '15 at 17:54

If you're learning about all this stuff, why not write a simple single-player Version 1, and once that's working, with your deeper knowledge, rethink the whole thing in-depth for Version 2 that will be multi-player?

Implement a "fake network" class that passes messages between threads, which has the same interface as the network class will have. Later you can elaborate the fake network to have random delays and packet loss. It will always be easier to debug network code with the fake class than with the real network.