The Starting Line Of Development: Designing and Programming the Player

Introduction:

In this segment of the blog, I will be going into detail on the starting of development of Midlands and what decisions and design choices were made when engineering the player's design and input instructions 

Basic Level Design

 The first thing I needed was some background images for the test level before I started to program in any features. Using some photos I had taken for reference I opened up pixel studio and set up my graphics place and drew up one panel of the level background images. 

Designing the player and its SpriteSheets

Now that I have the first panel for the level, this allows me to get a basic understanding regarding design approaches and provides a simple level to use to test gameplay mechanics. However, as of right now all I have is a blank, static image sitting in unity which doesn't do much as a 'Video Game'. Therefore, the next logical step and implementation to add was a playable character. I got to work on drawing and designing the main character, I took some burst photos of my friend walking in a straight line and used the frame by frame images to use as references for my drawings. So once more I opened up Pixel Studio and started with Idle a simple 3 frame Idle animation for the player as well as a six-frame run animation onto the same sprite sheet. 

The Player controller Script

Now that I had a sprite sheet for the player, I cut them into individual frames and fed them into unity's built-in animator and saved the two .anim files to come back too, as the player will need some sort of logic added onto it before it can really do anything, Therefore a script with some logical instructions and input would be needed to sew together the animations and inputs from the player, I opened up visual studio and began writing a 2D player controller that I can use across different 2D projects as well as this one. The script looks like this:  

Essentially, this is the script that will hold all of the data we need to make the player actually do something. Right at the start, I log and store a handful of variables and game objects that will be needed, such as movement speed values, jump height values and fall speed values, I also set up a ground check method to ensure the player is on the floor, if this is true, then it allows the player to press spacebar to jump. I could have not implemented this into the script, however its actually really important. If this method checks true, then the player can jump, if the player isn't touching the floor, this method is false, and will not allow the player to jump again while already in the air, without a ground check the payer could jump as much as they like even while already MidAir. Depending on the game and its design, a ground check wouldn't be needed, such as if I wanted to include double jumps or relied on a large amount of jumping to transverse levels such as some platformers such as super meat boy, but for my game, a ground check function is needed. 

As well as this, several other functions await for key input before being called, I mapped the keys to the traditional WSAD format, when either of these keys is pressed, the function will move the GameObjects transform position corresponding to the variable I have set at the start of the script. Depending on which axis the player is facing will also determine whether the flip function must be called when a movement key is pressed, keeping the player's sprite facing the direction they are heading. Finally, within the script, I have also set a handful of animation parameters to be executed with the function that is called. For example, when the player presses A or D to move, we're going to set the animator to play the running animation when the function is called. Otherwise, the player will move on its transform position but remain in its idle position, which isn't what I want.

 Now that the controller was written, I went back into pixel studio and began drawing some more sprite sheets for more animations that were going to be needed, such as jumping, attacking, death and damage, etc. Once again once the spite sheets were complete I cut them into individual frames, made them into .anim files to be used in Unity animator controller, went back into my controller script and set up the parameters in the script before going into the animation controller to plug the parameters and animate the player. Speaking of, once that was complete I opened up Unity animator to hook the logic from our controller script to the animator to switch appropriately from animation to animation. 

 

 Above you see the finished Animator controller, complained by 5 different parameters, meaning there are 5 conditions that if met, will switch from the current animation to said animation. As an example, the orange idle animation is our default animation, meaning that when compile time starts this will be the default animation that starts on the launch, in my case we want to start with the idle animation in the first place so that will be set to default. I have a float parameter called speed, in my player controller script I also have a public int called Speed, the animator and the script will communicate between each other and when this function is called, the speed parameter will recognize when the player's speed is increasing and thus moving us to the idle animation to our run animation which is exactly what I want, however, I had to set up another transition but reversed if one of the movement keys is not being pressed and the player's movement speed has gone back to 0, I want to transition back to the Idle animation so the player isn't constantly running on the spot. Finally, I set up a simple bool called 'isJumping' and as you probably guessed is set to true when the jumping function is called and the ground check is set to false, playing the jump animation when the player is off the ground, and when the player touches the ground and the ground check is set to true the animator will transition us back to idle or the run animation depending if specific parameters are being met or not. Thus giving me the following result:

 

Mechanically the player movement is both responsive with the execution and animation transitions which are exactly what I wanted, in the next segment of the blog I will go into detail of the implementation of the melee combat, enemy logic, and enemy and player health.