Developer Mamba contacted us to audit “Play Stories”, a mobile interactive adventure game they had developed through another outsourcing company. The game had a lot of stability issues, with plenty of bugs and recurrent crashes, as well as poor client/server security because the app was frequently hacked. They wanted us to audit the source code, and our team delved deep to find out what was causing the crashes and slow downs. 

Working in Unity, we did a theoretical analysis based on cyclomatic complexity, depth of inheritance, class coupling analysis and maintainability index to check the complexity of the code, and from there, figure out why it was so complicated to stabilize the game. From there, we detected the components that had too high complexity, and we studied them more deeply.

Developer Mamba contacted us to audit “Play Stories”, a mobile interactive adventure game they had developed through another outsourcing company. The game had a lot of stability issues, with plenty of bugs and recurrent crashes, as well as poor client/server security because the app was frequently hacked. They wanted us to audit the source code, and our team delved deep to find out what was causing the crashes and slow downs. 

Working in Unity, we did a theoretical analysis based on cyclomatic complexity, depth of inheritance, class coupling analysis and maintainability index to check the complexity of the code, and from there, figure out why it was so complicated to stabilize the game. From there, we detected the components that had too high complexity, and we studied them more deeply.

The problematic classes had too many functionalities, too many lines of code. We suggested restructuring these classes to better compartmentalize their functionalities.

We also detected that there was too much boilerplate code, as the following:
● if (checkIfInputIsBlocked && inputIsBlocked) 
● if (statusWait) 
● if (buttonId == -1)
● switch (phrase.Options[buttonId].Restriction.Command)

Examples like this make it difficult for the programmers to follow the code execution order, especially because these kinds of variables constantly change during execution. Our recommendation there to our client was to rather use state machines (FSM or HFSM), which would allow linear execution and behavior encapsulation. And where parallel propagation of states was needed, we suggested they use Dispatcher with a priority queue in its place, as well as event dispatcher for handling button states. 

Those are only a few examples of the many recommendations we gave to our client from our audit. The client ended up so satisfied with our analysis and solutions that they hired us to audit their backend.