phosit

Every component could do anything. Because of that it is hard to paralelize the message-system; and it is hard for the compiler to make optimizations. Did i understand you correctly: you want one mutex per ComponentType? That would be useless because a recource might be mutated by multiple ComponentTypes. The function taking long is PostMessage. This function sends a message to all components which have subscribed to the messageType. Some subscribed components do nothing: RangeManager subscribes to PositionChanged but has to check if it "trackes" the entity (CCmpRangeManager.cpp L570). This could be changed to first ask all subscriped component if they realy are interested in the message (This could be done in paralell). And then sending the message to the interested components (in sequence). An other idea: At the moment most Components have a switch in the HandleMessage. If Messages were static types this switch would not be necesary. This aproach might interfere with JS.

A link to CppCoreGuidelines would indeed be usefull. Yes but why? Would you go for str::FromDouble? The misc part will not go in to CC. "use std::string were possible" would be to harsh.

Ref: https://trac.wildfiregames.com/wiki/Coding_Conventions#C auto This paragraph should be removed/shorted, because sometimes it does make the code more verbose by adding very little value, sometimes it is slower because of implicit conversion, and sometimes it is impossible lambda; structured binding and trailing return type. The CC should state instead: Use const auto& or auto&& in range based for loops and algo-lambda-parameter or write a comment why not. const int i = std::reduce(vec.begin(), vec.end(), [](const auto& l, const auto& r){return l + r;}); l and r is what i mean by algo-lambda-paramerer. algorithm There is already: But STL is an ambiguous term and this paragraph does not appreciate std::algorithms enought This general rule is not good. Because sometimes i have iterators or the body is an existingt function. In both situations it is bether to use std::for_each. I would also write a paragraph about avoid old stile for-loops because iterations could be bypassed from within the body: // avoid for (size_t i = 0; i != 9; ++i) { // The iterator can be mutated. This loop never ends. ++i; } // saver for (const size_t& i : std::ranges::iota(0, 9)) { ++i; // compile-error } Misc could we try to integrate the code from source/lib? Licence; brace style; string type. propably rewrite it in source/ps. Own string type is a bad solution to add more functionality: free functions do it as well.

I remember a ticket were they talked about distuinguish phase by backgroundcollor.

I don't know what this "man throwing a discus" is. I'm a noob i know I start a new game: If it is ordered by function i know it produces units and in is enabled on phase 2 or 3 (since it is disabled on phase 1) If it is ordered by phase i know only that it is enabled on phase 2 or 3 (since it is between a building of phase 2 and one of phase 3)