Back to making games
I got a bit side tracked with that web project but now I’m back with good old Unreal Engine. The short break spent coding websites also got me thinking about what Magivoid is supposed to be. Consequently, with this post comes also a pivot.
Magivoid was initially meant to be some sort of MOBA-like, multiplayer, with two teams battling each other, etc. This was a fun idea and I may continue to explore it, but I want to make it easier for myself to finish this project. You can always extend the game after it’s been released. For this reason, I’ve been inspired to shift gears slightly and make this more of a single player experience. At least to begin with. This should significantly lower the effort needed to test everything and get a solid release candidate built.
The current direction is as such. You play a timed session where monsters of increasing difficulty rush you with the goal to survive. You start with a weak weapon, say a fireball spell, and as you destroy monsters and stay alive, you get to level up and upgrade both your character through various attributes as well as your weapon. Simple idea and I would say totally doable. If I don’t manage to finish this project, I need to move back to my grandma’s village and learn to take care of the sheep because there’s no future for me in gamedev.
One concept I’ve always wanted to explore is progressing the player from a weak individual to an overpowered character that destroys everything in their path. I seem to appreciate this in books and movies and it’s a concept not implemented enough in games. I have some cool ideas for how to take a lame fireball projectile and gradually upgrade it into a massive super weapon, but I’ll get to this later once I have something to show. There are also plans for different types of weapons with a similar sort of progression. For now, let’s look at the changes that have actually been implemented in the game.
Creepy crawlies
In this revised version of Magivoid you start with various small and relatively weak monsters attacking you. As they increase in numbers, you level up and become more awesome. In turn, bigger and scarier monsters start spawning and also gradually increase in numbers. You keep destroying them, level up, and become more awesome. This is the core idea.
Naturally, we need to start with a monster and I have already added it to the game. Say hello to the first annoying thing that will chase you: the spider.
It’s been an interesting journey creating an animation blueprint, hooking up the AI, and getting this thing to behave more or less the way I want it to. It’s not doing anything advanced, mind you, but there were a bunch of moving parts to keep track of. The extent of the spider’s skills is limited to spawning, chasing the player, and attacking when in range.
Oh, it also breaks apart when it’s killed. I thought this was a fun little detail, made possible by the spider being set up with a physics body and making it ragdoll once its health gets down to zero.
The spiders themselves do a random amount of damage controlled by a min/max value specified in a data asset. Their health is also a random value, again controlled by a min/max value. This results in the player sometimes needing two and sometimes three fireballs to kill a spider when the game starts. I’ve always liked RPGs that have slightly random values and give a bit of variability, yet still offer a controlled experience for the gameplay to make sense to the player.
The amount of spiders that spawn is controlled by a float curve starting at roughly 5 spiders and increasing to 20 spiders at minute 2. As new monsters are added, there will be multiple overlapping curves that together create a pool of monsters chasing the player. These are just arbitrary values at this point and will need balancing as new features are implemented. Data tables, curve assets, and the overall Unreal Engine reflection system make it fairly easy and, dare I say, fun to build these kinds of data-driven components.
Visual feedback
I added health bars that rendered above each enemy, which was a nice little detail, but I found it distracted from the game world. There are many nice marketplace assets to start prototyping with and it was quick and easy to get this added. I figured it’s nice to know the state of each enemy and potentially how easy or hard it is to kill it by gauging how fast the health drops, but at the same time I like the idea of keeping it unknown and suspenseful. With no visual feedback like health bars you have no idea what kind of threat a new monster poses until you finally destroy it. So, I got rid of the health bars.
One visual detail that does make damaging monsters rewarding is the recognizable white flash. I think this is inspired by old games where flashing a sprite was cheap and used as a means to show damage or death of a character. Regardless, the confirmation that a projectile landed correctly is a nice little rewarding detail. Unfortunately on small enemies like this spider it can be a bit hard to notice the white flash due to the fireball explosion particle effect running at the time. Still, I do like it when it is visible and will probably keep it unless I find a better way to show damage being done.
Let me see if I can bump up the scale of the spider so we see the hit flash in action.
Nice!
Next up
With these changes the project is starting to feel a bit like a game. When I debug things I constantly find myself running around killing spiders for just a bit longer than I need to get the job done. I feel it’s possible to extend this to something fun to play.
In the next devlog I’ll likely cover some of the weapon upgrades and see just how fun and overpowered I can make this fireball attack.
Top comments (0)