Now that we have the benefit of hindsight, and years of play, or editing/tweaking/hacking, what would we have done differently if we had coded OP2. Feel free to suggest ideas that weren't around, weren't feasible, or weren't big at the time OP2 was created.
You can try for the big grand picture, but really specific examples would be better. Let's see who has an eye for detail.
The network protocol! The client would never bind to an address, and addresses would never be stored inside packets. Only return addresses on the packets would be used. NAT would never have been an issues, and only the game hoster would need to worry about port forwarding.
There would be no hardcoded use of techIDs from the techtree files. All changes upon researching a tech would be done through tags/properties set in the tech file. Instead of making disaster warning depend on a hardcoded techID within the exe, the tech file would have a property along the lines of INCREASED_DISASTER_WARN <disasterType>. Techs that allow units or structures to be built would have something like ALLOW_UNIT <unitName>. There would also be an increased number of tags so more properties could be edited. Maybe even take things to the extreme and define all unit properties within the tech file, thus removing the need for the vehicle.txt file.
Levels would be able to redefine all game rules more easily. As in being able to replace any of the .txt files, not just the tech tree.
Map files could be self contained. The basic unit setup could be defined within the map files eliminating the need for a DLL to do it. There would also be support for basic trigger handling stored in the map file in some sort of data structure (or scripting language, but probably just a simple data structure). The map file would also contain all the settings it needed for the different game types (LOS/SR/Midas/Etc.). This would eliminate the need for DLLs and thus make map files self contained. Allowing a DLL, particularly for advanced scipting would be nice, but DLLs wouldn't be required, and certainly no more than one DLL should be needed to handle advanced scripting for all game types on that map.
The tile group info would be moved from the map files to the tileset files, where it would make a lot more sense to store it. There would be an increased amount of meta data describing the tilesets. This would be especially true for the terrain transitions and would include change directionality and border offset. Cell type info would also be placed into the tile set files. There would be a simple one to one onto correspondence between tiles and cell types.
Compressed audio would be nice.
There would be increased meta data describing the animations and graphics in the art file. The data in the .prt and the .art file would be merged into one file.
The radio button selection would be fixed.
More functions useful for building an AI would be exported. An attempt at a basic AI that could be placed into any level would be made. This would be done in a DLL in such a way that allows for easy upgrades to the AI, or available AIs to choose from.
Checksums would depend on actual data, not the compressed format of data.
Game recording would be built in.
Convecs would not be able to move away when they start construction. Maybe allow multiple convecs to work on the same structure.
Certain map file format limits would be eased. If the cell types were stored in the tileset files in such a nice association as mentioned above, then those bits would no longer be needed in the map files and could be used for something else. This would make it easy to extend the number of tiles a map could use. (Current limit is 2048 tiles).
The lava possible bits in the map files would actually be used, rather than set in the DLLs like is currently done. Maybe add support for defining different flows, perhaps based on difficulty, or maybe just random.
Change the unit system so tile's don't need to reference units. This would make it easy to increase the max unit limit. Instead, use an alternate data structure to keep track of unit locations and quickly finding all the units in a given area. (Such as when drawing the units currently visible on screen).
Add some sort of unit death and/or capture event or callback. This would help AIs keep track of units, or make for an easy way of keeping track of the number of active buildings of a given type. This would be more efficient than rescanning all units every so often.
