You came here to make something, so let’s make something! How about a game that we can play in our web browser?! Y’know what? Let’s kick it Old Skool, and create a classic space-based shoot-‘em-up. Let’s make Invaders.
ARE YOU READY FOR THIS?! LET’S GO!
Setting Up the Project
If you didn’t already follow the steps outlined in Setting Up a Dev Environment, you’ll absolutely want to do that first. Like… right now. Go on. I’m not going anywhere.
When you’re ready to continue… open VSCode!
Create Your Project in VSCode
You should be greeted with a screen much like the one below. I’ll go into more detail about VSCode in a future post — like changing the dark colors, if that’s not your thing — but for now, go ahead and click the Open folder… option beneath the word “Start”.
After clicking it, you’ll be given a Windows dialog to add a folder to your workspace. Use the left-hand panel of this screen — you’ll see things in there like “This PC”, “Documents”, etc. — to navigate to a spot to plant your project folder.
It’s important that you keep your files organized. I have the benefit of an additional hard drive solely to keep all of my projects separate, but you don’t have to do that. Just pick one folder where you’ll store all of your projects. If you need an idea, click “Documents,” and then click “New Folder”. Name your new folder “Projects”. Then keep reading.
As you can see from this next screenshot, I’ve chosen to place my project folder in
D:\Lab\invaders. Make sure you double-click your new folder before you click Select Folder.
After you click Select Folder, VSCode will look like this. Note that my new folder name is in that left-hand panel.
Installing Phaser 3 With NPM
“Wait, wait. What the heck is Phaser?”
In order to use Phaser, we have to include it in our project. We could just go to Phaser’s website, and directly download the file that we need.
But I’d rather introduce you to the joys of something we call dependency management.
It’s a lot like making a sandwich. You can’t make a sandwich without bread or peanut butter. The sandwich needs those ingredients, or it wouldn’t be a sandwich. One could say that in order to be a sandwich, it depends on those ingredients. Our game is going to depend on Phaser, which makes it a dependency.
Libraries like Phaser can update quite often, which means that if we want to make sure we’re using the best stuff, we have to constantly go out, look for an update, redownload it, and put it back into our project.
That gets tedious.
There’s a better way, and it’s why I had you go through all of the trouble of installing NodeJS back in Setting Up a Dev Environment. NodeJS includes NPM, which can be used as a dependency manager.
To get Phaser into your project, we have two steps to accomplish. We have to generate a manifest file called
package.json inside our project folder, and then we have to add Phaser to that manifest.
You can think of a manifest file as a sort of sandwich recipe in that it keeps track of our ingredients (dependencies), how much of each we need (the version of the package), and from which store we should get it (the origin of the package; we’ll always pull from the official NPM repository, so this won’t ever change).
Inside VSCode — near the very tip-top just beneath the title bar — click View in the main menu. In the dropdown menu that appears, click Integrated Terminal.
After clicking, VSCode opens a new area near the bottom. This is called the “Integrated Terminal”, and it looks like this.
To generate a new
package.json file, we need to type something in that area.
Just like this.
After you type that, press Enter. It’ll think for a second, and then update with this text.
This utility will walk you through creating a package.json file. It only covers the most common items, and tries to guess sensible defaults. See `npm help json` for definitive documentation on these fields and exactly what they do. Use `npm install <pkg>` afterwards to install a package and save it as a dependency in the package.json file. Press ^C at any time to quit. package name: (invaders)
It wants us to give it a name for our project. It says “package,” but that’s an interchangeable word in NodeJS. Notice that right after
package name: it says
(invaders)? NPM is suggesting a value for you to use. You can give it a different name, or you can just press Enter and it’ll use what’s inside the parentheses.
Now we see:
Again, same deal. You can just press Enter to use the suggested value in the parentheses. In fact, you can do that for all of these steps.
Eventually, it’ll spit out some extra lines, and ask:
Is this OK? (yes)
Poof! We have our freshly generated
Adding Phaser to
Next up, we’re going to add Phaser to that file. I won’t have you look at the file just yet, though if you’re extra curious — by all means have a peek.
We need to go back to our VSCode console area.
npm install firstname.lastname@example.org --save
phaser library — specifically
3.9.0 — and to
--save it to our
Press Enter, and you’ll see some behind-the-scenes text as NPM finds the Phaser library, and shows you the output. It’s telling us what it’s doing as it does it; nothing sneaky. It also very helpfully checks the packages for weaknesses or bad things. You can see that in the line that says
audited 2 packages in 2.87s found 0 vulnerabilities. Pretty cool.
You might have noticed a couple of lines that said
WARN, and they point out that there’s
No description and
No repository field. These are things that NPM likes to see in the
package.json file that we generated, but they’re not required. You can safely ignore those warnings.
Setting Up Our Web Server
Back in Setting Up a Dev Environment I mentioned that we needed a web server for these projects, and I had you install a package called
live-server. If you didn’t make it that far, no worries! And if you’re not sure that you did it correctly, there’s no harm in running the install again. It doesn’t mess anything up.
Back to the VSCode console area! This time type:
npm install live-server -g
Hmm. Looks a little different from the Phaser install, right?
npm install looks normal, but we didn’t specify a version this time (
@<number>). And there’s no
--save! And what’s with that
When you don’t provide a version, NPM assumes that you just want the latest version of that package. I provided one for Phaser because I want to specifically use a version that’s still being created; a “future” version that Phaser makes available, so we developers can get used to the new stuff that it provides over the “current” version. Not all packages have this. If we’d installed Phaser without the
@3.9.0, then we’d have gotten a version of Phaser where the code that we’re going to write doesn’t work. For the Live Server package, we don’t care about that since we’re not going to write code that uses it.
And speaking of that, the
-g in that line means to “install it globally” and not as a dependency of this project. Why would we do that? Because Live Server is just a piece of helper code, and our project doesn’t need it to run. You can think of it as the plate that you put your finished sandwich on. We don’t need a plate to pick up and transport our sandwich, but it makes it easier.
And when you install a package globally, you can then use it in any project on your computer without having to install it again!
Go ahead and press Enter to run the Live Server install.
Using Live Server
With the Live Server package installed, let’s take a look at our
package.json file. Go ahead and click the file in the left panel of the screen just beneath your project name.
There’s a block of code in there that looks like this inside the
scripts block. See it?
"test": "echo \"Error: no test specified\" && exit 1"
Let’s change that line to look like this:
"start": "live-server --port=3000"
Go ahead and save
package.json. You can do this by clicking File > Save in the main menu at the top, or by pressing Ctrl+S on your keyboard.
Move your mouse to hover over that horizontal bar that has our project name in it. When you do, you’ll get some new icon buttons. The left-most icon button is the “New File” button. Click it.
Name your new file
index.html. This is important. Web servers look for certain default starting pages, so if you name it something like
invaders.html, your web server might have a problem.
Press Enter, and VSCode will show us our new empty file on the right side of the screen.
Let’s make some magic.
I want you to type out the following in your
<!doctype html> <html> <head> <title>Invaders!</title> </head> <body> <div id="invaders"></div> <script src="node_modules/phaser/dist/phaser.min.js"></script> <script src="invaders.js"></script> </body> </html>
Since this HTML is such a minor part of this project, I’m going to save the primer on HTML for a later post. There are only three lines that we should look at right this second.
The first is:
The second line we should look at is:
This is the whole Phaser engine in a single file, and of the two
scripts that we’re using, it must come first.
The last line to take note of is:
This is the file that we’re going to create next, and it’s going to hold our actual game code! Let’s do that now.
The process is just the same as when we created
index.html. We’ll hover over the bar on the left where our project name is, and click the left-most icon button to create a new file.
This time we’re going to name our new file “invaders.js”.
Once again, an empty file. That’s okay, we’ll fill it with good stuff soon.
Running the Project
Yep, we have enough to actually see something happen in the browser now. I want to show you something cool.
If you closed your VSCode console area, open it back up by clicking View > Integrated Terminal from the main menu at the top of the screen.
Remember that line of code I had you change in
package.json? We did that for a reason.
In your VSCode console area, type this:
Your browser opened! It has your — very blank — project already loaded up! Cool!
BUT THAT’S NOT ALL!
In VSCode, let’s edit
index.html. Don’t close your browser.
Change this line:
Look at your browser window. The title updated instantly without you having to do anything except edit the file, and save it.
This is going to be extremely handy as we edit our game, and want to see the changes instantly.
And that’s where I’m going to leave it for now. The next part to this is going to be fairly involved, so we’ll dive right in for part 2! Slowly but surely, we’re getting to the good stuff!
You can find the source code for this series at GitHub.