If there’s one thing I’ve learned from 29 years of internet, it’s not to reply to YouTube comments.

Let’s do it anyway!

I gave a talk at Software You Can Love (SYCL) titled It’s Not About The Technology - Game Engines are Art Tools. The YouTube recording premiered on Monday, and there was a lot of high quality discussion in the comments.

Table of Contents

Building a game engine as an educational endeavor

@kenneth_romero: Great talk, loved the slide on the different experience levels and questioning the current popular patterns. Been thinking about making a game engine, honestly might take your first approach to just learn and enjoy it.

I think that’s a great idea.

In my talk, I mentioned that I took a minimalist approach to my first game engine, and that in retrospect this was the wrong approach to building an engine that’s productive to work with. However, it’s a great approach if you want to learn!

By rejecting standard patterns, you get to make your own mistakes. As a result you gain a deep appreciation for the patterns that work in a way you wouldn’t have if you just gone with the flow.

Using off the shelf engines

@distantforest2481: Fantastic talk Mason, a timely talk that highlights the hidden costs of not focusing on what really matters, the needs of the users. If we dont focus on that, In our case as developers, it’s misplaced time. And on a larger scale, the whole cough Unity debacle.

Something on the top of my mind though is that if we take this thought to its conclusion, why not use a game engine? The users don’t care what engine you use, as long as the game is “Good™”. I’m wrestling with this myself, as I’m the same where I’m stubborn and I want to create my own game engine. Sometimes there’s a reason why Game Engines do the things they do even if you don’t initially see the reason why (Such as the ECS thing). Game engines like Godot have spent years already tackling issues that have risen on various points on the development cycle. What are your thoughts to this?

“The users don’t care what engine you use” is a great point, I think a lot of programmers fail to consider the generalized version of this statement–your users don’t care what language you use, how your code is indented, how elegant your algorithms are, if you organize your files well, etc, they care whether or not your software provides them with value. Those other things all matter, but they only matter insofar as they support you in providing value to the user.

So, should you use an off the shelf game engine? IMO it depends on your goals.

If you’re making games as a hobby, then you should do whatever’s the most fun for you. If you want to learn, then you should decide whether you want to learn more about low level programming, or game design.

If you’re making games professionally, or have aspirations to, then it’s a bit trickier. I definitely would not recommend anyone use Unity for new projects of course, but like you mentioned, open source engines like Godot are a great choice.

Some games require rolling custom tech (e.g. Teardown) which makes the decision easy. If the game you’re building doesn’t, then you have to ask yourself, what about your engine would be an improvement for your workflow over using something off the shelf, and is that worth the cost in dev time?

That being said, you don’t owe the world pragmatism! If you like doing engine work, and can afford to, then go for it. Unless you sold your company to investors or have employees depending on you, you’re allowed to choose to have fun if you can afford it, and someone needs to carry the torch or there will be nobody left to maintain the popular general purpose engines in ten years. You have some flexibility here too because you can lessen the cost in dev time by not doing everything from scratch. There’s nothing wrong with writing a game engine that is essentially glue code for various middleware.

All that being said–I think using an off the shelf engine is a great choice (and often the only choice) for many teams/projects.

Engines for design vs for production

@loabrasumente2283: Fantastic talk! Normally we don’t see talk like this here.

I have a question about shipping. You mentioned game engine as an art tool for game designers. But I feel like it’s not in the same sense as Photoshop, because after you finished the design of an asset, you don’t need Photoshop anymore but need to embed it into “production environment” lets say. On the contrary, after we are done experimenting a game design idea, say the fast forward, in an “art tool” engine, should we port it to an engine that’s more mature, or we should make the art tool powerful enough so it’s shippable by itself, otherwise potentially we will have to maintain two parallel implementations of the same game, one for shipping, one for prototyping?

I’m not a game dev, I don’t know if a game engine can exist solely for the purpose of prototyping. I also don’t know the status quo of existing game engines, how good they are as an art tool. So I’m really curious about the direction you are heading.

Also I was wondering if we can design in Unity, come back with a bag of ideas and implement them in a minimal way?

In my talk, I claimed that a game engine is to a game designer what Photoshop is to a visual artist.

There is a fundamental difference between these two things insofar as visual artists don’t ship Photoshop when they distribute their work. However, the idea here isn’t that these things are identical, but rather that looking at engines through this lens results in the correct prioritization of effort.

It might seem like focusing on the designer and not the player misses 50% of the picture, but, since the designer’s job is to care about the player’s experience and the runtime directly impacts that, we can justify all work on the runtime through the lens of giving the designer what they need to create a good experience for the player. In looking at things this way, we correctly see the runtime as part of a bigger picture.

In response to the idea of using one engine for design and a separate engine for release–you’re onto something here, but I’m gonna tweak the idea a little bit!

Porting a finished game from one engine to another is typically very costly, so exactly as written this is unlikely to be worth it in most cases. Furthermore, an engine that’s good as an art tool likely has a solid runtime too since the two are intertwined, and the runtime is easier to get right.

(Unity is an interesting case since you don’t want to ship Unity games anymore purely for business reasons, but the prior point still stands.)

All that being said, many people do follow this pattern, just at a smaller scale. For example if you’re making a card game, you might prototype it with physical cards first. Or if you’re making a first person narrative game, you might make a mock up of the story in something like Twine to try out the main ideas. This workflow is a big reason game jams are popular.

The idea here is typically to explore the unique/risky/important parts of an idea as quickly as possible to de-risk before committing to the idea and building a stable foundation. The cost of porting isn’t an issue here because this prototype is typically small, and intentionally only covers easy to port ideas or things that need to be redone at higher fidelity before shipping anyway.

The danger of going too far

@geertenvink: Loved the talk, really interesting. The end sounds like you’re well on your way to finding some parallels with the wonderful world of web dev, where everything is user stories and customer journeys and “program for the user” to sometimes extreme degrees. I’d say “build with the user in mind” is great, but the common pitfall is “spend way too much time taking inventory of what the users want and what the users like” instead of just building what you, a team of experts, know will be good enough for 90% of the people that will use your product.

I’ve worked for companies that operated this way, and I agree it’s not productive at all. Big companies are where good paradigms go to die. :)

I think most small developers were born with antibodies against this trap, but it still gets people sometimes.

I used to help run a monthly playtest night for UCSC when I lived in the area, and I would see this a lot in people running their first playtests. It was common for developers to ask the players questions like “did you think the game was fun?” or “what features did you like or dislike?” and then try to directly implement the feedback they got.

You have to come into these things knowing that you’re the expert. You’re asking the users for perspective, not for answers. That is if you’re even asking–often I get more perspective from of watching users interact with my work than from asking them questions.

What about tech demos?

Some engines are entirely about the tech and the “game” part is completely reliant on the technology. It’s okay for games to be tech demos, or almost entirely about the tech–assuming the tech is novel and enjoyabel to people. Wolf3D, Doom, and Quake were basically tech demos. They came up witha game design and art assets to fit the engine–not the other way around.

(I’m paraphrasing this one because the author was weirdly angry and had an inappropriate username, but I think this excerpt raises an interesting point.)

There’s always feedback in both directions, but I wouldn’t personally call Doom/Wolf3D/Quake tech demos–Doom actually had a separate tech demo. If I remember the books about early Id Software correctly, it seemed like John Carmack saw his job as building tools for John Romero to build fun games with which is the perspective I’m advocating for.

However, pure tech demos do exist. I certainly love a good tech demo.

So right off the bat–sure! The more you’re building something that is literally about the technology, the less the advice in my talk titled “It’s Not About The Technology” will apply to you.

That being said, a tech demo is also art right? It’s essentially a high budget demoscene demo where you forgot that demoscene demos aren’t supposed to be 80gb. You ship some software to the user, it does cool and impressive stuff with their hardware, and they enjoy the results!

If you’re building an engine exclusively for tech demos–usually you aren’t, but you could be–you might prioritize different engine features, but you’re still building tools that eventually get used to build novel experiences for the player. The player doesn’t like your tech demo because it uses RTX, the player likes your tech demo because it looks good using RTX.

Highlights from chat

Hot swapping without having to implement hot swapping

Aaron Winter: I figured hot swapping might not be necessary if the compiler recompiles the code fast enough that it wouldn’t bother me - however it would not bypass the asset loading when restarting the game.

This is a great point I don’t see discussed often–hot swapping support is a gradient, you don’t have to take it all the way to start to get benefits.

For example, if you implement a hot key in your engine that saves, exits, recompiles, and then relaunches from save, you’ll get most of the convenience of hot swapping without actually having to implement the tricky parts.

That is, provided your compile times are short and your assets load quickly. For small games this can actually be viable! Just make sure you don’t store your textures in a format that takes a while to decode like PNG; right now I DXT compress my images and then lz4 them before saving to disk.

People love ECS but don’t use it

Michael λ: ECS is so well loved and yet I never run into it in practice

I spent some time in my talk explaining why everyone says that ECS is a good pattern, why their reasons are wrong, and why it’s a good pattern anyway.

While I was on this topic I said “I’m not a AAA person, but my understanding is that [ECS] is industry standard.”

Since then I’ve been told that it’s not industry standard, it’s the thing everyone wishes they were doing but isn’t. I guess this isn’t too surprising–none of the common off the shelf engines have first class support, and most in house engines have been around a long time.