Peter Eldredge PPJ #2

Input Changes/Experimentation - 3 Hours
Group meeting about the project and tasks - 2 Hours
Game Design Document Help and Sell Pitch Help - 4 Hours

New Input Type


This week my main goal ended up being a refactor of the ship controller as well as the implementation of the new Mouse Control Scheme. I started by streamlining the options so they would be more compatible with an options menu, but currently the options are tied to inspector and keyboard inputs.

One of the biggest improvements in the refactor is that the actual inputs have been abstracted away from direct player movement. By doing this, we can now take input in unity's Update() as opposed to FixedUpdate(), which is where the movement actually occurs, leading to more responsive controls. It also allows us to set the input calculation as a delegate. This means that we can simply swap calculations from Mouse to Keyboard at runtime without side effects, even though their calculations are very different.


This is our Update() function currently. The direct look at specific keys is for the sake of testing and rapid development, but the overall functionality is extensible. When T is pressed, we swap the mouse movement variable and then call SetInputType(). This function determines the input type that will be used during the update function, and sets the delegate for the _inputCalculation accordingly. At the end of the update, that calculation is then used to set the Pitch and Roll.

Keyboard Calculation

The Keyboard Calculation is very basic, we just set the pitch equal to the vertical axis with smoothing (not raw) and then multiply it by the _invertYControl, which will either flip the sign or not depending on if inversion is set. The roll is literally just the smoothed horizontal axis.

Mouse Calculation

The mouse calculation is a fair bit more involved than the Keyboard. This is because we are in essence creating a virtual joystick from the starting location of the mouse. Because of this approach, we need to keep track of the distance the mouse is from the center of the joystick. This is tracked in the _xMousePosition and _yMousePosition members accordingly. Each Frame, they are updated with the distance the mouse traveled, divided by 100 to adjust the scale of the movement, multiplied by the appropriate sensitivity and inversion control. Then the absolute value of the mouse position is taken and compared against the deadzone. If that value is smaller than the deadzone, then the movement is 0 on that axis. Otherwise, we subtract out the deadzone distance (to allow for fine adjustments just outside the deadzone region) and set that equal to the corresponding movement variable, Pitch or Roll.

For added comfort, if you lost your center you can always reset the center of the virtual joystick by hitting Spacebar. This calls the ResetVirtualJoystick() function, which simply resets the _xMousePosition and _yMousePotition, creating a new origin.

Input Findings

 Something that became very clear however, is that controller input is vastly superior in this case to the mouse and keyboard support. Even with the new customization and hours of experimentation, I was unable to make any keyboard or mouse controls feel nearly as good as a controller. I will leave in all the options and possibly expand upon them, as not everyone has a gamepad, but it is clear that is the best way to play.

Documentation

 I worked primarily on the aspects relating to controls, technical specifications, and enemy specifications in the GDD. Additionally I gave input on several sections that Jake wrote, and we updated the Sales Pitch together.

Group Positives

It seems like we are going to get the requirements for the presentations and documentation done.

Group Negatives

 This week we had the same issue as last. Meeting too late and not enough communication. This ended up leading to Jake doing the lions share of the documentation and not having the time to work on the game. Because of this, I ended up having to look into the input system, instead of continuing work on the enemy framework, and we are still in the same spot as we were last week. Finishing work on Thursday morning, something that I wanted to avoid. Additionally, the lack of communication means that we don't know what exactly everyone has been working on and how their parts are coming along. Overall, this was not a great week productivity wise, and I am glad Jake stepped up for the documentation, or I don't know how we would have gotten it done.

Upcoming

I am hoping next week I will be able to get back to the enemy framework, and am planning on doing all the stuff I was hoping to get done with it this week. This is what I said last week:

The Enemy Framework is going to get Movement Behaviors just like the Attack Behaviors, and this will function primarily as the game's AI. Additionally other types of attacks will need to be added as well as a damaging/destruction system for when the player destroys them. Overall a lot of components are missing, but they depend on what we decide for the design of the game and we have a good base to build from.

This still generally holds true, although we came up with some basic movements and some more attacks that I should be able to implement. Hopefully I will also be able to get some artwork for the enemies that I can implement.


Comments

Post a Comment

Popular posts from this blog

Image
Jacob Dixey, PPJ#3 Playtest Survey Draft  - 2 hours 2nd Scrum Presentation - 1 hour Camera Improvements - 1 hour Spinning Action - 1.5 hours COM-Buster Takeoff - 1 hour Pause Gameplay - 1 hour Bouncing - 1 hour Tweaking - 2 hours Samples Spinning and Bouncing Scrum Presentation Pause Menu Positive: The level's visual style came together really well, in addition to many of the core mechanics surrounding flying being solidified with a lot of time put into tweaking it for playtesting. Our meetings have also given us a lot of good ideas for how we can communicate the different states of the player visually, such as heating up changing a shader on the COM-Buster and its trail, and when Overheating causing a fiery effect on the screen that slightly gets in the way of your peripheral vision. Negative:  It was another week of getting things together last minute. I want us to start meeting up earlier (say, Saturday) and then using Monday (or u...
Read more

Getting Started: In the Cloud(s) Sean McFadden Summary (PPJ #01)

Image
This week was spent doing two main things, both seemingly involving clouds. The first was getting our project website setup. I don't think we need anything fancy yet, so it consists of a basic standard website hosted on an S3 instance. I added some nice features like logging and view counting just so we can monitor exposure in the future. The website is really bare bones at the moment, pretty much consisting of only a few lines of text and some empty web pages. I plan on adding some more styling and media over the coming weeks, as we don't have much in terms of presentable media at the moment. However it is important to have a good framework for a modifiable website at the moment, as it can ease the process as the game grows. If you want, you can visit the website below!  oilandcorditegame.com Additionally, I spent a big chunk of time researching and planning the implementation of our clouds system. Since the game world has a massive layer of clouds below the player, ...
Read more

Peter Eldredge PPJ #1

Image
Set up the Unity Project and GitHub, adding some of my useful Scripts - 1 Hour Group meeting about the project and tasks - 2 Hours Conceptualized and implemented a modular enemy framework - 3 Hours Helped Jake with programming the player controller (primarily the physics) - 3 Hours Final setup for the demo/build - 1 Hour Enemy Example Enemy Framework Example The behavior above was made just by tweaking some values on prefabs and scriptable objects. The idea is that this will be expanded throughout the course and we can have an easy way to create new enemies. The behavior system can also be expanded to movement patters and a health system/weak points. Here are some inspector tabs to demonstrate how the behavior was achieved. The scriptable object is the attack behavior. It controls the conditions for the attack to fire as well as the prefab which handles the attack itself. In this case, it simply instantiates the FastLaser prefab. The condition that must be met are that...
Read more