Edit: Made some extra additions/edits to the list.
Okay, this is pretty sweet. I'd like to add my own suggestions, though I might've missed things that might've already been suggested:
Behaviour/AI
Someone already suggested platformer pathfinding (Notch actually made an A* Mario pathfinding thing once), but to add onto that, I'd also like to see 'off-mesh links' (or in this case, 'off-grid links') that inform pathfinders of unusual methods of moving around an environment, such as teleporters, elevators, etc, and tell the behaviour what to do when they encounter such links.
Oh, and be able to provide platformer AI pathfinding information for custom behaviour, in case of custom platforming behaviours and whatnot - defining 'actions' that can allow an AI to do things such as crossing horizontal or vertical gaps (dashing, jetpacks, etc.) that they might not otherwise be able to cross or get past certain obstacles.
Controls
In my experience, coding up local multiplayer is awkward and requires giving every object control information via variables and additional variables for every button for stuff like knowing when the player has only just pressed a button, etc, and setting up controls for individual players either requires arrays for control sets or manual control definition. And then you have to individually define via variable which player controls which set of objects, which can get messy with 'for each' object picking and making sure they don't conflict.
I'd like to be able to add a 'player' behaviour/component to an object, that defines that object as being controlled by a particular player (or AI), and only responds to particular controller or specific set of controls. In addition, controls for both keyboard/mouse and controllers for each player can be defined via the editor independently of the behaviour/components, and also modified at runtime (and also whether certain players are using either keyboard/mouse or controller, or both). This would make implementing local multiplayer so much easier. Input systems generally aren't great for game engines in general out of the box, Unity's is kinda awful as well for many of the same reasons.
Really, being able to easily define certain objects and the objects they contain as being associated with certain players would solve a ton of problems by itself.
Object Picking and Prefabs
Also from my experience, if you want certain sets of objects of the exactly same type interacting with each other, such as multiple players who use the same object, aside from the aforementioned controls problem, you also need to do a mess of picking to ensure that certain events don't affect objects that shouldn't be affecting them at any one time, especially if each player has different 'skins' that do different things.
Lemme provide an example of this: with my last game, I had to consolidate my player/AI characters into two objects, the single main object that handles controls and behaviour, which has to be just one object, because otherwise, even with families, you end up getting into an absolute mess of picking nonsense, and thus I can't use that object as a container for the 'skins' that represent the player, so I have to spawn and assign each skin with its main player object individually, couple each pair with their event behaviours in picking, and then also handle what happens when, say, a player attacks another player. Unfortunately, this still results in an entire mess of picking nonsense, with for each object loops, and then a bunch of picking events during certain inter-player events to tell which skin belongs to which player and vice-versa. And then you get into issues with spawning and what happens with save states, and you can get that it gets especially messy trying to clear out bugs. No, families aren't actually that much help.
Basically, here's some ideas on how this can be fixed:
- Don't have containers set entirely in stone. Unity can have child objects (and children within children) and even add or remove children without problems, as long as they're not using said children for something that might cause errors due to their absence. Instead, allow a parent to spawn objects as children (or despawn children), and then check if they have a certain object as a child. This saves a lot of time and grief with sorting out picking when instead more flexible containers can do it automatically.
- As well, allow for 'child slots' or dummy objects that children can be slotted into, so a child slot/dummy that can represent many different objects that might be in that slot, while performing the same event behaviour. This preserves the existing container behaviour while adding additional flexibility. That way, the designer can create containers with dummy objects that can be substituted by more than one object, and still work fine even if the slot is empty, and if they want to replace an object in a slot with another, they can easily do so with a single action.
- A 'hierarchy' window that can be used for both assembling containers and sorting z-order, similar to Unity. That would actually be fairly convenient.
- In events, if two of the same objects do something with each other, be able to distinguish between "Object A" and "Object B", and the groups of objects that they contain. For example, if Object A collides with Object B at a high enough velocity, do damage to Object B, and so on.