Hi everybody welcome to another edition of the hangout on air for Front-End Nanodegree.
Today i'm joined with Mike Wales and I'm Jonathan Mavroudis.
Today we're going to talk about project three which Mike Wales
actually put together for everybody.
And we hope you can enjoying it so far.
We wanted to talk a little bit about like our expectations.
And sort of what the minimum requirements for the project are.
>> Mm-hm.
>> So as you can see here when we load up the game.
We have our little player character.
Starting in the middle of the grass and he can realistically start anywhere.
>> He can start anywhere, yeah.
>> Yeah.
So the minimum requirements we usually ask for
is first of all that the little guy can move around.
This is using the direction keys.
And that functionality's pretty much already built in.
The key handling is already put in.
You just have to, kind of watch, for
the key handling and adjust the data of your player.
So that whenever it draws, it draws in a new position.
There are player should be sort of confined in that window.
Right. So if I kind of move my player.
I can't go any further right even though I'm mashing right,
I can't go any further left.
Even though I'm mashing left and if he happens to fall off the window.
Then he's kind of not on the game.
Right. So, we want to try to
avoid things like this where the player can just sort of step out of bounds.
And then, the second thing is that the bugs move across the screen.
So, here we got a bunch of bugs flying across the screen at different speeds.
And these are the vehicles.
>> The bad guys [LAUGH].
>> The bad guys, yeah. That's what you got to try to avoid.
So, we can see that there is just this constant stream of bugs.
So, let's kind of recap those three things real quick.
Player moves.
Bugs move.
And player doesn't fall off the screen.
>> Mm-hm.
>> The fourth piece of functionality we're looking for
which you probably just saw.
[LAUGH] Is if I happen to get hit by one of these bugs.
Here no I fall the way back to the beginning.
>> Yep.
>> The last little piece of functionality is sort of
winning the game in a sense.
And that's if I'm able to get all the way across the road.
And again we've not hit anything here.
I get across it recessed the game as well.
>> Which is acceptable.
You can go as crazy as you want with this project.
>> Yeah. >> This is the minimum viable passing
product project.
>> So then the next thing we have is sort of the criteria called object
oriented code.
Let's talk a little bit about that.
So the whole course this is built off of
is the object-oriented JavaScript course.
>> Right. >> Can we go into a little detail about
what we mean by object-oriented, and sort of how that differs from
maybe some of the programming people are familiar with?
>> Yeah, so object-oriented programming,
particularly in JavaScript, is whenever you write what we call a class.
And so in JavaScript we really don't have classes, but we kind of fake it.
A class in JavaScript is any structure that can
create a fleet of objects that are similar in nature.
So your bugs for instance you have three different bugs.
There's really no point in having to write this out three different times.
>> Mm-hm. >> You just create
the general structure that defines a bug.
And then you instantiate that object a few times.
One of the biggest things we're looking for
is using the prototype object correctly.
You don't want to define your render and
update functions on every single object on the screen.
You want that type of functionality to be on the class.
That instantiates the objects.
So then the last three sections in
the rubric I think should be pretty straightforward.
Code quality, we're just asking that you
kind of adhere to the style guide we provide you.
You format your code, it's easy to read.
I think that's sort of the biggest point is that if you were to give
this to your mom, who doesn't know any JavaScript,
she'd at least be able to look at it like.
Be able to point out like you know long lines yeah.
>> Like this makes sense.
>> Yeah.
Just be consistent, we've had some questions are going like spaces
do I use more spaces to spaces or use tabs.
Just be consistent with your spacing and your the way you lay things out.
And like you said, we want it to be readable by our coaches and
not just one line string of symbols.
>> Then the next one is comments.
I think comments should be
pretty common practice in any sort of programming you do.
Even with HTML,
leaving comments in to just say this is what sort of this section is for.
Comments are just sort of a programmer to programmer way of communicating.
>> Exactly, so you don't want to have a comment that says like draw the book.
Because it's pretty obvious that that line is drawing the book.
Comments are really good for
answering the question of why am I doing something this way.
It really is programmer to programmer talk.
Ten years down the road when you move on to a new company and
some guy takes over your application.
You want to leave enough comments that
he doesn't want to track you down and kill you.
>> Yeah [LAUGH].
>> [LAUGH].
>> The last one, documentation.
Where we asked the students to provide us a read me file.
I'd say that's more just so you get into the habit of writing sort of a read me.
>> Mm-hm.
>> Write this is if you were sending this game
to a friend didn't want to be able to show it to them.
>> Yeah.
>> And especially if you really go above and beyond.
Kind of make this game your own.
A little bit of a read me at some of the additions you added.
>> Mm-hm. >> How you did them.
That would all be really, really great.
I mean as documentative as you can make your project.
The better it's going to look.
>> Yeah.