A small group of programmers from this community hacked the game to analyze its files in order to understand exactly how the game works. The research information is summarised below.
Location ID numbers[]
These can be derived either from the textures (TIX files on cd) or from the memory by inspecting the current_location variables.
| Location ID | Location name | Japanese |
|---|---|---|
| 00 | Bright Moon Cottage | 明月荘 |
| 01 | Pit & Temple | 寺院 |
| 02 | Kyoto | 京都 |
| 03 | The Natural World | 自然界 |
| 04 | Happy Town | HAPPY TOWN |
| 05 | Violence District | バイオレンス街 |
| 06 | Moonlight Tower | 月光の塔 |
| 07 | Temple Dojo | 寺道場 |
| 08 | Flesh Tunnels | 有機廊下 |
| 09 | Clockwork Machines | 工場 |
| 10 | Long Hallway | 長い廊下 |
| 11 | Sun Faces Heave | 太陽はヒーブ直面 |
| 12 | Black Space | ブラックスペース |
| 13 | Monument Park | 記念碑公園 |
File Structure[]
Folders[]
The root of the disc contains a folder called CDI where all of the game data is stored. jPSXdec can open the CD image file, and another tool that can open .TIM and .TIX files is PSicture 1.02 on Windows 8.1 (64 bit). The .TIX format is unrecognized by PSicture, but the files can still be accessed if the file is scanned.
The game also has a ZDUMMY folder with a ZDUMMY.STR. This was created so that the game data was close to the center of the disc, making loading the game quicker.
The image that appears if you play ZDUMMY.STR
TIX Files[]
There are four .TIX files for each location containing the four different texture themes. The textures stored within these files are in the .TIM format.
| File name | Texture theme |
|---|---|
| TEXA.TIX | Normal |
| TEXB.TIX | Kanji |
| TEXC.TIX | Downer |
| TEXD.TIX | Sexual |
SEQ Files[]
Each STGxx folder has five BGx.SEQ files, ranging from A to E (BGA.SEQ to BGE.SEQ). The SEQ files contain sequenced music (the PSX MIDI equivalent) which can be used together with the VB (sample) and VH (header) files in /CDI/SND/ to compile the tracks. seq2mid can convert the SEQ files into MID files. pSound can extract the VB file content. The mixes can be compiled to PSF using vgmtoolbox which can then be played using Winamp with the in_psf plugin or using foobar with the foo_psf plugin.
These files always begin with a "magic number" of "pQES" followed by "1" as a big-endian value. While the PS1 was little-endian as far as this dreamer knows, the dream journal mentions using a Macintosh, which was big-endian, and the tools used to create these scripts were likely on a Mac as a result. 1 could refer to a version number. Note that pQES is SEQp which backs this up.
VB/VH Files[]
.VB contains a bank of sounds, always accompanied by a .VH header to describe what's inside. They are used for the in-game soundtrack's instrument sets (AMBIENT, CARTOON, etc.) and sound effects (SE). Awave Studio/VABTool can be used to open these files and access the individual .VAG sound effects inside each bank. Here's a key, as it's not immediately obvious at the default sample rate which VAG corresponds to which sounds in-game, and there is frequent reuse of sound effects for different purposes (ex. the astronaut and Happy Town trumpeters). Square brackets denote an unconfirmed or unknown sound.
|
VAG No. |
Description |
|---|---|
| 00000 | [Jangling] |
| 00001 | [Opera Singer] |
| 00002 | [Jiggling] |
| 00003 | Grass, Sand, H.T. Footstep |
| 00004 | Train |
| 00005 | Astronaut, Trumpeters |
| 00006 | H.T. Squeak Footstep, Pterodactyl, Kissing Lips |
| 00007 | Flowing Water (Natural World) |
| 00008 | Link, Wind |
| 00009 | Minotaur Walk |
| 00010 | Deep Rumbling |
| 00011 | V.D. Dock Footstep, Kyoto Bell, Soda Cans |
| 00012 | Wooden Bridge Footstep, Balancing Child |
| 00013 | Tengu running |
| 00014 | Drumming (Kyoto) |
| 00015 | H.T. Footstep, Giant Head Kanji Show |
| 00016 | Small Geisha Running |
| 00017 | V.D Girl Jump |
| 00018 | Snarl (Lions, Dojo Dog) |
| 00019 | Wings Flapping (Pterodactyl), H.T Bushes Swaying |
| 00020 | Giant Baby Head Enter The Window |
| 00021 | Fetus Noise, Rocket Ship |
| 00022 | Breathing (Sleeper in BMC) |
| 00023 | BMC Birds Tweeting, Unknown Call in N.W |
| 00024 | Long Hallway Wall Open |
| 00025 | Horses Galloping (Natural World) |
| 00026 | UFOs |
| 00027 | Kyoto Grass Footstep |
| 00028 |
Generic Footstep (Tunnels, V.D., BMC Tile, NW Rock) |
| 00029 | Water Footstep (NW River, Flesh Tunnel Slosh) |
LBD Files[]
The .LBD files contain most of the models in the game. The models contained within these files are in .TMD format. They can be extracted with jPSXdec (uncheck raw) and further extracted with PSXMultiRip. Milkshape3D can import .TMD models which can be exported for editing in other modeling programs. LBD could also refer to Level Build Data.
In larger environments, these files are split into subfolders called Nx, which in the Natural World, for instance, span all the way from 1-9. The reasoning behind this is unclear, but perhaps it was just to keep the folder structure tidier. Maybe there were file system limitations or the map was split between developers.
Memory analysis[]
One way to understand the underlying game mechanics is to perform memory analysis on an emulator running the game. Once the analyst know about a variable, the variable itself can be monitored for studies. A variable can be modified directly by changing the memory of the emulator. The game's behavior can also be modified if the instructions are changed.
How to analyse the memory[]
Cheat engine is a program made for game memory modification. LSD: Dream Emulator running on the emulator pSXfin v1.13 was tested and worked well with Cheat engine. There is a .rar file containing a version of Cheat engine without the (potentially unwanted) OpenCandy on their official website download page. Be sure to read the guides available for free on various websites and to try Cheat engine with their demo tool before analyzing the game. Be sure to specify the memory region to scan from the address psxfin.exe+171A5C (2 MB game memory) and 0x200000 steps ahead instead of the entire emulator process memory (around 30 MB).
Step-by-step guide[]
Before starting Cheat engine, start the emulator application, load the CD image and start a new dream. Once you have run the Cheat engine main application, open the Process List window and select the emulator process.
Locating a day's variable:
Day 110
In this example, we will modify the number of days that have passed ingame. This game screen show us that we are on day 110. The game stores this as current_day = 109 with two different 4 Byte variables. Enter 110 - 1 = 109 as Value and press First Scan. Some variables that contains the value 109 will appear in the window to the left. Some of these are unrelated but simply happen to contain the value 109.
Play through a dream and the day will change - along with the dependent variables. Now enter the next current day Value 111 - 1 = 110 in Cheat engine and press Next Scan. This will filter out all variables that are not equal to 110. This is a good thing, as they are unrelated and unneeded.
Two variables found
A finished scan should have two variables that are dependent as we already knew that there are exactly two variables that contains days - 1. These can now be monitored or modified. Try entering Flashback mode. The variables will change indicating which day the Flashback is from. Once yourFlashback dream is over, try changing both variables to a high value (more than 365). This has been speculated to trigger more frequent The Gray Man visits.
Memory structure[]
There are some variables that control textures and some that are affected by The Gray Man if you get too close to him but those are complicated to map. Huge parts of the memory are modified when bouncing into something, linking and in encounters with The Gray Man.
Known variables[]
The offsets are measured from the beginning of the game memory. The variables are reached by adding the value found at psxfin.exe+171A5C. In Cheat engine, this is done by referring to psxfin.exe+171A5C as a pointer with the specified offset.
Day[]
There are two 4-byte integers that both contain day-1. These can be modified.
Skipped to day 999
| Variable | Speculated: current_day |
|---|---|
| Type | 4 Bytes |
| Offset | 916B0 & 8AC74 (2 copies) |
Timer[]
You can get and set the amount of time you have spent on a location with this variable. It is stored close to the current_day variable. The timer seems to affect some dynamic links in some generations, which makes the link almost random. It also may relate to the last calculation of your final mood on the graph. In other cases, the timer will just count passed time to make some dynamic objects disappear / do something. Some memory locations nearby fluctuates a lot. This might suggest that the location is used for randomness. Modifying this does not influence gameplay directly. Timer counts spent time in special time units, where 20 time units = 1 second.
Repeatedly setting location_time and game_time to 0 before and during linking is known to cause a glitch similar to the glitch texture.
Map corrupted by setting timers to 0
| Variable | Speculated: location_time | Speculated: game_time |
|---|---|---|
| Type | 4 Bytes | 4 Bytes |
| Offset | 8AC70 | 90b74 |
Location[]
Each location has a unique ID which is the same one as files are indexed (including texture files). It is possible that setting the values to 4 (Happy Town) would trigger more The Gray Man visits and setting them to 0 (Bright Moon Cottage) would disable them. They are numbered by the order they change when linking. They keep the same value once linking is done. The value equals one of the location ID numbers. Invariant: 0 ≤ current_location ≤ 13. Changing them during a half-complete linking will corrupt maps and sometimes freeze the game. Changing just 8ABF8 will load just that map's object behaviors, producing strange results.
There is also a starting position variable that can be used to determine where on the location you will start. The value will change when walking the stairs in the Bright Moon Cottage where the four bytes tell you in which direction you walked and which floor (third byte) you are currently on. When exiting a tunnel, this value follows another pattern. If you save one of the correct pos_start values and enter them after linking, you will likely start at that position. It may also give you a strange starting positon.
Map corrupted by garbling the location variables
| Variable | Speculated: current_location | Speculated: pos_start |
|---|---|---|
| Type | 4 Bytes | 4 Bytes |
| Offset | 91694, 8AC6C & 8ABF8 (3 copies) | 9169c |
Position[]
The x, y and z values are stored separately as signed integers. Modifying them teleports the player. There are some copies which are kept in sync with the main variables.
Teleported to below the bridge
| Variable | Speculated: x | Speculated: y | Speculated: z |
|---|---|---|---|
| Type | 4 Bytes signed | 4 Bytes signed | 4 Bytes signed |
| Offset |
Main: 91e74 Copies: 91e94 (display), 91dd8 & 91df8 |
Main: 91e7c Copies: 91e9c (display), 91de0 & 91e00 |
Main: 91e78 Copies: 91e98 (display), 91ddc & 91dfc |
Chart[]
These variables are used when the chart is drawn on the screen. chart_draw_x and chart_draw_y are identical 4-byte versions of the mixed 4-byte copy containing chart_return_x and chart_return_y. This suggests that the latter two are taken from a return value. These variables are dynamic and have other meanings in other contexts. It seems, that the return value of last event behave itself as an ID for every part of the map.
The values are can be calculated as chart_draw_x = steps to the left(-) or the right(+) from the nose * 10 - 5. If we are 2 steps to the left, this gives us chart_draw_x = -25.
| Variable | Speculated: chart_draw_x | Speculated: chart_draw_y | Speculated: chart_return_x | Speculated: chart_return_y |
|---|---|---|---|---|
| Type | 4 Bytes signed | 4 Bytes signed | 2 Bytes signed | 2 Bytes signed |
| Offset | 94008 | 9400c | 94014 | 94016 |
Events[]
There is an event counter. This increases by one when linking or loading some large parts of the map. Interestingly, object triggers are not being counted as event, however, these interactions completely change whole future walkthrough the same way as linking and loading the map does. It is possible that the game has different variables to store linking events and trigger interactions. There is also speculated " animations triggered " value, which is possibly has something to do with object triggers, but as it been said, it isn't affecting event counter. This topic is still heavily under research. Event counter can be used to detect if something happens. There is also a variable that might hold the return value of the finished event ( finished map load ). The final two bytes (offsets 91674 and 91675) holds the signed values added to the event_x and event_y respectively. This can be used to decide how the event affected the chart x and y values. x = event_x / events_triggered and y = event_y / events_triggered gives a rough approximation of the final chart x and y values. The return value may also act as an ID for every chunk of the maps in which the player is last loaded.
| Variable | Speculated: events_triggered | Speculated: event_return | Speculated: animations_triggered |
|---|---|---|---|
| Type | 4 Bytes | 4 Bytes | 4 Bytes |
| Offset | 91680 | 91674 | 91690 |
| Variable | Speculated: event_x | Speculated: event_y |
|---|---|---|
| Type | 4 Bytes signed | 4 Bytes signed |
| Offset | 91678 | 9167c |
Future memory analysis[]
Textures[]
The texture filenames are stored as text strings. There seems to be pointers to them. They might explain how textures are swapped. Another possibility is that the text strings are only stored by the emulator software.
Music[]
There are many different level-specific music tracks to distinguish from one another. The track number and theme maybe identified by comparing the in-game level music with extracted music tracks. Each level and theme identifies a track. The tracks can be identified using combinations such as AMBIENT_STG00_BGA.
Chart Mechanics[]
The graph changes when the user first modifies the day's variables and then enters the graph screen, suggesting that the positions are stored in arrays. Some unknown variables could also be correlated with the x and y positions on the graph screen you see after each dream. The linking screen colors might be correlated to the positions. One problem is that it is unknown how, not just where, those potential variables are stored. They could also be based on calculations with lots of data. It is also hard to know where zero is on the graph and how that should be interpreted.
Objects[]
Objects such as Greyman are dynamically allocated, which makes it difficult to find them. Using saved states, one might go back and forth within the same dream while the object remains at the same place in memory. It is not known how objects are pointed to (pointers) in the memory. The Greyman object, for example, contains its position and flags to make him fly forward or disable the linking.