| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
In the past, not using the "cardinal directions only" flag resulted in awkward and unintuitive paths. Two changes were made to the algorithm to improve these paths.
One, nodes in the graph are now a pair of a position and the direction taken to get there. This way, a small penalty can be applied whenever a turn is taken, which should incentivise paths with fewer turns (which should be simpler). This change theoretically affects the cardinal mode as well, but in practice it is unlikely to change the paths that would've been generated. This also multiplies the search space by eight (four in cardinal mode), but so far it does not appear to be a significant resource drain.
Two, the heuristic used in eight-directions mode is now octile distance, instead of dominant axis distance. Additionally, the real cost of moving diagonally is ~sqrt(2) instead of 1. This somewhat disincentivises diagonal movement, since it is no longer considered the same as cardinal movement (even though cardinal and diagonal movement occurs at the same speed), but the turning penalty makes moving diagonally more favourable than zigzagging cardinally to reach a diagonal destination.
Most scripted movement in the game is likely to use cardinal mode because that mirrors the way most scripted movement in Mother 3 works, but in some cases (the Hinawa event on the cliff) diagonal movement just looks better, and thus it's useful to have the improved pathfinding algorithm.
|
|
|
|
| |
This flag will make the sprite appear to be walking backwards.
|
|
|
|
| |
#28
|
| |
|
|
|
|
| |
Sprites with this flag enabled will ignore map collision.
|
|
|
|
| |
Background scripts are scripts that are launched when a map is loaded. They differ in use from a map's init script in that they are expected to contain an infinite loop. These scripts are linked to a sprite and will be killed when that sprite is destroyed (usually when the map is unloaded, but if the sprite is made persistent then it may last longer). The thread running the script is given no warning that it is being killed; the coroutine is simply never called again, and the thread is disposed of. Because of this, background scripts MUST ensure the game is in a consistent state before coroutine yielding, because it is not guaranteed that the coroutine will ever be called again.
|
| |
|
| |
|
| |
|
|
|
|
| |
#7
|
|
|
|
|
|
| |
Mostly because pressing M while the settings menu is open would not cause the music slider to go down automatically.
#7
|
|
|
|
| |
#7
|
|
|
|
| |
#7
|
|
|
|
| |
#7
|
|
|
|
| |
#7
|
|
|
|
| |
#7
|
|
|
|
| |
#7
|
|
|
|
| |
#7
|
|
|
|
| |
#7
|
|
|
|
| |
Even if it was left on a different option before closing the menu.
|
|
|
|
| |
#7
|
|
|
|
| |
#7
|
|
|
|
| |
Also, the game is not rendered at all if the pause menu is totally open, which makes sense because why are we going to the effort to render it and then just colour over it.
|
|
|
|
| |
#7
|
|
|
|
| |
#7
|
|
|
|
| |
This simplifies EffectSystem quite a bit, and will be useful in other classes.
|
|
|
|
|
|
| |
It currently has nothing in it.
#7
|
|
|
|
|
|
| |
The hot spring is also a little bigger now, because I'm using an enclosure to keep Lucas in, instead of setting the tiles to being solid or not.
#20
|
|
|
|
| |
#18
|
|
|
|
| |
This includes the player characters. It was impossible to access the Time Passage mailbox with the wider hitbox because the player would continuously slide between the solid tiles to either side of it.
|
|
|
|
| |
#3
|
|
|
|
| |
It is no longer split into horizontal and vertical results. Also, the collision detection routine now does the work of calculating an adjusted position, instead of the caller (CharacterSystem) having to do it. This will be useful for #3.
|
|
|
|
|
|
| |
Also made sprite hitboxes bigger.
#15
|
|
|
|
|
|
| |
Kumatora, Duster, and Boney had to be given hitboxes, but they are not considered solid.
#10
|
|
|
|
| |
#10
|
|
|
|
|
|
| |
He will wander randomly until you get close, and will then run at you. Talking to him or bumping into him does nothing currently. If you move out of his range of interest he will go back to wandering at a walking pace.
#10
|
|
|
|
|
|
| |
The whole function should probably be refactored at some point, possibly like therapy5's but that may be too complicated.
#14
|
| |
|
| |
|
| |
|
|
|
|
| |
This is really just for letting one sprite mirror another's movement and animation. I tried doing it in the BehaviourSystem, but you get stuttering if you do it earlier in the loop than the CharacterSystem, so I ended up having to make a new system just for this thing that will not happen very often.
|
|
|
|
| |
This layer is below the normal sprite layer. Sprites on it are only rendered within the area of a zone that is defined per-map.
|
| |
|
|
|
|
| |
Since it's always the same ones anyway, might as well set defaults and allow them to be overridden.
|
|
|
|
| |
This may happen due to lag or due to debugging with lldb. What happens is that 60 times a second, the engine will check whether the direction toward the current endpoint is equal to the direction in the pathfinding instruction, and if it isn't (because the sprite has gone past the endpoint) then it sets the sprite's position to the endpoint instantly so that the pathfinding can continue.
|
|
|
|
| |
It's because the game's coordinate system has Y increasing downward, whereas the coordinate system used by the trig functions has Y increasing upward.
|
|
|
|
|
|
| |
Looking pretty good so far.
TODO: direction facing functions have inverted Y coordinate. confusion expression doesn't exist yet. rest of scene.
|
| |
|
|
|
|
| |
The filenames for these are fairly regular, and we're gonna want to abstract it away further later on anyway.
|
| |
|