This week was primarily focused on universalizing the functions of both combat systems.

For one thing, a player’s stock of lives has been made relevant to RPG combat, as has EXP gain—though the latter hasn’t done anything of value yet, so I have repurposed it to be a currency to pay for a healer on the overworld. This way, the player can restore lost HP/MP/SP and Lives, whereas before they could not. In addition, the code for calculating damage and processing unit death now checks specifically for if the player unit has reached 0 HP before anything else, then (if so) runs a facsimile of the code used in the shooter section regarding respawning and lives. (On the subject of calculating damage, a small amount of variance has also been introduced to the formula. The damage value is multiplied by 0.5 and 1.5–both rounded to the nearest integer—then those minimum and maximum values are put into a range from which a random integer is selected. If the hit is a critical hit, it instead always takes the maximum value and doubles it.) Finally, I added a few basic sounds to RPG combat to improve game-to-player feedback. Currently they are not custom-made but instead taken from a folder of random sounds I’ve collected over the years, so I will probably swap them for original files later. For now, though, it’s nice to have something there that serves the needed purpose.

Conversely, a Flee function has been added to shooter combat, which previously lacked such a thing. Much like the way it works in the RPG game mode, it instantly ends the battle but deprives the player of any EXP, etc. that they may have gained from it. In the near future, I will disable this functionality in both systems when a required, scripted, or otherwise un-skippable encounter (such as a boss or tutorial battle) is in progress, so as to avoid unwanted sequence breaks. In addition to that, I have added MP and SP costs to skills in shooter combat, and thusly modified the UI to show all three relevant bars. In previous versions, these skills could be spammed with impunity, so by adding even a small cost, I can inherently force the player to consider when to use skills and when to just shoot and dodge.

In terms of universal changes to both systems: I have modified the player’s stats to use global variables for both base and current stats. The purpose of this is to allow for stats to be increased or otherwise modified through means such as (but not limited to) leveling up, equipping items, being afflicted by status conditions, using moves that increase or decrease certain stats, and so on. For the record, none of these examples are implemented at this time; I am simply sharing them now because I plan to add them sometime in the indeterminate future.

Notably, I was able to fix that ridiculous targeting error from last week. It seems that the issue lied with the global variables I was using to determine what the entity was targeting with: a regular attack or a skill. Previously they were two separate checks, but I have since made the skill-specific check a “sub-check” of sorts. That is to say, there is a check to see if the entity is targeting in general, and then a second check to determine whether they are targeting using a skill or not. This appears to have fixed the problem, and I can now freely expand on the library of skills and spells available. The logical next step from here is to produce the formula by which enemies select the moves they will use, as well as potentially some variant of an elemental weakness/resistance system if there is time. Introducing some way to check for a move’s secondary effects if any (e.g. a move with a chance to cause a status condition) is also on my agenda. I also hope to introduce a self-healing skill for the player, and have been trying to do so; however, making the targeting system target the allied team is proving to be (for lack of a better term) wonky, so this option is currently disabled and may remain as such if I cannot get it working in time.

With the skill system complete, the skeleton of the RPG battle system is complete, and therefore, the essential building blocks of the game are all here and accounted for. From here, I can focus comfortably on expanding on what I already have and producing a coherent user experience. However, I am still not sure how much I want to focus on aesthetics and art even now, since I still feel as if there is more I can do in the coding department. My current plan is to save the art for the last two weeks of the semester, then make a few basic tile-sets and sprites on my own time. They will not be perfect, but I can make peace with that as long as they convey what they need to convey––I can always swap it out for something of higher quality later.

With regard to user experience: I have had a few people play-test the current build of the game, and while the core gameplay appears sound (people seem to have a preference for the shooter style at the moment), there are certainly some issues that will need to be polished out. The biggest problem I have encountered so far is the tendency for enemies to get random critical hits and instantly reduce the player to 0 HP. It is unpredictable and that lends itself to a poor gameplay experience, especially since in the future, the game will primarily be spent with a single party member. Even the addition of lives does not remedy the feeling of being KO’d out of nowhere with nothing you can do about it. (On the bright side, in the process of learning this I was able to confirm multiple times over that the lives system is functioning correctly.) To this end, I am planning to either (A) introduce an entity-specific variable that determines their critical hit rate and set it to something nonexistent for all enemy units, or (B) simply only check for critical hits on the player’s turn. Either way, it should resolve the issue.

In addition, one player pointed out that the shooter gameplay’s player movement is stiffer than it ought to be, and voiced a preference for games with ample movement, citing “player expression”. I have taken this into account.