|
|
93aae6dc1f
|
remove dead code
|
2025-02-14 08:46:28 +00:00 |
|
|
|
c5cea8dcb3
|
partial refactoring so we use EnemyMap.t for collection of enemies
|
2025-02-13 13:36:30 +00:00 |
|
|
|
265c8db88a
|
implement EnemyMap functor (todo: migrate from 'enemy vector' type to 'EnemyMap.t' type)
|
2025-02-13 12:14:50 +00:00 |
|
|
|
f1521acec1
|
refactor file order in preparation for adding GapMap for enemy
|
2025-02-13 11:24:44 +00:00 |
|
|
|
4c8b404c09
|
add code so that bat also moves vertically (in addition to previous horizontal movement) when updating enemy state
|
2025-02-12 00:25:55 +00:00 |
|
|
|
1dc3116b77
|
add fields to enemy which are relevant to bat's state
|
2025-02-11 23:54:13 +00:00 |
|
|
|
3db27a4107
|
cut time which bat rests for in half
|
2025-02-11 19:40:08 +00:00 |
|
|
|
d0d93780fb
|
initial implementation of bat's update function (todo: make bat oscillate up and down while it also moves in x axis, and also code bat's collisions with player, adding to falling list if necessary, or being filtered by player's attack)
|
2025-02-11 19:38:02 +00:00 |
|
|
|
3202c67f47
|
begin adding variant for STRAIGHT_BAT enemy
|
2025-02-11 18:05:44 +00:00 |
|
|
|
534852c8bf
|
don't make 'falling' enemies come back down (fall), but lift them up instead, filtered when reaching beyond the top of the world. It's a little more fluid with current physics for enemies to be 'spirited away' rather than fall.
|
2025-02-09 13:14:38 +00:00 |
|
|
|
4301e9ae38
|
add line-of-sight, so FOLLOW_SLIME will only follow player if player is in specific range of enemy (within 199 pixels currently).
|
2025-02-09 10:05:12 +00:00 |
|
|
|
07d31119a7
|
code functionality to filter out falling enemy from list if falling enemy is colliding with player
|
2025-02-08 11:05:58 +00:00 |
|
|
|
26870816db
|
add code so that enemy gains a new projectile when attacking falling enemies, and also draw the falling enemies
|
2025-02-08 10:48:34 +00:00 |
|
|
|
51401231e1
|
update state of falling enemies per loop
|
2025-02-08 09:49:32 +00:00 |
|
|
|
38640b14a2
|
add falling_enemies type to game (these enemies can be picked up and thrown), and thread fallingEnemies through enemy.sml to set up scaffolding for them
|
2025-02-08 09:20:10 +00:00 |
|
|
|
1c105193e2
|
extract a couple of collision functions to a separate module for reuse
|
2025-02-08 08:39:04 +00:00 |
|
|
|
f9fe009d59
|
have patrol slime and follow slime also react to player's ChainEdge attack, and not only player's projectiles
|
2025-02-08 04:02:17 +00:00 |
|
|
|
23cf480dad
|
reimplement enemy-filter loop (now enemy's reaction, and decision to possibly filter, is fully under enemy's control - physics, damage reaction, whether to filter or update enemy's state, etc.)
|
2025-02-08 01:05:39 +00:00 |
|
|
|
1be44335cb
|
add asset for ChainEdge (attack)
|
2025-02-07 13:42:38 +00:00 |
|
|
|
7734496a8c
|
remove some references to charging when/ife we don't need it, and also only trigger throw/attack on new button press (if held, throw/attack is not repeated)
|
2025-02-07 12:32:38 +00:00 |
|
|
|
283962c176
|
make length of main attack increase and decrease
|
2025-02-07 11:22:23 +00:00 |
|
|
|
f6cd818c42
|
display fieldVec which is more accurate to the attack's hitbox for now
|
2025-02-07 10:40:47 +00:00 |
|
|
|
35eab0f789
|
reimplement attack patches (todo: add an int to the MAIN_ATTACKING variant to make the attack grow past some limit, and a bool to indicate whether the attack should grow in length or shrink)
|
2025-02-07 09:10:10 +00:00 |
|
|
|
f5071a953b
|
make sure playedr only checks collisions with enemy in the case that player was previously attacked
|
2025-02-06 17:42:45 +00:00 |
|
|
|
e1e20230d6
|
rip out player-enemy.sml and let player react to enemy collisions independently of enemy reaction to player
|
2025-02-06 17:37:48 +00:00 |
|
|
|
886e3a674d
|
progress checking collisions of enemy inside functor instead
|
2025-02-06 09:53:31 +00:00 |
|
|
|
7142f5dc66
|
a little more deliberate about timing of when player's patches should be applied
|
2025-02-05 19:33:56 +00:00 |
|
|
|
e1e1228983
|
delete pointer quad tree because it is twice as slow to construct as the vector-based implementation
|
2025-02-01 10:11:32 +00:00 |
|
|
|
bf3f0b3927
|
done implementing pointer quad tree (next: benchmark the two)
|
2025-02-01 09:54:35 +00:00 |
|
|
|
28380957b3
|
start implementing new quad tree that only uses pointers (just to test performance between vector-using implementation and only-pointer-using implementation)
|
2025-02-01 09:44:22 +00:00 |
|
|
|
0a9ab389c2
|
fix bug in tracing left jump path: we should consider rightmost x coordinate from enemy (which we now do)
|
2025-02-01 01:33:26 +00:00 |
|
|
|
9e9675aaab
|
decrease memory consumption of quad tree by refraining from storing bounding box metadata (except for the global root which stores the width and height)
|
2025-02-01 01:03:57 +00:00 |
|
|
|
73aeeb5301
|
remove timing print statements from game-type.sml
|
2025-01-31 06:26:09 +00:00 |
|
|
|
547b5bac97
|
use an immutable vector (always of length 4) for representing quad tree's internal nodes
|
2025-01-31 06:24:51 +00:00 |
|
|
|
76c5f9d662
|
change maxSize of quad tree's leaf nodes (from a max length of 3 to a max length of 9)
|
2025-01-31 06:01:02 +00:00 |
|
|
|
e23e2f0997
|
precompute graph to be used for dijkstra's algorithm, resulting in CPU usage that never exceed 7/home/humza/Downloads/sml/oh-my-stars/fcore/path-finding.sml with 5 enemies and eliminating lag
|
2025-01-31 04:32:53 +00:00 |
|
|
|
f3a0b2bc81
|
write code for new loop implementation of dijkstra's algorithm, which uses a precomputed graphy; however, this is not used yet as we need to add the graph to the game type first, and pass it along with other parameters, down to the path-finding.sml function
|
2025-01-31 04:10:58 +00:00 |
|
|
|
a24ada0f37
|
implement code for precomputing reachable platforms so it can be reused (but haven't modified implementation of Dijkstra's algorithm to use it, and haven't added it to game type yet)
|
2025-01-31 03:46:28 +00:00 |
|
|
|
0cdd81189c
|
implement function to trace left jump, thereby completing 'build-graph.sml' (and fix a bug in trace-jump.sml where a left-tracing function mistakenly made a tail call to a right-tracing function)
|
2025-01-31 00:35:36 +00:00 |
|
|
|
70f04c2e92
|
implement function in build-graph.sml to trace path of right jump to detect reachable platforms (different from deciding how enemy should move to next platform in trace-jump.sml)
|
2025-01-31 00:18:17 +00:00 |
|
|
|
2103a8e8ac
|
implement quad tree folder for building graph horizontally (but still need to trace the left/right paths)
|
2025-01-30 13:25:39 +00:00 |
|
|
|
bbb957f016
|
get path-finding.sml to use function in build-graph.sml to find reachable platforms, and remove now-dead code from path-finding.sml
|
2025-01-30 13:06:32 +00:00 |
|
|
|
755e5da7f7
|
fix bug in bin-vec.sml 'deleteMin' function: we previously deleted two elements, but we are supposed to delete one, and now this is fixed
|
2025-01-30 12:55:36 +00:00 |
|
|
|
29389d3561
|
try coding a level
|
2025-01-30 08:34:38 +00:00 |
|
|
|
859414035d
|
when tracing left jump, consider the enemy's 'x' coordinate to be the leftmost point of the enemy
|
2025-01-30 08:21:15 +00:00 |
|
|
|
73b4e607ae
|
delete function to getPlatformBelowPlayer because it is no longer need now that player stores platID (but still keep function to get platform below enemy as that is still useful)
|
2025-01-30 00:11:01 +00:00 |
|
|
|
2446f3ea14
|
in trace-jump.sml, begin descent depending on enemy's size
|
2025-01-29 23:51:02 +00:00 |
|
|
|
d55126b52a
|
implement left jump/left drop tracing in trace-jump.sml, and verified that it works
|
2025-01-29 23:04:28 +00:00 |
|
|
|
89abab31ab
|
implement function to trace drop (while moving right)
|
2025-01-29 19:35:40 +00:00 |
|
|
|
97a638b54d
|
from TraceJump.traceRightJumpAscent function, check (after we have reached ascent and if we have still not found nextPlatID in path) if we can find nextPlatID if we trace the descent path after having reached the ascent
|
2025-01-29 19:24:03 +00:00 |
|
