Forem: No_Arms_studio

Scratch biology (part 1)

No_Arms_studio — Fri, 27 Mar 2026 20:47:02 +0000

Over the past few days I have been working on an engine to create realistic life in the coding engine known as scratch. While it is no means realistically accurate and I will have to work much harder to make it look like real cells interacting, I would like to share with you my progress and how I implemented these things.
The first thing that I did was create a bunch of points in a list, these are all clones in the optimized version but I will tell you how I made them optimized later. Each of these clones put their x and y into a list in action to put a type or spices into a list, this can be any number but it is easiest with 3 to get the best results. This is so that each of the particles will be able to interact and see where each other is. In the end this looks like this:

Next I gave each of the particles the ability to move by changing their x and y by their xVelocity and yVelocity which I set to a random value between 1.0 to -1.0. Of course with movement comes collision so I implemented the naive collision algorithm which checks every other particle to see if they are colliding giving this result:(I increased the particle count for a better viewing experience)

After this I played around with adding cell spiting which happens every time a cell gets above a certain energy level but that didn't last long on around of the collision being to high of a performance cost. Here is what it looked like:

Wish I knew how to do video because it is pretty mesmerizing to watch but anyway no to the fun part, particle life. Particle life is where you put a bunch of particles next to each other and give them rules to interact and they will do it in fantastic ways, It truly is a weirdly close life simulator. Anyway the way that I did this was first testing my attraction code by seeing if a particle was within a certain distance It would start to move together. Which works but isn't that interesting, It looks kind of like tissue.
Remember that type list that I said to add at the beginning, that comes in handy now because we can set rules for how the different types of particles interact. This allows us to make the simulation look like this:

Now that we have this wonder of code we can optimize it because I had to run It at half the particle count to get more than 5 fps and I'm using turbowarp, scratch's compiled version. The first and easiest part of this process was to implement the easiest optimization on the distance equation, Instead of using r < sqrt( DeltaX^2 + DeltaY^2 ) use r^2 < DeltaX^2 + Delta Y^2 because using square roots is expensive. Now that we got that one done lets go onto the optimization that made me have the biggest rewrite of code I have ever had, spacial partitioning.
This is where you make the entire screen into a grid and put each of the particles into that grid, for each particle only check the grid cells that are around the cell that that particle is in. For this through our everything and start from scratch, literally. Sorry about what I just had to, anyway the reason for this rewrite is because everything needs to be In the one sprite, no clones, no other sprites, no nothing. For this all of the points need to be in a grid as an X, Y, XVelocity, YVelocity, and Type, this makes it so that optimization is easier because you don't need to good through a bunch of clones to find a value, only a list. Now the way that I made my spacial partitioning Is by setting up 2 lists called Gidx and Gidy standing for Grid index x and y. The way that you find your Gidx is by taking you x and running it through this equation ceiling( x / GridTileSize ) and the same thing for Gidy but switch x and y. Next, when you are checking collisions before finding distance or anything else, see if your selected particle that your checking is in the range of Gidx - 1 < selectedGidx < Gidx + 1 then do the same check for y and then if it meats that criteria then check it. This boosted my fps on 1000 particles from 5 to 14, almost a 3x difference.
This my friends marks the end of this article but fret not, spring break is on the way and I am going to work on modeling actual cells as talked about in scientific papers, I am going to regret it but I have time to be smart when I'm older. Thank you all for reading and I will see you next time :)

Planetary gravity

No_Arms_studio — Wed, 18 Mar 2026 23:03:41 +0000

It has been a minute since I last posted a devlog, and this is not it but it is coming soon, I promise. Today I want to talk about my gravity engine using Euler's method of gravity. The first step to this process is to make the planets, I just made a bunch of clones that all drew their position onto the screen with the pen extension. There is also another sprite the size of the screen that refreshes it every tick by stamping it onto the screen.

Next I gave each of the planets an initial velocity and mass scaling their size to that mass, you can't see it because the mass of the planets is too close but they are scaled with their mass. The amount that the velocity moves the planets is scaled by the global variable SIZE which also scales the planet size. I have it set to 1000 in this simulation. The result after a few seconds looks like this:

After this I setup a function that would make the planets be able to interact with each other's gravity. The way that It works is that each planet has a position in a list along with a mass in a list and this makes it so that the other planets are able to change their velocity depending on the other planets. I made it so that each planet every frame loops through this list and finds the distance to the planet that is selected and changes a sumXVel and sumYVel variable by the distance x / (d * mass) and the same thing for the y distance. At the end it changes the x and y velocities by the sum x and y divided by the total amount of planets. After a few seconds the effect looks like this:

In the end I also added some developer tools such as pausing, deleting planets, and most importantly creating planets. The way that the creation of the planet works is that first you are asked for the mass that you want, then whether or not gravity is on or not, then you find the position that you want then press space and It creates the planet. Anyway, thanks for reading this is my first article with pictures, hope you like them cause there is more to come and more below of the best pictures I got.

Y'all have no idea how long that last one took but I like it. Thanks for reading and have a great rest of your day :)

Devlog 4

No_Arms_studio — Thu, 12 Mar 2026 23:10:35 +0000

< Welcome back to my devlog series on fixed, my little indie game. So in this I don't know how long I made multiple things for the MVP of the game:

Perlin noise generation
A rough base for the creature system
Player movement First I am going to talk about the Perlin noise algorithm that I use to generate water and trees for the cover of this article. So basically if you don't know what Perlin noise is, it is the smoothing of white noise which looks like TV static, random values. You can also add a bunch of layers of this together with a higher frequency but a smaller overall effect to get something called octaves which i did do to make everything feel more natural but that is beside the point, there are much better explanations of how everything works elsewhere. But anyway, what I did was really simple, I got the Grid index of that point, and found its height. Then if it was over a certain value then it's a tree, if it is below a certain value it is water, and otherwise it is grass. The next thing that I worked on was my creature system, while not being that good yet it is a good base for me to build up different creature types. The way that It works is that all creatures have 2 states, active and recharging. When the creature is active, it walks around looking for food and when it is recharging it stays in one place getting energy. That's it. Finally, the player movement, this is the least complicated part. So when the player moves, the environment actually moves so that the player never actually goes off screen. But when the player moves the background so that It is at the edge of the background, the player starts to move. If the player is on the edge of the screen plus some value then the player stops. Well folks, that's all! Thank you for reading and have a great rest of your day :)

Devlog 3

No_Arms_studio — Tue, 03 Mar 2026 05:20:49 +0000

< there has been a large gap between the last devlog that I posted, sorry about that I am not good at sticking to plans I make in my head. This is why I made a Milanote board (Which is a fantastic website BTW I recommend it a lot) and now I am back to explain the very bare bones plan for my game.
So basically I am going to make a game that has a very small rain world like environment where the player progresses like Minecraft in the tool and resource sense but much slowing in progression. The bare bones lore is that an alien race came down to earth and waged war and then put the surviving prisoners in containment cells to test on.
The way that the ecosystem will work is there is a semi large area and when one animal dies another of the exact same genetic structure will be released into the environment. All animals at night will go back to their homes which are basically the holes in the wall from rain world. Talking about rain world, there creature AI system will be and is a great inspiration to my project.
I have not fully decided about whether I want to make the world 2d or 3d because of factors such as 3d rendering in scratch is close to impossible especially with a whole bunch of grass on the ground. The way that I layer sprites is with the griffpatch method but when you stamp a sprite you have to be behind another in order for that stamp to be in front because of layering and all that.
This is basically all that I have done so far in the planning stage, I will for sure be posting about magor updates on fixed's development but for now have a great day and thank you so very much for reading :)

Boids

No_Arms_studio — Wed, 25 Feb 2026 21:25:54 +0000

< I have been experimenting with something lately, this thing is called boids or bird-oids. This wonderful algorithm was invented in 1986 by Craig Reynolds and it mimics the flocking behaviors of birds, fish, and other things such as herds. This effect is accomplished by using 3 simple rules, Separation, Alignment, and Cohesion. There are of course other things that will be Tweaked such as the range a boid can see, its target speed, or its resolve for said speed.
First I will talk about Separation. This is exactly as it sounds, boid is in range of another boid then it will try to get away from that boid with the strength of this effect being controlled by the Separation value.
Next up is Alignment, All boids will try to face in the same direction as boids in view range and this again is controlled by the Alignment value.
Finally there is Cohesion. Every boid wants to be at the center of attention and be at the middle of its flock and one last time, this is controlled by the Cohesion value.
Using all of these values you can make a good simulation of boids but how do you make these happen? My Implantation for separation was changing the x velocity by ((0 - Separation) * (distance x / distance)) and the same thing with the y velocity. The way that I achieved Cohesion is by adding up all of the distance x and distance y and dividing them by the amount of boids within range then finally multiplying them by the Cohesion value (the math looks like this (Cohesion * (sum x / boid#))) I recommend setting the cohesion to 0.1. The way to get the Alignment is found by finding the difference in x and y velocities from the boid its checking to the current boid then multiply the value by Alignment, the equation looks like (Alignment * (sum x / boid#)) and again I recommend 0.1 as the Alignment.
This is pretty much the end of this article, thanks for reading and have a great day :) happy coding.

2D Raytracing

No_Arms_studio — Sun, 22 Feb 2026 01:10:41 +0000

< First thing I would like to say is that thank you all, I have hade a massive influx of followers and I thank you all for it. But anyway time to get to my approach of raytracing in scratch. First I would like to talk about what is a raytracer. A raytracer is a computer code that send out rays into an environment and let them bounce to see how light would act in that environment. This fundamental code makes all sorts of things such as cg in big budget Hollywood movies to just little side projects for indie devs.
The way that I made my version of a raytracing engine is first to find the math for the rays. There are 2 inputs, the amount of rays and the FOV. The raycaster sprite turns half of the FOV and repeats the amount of rays turning the opposite direction the FOV divided by amount of rays. each of those iterations make a new ray.
My engine is a 2d raytracer meaning that it has a 2d texture that it bounces it's light in. The way that each ray works is that when it is initialized it moves forward 1 pixel, if it is touching a wall then it will turn around and point in a random 180 degree radius and it gets darker. If it touches the light then it will end it's loop and draw the walls height depending on the distance to the camera, if it fails to touch the light within a certain length then it turns up completely dark.
This system in the end makes a pretty realistic looking simulation of light for scratches standards, in no means is it as good as Hollywood or even a normal indie side project but it works. Thank you for reading this far and have a great day :)

Color Always Haunts Me

No_Arms_studio — Thu, 19 Feb 2026 03:57:25 +0000

< over the past day I have been reworking my grass shader and right now its almost 10. It's much faster, in part to my superior way of programing but also the fact that turbo warp has compiled their games to make them run much smoother. Anyway that is non the matter if you want to learn more about my previous try then check out my devlog for my game fix with this is still about in order to learn more.
So, after finishing making the different wind and the clouds procedurally generated and the accent grass and all that mumbo jumbo I cam up to the color patches. Now this is my pain, I don't like color in art or at least working with it so you would expect how I felt with this finally step. I made a new function for noise and plugged in the new values but then the cover happened and after all of the troubleshooting I went through I still can fix it so, I'm going to sleep.
Good Night Folks and have a wonderful day, thanks for reading :)

Coding while being sick

No_Arms_studio — Mon, 16 Feb 2026 19:10:39 +0000

< I have been sick, for 3 days and it has not been fun. When your not sick, you take for granted how nice it is but when you are, boy you know my pain right now. I have not been able to code for like 2 days not only because I am sick but also because of the parades here witch normally I would not go to when I am sick but I isn't that bad of a sickness and I had family over.
But anyway when your sick, get some rest or you might get burnout and you aren't going to have as good Ideas as you would when your not sick. Thanks for reading, Ill probably be fine tomorrow and be back to coding but till then have a great rest of your day.

Matrix effect

No_Arms_studio — Fri, 13 Feb 2026 03:24:09 +0000

< I could not figure out what to do for today's thing so I just did the matrix effect, close to the simplest thing to code in all of programing. First you get green 1s and 0s then you make it so that they infinitely spawn and make their position random in the x axis and at the top of the screen in the y axis.
The trail effect is achieved by making the sprites stamp their position to the screen and move down a grid tile, after this have another spite stamp a black screen with a high ghost effect making the trails fade overtime. In the end when the letter is off the screen make it delete itself.
Short and easy, as i wish all things could be. Anyway thanks for reading this and see ya'll tomorrow.

Fireworks

No_Arms_studio — Thu, 12 Feb 2026 03:14:36 +0000

< I made this all the way back in December for new years. This is my very own particle engine at work making the fireworks spray. The way that it works is that there is a main firework that goes off then that one spawns in a bunch of clones. These clones have a high chance in order to be just regular and fall to the ground or letters. But there is a special type of particle that has a small chance to be made, this one acts like a firework that doesn't go up and makes a smaller amount of particles.
The way that the particle engine works is first it moves in the y direction, if it finds a collision it goes back to it's previous position and sets the y velocity to a negative with a damping value. The x position is the same. The y velocity is always reacting to the gravitational constant and air friction. When the particle is in the air the x velocity is only reacting with air friction but when it's on the ground it also has friction acting on it. This is how all of this works.
Thanks all of you for reading and Have the bestest rest of your day :)

Averaging values

No_Arms_studio — Wed, 11 Feb 2026 01:57:39 +0000

< So, In my quest to make good real looking environments, averaging values is my best friend. using averaged values between a large data set makes it so that we can have flocking by making certain things go in the same direction such as boids. It can also be used in the opposite case, If you have a bunch of values of enemies you can average them to find the best way to get free of their chase.
Me personally right now, I am using the first approach to make the cover image. It is a bunch of little machines that are stamping their positions and not clearing them afterwards. But using averaged values is useful for many other things such as conserving fluid density in a fluid simulation, or finding things in populations, personally I know that many games use a averaged value of a population to find certain stats say like in a city builder.
If your very, not smart the way that you calculate mean with is the averaged values is that you add them all up and divide that number by the amount of things your averaging. As an example I have a 1, 2, 3, 4, and 5, 1 + 2 + 3 + 4 + 5 = 15, 15/5 = 3. The mean is 3, shocker. This last part was just a filler part I'm going to be honest, but anyway thanks for reading and have a great rest of your day.

3D stylized rendering engine

No_Arms_studio — Tue, 10 Feb 2026 04:57:43 +0000

< I have made a very, very simple rendering engine for the game engine scratch and keep in mind that It is extremely simple. I do like the end result of what has come out of it being a stylized 3D rendering engine in scratch, a 2d game engine.
The way that this works is that there is a base image and the sprite goes down by a variable called height then goes back up to where it was stamping itself as it goes up. This drawing function is called with a message making it so that the screen can be reset without artifacts such as certain parts not being drawn as they were erased.
The code for this looks like:

   Draw
          brightness = -20
          Y positions = Y - (height)
          repeat (height)
                 Y position = Y + (1)
                 stamp
          end
          brightness = 0
          stamp

< And that's basically it, very simple yet very effective. There is no problem with this method though, when you layer sprites under and on top of another, you get weird artifacts when the spite is under the wall it should be in front of because its just a layered image. I fixed this by making sure that this artifact wouldn't happen by level design or making it so that it's all just the same image and at the same height is boring. you could make something where the sprite has individual costumes for certain heights.
Well this brings us to the end yet again, see y'all later and have a great rest of your day :)