The case for self-hosting VCS For game development, I like hosting my own source code repositories. The reason? They get big really fast. We’re hardly making AAA assets but even so, things adds up very quickly unless you’re doing something low-fi. Big files mean increased storage costs, and slower network transfer speeds if you use remote hosted solutions. If you self-host, storage is much cheaper to add compared to, for example, $5/month per 50GB on GitHub, and you can locate your server closer to your work machines to speed up data transfers.
A Problem of Determinism I had a particular problem to solve for our next (so far unannounced) game. I needed deterministic physics. That is, given a certain starting state, I needed to know that if I applied the same forces to that simulation, the same results would always occur. Now, this is extremely hard to do universally, especially across platforms, and even between different binaries on the same platform. So, I limited my definition a little: that given an identical build, on the same platform, the results were deterministic.
Almost 4 years ago now I blogged about my decision to use Unity for our new game development adventures, and in that time we’ve shipped one game (Washed Up!), stealth-shipped one polished prototype (only to our bestest fans 😏), participated in 4 game jams, and noodled with another 2 prototypes that never saw the light of day. All of those have used Unity, and generally speaking we’ve been quite happy with it.
Recently I needed to do something pretty common in many top-down games: render a whole bunch of health bars for enemies on the screen. Something like this: Obviously, I want to do this as efficiently as possible, preferably all in a single draw call. As I always do before I start something, I did a quick search online of what other people are doing, and the results were…mixed.
The case for self-hosting One of my favourite things about Git is how easy it is to turn any old server into a remote for collaboration & backup. Sure there are fully-fledged Git web services that manage projects, user access, pull requests etc, and these are a must for larger teams. But if you have a super-simple team like I do now (2 people, both co-located), there is beauty in simplicity.
Let’s stop labelling people. We label ourselves, in order to gain acceptance from others, to feel like part of a larger whole, or to claim some kind of “identity”. A neat, easily-parsed silhouette which can be presented as shorthand, like some kind of personality hash. It’s not accurate, but it’s simpler, faster and often more palatable than the hazy, shifting reality. Worse is when we apply labels perjoratively to others; usually it’s to build straw men, their primary purpose to faciliate bad-faith arguments, most commonly on social media.
I’ve had a few friends ask me why we chose the name Old Doorways for our new game development venture. I’ve repeated the explanation enough times now that I figured it was worth blogging about, in case anyone else was wondering. The struggle is real As anyone who has had to name anything - a company, a product, a small human - will know, names are hard. I mean really hard.
This is the fourth instalment of a blog series I’m writing about Nakama, which I’ve used for leaderboards in our first game Washed Up!. Part 1 covers what Nakama is, and why I chose it over other options Part 2 ran you through setting up a basic service you can use for development & testing Part 3 showed you how to run Cockroach in secure mode This part deals with how to set up SSL on the Nakama server.
This is the third instalment of a blog series I’m writing about Nakama, which I’ve been using for leaderboards in our first game Washed Up!. Part 1 covers what Nakama is, and why I chose it over other options Part 2 ran you through setting up a basic service you can use for development & testing The configuration at the end of Part 2 is not ideal; it works, but the database is running in ‘insecure mode’ and there’s no SSL between clients and the server, which could leave it vulnerable to interception attacks.