Player Input: Where Should the Logic Be Held?

By: Matthew Steinhardt

Expanding on the Player Input

When creating our player character, we initially had the idea for all of the player interaction to take place within the third person view. This included the shooting, placing towers, and purchasing upgrades. However, as we discussed our idea more it became clear that a better view for building towers would be a top-down, wider angled, view.

The Problem

I set out to create player input controls to allow the player to seamlessly switch between a third person camera view and a top-down view. In this new "mode", the player got a much bigger picture of their surroundings. In addition, we made the cursor visible only while in this view to allow the player to easily interact with a familiar UI for placing buildings. However, there were a few problems.

The first problem was that controlling our character from a top-down view didn't feel good. It was clunky and there was no reason for the player character to be moving around while in this view either. This meant we would need a different set of movement controls while in the top-down view and some way to "reset" the camera back to the player character when the player wanted to swap between the two. Suddenly, I foresaw our player input logic becoming extremely messy very quickly.

The Solution

Two Input Modes: Two Pawns

I took a step back and decided that our two separate input "modes" deserved their own respective pawns. The top-down (aka "Building Mode") view did not need to concern itself with the player character, as we moved away from having the player character be directly controlled while in this mode. So, I created a new pawn with a floating movement component that, when possessed by the controller, would allow the player to smoothly glide around the map using the WASD keys.   

Moving the Logic

I moved the logic that listened for input events regarding view-switching into the player controller instead of the player character, where it originally was held. I then stored references in the controller to both the player character and the "Building Mode" pawn. All of the logic that was responsible for swapping they player between the two modes is now here. Not only did this clean up the messy code structure, it also allows us to easily refactor and swap out one pawn for another. If we decide we want a completely different set of controls in the "Building Mode", it's as easy as swapping the reference for said pawn in the controller. Modularity is cool!

Player Controller logic handling swapping between both modes

Comments

Post a Comment

Popular posts from this blog

UI Polish

Image
 Author: Yashwant Patel The main thing that our game was missing in the last week was polish on certain things. One of the largest thing that we were missing was replacing the placeholder with final UI assets. This would make the game feel more complete and the player would appreciate the game with a finished UI. Since I was working on UI I had an advantage, because I didn't have to go around searching for UI packs since finding assets that you exactly want can be hard. Instead I mostly made everything from scratch with the exception of some elements that I got from freepik.com  and modified them to what we needed. The main challenge I faced with the UI was getting everything how I liked. I didn't really use Unreal's tools for UI before in terms of properly structuring the hierarchy for UI elements and properly wrapping everything to have it behave how you want it to, so this took a day to get used to. Another thing that needed to be done was reprogram the UI since the old ...
Read more

AI Navigation Problems - Yashwant Patel

Image
Problem In Island Defenders we want our AI to go down a lane to reach the core. Ideally the AI should navigate through the lane in a way where they don't cut corners to try and optimize the path they take in order to reach the Island Core. The path finding algorithm is implemented in a way to have the AI reach the destination using the quickest path while keeping obstacles in mind. For most games this would make for good AI, since you want AI to take the most efficient path. In our case we want the AI to always be in the center of the lane even if that path is not the most optimal. This wouldn't affect the user's gameplay physically, but it would seem like an odd behavior to have AI cutting corners in a game like this. For example, if you have a racing game and the AI cuts through the middle of the map in order to go from one point to another it wouldn't make sense. Even though that is the most optimal path in terms of pathfinding it's not the correct path. This is ...
Read more

Round End Cutscene Implementation

Image
 Author: Yashwant Patel Problem: Before the very first round and in between each round the player has access to the upgrade system where they can spend the currency they earn to purchase upgrades. Currently the player has no idea about the upgrades since they aren't told about them. One thing that can help mitigate this problem is to have a "cutscene" at the end of each round that shows a ship arriving with supplies (upgrades). This would help mitigate the main problem and it also solves the mystery of where the upgrades are arriving from. The objective is clear, but how should it be executed? Could use Unreal's level sequencer to make an animation and then render it and play the video once the round ends. Another way would be to have a "dynamic cutscene". Sounds fancy, but what does this mean? Essentially it means that each round end cutscene would be unique. How can that be accomplished and why attempt it in the first place? The main problem with setting u...
Read more