An Adventure in Pre-Rendered Backgrounds (2019)
jmeiners.comWe're using Blender to pre-render 3D assets into 2D ones for our upcoming top-down survival horror arpg. (Link in bio for the curious.) It's worked well for us overall. That said, it definitely adds a lot of complexity, and if you're ultimately making a 2D game it adds a whole new, complex tool to learn and integrate. Case in point the incredible efforts described in this article to create the cube map or depth buffer!
I will say, we solved the draw order problem a different, easier way by adopting a fixed ortho perspective and rendering objects as spritesheets/tiles. We can then author levels using conventional 2D methods. Objects now sort by their pivot's Y value, more or less, so walking behind things isn't an issue.
Seeing the Cave Story screenshot has me thinking, there might be an especially good opportunity for pre-rendered side-scrollers... Just entirely eliminate whole classes of problems, plus you easily bring back some of that animation-inspired back/mid/foreground goodness.
Not sure how the author wrote an entire article on pre-rendered backgrounds in gaming without once mentioning Baldur's Gate / Infinity Engine games, of which the developers largely pioneered this with DirectDraw API.
There might be a certain threshold of foreground/background integration in your favorite example, but the games mentioned as examples predate Baldur’s Gate, which kind of answers your question, right? If we’re talking about just the concept of a pre-rendered background, games have done that since the early 70s or earlier.
Great write up! I still don't really see the point in pre-rendered backgrounds for PC/console games anymore though. GPUs nowadays are powerful enough and storage space is limited enough that you can just render everything realtime and it will look great.
The technique does seem like it would be a great fit for mobile, where users have limited control and efficiency is really important.
The point is an ability to pre-compute a complex environment, playback that complexity at runtime, enabling the runtime's compute load to include that while devoting more compute to the real time rendered characters and effects than would be possible otherwise.
I did a pre-rendered background 3D game on the PlayStation 1. We had an operating steel mill as an animated background, with high resolution characters pre-rendered to 3D cards, plus z-buffer data for both so the characters could pass behind background set elements, and when characters fight their geometries overlay/penetrate correctly. Using the PSX MDEC video, we could have up to a dozen background frames. That enabled the giant rotating gears and assembly lines of the steel mill to 'operate' with 3-6 frame loops, and each game level to support multiple perspectives (camera views) of the action. Each camera view could be hundreds of millions of polygons, all precalculated to 2D elements, and the final game engine treating the hardware as more of a real time compositing engine (with a 3D simulation running logically in parallel.)
The game was not popular, misunderstood at the time, and the studio was a film VFX studio whose staff did not like being put on the game production. There were 75 levels and it had quite the large team for the time, about 45 animators, 15 level developers, and 6 engine developers. https://www.youtube.com/watch?v=n9w1e7D5ucY
Big Atlus fan. I'll try this game, thanks for the interesting history!