Watching speed runners play through games is a great way to visualise not only this aspect (that games are flimsy at best), but to visualise the same practice in any software - if you don't code defensively, often a simple mis-input breaks the game.<p>A common pattern in many speed runs is finding some glitch through a door, and then the game logic kicks in and says "you are past this door, so you must have got the key".<p>If you are curious, watch the five or so minutes of this speedrun: <a href="https://youtu.be/0Ct8n1CClUM?t=3072" rel="nofollow">https://youtu.be/0Ct8n1CClUM?t=3072</a> First, the player jumps through a game world, getting to a race he shouldn't be able to get to yet. Second, he glitches into the "solid" wall, which is just a thin wall around the racetrack.
Ex-Game dev here: shipped many titles on console (AAA and some zzz titles).<p>When comes time to shipping a game, the crunches, pressure and overall stress is through the roof. Most everything goes at that point: duct tape, hot glue, bobby pins and toad spit. And if you disagree with management over these 'not so best practices' (in order to ship faster...) they will find someone to do it and you could be out of a job.<p>That being said I would not trade my time in that industry for anything else. It's basically the BUDs of programming (of course I'm biased)<p>Good times!
I run a small MMORPG and I'm considering open-sourcing the whole thing but the code is a complete mess. The source code of VVVVVV is a work of art in comparison.<p>What holds me back are 1. I'm ashamed to reveal the monstrosity 2. I'm afraid the code is too messy for anyone to be able to make contributions 3. it will make it much easier for hackers to find exploits.<p>It's a shame because I think the game would be really cool as an open source project.
As a counterpoint, the Quake -> Quake 2 -> Quake 3 original open source releases are remarkably clean. Quake 2 in particular is very minimalist and the game was developed in something like 10 months.<p>Granted, it's not really fair to compare anyone to the id software team of the time. But the requirements of the Quake series, basically a BSP renderer that is easy to modify and extend, probably forces it to be extensible and clean.
A friend of mine in gaming though had an insight I found illuminating. The difference with games though is that there’s often an element of “One and Done” in that unlike much of web development, the starting from scratch for the next generation is more of a given. There is less need for long term support as games are expected to meet its twilight much sooner. With web development however, it is a regular risk assessment and there must be a true meeting of minds to decide that a rewrite is worth it.
I think code quality is important, and big studios make a buck on having clean and workable code they keep improving over time.<p>That being said, and especially on indie games like VVVVVV, hammering in a cool little detail gives the final product much more value than having clean code.<p>That's why big engines with mature coding patterns sometimes are not the way to go to make a cool little thing. Making novel mechanics (e.g. time reversal in Braid, or the super tight controls of Super Meat Boy) with an existing engine, while possible, would probably be a PITA.<p>The "hackability" of the engine you use can allow you to be more creative, even if a bit messy to maintain.<p>Back in the days of flash, I'd probably use a simple display list engine (flixel comes to mind) to do the heavy lifting, and hack away with those basic building blocks.<p>Nowadays, I was surprised by the relative hackability you get with godot[0], while still being able to tap into what you can call a mature engine. If you like to make small games, you owe it to yourself to check it out.<p>[0]: <a href="https://godotengine.org/" rel="nofollow">https://godotengine.org/</a>
Writing hacky code can be liberating though. I really enjoyed hacking together things in the pico-8 last year. Globals? Fine. Neat function names? Nah. Variable names? 'a' will do.
Wow a 3440 line switch statement for processing game state!<p><a href="https://github.com/TerryCavanagh/VVVVVV/blob/master/desktop_version/src/Game.cpp#L605" rel="nofollow">https://github.com/TerryCavanagh/VVVVVV/blob/master/desktop_...</a>
When you are making a game, priority number one is always that you are indeed making a game, and not how.<p>(substitute "game" for anything you want to do)<p>I love elegant code, but in the end it's never _more_ important than the game itself.
This is very true.
I created an open source framework to help developers build scalable real-time systems and I tried to focus on multiplayer games at one point; I thought it would be a good idea to ride the wave of web-based multiplayer .io games by targeting those developers but I ended up realizing that they're better off just using raw WebSockets. My framework could only help in terms of producing the initial prototype.<p>The profit margins on ad-sponsored web-based multiplayer games are paper thin. They don't care about code structure or cleanliness at all. If someone can make fugly code that performs 10% better, that can make the difference between a profit or a loss or it can mean doubling profits/earnings from the game.<p>This is very different from most software businesses where even a solution that performs 10x worse is still acceptable if it makes for cleaner code that is easier to maintain and can handle changing requirements better.<p>Micro-optimizations and clean code are mutually exclusive IMO. Like for example, people may be tempted to send JSON objects with nice descriptive properties like 'direction', 'keyCode', etc... But in the end it's faster to just send a raw string or binary packet without any property names; just pass raw integers directly in a certain order and the receiver decodes the message assuming a certain order. This is extremely inflexible at the protocol level but it performs really well (I.e. you can't easily add new properties later or make some of them optional without breaking the current protocol).
Games, websites, and everything else - both Apple [1] and Dropbox [2] got passwords wrong in the last decade. I am in awe of the NASA programmers who have virtually no bugs [3].<p>[1] <a href="https://www.theguardian.com/technology/2017/nov/29/macos-high-sierra-bug-apple-mac-unlock-blank-password-security-flaw" rel="nofollow">https://www.theguardian.com/technology/2017/nov/29/macos-hig...</a><p>[2] <a href="https://www.cnet.com/news/dropbox-confirms-security-glitch-no-password-required/" rel="nofollow">https://www.cnet.com/news/dropbox-confirms-security-glitch-n...</a><p>[3] <a href="https://www.fastcompany.com/28121/they-write-right-stuff" rel="nofollow">https://www.fastcompany.com/28121/they-write-right-stuff</a>
I'm sure there are oodles of creators out there who hold back their source code because they don't want to deal with being shamed. We should be using these opportunities to learn and grow together, and not as a soundboard to feel good about how much better we are than someone else.
Someone posted this talk by Johnathan Blow on a story a week or two ago and it seems worth sharing here:<p><a href="https://www.youtube.com/watch?v=pW-SOdj4Kkk" rel="nofollow">https://www.youtube.com/watch?v=pW-SOdj4Kkk</a>
I've never thought about it but it makes a lot of sense. Just thinking about the few times I had to write some hacky code to get something to work and given the complexity of video games it is kind of expected.
This I what made the 1990s era games so full of non-critical bugs AKA "glitches".<p>The ceiling of complexity was raised waaaay over that of the previous generation of tech, but the techniques used by developers didn't advance nearly as far.<p>So you have a lot of <i>if this value == this number, load this scene</i> (OoT) or <i>if this value is greater than this limit, cycle it back to the lowest possible value of the range</i> (Civ, Nuclear Ghandi)<p>Now, bugs in big games tend to be critical crashes because the tooling and techniques have standardized and caught up to the complexity ceiling
It's interesting to see how duct taping a game inside out can result in absolute success once you ship something valuable. It can be really thrilling and you can get away with it specially if you're working alone, which for me is the best work. It's another story entirely if you're on a team, coding together a product that must be maintained and improved for years. I work on both sides, and I can say that I only have real fun when I'm coding alone. Though learning to work in team is a great skill as well. I'm specially careful with code architecture and readability, but sometimes when you're on the flow, the zone, the code just flows as well;
So is almost every other piece of software. I would like to see an analysis of commercial closed source software on how many of then use good practices, have clean code etc. Not the ones that filled in the [] we y
use TDD in the CIO monthly questionnaire. Maybe I meet the wrong companies I have to work or integrate with, but in my experience it is not very far from 0% (but it is >0 luckily). I met one company last week who do everything right, but only for projects over 500k where over 10% goes into those practices, otherwise there is simply no money for the overhead...
The code sample they have there that is "messy" doesn't look that bad to me. The reality is that almost all the code that runs lots of important things is a complete spagetti.
> “Games aren’t just an ordinary piece of software, they are a complex beast that require many different disciplines to successfully ship, and often on timelines that require sacrifices to be made,” said game developer ...<p>Is this any different from any other type of software? What is this "ordinary" software that doesn't require different disciplines, or have timelines?
The real differentiation to games from most other software is just how little correctness actually matters. It arguably doesn't matter at all as long as it doesn't produce feel bad moments lost items or lost progress.
If AIs of today make a heap of code (if you say it's data, I say data is code is data) that is really a spaghetti of a code that happens to seemingly achieve a goal, maybe game developers are already a bit like that ;)
VVVVVV's code is still better than the source code of Descent - holy hell, was that codebase a mess in areas, and virtually no comments in the complex parts of the 3D engine...
Related from a few days ago: <a href="https://news.ycombinator.com/item?id=22011358" rel="nofollow">https://news.ycombinator.com/item?id=22011358</a>
Nit:<p>I wish people wouldn’t mention programming and computer science in the same essay, unless it’s something very technical such as discussing synchronization algorithms.<p>Most programming isn’t science. Most programming isn’t even engineering. Most programming is contracting or DIY tinkering.<p>We use ridiculous metaphors like constructing an airport, when most programmers are tradespeople working on renovations.<p>Have you ever inspected the work of a tract house builder? It’s awful and usually plays fast and loose with building codes.<p>When an indie teaches themselves to code, we get the same result as a homeowner teaching themselves to renovate. That’s not a bad thing, but nobody swapping ordinary outlets for outlets with USB-C ports is thinking about Maxwell’s equations.
I recently found myself trying to describe modern software techniques to a layman, who is a carpenter.<p>"Its like this - you're hired to build a house. First, you have to go get someone motivated to harvest the raw materials for you - designs, logic, etc. - which will then be turned into the 'raw wood' that holds up the walls and keeps the roof on. Then, when that person is busy getting the materials cut, you start building the tools you know you're going to need, to get the walls up and strung together. You don't have these tools yet, because you left all the previous ones you've worked with at a previous construction site. The reason for this is that you are going to use the tools to put the walls up, sure - but then you're going to glue all the tools in place to make sure the walls stay up. That glue is the most powerful stuff in the universe, but it will fail catastrophically if you don't put the tools at just the right angle in the glueball .."<p>Basically, you glue all the new tools together, cover them in wood, and leave them in place so that the thing doesn't fall over ...