<strike>//written on a phone, so know what to expect formatting-wise, guys</strike>
Got home to my pc, updated the post to make more sense, rephrased a couple of sentences.
I'm glad you asked, since there are quite a few things i'd change about this project of yours, if i were in your place, unless i wanted for it to fail at meeting my expectations.
Now, you should keep in mind that i am just some grumpy guy from the internet and that my advice isn't flawless, but i've had some experience with C2 and would like to warn you about bad design choices or just general hardware limitations that are present in current-day technology. Of course, you might perceive me to be too critical at times, but just read until the end of the post, as some of these suggestions are bound to come in handy sometime.
Performance & Compatibility.
This is the biggest problem that i noticed in your project, judging by the description. I understand that developers these days want to make games with the best graphical quality possible, and that's okay, but by doing this you basically remove a large portion of your potential playerbase, for example laptop users and people with gpu's that don't support WebGL acceleration. Of course, this isn't my decision, but i can guarantee that performance will be a problem if you keep those high resolution images, especially since some graphics cards only support sizes up to 2048x2048 (IIRC). What i would do is cut the background image up in fragments close in width to the screen width and make a scrolling background out of multiple such images, so that there wouldn't be more than 2 screen sized images rendered at any time. I'd likely also consider creating them at a lower resolution and then rescaling them to full size, as this is likely to save you quite a bit of space in download size. I would also look for ways to further optimize the performance and decrease the download size, such as using a solid colored layout background instead of a background image and putting objects on top of it, or at least give the option to do so to users, or using point sampling and making art in n (n mod 2 = 0) times lower resolution, then rescaling it, as this would prevent image distortion. Also, i'd suggest that you don't go over the top with the WebGL shaders, as they can be a big performance hit. Lastly, there is simply no possibility that you need collision detection of such fidelity, even C2 developers don't recommend more than 8-10 points for an object. There's no reason why a game that aims to have good graphical fidelity can't use at least some of these tricks to help it run better. Oh, and you also might want to allow users to switch between different presets for maximum particle amounts and thimgs such as decals, and also offer your game with both renderers (high and low quality). Also, since i can't stop ranting about this, sound can also be a performance hog, so be sure to implement running without it.
Platform choice.
This one also bugs me, as making the game available only as a downloadable .exe is likely to decrease the playerbase greatly. If i were you, i'd look forward to putting the game on sites like Newgrounds, Kongregate or others like it, and also advertising it on indie game sites, such as Pixel Prospector, and hosting it on its own website (for free hosting, see 000webhost, they're pretty decent, IMO). However, if you desire to stick to your current plan of distributing the game only on desktop platforms (or Windows, more specifically), you could try to do the project with Construct Classic, the DirectX 9 game maker and the predecessor to C2. Obviously, i realize that you won't switch half-way through the development cycle, i'd just like to point out, for future reference, that the renderer CC uses is still a lot more efficient than what C2 has and therefore bigger projects will have better performance, except that many people often have problems with editing them (its editor wasn't coded as good as C2 is, so there's a couple of memory leaks, which might cause problems down the road). Either way, i'd at least consider other methods of deployment.
Description & Story.
As i said previously, IMHO the description sounds a bit too enthusiastic if we compare it to the current screenshots and the progress made. Gamers like humble developers, not the ones who rush ahead of time and make bold claims (not saying that it isn't/won't be a promising game, just that it's not there yet). Furthermore, the story seems a bit generic to me. Why not mix it up a bit, make it seem more logical? For example, make the German project a new type of power plant, which was attacked by a group of radicals, which lead to its detonation and contamination of the environment with a variety of substances, which caused rapid climate change. This, in turn, lead to insufficient food production and possibly an increase in disease, so riots broke out, soon countries plunged into chaos, with some militaries becoming separated from state and private military corporations along with local militia forces were on the raise, as the crime rates skyrocketed. Some countries saw the uncertain future as a possibility to secure more resources and invaded others and hundreds of years of diplomatic progress quickly became irrelevant. Or something. Story as the one given in the example (one that explains the setting and the history behind it a bit more) would make the events seem more logical, as otherwise it makes no sense for Russia to be fighting Germany. Of course, this is just a tip, i have no idea how far you guys are with this project, it's just that the description isn't all that descriptive. Also, a couple of grammatical errors should be fixed.
Development goals.
Now, i don't know how far you are along with the project, but i'd like to give you the following quote: "When you are writing the GDD, you are not making a game. When you are creating art, you are not making a game. Even when you are working on the sound effects and music, you are not making a game. Why? Because at the end of these activities you don't have a functioning game." Well, i'm paraphrasing, but you get the idea. It's the result that counts and to achieve it you need to actually create something that's playable. Because of this, you should put gameplay mechanics in front of the content generation and refine those first, before making more maps, units etc. I am just saying this because otherwise frustration will set in quicker, e.g. if you try to make 10 unit types in a row without working on something else. If this is your first project, i'd recommend this approach, and i would even suggest that you save the more advanced features, such as the multiplayer, for later.
Multiplayer.
In regards to this, i'd recommend that you use something like PeerJS, unless you or your buddy know how to write a server (which would then also have to be distributed with the game). Also, a server browser is likely to take some time to be developed. As for the netcode, seeing the current state of C2 development in this regard (not working all that well for real-time games), i'd suggest that you only give commands to the a.i. (these would be sent over network), letting the movements and position updates to be done locally, and synchronise positions between the games only occasionally (except for things like unit states, e.g. which is dead, which is alive and so on).
Another thing that i'd recommend outside of these categories, is saving the game as a .caproj (Project), as this saves time when opening and saving the project, thus allows you to work more efficiently.
Lastly, if the download is this big, you really should consider making a detailed loader layout, which shows the estimated loading time and data left etc.
If you require any assistance with any of the points above (except for servers), i'm willing to help you in exchange for absolutely nothing (as i'm just curious to see the source). I'd like to join a development team of some sort one of these days, so i have a place where i can be grumpy and collaborate towards something at the same time. :3
Of course, i won't rush ahead of time... Good luck with your project.