Unused content

Unused Behaviors

Some behaviors can never appear under normal conditions for a variety of reasons. More information on each behavior here. 

Behavior 1 (0x1)

This behavior does nothing and is not called anywhere.

Behavior 2 (0x2)

Shows the a-life waving its arms in panic. This one is referenced by unreachable code that is meant to be triggered by the impossible condition of NiGHTS touch dashing an a-life that is not an egg.

Behavior 10 (0xA)

Technically this behavior can appear, but it will be invisible due to a bug which is explained later on this page.

Behavior 78 (0x4E)

This behavior is intended to be triggered when a normal a-life encounters a King Pian that is engaged in behavior 65 (commanding). However, it doesn't work because all types of a-life are programmed to ignore King Pians regardless of what they are doing.

Unused Animations

These are animations that are not referenced by any behavior. Many of them appear to be related to used animations or to objects in their associated stage.

Unused Animation Frames

There are some unused animation frames (numbers 0xE7 -- 0xED) that create an alternate snowball/rock throwing animation. The normal snowball throwing animation (left) shows the nightopian with a big smile which is only loaded properly in Frozen Bell and used as part of behavior 0x38, which is exclusive to Frozen Bell. The alternate version shows a neutral expression and loads correctly in any stage. Normally, nightopians and mepians outside of Frozen Bell do not throw rocks/snowballs. However, King Pians will throw them in any stage (snowballs and rocks are interchangeable depending on whether the stage is Frozen Bell or not). And the King Pians certainly don't look happy while throwing them, as their targets are nightmarens and mepians. Were normal nightopians also meant to throw things at enemies?

There are also a handful of isolated unused frames which seem to be duplicates of used frames adjacent to them in memory.

Unused Objects

Each stage includes data for objects that a-life interact with as part of their behaviors. The game has a list of all valid objects which can be loaded for whatever purpose they're needed for. To give you an idea of variety of uses of objects, some are particles (music notes for singing and Zs for sleeping pians), projectiles (rocks, snowballs, or even tears), "accessories" attached to the a-life (inner tube, sled, cake on a stick), or sculptures to be deposited in the level (snowmaren and drawing easels count too). They can also be generated when an a-life stops its previous behavior, "throwing away" whatever it was playing with. This happens with objects such as the remote toy nights, sled, umbrella, and flag. Since their uses are so diverse, it's hard to be sure what each of the unused objects was intended for.

Object 2

This is the chain seen in animation 41. It exists as a complete chain rather than separate links and can be loaded into any stage.

Object 12

A small green tree. Possibly meant to be used with animation 48. It is only loaded into Spring Valley.

Objects 15-17

Three identical small objects with red, yellow, and blue coloring. It is only loaded into Frozen Bell. 

Object 19

A pink arc shape. It only appears in Splash Garden. Possibly intended as the jump rope for use with animation 60.

Objects 23-24

Two identical round balloon-like objects. Only appears in Mystic Forest. Possibly intended for use with animation 54.

It's possible that the palettes assigned to these objects are not what was originally intended. The rope and balloon both share the nightopian wing palette and the Frozen Bell object uses the umbrella/flag palette, rather than having unique palettes of their own.

Unused Sprite Data

A few a-life sprites and palettes go unused and are not even referenced by animation frames. 

Sprites for large swirly and round spheres exist in every stage's a-life data. These are the same as the sprites used for touch dashing/throwing a nightmaren. It's possible that touch dashing nightopians and mepians was considered at one point, since some unreachable code exists to handle this scenario. This code does not allow them to be thrown, however, and shows them static with a panicking animation.

An unused palette exists in each stage's a-life data that shows an odd red to blue gradient. Interestingly, the colors from this palette are used in the remaster, for seven tail sprites for nightopians. This is strange because nightopians are not supposed to have tails in the Saturn version and are never shown with them in promotional art. These probably represent leftover assets from a very early build that predates the E3 prototype.

Unused A-life Data

Some values in the A-life data structure are not used meaningfully and seem to be left over from an earlier time in development.

The most prominent of these is the 8 unused a-life genes that exist padded between the a-life's body part genes. They are passed down using the same bizarre dominance calculations as the body parts and are even stored in the save file, but are not used anywhere. 

One theory is that two of the unused genes could have been attached to each of the four body parts, storing additional data associated with them. For instance, the dominance value on the main body part gene could have been placed in the first unused gene instead, and the linked gene passed down along with each body part could have been the second unused gene. Still, this doesn't explain why the unused genes have dominance values of their own in the final.

Another unused value is the higher nibble of the mood value. In-game, only the lower nibble is used meaningfully, such as to control a-lifes' interactions with the player and the tone of the music. However, many of the behaviors that set the lower nibble also perform operations on the higher nibble, which may be the same or different. For instance, the player throwing a nightmaren toward a nightopian sets the higher nibble of its mood value to 0, and the lower nibble to 1. When the player paraloops three or more nightopians in a single playthrough, both the higher and lower nibble of all nightopians' mood are set to 0. Also, the starting population of nightopians starts out with 2 in each nibble. My theory is that a-life were originally supposed to have two mood values: one for its overall mood, and one for its opinion of the player specifically. 

Unreachable Code

The game's ROM contains some unreachable code that offers insights into features that were scrapped some time during development.

Some genetic behaviors will never activate due to requiring an impossible condition. Genetic behaviors 15 and 23, as well as 16 in Stick Canyon only, are programmed not to activate under any condition. The same is true for genetic behavior 21 for nightopians only. Genetic behavior 2, which intended to cause both mepians and nightopians to cry when encountering a dying a-life, does not activate because another part of the code causes them to ignore the presence of dying a-life. 

Other non genetic behaviors can also have impossible conditions, such as behavior 2 which can only be activated by NiGHTS touching or touch dashing an adult a-life. In the final game as well as the E3 prototype, NiGHTS can only touch or touch dash eggs. Behavior 78, as mentioned above, will only activate when one a-life moves near another one performing behavior 65. Since the only a-life that can do this are king pians, and all a-life are programmed to ignore their presence, this condition can never be met. 

Erroneous Code

Fishing cake behavior 0xA (10)

The fishing cake behavior does not function correctly and will never be visible during gameplay due to a bug. Specifically, the code for this behavior contains the following instructions (label added by me):

mov     #0x74,r0
mov.l   @(r0,r2),r4
mov     #0x4,r5
tst     r5,r4 # if value at 0x74 has the 0x4 bit set,
bf      skip_generate_cake_sprite # then skip the following code
mov     #0x0,r0 # else set r0 to 0x0
mov.w   r0,@(0x1a,r1) # reset the a-life's angle (to make sure it isn't upside down)
or      r5,r4 # set the 0x4 bit on the value from offset 0x74
mov.l   r4,@(r0,r2) # write the value into offset 0x0

In plain english, what this code is doing is checking that a bit on the value at 0x74 in the a-life's data is 1 or 0. If that bit is 0, a cake sprite is added to the end of the a-life's fishing rod and the bit is set to 1. If the bit is already 1, the cake generating code is skipped. At least, that's what this code is supposed to do. 

The register r0 is supposed to hold the value 0x74 so that the bit can be stored back in memory at offset 0x74 in the a-life's data. However, the 6th instruction sets r0 to 0 instead, (which is used to reset the a-life's angle to 0) so that by the time the 9th instruction is reached, the bit is written into memory at offset 0 instead of 0x74 as intended. 

As it turns out, offset 0 contains a very important value: a pointer to the a-life's object reference. This is required to allow the a-life to be rendered on screen. If it's replaced with the value intended for 0x74, the a-life will disappear from the screen.

Fixing this bug is simple. Just move the 6th and 7th instructions after the 8th and 9th:

mov     #0x74,r0
mov.l   @(r0,r2),r4
mov     #0x4,r5
tst     r5,r4
bf      skip_generating_cake_sprite
or      r5,r4
mov.l   r4,@(r0,r2)       # write the value into offset 0x74
mov     #0x0,r0
mov.w   r0,@(0x1a,r1)

Gene dominance conversion

When two a-life breed, their body parts are not passed down with equal probability, but instead have different probabilities depending on a specific value attached to each parent's gene. This is known as the dominance system which I explain in more detail here. It contains two bugs. 

The first bug has to do with a feature described in the game's a-life patent. This states that when both parents' genes have A dominance, the offspring's gene will be converted to C dominance instead. If both parents' genes had C dominance, the offspring's gene will be converted to A dominance. In-game, the conversion from A to C works as intended, but the one from C to A does not. To understand why, it's important to know some details about how the dominance values are handled under the hood. 

Each body part gene is an 8 bit value where the first two bits are used as the dominance value:

0 0 0 0 0 0 0 0

└┬┘ └────┬────┘

 │       └─ body part type

 └─ dominance value

The patent refers to different dominance values using letters, but in the code they correspond to numbers: A=0, B=1, C=2, and D=3.

To determine whether both parents' dominance values are A or C, the first two bits from both parents' genes are "squeezed" into a single 4 bit value:

0 0 0 0

└┬┘ └┬┘

 │   └─ parent 2's dominance value

 └─ parent 1's dominance value

If both parents have A dominance, then the 4-bit value combining them will have bits 0000, equal to 0 in hexa/decimal. If both have C dominance, the bits will be 1010, equal to 10 in decimal and 0xA in hex. The code correctly checks if the 4-bit value is equal to 0. However, instead of checking if it is equal to 0xA for the second calculation, it compares it to 0x22 instead. This condition can never be met because the maximum value that can be stored in 4 bits is 0xF. 

It seems likely that this comparison is leftover from an earlier build that squeezed the dominance from each parent into an 8 bit value instead of a 4 bit one. This would work as follows:

0 0 0 0 0 0 0 0

    └┬┘     └┬┘

     │       └─ parent 2's dominance value

     └─ parent 1's dominance value

This way, if both parents' dominance was C, the resulting value would be 00100010 in binary, or 0x22 in hex.