In fact, after reviewing Magus and Neumann posts, I think the f(N) bonus should be removed, and the formula may be like Neumann proposes:
According to sample size calculators, for a margin of error of 5%, confidence 95% and population 780k, the minimum recommended sample size is 384 (see Sample Size Calculator). 500 samples will reduce the margin of error to 4.38%. It's a round number (better than 384) that gives enough confidence, and it doesn't need to be changed on the future (385 is the limit when population tends to infinite).
This removes the problem of really low played games, and simplify the calculation (as it will not be based on external variables).
The f(N) bonus isn't useful and make the formula overly complicated.
Mean points of least and most played Multi:
(1000+5000)/2=3000 at this time
No, I think it should be something between 24% and 33%, but I'm biased.. Contests show some skills of players (deadline and stress management, coding speed, short term objetives...), and Multis reflect other skills (long term objectives, code optimization, perseverance, constancy). With enough luck, Contests are 3 weeks of work, while Multis are at least 16 weeks of work (and increasing).
Percentage ratio should be defined by Codingame Staff, according to the relevance they want to put to Challenges (or just a poll).
Ratio related to multis? Probably yes.There aren't that many Optimization puzzles to be that relevant.
If you make
Base_Challenge related to
Base_Multi it will change too, a lot. It could be confusing, yes.
There is the option to make Base_Challenge constant, and assume there will be a drift in the future, maybe it will be noticeable in 4+ years.
Understood, and I prefer that the formula is agreed by the most people possible. The problem with the previous one is that there wasn't enough unit tests for all extreme cases, where its flaws are noticeable. The new one must be tested with extreme cases (low playercount, extreme high player count, a lot of new multis coming in, etc etc) and check that is stable enough.
About points, to avoid excessive complains there is the option to create "inflation" on the CG Points. Like in economics, the best way to reduce money value without people getting furious is via inflation. If the most played multi has Base_Multi == 5000 then set it to 5000 for all multis. Then, if Codingame Staff decides that Challenges must be 40% of the Multi Score, then Base_Challenge = 15 Multis*5000 Base_Multi * 40% /3 challenges = 10000 points. This is similar to Magus proposal, just 2x the points. Maybe these points increase are even more confusing, I can't know, but people react better to point increases.
P.S: Why we need to manually calculate CG Points? It's a nonsense, prone to errors.
The profile page should give a CG Point breakdown. I have a page with complete XP details, but I don't have CG Point details, There are some graphics but without any way to see how it's calculated.