Paul Barba - 2009-04-27

One of Squidi's suggestions was that it's easier to operate on the level of multi-tile objects, like tables and windows, rather than the individual tiles that make up the objects. First of all, we need a name for this concept. Map Object could suffice, although I'm reluctant to use the term object, since it already has such a important meaning in programming. Suggestions?

Additionally, there's the question of implementation. At it's simplest you could simply list tiles, either forming an explicitly sized object, or assigning a tile to each role (NE corner, SW side, center, etc.). This would be easy to express in YAML/XML. However, it's rather limited in it's expressive power. With a more complicated syntax, we could localize procedural generation algorithms within the map objects. I think there's a lot to be said for this technique: It modularizes the PCG code, so you can plug in a table and end up with map's with red table cloths and bare wooden tables and tables with place settings out. While the map-level logic could put down the items it wants on a table, it strikes me as more elegant to build objects procedurally separately.

I'm thinking that a Map Object interface would be appropriate for this, and we could implement map objects with logic to build themselves. One interesting addition would be the ability to supply parameters to a map object. Keeping with the table example, you could request a "rich" or "poor" table, a "modern", "futuristic" or "caveman" table, a "red" or "blue" table, etc. etc. Expose these parameters in the map script language, and user's can easily build internally-consistent maps that span multiple themes. While you could have separate Map Objects for each table type, it strikes me as elegant to be able to reskin a map from an impoverished hovel to a stately dining room with just a changed parameter.

I've got thoughts for the API/data structures, but I'd like to get other people's insight into this.