Welcome to Core Interaction Programming, the first course in the Unity Certified Programmer Specialization from Unity Technologies. This course will help you prepare for the Unity Certified Programmer exam, the professional certification for entry to mid-level Unity programmers. Unity is used to create real-time 3D applications for many industries, including video games, automotive, film, training, and more. In this course, you will be challenged to solve realistic Unity programming problems that are aligned to topics covered on the exam. Throughout the first course, you will build the foundation for a 2D action video game: AsteraX. In doing so, you will practice many of the skills covered in the exam, including evaluating scripting needs from a project requirements document, implementing the three "C's" of an interactive applications (Character, Controls, Camera), providing user feedback through basic UI elements, and applying professional programming practices like developer testing. This is an intermediate course, intended for people who are ready for their first paying roles as Unity programmers, or enthusiasts who would like to verify their skills against a professional standard. To succeed, you should have at least 1-2 years of experience programming interactive applications in Unity. You should be proficient at programming in the C# language and familiar with Unity's scripting APIs. You should have experience in the full product development lifecycle, from concept to launch (and beyond). And you should understand multi-platform development, including deploying applications to XR (AR and VR) platforms.
Challenge 1 | Scripting Needs
Loading...
來自 Unity 的課程
Core Interaction Programming
59 個評分
Explore Related Videos
At Coursera, you will find the best lectures in the world. Here are some of our personalized recommendations for you
從本節課中
Evaluating Project Requirements
For the first part of the course, you'll get an introduction to the course and its Challenge/Solution format, then launch right into planning out the code architecture for the AsteraX game project.
與講師見面
Jeremy Gibson Bond
Unity Technologies
Hi everyone. I'm Jeremy Gibson Bond and welcome back to
the Unity Certified Programmer exam preparation course.
This video is going to present you with
your very first challenge and this we're calling a scripting needs challenge.
So, one of the most important things that you do as a programmer,
is look at an overall description of a project and then break that down into
the classes and components that you think you will need to
create in order to implement that project or game.
So, we've created an AsteraX requirements document
that describes the game in a general sense.
It describes all the mechanics and gives you an idea of what you're going to be creating.
Let's take a look at it now.
Here's our requirements document, it's a PDF.
Now this is not a design document.
Design documents are these massive files that have every little nuance to the game.
This is a requirements document which is something I used
a lot at Electronic Arts when I worked there,
and I use a lot in my personal work.
It just gathers together the core ideas of what you have to
have in the game for it to be complete enough for people to look at.
So, here's the Design Goal,
it talks about the overall goal of the game,
it's got a screenshot of what we want the game to look like.
Then, Core Mechanics.
How does the player ship work?
How does firing work?
How do the Asteroids work?
Here's a shot describing how the Asteroids are structured
together with one core Asteroid that has
two smaller children and each one of those have two smaller children.
How does screen wrapping work,
which is a core element of the code for this game?
Level completion and game over various other game features like interstitial screens.
These are screens that will pop-up,
that are not part of the core game-play but are
important to know about and you can see them laid out here.
In a normal requirements doc,
these screens would be concept pieces.
But here because we have the ability of
hindsight of having made the game already for you,
you're seeing the final versions from the end of course two.
Achievements. What kind of Achievements are we going to have in the game?
What are they going to be called?
Then, what will the pop-up look like when we have
those Achievements occur so that the player knows they've gotten one?
Then, Unity Analytics.
What are we going to be tracking with Unity Analytics,
and as part of that,
what remote settings where will we be enabling?
Remote settings allow you to change something on
the Unity Analytic site and have it be pushed out to your game live in the field,
so you can tweak things like the difficulty of various levels and things like that.
The pause button. How will the pause button work?
Then finally, the customization panel.
This is something that pops-up when you pause the game and it allows
players to choose between four bodies and four turrets for their ship.
These don't have any change in gameplay,
but allows us to play around with some fun things like having
achievements unlock these different body parts.
So, you're going to take this requirements doc and you're going to use it to
create what we're calling a components and classes diagram.
So, this example here is from a simplified version of the game Pac-Man.
You can see here that I've created a micro requirements doc to serve
cover what parts of Pac-Man we're going to be implementing in this diagram.
For example, there's no fruit,
the Ghosts don't have different AI, things like that.
But here is the actual diagram itself.
This is not a formal type of diagram.
So, this is not something that you should know exactly how to make already,
this is just my version of this that I would use if I were working with you on something,
and I wanted to explain to you how I wanted to structure the code.
You can see here at the top,
there's the GameManager that manages the overall game,
that keeps track of the state, and the score,
and the number of lives that Pac-Man has left and level layout data.
Then there are served three panels that are
UI panels below this that would appear at different times in the game.
One is the intro panel,
which is just it would have the title of the game and a start button.
Another is the Game Over panel or the PanelGameOver,
that would have a final score and a replay button.
Then in the middle is the PanelLevel which is the actual In
a replay button and then you see when you're playing the game.
That includes things like the lives and the score
which both reference back to the Game Manager to get that data.
Then I've got the GameLevelLayout class,
and this takes the level layout information that's stored in
the GameManager and then turns it into an actual level.
It actually builds out the level by instantiating lots of
children including PowerPellets and PointPellets.
Now of course things like the walls and the hallways are part of this game level layout,
but they don't really have their own class associated with them,
because they're basically just dumb game objects.
However, the PowerPellet and the PointPellet need to have their own scripts
because they change the score when they get picked up in the case of both of them,
or in the case of the PowerPellet they actually
empower Pac-Man to chase after the Ghosts.
Speaking of Ghosts, Ghosts are instantiated as well.
There's going to be four of them,
and each Ghost has its Ghost Script plus a Ghost AI script
and the Ghosts are going to pull from a Ghost scriptable object that we've
created to allow someone like a designer or an artist to
come in and make changes to what the Ghosts look like or
other sorts of data about the Ghost they're very simple
and then those can be incorporated into the script or
without the designer or the artist having
to really get into the Code with you as the programmer.
Then finally, we have PacMan himself.
So, PacMan moves around, handles animation,
death responding that kind of stuff,
and it pulls from the standard Unity input class.
There's a note here that we could for
things like Pac-Man and the Ghost actually implement,
the Model View Controller pattern from the gang of fours, programming patterns.
But that's not entirely necessary and certainly not in this diagram.
Down here there's some notes at the bottom and you can see a solid line
denotes a parent-child relationship in the Hierarchy pane inside of Unity,
and a solid line with a semicircle like you can
see with the PowerPellet, the PointPellet, PacMan,
and the Ghost denotes that these objects will be instantiated by their parent class,
which will be the game level layout in all of those cases.
Then finally, a gray arrow is going to show you data passing back and forth.
Boxes stacked together are part of the same game objects so for the Ghost for example.
The Ghost and the Ghost AI are both on the same game objects,
so all those boxes are stacked together.
Then you can see at the bottom here I've got
a list of two components that are on lots of different game objects.
So, I've come up with just like a little,
smaller version of the name for them.
That's active only during some game states,
this is something that I also use in AsteraX.
That just makes say like the PanelIntro in
the PanelGameOver inactive when they are not being used.
Then screen wrap.
Both PacMan and the Ghost can wrap around the screen.
So, I've created a screen wrap component that can be applied to either of them.
So, now that you've seen my personal example of this component and classes diagram,
let me give you a couple of tips for you to think about as you're
making your version for AsteraX.
One is, anytime you have a shared behavior
across multiple different game objects or types of game objects,
for instance, the screen wrap,
think about combining it into a component can be used across all of
them so you don't have to repeat that code in multiple different classes.
Another is that scriptable objects are
a fantastic way to allow non-programmers to modify your gain,
and so in places that you might want to non-programmer to be able to edit something,
think about using a scriptural object.
Then, the final thing is just this challenge will be self-evaluate.
We're not going to have you pass this off to somebody else to
test and we're not going to say it's completely wrong if it's not exactly what I did.
This is just a way for you to think ahead of
time about the code that you're going to be creating.
So, that's it. I'm Jeremy Bond again,
and thank you so much for watching this video.
