Individual Assignment
|
Hello my name is Peter and this is a post assigned ONLY for programmers and not a part of my weekly blog posts, this is to aid in optimize and improve another groups code by “decouple” the code allowing it to be easier modified without having to tamper with several different areas of the code, this post is to Group no. 13. So starting off it took me a while to decipher your code (mostly because I’m a novice) due to your player is referred to as “OwlMom” and not as “Player”, for a tight knitted (small) group it’s perfectly fine however, if you were to expand members of your team it could be an issue, because all referred by name and not what they role they fill such as player, enemy etc.. What I noticed rather quickly is how there are some functions within SFML your group aren’t using and using more “back to basic c++” programming, I’m guessing it’s due to a senior programmer within the group, but that’s both good and bad but if SFML is the toolbox you’re utilizing I see very little reason too not use it, ( for keyboard for direction and more) but also when you’ve made an input manager when yet again something SFML “fixes” for you, clearing up your code. OwlMom seemingly being a sub class from IEntity and getting some pointers from there however, this leads me to beyond the player class where there are several entities that get rather useless pointers and functions (including player class OwlMom.), this could do with some optimization at least code structure wise. Going deeper into the two files of the hour is OwlMom.h and OwlMom.cpp , starting with OwlMom.h we see that you load from several classes as follows: Enrage – Seemingly, Enrage seems to have some animations within itself, which makes me wonder if it shouldn’t be within Animated sprite where it belongs, but mostly gives player ability to enrage(which is good that it’s separated mainly) InputManager – Which is given the extra mile being a bit pointless as SFML offers you this functionality in a easier form. Background – This one confused me the most of all, because it’s included to the player class, however it’s far as I could find serves no purpose at all for the player class. Animated Sprite – Here we got one that bothers me because it’s a separated class, for basic code for a animated sprite however, it doesn’t contain any of the animated sprites used within the code, personally I’d like too see that so you’ve got less Sprite animation clutter in the rest of the code. Utility – Random number generator, simple basic fun thing, however was it necessary it’s more of a game design decision, nice touch however. Projectile – Love that, the random number generator is what you use for projectile and both are just used for two lines of code in player class, overkill perhaps but nonetheless i love it. Collider/Sprite – For getting the actual Sprite and then giving it a collision box of size of the sprite width and height, nice and simple. and ofc Owlmom as a IEntity subclass but that’s already mentioned, however I want also to point out that you’ve got sounds included everywhere but in your SoundManager making for unnecessary lines of code cluttering where sounds are needed, this is all mostly code structure we’re talking about. The reoccurring trend I tend to notice is when code is where it shouldn’t be , simply put sounds aren’t in soundmanager, animations aren’t in Animated Sprite and Start up sequence for Owlmom isn’t in Owlmom if you did this slight improvement whenever you want to improve sound you just go to soundmanager and not some (obscure) location where it could be. One last thing I think maybe you should make a separate category for OwlMom’s Acceleration and Retardation having a “directionmanager” which takes in what you’ve presented there Speed, Acceleration, friction, direction of movement over time, it’s optional however it’s such a big chunk of code I think putting it in a separate category could Aid in your efforts to clean up the code you’ve got. However I don’t want to come of that negative as I’ve have been it’s mostly negative thing’s I’ve been mentioning but it’s because in nit picking trying to find something tiny to call out as a “obvious” problem, but what’s is obvious is that there isn’t much to complain about and that you’ve got a good structured code overall it’s just minor Move this into this folder, which is less then most groups I’d guess. You’ve got a good strong start and definetly got a good head wind now keep the good work up and best of luck to you Group no. 13  |