I have a massive feature suggestion that I've been sitting on for a while. It's outside the scope of 5.0 suggestions, but I have no better place to share it, and I need to get it out of my head, lol.
It explores a concept that I don't believe has been touched on in NESmaker tutorials:
Metaobjects.
Think about how "metatiles" currently work. NESmaker requires the user to create 16x16 meta-tile assets out of 8x8 tiles - you're using multiple tiles to create the final meta-tile asset.
Metaobjects would follow that same idea: Using multiple game objects to create the final in-game metaobject. It'd be like having one "parent" object, that is actually made out of multiple "child" objects, and they all work together.
You can also think of this as an expanded version of the "melee/projectile" editor — the screen you see when you click on "Game Objects" in the project tree. This is a metaobject!
Currently, NESmaker gives you two states to edit: "Melee" and "Projectile". These have their own default game objects, "Melee" and "Projectile Source". Each state can have up to eight directions, but these two game objects are separate to the "Player" game object! So in order for these game objects to work correctly, the user sets different X and Y position offsets for every direction that they want to use. These are basically just instructions that tell the game where to spawn these game objects.
---
With that explanation out of the way, here's the obligatory mock-up image to help visualize a dedicated "Meta-objects" feature.
From top to bottom:
1) The name of the meta-object, the current action set, and the direction that is currently being edited.
Ideally, the user would be able to set up a meta-object with all the actions they need.
2) The "Metaobjects Details" button.
It would do nearly exactly what the "Object Details" button currently does for game objects - including its own hitbox, but
excluding animation. Functionally, a meta-object controls multiple game objects at once, but different objects have different animation needs.
This would tell the "parent" how much health it has, how to move, whether it is persistent, etc, and all the "child" objects would follow its lead — unless told otherwise, as you'll see further below.
3) At the top of the "Manage Game Objects" panel:
A list of game objects and spawners attached to this meta-object, and
Sort Order for game objects.
Maybe you have a large sprite with limited animation frames, and a smaller sprite that is more animated and dynamic. Using multiple game objects would give you the best of both worlds, without wasting memory.
Or, maybe you want to push beyond the color limit Megaman-style, and layer two game objects over each other. Sort Order would ensure that your game objects appear as expected.
Also, buttons to add/remove game objects and spawners, in relation to the current
Metaobject Action - anything set for one Action should be present in every
Metaobject Direction attached to that Action.
4) Options specific to the currently selected game object.
In the mock-up image, a "tail" game object is selected. It sits underneath two larger player game object sprites, but you can see its boundary box over the top.
Object Details are available from this screen as a quality-of-life feature, in the event that "Inherit Metaobject Actions" is unchecked. X and Y Offset set the positions for game objects, relative to the metaobject.
5) The first checkbox "Visibility priority over monsters" is necessary due to NES sprite limits.
The consequence of using meta-objects is that they hit NES sprite limits
very quickly. This checkbox would allow the user to decide whether a game object should always try to be visible, or if it's okay to let it flicker/disappear when required.
6) The second checkbox determines whether a game object inherits the Metaobject's actions.
Most player objects will likely have this ticked for simplicity's sake, allowing the metaobject to take care of things like movement speed or AI routines. This would mean less processing power is required while handling multiple game objects, as the child objects would only need to listen to the parent.
In instances where a game object requires its own action routines or hitboxes, unchecking option this would allow for more granular control over game object behavior.
7) Game Object Animation
Unlike normal game objects, metaobjects don't have their own sprites, and thus do not have animations. Instead, the metaobject simply tells the game object which of its
own animations it should play - meaning one game object's animations can be reused over multiple metaobject actions.
If a user wanted more complex animation routines (via game object actions), they could disable "Inherit Metaobject Actions" - which in turn would disable listening to the metaobject for animation data.
Again, I believe animations should be applied in relation to the current
Metaobject Action - one animation setting would apply to every
Metaobject Direction in that Action.
8) What the heck are these for??
They're markers for object spawners! They're for when you need projectiles or particle effects. Some game objects, like projectile spawners, simply don't need a sprite — it's better that they don't clutter the editor view, or contribute to the sprite limit in-game.
---
This is easily the last big thing that I can suggest for NESmaker for a long while, lol. Hopefully some of this can be considered for a future version of NESmaker. 6.0? 7?