*EARLY DEVELOPMENT, VERY UGLY, MUCH PROTOTYPE* MGU (acronym is a secret for now) is planned to be a third-person, cover-based, online multiplayer shooter featuring cute magical girls engaged in bloody combat (and maybe love?). Players will be able to customize their girls 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.
Ok! Like I promised, I'm back with another article after finally getting movement between adjacent walls and aiming in cover working. Vaulting will be next, though that's kind of a tricky one to do without having any commissioned animations yet >_>
I've put together another video that shows the major additions, which you can see below:
Alright, now where should I begin...
A Major Headache
First, let's talk about a major headache I had. These articles are supposed to be my documentation as much as anything, so I think it's worth touching on this even though it has no bearing on my final implementations.
Basically, I was minding my own business, trying to get the character to move to another wall without it being either messy in code or awkward-feeling in game. As I was just about to take a break, Visual Studio asked me to update. So, being the good citizen that I am, I obliged.
When I came back, it was like everything just broke. Replication wasn't working for the Listen Server. My client's motion was super jittery anytime I used the MoveComponentTo function (cover sliding, rotating back into position after aiming in cover, etc.) I was completely flabbergasted! I reinstalled VS. Reinstalled Unreal Engine 4 (not a good time). Started making logs of the Client vs. Server positions each Tick... I mean, look at this nonsense:
This log shows the location data reported each tick by Client and Server during a slide to cover. The Client is like 15 - 25 cm behind the Server except at the end of the movement! Awful!!! Edit: Can I mention that I just noticed I spelled "Server" as "Sever?" You can tell how psychologically disturbed I was by this point.
Oh, but I will say I verified something I thought I knew but never conclusively determined before, which is that the Character Movement Component does NOT replicate explicit rotational changes. I won't show the log here to save space, but if you only run the function to set rotation on the server, the client doesn't change their value at all. If you set location, however, they do. Useful thing to know!
Anyway, after TWO DAYS of this nonsense, I find the problem... at the VERY TOP of my code:
WHY IS IT FALSE?! I DIDN'T. SET IT. TO FALLLLSSSEE ZSFOJOJOWE! *throws keyboard at cat*
...*clears throat* Yes, well, that was the problem. The MoveComponentTo function needs you to Tick, and my character wasn't ticking. As soon as I turned it on, all my jittering went away. Pro tip :)
NOTE: I only set Tick enabled right before and after a MoveComponentTo function. DO NOT TICK ALL THE TIME THAT IS BAD AND YOU LOOK LIKE A N00B.
Moving Between Adjacent Walls
Now that that's out of the way, on to happier topics! I had mentioned in my previous DevLog that one of my ideas was to move the actor to a CollisionBox on overlap and set their new rotation based on its ArrowComponent direction. It was the idea I said I was less fond of due to wanting to keep control in the players' hands, but I changed my mind for three reasons: 1) It's cheap and relatively easy to do, 2) The time to move doesn't noticeably interfere with player movement, and 3) It gives that motion just a slight feeling of "purpose", like there's some intent behind switching walls... which I think I might use to my advantage when designing levels (more on that later)...
So yes, the implementation itself isn't horribly complicated. There are a decent number of checks I have to do to handle things like aiming, is it high cover or low, is the player trying to get out of cover, etc., but the fundamental idea is simply:
And that's it, really. You can see the results without the CollisionBoxes showing in the video at the top of the article!
Aiming In Cover
You know, there are some intricacies to this aspect of cover that I hadn't fully thought of before starting to implement it, and as a result I'm not completely done with even the basic implementation. But I do have most of the basics down:
And that's what I have so far. Like I mentioned, there are some other details that I also need to deal with. For example...
...And a few other questions, but those are the main ones. The top one is the one I'm going to be most focused on right now. I don't think they can see far enough over at the moment because I'm not shifting them forward at all when they aim, so I'm going to try getting that worked on so they can see most of the way on the other side of cover (remembering my principle from DevLog #2: No Over-Powered Cover!)
I'm mostly in new territory now. The furthest I got on a similar project, which I started... oh, 3 years ago now?... was here, minus being able to move to adjacent walls. And I had some of the actions at cover edge figured out, just not super well. That said, I anticipate that finishing the cover system, even if I'm only working through the basic logic at the moment, should be quite the journey indeed.
However, I absolutely plan to come out alive on the other side and not fall into the deep, dark pit that many indie devs fall into, never to be seen or heard from again... but of course, we all say that don't we ;)
Brief discussion on some updates I've made to my original cover system implementation ideas, and details on where I'm at with movement in cover.
Talking about my design principles for the cover system, the next big system that needs to be implemented in the game, as well as some initial ideas for...
My first post on the game! Article talking about how I'm handling my line traces to deal with pesky third-person perspectives in shooters (especially...
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.