+ Added Armors

+ Added Weapons
+ Added REPORT.md
+ Finished the classes
+ (fix) Fixed problems caused by class hierarchy
- (todo) main loop, key mechanic.

REPORT.md

@@ -0,0 +1,30 @@
+### Headache : A critique of the project design (Optional to read)
+
+At first i thought this is just another simple assignment like the rest, however as i started working with it i stepped upon a tangled design.  
+the irony is the fact that TA team allowed changing the design structure indicating they knew the flaws.  
+
+#### Flaws :
+- First of all,
+there is literally no game available in the market in which the NPCs have Mana system. like what do you think a NPC does when it ran out of mana?  
+will it just stand there and look at you and wait for it destiny?
+
+
+- Second, 
+how player should have two attack styles (lightAttack and heavyAttack), if the Entity interface only provides one attack style?  
+to implement such mechanic you either have to implement two methods for two attack styles in Entity interface which doesn't make sense as Enemies should only have one attack style,  
+or you can just delete attack completely and implement it based on the entity instance.  
+The attack method situation was just an example, methods like "defend" ,"fillMana" and "getMaxMP" follow the same story. none of them is usable for Enemy class.  
+This whole situation and entanglement only defeats the purpose of class hierarchy which is code redundancy and code reusability. 
+
+
+- Third and the most important,
+the whole concept of a text-based RougeLike game just don't make sense, for the upcoming years  
+it would be much more logical to call it a "Card Game" as the follwing
+
+### The actual report
+
+i simply changed anything i complained about in first section (Nah you can't get away without reading that!)
+
+#### Just one more moment...
+
+i changed Entity from interface to abstract since i had problems with Player and Enemy sub-classes (idk if it was my language server issue or it was an actual problem).