Anime that resonated with me as a member of the game dev industry

I don’t watch as much anime as I used to when I was younger, but occasionally I still find some real gems that resonate with me personally. I want to share a few with you today that are meaningful to me as a person, but specifically with relation to my career in tech and entertainment software. I’m going to reiterate that the reason I’m sharing these is because of something I saw in them personally—other people (including you, dear reader) are likely to take away entirely different meaning. On the surface, two of the three listed below aren’t related to game dev at all. But I’ll explain for each one.

Additionally, if you want to watch them yourself, I’ve included a couple helpful resources for each. One, the streaming service where you can find them, and two, a link to a YouTube review from Arkada of the Glass Reflection channel—a resource I can’t recommend highly enough. Each one is not a huge commitment if you want to watch (only 1 or 2 seasons each), and the review might help you decide more than my personal thoughts.

Let’s get started!


Rust: first impressions

I’ve wanted to learn more about the Rust programming language for a while. While somewhat C-like and familiar at first glance, there are several concepts and constructs that were opaque at first glance when I looked at examples of Rust code in the wild. I decided a more structured learning session would help, so I picked up a book that came out earlier this year called, aptly, The Rust Programming Language.

Since this is the official book written by members of the Rust core team, I figured this would be a good guide, and I was not disappointed. It’s a great place to start for someone like me who already has a background in programming and just wants to learn the specifics of Rust. (Though thankfully it does not assume prior knowledge of any specific programming language, so it’s still useful regardless of your exact experience.) I’m only a few chapters in, but I’m already encouraged by what this language has to offer, and I’ve had a lot of fun trying out the examples in the book and poking around at the code.


Crafting a design system

One of the topics I’ve explored with my team at work recently is design systems. When applied to web sites and mobile apps, this refers to the collection of basic components that we use to quickly and efficiently build up user interfaces. Generally at Blizzard, design is a long, bespoke process where each site or app is painstakingly crafted by hand for a particular purpose, usually to match the look and feel of one of our game franchises.

At a team level, we’ve used design systems to help rapidly develop web sites within a particular vertical. This is easily apparent in the set of corporate-themed sites that were released over the past year-and-a-half. While each site is visually distinct, if you break it down into its component parts, you’ll easily find that they’re all constructed with similar building blocks.


The difficulty with Node.js

I originally wanted to call this post “I hate Node.js,” but that seemed a little too provocative. Also it’s not quite accurate–Node.js is a very useful product. As a fast, efficient JavaScript runtime, it does exactly what’s on the tin and fulfills a dream of being able to use the same programming language on both clients and servers of web applications. The real problem I have with Node.js is the package ecosystem. Npm is a complete mess.

To illustrate the problem, let me start with a seemingly straightforward example:

1
2
npm init
npm install gulp

It’s not unusual for me to install gulp first thing with a new project, as it’s a common tool that I like to use for the initial build pipeline for a JavaScript-based web application. This was fresh on my mind since I use gulp for building my professional web site, havisullivan.com, which I was working on the past few days. After installing just that one explicit dependency, here’s what my node_modules directory looks like:


Open-sourcing Critterbits

It’s been a few months since I last wrote about Critterbits. I guess it should be obvious by now that I’m not actively working on it at the moment. Work and real life got in the way a bit, and I also kind of hit a wall on where to go next with the project. To that end, the TL;DR of this post is I’m publicly opening the repository so you can get the code if you want to play with it and build upon it. The rest of this post goes into things I learned in getting this far and what I want to do in the future.

Critterbits on GitHub: https://github.com/taxes-dev/critterbits


©1975 Python(Monty) Pictures

Why I wrote Critterbits

Originally, I wrote Critterbits as an educational exercise. I wanted to learn more about internals of game engines, some ruidmentary graphics programming, and C++. I’ve written software for a variety of systems over the year, from payment services to gameplay code. But I’d never dug into the internals of a game engine except on a theoretical level. It’s a subject that fascinates me and I wanted to learn more. I once heard a colleague say something along the lines of “Show me a man who is writing his own game engine, and I’ll show you a man who has never finished a game.” I can appreciate that… there’s a reason solutions like Unreal Engine and Unity3D are so popular. You can pull them off the shelf and start writing your game rather than worrying about just getting an OpenGL context started and figuring out basic frame timing. Luckily for me, the end goal was to write an engine. I really wasn’t setting out to write a real game. Yet.