5SD023 Code Review of Team 9 Player(Giraffe) class
|
Code Review of 5SD023 Team 9’s player Class by Karl Malm (Team 8) This post will mainly detail the code of the Player (Giraffe) Class of Team 9’s space shooter project, found here: https://bitbucket.org/AdLaDCLXVI/gameprogramming2_wow General Project Status The code at the time of writing had an error which kept me from opening it without altering the project files, most likely a merge error introduced at 2016-03-02’s update. These can be found under the #include lists in the .vcxproj and .filter files. There are more merge conflicts in the EntityManager, FoG, GameState and Render classes that would keep the code from running. As for the Player (or Giraffe) class itself, there are some bits of code that currently do nothing. There’s a pointer to the class itself within the class, set as private, that is never used or passed onto anything or returned. The same pointer is created again in the EntityManager class where it fulfills a purpose of passing on argument information. Couplings and includes The Globals include with information I presume is for setting up the game’s window and determining distances need not be its own h file, accessed over and over by all the instances of not just the player but projectiles, pickups and the like. The game or menu state can be set up to hold a pointer to that same window information, and initialized in the main.cpp file (alternatively, as has been done in the FoG class) with any screen settings required, either with the sf::VideoMode::getDesktopMode or any settings of size you wish by using the basic VideoMode(width,height) function. When one needs position information to be passed on to either the player or any other entity, use the window pointer’s getSize function. The next issue seems to be in the Input class, which seems to generally handle input and its management. However, many of the functions within it can already be handled by SFML’s own Keyboard::isPressed or Mouse:isButtonPressed functions, and since the Input class requires information from classes like Extendedmath and the window class, this is an unneeded extra addition. To help uncouple the class further from the rest of the code, either recreate the Input class (sans homemade keyboard and mouse functions if desired) or handle input with a function under update in the game or menu states, then send information back via the Giraffe class’s update function. Creation of the power laser powerup also seems like it should be moved from the player itself, either to the entity manager, taking input information from the player as it is now, or creating a new manager and splitting up the (at the moment quite large) main manager into smaller pieces, handling projectiles, enemies, power ups. Then, all that is required is to obtain the player’s current position and angle and the projectile can be created on its own, as the code seems to intend. Beyond that, the only issue I can see would be using pragma once to avoid repeated use of includes, though the coders seem to also use ifndef to achieve similar results in some cases.  |
