New BUILD map format: Difference between revisions
Jump to navigation
Jump to search
Hendricks266 (talk | contribs) No edit summary |
Hendricks266 (talk | contribs) No edit summary |
||
| Line 21: | Line 21: | ||
==Behavior of the editor== | ==Behavior of the editor== | ||
We'd still want to save old map formats on occasion, like when making test maps that need to be opened in e.g. Duke3D 1.5. | We'd still want to save old map formats on occasion, like when making test maps that need to be opened in e.g. Duke3D 1.5, and when creating maps for other BUILD games. | ||
<br/> | <br/> | ||
<br/> | <br/> | ||
[[Category:Developer's corner]] | [[Category:Developer's corner]] | ||
Revision as of 15:15, 7 July 2012
This page serves to collect and discuss ideas about a potential future map format for the BUILD engine.
Proposals
map-ng (helixhorned)
That is, pretty much the same thing as now, but with some fields rearranged for convenience, and others added.
- sector[] .ceiling*, .floor* --> sector[].cf*[2], indexed by YAX_CEILING (0) or YAX_FLOOR (1). So that less code is almost-duplicated. Downside: worse readability?
- sector[].cfbunch[2], to keep xpanning free
- Support for additional information (author, per-map settings, ...). The most general way of accomplishing that is packing scripting code that would be run on map entry (near/similar-to EVENT_ENTERLEVEL) into the map
map-text (TerminX)
Purely textual format, similar to the "Universal Doom Map Format" (UDMF).
Behavior of the editor
We'd still want to save old map formats on occasion, like when making test maps that need to be opened in e.g. Duke3D 1.5, and when creating maps for other BUILD games.