Build 1 - Player Movement & Scene Layout

This week work  commenced on the top-down player movement and a basic level layout for GCD.

The current development build of the game includes a simple 8 direction movement system which utilises WASD and the arrow keys as the input system. The character also rotates to face the direction of the mouse pointer on the screen. This movement system is implemented via the use of two scripts on the player game object, one of the scripts operates the top-down eight-way-movement system (PlayerMovement) and the other makes sure that the player game object is always rotated to face the direction of the mouse (RotateToMouse).

First up I'll talk through the basics of the PlayerMovement script. To detect user input, this script utilises the Input.GetAxisRaw function in Update, which I use with the horizontal and vertical input methods, this essentially picks up the player's use of WS for or the up and down arrow keys for the vertical axis, or AS and the left and right arrow keys for the horizontal axis. From here, the system assigns a value of 1, 0 or -1 to the horizontalMove and verticalMove floats based on the input it detects, if any. The next part of the script was written in the FixedUpdate, this is where I had to implement a diagonal movement speed correction for the two inputs, because without it the movement felt too fast diagonally. To do this I just simply multiplied the horizontalMove and verticalMove by 0.7 if there was input detected in both axis. After this, I assigned the velocity on Rigidbody2D of the player using these movement variables, multiplying them with a changeable player movement speed variable. That's pretty much it for the movment apart from one more issue that came about due to an issue with angular velocity imparted on the player when it collides with other objects. Essentially the player would slide across the screen slowly with an angular velocity, to fix this, I just made sure the angular velocity was set to 0 at the end of each FixedUpdate call.

The other compnent that makes up my movement system is the player rotation which is managed by a rather simple implementation in the RotateToMouse script. This script takes the screen position of the mouse pointer and converts it to world position, with a correction to put it further forwards than it really is to fix an origin issue if it's right on the origin. From here, I determine the angle between the player and the mouse pointer using Mathf.Atan2 and then I simply adjust the z rotation of the player transform using the value via the Quaternion.Euler function.

The game scene has also seen a somewhat finished implementation with the use of tilemaps. The tile map uses the SciFi TDS Kit by AveryRe. The wall collision is  in-place too (excluding the bounds at either end of the map). This will be the discussion of the next devlog though.

Game Scene:

So, the game scene is implemented as follows, the brown (dirt) areas are navigable by the player and eventually the enemies too. The yellow caution marked pads are where turret mount points will be located and the grey looking area is high ground that can't be walked on by the player or enemies. The enemies will come from either of the right hand side entry points and try to make their way to the left hand side exit points.

Movement Demonstration:

I received feedback on the movement system during some play-testing and it was overwhelmingly positive. It was said that it "looks and feels good" with a "good speed" and it "feels nice and clean".  The collision system was liked as well, in that the player's gun can stick over the collidable map details and the rotation feel of the player when up against a wall. The people who tested it couldn't fault the current implementation apart from the fact that the player character can currently walk straight out the ends of the map and the look at mouse system was "almost imperceptibly" sluggish feeling, though they accredited this to the fact they may not be used to the genre. The endzone collider issue is planned to be fixed with colliders placed at the end zones which prevent the player from walking out of the end. The look at mouse script may receive a revision in future to see if it can be made more efficient as well, though I suspect it is a negligible issue that will be hard to fix.

Next up on the development journey will most likely be the player system shooting along with the enemies and an endzone collision system.