Code review of Mermaid River

In the game Mermaid River the class called “Captain” is represented as the playable avatar in the game. An object pointer of captain is stored as a private member in a derived class called “GameState”. When the game state’s “Enter” function is executed, the captain gets a struct filled with pointers to different objects like draw manager, state manager, mouse, etc. But all of the instances weren’t used like the state manager. They could have send only the useful modules to captain instead.

The captain object is updated inside an if statement when game state is updated. But captain’s update function takes a copy of a harpoon object which is provided by game state by dereferencing a harpoon pointer. But this copy only serves a small purpose inside the function by telling its windup time to the captain. This copying could be avoided by only sending that necessary value to the captain directly. But if they need more data from harpoon, captain could instead take a const(for safety) reference. The harpoon class is pretty big and has a lot of variables that needs to be copied and less RAM is used when passing a reference through a parameter.

Very quick recap:

The player object aka Captain has a very loose coupling but it also has some unused instances lying around. The latter is not a big deal.

~Adrian Lavrell

Code review of Mermaid River

Lämna en kommentar