31 lines
1.8 KiB
Markdown
31 lines
1.8 KiB
Markdown
### 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).
|
|
actual features of the game are in [README.md](README.md) |