Reclamation Project - Part 5: Technical Breakdown of Level 1 (Alisia Dragoon)

Let's take a look at level 1 of Alisia Dragoon. We're going to dissect every aspect of this level, from the overarching design down to the individual pixels. The main tool we're going to be using is Gens Rerecording. swapping out layers and grabbing a whole lot of screenshots. Our main reference is an excellent technical writeup on how the Sega Genesis/Mega Drive renders graphics.

 Resolution

The first thing that's noticeable is the resolution of the game. All of the images are uploaded in their original size - 320x224. That's noticeably smaller than your monitor is, and if you're using a modern 4K display that may be so small that you can't make out any details.

Old CRT style TVs had a lot of variance they could do. Their theoretical maximum was 1280x1024 projected dot beams on the screen, but unlike our modern pixel counterparts they could easily enlarge each projected beam to do something "smaller".

Width to Height Ratios
- TV: 1.25
- SNES: 1.1428
- Genesis: 1.4285
- Modern (16:9): 1.7777

The SNES had an advantage on older TVs. 8:7 ratio is a lot closer to 10:8, and if you scaled them up they would look very close. This is a big technical reason why Nintendo games seemed to have a characteristic look to them: the game screen they were working with was close to square and TVs were close to square.

The Genesis, on the other hand, was ahead of its time by supporting a widescreen format. Most TVs had a border where the light bled off of the screen to hide content and a whole bunch of other details I'll go over in the art analysis post later. For now, I suspect that this will make scaling up a Genesis game a lot easier than a SNES game. All we need to do is scale up the image and extend it a little bit.

If we crop out the UI and overlay that on the previous image in red, that looks as close to a modern display as the SNES did to an old TV. We may be able to capture not just the gameplay, but the feel and experience of watching the game as well.

Tiles

The entire game is broken up into 8x8 chunks of data called tiles. This is a technical limitation that applies all the way through the system, from the layout of the level, to the scrolling background, and even down to the characters themselves. The main reason why things used to be so small or proportioned so weirdly is because managing everything in the tiny amount of RAM consoles had was a huge technical challenge.

 

While sprites do have the same 8x8 tile limitation, they can be defined in larger groups of tiles up to 4 tall and 4 wide. Multiple smaller sprites can be used in place of a larger one to make a full character; Genesis games are known for having multiple fast moving sprites on the screen all working together to make a frenetic, fast-paced experience.

Alisia's sprite is two groups of 3x3 sprites all working in tandem - the legs and upper body seem to be animated separately. The caterpillar is made of 6 1x1 sprites all moving together and stitched into a whole character behind the scenes.

 Rendering layers

Gens organizes layers a bit differently than the writeup lays out. Scroll A is used for parallax backgrounds, Scroll B is the terrain and foreground, and the window layer is completely missing. I'm going to focus on how these layers are used in the game. In order:

 

Distant background - Scroll A, low priority

The back layer is used for a technique the Genesis is famous for: parallax scrolling. In Alisia Dragoon this layer is used to show distant background details. Clouds, mountains, and trees all appear to move slowly compared to the camera and gives the entire scene a depth that wasn't possible in consoles before this generation. 

Some of the odd details are hidden under terrain or the UI; the only way you'd be able to see this is by removing other layers that render on top.

 

Terrain - Scroll B, low priority

Most of the level is rendered on the middle layer. This layer is what gives the illusion of the level moving as the player traverses it. Everything that scrolls at the same basic rate, from the ground to these large trees, is here.

It's interesting that the UI is rendered on this layer despite being a part of the terrain. My best guess is that this is some kind of processor saving technique because the UI doesn't need to update very often.

 

Characters - Sprite layer, low priority

Characters have their own layer that renders on top of everything else. Alyssa Keil describes the mechanics well:

"Sprites for the Sega Genesis are defined as images with a size of (w x h), where w is the width in tiles, and h is the height in tiles, where each dimension can range from 1-4 tiles. . . The Sega Genesis can handle up to 80 sprites on screen, 20 sprites per scanline, though it’s worth staying under this limit to avoid slowdown."

Foreground - Scroll B, high priority

The start and end of level 1 has a structure that has pillars that render in front of the player. Outdoor levels use this layer sparingly, spending a lot more of the console's processing power on the parallax effect from clouds and other background objects. Indoor levels use the terrain and foreground much more extensively in building the level to the exclusion of distant backgrounds.

 

 Text - Sprite layer, high priority

This layer isn't used often. The main use is the pause or minion select screen, occasional dialog in cutscenes, or game over and the result screen.

"Sprites. . . have either a low or high priority flag set. This priority setting determines whether the sprite will be displayed above or below tiles in the other planes (which also have a low or high priority setting)"

Final Thoughts

Diving more and more into these games are showing me just how many technical limitations older systems had. If Alisia Dragoon was made in a modern environment... well, the studios are different so I don't know how it would have turned out. The bar for making a good game is much higher today than it was in 1992 due to hardware advancements and the sheer amount of great works we have now.

I'm more of a design and behavior analyst than a technical one. Details here are kind of sparse and are meant more as a way to see what's going on, rather than dive deep into the code and understand the ins and outs of it. I'm sure a lot of the code in the game is fairly simple due to the basic behavior that the game has anyhow.

The fact that these games have as much content as they do in such a constrained environment is a miracle in and of itself. The entire game has a file size of 1mb!