So now that we have set up our basic camera and screen resolution, let's go right into the demonstration of prototyping a game idea in Unity. Bear in mind that what you are going to see here is very rough. It is going to be a rough demonstration of the basic workflow and process of working in Unity. Don't expect to understand any of the code that you are seeing at this point at the fundamental level. Eventually everything will be explained, but at this point don't worry about taking notes or anything like that or trying to get exactly what is happening in this video. Just follow along and preferably write the code out on your end at the same time.
First thing we are going to want to do here in Unity, is click on our cube game object and we are going to want to make the cube a little smaller. Let's set the scale for X to .5 and Y to .5, and why not just move the cube a little more in a better place in our game world scene here. Okay, so a good start is to find a way to move our cube here. It will be our Player 1 character of sorts. In order to do that, add a component by clicking on "add component". Select new script, and let's call it "Cube Controller". Then click "create and add". Double click it to open it up into Visual Studio. Alright, and there is our script.
Now let's write some code. Preferably write this on your own end. Exactly as you see here. This will be responsible for reading the input from your keyboard and translating it into a movement of our Player 1 character square. I will just copy and paste this to make it a little quicker. Should be "RightArrow"", UpArrow", and "DownArrow". This will be "+=", "y =", "y +=". Alright, and actually one more thing "equals move." Save that. Either file, save or ‘Ctrl’+’S’. Then, go back in Unity and press "play", and if we have no errors ...Looks like I ...Alright, so there we go. We are moving Cube, although it looks like I made a bit of a mistake and I reversed the Y-inputs, so this should be "+=" and "-=". Save that, go back to Unity, restart the game, and there we go. We have got our little Cube character moving around the screen. Alright, so hopefully that worked fine on your end. We don't want to create a scrolling scene. That is just a little bit too complicated at this point. It will be just a fixed camera point.
Our next problem to solve, as you may have noticed there, is to constrain the movement within the boundaries of the screen. As you can see here, when you click on "cube", the transform position of the cube can go off the screen, so by looking at the values for the x position that shows right where it is at the edge of the screen, you can get some hint as to what number you need to constrain this value. -6.2 or so and of course on the opposite side it would be +6.2, positive. For the y coordinates, it will be about 3.2, 3.3 minus and plus there as well. That will give us some idea as to how to go about constraining our movements.
Let's go back to our controller script and write some more code to represent that constraint. Back here at the top, let's make a couple more variables. Let's make it 3.4. (Start at 6:34) We don't have to be too precise, and let's put this in another update method called "LateUpdate". Let's put a little comment so we remember what this is all about. If we are at...Put x, CamWidthX * 1. Let's Move.x = CamWidthX * 1. And the y coordinates. I keep hitting that wrong key. I am sure I will learn eventually. Yay, I learned this time, what do you know? "Equals move". Alright, so save that and go back to Unity, press play. Now we shouldn't be able to go past the edges of the screen. Great. Once again, don't worry about the code. I will explain it in more detail later, but I am just trying to give you a sense of how easy it is to start prototyping a game in Unity.
We already have a character that is moving around and is constrained by the screen. You have almost like an arena of sorts. That is a pretty good start. I guess now, a good idea would be to try to create some sort of enemy. It is not really much of a game without an enemy. In order to do that, I am going to move my cube somewhere in the scene. In order to do that, let's think of a good enemy. I guess a cube has right angles and has got straight edges, the natural enemy of the cube must be the sphere, so let's choose a sphere. You will see we have a default game object called sphere here by going to "game object", "3D object", and "sphere". Let's make it about the same size as the square here, or cube, however you want to look at it. We will do something very similar. We will try to get the enemy here to move just like we did with our square, Player 1. Create a new script called "Sphere Controller" and create and add. Let's open that up in Visual Studio. Whenever it asks you to reload, Visual Studio refreshed with the new information being sent from Unity. Hit "reload". There's our sphere controller.
I guess the easiest thing we could do here is try to find a way to get the sphere to take the position of our Player 1 character and try to just run towards you, you know? Basically like a homing missile running right straight for you. Let's write something that would represent that. Zero point...We are going to make it a little bit slower just to make it kind of fair, slower than our Player 1. This is going to hold a reference to our Player 1 character here. Then the update method we are going to comment. You know what, that variable is just a little bit too long for my taste. I am just going to make it like that. Form that position. transform.position = Vector3.MoveTowards(transform)
Alright, so now when we play our game again, our sphere should be able to track our Player 1 square. Sure enough, we are being tracked, but look at that. We are actually...Not much of a game because our enemy can't really do anything to us. He can just infinitely chase us down, so that will probably be the next thing we do which is take our enemy and create some sort of attack or something of that nature. Let's go back to our script for our enemy sphere. Let's do this by determining how close we are to our square Player 1, how close the enemy is to the square. If it determines that it is pretty much right over the top, then basically it eats the square and it is game over. Let's represent that with the following code.
Make a variable called "Distance", and in the update method, make a comment. Equals ‘transform.position.x’. Take away CubeRefPosition.x. What we are doing is we are taking the position of our sphere enemy and subtracting it from the position of our Player 1 square. If that value is within a range, then we can safely say that they are pretty much occupying the same space. If that's the case, "Game over, square. You're going to be eaten". Let's write that out. Express that with the following code. First, comment it. There are going to be a lot of checks that we are going to make here. Unfortunately, it is going to look a little sloppy, but that is okay, we are just prototyping. When you are prototyping, you don't have to be making anything too pretty and impressive as long as it works. As long as it is within this range between less than .1 and greater than -.1 for the x value, and we are going to have to do the same for y. If we are going parentheses crazy, we might as well go full on and make it just a little bit more pleasing or ugly depending on your opinion.
Now that we have that condition, basically checking to see if they are occupying the same space, let's do this. Destroy, pretty self-explanatory, I think, CubeReference, our Player 1 character.The easiest way we can make a message that tells us we have been eaten is to just say, "You have been eaten" for the console. You will see that when we run this. Alright, so let's run that and test it out. Save that, go back to Unity, and there we go. You don't see the message because... Make sure you select for the notifications here or else you will just see that message being spit out constantly. As you can see here, we have been eaten. Let me just run that again so you can see. There is no sleight of hand. Not eaten, eaten. Game over.
Alright so that is kind of awesome. We can be eaten now, but really this thing can go on forever as the challenge never really ratchets up. We should end the video here right now, but in the next video, we should probably look into how we can make it a little bit more of a challenge. You know, you can't completely run away from our little sphere enemy forever, so we will do exactly that in the next video, and I will see you there. Thanks.
Lesson 5 - Prototype Workflow