If you know you’re going to network a game, should you focus on the network code first, or is it a good idea to script the game then add in network functionality?
If you are trying to implement networking for first time, then I think it would be good idea to start with simple networking demo, and later upgrade it.
Also depends how big your project is going to be.
Network first. In my experience, that takes the most thinking and planning. Add neat features to your game once you have basic networking working (e.g. multiple players joining a server and able to watch each other move around. You’d be surprised how something that seemingly simple can take a long time to get working.
Funny, I was wondering about this same thing a short while ago
Anyway, my suggestion is to design your game with a client-server architecture first with no networking included, and when you need networking, add it. Networking is a difficult feature, and normally, there are other features of your game with a higher priority (like map loading, movement, and possibly AI), so I recommend implementing those sort of features first, and holding off on networking. Designing your game with a client-server architecture is the easiest way I know of to accomplish this.
Making a small demo (independent of your other code) to learn how networking works is a good idea, but you must remember never to build your whole project off of that demo - that is just asking for design trouble.
The problem with that suggestion is that 1) you have little to show until networking is finished 2) lack of something to mess around with often generates disinterest within the developer team. Simply using a client-server architecture ensures adding networking when higher-priority features have already been implemented will be simple.
Another option you have is to use Twisted’s perspective broker to manage networking if you are coding both the client and server of your project. With PB you end up with an event driven structure where code to handle incoming events occurs at the object the event is sent to. You end up with a message passing design in your code that is transparent to most networking details.
Handling remote calls is straightforward if you have any experience with GUI oriented languages such as the infamous VisualXXX series of programs (including even the dreaded VB!). A remote_Foo() is similar in many design principles to something like an on_MouseDown() in that they respond to a received event (the former event is a “Foo” and the latter is a “MouseDown”) and may pass arguments to the handler. Instead of some dialog widget on a form providing the “event” your event comes from the other end of the connection making some remote_XXX() call on an object previously made available to it.
In something like VB you’d create a form which would have however many controls/widgets and as the user interacted with the widgets your code would have its on_XXX() event handlers called.
In PB you’d create twisted.pb.Referenceable objects that may be transmitted to the client (or server). When a client first connects it has access to a “root” object that may have whatever remote_XXX handlers is necessary to make other objects available (ServerRootObject.remote_login() for instance which might return back an account related object upon successful login). As remote_XXX methods get called by one end the handler on the other end gets called. The process is two way. Not only may a client call on an object presented to it by the server but a server may also make calls on objects presented to it by a client as well. The pattern of:
made on the client side or server side works as expected.