NES style game in Unity - Part 8 - Storing the levels!

Hello and welcome to the 8th part of my thoughts on creating an NES style game with Unity!
I'm still at the beginning of developing my game. Before going into it I want to do some preparations and also learn some new things. My newest  idiocy is about storing the levels. So originally I started to create my levels in Tiled which is an absolutely amazing editing tool for tilemap based levels. So sounds perfectly ideal for me. But there are a few things that it can't store. So after reading a lot about NES game development I was thinking about storing the levels the same way as NES did.

Opening scene of Castlevania with the tile indexes in hexadecimal.
Original image source: http://www.dustmop.io/blog/wp-content/uploads/2015/04/castlevania-nt.png

What if I store the levels in simple text files? I can spend 1 byte / tile instead of wasting a lot in an XML file. Tiled uses XML and it stores many data. And nowadays actually XML is not a big deal in term of filesize and memory and it's easy to serialize and deserialize. So why do I go that far? Because... why not? Because for what I want, using simple binary format is perfect.

I can store my levels like NES did. Nametable with 32x30 tiles. 960 KiB data per a so called nametable. It'll store the tiles. Other than the 960 KiB tile data I can use more space for attribute table, and other things that comes to my mind. Of course I won't copy 100% that NES did. Probably I'll use additional bytes to store additional data.

The good thing is that it's easy to create an editor for this. I'll do it in Unity. A separate map editor that can write and read maps. It's a fun challenge actually and I am looking forward to complete it.

Reading this format will be easier than the XML I have right now. The XML stores lots of unnecessary data but it doesn't store attribute table. Yeah, it's a very old school method and hard to read the files as a human but the program will handle it with ease.

Obviously, reading all the data is not enough, I need to write some simple scripts to that turns the data to graphics. probably I'll use multiple sprites and multiple materials for this. Multiple materials will be needed for the different palettes, however the texture where the tileset comes from will be the same. Except if I'll need to use more than one tileset for a scene. in that case, I'll need some trick since normally this method can read only 256 different tiles and it assumes there is only one tileset / nametable. Other interesting topic is the collision handling. I'll need to have a definition for different tiles. Which one is passable which one is a slope, which one is a wall, etc...

Hopefully I can post a video about the editor itself soon.