Some people might still remember my .hack//fragment localization project.
Since then I've been spending my time wondering just what would be the best legal way for developers to build a authentic .hack MMO.
And I've figured out a proper way to do it.
To those that don't know the word MAD - it means Media Access Driver, its a layer providing a useable API for accessing third party devices, usually some kind of disc media, or similiar...
This time around, the .hack discs, be it INFECTION up to FRAGMENT or GU 1 to 3, will be the media in use.
And to access the archives properly, my MAD will do the dirty work.
I've spent quite some time reversing the CCSF format in use on all .hack games so far, I figured out its using a database like storage system for its data, splitting a file into multiple objects, and those objects into multiple variable sized sectors.
The library, as of the time of writing, isn't complete yet, but is capable of resolving all those referential links in the data storage of the games, which equals about 60% of the work necessary to access the files on disc in a useable way for game developers.
The reason I'm posting this topic early, even though I'm still working on this library, is because I'm searching for someone to step in my footprints, to take this baby all the way in my stead once this library is complete, to make a full The World MMO - based on the simple system of inserting the ps2 game disc into your computer and being able to play.
And before the flaming starts because I'm not posting code yet, let me say some last words, Cyberconnects users, aka. Joseph Stacko Slaves - I won't accept them as my heirs.
EDIT - Because the general oppinion on dothackers seems to be "not real until someone shows proof" - I'm providing some of the information I've gathered so far.
Code: Select all
All .hack games released so far (.hack INFECTION, MUTATION, OUTBREAK, QUARANTINE, FRAGMENT and GU 1-3) are using a storagesystem made by Crysoft - a japanese company that designs all kind of media tools. The idea behind this storagesystem is minimizing loading times by effectively using physical properties of DVD discs... (Outer Cylinders reading faster than Inner Cylinders, effective file splitting for loading only necessary components, etc.) I can't fully make out what the short-name of the filesystem means - but it seems to be CCSF. Each CCSF File Storage (About 7800 of those in .hack FRAGMENT, about 15000 in .hack GU 3) contains a variable number of files, mostly .max 3D scenes + animations aswell as materials, and is compressed using the opensource deflate algorithm provided by the zlib library. After proper decompression the storage is made up of different blocks, each CCSF storage has atleast 3 blocks, 2 header and 1 data block. The Header Block has the opcode 0xCCCC0001 and contains nothing of real interest, besides the CCSF magic code that identifies the file as CCSF storage. The second block contains the file and objectlist and decides which objects are linked to which file, it's opcode is 0xCCCC0002 and contains information like "number of files" aswell as "number of objects" and the referential integrity, similiar to a database system. Each block carries a size field, that contains the blocksize divided by 4 - ored with some binary flags that give further information about the blocks contents. Each block, except the two information blocks at the beginning carry a reference field, which in turn indicates to which object the block belongs, again - several flags are ored into this field aswell. So the overall way the system works is like this... testcharacter.max (file) |--arm_left (object) |-- block 1 (data block) |-- block 2 (data block) |-- block 3 (data block) |--leg_left (object) |-- block 1 (data block) |-- block 2 (data block) ... Of course, the system is a bit more complicated than this display, but it makes the system and how it works understandable to those that have no idea of database systems. There are many different types of data blocks, each containing different data, etc. Each block is identified by its opcode, just like the two information blocks at the beginning of the file, each opcode is unique and used to identify the block contents, they all follow the same opcode schemata of 0xCCCCXXXX. I hope this bit of information I've provided so far is proof I'm actually working on something real, and that the doubters finally get the idea of how much effort it is to fully reverse this structures and make proper use of the data inside. For those interested in the case... 0xCCCC0300 = Color Table for Materials (Yes, they are indiced, every material in the .hack games has no more than 256 colors). I hope to get some more work done on the MAD this weekend and hope to provide a opcode table for those interested soon.