*EARLY DEVELOPMENT, MUCH PROTOTYPE* MGU (acronym is a secret for now) is planned to be a third-person, cover-based, online multiplayer shooter featuring magical girls engaged in bloody combat. Players will be able to customize their characters before having them employ both traditional weapons as well as magic abilities to dismember, disintegrate, or otherwise annihilate their opponents. MGU will include PvP and PvE modes, with PvP supporting up to 8 players (4v4) and PvE supporting up to 4 (cooperative) at one time. There is also a customization mode planned... which I will abstain from talking about until it has begun development.
I've gotta tell you... using UE4 is not like riding a bike! If you don't use it for over a month, you will forget things! And it's certainly been a looong UE4-less month. Necessary, though. Way too many other distractions in my life to be able to properly focus on development. Luckily for me, though, I take lots of notes in my code and on my processes, so getting back into the swing of things took all of about a day. Let's talk about what I got done this past week, my thought processes, and where I want to go from here!
...BUT FIRST. I almost always make videos for my updates, because describing visual effects and sound in words is kind of... you know... stupid. But I can't really do much better than short text summaries of what's happening in the video, so I consider them like a supplement to the article. Check it out if you want!
Visual Updates - Ether Motion
Ether Motion is the in-lore term (yes, I wrote a bunch of lore before I even started working on this game) for how a Magical Girl moves around quickly without becoming exhausted. Obviously, running and rolling and vaulting and all that stuff is cool, but let's be honest... you'd get out of breath in like half an hour, and that's if you're really fit. So if you're a smol Magical Girl, you have to rely on some of your other tools... which in this case, is "magic". And "magic" in this world refers to channeling the electrical waves and frequencies that are all around us all the time, which most closely interact with someone's "Ethereal Self".
Well, the lore is based pretty heavily in occult perspectives on the world, and I'm not gonna go too deep into it. Suffice it to say that when you move around cover, it's going to look something like this:
As always, the 4MB limit for article images means my GIFs have to be a bit compressed (Hint: video at top of article), but you get the idea.
I want to stress that what I have right now is not likely to be the final effect, but it most definitely gets the idea across. The real question is, why this effect... well, I've harped on this a few times now in my articles and in my videos, but one of the biggest things I'm trying to avoid in this game is the campiness that you get from every other cover-based shooter game (that I've played, at least). And it's never, ever the players' fault that a game becomes campy... as someone who plays GoW at a high level, I can tell you that players in multiplayer games are looking for every advantage they can get, so if sitting behind a piece of cover is the most advantageous move, that's what they should do if they want to win.
I've already done a few things you've seen before to start addressing this... the Cover Blast mechanic, the fact that having even a little verticality means you can shoot someone behind cover, ease of getting in and out of cover quickly, etc. This is another piece of the puzzle I had written up in my design document; because most of the multiplayer maps in the game are planned to be dark (despite what the sunny-looking Prototype map in the video may have you believe), any bright visual and auditory cues are going to be important to tracking down opponents. So being in cover is going to provide a physical barrier, yes, but it's also going to reveal your location... and what I've shown so far is not the extent of the design I have planned around this. Not even close.
Suffice it to say that cover will be a tradeoff between needing a physical barrier and being located by opponents. It will be best used as a tool for moving around the map quickly and safely. Hunkering down will often not be the best choice...
Visual Updates - Death Fade
What happens to a body after it dies? .....well, nothing much, really. It'd be like watching a pot boil if you expected to see anything happen right away.
Luckily, this is a videogame, and it has magic in it... so when bodies die, they can disintegrate!
Mind you, I'm not sure if "Death Fade" is going to be an actual in-game term... I didn't actually write anything about it in the lore, I just needed to call my function something and that was what came to mind at 2 in the morning on Friday.
Basically, for anyone who uses UE4, you probably already know how it works. The most interesting aspect of it is the material and material function... the actual logic just involves a Timeline to drive the values of some parameters of Dynamic Instances of those materials, along with an "arterial blood" emitter I'm spawning at the neck bone. And in case you're thinking "arterial blood" spurts might be a bit much... oh, don't worry... I haven't even added in the blood splatter decals and the pool of blood that forms around the body after it hits the ground. It'll get much worse! :D
I'd like to add a bit more to the disintegration effect as well, like some particles that rise up and float away into the wind, but I'm trying not to focus too much on visual stuff right now. I'll be honest, I really just wanted something in there so the bodies don't randomly vanish, because I'll be sending this to a couple friends soon so we can start doing some network testing and I know they'll tease me if stuff like that is still happening xP
Yep, I can be insecure sometimes. But as long as my insecurity is getting crap done, then I will treasure it.
You know, every time I used to look at the physics asset in UE4, I would just kind of grin awkwardly to myself and shake my head. It was like that unfortunate 3rd child you never really wanted to have, but your wife insisted, and they haven't yet grown up enough that you can truly love them yet (I apologize to all the 3rd children reading this).
BUT. This week has been a week of me doing things I don't normally like to do, so I decided to tackle it head on and finally get ragdolls working properly. There's a really good video I watched on Youtube by someone named "Kunu UETutorials" on setting up a Physics Asset from scratch, and it really helped show how simple it actually is. Each bone has a capsule attached to it, which represents that body part in terms of shape and weight. Between capsules you can have constraints which limit or lock the angular motion of that "joint."
...And that's basically it. There are a ton of parameters you can change, but fundamentally, that's literally all you do. The whole point of the Physics Asset is to give your mesh some kind of definition that the underlying physics engine can understand when it starts simulating physics (which is what happens when we "ragdoll" a character mesh).
On top of setting up the asset, I also started applying impulses to the ragdoll based on the direction they got shot from before being killed. So now they will be "pushed" in the direction that they got shot from:
I also finally started using UE4's built-in "DamageType" class. It's intended use is basically to define how a player gets killed. Since you can easily pass a DamageType reference from the class that damages the player to the player that gets damaged, it's useful to store information like the name of the weapon, whether it was magic or standard damage, whether it has some other properties like fire damage, etc. What I'm doing with them at this point in time is defining different impulse strengths for each weapon. So, the SMG you see above has a much smaller impulse than, say, a shotgun...
Handling impulses for headshots required a bit of manual fenangling. Technically if you get head-shotted you're probably not going to be flying very far away in real life, right...?
WE MUST FIX REALITY.
Good times, good times... I like hyper-realism, in case you couldn't tell...
You may or may not have realized this, but the game has been completely without audio up until the past week. Yep... so that was one of the major things I'd wanted to get done before going on my hiatus. Obviously, I can't make the end-all-be-all sounds right now, because A) I may write music, but that doesn't make be a good sound engineer, and B) Without finalized models and animations to inform what the sounds should be, I can't be sure things won't change in the future. Instead, my goal was just to make some decent placeholders.
I actually tried contacting a couple of different people to do paid work for me, but they were both busy... not surprising, I suppose, most people who are good at what they do are busy. But I'm actually glad this turned out to be the case, because it forced me to just do it myself. So, instead of paying someone upwards of $700 for prototype sounds that might not even be in the game, I paid about $200 for this beautiful thing:
What is this glorious, digital piece of machinery you ask?!
...well, a synth, basically. Yep. It's called "Weaponiser." Basically, you can layer and time samples inside of it to create sounds. It comes with built-in EQ, Compression, etc. as well, which makes it extremely flexible to work with. I promise this isn't an advertisement, by the way... I'm not popular enough to make an advertisement, are you kidding me?.. I just really loved having this. I honestly don't generally enjoy the process of putting together complex sounds, but using this made it a lot more fun for me.
So basically, my process for each sound was to cut up and normalize samples I found online and/or recorded straight from Weaponiser in Audacity, load them into Weaponiser to create the base sounds, move that sound into FL Studio to add any extra effects I wanted (EQ and Reverb, mostly), and then finally bounce it into UE4 where I can do the pitch modulation and attenuation and all that good stuff.
I'd say the process of creating all the sounds I have so far took about 3 full days of work, which is really not bad at all... I got all the base weapon sounds (shooting, charging, reloading, switching weapons, switching to Magic Mode, Cover Blast, headshots) and the movement sounds (sliding to cover, walking, running, idle vaulting, run-vaulting, rolling) done.
Not to mention, this process involved putting in the logic of how and when each sound fires, so swapping out sounds later on to see what fits best will be a piece of cake :D
Alright, well I think I'll wrap it up for now! This past week has been a lot of getting stuff done I don't normally love to do... it's sort of par for the course for an independent developer, I guess. You have to be your own artist, sound designer, programmer, and all the rest of it. But I'm glad I was able to come back after an extended break and get a lot of it done!
My next steps at the moment are to start trying to break stuff (mostly with regards to networking), add in some basic menus (pause screens and scoreboards), and then get started on the Magic System, at long last.
The fun times just keep on rolling!
- Flash <3
Just a short update on what's been going on the past few weeks. Lobby system complete, started on some more visual FX, and am working on audio!
In this article, I show some of the new environments I'm putting together to better facilitate testing various game systems, as well as the beginnings...
Update on how the networking work is going, my REST API application, and some code refactoring I finished yesterday.
In this article, I run through my initial HUD prototype and the basic structure for how I'll be implementing the Magic System in the game.
No articles were found matching the criteria specified. We suggest you try the article list with no filter applied, to browse all available. Post article and help us achieve our mission of showcasing the best content from all developers. Join now to share your own content, we welcome creators and consumers alike and look forward to your comments.