8 ms·
What nobody told him is that it doesn't matter. The most beloved games have the shittest code. The goals of getting a job in the industry, and making a game pe
by andai 7mo ago
What nobody told him is that it doesn't matter. The most beloved games have the shittest code.
The goals of getting a job in the industry, and making a game people love, have completely different requirements, with surprisingly little overlap.
---
As for the latter (game industry requirements) I read this article a while back.
https://lazyfoo.net/articles/article11_top-ten-mistakes-game-programmers-make/index.php https://lazyfoo.net/articles/article11_top-ten-mistakes-game...
There's a great list of Fundamentals halfway through. Though I have no frame of reference for how reasonable it is. (Is the average game dev really expected to implement a rigidbody sim from scratch?)
- deleted 7mo ago[deleted]
- jordand 7mo agoThere's numerous studios across the games industry that have high coding standards, mandatory code reviews, and expect upskilling. Game complexity keeps increasing, and live service games in particular need to be stable and well maintained and very well engineered in the first place. For many games, the days of games being pressed to disk, shipped out and done with (where bad code is fine) are long gone.
- rawbot 7mo agoThey aren't long gone. There's a ton of very successful indie or AA games with shoddy development practices: https://www.reddit.com/r/programminghorror/comments/e0bub9/terrarias_source_code_is_an_interesting_one/ https://www.reddit.com/r/programminghorror/comments/e0bub9/t... A game isn't a fundamental or structural part of a system. In the end, it is just a game. The goal of a game is to deliver an experience. It doesn't need to be scalable or robust. If the experience isn't marred by bad coding or bugs, then it can still be a great game.
- jordand 7mo agoYeah all of that is always going to be true across hobbyists, indies and small studios. But for commercial game development at scale, where there's multiple studios or outsourcers/co-devs brought on, there's real expectations that people can be on-boarded quickly and work productively on projects with tight schedules. A poor quality, fragile codebase (usually with technical debt) is a recipe for disaster when things are at being worked on at that level.
- hannahstrawbrry 7mo agoI think it's odd to say that pressing to disk was more permissive of bad code. Releases like Cyberpunk suggest the opposite- that development teams selling games that can be updated take that into account as they plan and release, and the quality suffers upon launch for it.
- jordand 7mo agoYeah I understand what you mean. For bad code in that sense, I'm mainly thinking back to games work colleagues have worked on (in the era when patching wasn't possible) where horrible one-time hacks and weird workarounds get quickly thrown into a codebase under deadlines and crunch just to get things fixed, platform certified, and shipped. Games in the past were more often using in-house/proprietary engines too where this would happen too under pressure. With patching ubiquitous, QA still have a really difficult job especially with nearly every release being multi-platform.
- ivanjermakov 7mo ago> The most beloved games have the shittest code Do you have data supporting that? My favorite games (Factorio, Noita, Song of Syx to name a few) all share in common devs' passion and expertise. I don't have any example of a good game with shitty code.
- sudokatsu 7mo agoThe Simpson’s Hit & Run and Fallout 3 come to mind
- cubefox 7mo agoThere are countless great games with a lot of bugs and performance problems. Maybe most of them have pretty code behind the scenes, but I doubt it.
- DonHopkins 7mo agoI had an experience developing The Sims 1, which confirms the "Worse is Better" hypothesis, which is a harsh reality of the games industry and the software development industry in general: I pointed out to my manager that the code was shit, and we really needed to clean it up before shipping. So he sat me down and explained: "Don, your job is TURD POLISHING. If you can just make your turd nice and shiny, we will ship it, and everybody will be happy with you, because that is what we hired you to do." But then at least he gave me a few weeks to clean up and overhaul the worst code. The moral is be careful what you ask for, or you might have to be the one who shovels out all the shit. https://donhopkins.com/home/TheSimsDesignDocuments/TDSEditToDo.pdf https://donhopkins.com/home/TheSimsDesignDocuments/TDSEditTo... https://donhopkins.com/home/TheSimsDesignDocuments/ComprehensiveArtAssessment.pdf https://donhopkins.com/home/TheSimsDesignDocuments/Comprehen...
- LarsDu88 7mo agoI feel there was a very narrow time window in the 90s when a bunch of game franchises were started where the devs could get away with shipping stuff with a ton of bugs. The first two Fallout games come to mind. So does the original Deus Ex. This is definitely the exception not the rule though! Hardware constraints weed out shitty (or at the very least suboptimal) code very quickly. This is the exception not the rule however. If there's one unifying thing about games that succeed despite major issues with the code its that the developers tend to have extensive experience playing board games and can make a compelling gaming experience without having a game with all the bells and whistles.
- catmanjan 7mo agoI think maybe that was just when YOU were playing games, because games today still ship with tons of bugs - it usually isn't until a few years later that there is stability
- georgeecollins 7mo agoYeah try some early access games! I also don't remember thinking the games he mentioned were particularly buggy at the time. They worked fine for me on my PC. Why are you so sure they were unusually buggy? Just curious. You may be comparing what you heard to what you have seen.
- jeremyjh 7mo agoWhat TFA describes is not someone who wrote poor quality code, but someone who could write no code at all, before the era of AI.
- OkayPhysicist 7mo agoThat list missed the biggest mistake all Game Programmers make: They write code for the games industry. If you can program a videogame, you can program a shitty webapp, and the shitty webapp industry pays twice as much. Video games are great, but that's an argument for making your own game, not working for the soulless meatgrinder that is the games industry.
- alfiedotwtf 7mo agoNot everything is about money.
- OkayPhysicist 7mo agoWorking a job is about money, but even besides that the gaming industry has downright abominable conditions relative to the rest of tech. You get treated worse, paid worse, and none of it matters because there's an endless line of dumbass college kids behind you who are absolutely stoked to be treated like shit because they learned to program because they loved Call of Duty.
- alfiedotwtf 7mo agoWorking a “job” is about money, agreed. But from another perspective, we’re actually getting paid to work on our hobbies full-time.
- InexSquirrel 7mo agoI was thinking about this too, and I think there are two different views you can take. 1. Do you want to work IN the games industry? 2. Do you want to make and ship your own games? I think the overall internal engineering standard for #1 is higher, because you're ultimately assessed against that standard by others. For #2 _as long as it works_, you can get away with some under the hood crap, but you're the one that suffers for it (and hopefully not your players). I think I'd be wary (as I'm wary of this for myself), that aiming for #2 gives you an easy out to produce crap, as no one is holding you to standard other than yourself. Doesn't mean you shouldn't do it obviously, but it's a risk.