steven-murray
commented
4 years ago OK, I think you can go back through it again. I've fixed up all the games to use the new mechanics. I also renamed mechanics to board so we now have board.py and sprites.py which I think makes more sense.
The sprite hierarchy is fine, because the game dev is supposed to overwrite the sprite classes (we give just two examples that they could appropriate). The sprite classes can do whatever logic they want on an encounter.
Here's our version of doing encounters better (i.e. with other sprites and the bounds of the board).
It makes encounters entirely general, so that the Sprite itself owns the ability to decide what to do when it encounters another sprite. This happens in (semi) real-time, so there are no ordering issues.
Sprites should be subclassed, and are able to define properties which can be accessed during the encounter to decide what should be done.
Eg. one property is
dead: if it is set, then the sprite will be removed following the encounter.