Godot Game Architecture: 7 Tips for Extensible, Readable, Testable Game Code

In which we discuss the nature of good code and fix up a sloppy old Tetris-like. Sometimes refactoring can be a bit of an overkill, but here are some high-value architecture and code-style practices you could take on for pretty much any type of game. I'm working in Godot with GDScript right now, but I think the principles hold pretty well across languages and even engines. Agree? Disagree? Scream at me in the comments! GitHub Links: Before: https://github.com/hoveringskull/bloc... After: https://github.com/hoveringskull/bloc... 0:00 Intro 0:43 Why refactor our code? 2:51 Characteristics of "good code" 4:54 The tight-coupling problem 7:25 Case study 8:16 Problem 1: Over-reliance on global autoloads 8:37 Problem 2: The signal hub 8:51 Problem 3: Ad-hoc scene structure 9:00 Problem 4: Pointless file structure 9:25 Problem 5: Dynamic typing 9:36 Problem 6: No clear style guide 10:25 A warning against being seduced by the beautiful song of refactoring 10:51 Converting to static typing 13:22 Segregating game state 15:14 A context-based hierarchical scene architecture 18:16 Simple dependency injection to replace global autoloads 21:23 Busting up the signal hub 22:25 Restructuring file system to express feature encapsulation 25:24 Unit testing, now much easier due to our changes 28:56 Conclusion See also:    • Better, faster GDScript through Static Typing