Matthew Bloom Senior Project

This week, I added functionality for text boxes and random encounters, and made the bullet hell fights into multiple separate encounters as opposed to a continuous gauntlet. The latter was good for testing the bullet hell combat in particular, but is unhelpful in the context of a full game; however, I have not gotten rid of the code I used for it, and may later use it to create encounters with multiple waves.

In addition, I introduced the keystone of the game: the menu-based toggle between RPG and top-down shooter gameplay. It is available on both the main menu and the pause menu, and currently functions without issue. The shooter style of gameplay is already in place and functions at an acceptable level; all that is left to do is add the RPG side of things and polish that to my satisfaction, and then I can focus on polishing what is already here and adding small new things to improve the experience. 

The manner in which random encounters work as of the time of this writing is as follows:

• Each time the player takes a step (i.e. completes their movement pathing), a number is rolled for the global variable MobSeed. The table on which it is rolled is random, but the range depends on what the current room is–this allows different areas to have different encounter tables.
• A local variable in the overworld player object, randint, is also rolled as a random number between 0 and 100, inclusive. If the result is less than 10 and the player is within a zone that permits random encounters, the game saves the player’s current room and X/Y coordinates within said room, then transports them to a separate room dedicated to random encounters. The room to which they are sent depends on the currently selected gameplay style.
• Once there, the current value of MobSeed is checked. Depending on what it is, a different set of enemies is spawned.
• In this way, the encounters themselves are not completely random, but they are still random–that is to say, the enemies that appear are not selected randomly on an individual level, but on a group level.

Bug Fixes:

• The overworld player object spawns in in battles when it shouldn’t.
• After ending an encounter, it boots the player back to the title screen.

As per in-class feedback, I modified the bullet hell section so that player damage is more obvious, as well as introduced a results screen when finishing a battle (it determines when to appear by checking if any objects of the Parent Enemy type exist). I also created a main menu page with a functioning selection box, as well as a pause menu with the same. Finally, I created a small overworld with grid-based 4-directional movement (including a dash function), as well as scene transitions between rooms and menus. This overworld will be refined moving forward.

With regard to the player’s movement: I had long entertained the idea of a grid-based game, since having everything on the map be on a consistent grid makes determining collision events with terrain a breeze. After all, when everything is measured in 32×32 boxes, you need only determine which 32×32 boxes the player is allowed to walk on, and just like that, collision is sorted.

To accommodate this, the overworld player object uses four Paths to move around, each of which moves the player a fixed distance in a certain direction. Entities with movement paths may become an issue down the line if I continue to use my current system for player movement, as it only checks for collision before allowing the player to move, and does not account for things moving into the player’s path after the movement has already started. However, that should not be an issue for this particular demo, as I do not plan to have anything of the sort outside of potentially a cutscene.

This week, I resorted several objects (bullets, enemies, boss parts) into parent/child objects for ease of classification, and because the disorganization was bothering me. In addition, I introduced a bullet reflection mechanic currently mapped to 1, 3, 5, 7, and 9 (with a 15-second cooldown), and modified the cooldowns of all spells so that there is a 3-second delay before you can use another one, to prevent spamming.

Finally, I started and finished work on the bullet hell stage boss and its gimmick–the boss has three points that the player can shoot at, those being its two eyes and its mouth. The boss’s weak point is in its mouth and it will only lose HP if that weak point is shot; however, this weak point is protected by its teeth, which block bullets. To get the boss to open its mouth, the player must shoot its eyes until they close, at which point they will have a small window to shoot at the boss’s weak point and deal damage. Eventually, its eyes will open again and the teeth will reappear. The player must repeat this process until the boss is defeated.

This week was primarily spent focusing on enemy bullet patterns and introducing a relatively consistent difficulty curve which will be further modified and polished moving forward. In addition, I added bullet deletion protocols to avoid screen clutter and separate stages, as well as a special animation for this action to indicate that the bullets are disappearing intentionally. Finally, I introduced special attacks for the player, which are mapped to the number keys 1 through 0 and have been programmed with cooldowns to prevent spamming.

This week, I edited many of the audio files to remove any potentially-copyrighted sound effects and/or musical motifs, replacing it all with original work of my own design. A few samples of the songs included in-game have been included below.

In addition, I tinkered with the way the enemies spawn each other; now, instead of it checking for all three labeled enemies being dead in the enemy step function itself, it instead runs the check through a separate Game Manager object. This allows me to run seeded encounters that use multiple of the same enemy object, instead of having to duplicate them and name them different things.

Week 2: This week, I crystallized what I would be doing regarding the senior project in this class, in terms of order of priorities. I wish to perfect the top-down shoot-’em-up style of gameplay moving forward. If I can accomplish that quickly enough, then I will move on to the RPG section, then art. In addition, I went sifting through my older projects to see if any of the code used in those could be applied to this project in part.

Week 3: This week, I developed a schedule of sorts to keep myself honest with regards to the project. The issue with an idea like this, which has been developing in my head for a very long time, is that it often leads to unrealistic expectations. As aware of this fact as I am, I still want to be sure I’m not biting off more than I can chew. With this simple list of goals, I hope to ground myself in reality and make reasonable steps towards a more complete product.

The epicenter of my project is the two separate modes of gameplay. I hope to integrate two diametrically opposed styles of gameplay––turn-based RPG (e.g. Pokemon, Chrono Trigger) and top-down shooter (e.g. Galaga, Touhou)––and allow the core game to be played in either fashion depending on what the player is more comfortable with. Some overlap will of course exist, such as equipment affecting both gameplay styles. Some encounters may force the use of one style or the other, and the final boss will be a test of both, with one phase for each.

In order to accomplish this, the brute force solution would be to code each encounter twice––once as an RPG and once as a top-down shooter. However, I feel that that is a very big ask and so my plan is to code one style at a time and focus on the mixing of the two later down the line. I want to make sure the pieces are sufficient before putting them together.

This week, at the behest of the professor, I experimented with https://www.inworld.ai to assist with writing dialogue for my video game. I find the software interesting, and am heavily considering using it in the future to help patch holes in the dialogue I currently have. However, I feel as if using the AI exclusively for writing is a bit too much like cheating or cutting corners, so I only plan to use this as a supplement.

My overall plan for this project is too large in scope for this short a time frame. It would be naive of me to believe I can complete an entire full-length video game, code and story and art and all, from start to finish in the span of just a few short months. Instead, my hope is to have a proof of concept: a set of building blocks that I can use to build out the rest of the project from here. To reiterate, my end product for this semester WILL NOT be the complete game, but it WILL feature its core components and many of the elements that will later be present in the finished product.