I think the key element here is that it describes a moment where the problem space opened up and original engineering became necessary. When this happens, programmers tend to swarm over the problem for a few years, doing a ton of invention, until it's been heavily covered; and then afterwards the majority use an off-the-shelf option, with a few experts who stick behind and do maintenance.

This cycle defines technologies that are in their earliest stages, but as it becomes more of a commodity, the MVP comes to the forefront, since it allows marketing to lead the technology from the beginning.

With game engines, the problem space is ultimately specified by game design ideas, so it's extremely easy to enter the territory of invention by coming up with something that hasn't been done and saying "I will be the first one to do that!" At that point you have no alternative but to reach the black triangle, and once you've reached it, that's the engine. That point is the starting line for a commodity-code project. Everything after that is the "other 90%" of making it fleshed out and usable.

Hahahahahaha, 'MVP' doesn't exist in hardware or low-level hardware coding (e.g. this, which is a playstation game that presumably runs bare-metal).

In hardware, it's generally like ~80% of the design work before you even have a viable demo. If you're writing a bare-metal rendering engine, it's very much the same. MVP isn't used because there is none of the infrastructure even available to have one.

TL;DR MVP isn't possible if you don't have the infrastructure.

Not sure I agree. It is certainly possible to hack up the basic functionality of an embedded system; full of magic numbers and lacking the elegant hardware abstractions, OS layer and power management we all want.

Edit: Not to mention in hardware, where you can neglect design for manufacturing, solder modwires everywhere, and power everything off a 10kg power supply. MVPs do exist in hardware and embedded SW.

I think there's a difference between an MVP and a proof of concept.

You can hack together a one-off PoC for a hardware feature, in order to know the feature is viable--but what you've created isn't a viable product, minimal or otherwise. With an MVP, you'd expect to be able to incrementally improve the design into a non-minimal one, but with a PoC there's no real way to take it and "refactor" it into a shipping product at all. The design with modwires and a 10kg power supply (or the embedded-software equivalent) doesn't share any similarities, except at the most abstract level, with the design that can be mass-manufactured.

Once you're done experimenting and you know what you want, you really do need to design the "production model" from the top down, with all the layers that will enter into the solution considered in advance.

A concrete example: you can't just "write a voxel renderer" and then expand it into a full game engine. If the full game engine will have a rendering pipeline with support for things like dynamic lighting and fur physics, then voxel rendering will be implemented in that engine in a completely different way than in one that only needs to render voxels.

Editing one into the other would be like editing the code defining a b-tree into code for a hash-table: there would be exactly one edit, which would replace all the old lines with entirely new ones.

Cutting edge 3D game engines are incredibly complex pieces of software, and this was at the beginning of the 3D game revolution where there weren't any third party engines available, no one really knew what they were doing, and most developers didn't even have internet access; you did almost everything in house or you didn't have a game. It was completely uncharted territory, not some #yolo agile web development thing where 99% of the engineering effort is already done for you and you can just focus on the content.

This was a long time ago (1994), but even today, if you're writing a 3D renderer from the ground up, your polys are gonna pass through a big ol' pipeline to get onto the screen. No way around it.

What's to say this isn't the MVP?

Anyway, you don't want to be iterating on this stuff too much once it's rolled out - it tends to make the art team unhappy. They'd far rather work without the tools constantly changing underneath them.

Game programming does have engines and frameworks to get you off the ground quickly, and the early access stuff definitely feels like an equivalent to the "MVP first, iterate later" approach. This approach is only recently becoming viable because of digital distribution on PCs and on consoles. Before that you shipped a disk, and that was it. So you didn't get the chance to do any real iterating.

It wasn't until maybe 5 years ago that the out of the box engines were any good. Before that you either had to pay a lot of money (Unreal Engine, id Tech, Cryengine... also Flash!) or you rolled your own stuff out of the libraries that were lying around (Ogre3D, OpenAL, irrlicht). Once Unity and other engines with low entry points became common, things got a lot better.

But game programming also frequently runs into another issue: performance. Your whole game world has to update in 16-33 milliseconds, so you end up dealing with some very low level problems because fitting everything into 16ms can be really hard. Just take Minecraft as an example.

There are some problems where you just have to write a lot of groundwork before you can see anything for it and pushing something out fast wouldn't really have any benefit.

I think black triangles are only really possible if you're working on software architecture - that bit when you "go into the tunnel" and are working in purely abstract space comes with such a payoff once you reach your project's "black triangle". There's really nothing like it, it's a great feeling!

Some things can't by MVP'd, like a game engine, or a car.