This site contains archived posts made before July 2022. If you're looking for the live site, you can find it here.

Thoughts on TypeScript for Game Development

Sun Mar 10 2019

For those of you who are unaware, I've been posting videos for quite a while now on my YouTube channel (here). I started this channel (well, relaunched, honestly) about halfway through last year as a channel for game development. Since then, I've posted my thoughts about the industry as a whole, or specific topics therein. 

However, I also lauched a TypeScript Game Engine Tutorial series on there, which details the creation of an entire game engine in TypeScript using WebGL. I also, at the time of writing, developed a simple game from start to finish using that engine.

Granted, with only 28 videos, things are still pretty simple. However, I do know that TypeScript in games is scalable. Way moreso than I ever thought.

You see, in my full-time position, I am the lead developer and maintainer of the game engine we use there internally. While I cannot disclose details of it, one thing I can mention without breaking any sort of NDA is that it is built using TypeScript. This ultimately is a product seen by millions of people worldwide. Moving on now before I *do* say something I shouldn't :)

A couple of things stand out to me about writing a game engine in TypeScript - both on the good side and the bad. 

Starting with The Good:

Type safety presents a *huge* advantage over standard JavaScript development. TypeScript also provides interfaces, which Javascript does and cannot. (One should note, however, that when transpiled, interfaces become nothing, but in terms of a maintainable code base this is huge).
Typescript allows for better scoping of methods and members without having to resport to the typical trickery required by Javascript (although, it should be noted that the transpiler performs these tricks for you). Again, more maintainable code is never a bad thing.
The TypeScript transpiler outputs very neat, clean code.
Separating classes into diferent files is handled cleanly by the transpiler.
Works great with node/npm setups to include code easily (most of the time)
Now, for The Bad:

It still transpiles to Javascript which, for most cases, still kinda sucks. 
All the different options on module resolution and imports vs. references can get confusing.
Inability to perform an 'instanceof' or similar type check against interfaces, since technically they do not exist in Javascript.

And The Ugly:

You're still limited to a single thread. For loading, this really sucks. This isn't a TypeScript issue per se, but a Javascript one. Yes, WebWorkers *can* be used as *a* way around this, but it's still a hack with plenty of restrictions. We struggle with this constantly when trying to improve load times at work.
It's still ultimately a managed environment, which means the garbage collector gets in the way *all* the time. Again, this isn't TypeScript's fault, but is the fault of each and every implementation of the Javascript API. And they all handle it differently.

Given all these points, it's still a really large step forward in web development, and a solid choice for making games. Most of its limitations are those of the underlying Javascript implementation, but even with that said it's a great way to write a game which gets cross-platform compatability (almost) for free.

Do I recommend it? For simple games; absolutely. However, if you are writing a really complicated game, you will eventually hit limitations on performance using javascript, which ultimately means TypeScript. So, for large projects? Stick with native.