|
|
afe878c05d
|
begin parameterising level so that it fits into larger type (with different modes like TITLE, LEVEL, SETTINGS, etc.)
|
2025-02-18 13:16:52 +00:00 |
|
|
|
d3200745d0
|
allow player to have a different width/height that is not a perfect square, (now we have Constants.playerWidth and Constants.playerHeight, having deleted the previous size in Constants.playerSize)
|
2025-02-18 12:31:22 +00:00 |
|
|
|
18495a0cca
|
successfully parse controls from file (but todo: save controls imperative shell on load)
|
2025-02-17 03:48:31 +00:00 |
|
|
|
99669dd0b6
|
add function to convert string to CoreKey.key_code (for parsing/loading controls from files)
|
2025-02-17 01:39:41 +00:00 |
|
|
|
f2f1eeab8e
|
additional scaffolding of user's key mappings in imperative shell
|
2025-02-16 13:17:14 +00:00 |
|
|
|
47bda26da5
|
begin coding functionality for remapping keys
|
2025-02-16 12:45:29 +00:00 |
|
|
|
e758a5a13c
|
refactor falling_enemy to be contained in FallingEnemyMap, instead of a plain vector
|
2025-02-15 01:42:29 +00:00 |
|
|
|
b239dfa04d
|
add functionality to have enemies tract to player's attack
|
2025-02-14 12:59:22 +00:00 |
|
|
|
e00db5d8a3
|
make enemies move per loop (calling update EnemyMap by calling EnemyBehaviour)
|
2025-02-14 10:43:27 +00:00 |
|
|
|
46a1836ae2
|
additional refactoring, moving player type into its own directory
|
2025-02-14 10:13:03 +00:00 |
|
|
|
93aebe5fa1
|
a bit of refactoring with regards to enemy's structures and files
|
2025-02-14 09:06:32 +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 |
|
|
|
51401231e1
|
update state of falling enemies per loop
|
2025-02-08 09:49:32 +00:00 |
|
|
|
1c105193e2
|
extract a couple of collision functions to a separate module for reuse
|
2025-02-08 08:39:04 +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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
fac7a81767
|
trace path we can (move right + jump) using quad tree, as it is easier to implement than a pure math based approach
|
2025-01-29 19:12:24 +00:00 |
|
|
|
7138a05cd3
|
move quad tree helper functions which are useful in quad-tree.sml and will be useful in quad-tree-fold.sml, to quad-tree-type.sml, so quad-tree.sml only exports public API suitable for users
|
2025-01-29 07:07:54 +00:00 |
|
|
|
6369be21fa
|
tentatively refactor quad tree to make it more succinct + eliminate a class of potential bugs (passing wrong quad values through recursion)
|
2025-01-27 23:27:52 +00:00 |
|
|
|
174a99a5a0
|
switch implementation of heap from being based on heap.sml (heap as described by one of Chris Okasaki's papers) to being based on bin-vec.sml (simple vector storing elements in sorted order); more performant this way for cache reasons
|
2025-01-22 18:22:34 +00:00 |
|
|
|
3939b0b3e2
|
done implementing functor to search through quad tree, adding to priority queue (for Dijkstra's algorithm)
|
2025-01-19 23:56:52 +00:00 |
|
|
|
1ba42462ba
|
progress implementing dijkstra's algorithm for path finding using quad trees
|
2025-01-19 22:45:51 +00:00 |
|
|
|
4459a676ac
|
implement bin-vec (vector that always stores its elements in order, for binary search)
|
2025-01-19 12:06:56 +00:00 |
|
|
|
8c651b2221
|
implement heap which stores distance for later use with Dijkstra's algorithm
|
2025-01-19 11:07:45 +00:00 |
|
|
|
84ea0ce24b
|
code functor to fold through a specified region of the quad tree, without having to allocate an intermediary list or using a closure (which both have runtime costs)
|
2025-01-18 22:54:34 +00:00 |
|
|
|
0c01b224d0
|
slight refactoring to help with extensibility of adding enemy variants later
|
2025-01-14 11:50:27 +00:00 |
|
|
|
7290d9865d
|
have enemy physics working and applied to enemy
|
2025-01-12 23:58:21 +00:00 |
|
|
|
27fbe1c12e
|
create enemy patch structure
|
2025-01-12 23:28:03 +00:00 |
|
|
|
8906d244eb
|
extract player patch types and functions to its own module
|
2025-01-12 19:25:05 +00:00 |
|
|
|
9280a12911
|
functorise physics for player
|
2025-01-12 12:36:26 +00:00 |
|
|
|
a7c2e2ef01
|
progress moving constant values into own module
|
2025-01-12 07:18:44 +00:00 |
|
|
|
75e28b892e
|
done getting player's projectiles to collide with enemies successfully, and tested (although the code of the enemy reacting to the player is not the best)
|
2025-01-11 21:35:55 +00:00 |
|
|
|
0367b3a23c
|
progress detecting collision between enemy and player's projectile, and decrementing enemy's health once detected
|
2025-01-11 13:45:29 +00:00 |
|
|
|
df0926195d
|
decide on a different structure/module for each collision
|
2025-01-10 10:12:59 +00:00 |
|
|
|
5f437ae76d
|
draw basic field over player when player is attacking
|
2024-12-28 04:06:27 +00:00 |
|
|
|
e98c5b65e9
|
add bin search function
|
2024-12-26 15:10:33 +00:00 |
|
|
|
05cc1d3a46
|
begin coding enemy
|
2024-12-19 03:08:26 +00:00 |
|
|
|
ddd58fd534
|
add platform vector and platform quadtree to game type
|
2024-12-17 21:42:06 +00:00 |
|
|
|
cc7f30f718
|
add GameType.game_type which stores player and wall types, add GameUpdate.update function which takes a game type and returns a new game type, and refactor player/wall files, and gl-draw file, in light of these changes
|
2024-12-15 09:10:19 +00:00 |
|
|
|
1901043535
|
add functionality to move player by using arrow keys
|
2024-12-14 07:59:43 +00:00 |
|
