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
個評分
從本節課中
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 gain.
So we've created an Asterax Requirements document
that describes the game in a general sense,
it describes all the mechanics and sort of
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.
And 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,
talks about the overall goal of the game,
it's got a screenshot of what we want the game to look like,
and then core mechanics.
How does the player ship work?
How does firing work?
How do the asteroids work?
And 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 screens that will pop up that are not part of
the core gameplay 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 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 and what are they going to be called?
And then what will the pop-up look like when we
have those achievements occur so that the player knows they've gotten one?
And then unity analytics.
What are we going to be tracking with Unity analytics,
and as part of that what remote settings 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?
And 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 for tourettes 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 and 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 and 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 Game Manager that manages the overall game and 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 panel game over
that would have a final score and a replay button and then in the middle is
the panel level which is the actual Heads Up
Display GUI that you see when you're playing the game and 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 game level layout class and this takes
the level layout information that's stored in the Game Manager and then turns it
into an actual level it actually builds out the level by instantiating
lots of children including power pellets and point pellets.
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 power pellet and the point pellet 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 power pellet 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 GhostScript 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-alike or other 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.
And then finally we have Pac-Man himself.
So Pac-Man moves around, handles animation, death,
responding that 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 surf 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 power pellet
the point pellet Pac-Man and the ghost denotes that
these objects will be instantiated by
their parent class which will be the game level layout and all of those cases.
And 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,
all those boxes are stacked together and 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 and that's active only during some game states,
this is something that I also use on asterax and that just makes
say the panel intro in the panel GameOver inactive when they are not being used.
And then screen wrap both Pac-Man 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 scriptable object.
And then the final thing is just this challenge will be self-evaluated,
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.
