| I don't think it's a fallacy. As someone who has 2 WIP games in Rust, I noticed that getting a very minimal gameplay prototype was pretty easy (given a sane engine choice)* but then adding features made the code balloon in size. Switching from singleplayer to multiplayer was a mess. I also fell for some fads and had to waste time removing them. And Rust really, really doesn't like heavily interconnected graphs of game objects where a game event can lead to updating multiple other types. There is friction in everything. One choice was to just live with it and write slightly more code. The other was trying to find some systematic solution that would take more code upfront and save me time later. I chose the second options, went through some experiments but it feels like the breakeven point is way further than makes sense for a small one-person project. *Even within one language, there can be order of magnitude differences. Rust has 2 usable 3D engines, one is well known, has dozens of contributors and gets donations that can supplant a Bay area salary. The other is written by mostly one guy who alternates between living from savings and working full time. The first engine heavily focuses on advertising and has been promising various features for years with little to show for it. The other is ahead in both number of features and implementation quality. I think it's attitude. Some people code for the fun of it, some people have a clear goal in mind and focus on achieving it, some code for money, some code for public recognition, etc. I don't think an ugly messy codebase is necessary but there's a productive middle ground. People who focus on showmanship instead are more likely to chase fads and fancy architectures. |