I have some friends in game dev who have shipped some pretty big titles (and still do). They have very similar sentiments with regards to constant self-inflicted breakages and (lack of) testing and code reviews as well.
It’s given me an appreciation for the kind of code quality everybody just naturally agreed on and did back when I worked at a FAANG. Nobody needed to be convinced to write/maintain tests for their change, or be told to keep the mainline branch building cleanly.
I wonder if any of the large studios out there today have a culture of testing and reviews?
Reviews are fairly common but unit tests not so much, in my experience. CI is commonplace in all but the smallest studios, and automated testing (such as running the game after building and performing checks) is quite common; some productions use bots to simulate players.
It varies by company and project and also the stage of development. Avalanche sounds particularly chaotic though.
Really interesting to get some perspective on how Avalanche worked before I joined the Stockholm tools team, right around as JC4 was being wrapped up. The few peeks I got at the Python editor code gave me nightmares and I was very happy to work in the C++ and Qt version instead.
I think "crunch culture" in gamedev will always be its downfall. Especially in double-A studios that seem to end up with over ambitious projects where with scope creep and lack of direction, the sunk cost ends up too great to steer away from. Either you release what you've got, or throw it all away.
That post and the discussion in the blog comments were useful when I was interested in speeding up astar pathfinding (30% speedup of the whole search algorithm by replacing binary (2-ary) min heap with a min heap using a 4-ary tree).
That's basic knowledge in civil engineering. You can look up every text book.
* Lack of curvature control
Catmull-Rom splines pass through all control points, which sounds great, but the curvature between points is determined automatically. For roads, you need precise control over minimum curve radii for safety and vehicle dynamics - tight curves require reduced speed limits and proper banking.
* No arc length parameterization
Catmull-Rom splines are parametric (0 to 1 between points), not arc-length parameterized. This means equal parameter steps don't give equal distances along the curve, making it tricky to place lane markings, guardrails, or calculate exact distances.
* Curvature discontinuities
While the curve itself is smooth (C1 continuous), the curvature can have abrupt changes at control points. Roads need smooth curvature transitions for driver comfort and safety - sudden changes in steering wheel position feel jarring and can be dangerous at speed.
Better are:
* Clothoid/Euler spirals - Linear curvature change, standard in highway design for smooth transitions between straights and curves. I prefer clothoids
* Cubic Bézier curves - Better curvature control with tangent handles
* B-splines - Smoother curvature, don't pass through all points but more predictable
* Circular arcs with transition curves - Traditional civil engineering approach. Nice, but not for fast speeds. And I struggled with it constantly algebraicly.
I absolutely loved JC2 and JC3 with more than 500 hours in each! Despite the author's thoughts that the games were a buggy mess, I feel like I never noticed the bugs in JC2 and the very literal road bumps in JC3 were only problem when I was doing laps around the first island out of boredom.
I could never quite put my finger on why the large island felt so... empty? in the north, but it being canceled for most of the development cycle is an insight I never thought I'd have, so thank you very much for the insight.
The volumetric terrain of JC3 was an awesome improvement on JC2, with the second island being very for the terrain and vertical bases.
I tried JC4 and it was disappointing... It never clicked with me and (just like the author) I felt it was worse than JC3 in almost every way.
Major thanks to the author for the blog post, growing up and working in software I really appreciate the perspective and both Avalanche studio and the author for their work on these two awesome and timeless games. Despite the apparent hell of development, playing it always felt magical to me (maybe not the car handling in JC2 but I digress) <3
Yeah, I feel the same way. JC2 and JC3 are great. Never clicked with JC4.
I had always thought the north island was empty because it was used for the train mission. Like, the island existed as a backdrop for a few missions near the end of the game.
Also nice to hear that the devs also thought the wingsuit was overpowered. That’s part of what I like about JC2: no wingsuit.
> when I was doing laps around the first island out of boredom.
I spent hundreds of hours driving around the Just Causes with a podcast on. In versions 1,2 and 3, I circumnavigated every single island along the coast.
Yes these games are buggy (but got better each release), but they are so much fun.
Mad Max is incredible as far as licensed tie-in games go. Yeah it's a bit repetitive and has a bit of the Ubisoft "map-full-of-icons" shit but still, it's so approachable and so fun. Also it fucks unreasonably hard on handhelds.
I have some friends in game dev who have shipped some pretty big titles (and still do). They have very similar sentiments with regards to constant self-inflicted breakages and (lack of) testing and code reviews as well.
It’s given me an appreciation for the kind of code quality everybody just naturally agreed on and did back when I worked at a FAANG. Nobody needed to be convinced to write/maintain tests for their change, or be told to keep the mainline branch building cleanly.
I wonder if any of the large studios out there today have a culture of testing and reviews?
Reviews are fairly common but unit tests not so much, in my experience. CI is commonplace in all but the smallest studios, and automated testing (such as running the game after building and performing checks) is quite common; some productions use bots to simulate players.
It varies by company and project and also the stage of development. Avalanche sounds particularly chaotic though.
I've never seen any unit tests in my career in games. I'm not terribly convinced it would be helpful.
Code reviews are a constant at everywhere I've worked.
Really interesting to get some perspective on how Avalanche worked before I joined the Stockholm tools team, right around as JC4 was being wrapped up. The few peeks I got at the Python editor code gave me nightmares and I was very happy to work in the C++ and Qt version instead.
I think "crunch culture" in gamedev will always be its downfall. Especially in double-A studios that seem to end up with over ambitious projects where with scope creep and lack of direction, the sunk cost ends up too great to steer away from. Either you release what you've got, or throw it all away.
That was a great read, it's not often we get to read thoughtful retrospectives.
Tangent: the author's older posts also contain some gems -- I very much enjoyed this one about heaps: https://probablydance.com/2020/08/31/on-modern-hardware-the-...
That post and the discussion in the blog comments were useful when I was interested in speeding up astar pathfinding (30% speedup of the whole search algorithm by replacing binary (2-ary) min heap with a min heap using a 4-ary tree).
> I could write a lot about why you don’t want to use Catmull-Rom splines for roads.
I would read this essay, and share it with my friends.
That's basic knowledge in civil engineering. You can look up every text book.
* Lack of curvature control
Catmull-Rom splines pass through all control points, which sounds great, but the curvature between points is determined automatically. For roads, you need precise control over minimum curve radii for safety and vehicle dynamics - tight curves require reduced speed limits and proper banking.
* No arc length parameterization
Catmull-Rom splines are parametric (0 to 1 between points), not arc-length parameterized. This means equal parameter steps don't give equal distances along the curve, making it tricky to place lane markings, guardrails, or calculate exact distances.
* Curvature discontinuities
While the curve itself is smooth (C1 continuous), the curvature can have abrupt changes at control points. Roads need smooth curvature transitions for driver comfort and safety - sudden changes in steering wheel position feel jarring and can be dangerous at speed.
Better are:
* Clothoid/Euler spirals - Linear curvature change, standard in highway design for smooth transitions between straights and curves. I prefer clothoids
* Cubic Bézier curves - Better curvature control with tangent handles
* B-splines - Smoother curvature, don't pass through all points but more predictable
* Circular arcs with transition curves - Traditional civil engineering approach. Nice, but not for fast speeds. And I struggled with it constantly algebraicly.
I absolutely loved JC2 and JC3 with more than 500 hours in each! Despite the author's thoughts that the games were a buggy mess, I feel like I never noticed the bugs in JC2 and the very literal road bumps in JC3 were only problem when I was doing laps around the first island out of boredom.
I could never quite put my finger on why the large island felt so... empty? in the north, but it being canceled for most of the development cycle is an insight I never thought I'd have, so thank you very much for the insight.
The volumetric terrain of JC3 was an awesome improvement on JC2, with the second island being very for the terrain and vertical bases.
I tried JC4 and it was disappointing... It never clicked with me and (just like the author) I felt it was worse than JC3 in almost every way.
Major thanks to the author for the blog post, growing up and working in software I really appreciate the perspective and both Avalanche studio and the author for their work on these two awesome and timeless games. Despite the apparent hell of development, playing it always felt magical to me (maybe not the car handling in JC2 but I digress) <3
Yeah, I feel the same way. JC2 and JC3 are great. Never clicked with JC4.
I had always thought the north island was empty because it was used for the train mission. Like, the island existed as a backdrop for a few missions near the end of the game.
Also nice to hear that the devs also thought the wingsuit was overpowered. That’s part of what I like about JC2: no wingsuit.
> when I was doing laps around the first island out of boredom.
I spent hundreds of hours driving around the Just Causes with a podcast on. In versions 1,2 and 3, I circumnavigated every single island along the coast.
Yes these games are buggy (but got better each release), but they are so much fun.
Great read. It's a reminder of the costs of building custom game engines in smaller studios.
I really enjoyed Avalanche's Mad Max game, and Generation Zero was an interesting idea if imperfectly executed.
Mad Max is incredible as far as licensed tie-in games go. Yeah it's a bit repetitive and has a bit of the Ubisoft "map-full-of-icons" shit but still, it's so approachable and so fun. Also it fucks unreasonably hard on handhelds.
It's my favorite game of the last generation. They managed to capture the "empty desert" feel unlike any other game.
Ansel Adams pictures of New Mexico get similar feelings right
Note: this is not about/not to be confused with Avalanche Software [1]; another video game studio that started in the 90s.
[1] https://en.wikipedia.org/wiki/Avalanche_Software