Today, I was surffing the web and saw a very interesting story about the players suspected the Drogon Ball game maker cheat on the game here and here

Dragon Ball finally release their code to explain the reason, which is really HACKER way. I like it. In now days, as a player, you need not only the crack skills as before, but also some basic code skills. :-)

About the problem:

In the game application " Dragon Ball Z Dokkan Battle " there was a typographical mistake in some gacha and the influence "There might have been a character that does not appear for each user (whether there was a wrong setting)" According to the problem being said, the management side explained “by mistake of notation”. However, the source code has been released this time whether the riot did not fit.

Some points were here:

• Dragon Ball partly use C++ 11 as their back-end system.
• Dragon Ball use cache system to cache the CardId for players.
• If cache was missed, then the function will lookup the data in back-end Sqlite.
• The return value result will RVO(Return Value Opti) by the compiler, so no copy will happened between caller and callee.

The problem caused by the Sql query and following handling branch.

Beside the logical error, some improvements could be:

• Line 3 and Line 4 can be optimized in one line during constructor, it will be better if

vector<CardDataPtr> result(masterCardIds.size());

• All the self-incremental operation can be optimized by “++i” instead of “i++”.

• I am thinking the number of players will be dynamic changed, f.g. in the weekend or the evening, the player will be more than normal, assume cache system use LRU to do update, if the cache was not quite config well, f.g. the size was config with a relative small value comparing with number of players, it means this function will mostly lookup the value to the sqlite, Sqlite will be busy during this time, in some worse-case scenario, it will dramaticlly decrease the performance of the system.

  So, the cache system should know about this, increase the capacity to cache more data than normal, it means it was needed to emit a performance counter data to the monitor system between the block 1 and block 2 in the picture to tell how frequency of Query request for CardData, later system tuning will be considered if some system bottleneck was happened.

Finally, I like the working way of Dragon Ball exposing the problem. It is cool.