Me and Prime Talk Game Engine Basics
The VOD of our livestream is now available on his YouTube channel.
Once again, I had a fantastic time talking with Prime on his live stream — so much so that I used “Me and Prime” in the title rather than the uptight “Prime and I” that English grammar teachers think is better (it’s not).
The VOD for our discussion is now available, so for those of you who missed the stream, here it is:
It’s long, and we talk about a lot of different game engine and programming concepts. To make it easier to navigate for anyone who isn’t planning on watching the whole thing, I created a timestamp list that covers the major sections:
[02:14] Talking about the early days of programming streams on Twitch.
[12:00] Prime describes the Doom-via-Twitch-chat harness he made.
[14:16] Prime describes the tower-defense-via-Twitch-chat he is making now.
[25:10] Game engines run continuously, unlike I/O-driven programs.
[29:10] Difference between isolated game rule implementation vs. diffuse game rule implementation.
[41:00] How a game rule kernel interacts with the overall game engine, and the dangers of hyper-isolating a kernel.
[46:07] Replay gets easier if state is isolated.
[47:00] Importance of letting game rules systems track enough information to make your life easier when implementing the A/V and UI parts of the game.
[52:30] Difference between making a code change for actual performance reasons vs. to prevent potential bugs.
[1:00:00] Cameo by Molly the Puss!
[1:03:33] The importance of low experimentation cost when working on a new game design.
[1:07:10] Doing one experimental version is necessary to know what you actually need for abstracted interfaces.
[1:08:00] Difference between “everything is an entity” vs. “each thing is its own type”.
[1:09:38] Concrete example of how entity information works differently for game rule processing vs. for UI and A/V.
[1:13:45] Generalization of the example to other entity properties.
[1:16:50] Importance of using the advantages you get by making your own engine, since you start with the disadvantage of not getting all the prebuilt stuff.
[1:18:18] Prime explains the locality-of-behavior principle behind HTMX.
[1:22:30] Extension of the “don’t overcomplicate” idea to entity organization and processing, with examples like how entities determine which other entities are nearby.
[1:28:38] Epilogue about specifically when in the development process you should start thinking about performance.
[1:29:35] Importance of not letting slow architecture exist longer than just the prototyping phase (“counting on hotspots doesn’t work”).
[1:33:50] The prototyping phase is also about determining what architectural features you will need for performance.
[1:37:20] The dead-end performance of serial dependency chain architectures in web apps.
I always enjoy going on Prime’s show, and hopefully we’ll do another one soon. In the meantime, if you missed the previous stream we did together, you can check it out here.
Seeing you tell Prime that if the Tower structure just has the animation variables inside, the code would be by a multiple strictly better in all senses really made me feel the damage the current best practices did to my brain by not being nuanced. Not wanting to start watching 1000h+ of Handmade Hero, I'm curious if someone has something like a list of "good practices", that programmers/college graduates can't even start thinking to question, with some real alternatives to start understanging the "tradeoffs" made by default.
Very good case study with the health bar that would definitely benefit almost all the programmers working on new code I would definitely clip and tweet.
Maybe I am very biased on this because you literally decribed what I had to do to my animation system, and my conclusion back then was that animation systems are just difficult because of those things everybody has to do.
This was a great talk. I would love to hear you talk more about properly executing the prototyping phase for the more complicated type of game. If the concept is something like a modern RPG game with towns, npcs, action combat, questing, and monsters, where do you draw the line and decide you've made enough of a prototype and can confidently switch into performance architecture work?