Make data formats friendlier to external editors

[kemenaran]

External data editor (like level editors) may need to edit a data file, or even replace it completely. For this reason, data files should be easy to edit programmatically.

I think the project should favor simple assembly for data files (over complicated constants and macros). Richer details can be inserted as comments, which keeps the file readable while making it easier to edit.

For instances, the entities definitions for each room could move from:

Overworld00Entities::
  entity $6, $7, ENTITY_MINI_MOLDORM
  entity $2, $4, ENTITY_HEART_PIECE
  entity $2, $6, ENTITY_CROW
  entities_end

Overworld01Entities::
; snip…

to

Overworld00Entities::
  db $76, $23 ; ENTITY_MINI_MOLDORM, x:6, y:7 
  db $42, $35 ; ENTITY_HEART_PIECE, x:2, y:4
  db $62, $7A ; ENTITY_CROW, x:2, y:6
  db $FF      ; end of list

Overworld01Entities::
; snip…

[Rangi42]

In my experience with Polished Map, high-level macro data files are easier to programatically read and write than raw hex dbs with comments, especially if you want to keep the comments in sync with edited data. Like in your example, a entities_end line would be easier to parse than looking for db $FF (or equivalents db $ff, or db 255, or db -1). (You would at least some parsing, to extract hex/decimal/binary numbers and ignore comments, and at that point you may as well be recognizing custom macros like entity.)

[Xkeeper0]

The other unstated problem with this approach of "just use hex values" is that your editor still has to understand what those hex values mean.

Like, yes, a naïve editor might have an easier time parsing "14 58" than "entity 1, 4, ENTITY_DOORSTOP", but it also now needs to know that 58 = a doorstopper (and also keep that in sync).

iirc the NoDice Super Mario Bros. 3 editor works directly off of the disassembled files (and even includes a built-in assembler for its level renderer). so yeah, probably not the best of ideas.