| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
(except when the debug console is open)
|
| |
|
|
|
|
| |
This allows common functions to be stored in not per-map script files. Which is useful for code that we're going to want in a lot of places -- i.e. how every underwater map is going to have a copy of the same exit area function.
|
| |
|