Making Ghent Theft Auto, with Git. 🔃
Hey guys and gals from the internet! 👋
Another week, another article! This one is going to cover the various uses of source control systems in my pet project Ghent Theft Auto, more specifically: Git version control.
I started using source control just over a year ago, before I even started this whole programming mumbo jumbo, in a rather naïve search for backups and hosting in a single solution.
I had worked with Github Pages before to host static websites, having no clue about the sheer magnitude of and great functionality behind Git. To this day I discover new uses and advantages when it comes to tracking, well umm, stuff!
Seriously, if I could version control my life, sign my ass up any day.
Naaaaah, who am I kidding:
I got into Git because I thought I looked hella cool when I typed stuff like git commit -m "yeah baby" in a Terminal prompt. 🤓
Fanatics will probably rage (or at least frown) at me for using text-based source control when dealing with large binary files. While the use of version control for tracking 3D files definitely has some drawbacks, I feel like they’re actually a good thing. I learned a lot of ‘sloppy’ and high poly habits in my first job as an arch viz artist and the limitations of using Git for the map really helped me grasp the impact on hardware, software, in some cases even the network when producing and rendering 3D content.
Don’t fret, if you insist on being pedantic: there are ASCII based 3D formats, like .STL files. Github allows you to render those in their web interface, even though the format is extremely cumbersome to work with and lacks even the most basic functionality such as smoothing groups or material id’s. 🤷♂️
Issues
When I stumbled upon issue tracking, I started using it extensively as a personal advanced to-do list and time tracker.
Thinking in issues allows you to plan ahead, defining scope and architecture before writing a single line of code. Call it Issue Driven Development, where you could sometimes very well be planning months ahead.
There’s a masochistic touch about assigning hundreds of tickets in advance, quickly aggregating into a huge backlog, looming over your head.
On the other hand, it’s exactly that kind of self-inflicted torture that helps you decide what feature is worth those precious hours!
Assigning issues to Milestones helps me setting goals, like working towards apparently one of the most elusive thing about Ghent Theft Auto: a shippable first multiplayer demo.
Anyway, Projects allow you to group issues, helping you encapsulate development and understand the bigger impact of features.
Last but not least, the practice of feature branching, further allows you to isolate your development efforts, avoiding broken builds and non-relevant bugs.
When you’re done, integrate your feature branch with a commit message referencing the issue you assigned, which closes it automagically. 🧙♂️
Submodules
Submodules are my most recent Git discovery and I’m loving every second of them. I got used to working with submodules as we use them as a solution for managing common code bases in our Unity projects at In The Pocket. We use submodules as a temporary fix because Unity’s package manager is still getting its act together with regard to 3rd-party dependencies via Git. Fingers crossed for 2019.1 🤞
Long story short: submodules act like repositories within repositories, where you can point the submodule to a specific commit.
The structure enforced upon you when working with submodules makes it impossible for you to not think about the scope and architecture of what you’re trying to achieve. Encapsulating code, enforcing the single responsibility principle and avoiding circular dependencies becomes way easier when code is literally, physically split.
Instead of a cumbersome, monolithic blob, your project turns into a network of intertwined plug-and-play components that can be configured into other builds and even totally new projects.
If you for instance develop a video game where you include the ability for a player to drive cars, nothing stops you from developing that feature decoupled (i.e. as an independent submodule), later including it in other productions. The added benefit being, when you improve or extend your code in those later productions, updating the original repository could - in theory - be as easy as updating the submodule.
Likewise, code you’ve written for user input could be integrated into a common submodule. That module would be shared by all your projects, streamlining your code and allowing you to quickly integrate new best practices and lessons learned from other projects into new and old ones.
I like this kind of ‘plant the seed’ or ‘pay it forward’ approach to development, as I feel it offers all the benefits and none of the disadvantages of iteration. 🌱
Another major added benefit is how they can intertwine with Unity’s package system, but that’s literally a story for a different date. 😉
