- To begin, I had no idea that a "Design Document" even existed, until rereading one of @Quintillus' posts - which, I humbly suggest, should, in and of itself, be a concern. Any such major announcements/decisions should warrant their own thread.
I agree. At this point, I don't fully remember how that was shared initially, but it probably was before the forum was set up. But going forward, one of the questions will be, "what constitutes a major decision?" We will likely make errors in the future as well, so calling out, "hey, that was important!" will help reinforce what
is a major decision.
- This entire "Future Development" forum is, essentially, a technical back-and-forth among devs. I think we should have two sub-fora, one for technical issues, and another for game play.
Definitely agree. WildWeazel recently discovered that GitHub discussions can allow public participation, so I'm wondering (not convinced) if it makes sense to have dev discussions primarily take place there, and this forum be largely for non-dev communication. But two sub-fora at CFC also makes a lot of sense to me. In the immediate term, I hope the [dev] tag helps a bit, but I'm not sure it will go far enough, especially if [dev] threads significantly outnumber non-[dev] threads.
- I am distressed to see that the GitHub "technical" documentation includes bullet points like, "Unit Movement" and "Combat." To me, this can (at best) imply possible limitations due to the architecture utilized; at worst, game play features have been explicitly put in place.
If you mean the lists at
https://github.com/C7-Game/Prototype/projects, it's a combination of formatting limitations (plain-text), and that all past Carthage are still high-level ideas based on WW's initial design document.
As I've been fleshing out the details (including based on feedback from the "What do we want in Carthage?" thread, although there was only a moderate amount of feedback there), I've been putting them into "Milestones" at
https://github.com/C7-Game/Prototype/milestones . Viewing the issues for each milestone should give a much better picture of what they include. I will see if I can link those on the project page while not making it unreadable.
That said, to some extent game play features
are being put in place. Not set in stone, but set in code that can later be modified. The combat that is in Babylon couldn't exist without that game play feature being added. There is a recognition that these aren't final, to that effect, about 20% of document issues have the "
refactor" tag, and a significant part of the 30% with the "
enhancement" tag improve on existing features as well, including some which make them more flexible.
- I'm likewise concerned about the evident confusion between crowdsourcing & open-sourcing. The former is a means of raising funds to develop a game (which I've already described in some detail) whereas the latter has opened up development tasks, without CFC community input.
The "raising funds" is interesting; in the first post you mentioned, "We plainly cannot offer monetary compensation", so I had been viewing this thread with an eye more towards Wikipedia-style crowdsourcing, where other motivators are the primary factors. Over the longer term, I am not wholly opposed to the possibility of having some sort of optional financial contribution, similar to what Godot has; that could cover longer-term project expenses (e.g. a mod hosting server), and allow more consistent contributions. But at this point, I'd like to be farther along the road to "game that people are playing" first.
It is evident that one of the challenges is how to make the collaboration more... collaborative? IMO, it's a good thing that development
has been opened up, as the project could have stalled indefinitely otherwise. But there definitely is a question of how to involve non-coding contributions when there is
so much left to do to have a playable game, let alone compatibilty with existing scenarios. We have 56 things left to do for Carthage (and likely a few more that we'll discover en route), and did about a dozen per month for Babylon. If anything the problem is too many ideas and features, so perhaps the most valuable contributions would not be the popular, "could we add this?" but, "what existing Civ3 features do you think would let us get to a minimal viable game?"
Another item that could help is figuring out the answer to, "what sort of community input is wanted, other than the ability to suggest new features?"
Perhaps relevant, we got about a 25% boost in users on Discord after Babylon (to 36 total), and have 13 comments on the Babylon release versus 3 on Aztec. We've also had one new developer contributor since the Babylon release, and another who has become much more active. I'm interpreting this as a sign that at least to some extent, our approach is working - with room for improvement, of course.
- I keep "banging the drum," not so much about APIs, per se, but about a common format - at this point, I can only hope (for example) that a "Unit," a "Tile," etc., and modelled, consistently, throughout. I suggested this approach twice: once, very early on, to utilize an OO-style Class Tree, both with inheritable Attributes to, e.g., making adding any additional Unit characteristics easy.
- I also suggested that pretty much every game action, and interaction, can be modelled as an Event: ({Starting Condition(s)} + {Event Type} + {Event Outcome Decision Logic} = Outcome.) This means that the same structure can be used for, e.g., Combat, as well as the types of "true Events" we'd like to see. Note that this type of model is already implicit in the game in Tile Transformations, from Volcano Eruptions to Pollution.
- Similarly, I've mentioned that I have a set of "Rules" devised which I believe can go a long way towards causing quasi-intelligent, and vastly improves.\, AI behavior (I tossed a simple one, back-and-forth with @Flintlock, but the Conditions being discussed were on the simplistic side (how to decide where an AI Civ should build its next City.)
I think Points 1-5 might help poor
@WildWeazel's concerns about, "Herding Cats:
" (
) Irrespective, I believe that a shared set of Structure between game play and tech dev issues MUST be devised - you know something along the lines of any sort of methodology whatsoever, which distinguishes between Functional (game play "Rules"/features) and technical development.
I believe we are generally working towards unit/tile/etc. modeling. Some of these
are carryovers from the Aztec prototype days. But I'll reference
UnitPrototype.cs as one example to reference. It is not done;
canFoundCity and
canBuildRoad shouldn't just be booleans. I believe you mean that they should essentially be a key-value map, so that it is easy to add additional values? "canFlyIntoSpace" could be added in a mod, if the mod were also willing to implement the mechanics of that attribute? On the plus side, the IProducible interface works towards that OO-style class tree; so far UnitPrototype is the only IProducible, but eventually that will include buildings and perhaps other items as well.
I'll defer to WildWeazel on the events, as I know that is one of his personal goals for Carthage.
Do you have a link for the rule example you mentioned? I think I saw it, but can't remember which thread it was in. I think this is an area of opportunity for collaboration and two-way communication.
) "Project Plan," not as in Major Corporate Nightmare Land, but rather as in, "What gets rolled out when, in which order - and, oh, are there any dependencies I should know about?
) methodology at all, just some agreed upon standards ...
) can be "reasonably" construed as confusing: "Unit Combat;" etc.
... Oh, @Takhisis 
)
For me, the "obvious" part has been to implement a new game which:
... But, I don't recall seeing that specifically stated anywhere - Perhaps it might belong in a Design Document and/or some yet to be started "C7 Manifesto" thread?
