Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Get the latest Education e-news
  • How to Become a Great Network Programmer: Part II

    - Adam Martin
  •  In Part I of this article, I explained what a network programmer is, why so many companies are eager to hire them, and what courses a person should study if they want to become one.

    But much of what a network programmer needs to know comes from hands-on experience making games. This article outlines four small games that a beginning programmer or student can make to gain more experience working with networked systems. I'll also look at more of the high-level challenges that network programmers face, so you'll have the inside take on what this job is really all about.

    Four Games You Can Make Now

    In a single player game, if badly written software interferes with your game, you can at least ask the player to uninstall it. But that's not possible with the internet.

    To pick up some practical experience, you'll need to write some games. If you can, build these games while you're in school. Most courses have a series of practical programming projects that let you can choose what you want to implement, and it doesn't take much to convince a professor to let you work on video games.

    The four games given below are listed in approximate increasing order of difficulty and are arranged so that what you learn in one game will be useful in the next.

    Game 1. Multiplayer Tetris: Basic Networking

    It's Tetris, but it's multiplayer. Simple enough?

    Start out by making a two-player Tetris clone. This will test how well you understand how to send and receive network messages. All you're doing is setting up a basic two-way communication system between two machines and getting them to play a very simple game together, a task so simple, you should have very few or even zero bugs in the game itself. Because this game is pretty basic, you can concentrate all your efforts on fixing bugs in the network code.

    Making a multiplayer Tetris clone will also force you to start thinking about the two fundamental problems of network programming: latency and distributed states.

    You may find bugs in your initial code that cause huge latency issues, but you should be able to solve them quickly. Likewise, you may find that the two computers are running different games of Tetris because of mistakes in your sharing-of-state information. Again, there's so little data involved that you should be able to rapidly debug and fix it.

    For bonus points, make the game work with more than two players. Try three or even six. (Hint: You probably started with peer-to-peer for two players, but for many players, it's much easier to develop and debug if you have one computer acting as a server and all the rest as clients.)

    Netris, a networked clone of Tetris.

    Game 2. RPG: Authentication, Databases, Persistence

    Now try making a traditional dungeon-exploration game. Make a dungeon, throw in some dragons, leave a variety of lethal killing devices of great value lying around on the floor, or in unlocked chests. Drop a series of adventurers in at the top, and let them go wild!

    Building this game lets you focus on persistence, storing information between successive runs of the game so that individual players gradually increase their characters in the game over time, rather than restarting from the beginning every time they play.

    It's also the first game where real-time chat will be genuinely useful. Chat is simple to do, but it's worth learning early since it's such an important part of the player experience. You'll probably want to move to voice-chat later on, but text chat is good enough for now.

    You'll need a database, and you'll get practical experience crafting SQL queries, both to create and alter data, and to read it back out again.

    You will also need to take your first steps with authentication, that is, usernames and passwords, or else your players will have no way to ensure that they get their own persisted data -- not someone else's. For this kind of game, you only need to consider username, password, and email address, and you won't need to do any authorization. The difference is that authentication answers the question, "Who are you?" while authorization asks, "What are you allowed to do, now that I know who you are?"

    For bonus points, add in-game editing of level data -- such as items in the dungeon: What are they and where are they? -- and character data (player stats), using a multi-level authorization system ("standard" accounts, "editor" accounts, and an "administrator" account that can grant or revoke access to the editor authorization level).

    Integrate the text-chat with one or more popular instant-messaging networks by interfacing to its API to send and receive messages in-game with your friends who are out-of-game. Embed a link to the game download page in your outgoing messages and see if you can get anyone to jump into your game just by messaging them.


comments powered by Disqus