This course is all about starting to learn how to develop video games using the C# programming language and the Unity game engine on Windows or Mac. Why use C# and Unity instead of some other language and game engine? Well, C# is a really good language for learning how to program and then programming professionally. Also, the Unity game engine is very popular with indie game developers; Unity games were downloaded 16,000,000,000 times in 2016! Finally, C# is one of the programming languages you can use in the Unity environment. This course doesn't assume you have any previous programming experience. Don't worry if you've never written code before; we'll start at the very beginning and work our way up to building small games by the end of the course. Throughout the course you'll learn core programming concepts that apply to lots of programming languages, including C#, and you'll also learn how to apply those concepts when you develop games. Computer programming is really fun in general, and programming games is even better! Caution: Beginning (assuming no prior programming knowledge) is not the same as easy (not hard to do). Learning to program IS hard to do, especially since this course is essentially the first half of a freshman-level college course. Meeting the course challenges while you master the material will be rewarding to you, but doing that will require hard work and maybe even a few expletives along the way. Module 1: Write your first C# console application and Unity script and learn how we store data in our programs Module 2: Learn how we use classes and objects to implement our code Module 3: Learn the basics of Unity 2D games and discover how we make decisions in our code Module 4: Get and use player input in your Unity games Module 5: Complete final peer review and take "Final Exam" “Unity” is a trademark or registered trademark of Unity Technologies or its affiliates in the U.S. and elsewhere. This course is an independent work and is not sponsored by, authorized by, or affiliated with Unity Technologies or its affiliates
Keyboard Processing
Loading...
From the course by University of Colorado System
Introduction to C# Programming and Unity
396 ratings
University of Colorado System
396 ratings
Course 1 of 5 in the Specialization C# Programming for Unity Game Development
From the lesson
Unity Input
In this module, you'll learn how we can process user input in our Unity games.
Meet the Instructors
Dr. Tim "Dr. T" ChamillardAssociate Professor
Computer Science
In the previous lecture, we finished doing our mouse input processing in Unity.
So, in this lecture, we're going to move on to using the keyboard for
input in our Unity games.
Before we do, you should take an in-video quiz about using the keyboard for
game input in Unity.
And now we can go to Unity and learn how to do that.
Before we go to the character script to make it use keyboard input
to move the character around, I will point out that, here in the input manager,
we're going to use the horizontal axis and
the vertical axis to drive that input for us.
Okay, now we can go to the script.
So here, in the update method, remember we used
to just convert our position to be the same as the mouse position.
But we can't really do that anymore,
because there's not a keyboard position that we can retrieve.
Instead, we should think about this as pushing the game object around,
by reading the inputs and
moving the character a certain amount based on those inputs.
What that means is we should have a constant up here to
support the movement.
And I'll just call it, movement support.
So this is a constant.
It'll make it a float, and I'll say this is, MoveUnitsPerSecond.
So this will really end up being the speed, but I will take a guess and
I'll say 5, and we'll see if that works out for us.
Back in update, we're not going to convert mouse position to world position anymore,
so let me do a few changes here.
We'll get rid of this And I'll say, move based on input.
And I'll also say here, move to new position.
Let's actually start with that position local variable that I just deleted.
Except, this time, we'll set it to, transform.position,
the current position of the character.
Now, we're going to check for input on the horizontal input axis.
So, if Input.GetAxis,
Except, this time, we're checking the horizontal input axis, Is not equal to 0.
So, remember when we were changing characters,
we checked to see if it was greater than 0.
But now that we have both positive and
negative mappings to this input access, we want to check not equal to 0.
And using the keyboard, it's essentially going to be either negative 1, 0, or 1.
So I know I need to change the x component of position for horizontal input.
And, now, I've just realized I need this again.
So instead of calling the method again,
I'm going to store that in a local variable.
So I will call it horizontalInput, And
I will set it equal to this.
And then, my Boolean expression, we'll use horizontalInput instead.
So this is your standard time-space trade-off.
I am saving a little bit of time because I'm only calling this method once, but
I am using a little extra space because I
have an additional variable that I've decided to declare.
Now, because horizontal input will be negative for
left input and positive for right input,
I can essentially treat it as the sign for how I want to change my position.x.
So I'm actually going to change this to say +=.
So I'm going to add some amount to my current position in x.
And the first thing will be the sign.
So, not trigonometry sign, right?
Sign, positive or negative.
So, I will multiply that by MoveUnitsPerSecond.
And now I need to know how many seconds have elapsed since I last moved,
based on input.
And, Time.deltaTime tells us how long the previous frame took to execute.
So we're going to multiply positive or negative times how far we
move in a second, times how many seconds the previous frame took to execute.
And that tells us the new position.
I'm going to do all the same stuff for vertical input.
So I'll come back once I've typed that all in.
Okay, so
this should look really familiar based on what we did with horizontal input.
I have a vertical input local variable that I'm setting to getting the vertical
input axis.
I check to see if that's not zero, and
if it's not, I modify y based on the verticalInput,
times MoveUnitsPerSecond, times how much time the previous frame took to execute.
Notice this is not an else/if, because, if I made this an else/if,
I couldn't respond to both vertical and horizontal input in the same frame.
And users like to move diagonally sometimes.
We'll actually talking about an issue with that once we go back and run the code.
And, in fact, let's go do that now in the editor.
So, now, when I run my game, You can't see this,
but I'm actually moving my character using the up and down keys.
And I will point out that, if I do go diagonally,
you may not be able to notice this watching the video, but
I'm actually moving faster than those five move units per second.
And this is actually a very famous bug from, Doom, called the Strafe 40 bug,
so we can actually look at the code to see why this is happening.
If I have inputs on both the horizontal axis and the vertical axis,
then I'm not actually moving five units per second.
I'm moving five times square root of two per second.
And that's just from the Pythagorean theorem.
So there are certainly ways to fix our Strafe 40 bug,
but we're not going to fix it.
Okay, the other thing that we need to change is changing the character
based on ChangeCharacter input.
Let's go back to the editor to do that.
So, remember, our ChangeCharacter input access has a Positive Button, mouse 0.
And we don't have an Alt Positive Button yet, so we can just add one.
Let's make it the space bar, so
that we can change the character by pressing the space bar.
When I run the game, here's the character,
and when I press, space, the character changes.
You [LAUGH] can't tell I'm pressing, space, so you'll have to trust me.
But that's how it's working, so this is pretty awesome.
We can change character, responding to keyboard input,
without even having to touch the script code at all.
We just changed the mapping in the input axis.
And that's it.
Now we've converted from our mouse input to our keyboard input.
Of course, I can still change the character with the left mouse button
here if I wanted.
But if I wanted to get rid of that, I could just make the positive button,
space, and make this one blank.
And then it would only respond to keyboard input.
But there's no need to do that.
We've done our conversion, so
we can do everything with the keyboard instead of the mouse.
To recap, in this lecture, we learned how to process keyboard input
in our Unity games, particularly using named input axes.
And we didn't even have to make any script changes at all
when we wanted to change the character by using a key.
Because all we needed to do was use the input manager to change
the characteristics of that input axis instead.
Explore our Catalog
Join for free and get personalized recommendations, updates and offers.
Coursera provides universal access to the world’s best education,
partnering with top universities and organizations to offer courses online.
© 2019 Coursera Inc. All rights reserved.
