5 ms·

> I'm pretty sure the initial Quake engine was harder to write than getting the requirements right for said engine for example. Gamedev is historically an outl

> I'm pretty sure the initial Quake engine was harder to write than getting the requirements right for said engine for example. Gamedev is historically an outlier because the technical requirements are relatively obvious: keep FPS above a minimum, and latency low. Actual game content is highly flexible, but performance cannot be compromised. By contrast, enterprise and industrial systems have far more specific requirements that must be identified and satisfied, including domain logic, security and safety.

zzzzzzzza 3y ago
in an ideal world the code is the best, first, and foremost specification of the requirements. you should be able to parse the abstract syntax tree and just look at top level definitions to get a good overview.
syntheweave 3y ago
Games have two other elements that make them an oddball: 1. The data integrity mostly doesn't matter. Crashes, corruption, whatever. Just throw playtesting at it until it kind of works. Higher discipline than that is only needed for multiplayer. 2. Most of the engineering exists to support a pipeline to create, load and render specific assets at a specific level of dynamism, ranging from "menu text" to "skeletal animation" to "character creation". It's the definition of what an asset is or can be, and how dynamic it has to be, that can make the difference between "days" and "years" of development. A team that can argue its technical case eloquently can chop out the most expensive kinds of assets, make extremely shoddy tools to help deliver the ones that remain, and still end up with an engaging experience. When we discuss old engines like Quake, the genius in them is primarily in finding exactly the right specification of assets to hit the target machine of the time while achieving previously unprecedented levels of detail. It's easy to make a game on modern hardware run at 500hz if you stick to rendering Atari 2600-grade scenes - it's the additional detail that turns it into a major project to hit 30hz. Today the burden in games has shifted away from the runtime performance costs of a scene - since there are a lot of standard methods of getting an acceptable result, including entire engines with level-of-detail systems to help automatically downgrade graphics - and towards the production cost of achieving detailed assets, which is more in the realm of what technical artists now do as a dayjob.

zzzzzzzza 3y ago

in an ideal world the code is the best, first, and foremost specification of the requirements. you should be able to parse the abstract syntax tree and just look at top level definitions to get a good overview.

syntheweave 3y ago

Games have two other elements that make them an oddball: 1. The data integrity mostly doesn't matter. Crashes, corruption, whatever. Just throw playtesting at it until it kind of works. Higher discipline than that is only needed for multiplayer. 2. Most of the engineering exists to support a pipeline to create, load and render specific assets at a specific level of dynamism, ranging from "menu text" to "skeletal animation" to "character creation". It's the definition of what an asset is or can be, and how dynamic it has to be, that can make the difference between "days" and "years" of development. A team that can argue its technical case eloquently can chop out the most expensive kinds of assets, make extremely shoddy tools to help deliver the ones that remain, and still end up with an engaging experience. When we discuss old engines like Quake, the genius in them is primarily in finding exactly the right specification of assets to hit the target machine of the time while achieving previously unprecedented levels of detail. It's easy to make a game on modern hardware run at 500hz if you stick to rendering Atari 2600-grade scenes - it's the additional detail that turns it into a major project to hit 30hz. Today the burden in games has shifted away from the runtime performance costs of a scene - since there are a lot of standard methods of getting an acceptable result, including entire engines with level-of-detail systems to help automatically downgrade graphics - and towards the production cost of achieving detailed assets, which is more in the realm of what technical artists now do as a dayjob.