Pacing on - Week 6
Overview:
The Fly is the first enemy, the most common one, and most likely the most annoying one to deal with. Simple in it's mechanics, the Fly well... It flies towards you, taking the shortest path possible, and damaging you upon coming in contact with you. That isn't the only thing it does, though. The Fly also splits into two, smaller flies when damaged - the smaller flies are faster, but does less damage.
- Enemy Development - Fly, Plant, Slime.
- Camera Development
Time to talk about some actual gameplay - specifically, enemies. This week I focused on creating the enemies for the game as well as experimentation with the camera. Also - this post is going to be formatted a little differently. Need to spice things up now and again, right?
I was tempted to go overkill and do a smash bros style intro for each of them but I really shouldn't.
I was tempted to go overkill and do a smash bros style intro for each of them but I really shouldn't.
The Fly
The Fly is the first enemy, the most common one, and most likely the most annoying one to deal with. Simple in it's mechanics, the Fly well... It flies towards you, taking the shortest path possible, and damaging you upon coming in contact with you. That isn't the only thing it does, though. The Fly also splits into two, smaller flies when damaged - the smaller flies are faster, but does less damage.
Since this was the first enemy created, I also had to create the base of the enemy - specifically, figuring out how enemies should detect the player in genera. I found a component called 'Pawn Sensing' that can be used to sense and detect any kind of pawn in a certain 3D space. I was able to adapt this into a system that detected the player and caused the fly to chase the enemy. This is also the same as what I used for player detection with the Slime.
You can view the full blueprint of the (Large) fly here.
The Slime is the second enemy you encounter and hence, the second enemy I made? See a trend? The idea for the slime is to become dangerous when damaged - specifically, it explodes. Unlike the Fly, the Slime patrols the platform it's currently standing on. This is done through the use of Line Traces, detecting any kind of collision in front or below it. If it detects collision in front of it, it will turn around. If it detects no collision below it, it also turns around. This ensures that it doesn't fall off any platforms I put it on. However - this is broken when it spots the player. It begins to make small jumps and go in the direction of the player, regardless if it means it will fall or not. Otherwise, it would be rather easy to avoid this enemy.
Upon taking damage, the slime will begin to glow - a purple circle will appear around it, indicating danger. If the player stands in that circle as the Slime 'detonates', the player will receive a large chunk of damage and be knocked back. It is possible, however, to destroy the slime with two additional hits (three total), stopping the explosion. However, this will most likely leave the player with no stamina, making them vulnerable. Either they can avoid the slime and it's explosion, or attempt to destroy it before it hurts you.
You can view the blueprint for the Slime here.
The plant is the final enemy of the three that I have created - and is most likely the most annoying. The plant is a stationary enemy that is placed down anywhere - it can be on walls or ceilings, and is 'implanted' into the ground. When within the plants 'radius', the floor below the player will begin to glow and rumble. If the player stays on the ground for too long, they will be damaged for a large chunk of their health. If the player jumps, the countdown for this damage will reset, and you'll be able to navigate to the plant and kill it. This enemy has one primary function - to punish any player who does not take advantage of the high mobility provided to them. Mobility is the core mechanic of this game - in the form of teleportation. Being able to double jump means there's little to no excuse for being on the ground for long at all.
Now, it's rather difficult to indicate what the rumbling glow below the enemy means. To fix that, just before the player encounters the enemy, a small rabbit can be clearly seen bouncing up and down. The same glow being noticeable under the bunny. After a short moment, the bunny is killed - indicating that if the player stays in the glow for too long, they will die. This is a great use of show not tell, which is a large part of what Megaman X does when tutorialising new enemies. It introduces them in a 'safe' environment. This is also what many mario games do in the form of Kishotenketsu. There's a video explaining this design philosophy here.
Creating this enemy was the most complex - I had to create three seperate entities for it. One for the particle that follows the player on the ground, one for the plant itself, and one for the spike that damages the player. You can see the blueprints for them in the links above.
As you could imagine, the dealing with these enemies all at once can be rather difficult. This is what I am planning - as rather than increasing difficulty with pure numbers and scale, I thought it would be interesting to deal with multiple mechanics at once. This is what Raid Bosses do in games such as Final Fantasy XIV, a game that I am very much in love with.
You can view the full blueprint of the (Large) fly here.
The Slime
The Slime is the second enemy you encounter and hence, the second enemy I made? See a trend? The idea for the slime is to become dangerous when damaged - specifically, it explodes. Unlike the Fly, the Slime patrols the platform it's currently standing on. This is done through the use of Line Traces, detecting any kind of collision in front or below it. If it detects collision in front of it, it will turn around. If it detects no collision below it, it also turns around. This ensures that it doesn't fall off any platforms I put it on. However - this is broken when it spots the player. It begins to make small jumps and go in the direction of the player, regardless if it means it will fall or not. Otherwise, it would be rather easy to avoid this enemy.Upon taking damage, the slime will begin to glow - a purple circle will appear around it, indicating danger. If the player stands in that circle as the Slime 'detonates', the player will receive a large chunk of damage and be knocked back. It is possible, however, to destroy the slime with two additional hits (three total), stopping the explosion. However, this will most likely leave the player with no stamina, making them vulnerable. Either they can avoid the slime and it's explosion, or attempt to destroy it before it hurts you.
You can view the blueprint for the Slime here.
The slime in action - it deals damage on both contact and detonation.
The Plant
The plant is the final enemy of the three that I have created - and is most likely the most annoying. The plant is a stationary enemy that is placed down anywhere - it can be on walls or ceilings, and is 'implanted' into the ground. When within the plants 'radius', the floor below the player will begin to glow and rumble. If the player stays on the ground for too long, they will be damaged for a large chunk of their health. If the player jumps, the countdown for this damage will reset, and you'll be able to navigate to the plant and kill it. This enemy has one primary function - to punish any player who does not take advantage of the high mobility provided to them. Mobility is the core mechanic of this game - in the form of teleportation. Being able to double jump means there's little to no excuse for being on the ground for long at all.
Now, it's rather difficult to indicate what the rumbling glow below the enemy means. To fix that, just before the player encounters the enemy, a small rabbit can be clearly seen bouncing up and down. The same glow being noticeable under the bunny. After a short moment, the bunny is killed - indicating that if the player stays in the glow for too long, they will die. This is a great use of show not tell, which is a large part of what Megaman X does when tutorialising new enemies. It introduces them in a 'safe' environment. This is also what many mario games do in the form of Kishotenketsu. There's a video explaining this design philosophy here.
Creating this enemy was the most complex - I had to create three seperate entities for it. One for the particle that follows the player on the ground, one for the plant itself, and one for the spike that damages the player. You can see the blueprints for them in the links above.
As you could imagine, the dealing with these enemies all at once can be rather difficult. This is what I am planning - as rather than increasing difficulty with pure numbers and scale, I thought it would be interesting to deal with multiple mechanics at once. This is what Raid Bosses do in games such as Final Fantasy XIV, a game that I am very much in love with.
The Camera
I almost forgot to talk about this! During this week, I enhanced my camera. Specifically, I had a problem that I needed to solve. I often found that, when teleporting, it was rather difficult to get an idea of where you're actually targeting. Rather than create an extensive UI system that could do the job (but clutter the screen), I thought it would be best to indicate the mouses position with the camera.
Using some math, I was able to create a system that dynamically places the camera in between the position of the player and the mouse. This way, when the player moves the mouse, the camera also moves. To help with this, I ended up creating Camera Anchors, which also affect the position of the mouse. I wish that I had put this in the final product, but the problem with creating the camera anchors is that they had to manually be placed and set for each instance. Which, well, took time - for something that I thought may potentially annoy the player more than help them. I thought that the mouse-based camera was enough. In the gif below, I added a dot in the middle of the screen to indicate the centre.
You can view the blueprint for the camera system (which is inside the player blueprint) here.
Using some math, I was able to create a system that dynamically places the camera in between the position of the player and the mouse. This way, when the player moves the mouse, the camera also moves. To help with this, I ended up creating Camera Anchors, which also affect the position of the mouse. I wish that I had put this in the final product, but the problem with creating the camera anchors is that they had to manually be placed and set for each instance. Which, well, took time - for something that I thought may potentially annoy the player more than help them. I thought that the mouse-based camera was enough. In the gif below, I added a dot in the middle of the screen to indicate the centre.
You can view the blueprint for the camera system (which is inside the player blueprint) here.
Comments
Post a Comment