Welcome to another issue of (the) New Gnorp Times, voted superior to The New York Times in a recently conducted survey (Sample size: 1; Margin of error: ±0%). The topic of today is The Ring, a new mechanic designed for the Epilogue Expansion.

The Epilogue is an upcoming free expansion to (the) Gnorp Apologue in the form a new mode, which will include new talents, mechanics and a different ending.
If you look above while playing the Epilogue, you will find a number of particles that compose a ring around the planet of the gnorps.

The ring is not precious. It is the worst. Not only does the ring reduce the amount of damage and collection the gnorps do through its oppressive presence—it is also hoarding talent points.

Besides further beating up the rock, in Epilogue you also want to reduce the ring integrity in order to get those talent points, increase collection and damage, and ultimately win.

The ring is the rock's fault. In the base game, during compression events and prestiging, the rock reclaims shards that were ouput. In Epilogue, things are slightly different.

When a compression event occurs in Epilogue, shards fly up and coalesce into more ring particles. This further reduces damage and collection, and makes it harder to collect talent points from the ring. This downside of compression is intended to allow for a little more strategy about when to compress, but is not meant to be very punishing.

How do you destroy the ring? I'm not telling.

Before we get into the next section, which will be about optimizing the performance of the ring, I want to quickly mention a couple of things:

• 
  I am not 100% happy with the beta patch. More work has to be done, but Epilogue feels right to prioritize right now.
  
• 
  I've shifted the road map a bit. Gnorps in Space will be the next focus after Epilogue, but I will talk more about that in the future.
  
• 
  More hats are coming!
  
• 
  I got pneumonia from a bacteria called Mycoplasma Pneumoniae, which I thought funny because Mycoplasma is the origin of my handle, Myco. Being knocked out for several weeks was less funny.
  
• 
  I did an interview about speedrunning (the) Gnorp Apologue with the guys at Board Boosters. You can watch it below.

There's a couple of very exciting things we can do to optimize the performance of the ring. If you're interested in that, keep reading. If not, escape.

First of all, the ring particles, or roids as I call them (they are not asteroids or meteors as one might assume (in Gnorps in Space there will be asteroids (no meteors because meteors are defined as objects from outer space that enter the atmosphere of a planet and Gnorps in Space takes place in space (shooting stars are meteors (an asteroid that briefly became a shooting star killed the dinosaurs (except for the ones that evolved to become birds (birds are avian dinosaurs (pterodactyls were not dinosaurs)))))))), fly above the planet of the gnorps at the same velocity. This simple fact allows us to make some cool optimizations. More on this later.

Let's establish a few points to walk through things:

• The ring has a fake orbit, the roids move at a fixed velocity on the X-axis
  
• When going beyond the maximum X-position, the roid wraps around to the minimum X-position by subtracting the width of the ring
  
• For this, we define the Width=50, Minimum X-position=0, Maximum X-position=50
  
• We define the speed as 1, meaning every update the roids move 1 position to the right
  
• The roids do not collide with themselves

So, assuming a list of four roids with the following X-positions:
[25, 10, 50, 17]
We update the ring, and end up with this:
[25+1, 10+1, 50+1, 17+1] -> [26, 11, 51, 18] -> [26, 11, 0, 18]
The third roid in the list has wrapped around because it had an X-position greater than the maximum X-position.

This is essentially the first optimization we make, as we do not delete roids outside the maximum X-position and insert new ones--we recycle them. You can follow individual roids by color in the gif below.
And here is the pseudo-code for the behavior of the roids.
Next, we have to look at collision. The roids will be able to collide with certain game objects, so we need to allow for that. Now, normally we might define the roids as circles with a radius—but objects that orbit around a planet tend to move at terrifying speeds, and therefore we do not need the precision of collision between circles. That is a benefit as collision detection of circles can be fairly computationally expensive. So roids are circles, but for collision they are considered squares—and so are the objects that they collide with.

Below we can see the function we use to check for collision. Within it, we can see another function, intersects(house, roid), which is a simple function that compares two rectangles against each other. An intersection means collision. As mentioned before, roids are converted into rectangles within the function in order to reduce the computational cost of collision detection.
To illustrate the work being done, the gif above pauses on every update and highlights the roids we are checking against. The object we collide against is a house with two gnorps inside. The collision detection function simply goes through the list of roids to find if there is any intersection.

Checking for intersections can take fair bit of time, as there might be many objects to check against. For example, if we have 100 roids and 10 objects to check against we will have to do 1000 (100 x 10) intersection checks every update.

The roids fly above the planet, which means we have knowledge about where they won't be. When the roids are generated, they are given a Y-position that is always under 100 as they are in the sky. (Lower values here mean the roids are higher up in the sky.) We also know that roids have a maximum radius of 10. Armed with those two pieces of information, we can do this:
Now there are far fewer comparisons being made, and that's a job well done. Thanks for reading.

Just kidding; life isn't that easy.

At this point in our journey, it's important to establish a benchmark. We need to know the speed at which the computational work is being done in order to take the potential out of "potential improvements". The more you run a benchmark, the more accurate it is. Any good benchmark is also reflective of the real-world conditions: When players run the game.

We set up the benchmark with the following conditions:

• Create a list of 1500 randomly positioned roids
  
• Create a list of 10 randomly positioned houses (the objects the roids collide with)
  
• Run the movement and collision functions 10000 times
  
• Repeat the the steps above 99 times

This should give us a fairly accurate benchmark, and we will collect three data points: The time it takes to update the movement of our roids and houses, the time it takes to check for collisions, and the number of collisions. The reason we collect the number of collisions is that we need to make sure that our changes do not alter the results of the collision detection itself—any meaningful change in the number would indicate that something got messed up.

So for every benchmark we run 1 million updates, which is equivalent to running the game for 4.6 hours.

And with that, we arrive at these numbers, our baseline:

Benchmark: 10k updates, 100 runs. Numbers are the average of 100 runs.
We observe that 95% of the time is spent on collision detection. Reducing that number should then be our focus.

Optimization is all about not doing things. For example one method of optimization is asking an LLM to write (the) New Gnorp Times for me, but that would change the output from "hopefully good" to "definitely artificial", so it would be a bad optimization. We need to find a way to skip work while not changing the outcome.

Let's look a picture I made in paint.
In the picture several roids can be found, and their left edges have been marked with either red or green based on the following comparison: Is the right edge of the house greater than the left edge of the roids? If the comparison is true, there might be a collision: We'll have to do further checking to find out. But if the comparison is false, then a collision is impossible, because a rectangle where the right edge is less than the left edge of another rectangle can never intersect.

The key observation we make here is that if we were to check the roids for collisions according to the order of their left edges, we can skip all remaining collision checking once we hit upon the first roid where the right edge of the house is less than the left edge of the roid.

So, every update, after updating the positions of all the roids we also sort them by their left edges. Reiterating upon the above, that allows us to go through the list of roids in the order shown on the picture, and once we find a roid where house.right() < roid.left(), we skip all the remaining roids.
Here's how it looks in our little simulation:
And here is the result of the benchmark:
Benchmark: 10k updates, 100 runs. Numbers are the average of 100 runs.
The time it took to check for collisions was significantly reduced, but the time it took for the roids to move was increased by 9x! The increase is due to the time it takes to sort the list, because we need to do that every update as roids might have wrapped around. Overall the change was an improvement, but still—can we reduce the amount of time it takes to maintain the sorted order?

Sorting lists are expensive. This has to do with moving things around in memory. In our instance, if we have to sort a list like this in ascending order:
[20, 25, 30, 0] -> [0, 20, 25, 30] — The 4th element in the list moves to the 1st position and 3 elements have to shift to the right. The more elements we have to shift, the longer it takes. We have a lot of roids, so it takes quite a bit of time.

Since all the roids have the same speed, we know then that the order of the list never changes except when they wrap around, and when that happens the back of the list simply moves to the front of the list.

This allows us to use a circular buffer to maintain our sort. What that means is fairly simple. It's a list that can rotate its "head", the start of the list. Instead of the actual list changing, it is the starting point of the list that does!

Consider the list of roids here as rotation is applied. The index indicates the order of the list, and we start at 0.
Roids: [20, 25, 30, 0] -> [20, 25, 30, 0]
Index: [0, 1, 2, 3] -> [1, 2, 3 , 0]
The list remains the same, but the starting point changes.

So, when we go through our list, we start at index 0 and that yields the X-positon 0. That means our sort is maintained!

Upon creation of the roids, they are sorted according to their left edges as usual—but only then! After that, the rotation takes care of the rest.
We implement and benchmark, and our results are:
Benchmark: 10k updates, 100 runs. Numbers are the average of 100 runs.
An enormous improvement compared to sorting every update! We took a hit to the collision detection speed, and that has to do with circular buffers being slower to iterate through.

Now, we have another key detail about the belt that we can use to skip even more checking, the coup de grâce of our optimization work: A positional heuristic.

The ring has an even distribution of roids along the X-axis, that is to say that you can expect to find a similar number of asteroids comparing any given bound with the same width. The even distribution is due to the way asteroids are generated: They are given a random position between the minium X-position and the maximum X-position of the ring. When you do that enough times, you get a fairly even spread of roids along the X-axis. That allows us to make an assumption about where to start checking within the belt.

Our goal will be to turn an X-position into an index, a number we use to access the list. In order to do that we take the X-position and divide it by the width of the ring. That gives us a number that represents the ratio of progress, which we then multiply with the number of roids in our list. This gives us a roid that we expect to have a similar X-position as the house we may collide with.

There is no guarantee we were right, however! We need to do some additional work to make sure that we won't miss any collisions, as any misses would invalidate the optimization. In order to that, we go down the list in descending order to find a roid that we cannot possibly collide against. Remember, we sort by the left edges of the roids, so we need to compare with the maximum possible radius of a roid: roid.x + 10 < house.x would mean we have found the point where we will never find roids that we can collide with.

Let's see how it works within the simulation.
Pure heuristic beauty. We can see that very few checks are made, and the benchmark should then show significant improvements.

Benchmark: 10k updates, 100 runs. Numbers are the average of 100 runs.
And indeed it does. We go from 79 milliseconds spent checking for collisions to 10 milliseconds, a rather significant reduction! Optimization! Our positional heuristic is extremely effective at guessing thanks to the properties of the ring.
The answer to that question is always yes. But is it worth it? No. Our optimizations are more than enough for what we need, so our time is better spent elsewhere. We did great!

Our view into the game, whatever you can see in the game window, is just a giant rectangle. It would be wasteful to draw things outside the view into the game, so in order to to figure out what is within the view we also apply collision detection: The rectangle representing the screen is checked against the list of roids, and if an intersection occurs we draw the roid in question. This allows us to apply all the optimization work we did in order to also optimize the speed at which we find which roids to draw.

I made this because I thought it would be fun to show the work that might go into optimizing a game. Normally naïve implementations of systems are fine most of the time, because computers are extremely fast, especially when using a low-level programming language like Rust (which Gnorp is written in).

What matters the most is if the code is an accurate description of the steps required to accomplish your desired outcome, written in such a way that it can easily accommodate any future changes to both desired outcome and desired performance. In other words: Write straightforward code.

While working on a different project a while back, I came across this Sort, sweep, and prune: Collision detection algorithms[leanrada.com] post about collision detection. A few of the things I apply to optimize the ring I learnt from that post. I drew inspiration of visualizing the collision detection from the post as well.

I'm quite excited to continue the work on Epilogue, and I hope you are looking forward to playing it. Thanks for reading (the) New Gnorp Times #21.

There's a new bundle in town and it is called Gnome Apologue because it consists of yours truly's game and Gnomes—a tower defense game where you endeavor to murder hundreds of goblins as, you guessed it, gnomes!

I've been privileged enough to be part of the playtesting for the game, and I think it's a really interesting game with great music and great atmosphere.

The developers, Tommy and Patrick, have done really great work, and if a turn-based tower defense game with well-designed mechanics sounds interesting to you, I hope you will check their game out.

https://testx-steam.c5game.com/steamstore/bundle/51623/Gnome_Apologue/

Another issue of the LLM-free, Gnorpitzer prize winning publication (the) New Gnorp Times has arrived.

Today we'll talk about:
— Another hat batch
— A new beta version
— Talents in the Epilogue Update

More hats have been implemented! You'll find them both in the live version and the beta version. A big thank you to the hat creators, and I hope they will be pleased to finally see them in-game!

Zygnorps become united with machine — the drone gnorp. This was made by Matsan, and is acquired by the achievement "Y2K". I gave the Drone Gnorps some extra love with an animated booster effect as a replacement for the regular Zygnorps' little tadpole tail.

Directors get some glasses. Nerds. This was made by Popgoes, and is acquired by the achievement "MY EYES".

Wildly unsafe, but it's Bring Your Gnorp to Gnorp Day for the gunners. This was made by Caty, MetallicSaladFork, Pumpkinburger, and Sting — they all had the same wonderful idea. Acquired by the achievement "Uh, is this allowed?"

Only the hardest working, fastest archer is deserving of a hat like this. It was made by Goat, and is acquired by the achievement "Getting somewhere".

A beautiful flower wreath for your runners. This hat was made by Pumpkinburger, and is acquired by the achievement "First compression".

Thanks to everyone who has tried the balance and rework beta, and thanks for all the great feedback!

The talent changes have been received well, particularly Supershatter and Sacred Mountain, and I do agree that it's quite nice to not have to click on drones in order to brutally, viciously murder them. A lot of you have mentioned that you especially enjoy the drone rework, and I am very pleased about that. The mountaineers also got significant changes, and it's been great to see them finding additional use.

We're not quite done yet, though, as there are many elements I would like to improve before the beta becomes a proper update.

I've just uploaded a new beta version, and you'll find the changes here.[gnorp.dev] You can access the beta the following way: Right-click the game in your Steam Library -> Properties -> Betas, and then write 4gnorplovers in the private beta field.

Here are some of the highlights of this round of changes:
— Clear button for the talents
— The Supershatter rework has been reworked, and it is now called Minishatter
— Baby drones now have a cooler way to attack
— Slam 2: Re-Rockening (neé Combo Power) now allows for possibly infinite combos
— Melty Bullets has a synergy of sorts with Future to the Back
— Ice immunity is visible as a status

Again, the full list of changes can be found here.[gnorp.dev]

A big reason for these changes are to improve the foundation of the base game to in order to make the Epilogue a better experience. So let's talk about talents in the Epilogue Update.

The Epilogue Update will have a new mode, Epilogue, that will feature additional gameplay mechanics, like sending gnorps (almost) to space, and a new ending.
(the) Gnorp Apologue is a bit like a puzzle. The problem of the puzzle is always "How to get more", but the solution will depend on your progression level — your talent points. With only a few talent points available, many people find Popcorn and Superhot to be an excellent solution, but that specific talent combination can only take you so far without adaptation. Along the way, as the player discovers more interactions and gets a more intimate familiarity with the units and mechanics, more solutions are discovered.

I'm very satisfied with the idea of the design. I think (the) Gnorp Apologue would be a poor game if the player was not encouraged to seek out new solutions for progression or their own curiosity.

Now, the tree itself initially started as a tree-like structure — the sort you'd find in WoW or Borderlands. Then I realized a tree-structure would feel too restrictive. My goal was to have the player feel like they are carving a path through a forest. The tree-structure goes against that goal, as then the player merely picks a path through the forest to walk.

Concepting the talent tree we have today.

The talents themselves were meant to allow for exploration of the game, and with an open non-tree structure it was important that the talents adhered to the following rules:
— Not openly synergetic with other talents
— Opens up new opportunities for exploration
— Have a downside, apparent or otherwise, that could ideally be worked around

If you have a very good memory or have recently played the game, you might be asking "What the fuck, Myco. There are many woeful exceptions to these". Yes, indeed. Some talents exist to feel good—to shelter the player from the chaos of permutation. Complicated talents might not have a downside, besides the cognitive load of reading the tooltip.

Some talents could use a bit of a redesign. That's what the ongoing beta is for, and I feel confident that it's moving things in the right direction. But let's not have perfect be the enemy of perfectly adequate.

Now, assuming a delightful talent tree of interesting choices—can we extend that? Should we? I think most of you would agree that more talents would be cool. I am also of this opinion, so I decided that—yes, we should—the Epilogue Update will have more talents.

The question then is, how? A few options are apparent:
— A clean wipe of the existing talents, replacing them with new ones when playing the Epilogue
— New talents are inserted into the tree, resulting in a total 6 or 7 talents per milestone section, up from 5
— The talent tree is extended with new milestones and milestone sections

Ironically, the clean slate option might be the easiest. It would allow for more creative freedom allowing for all sorts of possibilities, instead of trying to come up with new talents that would cleanly fit with all the other ones. Unfortunately, there is a significant downside with the clean slate: You, the player, would not be able to leverage your existing knowledge going into the Epilogue — and that's a deal breaker.

The second option, with new talents being inserted into the tree, could be neat. It would be difficult to come up with talents that fit with the existing ones, but certainly not impossible. The biggest problem would be cognitive overload, where there are simply far too many options to consider — and that's a deal breaker.

The third option, an extended talent tree with new milestones and milestone sections, is a bad option for the following reason: You, the player, would be retreading too much old ground — and, because the Epilogue is supposed to be fresh, that's a deal breaker.

So all the readily apparent options are terrible, but now we can move on with an understanding of what the unknown, good option must do:
— Avoid cognitive overload
— Allow the player to leverage previous knowledge
— Fresh

After tossing ideas like a salad in my brain, I came up with a solution that I am happy with: Talents+. That's a terrible name, but (the) Gnorp Apologue might not the best name either, considering how many "gnorp analogues" I've seen online.

Talents+ is an extension of the talents in the game, where all talents have two slots for points. You'll have to spend two points to get the the Talent+ effect. A talent might look like these:

HIKING BUDDIES
— Mountaineers bring a friend when they depart the Cocoa Cafe
BRING THE WHOLE GANG
Unwilling participants galore!
— 4 hiking buddies now join the mountaineer

Doubling down on the talent avoids cognitive overload and gives a significant power increase to the talent.

BULLET BREATH
— With Fire Breath acquired: Slammers will spray gatler bullets instead of breathing fire on their 7th combo
BABY BREATH
"Where did you get these? Why did you eat them? Why are you the way you are?"
— Instead of bullets, shoot baby slammers that.. despawn when completing their combo

For this one the talent is replaced by something different — it works similarly and slammers breathing babies should be a delightful viewing experience. Since it'll cost 2 talent points and is a replacement, it has to be powerful.

POPCORN
— Fire damage has a range of 7-10, up from 0-3
SOME GNORPS WANT TO SEE THE PILE BURN
Actually, all gnorps if this proves effective.
— Gnorps that shoot fire arrows will now aim for the pile. Burning the pile shifts shards forward.

For this one you keep the previous talent and get an entirely new one!

This solution is exciting, and ultimately the superior one as it sidesteps the issues with leveraging knowledge, cognitive overload, and freshness. The end result will ideally achieve the following results:
— Unhinged and interesting
— The above

— The work to increase the frequency at which I release (the) New Gnorp Times continues.
— Currently splitting my time on the Epilogue Update and the currently-beta-update.
— Doing well! I hope you are too.

It's time for another edition of well-respected publication (the) New Gnorp Times.

Today is the start of the Idler Fest on Steam, and I thought it cool to also provide a couple of new things to mark the event.

The first batch of hats are now available! It's been a long time coming, but the first ones are finally here! There will be over 20 hats implemented into the game, but we're starting with six of them. These first six hats are amazing and they all look great in-game. They're unlocked by completing certain achievements — for example the SPEED achievement unlocks the snail-gnorp (snorp?), made by Joy. Fitting!

Thank you to submitters Joy, Sleepyhead, Doshige, Zymosan99, and Popgoes! More hats coming soon.

A new beta update has just been made available. You can access it by right-clicking the game in your Steam library -> Properties -> Betas, and then write 4gnorplovers in the private beta field.

Please note that the localization for the beta has not been updated to match the changes.

The goal of this update is to meaningfully improve units and talents to make your choices a bit more interesting and to enable new and cool builds. With the Epilogue Update on the horizon, ensuring a solid base-experience to further build upon is very important.

Slammers, Mountaineers and Drones have all received updates. Here are some of the highlights:
— Drones now consume shards to spawn baby drones
— Mountaineers can now, with the help of a talent, designate an area of the pile sacred
— Slammers have can now deal significantly more damage with the help of the redesigned talent Remembrance of the King
— Reclamation Nullification has been replaced with a new, more interactive upgrade called Don't touch my pile!
— A new talent called Melty Bullets. How does it work? Really well!

The changes touch on many parts of the game, and I'd love to hear your feedback if you end up trying the beta update. The best place to provide feedback is in the Gnorp Discord[discord.gg], in the #beta channel. However, I will also try to check for feedback in the Steam forums now and then.

Below you'll find a comprehensive list of the changes.

(the) New Gnorp Times, well-respected publication, will now be released roughly every 14 days until the release of the Epilogue Update/Mini-expansion. The work on the Epilogue is going well, and I might tell you more in two weeks. Thank you for your patience, and I'll talk to you soon.

<3


Reclamation Nullification has been replaced by something better. The something better is intended to allow for a more interesting way to work around reclamation.
Don't touch my pile!The rock might be fighting back, but the mountaineers (and drones) resist.
— Prevents reclamation where mountaineers (and drones) are planning to go
— When told to rest, Mountaineers now rest on the pile, as long as there is space and the pile is worthy of climbing

A replacement to clicking on drones
Roboticide
Would be a shame if anything happened to one of these drones.
— Murder a random drone

Drones have been modified to no longer eat shards for no gain. Instead they spend some time eating, then spawn a baby drone.
Drone
Get yourself a drone, but be careful — they're hungry! Drones are auxiliary units that need some help to succeed.
— Drones pick up a fixed amount of shards, based on the current tier
— Drones consume 70% of their capacity over 3.5 seconds. If Drones finish eating, they spawn a Baby Drone
— Baby drones deal damage equal to the consumed amount, with a range of 7-10, then die
— Drones die during compression events


Higher the pile has been replaced by:
SACRED MOUNTAIN
The gnorps bless the pile, for it represents the fruit of their labor.
— Mountaineers now consider the rightmost area of the pile sacred, and attempt to build a large mountain of shards there
— Mountaineers do not dig the sacred area

This new talent replaces drone targeting. It gives bullets an interesting effect.
MELTY BULLETS
Perpetuate that fire with some melty bullets! How does it work? Really well! Pyromaniacs pick this.
— Bullets that hit the rock while it is on fire deal their damage as fire damage

Descent of the king has been redesigned to empower the king when he is present and to also empower slammers when he is not.
DESCENT OF THE KING -> REMEMBRANCE OF THE KING
When will He return?
— The King of the Pile will always dig an additional 2ø of the current tier
— Slammers gain a bonus to their damage when the king is gone
— Bonus starts as +10, increasing by +2ø every minute
— To facilitate The Return, slammers halve their range when Remembrance is active

The flow has been modified to give slammers a bit of extra damage and now they only fly farther when they actually combo
THE FLOW
Allow slammers to unlock their latent power, displaying the power of dumb determination.
— After having meditated, slammers deal +3ø damage, plus an additional +3ø damage for every slam in their current combo
— Slammers fly much, much farther away after a combo


Supershatter has been modified and moved in the talent tree! Old supershatter took away the ice multiplier, but this version does not
SUPERSHATTER
Let's put this rock on ice.
— Ice arrows immediately freeze the rock
— When ice shatters, an additional 60 shards, doubling with every tier, is dealt. This additional damage has a range of 0-6 or 4-10, picked randomly with every occurrence.
— Ice arrows striking the rock when frozen deal 4x damage, up from 2x
— Frozen duration increased to 20 seconds, up from 4
— Shattering the ice with fire effects allows the rock to be frozen again immediately

Combo power has been renamed, and now has an additional benefit when combined with baby drones
COMBO POWER -> SLAM 2: RE-ROCKENING
Starring: The slammers, and the baby drones in a guest appearance.
— Slammers gain an additional 1% chance to combo every time they do a preparation jump
— When triggering Combo Power, slammers cause baby drones that are attached to the rock to explode for 2x their total damage

Drone capacity is adapted to fit the new drone behavior
DRONE CAPACITY
Drones get more capacity and they spawn more baby drones, but at a cost.
— 2x capacity to drones
— Drones eat twice as much and now spawn 2 baby drones
— Descent speed reduced by 50%

A redesign to fit with the new drones, and a name to highlight potential synergies with zygnorps and baby drones.
DON'T EAT THAT -> BABIES TOGETHER STRONG
United by the power of shared suffering!
— When drones spawn a baby drone, zygnorps gain energy equivalent to the consumed amount
— Zygnorps never collect from the left side of the pile

This used to be a talent. Now it's an upgrade that costs gnorps.
New upgrade: Drone Targeting
By default, drones are directed to target the highest points on the pile. With some additional gnorp-power, additional targeting modes can be unlocked.
— Drones unlock the FAR and NEAR targeting modes

Redesigned to fit with new drones
Inspiration: Drone-Bomber
Drones enter efficiency mode, reducing their overall movement speed and consumption.
— Descent rate is halved
— Consumption reduced by 30%, without affecting baby drone damage

Redesigned to fit with new drones
Inspiration: Drone-Rocket
Drones enter burn mode, increasing their overall movement speed.
— Descent rate is doubled
— Acceleration is doubled

King of the pile has been modified to give the king some additional power and now also affects his mobility.
King of the Pile
A zybellium crown with powerful effects is granted to a single mountaineer: The King of the Pile.
— The King digs 10x faster
— The King digs twice as much
— The King has significantly increased mobility
— The King will not rest

Acid has been modified slightly to avoid instances of it being doubly good for both damage and compression.
Acid
Puke flowers create Spewers. Spewers explode on the rock, leaving Acid. While acid is present on the rock, it has the following effects:
— 1.5x increase to all damage
— The minimum range of damage is reduced by 3, ex: 7-10 -> 4-10

Rest in piece: Adaptive Learning
Rest in piece: Terathrusters
Rest in piece: DRONE.TARGET = FAR |DRONE:TARGET = CLOSE

Hello, friends.

It's been a little over one year since the release of (the) Gnorp Apologue.

I hope 2024 has been a good year for you — that you have made progress in life, whatever that might mean for you. For me, 2024 was a year of relative tumult and honestly personal failure: My primary goal at the end of last year, was to deliver lots more Gnorp. We're now at the end of this year, and the goal remains the same.

The headlines of 2025:

• (the) New Gnorp Times (what you are currently reading) will be published at a regular cadence
  
• The Epilogue Update will be released
  
• A new game announcement and, ambitiously, release

[/b]
[/list]I would love to highlight a recently released game, a game which had (the) Gnorp Apologue as one of its primary inspirations. Idle Colony is, like (the) Gnorp Apologue an explosively visual incremental game. If the game looks interesting to you, I hope that you will support the developer. Together we have made a bundle featuring the two games at a discount.

It's an incredibly cool feeling to have the gnorps be a small part of the journey of the development of Idle Colony.

https://testx-steam.c5game.com/steamstore/bundle/48656/Explosively_Visual_Incrementals/


What started as a numerically harder game mode, has now morphed into something more distinct. I want to share with you a little teaser which features a new core gameplay feature of the Epilogue Mode — a different kind of firework.

I hope you'll enjoy the update when it releases, and I hope it will deliver on the idea of (the) Gnorp Apologue with a different flavor, and new mechanics to explore (and abuse).


And finally...

Look at all these bullies ganging up on a single gnorp, just to get a shard.

Take care of those you care about (a list which should ideally include yourself), and have a great 2025. Thank you for reading, and thank you for playing Gnorp. You're the best.

Hey guys. It's been, frankly, far too long.

Developing (the) Gnorp Apologue continues to be a privilege, and today I'm going to share my current plans for the future.

During the development of (the) Gnorp Apologue, game design solidified itself as my passion. I have too many ideas that I want to execute, but I want to get to as many as possible. My dream is to create gameplay-focused games with satisfying gameplay and a strong visual identity.

Here's what I've been working on, divided into three parts:

I've talked in previous news updates about the development of a hard mode, and this is the evolution of that hard mode. I realized that I would not be happy with myself if I didn't take the opportunity to add some form of new content to the game with the addition of a new mode, and thus a new path presented itself: (the) Epilogue — a more challenging, hopefully not frustrating, version of the game that works as a continuation of the base-game, with the following highlights:

• Two new gameplay features: Shard-spilling and the slightly unhinged Weaponized Housing
  
• A new building
  
• A new, perhaps alternate, ending
  
• Updates to talents, replacing some, renewing others
  
• Altered scenery and some music to fit the tone of the (the) Epilogue

Think of it as a tiny expansion in the form of a new mode, that will allow you to revisit (the) Gnorp Apologue with a fresh new perspective.

The new, perhaps alternate ending will lead us to two places: PART II & PART III.

A project that I am very excited about, [Untitled Project] will be a new game that will deal with the aftermath of the ending of (the) Epilogue. The goal is to talk more, including a title reveal, about this project with the release of (the) Epilogue Update, provided I reach a point where I have something representative to show you. For now, here's a little teaser.

The project that will take the gameplay and the gnorps to the stars, it is planned as an expansion to (the) Gnorp Apologue with entirely new gameplay, but may end up as a standalone game. It *also* deals with the aftermath of the ending of (the) Epilogue, but in a different way.

Space is vast, and so is the design-space for this project. I've worked on several gameplay ideas & prototypes, and I believe I am approaching something that fully encapsulates my goal for the project. The plan is still for Gnorps in Space to be a physics-based incremental game, but I am drawing influences beyond that as well. There are several considerations to make, but chief amongst them are 1. Executability and 2. Satisfying gameplay

I'd love to tell you more, but I'll leave it at this for now: I tend to think of the gnorps as a force of nature, and I want Gnorps in Space to adequately portray that force of nature.

So this is my vision and plan. All three parts are playable, with Gnorps in Space the most in flux. Right now, the focus is on completing (the) Epilogue Update.

In terms of timeline, I don't want to overpromise. I know when I *want* to complete all of these projects, but development can be unpredictable. Additionally, I've been hamstrung, as some of you may already know, by the release of an app on the Play Store that bore striking visual & gameplay similarities to (the) Gnorp Apologue. If it had been a benign fan-game with differing gameplay, I probably wouldn't care — but it was monetized with ads and microtransactions. I've received a truckload of emails and messages about it, and it's currently a work in progress to resolve the situation. It's honestly been an tough time, and not to mention a huge distraction from what I actually want to be doing — working on the game(s).

So, I want to apologize for the past months of silence, and I want to thank everyone who has notified me about the game on the Play Store. I'm working on it. But more importantly I'm working on all these projects that I am so looking forward to seeing through, and I hope you are excited about them.

I haven't forgotten about hats! I would love to have hats ready for (the) Epilogue Update, but there is one outstanding issue: Originally, I intended to add new achievements to the game that would allow you to unlock hats, but I am not certain if this approach is correct. The approach I am currently considering is to have hats be unlocked through a currency that you earn passively while playing the game. Once I arrive upon a solution, I'll be able to move forward with the full implementation. If you have any feedback on this, I would love to hear it.

Thank you again for all the wonderful hat submissions, and I am so looking forward to seeing the winners be represented in-game.

Summing up, I'm super excited to see all of these projects through. First off is the release of (the) Epilogue Update. Following that, [Untitled Project] production will proceed, along with smaller-scale updates to (the) Gnorp Apologue. Then, we set course for Gnorps in Space.

Finally, I'd love to give you more frequent updates (both news and updates to (the) Gnorp Apologue), so I am going to make that a priority.

My wife and I also got two cats: Beast Gnorp Bosemeow (right) and Jean-Claude Luc-Pierre I (left). They're high-quality cats, except on days when they jump onto the kitchen counter, which is every day.

Thanks for coming to my Gnorp-talk.

Yesterday I uploaded a patch that changed the order of shop items. I got some feedback that this should be an option, so now it is!

• "Reverse shop" is now an option than can be enabled. Enable this to get back to the previous order.