Reclamation Project - Part 6: Perspective (Phantasy Star II)

I'm a sucker for ye olde JRPGs. There's something about playing a game in an old style with an expansive world and a cohesive story that tickles my whiskers in a way that very few games actually do. My younger self would take the sparse details of this world and expand it out into a fully-fleshed out experience, filling in all of the details that were missing.

Most of the nostalgia for Sega Genesis games comes from the sound. There's nothing quite like opening the game on a blippy, peaceful tune. The overworld music is catchy and full of pop, and the battle music takes you right out of whatever you're doing and dumps you into a desperate situation where you have to fight for your life. The game is brutally hard and full of grinding, and you will wind up dead multiple times if you're not overly careful.

One of the things that always stuck out like a sore thumb in this game is perspective. There are conventions that are put in place so that the player can get a sense of the world around them, and suspension of disbelief willing, they can enjoy a fun romp through a fantasy land very different from our own. 

It all kind of works together if you squint at it really hard, pretend that things have to be this way, and excuse everything because "video games". Most of the weird things about games that still continue to this day come down to technical limitations. There may be limited memory in the ROM for sprites, or the amount of time that you had to program an entire game in assembly could have been cut short.

Phantasy Star II was made in 2 1/2 months. That's amazing! Given the sheer amount of content in here, it's a testament to the developers that they managed to cram all of that into 771kb. The size of this blog post is larger than that... technology has progressed so far since then.

Let's take a look at some of the glaring flaws that the game has. The biggest thing that has always bothered me is the perspective in the game. I'm sure things ended up as they are due to the rushed timeline and technical limitations, and the game does hold to the conventions of the time... but the conventions themselves are jarring.

Overworld, inside town

Going from the outside of a town to the inside is... how do I put this? The character is the same size but the size of everything around them has changed. The characters themselves haven't changed, and in fact they are exceptionally tall for an RPG character. That makes the change from humongous trees to small trees all the more egregious.

Shops are so different they take on a separate visual style The characters are completely gone now and the way that the game is presented has changed. We now have a text box, an image of a character in some kind of building with bottles and shelving, and a basic UI for shopping. 

 

I can forgive this more than the others. Interacting with a shop is a different style of gameplay than adventuring or combat. It makes sense that the way you would interact is different than the usual. The absolute waste of space, on the other hand, is, well, wasteful.

 

Overworld, inside dungeon

Moving to the inside of a dungeon is worse. The hint of perspective is that the areas are large and expansive, but the rooms are empty and bland and I could have sworn there was a ton of monsters outside. The speed of the character is consistent from one screen to the other, which is okay, I guess. That's a remnant of how the character moves on all screens, not just inside.

The biggest offender in all of this? Randomized battles.

How big is anything? Exactly as big as it needs to be so that you can make out the details while still giving the player the sense that they are in the world... somewhere. It's a band-aid of a fudge that takes what little memory the systems has and makes it work.

 

Dungeons themselves have a different problem. With the complete lack of relative size to anything else and an inability to measure them, the only thing that actually matters is time. How much time are you spending in all fifteen dungeons? Around 90% of your 30 hour playtime.

 Courtesy of www.fantasyanime.com

The first dungeon has four floors. The only thing that differentiates which floor you're on is the rough layout, how many times you've went up or down a teleport pad, and what kind of monsters are there. The deeper you go, the more likely you are to find a nastier version of something that you just fought. Everything else is completely empty.

The most interesting dungeon in the game is the Biosystems Lab. This dungeon has container vats of unknown creatures, odd machinery, and hazardous glowing liquids in the basement. By the time you reach the bottom floor you've likely exhausted yourself to the point where you're running on empty, and if you haven't died three times in the dungeon then you're obviously grinding yourself to some worthwhile level where the experience starts running off rapidly.

The game does have some nice world building after this point, but as far as actual gameplay goes this is the peak. There are somewhat interesting things going on after this, but the dungeons get confusing, lazy, boring, and even more empty as time goes on. 

I've been playing the modernized mod of Phantasy Star II to see if a bit of tweaking could make the experience worthwhile. It has its ups and downs, and the multiple hours of grinding have been smoothed out and condensed into a much better path, but I'm afraid that it's going to run out of steam sooner or later. As much as I like this game, it has a bunch of flaws that can get in the way of fully enjoying the experience and...

...wait a minute. 

1. The experience is fun and memorable
2. The experience is fundamentally flawed in a way that is disappointing or maddening
3. The act of solving a problem with the experience itself is a worthwhile endeavor.

The criteria for wanting to make something is perfect here.

1. The music is fun, the world setting is great, the characters are interesting and varied, and the progression of RPGs is always fun. It might seem lazy in other games, but I do love how monsters are re-used here.
2. The entire game loses steam around a third of the way in. It gets repetitive, grindy, and the dungeons that make up a disproportionately high amount of content are empty. The planet of Dezo is just... empty and shallow.
3. One of my childhood dreams was to fix the perspective and make the gameplay more engaging.

You know what? We'll come back to this later. My mind is spinning with ideas and plans need to be made.

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!

Reclamation Project - Part 4: Movement Analysis (Alisia Dragoon)

Alisia has four movement mechanics: walking, crouching, turning around, and jumping. Let's take a look at each one.

Walking, Crouching, and Turning Around

Alisia walking speed is 2 pixels per frame. There's a quirk in the movement where the first frame of movement is only one pixel. This is likely to account for the change from a standing to a walking sprite. A single pixel of movement in one frame isn't noticeable, so this might just be a bug.

Alisia can start and stop walking with no acceleration or momentum at all. The main mechanic that interrupts this is turning around. If you're pressing right and decide to turn left, Alisia will spend 10 frames horizontally locked in place while the turning animation plays.

Alisia can also instantly crouch any time she is walking. She can return to a standing position after 10 frames have passed. Any time after this point she will stand instantly, but a mistaken tap for a couple frames will stick her to the ground for 1/6 of a second. Crouching's main advantage is that the player's hitbox is smaller, allowing her to dodge attacks that would otherwise hit her.

Jumping

Jump time: 52 frames
Jump speed: +4 pixels per frame, decreases by one on frames 11, 16, 21, 29, 32, 36, and 41
Jump height: 69 pixels
Jump width: 106 pixels
Jump ratio: 0.75
Last input frame: 20

 

 Visual plot of jump data

Figuring out how to calculate jump height on a character can be a bit tricky. Alisia's jumping sprite doesn't change her leg position, so I picked a single pixel and tracked that across the entire jump. Each change in position was measured against the previous one and manually plotted in GIMP. I had to double-check each keyframe to make sure that the velocity was changing and to get a good idea of how the visual interacted with the controls.

Jump ratio is calculated by taking half of the jump length and dividing that by the jump height. The higher that number, the flatter the curve appears. The last estimated frame for controlling jump height is a guess; I'm not interested in replicating the movement exactly, just in getting an idea of how it works. Other stats should be self-explanatory

This whole process isn't hard... but it is tedious. Creating the chart took around 45 minutes from start to finish.

 

Tracking pixel

Jump mechanics can be divided up into three parts. These are divided up into boost, hang time, and fall, which are red, green, and purple respectively.

Boost is the most important part, as the player has direct control over this period. Many games with a platforming system have a mechanic where holding the button longer lets the player jump higher. Older games tend to do this in a more obvious way, cutting off upward momentum directly after the button is released.

Momentum at the top of a jump is called "hang time". In general, this is the period of time where the character hangs out in the air before they begin to fall but after any control the player has relinquished. Some games will go out of their way to extend control all the way into this phase. Having that sort of control tends towards cartoony physics.

Fall happens on the downward direction. All control over the vertical direction has been lost and gravity takes over.

Because of the way hang time works, her minimum jump curve looks like this:

Alisia's jump appears to be a smooth ballistic arc. While she does jump lower when the button is released sooner, she still jumps in an arc that looks reasonable because the cutoff of boost still has upward momentum. The game doesn't differentiate between hang time and fall from a mechanical standpoint, but falling animations do play on the way down.

Jumping and walking control independently. The player has full control over how the player moves sideways in the same way as walking happens, down to getting stuck in the air with a turning animation.

Subjectively, Alisia feels like she falls a bit faster than she rises. She also appears to jump higher than she. The graph shows that she loses speed a lot quicker on the way down than the way up and is better at jumping up than out. The entire jump feels basic and a bit quirky, but it works. That doesn't mean I have to like it.

One advantage to a low jump ratio is that your character is a lot better at jumping over incoming projectiles. Another advantage is better vertical movement. Neither of these ideas are present. There's only one set of projectiles in the entire game all the way at the final boss to jump over and platforming is full of small, incremental jumps.

Contrast that with the crouch mechanic: Having a hard 10 frames where you're stuck on the ground means that you've committed to the choice, but have access to it immediately. There's a lot of enemies that pull out spears or fly directly at your head. These enemies are sprinkled throughout the game from the beginning to the end

 

Single hop stairs

The way I would describe this type of movement is "serviceable". The focus in this game is on combat and reflexes. You're able to move the character around with a large amount of flexibility, and the 1/6 second that it takes to turn Alisia around or duck means you have to move forward strategically. It's somewhere between purposeful and twitchy, overall basic, and works well enough. The focus is more on combat anyhow

Final thoughts

Alisia's walking speed is 2 pixels per second. How fast is this compared to the real world? Well... we don't have a ruler to measure the game by. The entire game is set in a high fantasy setting with an emphasis on trying to make things look good. Nothing in-game, in the manual, or from the developers indicates a canon height for any element, and all the sizes for things are wildly off from what we would expect to see by taking a hike anywhere.

My best guess based on this screen is that Alisia is very small, perhaps thumb sized. The alternative is that she's human sized and her entire world is full of gigantic trees and bugs. As with anything in a world that plays fast and loose with sizes, we can't really know.

Trying to relate these numbers to a real world situation is like trying to write down how time works in a black hole. We can make some assumptions about how it works based on our math, measurements, and theories, but any attempt to make real use of it will end up breaking your brain, crashing your computer, and eating your soul. Best not to think about that too much.

Scale? Rulers? Who says what is real and what is false?

Reclamation Project - Part 3: Genesis Analysis Tools

Starting on a journey of dissecting an old game can be a challenge. The easiest way to do this, of course, is simply to play the game in an officially licensed format. For modern gameplay I would suggest using a Genesis Mini and hooking it up to a modern TV. If you're feeling really old school, then you can grab yourself an old Sega Genesis/Mega Drive and a copy of any cartridge and you'll be good to go.

Just playing the game is not enough for me. I want to tear the game apart all the way down to its roots. Every aspect, every little detail, and every bit is going to be examined. There could be useful data hidden inside the game, and at one point I had considered hacking as a slap-fix for my own fix. What we're going to need is a dump of the game, otherwise known as a ROM.

From a legal perspective, if you own a copy of the game you can make backups of that game for archival purposes in most countries. That idea has been tested to varying degrees across the world, and while having a backup copy of a game for archival or other purposes is seen as legal, downloading a game from the internet is not.

Here's an overview on how to dump games from an old cartridge
Here's a writeup on how to dump games from a Genesis mini

With a legal copy of a ROM in hand, the next step is to analyze it. For our purposes, being able to change what a console would do at runtime should be enough. We're going to need more than a standard emulator for that purpose

Gens Re-recording is a great tool for examining how the game is structured piece by piece. We can turn on and off different rendering layers, record videos, and play back a series of inputs. I'll be using this one most throughout the project.

Disabling sprites is simple and effective

For more technical analysis, we're going to need an emulator with more potent debugging powers. Gens KMod can bring up multiple debuggers, from the CPU to the sound card. It's ideal for ROM hacking. For my purposes, I'm looking at how the game is running in the background and finding useful data in the debugger.

Some Genesis games store sound files in their ROM as uncompressed data. You can open up a ROM in Audacity as raw data. Import the entire ROM with 6 channels and use KMod to determine the frequency of the sound. That frequency should be found below; you may need to slow down or stop the emulator's playback to find out exactly what you need.

Alisia Dragoon seems to have all of its music stored as custom data instead of something easier, unfortunately. This may apply more for future games

The last piece of the puzzle is something for analyzing footage after the fact. VirtualDub is a simple and free video player that lets us precisely control each frame, scrub forward and backward through the footage, and make easier miniature videos for the blog. Paired with game movie and AVI output from Gens Re-recording, that should be all we need for the bulk of this.

Virtualdub in all its basic glory

Reclamation Project - Part 2: Initial Impressions (Alisia Dragoon)

 Alisia Dragoon. A game that makes me nostalgic for a time I never had. Let's jump right in.

Ah yes, the good old days. I'm a bit disappointed that there isn't a blaring S E G A right at the front screen, but the animated shine is a nice touch.

The logo fades out onto a scrolling background reminiscent of Mayan mythology. The music has a nice folksy tone to it, but also has that characteristic genesis grunge mixed in. The background seems somewhat important and impossible to read properly... until it reaches this.

I'm guessing there's an epic story somewhere in here referencing characters and stories in the game. There's a lot of polish in the title screen alone; this should be fun!

I haven't played a Genesis game in quite awhile, but I know two things about these games: we can take a look at the controls and difficulty is probably hidden in the options. There's an entire discussion to be had about asking players to pick a difficulty right at the start of a game, but luckily we don't have to make that choice in older games; it's already been set at a default for us.

Normal and Hard is a bit unusual for difficulty. If the game has a difficulty setting, you can usually pick easy. Most difficulty modes are just the number of starting lives or maximum health anyhow, so we'll leave this alone. I'm much more interested in the controls - monster select, thunder, jump. All of the other control types have jump not on the C button, which is a bit disappointing, but the default looks fine anyhow.

Enough plot contrivances, let me get to the game!

Wait, what was that? There was some kind of bouncy sound effect and a bunch of sparkles and something? I had to restart the game and get a proper screenshot just to see what went on; the animation happened in less than a second

Alisia, of course! I didn't know she could fly. I'm impressed... by the amount of speed she can put out, of course. Not the legs showing all the way up to the hips or size of the bust or anything, I swear!

We don't have full control over the character to begin with. Notice the demo marker; that only appears when the player is trying to take control during a cutscene. Instead of getting right into the gameplay we watch Alisia walk in from the side of a large structure that resembles a castle. There's a nice sunny day in the background and the music positively drips with adventure. 

I like the idea of setting up the scene by bringing me in from the outside world into this fantasy land. It has the feeling of being transported into an unfamiliar land, brimming with danger and excitement. The cutscene goes on for just long enough that I drop my guard and...

We're under attack! I have control! I have no idea what the controls are, there's nowhere to experiment, push random buttons!

Ah, I see a problem. You can't see the problem or the character at all in this screenshot because the character is flashing on and off rapidly to represent an invincibility window. I've never really liked this technique because of the kind of headaches I can get from watching them for too long, but just taking a bit of damage should be fine. 

Thunder is something I'm a bit more worried about. The whole attack alternates between multiple sprites with the same kind of alternating flashing missing frames that invincibility causes. I'm sure it looked better on CRT TVs, but it's one of those things that hasn't aged well. We have a lot more awareness about what flashing lights can do to people nowadays.

On the UI there is a bar that charges over time. It decharges fairly slowly while in use, recharges quickly up to the yellow mark, and slowly after that. When it's full and you push the thunder button...

A huge swathe of thunder moves in two arcs from front to back and front again. It's flashing like the other thunder attack, but isn't so bad. In fact nothing of these flashing attacks really bother me, so I should be fine playing this game for a few hours. Let's move on...

Almost forgot about the monster select button.

Neat. I have a dragon and a fireball. There's also another dragon and a winged lizard. Each of them seem to be different for one reason or another, and they also appear to have their own health bar and maybe level. The arrows next to the monster's level also resemble the lightning bar under Alisia's health, so that's probably an attack.

Thunder homes in on enemies. These green creatures come flying out of the side of the screen in groups of 10 and thunder takes them all out in a second. Running and instantly zapping everything that can possibly come your way is definitely the best part of the game. You're going to be spending a lot of time doing this, so it's best that the core gameplay is the best part.

Alisia's dragon buddy seems to change color as they get damaged. That's a good way of showing the player that they need to take care of their pet without relying entirely on the UI.

On my first playthrough I got to this point and promptly lost. It's not that far into the level so I'm not too torn about that. Besides, these kinds of games have a life system so I can just start up from the beginning again and...

Oh.

That's pretty brutal. Very few games will take an arcade style game and end it immediately on the first loss. I can't say I'm happy with that idea. It smells... off. There aren't any good reasons to be this punishing in a game that you have confidence in.

There are only a few reasons I can think of to do this:
1. Artistic vision
2. Lack of development time to implement systems
3. Artificial difficulty enhancement
4. Artificial extension of game time

There are some other problems later on in the game that will make the answer to this oddity more clear. For now, take it as a sign of what's to come.