Priorities for the Dutch milestone

[WildWeazel]

Carthage is out, and so we are technically now in the Dutch milestone. The former kind of got away from us - we thought we were close 2 years ago, and the Godot 4 migration was not originally in scope - so I want to be more deliberate up front this time about what we're planning to do and how long it might take to get there. Plans can and will change, of course, but I would propose that we focus our planning on the following areas for Dutch:

Make the game run standalone with all necessary assets included whether placeholders, reused, or dedicated creations. By volume this will mostly consist of a terrain set, unit animations, and UI elements.
Why: This is not only essential in the long run to make the game more usable, but it greatly reduces the appearance of impropriety and risk of a DMCA or other legal complaint if it does not look like we literally copied from Civ3. Judging from the responses to Suede's video, many people are confused about what we're doing because of loading original files. Having our own content and running independently makes it clear that this is its own game with all "new" content.

Settle on a name along with an icon and official tagline/blurb for branding.
Why: Seems pretty self explanatory, but along with running standalone this will make us more memorable, discoverable, and distinct from Civ3 and C3X, with a clear identity and basis for advertising ourselves beyond the Civ3 community. The sooner we establish this the stronger our identity will be.

Use only custom assets in all public-facing screenshots/recordings going forward as soon as possible, unless we're specifically illustrating how to import from Civ3.
Why: Again, avoiding potential legal objections and misunderstandings. Also, to showcase all the cool stuff the community has made!

Decide on and document our policies for content attribution, handling of assets sourced from CFC, displaying third party licenses, contributor agreements, etc.
Why: These are logistical, ethical, and legal-ish positions that can cause a lot of trouble if they're not settled on before people start raising objections. It's best to have something in place even if it's not perfect.

Reorganize the project and repositories to follow a notional architecture with Godot/UI code, the game core, Civ3 interaction, and our own assets split out into their own repos with appropriate policies and controls.
Why The code is roughly partitioned into different C# projects, but everything is together in one place and not particularly well organized. Having these different parts in their own repos comes with technical and logistical advantages. This "Prototype" repo was intended to be just that, but like so many temporary measures it stuck around. Also, separation gives us an opportunity to purge things from public history and reduces the impact should anything later be the subject of a complaint.

Identify major Godot plugins and .NET packages that are candidates for integration
Why: Whether we integrate them now or not, these can inform some of the architectural decisions and potentially save us a lot of work from reinventing the wheel or going down the wrong path.

Settle on coding standards and formatting and clean up the source files with a quick pass through.
Why: Messy, inconsistent code slows everything down and makes it harder for newcomers to get started. The sooner we get things cleaned up and standardized, the less time we lose dealing with it.

Perform a brief code/design review making liberal use of TODO comments and new issues, especially where the logic is incomplete/imprecise, events could be used to interact with other code, or code could be converted to Godot scenes.
Why: The code is getting large and complex enough that it would benefit from a fresh look, especially when so much of it in the beginning was hacked together to get something on the screen. Similarly to code quality, the clarity of the design will help to reduce the friction of writing new code, and help root out bugs and problem areas.

Expand logging and error handling in the code and consider adding an error reporting mechanism
Why: We've already identified robustness and graceful failure as critical elements to improve on over Civ3. People will start to get frustrated if we're just as fragile. As the code/game becomes more complex, there will be more of a need to know what's happening and how to recover when things go wrong. It's a lot easier to do this as you go rather than work it in later, and again doing it well helps everything move along smoothly.

Build out unit & integration tests to be run in our GitHub pipelines
Why: Quality control to catch all of things that break as we make the changes above!

Add steps for code analysis and security audits to the pipelines
Why: Less crucial than tests, but these are more things that help to uncover issues early and improve quality as we grow the project, saving everyone time and trouble in the long run.

Identify code in the game core for component/event extraction and start to define the components and events to be used.
Why: This concept of loosely coupled components interacting primarily through events is the basis for the intended architecture and the flexibility and extensibility that it will provide for modding. Identifying these elements helps us to see where and how those interactions will work and how to refactor the code to use them. The more code and more features there are in the game core, the harder it will be to refactor. The sooner it's done, the easier it will be to build on going forward.

In short: doing a lot of both behind the scenes and production work to take this from an ad hoc tech demo to more of a real product. The common theme is investing time now to make it easier on ourselves moving forward. You'll notice there's really not much here about functionality. This is not to say we shouldn't or won't add features, but I think which features we tackle next should be secondary to maturing the project overall. (Not to mention, the active developers have already accomplished more than I could keep up with since the Carthage release!) Once we've accomplished the above, I'd be more comfortable promoting the game and open source project to a broader audience and giving contributors more leeway in scoping subsequent work.

[WildWeazel]

Any thoughts from @C7-Game/devs ?

[TomWerner]

Broadly these all seem like reasonable points, but I worry a little bit about momentum vs perfection. A perfectly tested, logged, and documented game that isn't playable is hard for people to get excited about. I've found that people tend to get more excited about features. To that end, making the game run standalone seems like a great goal, but I think it should be paired with making the experience of playing the game meaningful.

A couple of other thoughts:

Reorganize the project and repositories

I'm not sure I see a clear benefit here. Unciv has everything in one repo and that seems to be a fairly successful project. I frequently have PRs that touch the UI and the engine and the civ3 interaction, and having to deal with multiple repos would be a huge pain.

If the concern is more about art assets, maybe a temporary staging area (Google drive, Dropbox, etc) for people less familiar with git that gets ported over periodically.

Settle on coding standards and formatting

If we do this my vote is https://csharpier.com/, and we should add a GitHub actions that enforces this linting.

[esbudylin]

I really like the directions proposed in this document! I'm looking forward to the project getting a real name and a set of open-source assets!

However, I have doubts about reorganizing the project's repository. I don't see any clear advantages to splitting the codebase into separate repositories. Currently, pull requests often require changes across several projects. If the projects were split into multiple repositories, contributing to the game and reviewing changes would become significantly less convenient.

Even more importantly, I don't see purging the repository history as a desirable outcome of the code reorganization. I believe we should preserve our commit history, except in rare cases (such as mistakenly committing copyrighted material). In my opinion, the commit log contains valuable information about the code, and getting rid of it would be impractical.