A few comments from a *very* new player (downloaded and played my first game yesterday).
As I understand it, this game is very much in an alpha state. We may enjoy the games that we play, but some of the responsibilities that we have as players are to report bugs as we find them, suggest improvements, or - if we have the skills - participate in the coding process.
I haven't written any code for 20 years, but somewhat more recently (maybe 10 years ago -LOL) I tested software. I was pretty good at finding bugs but my biggest problem was testing software for what it was supposed to do - because many times I didn't know or understand what it was supposed to do.
Documentation goes hand in hand with software development and the initial run through must be done either by the person spec'ing the code, or the person writing the code. In my time, I found a lot of coders who didn't want to "waste" their time documenting when they could be coding, but it bit us in the ass if they didn't.
Here are a few suggestions:
1) The design team should put together a manual in the wiki. (The existing manual page is NOT a manual, it is a hotkey cheat sheet). This manual should be outlined by people with technical writing skills, preferably people who have played a lot of 4X games.
The design team does not need to write the whole manual - they just need to create the skeleton which coders and players can flesh out. What is the concept for how the game is supposed to work? What features have been implemented? What features are being worked on? What placeholders have been installed for other features later? The bottom line for me as an IT manager or a software tester was, "if it is in the code, it has got to be in the documentation".
It isn't necessary to talk about possible future features unless a player will be confused by something that they experience in the game; i.e. "this building does nothing yet, it is a placeholder"
2) The manual should include a basic "strategy guide" chapter. What should a player focus on when first starting a game? How can the player maximise growth? production? expansion? What defensive preparations need to be made?
This "strategy guide" is more than just an intro for new players, it is a play test guide. If I do this, does that really happen? What if I do something else instead? That seems really cumbersome, what if we changed the way Process X was implented so that it worked this way instead?
The "strategy guide" will go through many iterations during alpha. It is the visible embodiment of the mechanics of the game. Every time the code changes, strategy will change in some way - The Butterfly effect. And given that there are two modes of play - single player vs. AI and multiplayer - there needs to be two sections in the strategy guide.
3) Every item that can be built and every "tech" that can be researched should have a comment section that clearly states what impact that item has on the game. "This allows the player to create XYZ"; "This gives the player a +n bonus to ABC"; "This is a placeholder for a feature to be added later".
Some items and techs have comments like these, many don't. The comments should be uniform (all at the top, all at the bottom, all in yellow text, etc). They may be modified or completely removed when the software goes beta, but they are critical to testing and development. "I spent 80 turns researching Tech PDQ - did it have an effect? Did it have the effect that the design team intended?"
I like what I've seen so far and I hope that I will be able to contribute to the development in some way. Once I've finished my first game, of course.