- Notification Engine
- Notifications on map sprite collisions
- Smoother map context transitions
- Track how many times each map event has been started on the map
- Add additional map events for common map script operations: PushMapStateEvent, PopMapStateEvent, CameraMoveEvent, ChangePropertySpriteEvent
- Improve our map sprite and enemy sprite creation shorthands in Lua
- Have the editor state the coordinate boundaries of a selection area in the status bar when a selection is active
- Add property that allow map sprites to display their walking animations even when standing still
- Add property that flips the direction the sprite image is facing relative to the sprite's direction of movement (aka, "moonwalking")
- Add simple state tracker in map mode (string/integer pairs) that can be set and read (now called "local record group")
- Allow records to be written by starting map events, and by dialogue lines and options executing
- Remove ChangeDirectionSpriteEvent class and replace all uses of it with ChangePropertySpriteEvent
- Move sound and music object storage to map scripts and stop relying on audio logic hard-coded into MapMode class
- Remove or redesign ContextZones
- Create notifications on every sprite position change; use this for ResidentZone class to automatically check when sprites are inside (instead of having to do it manually in the map script)
- Dialogue property that instructs the sprite owning the dialogue to -not- face the player sprite when the dialogue is active
- Add a second dialogue icon that displays only when a sprite has new, unread dialogue
- Add SoundObjects to map code, which are invisible sound sources that can be placed on the map
- Blending one context into another during transitions
- (Possibly) Refactor the way we store coordinates for objects (currently two int and float offset) with two floats
- Rename map_sprites_stock.lua and possibly make it more generic and include other convenient Lua shorthands for making multiple C++ function calls
------- Original Post Below -------
As we've been building larger and more complex map, I've been finding several technical obstacles with scripting them. The purpose of this thread is to list these obstacles and point out other limitations of the map mode code, and then to discuss solutions to them.
Issue: map context drawing and switching
When you switch from one context to the next, the change is instant. It's a little jarring just walking through a door and suddenly being in a different "map" in a single frame. So we want to make the transition a little more natural. But there are problems with the way manage contexts right now. To figure out what context we should draw, we look at what context of the object that is being pointed to by the map camera. We get around this somewhat in the cave map by scripting a fade screen event to black, change the context, and then fade back.
There's already a task for improving this that I'm working on. Here's the changes I've got coming:
- The current map context (the one drawn on the screen) is no longer always the context of the map camera. We now manage a member that tracks the active context, and to change it we call one of several functions for transitioning contexts.
- There are three types of context transitions I'm creating. Instant (what we have now), Blend, and Color. Blend works by drawing two contexts on the screen at once, applying some transparency to the result, and blending the two images together. That way we can get a fade from one context into the next. Color does the transition by fading the screen to a certain color, then switching the active context, and then fading the color back out. You can also set the time it should take to complete the transition, or use the default time. I think Blend should be our default transition type.
- ContextZones, which are currently used to change the context of objects walking through them, will mostly be unchanged. But we'll have to add some conditional logic so that the zone can detect if the player sprite is transitioning, and start a context transition if so. And we'll need to allow for some additional parameters so that the user can instruct the class what type of transition to do.
- I considered making context transitions a type of map event, but decided it was simpler to just have the transition managed directly in the MapMode class rather than have to create and initialize a new event for every transition.
Issue: event triggers aren't comprehensive enough
The event system itself works wonderfully, but what I think needs improvement is the way we trigger events. The only way we have to do this right now is either in the map script's load function (starting an event right after the map finishes loading), or through a series of if statements in the script's update function. Usually those event checks are simply "is the player sprite inside any map zones that we defined?". In other words, events are only triggered by physically moving to a location on the map.
I'd like to be able to trigger events by other means, and perhaps have some better mechanisms for the existing way to trigger events. For example, if the user presses the confirm button while facing an interactable object, I want an event to be able to fire. Or if the player sprite collides with something, such as a locked door, I want to trigger an event (maybe play a "locked door" type sound). And maybe other conditions too, such as a check after battle to see if fatigue is high, and maybe have a character in the party warn the player that they are heavily fatigued.
I haven't gotten much further than defining what it is I'd like to be able to do at this point. I'm still thinking about how to actually go about making this happen, and what needs to change to support this kind of triggering system. I'll probably have to go do some research to figure it all out.