This video provides an in-depth, critical code review of a publicly available demo version of Pirate Software's game, Heartbound. The review is a direct response to the game's developer ("Thor"), who criticized a previous analysis for lacking specificity. Collaborating with an experienced GameMaker developer, the creator examines code extracted from the game's 2018 demo, cross-referencing it with the current version to confirm the persistence of major issues.
The review categorizes problems by severity. The most significant issue is an extremely inefficient, per-pixel lighting engine that performs tens of thousands of redundant collision checks per frame, resulting in abysmal performance (<20 FPS, 99.6% performance usage in a benchmark test). This is contrasted with an industry-standard, surface-based lighting method that uses a fraction of the resources (0.24%). The video also highlights a "medium" severity issue in the dialogue system, which embeds all text and logic in hardcoded, unscalable 2D arrays within the game's code files. Minor issues discussed include the presence of useless code, unexplained "magic numbers," and unsafe file I/O operations that lack error handling. The video's central thesis is that the code's quality is highly incongruous with the developer's claims of having over 20 years of experience in the game industry.
A Critical Code Review of Pirate Software's Heartbound Demo
0:10 Context for the Review: The creator, "Coding Jesus" (CJ), is making this video to provide a more specific, evidence-based code review in response to criticism from Pirate Software's developer ("Thor") that a previous review was too general.
1:32 Code Source and Relevance: The code being reviewed was extracted from a 2018 demo of the game Heartbound, which was publicly distributed by the developer. CJ confirms that the major issues identified in this older code are still present in the current, publicly available demo.
2:50 Major Issue: The Lighting Engine: The game's lighting engine is identified as a major performance bottleneck. It works by looping through every single pixel of a sprite, performing multiple collision checks per pixel to determine if it should be drawn as light.
Key Takeaway: For a 128x128 pixel sprite, this method can result in nearly 100,000 collision checks per frame, per light source, which is extraordinarily inefficient and leads to severe lag. The code is also duplicated for different directions instead of being generalized.
4:39 A More Performant Solution: CJ brings in a GameMaker expert, "Level 5 Fish," to explain the industry-standard approach. This method uses surfaces (essentially, invisible canvases) to create lighting effects. Objects create "cutouts" on one surface, and light gradients are drawn on another. The surfaces are then combined, a method that is drastically faster.
9:47 The Benchmark Proof: A side-by-side benchmark shows the dramatic performance difference.
Pirate Software's Method: Runs at less than 20 FPS and uses 99.675% of the system's performance to render a single large light beam.
Industry-Standard Method: Runs at a stable, high FPS and uses only 0.238% of the system's performance for the same visual effect.
12:37 Medium Issue: The Dialogue System: The system for handling in-game dialogue is bloated and not scalable. Dialogue for every language and scene is stored in large, hardcoded two-dimensional arrays directly inside code files.
Key Takeaway: A better practice is to use external data files (like JSON), which separates the dialogue data from the game logic, making it easier to manage, localize, and scale. The system also uses confusing "magic numbers" to reference characters and emotions for voice lines.
15:30 Minor Issues: Several smaller but still significant problems are highlighted:
(15:30) Useless Code: The codebase contains dead code, such as a switch statement that has no effect.
(16:22) Unexplained Constants: "Magic numbers" are used frequently instead of named constants, making the code difficult to read and maintain.
(17:02) Unsafe I/O Operations: The code attempts to read and write files without first checking if the file exists or if it has the necessary permissions, leading to a risk of crashes.
17:30 Overall Conclusion: CJ argues that while these mistakes might be understandable for a beginner, they represent a "massive incongruity" for a developer who claims to have over 20 years of experience. The code does not reflect the level of expertise that the developer professes to have.