Development of the game should be on the server first, then a client will be able to plug into the server from there. This allows for much higher generation.

Things we should consider when designing the server:

• How much processing should be done on the server? Should the client take care of mundane things or the server. For example, lets say the player has a collision with another object, is it the client's responsibilities or the server? If you did this on the client, the user would get instant updates, but if he/she became out of sink with the server, other players in the game would not get notified straight away.
• We probably should create a networking class library for use throughout the game. If properly designed it could be used for both the Server and the Client. It would allow the server and the client to be easily ported between platforms.
• Along the same lines, we should probably allow players to upload new levels to the server, and make everyone sink up with the level after that, by having them download it. Probably should send everyone to a lobby, and wait for everyone to sink up with a timeout specified in a configuration file, where that player will be booted from the game.
• What do we send the information to the other clients in? Binary/Text? Binary would make the communications faster generally, but text has the advantage making it easier to debug at run time. Someone could just Telnet to a port, and from there proceed to test the game.
• AI Ships should probably be introduced into a game, when a player leaves or to balance the teams on smaller games. AI Ships will always have a advantage over other players, if most of the processing is done on the server side, then AI ships will get instant updates in regards to player locations. We'd have to make it so the AI was "dumb" enough to look a bit more human.
• The server will probably have to be restricted to NT based systems for the Win32 platform. Windows 95/98 etc had a poor socket implementation that only allowed a certain number of connections. 2000/XP would allow many more connections to the server, and with updated Win32 API (especially in threads etc) we could take care of some advantages here. Another feature we'd be able to take advantage on NT over 95/98 are enhanced services.
• Good class design will be almost essential here. If we create abstract classes we can use on any platform, then just initialise appropriate versions on various platforms then changing and swapping the code between platforms will be a piece of cake in reality(Well maybe not, but will make life easier)

The client will most likely be the more challenging of the three sections of the games.

Some issues that might be face in the design of the client will be:

• It will require a common API to be built for various functions, including graphics, sound and input and networking. Some libraries out there already allow users to many of these things, is it better to build something in house or to outsource to already created APIs?
  
• One of the problems with networked games, is that they have a tendency to get out of sync with other players and the servers. There may be "lag" between the player and the server, so players will not get the latest instructions from the server, until a delayed time. This causes problems, including when the player gets updated, other objects and players not being in the expected position, players destroying other players when in reality the other player wasn't even there. One way to take care of this, is to invoke a technique called "dead reckoning". This uses a variety of algorithms that guess based on other objects trajectory where they will end up being.
  
• We considered at one point integrating a Newtonian physics model into the game. This would apply a realistic physics model on what would actually happen in space. Players wouldn't be able to turn instantly, players could have the ships face the opposite direction to what they are travelling. Much like space scenes from the sci-fi show "Babylon 5". It was decided in the initial stages this would confuse many players and so we opted for a arcade style model instead, where the ship would be travelling in the direction the player was travelling, and have a consistent speed etc, rather then worrying about thrust and de-acceleration. Maybe include a slide button to allow players to temporarily look in the other direction.
  
• Turrets will have to be created on larger ships. Players should have a limited arc of firing based on the ships specs. This means that there will be a coordinate in model space, and then translate this to world space coordinates.
  Same question from server? How much processing on client and how much on server?
  
• Probably have some sort of mechanism to check for client updates on the web, nothing fancy, just taking the players there to download.
  

The tools initially will be developed for the Win32 platform only. This should ease some of the porting problems. Maybe class design should be an issue here in case in the future we ever want to port these to other platforms, but the specs for these products say specifically windows only.

These tools will need to be easy enough to use from the average player. So maybe not make it where players have to know about textures, but just keep things simple. Maybe have a separate texture and object creator for power users. Ship editor should probably be a simple drop down system, where players choose from various specs,