*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.

  • View media
  • View media
  • View media
  • View media
  • View media
  • View media
Post article RSS Articles

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:

Client Server run log

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:



...*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:

  • When the player overlaps a CollisionBox, check to see if the forward vector of its ArrowComponent equals the one of the previous box. If not, it's an adjacent wall.
  • If it's an adjacent wall, use MoveComponentTo to set the player's location and rotation to the new wall over a short period of time. Adjust this time to be smaller based on player speed so that the motion feels consistent whether walking or sprinting.

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:

  • The player can aim while in cover.
  • The direction vector calculation is updated when the player aims so that it feels just the same as when they're not aiming; they can move right or left in cover by inputting directions that make sense intuitively based upon where the camera is pointing.
  • The player can back out of cover while aiming and put themselves into a "Not In Cover" state.
  • The player automatically rotates into a position that feels natural when releasing the aim button while in cover. For example, if they got into cover facing to the right, aim to the left, then release the aim button, they will now be facing to the left. This ONLY applies when the player is NOT moving, because when moving it's more natural to rotate back in the direction of movement, regardless of which way we are aiming.
  • When moving in cover, if the player reaches a piece of high cover, they will stop aiming automatically.


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...

  • How far over cover can the player shoot? Can they look all the way down behind the other side of cover? Will that depend on the type of cover?
  • If a player is in high cover, should they be able to aim behind them while still in cover? Should we automatically take them out of cover when they try to aim in the opposite direction of the wall's normal?
  • Do we allow the player to hold the aim button while sliding into cover and automatically start aiming? Should they have to time the button press properly to aim only after the slide is complete? Should aiming cancel the cover slide?

...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 ;)

-Flash <3

Cover System - Basic Movement (DevLog #3)

Cover System - Basic Movement (DevLog #3)


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.

Cover System - Design Philosophy & Implementation Ideas (DevLog #2)

Cover System - Design Philosophy & Implementation Ideas (DevLog #2)


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...

Handling Third-Person Perspective Shooting (DevLog #1)

Handling Third-Person Perspective Shooting (DevLog #1)


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...


Looks cool!

Reply Good karma Bad karma+2 votes
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.

Follow Report Profile
Windows, Linux
Send Message
Release date
Game watch
Embed Buttons
Link to MGU by selecting a button and using the embed code provided more...
Last Update
4 members
You may also like
Transformers: Fall of Cybertron
Transformers: Fall of Cybertron Third Person Shooter
Project Gun Arts
Project Gun Arts Third Person Shooter
Saints Row: The Third
Saints Row: The Third Third Person Shooter
State of Decay 2
State of Decay 2 Third Person Shooter
Dead Space 3
Dead Space 3 Third Person Shooter
Despair World
Despair World Third Person Shooter