2025.03.08 - General Dev Meeting

[Chikinsupu]

2025.03.08 - General Dev Meeting

About

This meeting is about defining coding standards and how to proceed with the project. From project hierarchy, file names, target platforms to future tech and ideas.

Specifications

Type	Coder Meeting
Date	08. March 2025
Attendees (Speakers)	xezon, ArcticDolphin, GeneralCamo, OmniBlade, Tarnished Knight, USB, Lucas ‘m1cr0man’, Amazing Mr. X, Louis, stingray427, Nils ‘Chikinsupu’, lordkian, Nabeel, richardboegli, Fighter19, Agent, Yah-Nosh
Author	Nils ‘Chikinsupu’

Discussions

File locations, naming, casing

• Split Generals and Zero Hour into two distinct repositories.
  • Postponed. Waiting for 1.05 and keeping compatibility in the meantime.
• Reverse the split between the include and source folders.
  • EA splits headers into include and cpp files into source but only in the game engine itself not in the tools
  • Keep folders as they are to guarantee compatibility. Especially for 1.05 which gets released later
• Create additional subfolders rather than grouping a large number of files into a single folder.
  • Postponed. Waiting for 1.05 and keeping compatibility in the meantime.
• Standardize file names (which will also make it easier to adapt to Linux).
  • EA’s codebase is a mess and inconsistent
  • Pascal case is mostly used in the current codebase - Chikinsupu
  • Clang should be able to handle the formatting - GeneralCamo
  • Snake case seems to be generally preferred
    • A poll will be held
  • Postponed. Waiting for 1.05 and keeping compatibility in the meantime.
• Improve file hierarchy.
  • Postponed. Waiting for 1.05 and keeping compatibility in the meantime.

Code, building, ci/cd

• Code formatting (clang-format, ...?)
  • No conclusion
• Code commenting, documentation
  • Verbose comments when changing something in code including tag/label, author, timestamp and comment - xezon
  • Create YAML file for each change to document changes - xezon
    • Yes, it is maintenance overhead, but easier - xezon
    • Merge it with the Git Blame system - GeneralCamo
    • Perhaps there is a way to auto generate the YAML file when creating a PR - ArcticDolphin
  • Sometimes naïve solutions are sufficient, like a single guy just going through commits and writing a changelog - Tarnished Knight
  • No decision, needs more research
• Language standard (C++11, C++17, ...?)
  • Using way newer C++ versions can cause compatibility issues and not every compiler may have full support
  • We decided on C++20 as our language standard going forward (VS2022 branch)
    • VS6 branch has to stay on VC++98
• Code guidelines (ban goto, auto, lambda, ...?)
  • Ban goto, yes
  • We shouldn’t be too strict, in order to not discourage future contributors - Tarnished Knight
  • Trust code reviewers - GeneralCamo
  • Use googles guidelines - Louis
  • Don’t make it too long - ArcticDolphin
  • Curly brackets should be on a new line, “Allman style” - Chikinsupu
    • Perhaps allow K&R as well (first curly bracket at the end of line)
      • No other bs like spaces or tabs in front of brackets
• VS6, VS2022 branches, integration rules
  • Focus will be on VS2022 branch, VS6 will eventually fade away - xezon
  • VS6
    • Any changes that will break compatibility to 1.04/1.05 will be blocked
    • Needs to be developed with VC++98 in mind
    • Keep 32-bit support
    • No refactoring
  • VS2022
    • Do whatever
• Build system: CMake, meson, other?
  • CMake it is
• Automated CI builds, testing policy
  • Testing:
    • Manual testing
    • QA testers
  • Use GitHub Actions
  • Add GH actions to test if the projects build for the supported target platforms
  • Unit testing perhaps for algorithms?
  • Test with replays and test maps to check determinism
  • Explore more and have a meeting later on again

Tech, specs

• Target graphics back-end: Modern DirectX, OpenGL, Vulkan, WebGPU?
  • Wouldn’t use SDL for a full game, but it could probably handle it since the game is so old - Yah-Nosh
  • Let’s go with an abstracted approach, where every backend could theoretically be supported. Game sends abstracted rendering commands to the backend and the backend can be whatever - Yah-Nosh
  • Explore the abstraction layer proposed by Yah-Nosh
• 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
  • We don’t do mobile, someone else can do that
  • Support all windows versions microsoft supports themselves Win 10, 11?
  • Make it run on linux and macOS, that’s more important than win XP support
  • Let’s go with an abstracted approach, where the code doesn’t require windows. Meaning that modules shouldn’t have dependencies to windows. - Yah-Nosh

Contribution, guidelines, policies

• Contributor guidelines
  • Avoid using AI
  • Understand what you are doing
  • Focus on one thing
• Should there be a committee?
  • No, always consider community feedback - xezon
• Code review rules and requirements (reviewer count? complexity? mixing of refactors and changes)
  • Complexity: PRs should focus on one thing and one thing only. Don’t fix a bunch of issues and call it “fixed some bugs”
  • Introduce a maintainer council - GeneralCamo
    • Don’t merge your own PRs
      • Exception: Critical security flaw
      • Discuss this in more detail - xezon, GeneralCamo
    • Everyone on that council needs to be trusted to actually review the code not just give a thumbs up
    • Doesn’t have to be closed
    • Review from council should have more weight than reviews from some random users - ArcticDolphin
  • Introduce code owners - GeneralCamo
  • Maybe there should be regular group reviews, where multiple “experts” review PRs together - Tarnished Knight
  • Only Maintainers should have the power to dismiss other code reviews - GeneralCamo
  • Have X amount of approving reviews in Y hours to get merged - GeneralCamo
  • Nothing set in stone yet, but we can start setting it up in that direction - xezon
• 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?
  • No refactoring on VS6 branch
  • On VS2022: yes, but be diligent and be sure what you are doing and what the consequences are

Compatibility

• Keep compatibility with 1.04/1.05 for now, with the VS6 branch
  • Our first goal should be to get a version running that is identical to said versions and runs on its own
  • Later on we will have more meetings about features, bugfixes and co.
• The VS2022 branch can break compatibility right away
  • Drop 32-bit support, 64bit babyyy

Misc.

• Does the Renegade team have a tool in place to convert w3d files to plain text? - xezon
  • No - GeneralCamo