I don't talk about it that much, but one of my earliest homes online was on Scratch, a website that aims to teach the basic fundamentals of coding through it's own graphical programming language. While I'd love to tell my whole story with this site, that's not the focus on today's post, today I'd like to talk about my recent (one-off) return to gamedev on scratch and hopefully shed some light on what the site is like.
My current school actually has a course called Game Design, I very nearly took it but it seems like they spent more time drawing concept art than anything else (at least during the first year) and I can barely draw programmer art so I decided to pass on it. HOWERVER, quite a few of my friends did end up taking it and I've enjoyed looking at what they've been getting up to from afar. One of these friends was talking about their idea for a platform game and I shared some of my wisdom learnt from my experiences making those games on scratch a few years back.
A lot of very amateur game programmers will program movement using the built-in "move _ steps" or "change X by _" blocks, which does work but isn't very engaging to play since your character won't have any sense of momentumn. By the end of my time on scratch I was mostly controlling movement from variables that scaled linearly (mostly for racing games, but the same would apply to a platformer). So I decided to illustrate my point by very quickly hopping into the scratch editor and trying to program the most basic example of this variable-based-movement.
I had it so that the left and right arrow keys increased or decreased a momentumn variable ("mo") and the character would move according to that, I was able to convey the idea of slowly speeding up instead of immediately hitting top speed, but I didn't program in a way for the mo variable to reset itself to 0 once the arrow keys were no longer being pressed, which resulted in the holding left after going right slowly decreasing the mo variable before eventually moving it into the minus numbers (and giving the character movement a very weird feeling). So I didn't really illustrate my point, but we got a bit of a laugh out of it and moved on.
A few days later, I was considering ways to create a digital implementation of the card game Mao that could be played online (a pretty tall order considering the game heavily revolves around the spoken word in a way that a similar card game like Uno doesn't need to worry about). I again went to scratch to draft up some ideas (simply because it's the only programming language I know and is very easy to quickly prototype things on, since there's no need to compile before running any code and it contains a pretty good drawing program inside the editor), I got bored quite quickly though (I think I only got as far as creating some assets of all the cards and a few dialogue option buttons before I decided it would be far to much effort to even implement uno into scratch, let alone mao) and decided to give up on that idea. However, since I had the editor open I felt like going back to my idea for character movement and see if I could actually get it working. It took about an hour or so, but by the end of that evening I was able to get the character moving around! I still used the mo variable, but put in a script that automatically moved the variable back to 0 if I wasn't holding down the arrow keys, creating the feeling of slipping around instead of a pure stop/start feeling. Feeling satisfied, I took a quick video of it and sent it off to the friend in question before going to bed.
The next day, I decided to return to the project, the next logical step was to add a jump. It was basically the same idea as the horizontal movement, just with a seperate up/down momentumn variable that automatically pulled the player down if they weren't touching the ground, but that required me to create a seperate ground sprite, and that's when the project started to take shape, but first a quick diversion.
Since scratch doesn't support scrolling sprites beyond the border of the screen, a lot of platformers on the site are single-screen affairs. I always think back to games like Marshall, which also used scratch's "if touching colour" block instead of using hitboxes/hurtboxes or making all the interactable elements seperate sprites. Likewise, every level has the same criteria of touching the right side of the screen to advance to the next level. Now, Marshall was pretty popular, judging by it's 7 million views and 2500 remixes (a feature of scratch where someone can take an existing project, modify or add to the code and publish it onto their profile while linking back to the original, I guess the modern equivalent would be forking a project on github), and a lot of other games would copy and expand on it's formula (hell, I did a few myself).
But why not have large, unbroken levels that scroll? Well scratch has a lot of quirks that get in the way of this. Firstly, it doesn't have a camera like a lot of modern game engines, so you'd have to make the level sprite be the one that moves instead of following the player sprite as it moved, but that's mostly just a different way of thinking about how games work, the actual thing preventing you from using this kind of scrolling is that scratch has a lot of arbitrary limits. Firstly the afformentioned restriction on sprites scrolling off-screen, but also on how big sprites are allowed to get in the first place. While scratch does allow sprite scaling, it places a cap on how big the sprites can get. This project I made back in 2015 is a good example of this, it was an early attempt at making a racing game whose track sprite scrolled, but you can see it can't get big enough to scroll that much (there's a hundred and one other problems with it but don't worry about that). But not long afterwards I discovered a game called Xelokart, which (among lots of other things) was impressive because it was actually able to scale the track far beyond the typical limit! How did it achieve this? A very simple, but clever bodge. See, scratch's limit on scaling is relative, so if you create a sprite with a costume that is just one pixel, scale it up to the desired size, then switch to the desired costume, it keeps the scaling! I ended up using this technique to create my own fullscreen racing game back in 2019 as a swansong for my days on scratch (although I definitely flew too close to the sun by making it almost impossible to see upcoming turns due to how zoomed in the game was, in other words I made micro machines), before leaving the site altogether to focus on other creative ventures like the youtube channel (as well as school, since GCSEs were starting up around then).
SO, when making this new platformer I quickly decided to give it the same fullscreen scrolling, specifically having the level sprite move according to the mo variables in addition to the player character, but having the player move a very small amount on the X axis and having the level move a lot more. For some reason I initially decided to make all of the movement speed controlled by the size of the character, but later changed this to being the size of the stage (still kind of weird and results in the code being a bit more complex than needed, but did come in handy later on)
A quirk of my basic gravity system was that it resulted in a certain amount of jitter, which had been the case ever since I first used it. This comes down to how it's scripted (if not touching ground, go down, if touching ground, go up) but it was the best option I had 10 years ago and it'd been so long that it was all I remembered coming into this project. However, I decided to lean into it this time. It already was more of a bounce than a jitter, and it allowed you to go through any platform (say, touch one from underneath to be brought to the top) so I decided to design the entire game around this movement system I'd stumbled into.
In a lot of my earlier games, I'd pretty much just focused on programming the systems and mechanics, then put the bare minimum into the level design before working on more tertiary systems to boost the game's replay value if I really liked the idea. Fast forward to the present, and I've watched at least a couple of game design videos on youtube so I felt like taking a real crack at level design this time. The first level was meant to be a basic introduction to all the ideas I wanted to implement into the game; big platforms, small platforms, levels that require you to move in all four directions and thin platforms that you fall through. I decided to use the colour-based hit-detection since it was a lot quicker to implement and I was still working on this just for my own personal enjoyment. I then created a few more levels with ideas like climing up vertically, using the blocks to boost a big jump, taking big leaps of faith to get to the goal and a finally a series of tricky jumps with hazards in the way. Yes I quickly implemented the classic red blocks that kill you with one touch, at first just because I realised you could skip the entirety of the first stage by taking a tricky leap of faith, so I initially put a big red death block there, but later on decided to embrace the idea of skips by implementing these shortcuts into every level and placing blue blocks that could be passed through but changed a variable that kept track of if you took any of the shortcuts.
After a few days what had started out as a simple exercise in programming character movement had turned into a full game that I really enjoyed playing, so I set about polishing it up to a state I'd be happy sharing it to the world in. A classic staple of gamedev is that if you play through a game enough times while testing it, you are able to anticipate exactly how the character will move, exactly what the level entails and exactly how to beat all of them, after all, you're the one who made them! (I'm assuming this is why so many of the old british bedroom-coder games on our home-computers of the 80s were so difficult) I quickly noticed during playtesting that I'd often need to tell people where to go, but I obviously can't look over the shoulder of everyone who plays my game, so that's where the guide arrows came from, a very unsubtle way of nudging the player in a certain direction, or letting them know that there is a platform nearby that's just cut off by the screen (yes I made the same mistake of zooming in too far as I did in my last game). I also decided to create actual graphics for the levels, up to this point I'd just been using coloured blocks and a white background. I started off with a floating sky islands aesthetic, but it didn't make much sense for the character to move through these solid islands, so the next logical step was to make them all clouds, which also doubled as a small tribute to an earlier game I'd played with a similar aesthetic that I really liked, (this also is a really good example of the scratch single-screen-platformer, complete with walljumps, although it stuck out by having a well-told story too).
Around this time I also switched to making each interactable element it's own sprite (whose movement and size was tied to the main level sprite, and made the skip detectors completely transparent. Lastly, I added a parralax scrolling effect (basically just creating extra decal sprites that still move according to the main level sprite, just with an offest) It's a pretty basic effect from the early 16-bit era, but it still looks quite nice and is something I rarely saw in scratch games. By this point the level design was set in stone and I was just adding extra stuff for fun. I put in a simple HUD that showed your deaths and time played, but instead of taking the easy way of using scratch's built in variable display, I took the unnecessary step of creating unique sprites for the three numbers involved, and coded them to appear in accordance with the variable. I also added a small post-game congratulations/credits roll, with a little reward for players who completed the game with no skips or no deaths. Lastly, I added a cheats menu because why not. This started off for debug purposes (automatically setting the size of the sprites, allowing me to move the stage around during gameplay, etc) and later on also included my failed attempt at a dynamic jumping sound that raised or lowered in pitch according to your vertical momentumn (didn't really work so I threw it in as a cheat code). I was playing around with scaling because I wanted to try creating an easier difficulty where the "camera" is pulled back a lot further so the player can see more (during testing a lot of my friends complained about not knowing where they were meant to go, hopefully this fixes that issue), so I cleaned up my movement code to make everything relative to the size of the player sprite, which theoretically should allow the game to be scaled infinitely and still play the same (before some things like the jump height didn't scale so the game would move differently when zoomed out). The only thing left to add is a title screen, some music and an actual player sprite (I'd been using the default scratch cat sprite all the way through development), and then the game will be ready to publish! I briefly considered putting it out in itch since there are now tools that allow you to compile scratch projects to standalone applications for windows, macos and linux. But I figured this project belongs on scratch, so I'll probably just publish it on my old account as a little treat for those who still follow me there. The game isn't actually published yet, but it's functionally finished so if enough people nag me I'll upload it as-is and add in the extra stuff later on
So that was my return to Scratch GameDev after a very long hiatus! Will I make more stuff? Well right now my hands are full with my final school project, with any leftover time going to the youtube channel, so I wouldn't hold your breath. But I also really enjoyed getting back into the process, I didn't realise how much I'd missed the fun challenge of coding games until I'd done it again, so who knows maybe this will be the motivation to finally move onto a "real" programming language or another game-creation software like Gamemaker studio. Ultimately I have no idea what the future holds, but I hoped you enjoyed my ramblings!