Martyn Patrick / Portfolio
KeepEmLivin
 |  |  |
|---|---|---|
 |  |  |
KeepEmLivin was made over 2 weeks, with the theme of heal in mind. Player's are the lone healer left in a small town attacked by demons. In order to defend themselves they can only heal the small band of knights around them.
You can play the game on the Itch.io page HERE
And the Github is available HERE. There is linked examples to specific bits of code throughout however.
The jam was ultimately my first so I'm really happy I got out something that is playable with a beginning and an end. Somewhat un-necessarily, all the systems are built with expansion in mind. The spell system in particular, is very customisable which each spell having its own logic derived from a parent class but unique from it. One spell might do nothing at the start and end of its casting but instead heal it's target every second another might do nothing until its finished casting for an increased effect.
Each spell is its own object which gets instantiated in the scene when the player begins casting it. And is removed when it's cast time runs out. Each spell handles its own clean up logic so it's possible that some spells could stick around longer in the scene, and then clean themselves up when it's own logic dictates.
Each enemy and ally is similarly polymorph-able, although admittedly it was closer to the jam's end that I finished those systems as such the code isn't as clean as I'd like it to be. There are some systems that handles things that could be given to another script to handle for code readability and reusability.
For example, the EnemyAI code handles the enemy's animation when really it could've been left to the "Enemy" class that handles the stats of said enemy. Ultimately, it would allow for more enemies to be created a little bit easier in the future. Likewise, the "Ally" class handles Animation, AI and stats of said ally. Seeing as they are similar entities (by way of they are units outside of the player's direct control and use of lot of the same functions) their code architecture should reflect this something I will be more careful of in the future.