Hello. I'm trying to wrap my head around a tricky design issue and I need to take a clear look at what I'm dealing with, so I'm putting this out here for my own benefit and should anybody passing be inclined to provide their input.
The golden rule for level editors that I have discovered, having been coding them since 1999, is: _"Objects are always more complicated and involved than you think."_ (Where an "Object" is a 'Movable Object Block', typically a sprite / enemy / player character &c.)
In MaSS1VE--The Master System Sonic 1 Visual Editor--the objects in a level consist of a variety of resources, and most difficult and complex of all:-- dependencies.
The 16-colour palette used for sprites is per-level, not per-object! Which objects appear on which level _cannot_ be arbitrary. Not all palettes are compatible with all objects.
With the current assembly code, the objects allowed on each level is completely fixed. The objects are hard-coded into the tileset used for sprites and their graphic offsets implemented in ROM. This makes things at the Alpha stage easy, but limited. The long term plan is to allow the user to create levels from scratch and to select [mostly] arbitrary objects for a level as suits them.
I plan to entirely rewrite the object code in Sonic 1 so that any object is loaded on-demand when it comes on screen so that a level may use more objects than can fit into the tileset normally.
MaSS1VE combines a number of inter-dependencies in Sonic 1 into a "theme". A theme such as "Green Hill" will be based on the graphics for the level and compatible palettes (day, night for example). This is done so that end-users are limited to non-breaking choices.
In the original ROM the graphics for the objects are supplied in a single tileset for the whole level theme (Green Hill acts 1-3 for example). In one instance the same object might be used in two themes (the floating platform in Green Hill and Jungle), but using different graphics! So, an object needs some way to provide alternate graphics for different themes, but not in 99% of instances.
In the long term, I would like users to be able to install new objects to use in their projects. What happens if a user opens a project that contains an object that they don't have installed? What is the best way to handle custom objects as well as the original objects in the game?
Are objects part of the editor, or are they part of the project? That is, we could take the approach of bundling the objects into the user's project so that it becomes portable. But then, how do we handle versioning and compatibility? An object consists of graphics and Z80 code. We would therefore need to bundle the entire Z80 source code in the project. And what if that gets updated? How do we update the existing project's copy, without potentially breaking 3rd-party objects and their Z80 code? It's so messy.
The more typical approach is to make the objects part of the editor install and not the project contents. Updating and versioning is easier but document portability is reduced.
Is the object a part of a theme, or tied to a theme in some way? One object will not be compatible with every palette, and nor will it provide individual graphics to suit every theme's tileset. If we mark objects as being only compatible with certain themes, then we immediately restrict the user making (or importing) custom themes. I suppose we will just have to allow the user to use any object on any theme and if it doesn't look correct then they will have to be the judge of that instead of trying to enforce that in the design.
Objects will have to come in multi-object bundles since Z80 code is often shared between similar items (the monitors being a primary example). That I do not feel is so much a problem.
At the moment, MaSS1VE unpacks the ROM and generates a project in-memory from it. The plan is to do away with the need for an original ROM entirely and instead ship a 'template project' that acts as a starting point.