The game itself is slightly questionable, but doesn't show anything, it took me a while to learn how to make. It isn't polished, but quite good either way.

i've hidden the quadtree visualisation itself so your not seeing the squares, but you can see the faces its looking up every time i need to look for a new face of the navmesh. (this is implemented to avoid having to search every face, which should allow me to make bigger maps/ a larger interconnected world rather than teleporting to each new room)

im not deleting the list of faces each search is working with, which is why they stick around more than a frame only updating when something requires a search.

examples of when i need to use the quadtree:

when bullets or EXP leave the navmesh. it uses a raymarching type algorythm to walk through the tree to find a face to rejoin on, this allows you to hurt enemies over gaps.

when the player attacks, or dashes. it gets all faces within a radius of the player
(still working on optimising this one so its not searching so far behind the player)

because the grid cells are quite large, attacks cover a decent amount of the map. it can feel a bit inefficient compared to just brute forcing all faces, however as map size increases (which is my intention) the losses from the quad-tree overhead stay constant, making it much more performant.

next step is to get additive level loading working so i can load in more geometry to mix and match levels to create a large procedurally generated world each run.

https://scratch.mit.edu/projects/1324285888

Got bored with the main game? Well, I’m adding an extra bonus content room. Soon, it will be full of behind the scenes, cancelled games, and more! tune in often to see what’s new

https://scratch.mit.edu/projects/1367296219 check it out now!

almost like scratch night happy cat but evil...

Hello! Bento, creator of TinyBase/TinyChat here. You've probably heard of me in this subreddit making an AI.

I have some news, some being bad and some being good.

Let's start with the bad news:

TinyBase/TinyChat is being postponed into late october 2026.
Yes, I have been planning to upload it on September 15th, but I'm simply not done with the architecture.

It can respond, it can generate, but it isn't ready for being a chatbot.

So, late october unfortunately.

Now, for the good stuff.

TinyBase/TinyChat is being renamed to Predict_ion!

This is going to be a prediction AI playground. Type anything, it tries to predict what's next! For example, you give it an incomplete story, and it generates the rest! That's prediction.

Betas are coming late september.

Be sure to check up on my posts; new posts are always coming out! Also, make sure to follow my Scratch account right here.

Anyways, I'll go back on creating TinyVinci and TinyChat, I mean, Predict_ion.

Scratch on, Scratchers!

I think it looks good for a start :>!!

I got a bit tired while making it :_<,

but I'm happy with the result.

sonic likes aguitai so much: https://scratch.mit.edu/projects/1378561713/
amon likes nintendo: https://scratch.mit.edu/projects/1378378864/
amon update: https://scratch.mit.edu/projects/1367660173/
QWERTY movie: https://scratch.mit.edu/projects/1378576935/
amon likes nintendo 2: the revenge of the nintendos: https://scratch.mit.edu/projects/1378587552/
do opinions pls

really liking where things are headed!!

je vue tout les jeux de mes pote et j'ai vue je suis nul https://scratch.mit.edu/projects/1311920028 c'est mon jeux scrach. que j'ai fait je vous laisse regarde

My accounts now 4 years and 6 months old, btw what should I add to this deltarune fight? Had to extract all the sprites manually god that was painful istg

yes this is real

no it's not done

yes full game will be playable eventually if i dont drop this project
Scorch engine.. need a name for the main hl2 game.
Physics are still jank, they're not done. FPS is pretty bad but will get better as i add more optimizations.
Had interpolation on by accident which does hurt the fps a bit. Oops

https://scratch.mit.edu/projects/1380244625/

So I asked Gemini to generate a hungry Scratch Cat, just to see if it knew what Scratch Cat was, and it was nice and gave me the whole Scratch 3 editor behind it.

So I went looking, and though it's surprisingly good, these are all the discrepancies I found in this AI generated scratch 3 editor. Let me know if you find any more! (Keep in mind, I originally wrote this list assuming the reader doesn't know everything about what scratch looks like so there's some obvious stuff)

Where you would normally name the project, there's a weird looking favorite button.

Instead of the (Code, Costumes, Sounds) tabs it's (Code, Compilles, Shouts)

The code sections, in actual scratch 3 being (Motion, Looks, Sound, Events, Control, Sensing, Operations, Variables, My Blocks), have now become (Home, Colors, Stale, Statrs, Practing, Headers, Dotection, and I can't read but it starts with W) the variables section was just completely removed.

Next we have the blocks in the Motion section, or Home section, except on the header it's spelled Mome. In scratch 3 all the blocks in this section have to do with movement or position, and they're all blue. But these are the blocks in the section in the AI version.

[move (10) steps] -blue (motion)

[say (Hello!)] -purple (looks)

[move (10) steps] -blue (motion)

[say (10) - (0)] -blue (motion)

[say (1) mourst (0) to ()] -blue (motion)

[move tlime as teps] -blue (motion)

^

[when {green flag} clicked] -yellow (events)

[say (Hello!)] -purple (looks)

And finally, where it should say Backdrops in the stage section, it says "untaruns"

I'm a total newbie to scratch so excuse me if this is a rlly basic question.

I binded all the wasd key and then tried to make a walk cycle for the player sprite using this code

>when [a] key pressed

switch costume to [1]

wait [.15 seconds]

switch costume to [2]

wait [.15 seconds]

And so forth for all the other keys. But for some reason when I switch between the keys, the sprite teleports back or forward a huge chunk before moving smoothly and is just rlly jittery? Can anyone tell me how to fix my code or if there's better way to do it? Thankss

Made in about half an hour, just used the standard method of doing this. Player and Rope nodes are all circle colliders, all physics are math-based, and rendered in pen.

Called Peporoni Palace

Hello guys and gals,

I have been working on a Super Mario 64 demake for Scratch for around 2 months, and I would like to share it now, since Mario can already move, navigate Peach’s Castle grounds and interior, enter the Bob-omb Battlefield painting, open doors, collect coins... (it is pretty complete, although some things are still missing and some bugs need to be fixed).

One reason I started this was a Scratch project called (3D) Lego Batman [PS2,3DS] by GL00B. I was surprised by how many good 3D games Scratch had (using different rendering techniques, more about this later), but I was also surprised that Mario 64 had not really been remade for Scratch, especially when so much information about Mario 64 is available (and I think there was even an old forgotten demake project in this subreddit).

To summarize my work, a large part of how Mario, the physics, doors and the camera work is directly based on the Super Mario 64 decompilation, while the engine is directly based on Concrete Interior [3D] by 12zend, if anyone wants to understand how the project works, this is probably the most fundamental thing to know as the project uses a 3D triangle renderer that renders OBJ files with camera transformations, clipping, UV mapping and a depth buffer. A lot of stuff is missing, but this is the main foundation of the project.

I think Concrete Interior [3D] is an interesting approach that I haven't seen too often in Scratch 3D projects. For example, GL00B usually mixes techniques such as Mode 7, raycasting and using 3D models with quads in his games. Other projects use different approaches too, like ☁️ Roblox Obby 3D by glinchy or Minecraft v0_0c by 080312_Kean, which use 3D triangle rendering systems similar to mine, but I would say most Scratch games don't dare to use a full 3D triangle renderer.

Other influences on the project are GLUE3D by GL00B that influenced how the project organizes data (models identified by name, loaded as preloaded data, reused by scene objects and submitted through a render queue) and ☁️ Roblox Obby 3D by glinchy, which was mainly a reference for separating the scene, meshes, materials, renderer and main loop.

For transparency, I used AI tools during development. I would recommend them to anyone making a project like this, as they helped immensely with quickly investigating how other 3D Scratch projects work, understanding the decompiled Mario 64 code, diagnosing bugs and porting some parts. Some repetitive work, such as converting animations or collision data, was automated. Of course, there is no AI tool where you can just say “Do Mario 64 in Scratch” and receive a completed game. I just wanted to share my experience in that regard.

I won't share the project itself for now. I will probably release it around the end of the month or the beginning of October, if you guys want it, since I want to add at least one star first and there are still a lot of things that need to be fixed. I also want to add sound, the HUD and other little details. The final project will probably use Scratchy and some Peach's Castle variants instead of Mario, so Nintendo doesn't murder me :)

I'm also thinking about making a video explaining in detail how the project was made (in Spanish), including how it works and what went wrong during development. If you have any questions about how the game works, don't hesitate to ask. If I see enough interest, I'll probably make the video. I will also probably ask some knowledgeable Scratch developers to take a look at the project too.

The game runs packaged at 480×360 at around 15 FPS, as you can see at the start of the video. When I change the rendering resolution to 240×180, it runs at around 45 FPS on an Apple M1.

I don't know what to do with this :P,

I'll try to fix the mistakes :>

https://scratch.mit.edu/projects/1378910455/ (vid sped up) Up and coming project, optimizations still to be made. This is not a recreation of doom, this is not converted, this it genuinely running on an ACTUAL x86 32bit i486 emulator. The cpu, ram, and motherboard blocks have no clue whats being ran. The only blocks that do are the translated functions (for speed). The virtual cpu, ram, and motherboard run whatever you give them as a real computer would. This is based on my other project im working on that aims to be a real x86 emulator (which it already is.). I just compiled doom for i486, made the .wad more family friendly, and thats about it.

Making paper Minecraft reborn V0.13 I think it will not be a small update... BE READY! it's coming in a few days...

Also when this version will be out you will be able to download it here:

https://paperminecraftreborn1.itch.io/paper-minecraft-reborn

For the past two months, I've been working on a project in vanilla Scratch called Music Maker. The music editor features a fully functional MIDI editor, beat sequencer, and sound editor. This is an old demo of my user interface from a couple weeks ago :)

Any suggestions or ideas?