Okay, a final draft, from a user POV:
Generic objects live in default.obj, and apply to all levels. These appear in the editor palette as currently, and operate exactly as currently, and include any object where the image and script are identical in all levels. For example health paks, player start points, keys, doors. A maximum limit is applied to this file (say 100). RMB on the tile in the palette (NOT on the map) allows you to edit the generic script.
'Special' objects are created by selecting the 'Special' tile object in the editor palette and pasting it on the map. This assigns a new object ID to that tile (>100), and creates a new object of that ID in LEVEL.OBJ. That new object has an icon of 'Special' and no scripts. The new object ID is stored in the map layer as currently.
RMB on the 'special' object on the map (NOT on the palette) allows you to either re-assign the selected map tile object to an existing object ID(allows shared code for samey spawn points, or for say four laser beam tiles across a corridor), OR edit the object. Editing the object allows you to amend the tile image (allows for switches, visible pressure pads, laser beams), and write object specific script(s).
The game engine changes are now very small - ensure level.obj gets loaded if present alongside default.obj. And that's it, because the id's in the map layer will just point to the relevant loaded object.
Q: Why is this better than a script layer in the map?
A: It allows shared code between objects.
Q: Isn't this exactly the same as Rob's original option 1?
A: Almost. But it allows you to have images assigned to the object too. ;-) Oh, and it largely reuses the existing data structures.
Q: Couldn't you do the same with a separate script layer and an object image layer?
A: Yes. But then you've separated the image and the script, and that just feels wrong and prone to error. It also makes the default objects that bit more complex than they need to be.
Q: Why not parameterise?
A: While it would be neat in terms of allowing us to have a single 'spawn' object that could then be driven by inputs, the reality is that most spawn points are going to vary in nature. And it's not that much effort to drop a special on the map, open the script editor and type "createalien(hugger)". And if you really want to, within any one level you can still reuse spawn point code...
Q: Why are my posts so long?
A: Because.
Generic objects live in default.obj, and apply to all levels. These appear in the editor palette as currently, and operate exactly as currently, and include any object where the image and script are identical in all levels. For example health paks, player start points, keys, doors. A maximum limit is applied to this file (say 100). RMB on the tile in the palette (NOT on the map) allows you to edit the generic script.
'Special' objects are created by selecting the 'Special' tile object in the editor palette and pasting it on the map. This assigns a new object ID to that tile (>100), and creates a new object of that ID in LEVEL.OBJ. That new object has an icon of 'Special' and no scripts. The new object ID is stored in the map layer as currently.
RMB on the 'special' object on the map (NOT on the palette) allows you to either re-assign the selected map tile object to an existing object ID(allows shared code for samey spawn points, or for say four laser beam tiles across a corridor), OR edit the object. Editing the object allows you to amend the tile image (allows for switches, visible pressure pads, laser beams), and write object specific script(s).
The game engine changes are now very small - ensure level.obj gets loaded if present alongside default.obj. And that's it, because the id's in the map layer will just point to the relevant loaded object.
Q: Why is this better than a script layer in the map?
A: It allows shared code between objects.
Q: Isn't this exactly the same as Rob's original option 1?
A: Almost. But it allows you to have images assigned to the object too. ;-) Oh, and it largely reuses the existing data structures.
Q: Couldn't you do the same with a separate script layer and an object image layer?
A: Yes. But then you've separated the image and the script, and that just feels wrong and prone to error. It also makes the default objects that bit more complex than they need to be.
Q: Why not parameterise?
A: While it would be neat in terms of allowing us to have a single 'spawn' object that could then be driven by inputs, the reality is that most spawn points are going to vary in nature. And it's not that much effort to drop a special on the map, open the script editor and type "createalien(hugger)". And if you really want to, within any one level you can still reuse spawn point code...
Q: Why are my posts so long?
A: Because.