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!
Requirements
|
Learning goals
|
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.
[nextpage title=”Editor & The game”]
An IDE or Text Editor
With software development an Integrated Development Environment (or IDE) is often used. It provides a collection of tools (usually even Version Control with Git) that make development easier and prevent a lot of different software running in separate windows. Though with most modding you can stick to a simple Text Editor.
When I say Text Editor I don’t mean something like Microsoft Office Word, OpenOffice/LibreOffice Writer, Wordpad or even Notepad (whilst you will see a lot of other beginning coders start with Notepad). No, what I mean with Text Editor is a software that supports the writing of scripts and make scripts easier to read by providing syntax highlighting. Syntax highlighting means that certain elements of the code will get different colours depending on what the rules of the language dictate they should do, allowing you to see problems more easily and causing for less of an eye strain from just looking at a bunch of black on white text. Syntax is part of any language, even non-programming languages.
Fun fact about coding: when you’ve mastered one language, stepping up to a different language is a whole lot easier! So when you’re done with modding for the current game, maybe go mod a different game. Maybe you’re even going to fire up a simple game engine and write a game in that!
With regards to the text editor you will be needing; there’s a few options you can go for, but we’ll go over 3 of the more popular ones.
Notepad++
This was the editor I started with, it provides a nice and clean interface with more than enough room to edit your code. It provides customizable syntax highlighting and can autocomplete words and functions amongst other things. Expanding it is possible with plugins that have been made by the community, there’s even a Garry’s Mod Lua Syntax plugin to highlight many of the functions and libraries that can be used for modding.
Sublime Text 3
Doing the same things Notepad++, Sublime Text has a few more features that I’ll let you figure out yourself. One of the most powerful plugins for Sublime Text has to be the Package Control utility though. It can be installed through instructions here. It allows you to install packages from inside Sublime Text that can give you extra features within the reach of a few keypresses. Also through this Package Control can you find a ‘GMod Lua’ syntax plugin that will add syntax highlighting for the Lua variant that Garry’s Mod uses.
Atom
From the creators of GitHub comes a ‘hackable editor’ which has gained a lot of popularity. It comes with a built in package manager and it has a modern and clean style. I see a lot of people use this recently and it feels nice and snappy whilst providing a lot of customization.
In the end it is all personal preference. I advise you to just try them all out or even look further for other editors as there are many more out there.
If you do want to get an IDE to develop or need one for what you are working on I advise Visual Studio (by Microsoft) for general application development; PHPStorm (by JetBrains) for general web-development; or perhaps one out of this list for Lua development (although I have not personally tried them, which makes me feel pretty bad about myself)
The game
Whilst also losing it, you can also code for some games. A bunch can have mods be made for them and a few even provide scripting languages to do that with. Lua is one of those scripting languages, it can be found in Garry’s Mod, World of Warcraft, Civilization 5 and a whole lot more. It’s a great scripting language to get started with and has all the big boy parts other scripting and even programming languages have!
(I’ll leave it up to you to figure out the difference between a scripting language and a programming language, but it really doesn’t matter at this point)
Some games these days even allow for modding with more popular languages such as C#, Python and Javascript. Working with these languages to mod your favorite game is great, because the knowledge of those languages is an actual skill that is requested in the work-field. (So if you live with your parents and they’re wondering why you are up so late looking at ‘that darn screen’, tell them you’re studying for your future profession as a programmer!)
If the game you are modding for provides a choice of language then it’s all up to you! If they provide a choice the things you can do in both languages are possibly (but be sure to check) the same. Meaning it couldn’t really matter what you chose as it’s personal preference.
Next think you will want to look out for is a good documentation for the modding of a game. A great example is the Garry’s Mod Wiki as it comes complete with example code and a few tutorials. Whenever you find a function, event/hook or anything you want to know, you head for the documentation to see what it says. Sometimes the page will even inform you of limitations with that particular code.
If your game does not have any documentation for modding, modding capabilities and/or modding languages, then you are in for a rough ride! It might be easier to first get a basic grasp of coding before you try this. Starting with modding for games where you have to reverse-engineer code (made by people who don’t really appreciate you digging around their product) is a bad idea for multiple reasons, one of them being that it can be really challenging and near impossible for any beginning coder.