> The entity component system (ECS) is one of the main reasons why programming games in Unity is so pleasant.

I agree programming in Unity can be very pleasant. To avoid confusion, I wanted to point out that traditional Unity programming isn't really a typical example of an ECS. Unity's system actually lacks most of the performance benefits you can get from one. This is relevant because Unity is actually currently developing a "real" ECS architecture they call DOTS (data oriented technology stack).

To be ultra confusion avoiding you don’t necessarily get great perf benefits from the merely organising things as per the ECS pattern. You still need to organise your data around how it is used. Which is why Unity uses archetypes which trade fairly automatic organisation based on entities component signature for increased cost if you add and remove components from them (as it triggers reorganising where that entities components are stored). There are other patterns with different trade offs.

In terms of just mental overhead any form of composition is useful be it Components in the Unity sense or Components and Systems in the ECS sense.

Personally, the performance benefits are secondary. It is a lovely way to program to be able to use composition like you can in Unity. If only they didn’t revoke usage rights on their asset store without warning during license updates, I would be a much bigger fan of the company

The GoF book is literally a dictionary. I wish more people realised that. It is an attempt at describing a specific "pattern language". A "pattern" is a solution to a problem that comes up repeatedly in different contexts. For a pattern to be a pattern it there must be a problem you are trying to solve. There must be a context in which you are trying to solve the problem. It must describe the solution in the context. It must describe in which contexts the solution is appropriate and in which contexts it is not appropriate. It must be a solution that is well known and widely used (this bit always surprises people -- usually there is a rule that there must be at least 3 unrelated implementations of the solution in the wild). Finally, for a design pattern, the solution must be in the design domain and not the implemenation domain (drives me crazy when people say that they don't need design patterns because they have a reuse library).

A pattern language is a collection of patterns where the use of one pattern commonly implies the use of other patterns. In other words, if you use one pattern in a specific context, then likely certain other patterns will also be useful. Importantly, there are situations where you want to avoid using certain patterns with certain other patterns. The intent of a pattern language is describe these related patterns and how the work (and don't work) together.

The GoF book was an example of a possible pattern language for object oriented programming. It was never intended to be an exhaustive pattern language, or a recipe book for implementations. It was simply an example of how you might go about making a pattern language in that domain. It was an amazing achievement because it was the first serious attempt at creating such a pattern language.

Unfortunately, not many people have actually read the GoF book end to end and therefore don't really understand what it was for.

It's hard to understate how much game programming helped in my career. All at once it helped me grok not just patterns, but also Calculus ("wait... isn't this for loop very much like an integral? is that what they actually were all along?!"), Algebra, OOP, Discrete Math and even got me out of a rut after a very boring and stale couple of years.

I very much recommend working on graphics and games to every programmer and CS major who hasn't already!

What would you suggest as a starting point for a regular software engineer who'd like to look into this? See how everything comes together at a high level I mean? Because to someone on the outside, the field of game development appears to be very daunting.

There are a lot of libraries in different languages that are sort of in a middle place between drag n drop engines and programming straight to a graphics API like Direct3d or Vulkan. You should look around for a popular one in a language that you're already comfortable with and read up on tutorials, documentation, and such first.

For reference, the ones I used to love and seem to still be kicking were Phaser.js for web games and Libgdx (on Kotlin) for mobile/desktop. Both were incredibly fun to learn, and I went at it very slowly on my own pace with a clear, small-scoped, end game goal each time. It was very hard but worthwhile to not let myself fall to scope creep, and after a couple of completed prototypes I felt ready to tackle 3d. I got some projects on C# that used Direct3d to draw things with triangles and went nuts trying to implement the concepts I read about in books like realtimerendering.com

I know it all looks daunting at first, but always remember that it's supposed to be a very long, very fun journey, meant to satisfy your intellectual curiosity at every step of the way. Games and graphics are one of the most rewarding problem spaces since every time that you learn a new concept and get it working, you get to see it and play with it and it's the best feeling ever!

And while I'm here I want to share the most wonderful tutorial on how to build hexagonal grids for games and things, in case you want to do something hexagonal at some point like I did, from what I think is one of the best educational resources I've ever seen: https://www.redblobgames.com/grids/hexagons/

Cheers!

That site has a rather good walkthrough of pathfinding in general

Starting with something easy, like 2d animations in browser using libraries like pixi.js. From there you can expand on many topics, just focus on one at once, be it shaders, networking (for multiplayer games) or whatever might interest you.

Monogame if you are coming from C# background, or want a fun intro to C#.

https://www.monogame.net/

The MonoBehaviour pattern is similar to ECS (both follow composition over inheritance), but there are some crucial differences IMO. In case of monobehaviours there are no systems as such and components aren't mere data containers.

Re, events: events are wonderful, but doesn’t it get a bit hard to debug them later on? Whenever I work in a poorly written web application, following people’s random/out of date event chains to fix a bug is just maddening

> turn each entity in a game into a server which sends events to other entities.

This reminds me of event-driven microservices. Is it similar, in principle?

Sounds more like actors. And how Alan Kay envisioned what he called object oriented programming at the time.