Week 2 of development (Unity)
- Owen Hey
- Jul 17, 2021
- 4 min read
Updated: Sep 2, 2021
This week's post is a follow up to last week's, where I started creating an environment to practice my design skills. This week, I tweaked some of the combat mechanics and designed some enemies for the player to fight.
To give you an idea of where I left the project last week, here is the short gameplay video I showed at the end of last week's post:
There's a lot of strong elements here. The movement for the character feels great, the art style is simple but engaging, and the little enemies move like I had wanted them to. However, there are a few problems that stand out.
The player's melee attack feels bad. Because it sweeps from one side of the player's body to the other, the blade can "stall" if the player turns in a certain direction right after using the melee attack (I'll show an example in a moment).
The enemies aren't interesting to fight against. Their "shooting" mechanic doesn't work very well because they always are aiming directly at the player instead of predicting the player's movement. This means it's very easy to run circles around the enemies.
The visual style works, but it's a little bland. The things the player needs to focus on should "pop" and draw the player's attention.
I slowed time a little so it was easier to see. If the player rotates the opposite direction of the sword swing, it cause the sword to "stall" in space.
Dodging the enemies' bullets is pretty easy if you just run around in circles
To fix these issues, I implemented two three simple changes. First, I made the player unable to turn during their attack. This fixed the issue of the player's sword stalling while they turned while also adding a slight drawback to using your sword. Drawbacks for actions are important to have in games because it stops the player from using their actions constantly.
Second, I changed the boids' attack from the simple projectile seen above to a "suicide-bomber" attack. They charge at the player and if they collide, they blow up and deal some damage to the player.
Third, I added a small glow to the objects in the scene. This really brought the game to life visually.
Here is the result:
It may look similar to before, but it feels a lot better to play.
Although the melee attack is better than it was, I'm still not super happy with it. I'll be working on it more over the next few weeks.
I want to touch on the idea of "drawbacks" for your actions I just mentioned. It's an important thing to consider when designing mechanics, and there are a million ways to approach it. Abilities that are purely positive lead to extremely repetitive gameplay, as the player has no reason not to use an ability at any given time.
Some popular ways to implement drawbacks are:
Cast-time. If an ability takes a quarter second to "charge up", and the player isn't able to act during that period, it means the player is putting themselves at risk for that brief moment. Additionally, it provides time for enemies to react which leads to fairer gameplay.
Resource costs. Mana, energy, and ammo are all examples of this. The player has a limited amount of resources to spend, and abilities cost resources to use. I'm a big fan of this approach because it adds resources other than health to consider when balancing the game.
Sound. This is only really works in multiplayer games or games centered around stealth. If an ability creates a huge explosion that attracts nearby enemies, players will think carefully about when they choose to use it.
Cooldown. If an ability has a 5 second cooldown between uses, players will make sure it's ready for the most intense moments of the fight.
Right now, the player in my game is able to "shoot" as much as they want without any drawback whatsoever. This is terrible game design, as it means the player has no reason to not hold the shoot button for the entire course of the game. I'll be looking into this problem next week.
Another thing I wanted to add was a simple reward for killing enemies. I'm a huge fan of enemies "dropping" a powerup on death, as it lets the player chain enemy kills together in a satisfying way. I made a little orb drop when enemies die, which the player can pick up. I'm not sure what exactly I'll use it for in the future, but I think it looks cool and can lend itself to a fun mechanic down the road.
The last thing I added were some basic enemies. I had the "boids" enemy already programmed, but I wasn't a huge fan of just letting them loose in a room. And since their movement was based on flocks of birds, what better than a "nest" to spawn them throughout the game?
The nest enemy sits on the walls and spawns boids - it can get pretty out of hand if you let it survive for too long
The next enemy I created is called a "squenemy". It's an extremely simple enemy for the player to learn the basic mechanics on.
With just two (three if you count the boids) basic enemies, the game is already getting pretty hectic. I definitely need the go back and adjust some of the functionality for these creatures, but I'm happy with the path I'm on. Here is an example of a "room" (a part of the game where the player gets locked in with a bunch of enemies).
Far from a game worth playing, but it's on its way...
The game needs a lot of work, and I'll try to make a lot of progress next week. Here are some of the goals:
Even with just a few enemies, the game quickly becomes impossible to follow. There's too many things flying all over the place - all moving way too fast to keep track of. I want to slow everything down a little.
I want to improve the basic abilities. They're functional in their current state, but not very interesting.
I want to utilize the entire controller. Right now, I'm only using the left stick and the four main buttons (A, B, X, and Y). But there are bumpers and triggers at my disposal as well as the entire right stick, all of which have no use in the game's current state. I'm not sure what I'll end up using them for, but it would be silly to leave them unused.
See you next week!
Comentários