It’s time for part of my guide to development. If you haven’t gone over the first guide I highly recommend you do so. In this guide, I will focus on all the tools that you will be needing in order to start your journey. Keep in mind that this guide is divided into two pages (information regarding editors and the game can be found on page 2). Ready? set, go!
Let’s assemble our toolbox!
A developers’ most important tool is probably their workstation. Whether it’s running Windows, MacOS or even Linux it is your most precious toolbox. I say toolbox because on this beast you will most likely install a lot of tools that will help you develop more easily, faster or more safely.
Because you’ll be on your workstation most of the time whilst developing; you’ve got to make sure that it’s running smooth and without as many annoyances as possible. You don’t want to constantly be hating the machine you’re working with, as it will demotivate you to work on it for long periods of time. Your machine should at least be able to run the game, for the things listed below you won’t need much more in any of the specs on your workstation.
Now for the fun stuff, some things to code with! Generally there’s at least 3 vital tools you will have to install on your workstation:
- Version Control Software
- Text Editor or an Integrated Development Environment(IDE)
- The game to develop for
We’ll be going over each of them and give you some basic information to help you make up your mind.
Version Control Software
Although this tool is very optional it is honestly one of the most important parts of any developers’ workstation. You wouldn’t want to lose dozens of hours of work just because you accidentally pressed shift+del on your project folder (permanently remove files without storing them in the Recycle Bin). Or because your device crashed and now doesn’t want to boot up, also the hard-drive caught on fire and I’m pretty sure that noodle-soup you spilled over your device isn’t helping either…
Version Control Software helps you keep track of the different versions of your project (be it code, a book you are writing or even a digital art piece you are making). Consider it like a ‘Save Game’-feature for your stuff so that you can ‘Load Game’ a certain part at a later point. It also helps you in making a list of changes more easily (to show to your users) and it can help you work together with other developers in a very comfortable way.
“Pro-tip: ALWAYS, ALWAYS, ALWAYS commit changes you do not want to lose!”
Popular software like Dropbox and Google Drive have version control built in and can be used to manage your project. Other more specific tools are Apache Subversion(SVN) and Team Foundation by Microsoft. Though a software used by a lot of developers is Git (originally made by Linus Torvalds, the guy who made Linux). We’ll be going over a quick Git overview, though I advise you to head off to Google and find more information yourself.
Learning how to use Git can seem like a big challenge, though there are a lot of tools that help with making it easier to work with. My personal favorite is GitKraken which has a great documentation which can help you get a hang of it.
A simple (although not perfect) Git workflow that can work is displayed in the following diagram. A small description with each part of the flowchart can be found after the diagram.
Initialize repo: The first thing you will need to do is tell Git (through GitKraken or by command line) what folder your project is in. A version controlled project folder is called a ‘repository’ or ‘repo’. Initializing a repository will cause for all changes to a file to be checked, but not automatically backed-up, for that we need another step. Git will create an invisible ‘.git’ folder in the project folder, be sure to NEVER delete this folder as it stores all the changes you commit to.
Make changes that belong together: Now that the repo is ready for version control, you can start making some changes. Generally you will cluster changes together. So with the start of a project you will first set-up a folder structure and perhaps also add a README file with some general information to other developers.
Stage the changed files: Now that we have the folder structure and README set-up in our project, we feel that we are committed to these changes, so we’ll add these files to our ‘commit’.
Commit these changes: Now we’ll make the changes definite, we’ll tell Git that we are so sure these are important, that we want to ‘commit’ them. Once you have made a commit you can be certain you won’t lose the files unless your hard crashes or if you delete the .git folder. Pro-tip: ALWAYS, ALWAYS, ALWAYS commit changes you do not want to lose! If you don’t want to lose anything, COMMIT!
With just an offline repository, you repeat from ‘Make changes that belong together’ all the way to commit. Though usually you will want to back-up these changes somewhere other than your own computer in case the proverbial shit hits the fan. For this reason you will usually add a ‘remote’ to your repository. Services like GitHub, Bitbucket and GitLab can provide this remote in an easy to use way. Register on one of these sites (I recommend GitHub) and usually it will explain to you how to hook up your local repository to their site. You can optionally choose to have a ‘private’ repository online, which will make sure only you and those you invite have access to the source-code (this is a paid feature on most sites, but if you have a school email address you might have access to the GitHub student pack which provides a few free repos amongst other goodies).
Once you have set-up your remote, the following steps are to be included in your workflow.
Pull changes from others: When you have made changes and committed to them; it would be prefered to get any changes from other developers as well. This is why after you commit you ‘pull’ changes from the remote into your project. This will bring you up-to-date with the latest version of the script.
Decide which changes are to be kept: When others worked on the same files you did, you will want to decide how all the changes are to be merged together. Sometimes git will find it easy to do this on it’s own, but usually you will need to help it by telling how the code should be merged. GitKraken comes with a great ‘Diff Checker’ which shows the differences in files. On one side (usually left) you will see your local changes and on the other side you will see the changes from the ‘remote’. Simply by clicking some checkboxes you can decide what to keep from either version.
Merge these changes: Once you have decided what to keep you can merge these changes, composing a single code file as a result.
Commit this merge: Once the file is changed, you will have to commit it so it becomes the new version of the file and so you won’t ever lose it again.
Push your commits online: Now that you’re all set, you can say “ok I REALLY REALLY never want to lose this file” by uploading it to the remote (GitHub, BitBucket or GitLab for example). There it will stay with your personal account as an online repository.