New export: areas

[bates64]

After some discussion with clover, I realised that removing the game's notion of 'areas' is not a good idea - namely, enemy defeats, collected coins, etc are remembered until the player leaves their area. There is no cleaner way to support this than just using standard areas.

That means adding a new export type: areas, which encapsulates both maps, stages, battles, and possibly relevant resources such as textures or backgrounds. (On the latter two, they could also just be their own exports as one can override backgrounds/textures on a per-map basis...)

src/
  area/
    <name>/
      <name>_bg.png            -- ???
      <map name>/
        <map name>.xml
        <map name>.mscr
        <map name>.toml
      <stage name>/
        <stage name>.xml
        <stage name>.bscr    -- script file extension is how stages are separated from maps
        <stage name>.toml
      <battle name>.toml    -- or possibly <area name>.toml with [[battles]] array

• Areas which use particular entity sets ("normal", "jungle", "desert") are detected automatically and will be placed into MapTable.xml areas accordingly
• Areas and maps may have arbitrary names as long as they are unique within the package
• Areas defined in a package are guaranteed to end up in different MapTable.xml areas
• Areas defined in different packages may be combined at assembly time

Applying the above rules, specifically the last two, the following structure:

parent_package:
  depends on 'child_package'
  exports an area using general entities called 'parent_area'

child_package:
  exports an area using general entities called 'child_area'

Could end up producing a maptable like:

<Area name="kmr">
  <!-- parent_area maps -->
  <!-- child_area maps -->
</Area>

Special maps such as those loaded on First Play and Game Over can be set per-mod. The simplest implementation of this is probably by placing references to the configured maps into the specific indexes of the MapTable that said special maps occupy.

Discussion & feedback before implementation would be appreciated! Questions we need to answer:

• Should stages and battles be included as part of area exports?
• Should battle formation configurations be combined in an <area name>.toml or separately in multiple <battle name>.toml files? The latter, if just placed in the <area name> directory, is somewhat inconsistent with the way the rest of starpkg's file structure works!
• Should backgrounds / textures be a separate export resource?

[bates64]

Discord discussion:

Lord Ruby

Ah, this explains why I had a bad feeling about removing areas.
To be fair it's not like everything needs to change. Areas only matter for maps (and possibly stages > if we want to save texture memory).
Each area could probably just be a single file that defines which maps it contains, and how those > maps' exits and entries connect.
(And then some master area file I guess that defines how exits/entries between areas connect.)

alex

you're thinking about entries/exits? interesting

Lord Ruby

So I guess an example of how it would work is something like this:

Package M
Dependencies: A, B
Files: Mod configs and whatnot. Defines the starting map (1), and that area A's east exist connects > to area B's western entry (and vice versa)

Package A
Dependencies: Packages with maps 1-4 (which in turn contain textures, enemies, and the like)
Files: Area file. Connects the maps. Defines area exits/entries as west of map 2 and east of map 4.

Package B
Dependencies: Maps a-e.
Files: Area file. Connects maps. Area exits/entries: north of a, west of b, east of d, south of e.

Which compiles to:

        |
1       a
|       |
-2-3-4-b-c-d-
        |
        e
        |

Obviously not complete but to convey the point.

alex

I think I understand
I was thinking that a simpler Call GotoMap ( {Map:package/area/map:entry} ) would be fine
oh wait
I see where you're going with this
without some kind of exit/entry manifest maps defined in dependencies don't know how to connect to yours
that's.... a difficult problem
we could solve it your way, or we could make a more generic configuration system for dependencies e.g.

name = "M"
version = "1.0.0"

[dependencies.A]
version = "1"
config = { east_exit: "B/awesome_area/b:Entry0" }

[dependencies.B]
version = "1"
config = { west_exit: "A/cool_area/4:Entry2" }

packages can define what config they take via:

name = "A"
version = "1.0.0"

[config]
east_exit = "map_entry"

% A/src/area/cool_area/4/4.mscr

#new:Script $Script_Exit_East
  Call GotoMap ( {Config:east_exit} ) # expands into {Map:B/awesome_area/b:Entry0}
  Return
  End

or we could just do simple string replacements like GotoMap ( {Map:{Config:east_exit}} ) and not bother with types - this should be fine right?
might be worth making the config system more nuanced in the future which brings into question the {Config:x} syntax, e.g. if I want conditional compilation
Star Rod uses {...} already for its expressions, too; could move away from that?