OFFICIAL 5.0 SUGGESTION THREAD!

User avatar
Dirk
Posts: 388
Joined: Fri Mar 09, 2018 5:30 am

Re: OFFICIAL 5.0 SUGGESTION THREAD!

Post by Dirk » Mon Aug 26, 2019 1:42 pm

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
suggestion_02.png (4.69 KiB) Viewed 1664 times
-----
Disclaimer: English is not my first language, so mistakes are bound to happen.
User avatar
Dirk
Posts: 388
Joined: Fri Mar 09, 2018 5:30 am

Re: OFFICIAL 5.0 SUGGESTION THREAD!

Post by Dirk » Mon Aug 26, 2019 8:55 pm

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
suggestion_03.png (48.03 KiB) Viewed 1648 times
-----
Disclaimer: English is not my first language, so mistakes are bound to happen.
User avatar
rimoJO
Posts: 246
Joined: Sat Jan 12, 2019 2:23 am
Location: Planet Earth

Re: OFFICIAL 5.0 SUGGESTION THREAD!

Post by rimoJO » Fri Sep 06, 2019 12:02 pm

Ctrl+Z for undoing block placements in the overworld editor.
Mystery Game status: Currently at least one in development. Stay tuned!
erockbrox
Posts: 50
Joined: Sun Mar 11, 2018 5:40 am

Re: OFFICIAL 5.0 SUGGESTION THREAD!

Post by erockbrox » Sun Sep 22, 2019 6:02 am

Make everyone easier and more intuitive to use and make stuff drag and drop.
User avatar
taluigi
Posts: 6
Joined: Mon Sep 23, 2019 9:13 pm
Location: Faro

Re: OFFICIAL 5.0 SUGGESTION THREAD!

Post by taluigi » Sun Sep 29, 2019 1:24 am

Image

Is something like this even possible or even considerable? :oops:
User avatar
Lollie
Posts: 6
Joined: Wed Mar 07, 2018 3:01 am
Contact:

Re: OFFICIAL 5.0 SUGGESTION THREAD!

Post by Lollie » Tue Oct 22, 2019 4:03 pm

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
NESMaker_GameObjects.png (2.93 KiB) Viewed 1169 times
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
Metaobjects.png (41.13 KiB) Viewed 1169 times
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
Metaobjects-SpawnerMarker.png (622 Bytes) Viewed 1169 times
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?
User avatar
axbakk
Posts: 99
Joined: Thu Sep 26, 2019 9:17 pm
Location: Axvall, Sweden

Re: OFFICIAL 5.0 SUGGESTION THREAD!

Post by axbakk » Mon Oct 28, 2019 4:41 pm

Option to change if you want to make Ntsc or PAL games?
Noobing around NESmaker just for fun! Totally noob in gamemaking and have no experience in programming! But I love retrogames! :D
bluefoxicy
Posts: 6
Joined: Sun Nov 10, 2019 9:36 pm

Re: OFFICIAL 5.0 SUGGESTION THREAD!

Post by bluefoxicy » Tue Nov 12, 2019 1:51 am

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
Posts: 6
Joined: Sun Nov 10, 2019 9:36 pm

Re: OFFICIAL 5.0 SUGGESTION THREAD!

Post by bluefoxicy » Sun Nov 17, 2019 3:57 am

TheNew8bitHeroes wrote:
Tue Mar 26, 2019 1:27 am
@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)?
Post Reply