Professionalize your development
Contents
- Introduction
- Git
- Anti patterns
- Documentations
- Semantic versioning
- Continuous integration (workflows)
- Unit test
- Technology intelligence
- Style guide (BONUS)
- time tracking (BONUS)
- resources
1. Introduction
I followed software engineering at university and did a few open source software. I’m proud to say, when I make a project, it’s always better realized than the previous one. (Of course this guide is biased. I’m more a software engineer than game developer. HF reading it though :))
Now I’m getting into game development. I’m no big name (not even a name) but I have many things to tell to novices. Sadly, I’m no teacher, therefore I will not teach you how to use all the tools or methods introduced in this article.
The goal here is to introduce you to tools, concepts and techniques. There are very good resources online, I will try to list some of them for you.
Feel free to add links to resources or suggest improvements in the comments! Lets create a cool guide for the novices :), any contribution is welcome!
All these tools/techniques/concepts can be used with any technology.
2. Git
Intro
If tomorrow I should choose only one tool to use, I would take Git without any hesitation.
Git is a “distributed version control system”. Basically, with my words, I would describe it as “how to sleep at night and remain Zen whatever happens to project”.
Git will allow you to:
- Record changes (called commits) to your project.
- Undo changes.
- Split in less than a second your project into two separate environments to experiment, implement, patch. (We call it “branching”).
- “Return” to ANY previous state of your project.
- View the commit history.
- Work on remote projects.
- Mark any point of the history as important (Called tagging, we usually create tags to track releases).
- And much more.
Git is also usable in cloud for the safety of your project. Check:
Branching
Branching might be difficult to apprehend for novices. At least it was for me. But after some time you will create multiple branches every day.
This article taught me a way to use the branches. It’s not the only way, there are different techniques, but it’s a great one! I recommend you to read it.
3. Anti patterns, AKA what you shouldn’t do
I believe we learn very well from bad examples. I won’t list you all the anti patterns. I will only show you one.
The blob.
What is the blob? The blob is a script that is WAY too big. A script of 1000 lines is most certainly a blob.
The blob does everything and is hard to maintain or understand.
You should read the articles on sourcemaking.com about anti patterns. In fact, you should read everything on this website, but if you don’t have the time just read Software dev anti patterns
Refactoring
Refactoring is a disciplined technique for restructuring an existing body of code
Again, sourcemaking.com will teach you all you need to know with figures and humour.
It will help you identify the problems in your code and how to improve it.
4. Documentations
This one might seem obvious to some of you, but I see many people asking for videos to learn programming.
It might be me, but I never managed to learn much with the videos. Most of the time I ended up stupidly copy pasting and wasting my time. Moreover, videos are slow and harder to find than proper documentations (Even more if you don’t speak English).
Investigation is an important skill for a dev. Your best friend is the official documentation and the quality of this documentation will weight a lot in your decision to use the technology A over the B.
Semantic versioning
The point of semantic versioning (except it looks cool) is to avoid the dependency hell. It might not fit all projects though.
The version number is in this format MAJOR.MINOR.PATCH. And to summarize it increments like this:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
PATCH version when you make backwards compatible bug fixes.
If you need to add some pre-release or additional info add them as extensions to the MAJOR.MINOR.PATCH format.
If you want to use the semantic versioning you should read the Semantic Versioning website
5. Continuous integration(CI) or the implementation of automatic workflows
Continuous Integration refers to both the continuous compiling and building of a project tree and the continuous testing, releasing and quality control
From lone wolf to big teams, CI will make your life easier. It will require some (or a lot) of work, but once done, you will never want to go back to the stone age.
You can use CI to build your game, control the form of the code (to enforce a style guide), upload the files to itch.io, and run unit tests.
You can set up “simple” CI with Github actions
6. Unit test
Unit tests are used in CI (they can be manually used though). The point of the unit testing is to write simple and easy to verify scripts that will test your code. With each change you will run the tests and increase your chance of spotting a bug before you release into in production.
Because testing your whole code might be a waste of time you can write tests for key functions or objects on which you rely a lot. We call this “test coverage”
Moreover, when writing a test you will find out it is hard to test a badly designed function. It will encourage you to write easy to test code, which is a good thing.
Now you might ask, “how do I write unit tests?”
Well, there are A LOT of tools out there for writing unit test and a lot of tools to add them in your CI workflow. But just type “unit test [your technology here]” in your favourite search engine.
See the research “unit+test” on Github results
7. Technology intelligence
This one is very important. Let’s be honest, we are not very good programmers. There are way more competent people out there. But the good point is we, the developers are sociable and like to share our work.
The point here is to not reinvent the wheel. One of the simplest way to search for a library or anything is to type key words on Github or Gitlab. You will find amazing open source work. And the best part is, you can actually help them to improve it!
Save yourself time and effort, use libraries made by fellow devs. If you don’t find a perfect solution you can always fork and modify an existing one. Or you can make a brand new one and share it to help your fellow programmers ;)
8. Style guide (BONUS)
A style guide will allow you and your team to be consistent with the style of coding. You can even use one if you are alone.
This guide will be the bible of your project. You might use the one recommended by your engine or technology, make a new one, or modify an existing one. The point is to be consistent to the rules you want to use for your project.
Here is an example of the style guide from Godot Engine.
var party = [
"Godot",
"Godette",
"Steve",
]
var character_dict = {
"Name": "Bob",
"Age": 27,
"Job": "Mechanic",
}
enum Tiles {
TILE_BRICK,
TILE_FLOOR,
TILE_SPIKE,
TILE_TELEPORT,
}
It shows how you should format, name or write things, from files, to variables.
9. Time tracking (BONUS)
Tracking the time you spend on each task might come handy if you need to bill someone, want to make stats or efficiently plan a project. I recommend using simple and non intrusive software.
Here is a quick list of time tracking apps
10. Resources
Git
- git-scm.com
- Pro git documentation
- Github
- Gitlab
- Bitbucket
- Nvie.com “A successful git branching model”
Anti patterns
Semantic versioning
Continuous integration
- Software_Development_with_Continuous_Integration wiki book
- Introduction_to_Software_Engineering wiki book
- Github actions
Unit test
Bonus
- Alternative to - A website to find alternative to a thing.
