Fileformat is the SQLite3 DB, so here we will discuss the table structure:

Database world

Table sections
  id integer primary key autoincrement
  x integer
  y integer

Table terrain
  id integer primary key autoincrement
  sectionID integer
  x integer
  y integer
  red integer
  green integer
  blue integer
  goto integer

---

World may be Peresphone or GreenLeaf or...  Each world will have its own database file.

For simplicity, the world will be cut up in squares and numbered according to Euclidian Geometry.  These _sections_ are basically indicies.  Each section's _terrain_ will be a q by r meter square, where q and r are yet to be determined.  Perhaps 10 by 10 for proof of concept purposes?

The red, green, blue in the terrain table is the colour that will be displayed for that particular square.  This is only for testing purposes and will be changed later.

The goto column is for when if a player steps on that square, they will be taken to that section.  It will be set to 0 if they are to say in this section.  For 1, 2, 3, 4, it leads to the above, right, below, left section respecitively.



Future formats should also contain whether the square is walkable or not.

Future formats should have the ability to have non-flat terrain ie floors to a building, etc.

The future ship format must be able to handle non-flat terrain within the section itself ie catwalks can see below.

