Check out a free preview of the full Complete Front-End Project: Build a Game course

The "Wrapping Up" Lesson is part of the full, Complete Front-End Project: Build a Game course featured in this preview video. Here's what you'd learn in this lesson:

Brian wraps up the course, reviews the course material, and gives examples of challenges students can work on to enhance or change the game.


Transcript from the "Wrapping Up" Lesson

>> That's it. You, and I pair coded on a fox game together. And it works. It's, let's say of mild amusement. I don't know if you're gonna be playing this for hours and keeping it alive, but, more power to you if you choose to. Uh-huh. And this is the last milestone, by the way.

This is the code complete game. This is literally the same code that I have running. You can actually see here, code complete game. If you go to the GitHub actions, you can actually see that I have, it automatically deploys the code complete game. So it's actually literally the code that's running, yeah, for this game.

There you go. Yeah, see, it's the same one. Okay, so that's it. That is the the entire fox game. We built it together. There's no more to it. So I just want to wrap up with everything. So I just wanted to give you some notes, and things that I chose, and decisions that I made that you might reconsider or rethink through.

First one, I alluded to this at the beginning, but gamestate.js ended up being quite long. Whereas all the other files are not necessary as long. This is 170 lines of code, and there's a decent amount of whitespace in there, so I'm not heartbroken at how long this is.

And like I said, when I tried to break it into different pieces, I didn't like it. I liked it better all together, so I eventually refactored it back into one file. But there's a lot of ways you could have chosen to implement this. You could use more functional style programming.

You could have used more object oriented programming. There's a lot of directions you could have gone with this that I chose not to. I felt like this ended up being pretty readable code. You can tell me otherwise, I'm really interested to see how people choose to re-implement this.

But in general, I tried to have problems before I solved them. If I had tried to break this down into more files right now, I feel like if I would have caused more problems than I would have had. So that's kind of where I ended up on that.

The CSS ended up going in two files and it definitely could have been broken down into like a fox.css, a frame.css. And I just didn't really know where to go with that. Again, I feel okay about where we ended up, style.css ends up being 150 lines of CSS with a lot of whitespace in there.

And sprites was a bit longer than that, I think. So that's kind of an arbitrary philosophy. If this had been something like React, it would have been more component oriented. But we didn't do a component Oriented Architecture here. So that's where we ended up with that. Tests, this code ended up in very testable ways like something like mod fox, it'd be very easy to put like a spy on query selector and make sure that it's called with the right parameters.

Same here with buttons. And then here with game state, you could import game state and just make sure that it's transitioning to the correct current. And that would be a pretty good place to do some unit tests there. So that's more stretch goals for you to go play with and try testing.

This would not this project would have benefited from TypeScript. And it would not be hard to convert it to TypeScript. So again, something for you to look at. I love GitHub actions. They're like my new favorite toy. So you can see here again, both the project files for the fox game and the other repo are using GitHub actions pretty extensively.

And this is allows you to automatically deploy your code to GitHub Pages. I would definitely invite you to check that out. They're not super hard to write. And yeah they allow you to automatically deploy your code, automatically run prettier, automatically run ES lint on everything that goes into your repo.

So that's another thing you could definitely go look at. Make a framework version of this. I think that would be pretty cool if you went back and did Svelte or Angular. Something like that. Co-op parenting is what I call this, it'd be really cool to write like a central server version of this.

It's hosted in node.js. And so that like me and Jumana could like play the same game at the same time, right? And it would be keeping track of all the state on the server and using WebSockets to real time update all the clients. That would be a lot of fun.

And you could definitely use local storage here as well. If I started the game and then close my window and came back to it, it could reload the same state and you could use local storage to do that as well. So, there's a bunch of ideas of ways you could think about this, ways you could go change it, kind of all the various different directions.

You could go with this. And that's it. I'm very grateful again to Frontend Masters for letting me come back and teach this again. Please, again, make versions of this hosted on GitHub. Share them with me. I'm very interested in all the various different cool things that you do with the game.

And yeah, I wanna see him. And yeah, thanks.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now