Trends and creative decisions driven by technical limitations

[lazygecko]

This is a fun topic to think about. There's plenty of observations about particular recurring design choices or broader movements, that when you think about it, are very likely informed by various technical obstacles developers faced at any given time and finding out what works most effectively within that particular scope.

The most recent thing that came to mind for me was the whole rise and fall of the car combat subgenre. This type of game usually built around large open arenas with gun-mounted vehicles suddenly became very prominent during the early 32-bit era in the mid 90's with tons of different games coming out, but then seemed to peter out of the mainstream fairly quickly as the years dragged on. Could be that it was a fad with limited novelty that audiences just lost the taste for, but when you consider not only the limitations in 3D hardware at the time but also the general industry knowhow and experience with 3D game design, this genre really has "path of least resistance" written all over it. Consider how much work was involved at the time with designing a third person 3D character game, how many polygons it took to render characters, how to animate them and design the controls etc, against the equivalents for a car game.

Vehicles didn't take nearly as many polys to render at an acceptable fidelity, much easier to animate, and since cars are innately pretty clunky and there already being a couple of years with precedence we already had a pretty good handle on how a car was supposed to be controlled in a 3D environment. All of this I think made the industry just naturally pivot towards this type of game at the time, and as general 3D character games kept evolving with better iterations, car combat became less enticing as an easy template by comparison.

Remember when everyone made fun of western games being largely comprised of bald space marines around 10 years ago? I don't think this was just a cynical focus group demographics thing. I'm pretty sure I've seen at least one developer point out that this was just a result of being much easier to render and deal with in a game, and I can believe that. To this day hairstyles on characters often seem to be conveniently chosen to minimize technical obstacles, so you don't have to deal with hair clipping through the body/arms and stuff. Japanese 3D games seemed to have historically been kind of exempt from this rule during the PS2 to 360 era, but I also noted during this time that level design/environments seemed to be a lot more barren and simplistic compared to their western counterparts as if they wanted to dedicate more resources to the characters, so I think that lends some credence to the theory.



Here's an excellent video video explaining system-wide discrepancies in design philosophy on the PS1 and N64 respectively and how the differences in both 3D rendering and disc/cart storage methods heavily informed what kind of games were being made on each platform. Things like wide open spaces being more common on the N64 while constrained yet more varied/detailed spaces were common on the PS1.

 

[Barrel Cannon]

Elevators and long drawn out sequences where player control(and/or camera movement) is relinquished from the player, is a major design decision a lot of devs did to mask assets loading. I feel like it helped pacing sometimes but was disastrous in others. It's one thing that's still sort of been there in current games despite not always being there for masking loading anymore.

 

[lazygecko]

Elevators and long drawn out sequences where player control(and/or camera movement) is relinquished from the player, is a major design decision a lot of devs did to mask assets loading. I feel like it helped pacing sometimes but was disastrous in others. It's one thing that's still sort of been there in current games despite not always being there for masking loading anymore.

Click to shrink...

Masked loading segments are a classic and I don't think they're ever going to go away. The first game I can recall doing this is MDK in 1997, which had these long hallways inbetween level sections in order to seamlessly load in the next part without interrupting gameplay. That was quite unusual to see in a game running on PS1 (though I played the PC version) and I can't think of any games before it that did so. Symphony of the Night had the loading hallways inbetween castle segments of course, but it didn't feel entirely seamless.

 

[D.Lo]

Great thread! I love seeing machines' limitations pushed in creative ways. It made games very diverse back then because the limitations were on the first page of the design document.

Even earlier, eg with sound design - leaning into the Mega Drive sound chip as an instrument gave you Streets of Rage, vs some of the GEMS nightmares for people just trying to play midi stuff. Also see the issues with colour selection. As such making darker looking and edgier electronic sounding games became a trend, which also worked well for the edgy teens of the 90s, dragging the SNES with it despite it having different strengths.

Symphony of the Night had the loading hallways inbetween castle segments of course, but it didn't feel entirely seamless.

Click to shrink...

Especially when they literally say 'CD' at the top!

At least it was honest!

 

[lazygecko]

More SotN stuff

I found it a bit odd and jarring how the wolf form was a multi-jointed sprite with rotating limbs instead of being beautifully hand-animated like the rest of the game. But it makes sense when you think of it like this: After getting wolf form you are able to shapeshift into it at any time and any place. That means the art has to be cached in memory constantly given the limitations of the CD format. Storing bespoke animation frames for something you rarely ever use wouldn't have been very cost effective at all, so I can see why they did it this way instead.

Also see the issues with colour selection. As such making darker looking and edgier electronic sounding games became a trend, which also worked well for the edgy teens of the 90s, dragging the SNES with it despite it having different strengths.

Click to shrink...

Dark colors is actually where the greatest bottlenecks exist for the Genesis palette. You pretty much only have a handful of highly saturated blues, purples and browns within the darkest range of colors. Which is why games that did have a very dark color style (although there were exceptions with skillful artists who could convey the same feel using technically brighter colors) tend to use those particular colors so much on the system.

 

[Dan Thunder]

The fog in Silent Hill 1 was a great way to use the PS1's limitations in draw distance:

I'd also say that the limitations on PS2 really improved the atmosphere of SotC by making it feel that much more desolate:

 

[MysticGon]

The painted on faces and block hands from the PS1/N64 era. They couldn't model the faces and hands so instead we got these but they hold up even now I think.

 

[lazygecko]

The painted on faces and block hands from the PS1/N64 era. They couldn't model the faces and hands so instead we got these but they hold up even now I think.

Click to shrink...

It was the PS360 era when games truly made the jump en masse to fully modeled faces. After having watched a retrospective video on some of the worst games from the past 15 years, with those visuals in hindsight I must say that the early generation of modeled faces has arguably aged worse than the preceding era where people just plastered a facial texture over a mostly blank polygon plane. There's just something about that era in the mid to late 00's, and early 10's, where if they didn't get the rigging or animations right on the faces, holy shit does it look creepy as hell. It takes a lot more work to get things to a passable level when things are less abstract.

That also made me eat crow a bit with regards to Bethesda's faces for Oblivion. Sure, the heads and faces as a whole were pretty ugly as a whole, but at least they got the animations and expressions to look fairly naturalistic and didn't creep me the hell out. Especially when compared to the competition in 2006-2010.

 

[Barrel Cannon]

The painted on faces and block hands from the PS1/N64 era. They couldn't model the faces and hands so instead we got these but they hold up even now I think.

Click to shrink...

It blows me away how good the PS1 MM Legends (+tron bonne) still look. That art style was a really smart way to work around the limitations of the PS1 at the time and it still scales up really nicely today

 

[EarthPainting]

More SotN stuff

I found it a bit odd and jarring how the wolf form was a multi-jointed sprite with rotating limbs instead of being beautifully hand-animated like the rest of the game. But it makes sense when you think of it like this: After getting wolf form you are able to shapeshift into it at any time and any place. That means the art has to be cached in memory constantly given the limitations of the CD format. Storing bespoke animation frames for something you rarely ever use wouldn't have been very cost effective at all, so I can see why they did it this way instead.

Click to shrink...

I think your example image couldn't be more perfect too. The wolf form is a lot wider than Alucard, which becomes tricky with sloped surfaces. You'd need an entire new set of animations for going up and down slopes to compensate for the extra angles. By segmenting it into parts, you can only rotate the parts you need, sparing the other bits from the low resolution rotation. Rotations can easily result in messy, undesirable outcomes at this scale.

 

[Patitoloco]

A big reason why most modern AAA games have a live component to them (other than the obvious benefits of MTX to the revenue) is because AAA games take years to do, and it's cheaper and quicker to keep improving upon a game and its fanbase than doing multiple releases.

 

[Silvergun-Blue]

Doesn't Mario have a mustache purely because it was easier to represent that than it was a mouth with the limited pixel graphic of the time?

 

[bearbytes]

Doesn't Mario have a mustache purely because it was easier to represent that than it was a mouth with the limited pixel graphic of the time?

Click to shrink...

Yes, and also the reason he wears overalls, I believe. (So his arms don't blend into his torso)

 

[Deleted member 18161]

The planetoids from Super Mario Galaxy were born out of the Wii's limitations for one large map per level. Splitting it up into many smaller chunks made it a lot easier to process.

I believe I read this in an old interview with Iwata about how technical limitations can drive innovation in level design and gameplay.

 

[Deleted member 12790]

The way the Sega Saturn created it's graphics work is that it composited 3D objects created on VDP2 onto a tiled background layer in VDP1. In this regard, the Saturn's 3D mode was basically a super charged version of the way old 2D hardware worked. The VDP1 background layers were more like mode 7 on steroids. As such, most 3D levels in Saturn games tended to have flat playing fields, like in Last Bronx:

Sonic Jam's 3D worlds high camera angles are a result of this:

You might ask, how does the water work then? The water is 3D geometry that is over layed on top of the rotozoomed background layer:

 

[Deleted member 12790]

The way the 32X worked is that the output of the Genesis could be composited as a layer, like photoshop, over the output of the 32X, either entirely behind the 32X's output, or entirely in front of the 32X's output, but could not mix. As such, the most common use of the Genesis in 32X games is to display tiled backgrounds while the 32X outputs either 3D polygons or high color sprites on top. It is commonly reported that the 32X lacked scrolling hardware, but this isn't actually true. The reason this is done is due to how the 32X works itself.

The 32X, from the perspective of graphics programmers, is a large frame buffer in memory, exactly two screens big. A frame buffer can be thought of like a painter's canvas, it's where you "paint" images on to. There are a few different color modes on the 32X, but the main color mode used is 8 bits per pixel, where you have a palette of 256 colors one can display at once, and a single byte (8-bits) represents 1 pixel on screen. However, you cannot write a single byte to the frame buffer on the 32X, the 32X only allows access to the framebuffer in word size. A word is two bytes, 16 bits. Every time you write to the frame buffer on the 32X, you do it two pixels at a time, packed as a single word. Because of this, there exists a scroll register which will offset the output of the frame buffer by one pixel to the right if set, which allows for smooth, single pixel scrolling in left or right directions. However, because you can only offset the frame buffer by 1 single pixel, as opposed to multiple pixels like on the genesis or SNES or any other common hardware of the time, that means you have to basically redraw the entire frame buffer every 2 frames. On conventional 2D hardware, you can usually scroll 8 or more pixels with a register, which allows you to only have to update a single strip of 8x8 tiles off screen (or more) so most of the image doesn't refresh constantly. Drawing to the frame buffer takes time, and thus the 32X is actually too slow to quickly update an entire screen's worth of graphics fast enough, so they rely on the scrolling hardware of the genesis to handle backgrounds speedily instead. This is why certain games which do solely rely on the 32X for high color backgrounds, like pitfall, run at 30 frames per second. This gives more vblank time to draw the frame buffer, but if you miss the interrupt to return to normal execution at the end of vblank, you have to wait for the end of the next entire frame before you can return. Since the 32X is synced to the tv at 60 frames per second, taking two frames to draw the screen is 60/2 = 30 fps.

 

[mindsale]

I always hated that the Ice Climbers were left out of Smash U / 3DS because of memory limitations on the latter system.

 

[Timeaisis]

JRPG world maps are my favorite example of this. They were limited by how much stuff they could render on the screen, so they abstracted down everything and the world felt "big" without it actually being big. To this day, I think it fulfills its role better than most modern overworlds.

 

[Deleted member 12790]

In the mid 90's, FPS games became huge on the back of DOOM, and it's commonly said that this is what killed the Amiga computing platform. The reason FPS games killed the Amiga owes to the way the Amiga handles graphics in memory. Like the 32X, the Amiga exposes what is essentially a frame buffer in memory that it can arbitrarily plot pixels to (unlike the 32X, these buffers are many times larger than the viewable screen and have thick scrolling registers, so the problem I described above doesn't exist). What the 32X uses is known as a chunky pixel format, meaning a pixel is a solid chunk of memory. Unlike the 32X, however, where each pixel is defined as a contiguous byte of memory, the Amiga uses what is known as planar pixel formats.

What a planar pixel format is, is where individual bits on a frame buffer define pixels, one bit at a time, in groups of 8. This is to say, on a single plane, each byte (8-bits) defines 8 pixels, where the pixel can either be on or off. There exists a register that defines the palette for that plane. For example, take the following byte: 0010-0010. This byte in memory would define 8 pixels in a row, with the first two being off, the third being on, the next three being off, the seventh being on, and the eighth being off.

The amiga let you define multiple planes to make up a screen's worth of graphics. These planes are, using boolean logic, blended together to give the resultant color of the output pixel on the screen. You can define, depending on the type of Amiga hardware, up to 7 planes for one screen planemap. You can sort of think of this as like a 3D representation of memory, like so:

The amiga stores a full screen's worth of pixels for an entire plane in one group, then a full screen's worth of pixels for an entire plane in a next group, and so forth. instead of grouping the bits that define a single output pixel on the screen in one chunk together, the bits that define a single output pixel's color are separated by hundreds of bytes in memory.

This is a good thing for the amiga, normally, because it lets programmers do all sorts of tricks, and can save memory. If you only need 3-bit color depth, you can make it so each pixel is exactly 3 bits long (3 planes) as opposed to a chunky format, where you are required to adhere to the minimum size of the chunk (4 bits per pixel on the genesis, 8 bits on the 32X). Additionally, you can simulate things like transparency this way, or crazy amounts of parallax scrolling. The outline of the person in this demo, for example, is a single bitplane:

The moon in Shadow of the Beast, for example, is just a single bit plane. An example of the cool tricks programmers used on the Amiga:

Now, this is great for 2D games, but it's awful for 3D games like doom. To do 3D games, you need to be able to plot pixels in any location on the screen incredibly fast. The Amiga is slow at plotting pixels, because it has to jump around memory so much to access all the planes to do so. It gets around this by having scrolling hardware and lots of sprites. But if it needs to draw 3D graphics, it chokes.

Because of this, programmers came up with some brilliant work arounds. Doofuses like the AVGN in his Amiga CD32 review bitched about how poor the programmers were who worked on games like Gloom, but those are actually coding miracles. There were typically two modes of thoughts about how to get around the planar graphics of the Amiga to produce 3D games:

First, ignore all other planes, and just use a single mono-color bitplane as a frame buffer (in other words, 1bpp color) and color things carefully using the gradient features of the copper processor to make things look nicer. This is how stuff like Behind the Iron Gate works:

The alternate method is much, much cooler. I mentioned something called "copper" earlier, copper is the name of a co-processor that the amiga uses. It is synced to the output of the TV, and you can write programs and run code on it entirely separate from the CPU. It is like a tiny GPU inside of the Amiga. To put it in modern terms, it's like a per-scanline shader on a modern graphics card. What it does is it has the ability to change certain registers in the amiga on it's own. Registers can control lots of parts of the Amiga's video output. There exists, for example, registers that control the output palette of the amiga.

Using the method I described above, where programmers ignore the other bitplanes and concentrate on 1bpp planes for output graphics, they could write very complex programs for Copper that would, per pixel, change the output color of the framebuffer. By changing the output color of the framebuffer for every single pixel on screen, they could turn a 1bpp plane into a 256 color plane, making the single plane's memory act like chunky memory. This is known as chunky copper. It is what Gloom uses:

'

Making Chunky Copper work takes extreme mastery of the entire amiga hardware, it's one of the most complex graphical tricks the system can do. Now, the resolution of the output image takes a huge nose dive, because the copper actually isn't fast enough to change the palette register per every single pixel on the screen. It takes a couple of cycles to update the palette, hence the "fat pixels." But despite this, they managed to complete transform the way the Amiga produces graphics in a way never intended, to let it create true FPS games with full color on the machine.

This is why FPS games on the Amiga tend to look fat like that. Alien Breed 3D is another game that uses Chunky Copper:



John Carmack once said it was impossible for the Amiga to produce chunky pixel formats at any real speed. Crafty programmers proved him wrong.

 

[cursed knowledge]

Krejlooc just wanna thank you for the posts, man, always impressive and makes me learn something

 

[Deleted member 17210]

Smooth scrolling games on early systems that don't have hardware scrolling always impresses me. I don't know the technical stuff but it's done somehow by how the sprites are moved.

 

[Deleted member 6582]

Elevators and long drawn out sequences where player control(and/or camera movement) is relinquished from the player, is a major design decision a lot of devs did to mask assets loading. I feel like it helped pacing sometimes but was disastrous in others. It's one thing that's still sort of been there in current games despite not always being there for masking loading anymore.

Click to shrink...

It's more nuanced than even that. Take a look at games dating back to the 2000s all the way to today and you'll see they are often made up of corridor/hallway/alleyway and then a bigger area where the smaller area is used to help slow the player to mask asset streaming but also allow it so that the player cannot see two large areas in their line of sight to better optimize for RAM usage.

 

[Barrel Cannon]

It's more nuanced than even that. Take a look at games dating back to the 2000s all the way to today and you'll see they are often made up of corridor/hallway/alleyway and then a bigger area where the smaller area is used to help slow the player to mask asset streaming but also allow it so that the player cannot see two large areas in their line of sight to better optimize for RAM usage.

Click to shrink...

Yup. Halo 1's level loading in assault on the control room always comes to mind when I think about that

 

[MysticGon]

Burnouts 3s fake motion blur made this really cool tunnel vision effect and to this day I consider in the most best representation of speed in gaming.

 

[sn00zer]

Im a bit worried that a lot of games are going to start looking very similar next gen since their will need to be less and less need to figure out a creative way to represent a realistic object. Lighting will be the big one. I hope more games take a cue from FF7 which had extremely stylized lighting which felt pretty refreshing compared to other games I have played recently.

 

[r_n]

Smash 3DS is pretty interesting overall. We all know about how Ice Climbers got the cut because of its limitations but there's other aspects too, especially when you compare them with the mostly-limitless Wii U version:
-The game uses 2 models. A lower quality set and then when you pause the game it swaps in higher quality models

-The character swap mechanic used by Zelda/Sheik, Samus/ZSS & Pokemon Trainer caused issues, so they wound up splitting the former 2 out and Charizard was the only remnant from Trainer.
-Because the screen was smaller, they implemented outlines as an option to help them stand out more (frankly I think this one should have become a series mainstay....)
-Olimar had 6 Pikmin in Brawl, but the 3DS had trouble with them & their AI. Olimar's 3DS Pikmin AI in particular is really bad, even after patches.
-Some of the shared stages show their limits in smaller ways. Gaur Plains lacks Metal Face, Final Destination has a far less elaborate background, Umbra Clock Tower's background enemies are sprites and run at 30 FPS, Super Mario Maker only runs through 2 of the styles per match & lacks certain background elements. Pirate Ship was supposed to come to 3DS as well, but they couldn't get it to work properly.
-Magicant was origianlly going to have fully 3D Flying Men, but it had problems so they went with a sprite instead. This is for the best because the 3D version was hideous.
-The Character & Stage Select screens were fairly plain, just the icons of the characters/fighters, assumedly because of screen limits. Which is also probably why there was Extra Fighters/Extra Stages buttons to shove the DLC onto when it ran out of room.
-Assist trophies also ran at 30 FPS.
-There's a fully 3D Cuccoo item, but the Cuccoo is a 2D Sprite in Smash Run. I assume that, because smash run is a much more intense and larger mode, they had to use a sprite for the cuccoo rush to maintain framerate/crashing.
-We got a small look at the game's project plan once that detailed how Smash Run was originally meant to have all the players on screen at once. Which...obviously....did not happen, no doubt because the 3DS was not strong enough for it.
-Cartridge size limits were likely why they culled music to 2 per stage and the na selection of other music for Smash Run/the Sound Test
-Here's a big one, the game used so much of the 3DS' power/ram/whatever that if you played on an original 3DS it had to do a full reboot any time you went back to the home screen. iirc there were a few other 3DS games, I think the mosnter hunters, that worked similarly.
-There was a hard limit to the number of patches (& I think size) that the 3DS could receive! This likely caused issues when trying to distribute DLC and balance patches, I imagine.

And I'm sure there's plenty of other instances of what had to be pulled back on to get this game going as well as it did. Sakurai was fairly blase about bringing up this in interviews and such, it's kind of funny.

Smash Wii U had a few, itself:
-The 8 Player mode clearly took a lot of power. Not every stage could run it, even in Omega mode or with certain hazards/elements removed, and the ones that did had to remove joints & polygons from assorted models. Wii Fit Trainer's the one example I see brought up a lot, they can no longer give a thumbs up. Contrast with the Switch, where every single stage can be played with 8 characters, with any characters and the only limits are they'll disable hazards briefly.
-There was a number of songs cut between Brawl & Wii U due to size/data constraints. Ultimate actually got to use a new compression algorithm which is why it brought back almost every song and of course has a mountain of new music.

 

[bearbytes]

One of my favorite examples of this is on NES. You'd arrive at the end of a stage, and the background tiles would fade to black, and then a large boss would fade in or move onto the screen. This happens in tons of games, and that fade to black always felt like an epic, "oh shit" moment cuz you knew a big boss was coming.

The reason this was so common was that the NES wasn't able to render large sprites, and was pretty limited in the number of sprites it could render at time. So in order to get a huge enemy, you have to render it as the tile background and use just a few sprites with it (to make it open and close it's mouth for example)

This, along with some of the other examples here really illustrate how certain hardware quirks and limitations would give individual platforms their own feel and identity, which is definitely something I miss nowadays.

 

[lazygecko]

One of my favorite examples of this is on NES. You'd arrive at the end of a stage, and the background tiles would fade to black, and then a large boss would fade in or move onto the screen. This happens in tons of games, and that fade to black always felt like an epic, "oh shit" moment cuz you knew a big boss was coming.

The reason this was so common was that the NES wasn't able to render large sprites, and was pretty limited in the number of sprites it could render at time. So in order to get a huge enemy, you have to render it as the tile background and use just a few sprites with it (to make it open and close it's mouth for example)

This, along with some of the other examples here really illustrate how certain hardware quirks and limitations would give individual platforms their own feel and identity, which is definitely something I miss nowadays.

Click to shrink...

This also happens in Super Nintendo games, but for different reasons. Often when they want to have a boss utilizing scaling and rotation, the boss needs to be a background to be manipulated like that, so a background layer needs to be sacrificed. Whether you have any layers left for any background at all I guess depends on a case by case basis and what specific mode is being used. For the typical one used in sidescrolling games with one layer used for UI I guess there aren't any left for the actual background.