Phaser Project
With the project in Phaser in full swing, I took a few days this week to go over what kind of final design notes I wanted to make before getting any further. I decided to draw out the three stages with the final set of mechanics finished, along with what kind of enemy interaction I wanted to implement. This is to make sure now that the initial mechanics are complete, I don’t fall too off track in the last couple of weeks before the deadline.
I did this by going over my original notes and design documents I made before the project, and then revising them with the updates, along with what features I know I need to implement before the end. So far, the initial idea I had in mind, as far as a completed project, is close to what I intended, but the ways I see the finite states working for the enemy have drifted slightly. After learning more of the Phaser framework, I have found different and more optimal ways to set these states.
The first is in creating an enemy class, along with passed in attributes that will trigger certain states. I did this to organize the main scene. When a new stage is triggered, I can set a new Enemy object and have that new finite state run. It does this by creating and running a new Event in which is called every so many seconds and loops until the enemy’s health bar is depleted by the player, destroying this instance of an Enemy, and setting a new one. This has been easier to control and gives me more options to add small adjustments along the way. This organization has been a big upgrade in not having to go back and change other features in a scene, if an Enemy object can just be destroyed and added in another stage.
2D Physics and collision
Further class studies have pushed into the realm of 2D physics. More specifically collision detection and efficiency practices that come along with them. I spent a lot of time reading and studying this topic as there seems to be an algorithm focused well of information on the matter. The contrast of efficiency and performance is a common denominator in any user-focused project, and this is no exception. Because there are different ways and methods to detect for collision, there is no one best way to do so. It depends more on what kind of game it is and the game mechanics that are featured. For example, a First-person shooter with hundreds of high velocity bullets in a small hallway is going to need Continuous Collision Detection on these objects for highly accurate outcomes. Otherwise, this mechanic, shooting, would be very un-fun to play.
In contrast, a massive open-world RPG will not want to take this same approach. A massive map with hundreds, if not thousands, of NPCs will not want to run these constant, and computationally intensive checks on all the objects while the player is nowhere near them. So, the Broad Phase is mightily important for these types of games. Meaning the objects not on screen, meaning the player is not currently engaged with them, can be practically asleep. Only to be woken up when the player has to potential to interact with them. This will save a tremendous amount of processing power and deliver a more seamless experience for the user traveling a larger world.
Currently because my Phaser project is happening in a very simple scene, the need to make efficient checks is less important, but the way the player interacts with these collisions can have a big impact on how the character looks and feels to control. These small changes in the collision detection have made the current mechanics I already have implemented, feel better to engage with than before.