ASCENT v0.10 UPDATE - EM FIELDS AND SEXIMAL

welcome, organics, synthetics, and everyone in between, to another ascent update post ^^

this week's update features:

• electromagnetic fields which will scramble the protagonist's circuits if e gets too close
• four new levels
• levels are now numbered in seximal because its my game and i said so
• new animation system (ugh)
• gravity code is now (somewhat) centralized
• minor bugfixes

electromagnetic fields

these are a new feature similar to bridges. whereas bridges prevent anything from passing through them (they are functionally identical to a row of titanium blocks), em fields only prevent the player from falling/climbing through them; dropping boulders and grappling are both permitted. they don't seem to have quite as many interactions as bridges... bridges can be used to open OR close a route (or even both at once) while em fields can only close routes. but they create a lot of situations which were difficult or impossible to achieve using existing elements. i had a lot of fun making puzzles with them.

why'd the version number jump from 0.5 to 0.10?

levels are now numbered in base six or seximal. in base six, there are six digits: 0, 1 ,2, 3, 4, and 5. place value uses powers of six (rather than the powers of ten you're used to seeing in decimal), so the number six is written 10, seven is 11, and so on.

so when you load ascent v0.10 and see "level 00 of 43" that's not forty-three, it's foursy-three; four sixes and three ones. which is 27 in base ten. there are twenty-seven levels [after the tutorial level]. i swear im not doing this to inflate my level count this is just how i like to count things >.>

after i do some reorganising, levels will likely be grouped into stages of six which share a common theme/mechanic/set of elements. my fantasy for the first major release of ascent is 100 levels, which isn't that far off. we'll see how it goes!

animation is hard

this week's feature posed a significant technological challenge to me: it has a passive animation. if you've never used puzzlescript this might sound insane to you, so let me give you a rundown of how the engine works.

a puzzlescript level consists of a grid of cells, each of which contains objects. an object is a 5x5 sprite with a name. a rule in puzzlescript looks something like this:

[ > player | boulder ] -> [ > player | > boulder ]

each turn, the engine scans the grid for the pattern of cells contained in the first set of brackets, and replaces it with whatever it finds in the second set. in this case, any player which is moving towards a stationary boulder will be replaced with a player and boulder which are both moving. this is the actual rule used for pushing boulders in ascent.

...thats it. thats the entire engine. so if i want to, for example, animate an electrical arc, i can't just pop a spritesheet into some folder and call it a day- each frame of the animation needs to be a separate object and i have to write multiple rules to replace those objects with each other. puzzlescript is excellent for quickly implementing simple puzzle mechanics, but trying to use it for anything outside its very short list of intended uses quickly spirals into insanity.

so what did i do? well, first of all there's a setting for puzzlescript games called realtime_interval, which tells the engine to periodically simulate a turn without player input. this is a must if i want anything to happen while the player is standing still.

so i turn that on and tell the arc to display a random em_field object every turn. works great. but there's a problem- whenever the player moves, it causes a turn... which causes the animation to run faster. so i need to distinguish between player-caused turns and realtime turns. no problem, this rule takes care of it:

[stationary player] -> [stationary player realtime]
[realtime] -> [] //delete realtime at the end of the turn

i can now check for the existence of realtime (an invisible object used as a token) in the animation rules, like so:

[em_field] [realtime] -> [random em_field] [realtime]

but there's another problem. for the existing grapple gun animations, during which the player cannot move, im using "again," a rule marker which tells the engine to simulate another turn with no user input after a short delay. and the again delay i have set is much shorter than the speed i want the animation to run. and also realtime turns aren't called while an again chain is in progress.

so i made a series of five tokens called animate_1-5 which decay into each other only on realtime turns in a loop, and set up the em_field animation to only trigger on animate-5. then i changed the realtime_interval to match the again_interval so that the realtime animation will merge seamlessly with the again one. (the realtime detector detects again turns too since there's no player input on those turns and i don't use the motion system to move the player).

all of this nonsense took about three hours- but now i have a universal system to power any animations which run in real time without taking control away from the player! in addition to em fields i connected the snapping_cable and titanium clink animations to this system; they're both only four frames so there's not a noticeable play speed increase, but it's something. i have ideas for future visual effects which will use this system as well.

december

i will likely take a break from ascent in the coming weeks. i don't have any ideas for future features right now (lie) and would like to spend a longer chunk of time tweaking/sorting/culling/organizing existing levels. the game's difficulty curve has taken a hit from my lack of inspiration and it needs attention before i can proceed with anything ambitious.

if i come up with any new levels this week i'll post an update as usual, but im not making any promises. that said there will definitely be a full-size update either the first or second week of january, depending on where my other projects take me.

one reason for this decision is that i'd like to put some work into Dungeon Keysmith's Apprentice. i promised to look at it a few weeks ago but i haven't managed to put enough hours in to finish any kind of update. next monday that update will be released, so keep an eye out!

(please don't go play it before the update the "puzzles" are totally unpleasant its embarrassing)

other projects

check my discord to see what other things im working on!* these include but aren't limited to:

• Dungeon Keysmith's Apprentice (mentioned above)
• doing follow-along tutorials and various experiments in Godot
• learning to crochet
• skill tree-based ttrpg called Tree Game
• working on my constructed language
• studying rope dart
• seeking actual employment

* "am working on" is code for "have started"

if you're interested in collaborating on ascent, hit me up in my discord server. i'm not committed to taking on a partner on the project but i'm currently open to the idea. a pixel artist or general puzzle designer would be a huge boon- you don't need to know puzzlescript. if you don't want to join but have ideas those are welcome too!