OFFICIAL 5.0 SUGGESTION THREAD!

rimoJO

Member
whether it be 1 or 3 save files, or possibly a password pak...
long term saving
yes,
long term saviiiiiiiiiiiiiiiiiiiiiiiing
 

Grimsley

New member
I know this is probably going to happen at some point anyway, but I'll throw my hat in the ring... Would an RPG module be reasonable? I have wanted to do an authentic NES RPG ala the Dragon Warrior games since I was a young kid but never had the resources or time to pursue it. I've messed with NESmaker a bit and I think it's THIS close to realizing that dream... but unfortunately certain memory/design limitations make it very difficult to create that type of game with the current tools. If another module were to be added, I think a text-based RPG would add the most versatility to NESmaker's current toolset.

EDIT: for those reading this in the future...I believe it's been confirmed that something like this is being worked on right now by the NESmaker guys. I'll update this if I learn anything else. :)
 

Lollie

New member
I have a small laundry list of improvements I'd like to suggest, and I'm using visual mock-ups to help convey them. Admittedly, some of these fall between "tool" and "engine" suggestions, but I hope they're still useful to consider.

Getting the biggest suggestion out of the way first, intended for cores that make use of map-scrolling:
Streamline the "Screen Scrolls [Direction]" and "Edge Stops Player" options by allowing users to create Screen Groups.

ScrollGroups.png

The idea is to let users visually select which screens should scroll, as well as determining where a group of screens should stop scrolling - all without ever having to open a "Screen Info" menu.
A user could create a group simply by clicking and dragging to select multiple maps, and then right-click to open an options menu, where they can select the option "Create Screen Group". Similarly, if the user wanted to add or remove screens from groups, they could open the same right-click menu and select "Add to Screen Group..." or "Remove from Screen Group" respectively.

(Also, yes, selections could also determine whether a Screen Group scrolls horizontally or vertically. Even if Vertical Scrolling doesn't happen in 5.0, I'm sure it'll happen eventually.)

In the case where the user wants screen edges to have different behaviors, the Screen Group's border could be colored to indicate what features are toggled at a glance.

GroupBlockEdge.png

For example:
  • A solid red border could mean that it blocks both the player and camera from moving.
     
  • A solid light blue edge could mean that the player CAN move off-screen and transition to a new screen. (the camera stays stationary, as it has reached the end of the screen group)
     
  • A dotted black divider could mean that a flag needs to be set before the camera can continue scrolling — defeat all enemies on screen, or a mid-level boss, or a puzzle that blocks the way. Etc.

-----

Moving onto briefer suggestions, with a bigger mock-up image!

GameObjectAdditions.png

  • (not visible in the mock-up above) A way to toggle 8x16 hardware sprites, project-wide. This is a must-have for games designed for larger character sprites.
     
  • A "Draw Nothing" tile, to remove the use of wasted blank sprites in larger game objects. This speaks for itself.
     
  • "Show Alpha" option. This is a quality-of-life feature, an alternative to changing the global color while working.
     
  • Show all four palettes, and allow users to freely assign Sub-Palettes to game objects. (explained below)

Currently, the way palettes are broken up for players and monsters is needlessly limiting, and enables redundancy if a monster/item game object is designed to share palettes with the player.
Instead, allow users to assign Sub-Palettes to sprite tiles — much like how you can use sub-palettes to repaint tile colors on the Screen-Painter, except at a game object level.

This would enable all game object palettes to be controlled on a per-screen basis, including the player object. This change would require users to design game objects and palettes more thoughtfully, but it would open NESmaker up to much more interesting usage of palettes.

-----

I have more suggestions to share, but this post is already long as is, so I'll save them for another post.
 

rimoJO

Member
Honestly, tN8bH needs to add a easy-to-use rpg module. that would be the minimum, but maybe more could be added as well, like possibly building a party to help you defeat enemies quicker, literally everything in Mystic Searches, and more. I want to make a game like that. So does everyone else. so please, New 8-bit Heroes- we need your help, and so it's time to save the day. That's what we all want.
 

Lollie

New member
Dang, I was hoping to see a little discussion about some of the suggestions I raised here, before posting more of them. Oh well, more incoming!

I'm personally not a fan of the HUD's automatic border, and I find the use of HUD Assets + HUD Elements for custom HUDs to be kind of unnecessary. I'd much rather see the Screen Painter tool applied to the HUD - with 8x8 tiles, because the HUD can be easily reused across the whole game, so memory should be easier to allocate.

Mockup Image:
HUDTilePainter.png

In addition to tile-painting directly into the HUD:
  • The ability to use two tilesets for HUDs. This would allow for Uppercase and Lowercase letters, as well as more detailed UI graphics.
     
  • "Half Tile" value, for graphical UI elements that can convey a "half-full" state, eg: half-hearts.
    (In the mock-up above, I've used "capsules" instead of "hearts", but the concept is the same: Two capsules is a "full tile", one capsule is a "half tile", zero is "empty tile")
     
  • Access to Background Palettes. The HUD uses background tiles, so access to background palettes would be great for more colorful HUDs.
    Much like my suggestion for full palette access in game objects, this would require the user to plan color palette usage more carefully in order to make the best use out of them, but I see no reason why this couldn't work on a functional level. You would need to convey that palettes can only be applied on a 16x16 grid - I'd suggest showing a 16x16 "tile painter" square specifically when applying palettes.
     
  • A small quality-of-life change: Show Number Tags for HUD Elements when "Show Element Boundaries" is enabled.
     
  • One last suggestion here, not conveyed in the mock-up: More control over the appearance of textboxes.
    I feel the current automatic border and "Assets + Elements" approach could be better utilized here, at least for simple textboxes. It could also be useful for designing interfaces for shops or level-up screens, but this is more of a far-future thought.
 

rimoJO

Member
What I think should be in NESM is:
A top-down RPG module for making Mother-style games.
Startropics-style jumping for top-downs, like in Mystic Searches.
Everything in Mystic Searches. Actually, having a Routines folder for everything in Mystic searches, as well as a module would be nice.
PLEASE GIVE US LOWERCASE LETTERS FOR HUDS AND TEXTBOXES. WE'RE ALL TIRED OF TYPING LIKE THIS. THIS HAS BEEN DONE IN NINJA GAIDEN SO PLEASE MAKE IT POSSIBLE IN NESM. THANKS.
Speaking of text boxes, a more interactive text box setup menu would be great.
A dark mode would be nice, too. Sometimes I work in the dark, and the constant brightness of NESM can be stressful.
For text boxes, instead of > adding a new page, there should just be a button that does it. again, interactive text box UI.

And everything before this comment is a great idea.
(I hope this comment gets noticed...)
 

Attachments

  • Capture.PNG
    Capture.PNG
    99.9 KB · Views: 4,656

Croque_Monsieur

New member
Could we please have a Cutscene maker? And better tools for special screens editing.
Say you make a "scene" and have an option to just have it connect to another or to resume the game.
Open Screen Maker Tool> Make a scene (title screen, whatever) > game
And to be able to make little intros for levels or boss battles, these "scenes" could also be used for the end credits and so on.
 

Mugi

Member
here's an important suggestion;
make it possible to manually edit the ram defines (modulevariables, ZP_RAM, system_RAM) without the UI overwriting your changes on export.

currently it is impossible to edit ram defines without the tool overwriting your changes because the UI does not refresh from the file, and hitting compile just exports the old variables from the UI back to the file,
destroying any manual changes made.
 

Dirk

Member
I don't know if this has already been suggested.

  1. Select active tile with "ctrl + left mouse click".
    When you are constructing your levels "ctrl + left mouse click" on an already placed tile would select this tile as your new active tile so you don't have to choose it from the assets list.
    A bit like the pipette tool in many programs, but for tiles.
    I know you can make groups, this just makes designing levels a bit more convenient and faster.
  2. Set a tile as your "deletion tile".
    When pressing "del" on your keyboard the tile under your cursor gets replaced by the "del tile". Pressing "del" is very common in many programs and is very ingrained in people's muscle memory so it'd be nice if the habit of pressing "del" would translate in NESMaker as well.
  3. Options for scrolling preferences in level editor.
    You don't have to open a menu for changing your scroll behavior and you also can see with a glance what it is set to.

Here is a picture for illustration.


suggestion_01.png
 

Dirk

Member
Some other suggestions:

  1. Show a tiny number next to a placed monster so you don't accidentally replace it when you really wanted to add another monster
  2. Make it possible to remove a certain monster. It might already be possible and I'm just a bit blind, but I can only delete all placements and start placing monsters all over again
  3. Set offset of monster projectiles like you can do with player projectiles.
    Bonus: It would be nice if you could drag the projectile around and drop it at the right location.
  4. Add a script for running like in previous versions.




suggestion_02.png
 

Dirk

Member
I made a quick mock-up for the Monster projectile screen with a small addition.

Dragging the projectile sprite around automatically updates the numbers for x and y offsets.
Instead of having to set the offset for each and every direction you can select for wich ones you want to set the current offsets.
In the picture you can't deselect "Down", because it's currently active.
It would be great if you can choose a different projectile for each enemy.


suggestion_03.png
 

taluigi

New member
gxBeBZ8.png


Is something like this even possible or even considerable? :oops:
 

Lollie

New member
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!

NESMaker_GameObjects.png

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.

Metaobjects.png

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??
Metaobjects-SpawnerMarker.png
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?
 

bluefoxicy

New member
Super NES controller support. If wired to the NES, you can read the X Y L and R buttons by continuing to interpret controller bits. On an NES controller these will be 0 0 0 0.

Technically you could also read byte 3 and 4 as [XXXX YYYY] with X and Y being -7 to 7, byte 3 is left analogue stick, byte 4 as right; and read byte 2 as A X L R L2 R2 L3 R3 for an extra trigger button and the analogue stick buttons. That's a bit of overkill and would also require talking to 8Bitdo about passing second shoulder buttons and analogue sticks to the NES and SNES through their receivers with that protocol.

The SNES A X L R buttons can be wired in by wiring the official SNES controller to an NES connector and plugging it into your NES, no fancy third-party goings-on needed.

Good game design would suggest ensuring the player doesn't need A X L R, but that they are convenient.
 

bluefoxicy

New member
TheNew8bitHeroes said:
@Convoy_Avenger - good suggestion, but that memory space is regimented for a reason. What would end up happening is if you started to change those things, the regimented memory space would break down. That would lead to constant compilation issues. That's one thing we did to make NES development easier to a WYSIWYG type tool. It's possible that you could load existing screen specific tiles in that space or something like this, but then it's very difficult from screen to screen to control that, and it will wreak havoc on things like animated tiles and other specifics of tiles. Not impossible, but...that's pretty baked in, and it all has to do with memory management. :)

Would this be better if your window was 48K of 4K segments with 16M used for both PRG RAM and CHR RAM (mappable to either)?
 

Dirk

Member
This has probably already been suggested, but I can't find anymore.
Add an option in the NESmaker menu to change your language.
I have a new install and I can't remember in which file I had to change the language of NESmaker.
 
Top Bottom