How slow would something like this be, had someone tried to make it for a 386/486 era computer? Like, could have this technique been used effectively for 3d games of that era?
Well, the engine already uses a lot of tricks from that era as far as I can tell: it's isometric, so "fake" orthogonal 3D, and uses sprites with different angles to view them from under the hood for the buildings and trees. It then renders all of this to ASCII with WebGL, which I presume generates a sprite-sheet.
Also keep in mind that games like Zarch[0][1] (aka Virus[2]) already existed in 1987. The ASCII actually hides the fact that we have a low rendering resolution, which may help a lot here.
So I think the main limitation might be the tricks required to render to ASCII, and time it takes to display those ASCII characters. Assuming the implementation tries to make a pure text-based renderer instead of a bitmapped one.
Searching on pouet.net for "ASCII" doesn't reveal many demos[3], but the few that exist look pretty cool[4][5]. They lack separate foreground/background colors though, which bring up one important point: what terminal are you targeting?
Anyway, I'm pretty sure there are more demos out there that basically render to the console but I don't remember the names right now so can't find them.
Not necessarily, depending on what you mean with 3D (although one of the other comments definitely proved it).
If you mean "uses WebGL to render 3D polygons", then there are other possible solutions, like the isometric approach I mentioned before. Given that the developer wants to target linux terminals[0] he is likely to come up with his own rendering scheme, probably not unlike the old software 3D engines of the late eighties/early nineties (like the aforementioned Zarch, or later Bullfrog games like Powermonger and Syndicate 2)
Shrink your browser window until you see this running at about 80x70 characters, then ask your second question again. Modern displays are a lot higher resolution than SVGA.
