Advantages and Disadvantages of Forking the EA Repository

[DevGeniusCode]

Why is it better to fork the EA repository?

• Forking the original repository will make it easier to manage changes across multiple forks of the EA repository.
• All our repositories will show in the EA repository network graph: https://github.com/electronicarts/CnC_Generals_Zero_Hour/network.

Why is it good to create a new separate repository?

• To split Generals and Zero Hour into two distinct repositories.
• To reverse the split between the include and source folders.
• To create additional subfolders rather than grouping a large number of files into a single folder.
• To standardize file names (which will also make it easier to adapt to Linux).
• To improve file hierarchy.
• To improve code formatting.

Till now, there only less than 20 active forks from EA repository.

[augustresende]

The main advantage of being a fork is that it is easier to receive people who see what is active through the insights and forks tab. In the future, it is possible that this repository will become just the aggregate of all the bases with something like git submodules.

But I really don't see much need to separate the main game code (Generals and Zero Hour) into two repositories.

[ViTeXFTW]

I agree, it should be for ease of readability. With a GitHub pipeline/action and clang formatter, we can ensure that the repo is formatted according to these rules.

[xezon]

I'm personally in favour of normalising the file naming to lower case for the code to make it easier to keep casing correct between file system and includes for case sensitive platforms.

The problem with all lower case names is that these are more daunting to read, especially for non native English readers who may have it more difficult to decipher the names. Additionally, if applied to release files, we would ship lower case files, so WorldBuilder.exe would become worldbuilder.exe. This is untypical for Generals, because all user facing game files use CamelCase naming. In principle I think it is our first choice to keep the CamelCase naming convention from EA as the foundation and simply make sure all the casing is correctly written.

We could write a python script that finds and auto corrects mistakes.

[tintinhamans]

Another option maybe is to add underscores e.g.world_builder to help with readability but i guess that is a more extensive change.

But yea, a script also sounds like a decent option.

[hossein-lap]

In general, I think using LSPs would be a better and safer option [1] in case of renaming variables and other names. I think I (or anybody else) can write an automated script to achieve this goal.

[1]: As you all may know, LSPs will (kind of) parse the source code and analyze them, thus they'll have a (better) understanding of the code. But I'm not sure how clangd will be good at it btw.

[itshallrun]

@xezon
Are you familiar with commit hooks? They can check or format code according to predefined rules when you perform a commit.

LeftHook is a popular tool for this purpose. It allows you to set up pre-commit hooks that are executed when you commit your code.

Now, we just need to find a good package that performs formatting on c++ and set up rules for how the code should be formatted.

[xezon]

There is also an option where we do not leave the network graph, by keeping the forked status, not split Generals And Zero Hour, but do the other fundamental file changes.

[xezon]

Also we probably want to check if any of the original files end with CRLF instead LF and correct that. We perhaps also want a .gitattributes that explicitly marks them as text files with LF so that no one tries to push CRLF files.

[xezon]

I suggest we make a meeting with programmers and make a decision. I have asked Community Outpost leadership to organize that.

[xezon]

Not that I am aware of. Perhaps we need to organize ourselves.

I would like to have OmniBlade in the meeting, but he already noted his recommendation in a message:

OmniBlade:

In regards to repo management, I'm personally in favour of normalising the file naming to lower case for the code to make it easier to keep casing correct between file system and includes for case sensitive platforms. I'd also like to put in place consistent formatting rules enforced via clang-format or similar though version bumps can cause some reformatting issues and it will be a big diff if the format we choose is very different to the current formatting. I'd also like to enforce linear history on the main branch to make following the history easier.

[xezon]

Drewminator:

in regarding of code formatting, please keep the current format it is very pleasant to work with, easy to read and clean

OmniBlade:

Current formatting is inconsistent between files though and isn't automated for lint checking purposes. We can try and keep the format as close as possible with automated tooling though.

[xezon]

In regards to coder meeting, I checked with OmniBlade and he has limited time so we are aiming for 21:00 GMT on Saturday 08.03.2025 in Community Outpost Discord.

Topics from the top of my head:

• File locations, naming, casing
• Code formatting (clang-format, ...?)
• Code commenting, documentation
• Language standard (C++11, C++17, ...?)
• Code guidelines (ban goto, auto, lambda, ...?)
• Code review rules and requirements (reviewer count? complexity? mixing of refactors and changes)
• VS6, VS2022 branches, integration rules

[xezon]

Additional topics proposed by Louis:

• Target platforms and eventual cross-platform support: Windows version range? Linux, Mac? Mobile? Web? Narrowing down a list would help making relevant choices for other topics
• Build system: CMake, meson, other?
• Automated CI builds, testing policy
• Contributor guidelines
• Policy regarding refactoring old code: should you accept contributions "modernizing" old code without added * features or bugfixes, at the risk of breaking old code unknowingly?
• Target graphics back-end: Modern DirectX, OpenGL, Vulkan, WebGPU?

[martixy]

I just saw the programmer meeting on xezon's youtube.

• Code guidelines (ban goto, auto, lambda, ...?)

Upon this point in the discussion, there are some points I think need to be considered.

You should very carefully consider the nature of this project and who you expect to develop this code now, and into the future. As a community project, OSS project, how friendly do you want to be to new programmers? What do you do when people exit the project? How much tribal knowledge do you intend to tolerate? How do you intend to pass that along as people move in and out?

For example, every language accumulates a ton of cruft and syntactic sugar over its lifetime. This is true for C++ as well. A veteran dev might be used to fancy language features, but if you wish to be friendly to a dev coming from a different language or environment, asking them to wrap their heads around all those new features before being able to contribute will create extra friction. And in a project where (probably) nobody is getting paid, what is the amount of friction it can tolerate before it withers?

Basically, my point is, adapt any guidelines to the developers you wish to attract to the project.

• Target platforms and eventual cross-platform support: Windows version range? Linux, Mac? Mobile? Web? Narrowing down a list would help making relevant choices for other topics

1. Mobile: Not an question of technical ability, but of design. Mobile presents enormous challenges implementing a different control scheme.
2. Yah-Nosh on abstraction: Good advice. Tim Cain, creator of Fallout talks about this approach on his own Youtube channel.

[hossein-lap]

Also I suggest creating a github organization if we're going to have helpers and wrappers scripts. Plus using the Project feature of github, which gives a planning table. It would benefit us to organize works and topics that are needed to be done.

[tintinhamans]

TheSuperHackers is already a GitHub org, and I believe @RedvsBlue87 is cooking up something in GitHub projects.

[xezon]

I wonder, should we perhaps consolidate file name casings if they are different between header and cpp?

For example there is this:

rawfile.cpp
RAWFILE.H

This is quite a bit unholy.

[DevGeniusCode]

An additional advantage of a new repository is the ability to consolidate shared folders between the two types of games: Generals and Zero Hour. For example, the GameNetwork folder contains code with only small differences between the two, and by using #ifdef(ZH), we can clearly separate them.

This approach will allow us to manage bug fixes and code upgrades more effectively, without duplicating code in both parts, simplifying the process.

(If the decision is made to keep both games in the same repository.)