Matthew Bloom Senior Project

So as it turns out, it’s a lot harder than I thought to keep my motivation up to par when I’m not being graded on it anymore!

I keep trying to push myself to come back to this and continue the work, but what’s required of me right now is essentially a bunch of extremely monotonous transfer work that is difficult to drum up the motivation for. Furthermore, I also need to implement saving/loading, a functioning inventory and item pickups (probably using arrays of some kind), equipment, refining RPG combat because it’s super basic right now, and a ton more. The workload before me is daunting, to say the least. I also have plenty of other things going on; a trip in August, a summer job, and more. I do not want to drop this project; I promised myself I wouldn’t. I will see this through but it may take longer than expected.

Since my last entry, I have modified pause menu layout to accommodate for a future inventory or party menu, and added a descriptive text box in case the labeled options aren’t clear enough to people. In addition, an intro sequence and a legal disclaimer were introduced; finally, I added a new menu theme and a background track for the disclaimer and difficulty selection (the latter of which is not implemented yet).

With regard to said difficulty selection: I am thinking of using a global variable of some kind to check what the current difficulty is, and temporarily dumbing down the changes to just an Easy and Hard mode with a 0.5 and 1.5x damage multiplier, respectively.

This week was spent compiling information. Not a ton to report on, but I will provide links to the Google Doc for posterity.

https://docs.google.com/document/d/1LJgX0l7PHbQ_pBtFMzv6Qc4s2-BT2iljTyqvsvgxFG4/edit?usp=sharing

At this point in time, the semester has ended and this has officially gone from “senior project” back to “personal project.” However, I’ve already gotten into the habit of noting my progress here and it seems to be helping me stay honest with myself, so I see no reason not to continue doing so.

Most of this week was spent preparing for the end of the semester, but I spent what spare moments I had compiling information from the original game in preparation for porting it over. This mainly includes dialogue, which I was able to extract from the RPGMV file––which was the original botched solution to the problem which sparked this project in the first place. The irony has not escaped me. The tiles and events therein are completely unsalvageable, but luckily, the text seems to be intact. I just need to pull it from where I originally had it and compile it all, and then I can go about redistributing it to the new system.

In addition to that, after having seen MyHouse.wad and been utterly inspired by its use of non-Euclidean geometry to create a sense of dread without the need for screamer horror, I have decided on my next goal, which I hope to achieve by the end of the summer. In short, I hope to perfect non-Euclidean level layouts in GameMaker 2.0. Based on prior experience, it isn’t as difficult as it makes itself appear––I was even able to accomplish it in the original software of RPGMaker VX Ace, which is over 15 years old at this point. If that can accomplish it, I have no doubt that GameMaker can do the same. I even have a general idea of how to go about it, which I will apply and experiment with moving forward.

This week, the visual elements of the game were polished to a workable state. They are, of course, still placeholder elements; the final game will not look like this. However, for the purposes of the demo, they are acceptable in that they are representative enough of what is being conveyed. In the end, as per the advice of several close friends, I imported some stock sprites from RPGMaker VX Ace (ironically, the software I first began this project in all these years ago) to fill in some gaps in the overworld aesthetic. It has come to my attention that, no matter how well the game plays, no one will give it a passing glance if it doesn’t look presentable. Thus, I’ve chosen to take this path for now and introduce personalized graphics in the future when I can truly refine them.

In addition, more detailed win and loss screens were introduced, as well as a bit of extra code to reset variables when reaching the main menu. This has no effect on gameplay but is instead me being pragmatic; this way, I do not have to reset the game each time someone plays it.

The early half of this week was spent finishing the map adjustments that were started last week, as well as introducing a few tutorial elements interlaced into the gameplay. This way, instead of having to read the game’s About page before beginning, the controls can be learned organically.

The rest has been spent beginning to work on the art and sprites for the game. I do not expect to have the game’s finalized art direction locked down here, since as previously detailed, this is just a temporary visual aid––I do, however, hope to make something that generally conveys what the player is looking at. Amusingly, finding the inspiration and energy to do the art has been the hardest part of this entire project so far; perhaps that is why I chose to save it for last. Perhaps unfortunately, there is less to report on this week, since aside from the art, everything else that was necessary to make has already been made.

The final deadline is fast approaching, and it still doesn’t feel like I have been working on this for long enough. However, all things considered, I am satisfied enough with the work I have done––though not satisfied enough to rest on my laurels. I will keep working on this project well after I graduate. This project is, after all, going to be my magnum opus–my greatest work.

This week, I proliferated enemy types on the RPG side of things so that more than one type of encounter is possible. In addition, I reintroduced both boss events, and also added some dialogue before, during and after the fight. Specifically regarding the shooter version of the boss fight, I also adjusted the boss’s attack patterns to appear more intimidating and reduce “safe zones” where the player can’t be hit at all. I did this because the original ones were too predictable for my liking and I wanted to experiment with the bullet production code some more. I am currently satisfied with the results, but I reserve the right to double back and make more on-a-whim changes later.

Returning briefly to the topic of text boxes in combat, I also made it so that said text boxes can appear in RPG combat, and streamlined it into a specific check that I can use in later builds when there are more bosses. I should, in theory, also be able to run this code at the beginning of the turn (currently it only runs at the end), but I have no need for that right now. Said text boxes do not currently appear in the shooter game mode––my primary concern therein is the sudden appearance of text and relinquishment of control from the player would be jarring and throw the player off their rhythm. In addition to that, the issue of enemy shooting timers and bullet collision are also subjects of note.

Furthermore, I added code that prevents the player from fleeing while a boss is active, and also made it so that when the boss dies, it sends the game into a win state. 

In addition, the player can now use magic properly; to incentivize this, type effectiveness has been introduced. Certain enemies have certain weaknesses, resistances and immunities, and targeting them with the correct element will inflict additional damage. 

From here, all that is left to do for this build is to expand the overworld, and perhaps also introduce some tutorial elements so that players can learn the controls organically. After that, I can focus on aesthetics. I have begun doing this, and will continue to iterate upon it throughout the next week or so. Once that is finished, all that will be left is to update the game’s visual elements.

Notably: As it stands, the shooter side of the game is much more popular, which leads me to believe that I ought to introduce some more appealing elements to the RPG mode so that it can have its own draws as well.

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. 

Please note: Due to a family emergency, I was not able to get as much work done this week as I have in previous weeks, as I spent the latter half of the week at home mourning with my family.

This week, I got skills working…for the player, anyway. I am still working on it for the enemies. The SP cost and most other functions work as intended.

I also changed the button layout to a menu layout, in keeping with the rest of the game, and updated the battle menu to support cycling through spells and skills in a manner similar to the menu toggle for gameplay styles. When doing so, the name, cost and description of the skill will be displayed for the player’s benefit. Moreover, battle text is now set up––a text box displays what enemies have appeared, as well as what moves are being used, whether they hit or miss, how much damage was dealt, and if the target was defeated––among other things.

I am, however, currently dealing with a few small bugs on with regard to skills: namely, When targeting, the game can select enemies that aren’t there anymore. However, it will course-correct to an existing enemy regardless, so I am not in a hurry to fix this since it doesn’t deter gameplay and isn’t all that noticeable to begin with (it took me a few days to even realize it was happening).

In addition, something appears wrong with skill targeting. Death checks work fine for basic attacks, but not for skills––it crashes the game. I am working on resolving the issue.

Moving forward, I hope to flesh out the overworld a little bit while also modifying skills and enemies to be a bit more distinct.

This week, I added the capability for units to deal damage to each other in turn-based combat, as well as functions for winning or losing the battle. The manager uses the same general system as shooter combat regarding post-combat. That is to say, it checks whether or not any “Parent_Enemy” objects exist after a brief delay (which has been included to let them be spawned in without issue). Enemy AI is currently primitive, but hopefully I can refine it moving forward so that they actually make meaningful decisions in combat; as of now, it only does the basic attack.

Moreover, I modified enemy stats and action options to be universal across both turn-based and top-down gameplay; each instance pulls from the same stat block and move pool. This is accomplished in the same manner through which all player objects share the same stats: a single parent object with macros determining stats and move options. Bullet patterns will be hardcoded in shooter gameplay, so the latter only applies to turn-based combat.

I also developed a fix for a strange bug that prevented turns from progressing properly. From what I can gather, the turn cycle moved so quickly that it kept overwriting actions that units were in the middle of performing––multiple times, this had the result of units “forgetting they were dying” and continuing to fight with 0 HP, never leaving the turn order. My current solution to this is a timer that must run out before the turn-end events can process and which resets at the start of every “unit turn”. 120 in-game ticks is probably a little high, but it’s time enough for all the affected events to play out safely.

Finally, I devised a damage calculation formula which will eventually be used universally across both gameplay styles. It has not been implemented yet at this time, but for posterity, I have provided my pseudocode notes from this week and last week at the bottom of this entry. Please note that the implementation of this formula is NOT a top priority at this time; I have taken notes on it and hope to add it in if time permits, but for now, my goal remains to have the game in a playable state before I start going for extra style. As stated in class, it is for this very same reason that I am currently holding off on the visual elements like art. My modus operandi for this project is, has been, and will for the foreseeable future remain as follows: I would rather have an ugly game that works correctly than a pretty game that doesn’t do what I want it to.

This week, I introduced a separate room for RPG combat and made it so the binary option in the menu correctly determines which battle room the player is sent to. I also ensured that, post-combat, the player is sent to the correct location as usual. Furthermore, the player object now has consistently measured stats across all of its incarnations, and the player in the shooter sections no longer dies in one hit–instead, damage is calculated on contact with a bullet using the player’s defense stat against the attack stat of the entity that fired the bullet. A more robust and complicated damage formula may be introduced down the line, time permitting; however, this functions adequately for now, and I do not want to waste time perfecting something before I have made the rest of the game.

In addition, I added a basic battle phase system in preparation for the turn-based portion of the game, and a bubble sort algorithm that calculates battler speed to determine turn order. However, this system does not currently account for “speed ties”, or instances where two different entities have equal speed. On a slightly less fun note, a basic Game Over screen is now present and woven into all aspects of gameplay; additionally, a second battle track was added, because I imagine people will eventually get sick of hearing just one.

Bug Fixes:

• Fixed a bug where the first line of a text box doesn’t type out properly, instead spawning in fully typed.
• Fixed a bug where, in a top-down encounter, you can still use spells and abilities when the results screen is present (this should not be the case).