Godot: Learn To Be A Professional Game Developer by Making a 3D RPG From Scratch
Chapter 1 - A Good Foundation

Level 3: GitHub & Plugins

Complete & Continue Next Lesson Learn More

IN THIS LEVEL

Backing up in case of catastrophic failure.

Just like in an RPG, you want multiple save points. You may have entered an area too early and need to go back a few saves. Git is a tool that takes snapshots of our code and uploads it to a server. We can even create branches, like branches in reality, and then merge them in to the main branch later. This allows us to collaborate with other developers.

In this Level you’ll learn how to:

  • Install Godot Plugins from AssetLib using the Godot Git Plugin

  • Download and Install Git

  • Create a Github Project

  • Configure Godot to use GitHub

  • How to Save your changes to GitHub

Godot Plugins with AssetLib

We are going to start by downloading and installing the Git Plugin for Godot.

  1. Click AssetLib at the top center of the window. (Right of the Script button.) (The Go to the AssetLib View will open.)

  2. Click Go Online. (A list of plugins will load.)

  3. Type “git” into the search bar.

  4. Click on the Godot Git Plugin.

  5. Click the Download button. (Wait for the download to complete.)

  6. Click the Install button. (Wait for the install to complete.)

  7. Click the Ok button.

You now have the Godot GitHub plugin installed! You’ll notice in FileSystem that you now have an addons folder where the plugin resides. Before we can use the plugin however, we need to install Git and make your first GitHub Project.

Downloading and Installing Git

Git is a Software Change Management (SCM) tool. It is software that allows us to make repositories (repos), as well as share them with others. It is used because it not only stores your project, it stores a snapshot of your project every time you save it, and it allows you to easily merge changes you’ve made with changes that other developers have made. Git was made by Linus Torvalds, the creator of the Linux Operating System. At the time of its creation, it was a huge step forward in change management. It is still the industry standard today.

  1. Go to https://git-scm.com/downloads.

  2. Download the latest version (it’ll be the 64-bit version if you’re on Windows).

  3. Run the installer.

  4. Click Next on the License Page.

  5. Select to install everything.

  6. Click Next.

  7. Use whatever you’d like for Git’s default editor. (I use Visual Studio Code.) You will probably never need this integration.

  8. Click Next.

  9. Select Override the default branch name for new repositories. Leave the default as “main”.

  10. Click Next.

  11. Select the recommended option, Git from the command line and also from 3rd party software. (We will use the command line, and we will also be using our git plugin, which is 3rd party software.)

  12. Click Next.

  13. Select Use bundled OpenSSH.

  14. Click Next.

  15. Select Use the OpenSSL library.

  16. Click Next.

  17. Select Checkout Windows-style, commit Unix-style line endings. (If you are on Windows. You must do this!)
    OR
    Select Checkout as-is, commit Unix-style line endings. (On Mac and Linux.)

  18. Click Next.

  19. Select Use MinTTY.

  20. Click Next.

  21. Select Fast-forward or merge.

  22. Click Next.

  23. Select Git Credential Manager.

  24. Click Next.

  25. Check Enable file system caching. (You won’t need symbolic links.)

  26. Click Next.

  27. Leave the experimental stuff off.

  28. Click Install.

Now that you have Git installed, we just need to do a little configuration. Git needs to be configured to tell GitHub who you are when you push code.

  1. Open up File Explorer.

  2. Navigate to your Dungeon Delvers project folder (or whatever you named it.)

  3. Right-click in the folder and select Show More Options -> Open Git Bash here.

  4. Enter the following two lines into the Git Bash Window:
    git config --global user.name "your name"
    git config --global user.email your@email.com

  5. Close the Git Bash Window.

You are now ready to make your first GitHub Project!

“Git is the premier change management tool because it’s Open Source and free. Even large organizations use Git. GitHub is the most popular repository system because it is free to use for individuals. GitHub (not Git) was bought and is owned and maintained by Microsoft. Many medium-sized companies use GitHub professionally. The second most popular free repository (repo) is GitLab. Using Git is a skill you are expected to have as a developer. But it’s also just good practice.”

Making a GitHub Project

GitHub is where the code for Godot is posted, so it’s what we will be using. Right now, you will be making your own repo and committing to it, but the skills you learn here will help you contribute to the Godot repo if you so choose. It will also help you to download other people’s open source repos and see how they’ve coded things so you can learn. So, the first step is to create a GitHub.com account.

Once you have an account, we are ready to create our first repository. This is going to involve the plugin we installed, the tool we installed, and the account we just created.

  1. Go to https://github.com.

  2. Type a name into the Repository name field. (We used “dungeon-delvers”.)

  3. Add a description if you like. (We said, “A 3D RPG using Godot.”)

  4. Leave your repo as Public.

  5. Leave the README, .gitignore, and license options alone for now. (Godot created a .gitignore for us when we made our project, and we will take care of the other two in a minute, but adding them now will cause us heartache in making our repo because we already have code to commit.)

  6. Click Create Repository.

  7. Click your profile photo.

  8. Select Settings. (Near the bottom).

  9. Click <> Developer Settings. (It’s the last option in the left sidebar.)

  10. Click Personal access tokens. (Left sidebar.)

  11. Click Fine-grained token.

  12. Click Generate new token.

  13. Name it “Dungeon Delvers”.

  14. Set the Expiration for as long as you like. (We don’t recommend over 90 days).

  15. Make a note to yourself in the Description field. (We said, “Using the Godot GitHub plugin.”)

  16. Select the Only select repositories option. (Under Repository access.)

  17. Click the Select Repositories dropdown button that just appeared.

  18. Select your dungeon-delvers repo. (Or whatever you named it.)

  19. Open up Repository permissions. (Under the Permissions header.)

  20. Select Read and Write from the dropdown for Contents.

  21. Click the Generate token button. (At the very bottom of the page.)

  22. Copy your token and store it somewhere. (You will need it in the next step.) You cannot come back to Git to see what it is later, and will have to make a new one if you lose this one.

Great! Now we’re ready to push our project up to GitHub!

“Committing to Public repositories is a great way to show that you know what you’re doing, so don’t be afraid to make your repositories, even your learning ones, public. This will tell people you’re a real developer, because you’ve written and committed code.”

Pushing Code

Pushing code is the term Git uses for sending code to a code repo. Pulling code is what we do to get code from a repo. Once you’ve pushed your code, you can pull it again anytime. Even if your computer hard drive completely crashes, you can pull your code and start up again from the last point you left off. This is also helpful with a tool like Godot, which sometimes can have stability issues. There’s nothing like having your game corrupted and not knowing why, and losing work you did. It’s so much worse if you cannot fix the problem and cannot go back to a save point.

Push early, push often.

This mantra is very important in development. It’s from the old adage, “Save early, save often.” Make sure you are pushing your changes to your repo at least daily. Definitely every time you finish a chapter. Once you have finished this section, you can push new changes by just following steps 20-24.

  1. Open Godot.

  2. Go to Project -> Version Control -> Version Control Settings…

  3. Turn on Connect to VCS.

  4. Enter your email address in the Username field.

  5. Paste your new Personal Access Token in the Password field. (We made this in the previous section. If you forgot to copy it, you’ll have to make a new one.)

  6. Click the Apply button.

  7. Find the right-hand dock where it says Inspector | Node | History.

  8. Click the right arrow next to History until you see Commit (##).

  9. Click the Commit tab.

  10. Click the three dots in the lower right-hand corner of the window.

  11. Select Create New Remote.

  12. Enter “origin” for the Remote Name

  13. Go back to GitHub, and click on your Profile.

  14. Select Your repositories.

  15. Click dungeon-delvers (or your project name.)

  16. Press the Copy Button next to the URL in the blue box titled Quick setup.

  17. Go back to Godot.

  18. Paste the URL you just copied into Remote URL.

  19. Click the Create button.

  20. Click the Stage all changes button. (The down arrow in the Unstaged Changes section.)

  21. Type “Initial commit.” into the Commit Message section.

  22. Click the Commit Changes button. (Right below the box.)

  23. Click the Push button. (The up arrow at the bottom of the dock.)

  24. Wait for a message in Output that ends with “done”. (Godot will seem like it hung - the GitHub plugin is single-threaded.)

  25. Go back to your GitHub repo.

  26. Refresh the page.

Congratulations! Your project is on GitHub! In the next section, we will add a few things and see how to pull changes.

“Threads are an advanced programming topic, and you will likely never need to deal with them directly. Most programs these days are multi-threaded. It means they can do more than one thing at a time. A single-threaded program can only do one thing at a time, so if it’s processing, you can’t do anything else with the program until it is finished.”
Step 6

Step 6

Step 14

Step 15

Adding a LICENSE

There are two files that every repository should have. They’re so important that GitHub offers to make them for you. Since we declined to auto-create them, we are now going to make both. First we are going to add a License.

  1. Go to your GitHub project page.

  2. Click the + button to the left of the green <> Code dropdown button.

  3. Select + Create new file.

  4. Type type “LICENSE” into the box that reads Name your file… (Directly below where you typed, a button will appear labeled Choose a license template.)

  5. Click Choose a license template.

  6. Click OK on the warning message.

  7. Click MIT License on the left-hand side.

  8. Click the Review and Submit button. (Your license text will be added.)

  9. Click the Commit changes… button.

  10. Accept all defaults in the popup dialog.

  11. Click Commit changes.

  12. Click the name of your project at the top to return to the main page of your project.

You will notice that at the bottom beneath the last file, it now says MIT license. Now that we have a license, we are going to create a Readme file.

“Licenses are a complex subject. If you don’t want people able to use your project freely, you’re going to either want to make it private, or put a more restrictive license on it. If you make a project private and you want to work on it with collaborators, you’re going to have to pay GitHub for that.”

Writing a README.md

The Readme tells everyone who comes to see your project what your project is, how to install it, and how to use it. Having a blank Readme is a sure sign that either you don’t want anyone else using your repo (either through ignorance or intent), or you don’t know what you’re doing.

  1. Click the Add a README button.

  2. Copy and paste the code to the right into the editor.

  3. Accept all defaults in the popup dialog.

  4. Click Commit changes.

Let’s take a look at the Readme we’ve created. At the top, we have what’s known as a static shield: Static Badge Shields are commonly used at the top of your README to convey important information about your repo. For example, what language it's written in, what release it's on, and if it's passing unit tests (more on that last one later.) For now, we are going to construct a new shield that will tell everyone what the main language your repo contains.

  1. Go to https://shields.io/badges

  2. Click the Analysis section. (Left-hand side.)

  3. Click GitHub top language.

  4. Enter your GitHub username into the user textbox. (Right-hand side.)

  5. Enter your project repo name into the repo textbox. (Ours was “dungeon-delvers”.)

  6. Click + Show optional parameters.

  7. Enter “godotengine” into the logo textbox.

  8. Click the Execute button. (At the bottom.) (A preview of your new shield will appear below the button.)

  9. Click the Markdown tab. (Above the Execute button.)

  10. Hover over the text that starts: “![GitHub top language]”.

  11. Click the Copy button that appears.

  12. Go to your GitHub project.

  13. Click the Edit file icon. (Pencil on the same line as the README file start.)

  14. Paste the copied markdown code after the first badge code. (Separate it with either a space or return.)

  15. Click the Preview button to see what it will look like. (If you don’t see two badges, click Edit, hit Ctrl + Z and try again.)

  16. Click Commit changes…

  17. Click Commit changes. (Again.)

Now you have two shields on your repo.

Next in the Readme is the header. I’ve just added the name of the game, and a quick description. Later on, this will get more descriptive to entice people to use or contribute to our project. Projects with good Readmes get used. Projects without them rarely get used by anyone. If people cannot at least get started with your repo, the chances are they aren’t going to waste time messing around with it.

Documentation is king. The second reason to have a good Readme is so that you can remember all those piddly little configuration things you had to do to get your project running. If you download a plugin, and something needs to be done to get it working with your repo, document it here in case you have to re-install from scratch. Take care of future you.

The next header is for Assets. Even though you can get many game assets for free, many creators require attribution through their license. Adding that to your Readme meets that requirement. It also helps you out later if you want to remember what you have used, or where you got something. It’s all in your project.

Finally, even if you don’t have to, it’s the appropriate thing to do. Other people may like the style of the art, sound of music, or love the sound effect you chose for an opening chest. Sharing where you got that is a great way to support content creators and other indie game developers. It also shows you understand the way the open source community works - important if a potential manager comes to look at your work.

“Badges are just a little UI thing that separates out experienced developers from new ones. They give an open source project a little polish. They seem difficult to make at first, but shields.io makes the process relatively painless once you understand their site. Poke around at all the options, see if there’s anything else you’d like to add to your site.”
“Documentation and code comments are written for future you. A great developer documents as they go, because no one, and I mean no one, goes back to do documentation later. This is typically a lesson that you learn in your first job as you are taking over old code and have to figure out what the last person did with no documentation, comments, or notes.

The second lesson you learn comes 6 months to a year into your first job, when you go back to fix a bug in code you wrote yourself - and you are cursing your past self for leaving no comments or documentation as to why you did what you did.

DOCUMENT AS YOU GO

The final reason to do this, is when it’s time for a promotion, to go to a new job, or just to hand off an assignment to someone new, good documentation means you won’t be bugged by that person. It also prevents the worst case, where you get pulled back onto an old team because you are the only one with domain knowledge.

Being the only one who knows something is a trap many developers fall into. They feel that they are creating job security for themselves. They are not. What they are doing is creating job stagnation for themselves. They get stuck in a role without promotion. When layoffs come, the accountant isn’t going to care that you are the only one who knows a system.”

Pulling Changes

To finish our side quest we are going to pull the changes we just made to the repo. This is the same step we would make if we were collaborating with someone else and they made changes we needed.

  1. Open Godot.

  2. Go to the Commit tab. (Right dock.)

  3. Click the Pull button. (Down arrow at the bottom of the Commit tab.)

  4. Wait for Pull ended to appear in the Output.

That’s it! You now know the basics of using Git and GitHub. We will be coming back to do more things with both in the future, but for now…

Level Up!

Congratulations! You’ve made it through a rather technical level! While it may have been frustrating to take a side trek onto a topic that isn’t making a game, you’ve learned important skills to any game developer, and learned it as fast as we could teach you.

As a reward, in to Level 4 where we will be making a player character. Very soon you will be running around in game for the first time! Hurry up! Gerard has missed you!

“Good job! You’ve reached Level 4! Git’s main use is for collaboration, and we didn’t go into that much. GitHub itself does a nice short tutorial on how to do pull requests. Godot has good documentation on how the project does pull requests, and that can help you if you need to learn how to collaborate. Finally, the Godot GitHub plugin comes with documentation. See if you can spot the part we contributed!”