| sundin13 said: @ Tachi: Just out of curiousity, do you know anything about the difference in cost between what Nintendo is using and what would be enough to three or more save files? |
Difference would be around $0.60 per amiibo, but the issue is more that the NFC reader on the WiiU is a broadcom 20792 low power module, its datasheet doesnt state any compatibility with type 3 nfc, so in all likelihood, they potentially couldnt use the higher capacity units even if they wanted to.
Looking through the SDK documentation, how it works is the console NID and savedata is compressed into a single string encoded in base64, the string is then encrypted and stored with a private key, if someone elses data is read, the private key decrypts the string and can pull the NID and save string to use in the software.
Their approach is to have the game software translate the save data to a string, much like old games giving you save progress in a short series of numbers and letters, the crypto on private key prevents the tags being modified and the latter 32byte of memory is used for a basic handshake as was done with disney infinity tags, a separate security inclusion to try and stop generic readers dumping the data.
So I would, based on that info, assume that they are use up to 64bytes for encrypted save string and the remaining 32 bytes for security layer, thus using 96byte tags.
You can, with compression, store a decent amount of data in 64 bytes, even with the header, but multi-save support would cut into the available space per title, then you would need to implament a secure data management routine in to the SDK for decrypting data, reading the whole array then allocating different parts of the data to different titles, and that sort of management is not in the latest SDK, literally just read/write/encode/encrypt support.
