This PR focuses on implementing a status system to the combat system. The first and largest change is that instead of using a string to represent the status of entities in combat, the status is represented as a tuple of size 2. Index 0 has the name of the status while index 1 has the turn count. a turn count of -1 means that it is an infinite status.
Information about statuses and their effects is stored in the Status.json file. The most important part of this information is the maxCount value for a given status. If a maxCount is not -1 (represents infinite statuses), the value represents the number of turns the status can be on an Entity before it is removed.
Because of the above changes, the hero object now has a new field called fieldStatus which does what the old Status variable used to do on the overworld in the Rpg2.py file. This way, I don't need to refactor much code and I can further separate the overworld and battle portions of the code. The final general change that was making functions that required the status string to look for the status string look at index 0 of the Status tuple.
Because of these changes and the implementation being for the battles, BattleManager received a variety of changes. The class gained a new attribute statusDict and 3 new functions, get_status_dict(), apply_status_effects() and handle_status(). The do_one_turn() function was also modified to take advantage of these changes. apply_effects() also received a minor change, now being able to apply effects to entity objects.
get_status_dict(): This function just parses and returns the dictionary contained in the Status.json file.
apply_status_effects(): This function takes in an entity object and returns a list of event strings. This function works similarly to the apply_effects() function and reuses much of the code. The main differences are the way it handles the effect strings and the effectStrings it creates which are added to a list which is returned by the function. The main change between how effect strings are handled is that apply_effects() assumes that the effect string -15% Hp means that you inflict 15% of the max Hp stat to the target.
apply_status_effects() will interpret the same string to mean inflict -15% of CURRENT Hp as damage. apply_status_effects() can handle effects based off of current and the cap stats but apply_effects() cannot. The two also do not handle the same types of effects. For example, apply_effects() can handle an effect string that tells it to apply a certain status effect to a target but apply_status_effects() cannot. The final difference is that apply_status_effects() will increase the "counter" for a status effect before it applies them.
handle_status(): This function takes in an Entity object and returns a list of event strings and calls on the apply_status_effects() function. Once the apply_status_effects() function is done, the function checks if the "counter" for the status has reached it's maximum value and if it has, it removes it, setting the status of the entity to Normal and adding another event string to the list that was received from apply_status_effects().
do_one_turn(): received some changes in order to implement these changes. The main change being that before looking at which type of object is being called with this function, it checks if the object can even make a move by looking at it's status. If the status is one that has the effect of making them lose their turn, it just effectively skips their turn. handle_status() is still called however in order to handle any other effects caused by the status even if their turn is effectively skipped. This has the consequence of having the same repetitive bit of code appear in all 3 situations (turn is skipped, player character's turn and enemy's turn). This is an acceptable consequence as it is better than having the player enter a target and a move only to lose their turn. As a result of handle_status() returning it's own list of event strings, all instances of returnable_strings now add the returned lists instead of being set to them.
apply_effects(): The function now is able to apply effects and also now has new event strings for when the player uses an item to cure a status effect, one where it succeeds and one where it fails.
As with all other changes, the tests for these changes have been written. Because of these changes, the save files were updated as well.
PR checklist
[x] All Pytests pass
[x] All changes are documented somewhere in the commit
[x] Rpg2.py is tested and works even with the changes
Pygame-RPG 18 Implementing Status System
This PR focuses on implementing a status system to the combat system. The first and largest change is that instead of using a string to represent the status of entities in combat, the status is represented as a tuple of size 2. Index 0 has the name of the status while index 1 has the turn count. a turn count of -1 means that it is an infinite status.
Information about statuses and their effects is stored in the
Status.jsonfile. The most important part of this information is the maxCount value for a given status. If a maxCount is not -1 (represents infinite statuses), the value represents the number of turns the status can be on an Entity before it is removed.Because of the above changes, the hero object now has a new field called
fieldStatuswhich does what the oldStatusvariable used to do on the overworld in theRpg2.pyfile. This way, I don't need to refactor much code and I can further separate the overworld and battle portions of the code. The final general change that was making functions that required the status string to look for the status string look at index 0 of the Status tuple.Because of these changes and the implementation being for the battles,
BattleManagerreceived a variety of changes. The class gained a new attributestatusDictand 3 new functions,get_status_dict(),apply_status_effects()andhandle_status(). Thedo_one_turn()function was also modified to take advantage of these changes.apply_effects()also received a minor change, now being able to apply effects to entity objects.get_status_dict(): This function just parses and returns the dictionary contained in theStatus.jsonfile.apply_status_effects(): This function takes in an entity object and returns a list of event strings. This function works similarly to theapply_effects()function and reuses much of the code. The main differences are the way it handles the effect strings and the effectStrings it creates which are added to a list which is returned by the function. The main change between how effect strings are handled is thatapply_effects()assumes that the effect string -15% Hp means that you inflict 15% of the max Hp stat to the target.apply_status_effects()will interpret the same string to mean inflict -15% of CURRENT Hp as damage.apply_status_effects()can handle effects based off of current and the cap stats butapply_effects()cannot. The two also do not handle the same types of effects. For example,apply_effects()can handle an effect string that tells it to apply a certain status effect to a target butapply_status_effects()cannot. The final difference is thatapply_status_effects()will increase the "counter" for a status effect before it applies them.handle_status(): This function takes in an Entity object and returns a list of event strings and calls on theapply_status_effects()function. Once theapply_status_effects()function is done, the function checks if the "counter" for the status has reached it's maximum value and if it has, it removes it, setting the status of the entity to Normal and adding another event string to the list that was received fromapply_status_effects().do_one_turn(): received some changes in order to implement these changes. The main change being that before looking at which type of object is being called with this function, it checks if the object can even make a move by looking at it's status. If the status is one that has the effect of making them lose their turn, it just effectively skips their turn.handle_status()is still called however in order to handle any other effects caused by the status even if their turn is effectively skipped. This has the consequence of having the same repetitive bit of code appear in all 3 situations (turn is skipped, player character's turn and enemy's turn). This is an acceptable consequence as it is better than having the player enter a target and a move only to lose their turn. As a result ofhandle_status()returning it's own list of event strings, all instances ofreturnable_stringsnow add the returned lists instead of being set to them.apply_effects(): The function now is able to apply effects and also now has new event strings for when the player uses an item to cure a status effect, one where it succeeds and one where it fails.As with all other changes, the tests for these changes have been written. Because of these changes, the save files were updated as well.
PR checklist