Meet Alex. He was the programmer art for our main character in Adeona as were looking for a professional pixel artist to hire. In this post I want to discuss to important aspects to developing games within Unity: MVP and Programmer Art (plus of course how I set up the walking system).
MVP stands for Minimum Viable Product, otherwise known as making the most basic structure of a game in order to see if it has potential to be an entertaining product of work. Games can typically take years to make, and the purpose of an MVP is to make sure you are working toward a product that is actually fun and can become a viable game. If you develop your MVP and the game play is dull or clunky, the rest of your game is going to continue to reflect that as you continue to develop the game (no matter how pretty it looks or how cool the story is). Creating a Minimum Viable Product should be the first step you take in order to see if your game has potential and whether you should invest a lot of man hours into it.
The concept of programmer art continues to support this theory of MVP. When you are creating the core of a game, art doesn't really matter that much... you just want to make it work. This is a trap a lot of people tend to fall into, they spend so much time working on the art and animation for development before they have even begun core development and they see no viable result from the game months later. I fell into this trap into the first couple months of development, as I worked on animation and art before we had even created a base Unity project. This did allow me to have animations when I finally did get around to working in Unity... but I had to scrap a lot of the animations when I realized they didn't look or work as well as I thought in game play. Creating bad-looking programmer art and beginning development immediately leads to a better base for your game, and you can always replace the art later on into development.
Now to get to the dirty technical details of this video. So in Unity 2D, movement is typically handled by a rigidbody physics system that you would put on a game object or prefab. So Alex here has a rigid body attached to him, and a script I wrote grabs this component and sets the velocity of the rigidbody depending on whether the player is telling the character to move or not. In this script, we update the velocity continuously so if the player is not telling it to move it is set to zero. Now we can move this game object, but only in one direction, so we need to create a directional system. Luckily, the velocity is a Vector2 (which is essentially 2 integers of x and y) so to set the direction we simply set the integers to 1 or -1 in the x and y and multiply it by a speed integer. For example, Up would be Vector2(0,1), Left would be Vector2(-1, 0) and so on. Now the game object has the ability to move in four directions and stop.
To actually allow the player to move this game object, we have to check the input (the keyboard) and see if certain keys are being pressed. Although we can do this within the same script, it is better to create a separate script to keep things organized and simply have the scripts access each other. So in this control script you will continuously check for button presses of the keys W, A, S, and D and if one of these keys are pressed, you will set the direction in your movement script to the appropriate direction.
So now we have a game object that you can move in four directions, but it just looks like a creepy lifeless body floating from direction to direction. We need to control and set the animation system, and this will also be a separate view script. This View script will access the game objects Animator and set the direction integers in the animator depending on the information from the Move script. Now, in Unity's Animator you need to pull in the Animations for walking and idling (this is 8 animations total, one for each direction) and create a blend tree for both. Within the blend tree you can have the have the animations switch depending on what the current direction is for x and y. To switch between the idle and walking blend tree you need to set a boolean parameter to check if the player is moving. You can set this parameter from the view script as well. Now you have a little dude that can walk around the screen!
I know those 3 paragraphs were heavily laced with information, and if you are just starting out it may have been a lot to take in. But don't feel discouraged, game development is a lot and I have sure had a hard time figuring this stuff out as well, but I had a lot of help from Unity's community. Youtube tutorials online and Reddit communities like r/gamedev and r/Unity2D offer a lot of resources to help you understand the engine and make progress in your own game. If you have any direct questions about the post or if you are having any problems, feel free to reach out to me and I'll try to help as much as I can.
Thanks for reading the weekly blog post, next one should be uploaded next week!