Project Breakdown

this is the only section of code that directly access data from the disk. it also handles saving of preferences and player data. sound and graphic resources can be loaded into separate 'bundle' containers. bundles will be loaded and destroyed as a group. should be able to 'incrementally' load resouce files so game can remain interactive while loading happens.

responsible for handling network communication. there will be work on the client and server side of the fence. Data traffic will be fairly light, and tcp will be used unless latency becomes too large a factor. Networking code in the clients must be able to sense when things have gotten too far lagged and interrupt the game to allow for things to get resyncronized.

separate executable that lives on a fixed server. doesn't do much logic except show which users are connected. can pass simple chat text between connected clients. needs a separate client module that can simply connect and access the data. There is no need for it to depend on the network core built for the game, but it may want to.

this is the map and tile data. these are static datafiles that do not do anything. separate tools will be needed to precompute information into the map.

generally dealing with map navigation and interaction. determine line of sight calculations, unit damage, pathfinding, etc. this contains the tile and map classes. It is generally used by the server, but the client will require use of it to compute map and fog-of-war rendering.

all game classes are a part of this core (aside from map and tiles). runs at a set framerate. runs as a separate process on one of the players machines. still speaks through network interface to both players. unit ai is here as well, belonging to the unit class.

this is a separate team for developing the graphics for the game. there will be many to do, and this is a large job to tackle. we will likely stick to low detail and low color to keep as many people as possible available to help this team. this will include designing the menus and setup screens.

this code will consist of the classes used by the render engine. these will mainly be one of still or animated images. it will enhance the standard resource bundles by offering graphics in different color sets or with alternate effects. classes will also be needed to handle ui elements like cursors and buttons.

this will handle setting all graphic modes and drawing to the screen. it will be designed as if there could be multiple render backends, even though that is not being done for this game. it will handle optimizing all final images into a format for the render engine. simple renderers must be included to handle the setup screens.

this is both the sound code and sound resources rolled together. the amount of code needed to manage sound effects should be minimal. sound bundles will build on regular resource bundles by offering sounds at different sample rates. the sound team will be responsible for 'recruiting' people to create the needed voice recordings.

this will handle all user input and client initialization. client classes for game objects will be simply shells of data that don't do anything on their own. unit data is received from the server and passed to rendering and input handling. logic for menu and setup screens are handled by separate game state classes. this part of the game has the most code inside that can be broken into separate parts.