My first game on Scratch

I decided to take the CS50x course (on edX) to cover the basics of computer science, and what better way than with this legendary (free to take) Harvard course.

CS50's Introduction to Computer Science

I already know programming. I've been making small projects for years (but sadly very rarely finishing them), but after a couple of years away of code one can get a little rusty.

That's why I'm taking CS50, to really cement my basis and improve on my current skills.

The first week (Week 0) introduces Scratch, a visual programming environment where you can make 🕹️ games with simple drag and drop blocks.
About Scratch

It's probably won't blow anyone's mind, but I'm satisfied with the end product:⚽️ 🥅 a soccer penalty shooter game.

I don't know if you ever felt that you could go on forever making small twiks and changes, but it gets to the point you have to trace a line (ideally you have a clear scope before even starting, that wasn't my case tho) after two sleepless nights I felt it was good enough

TLDR; here's my game: scratch-vs-goalie

scratch.mit.edu

What I learned

SRP for the win

Scratch is simple, you have sprites and make them do stuff with blocks of logic, 🤓 the good old stuff: variables, conditionals and loops. But it can get complex and messy pretty quick (as your logic grows).

To not get overwhelm and lost in the chaos is a good idea to split your logic in small, easy to understand, bits of logic, that is, functions (in Scratch are called Blocks).

Single Responsibility Principle (SRP), (Check SOLID principles) says that your blocks of logic (functions) should only have one responsibility or job.

By adhering to this principle, code becomes more modular, easier to understand, and less prone to errors.

If you can't read and understand your block at a single glance, it's probably time to split it into smaller parts (good variable names are also important).

Logic rules over all

As I mentioned earlier, code isn't stranger to me, but sweet modern JS and Python can really spoiled you and your problem-solving skills 😅
At the time I have little JS project cooling in the window 🥧🪟 where I use a lot of async programming (promises) and reactivity (using Svelte), then Scratch is so basic (not a bad thing) that your variables are either text or numbers (where are my Booleans!!😱)
So I had to water-down my logic to think in the basic building blocks of programming.

Take your time to save time

"If I had eight hours to chop down a tree, I'd spend six hours sharpening my axe." - The honest Abe.

Confident in my "I know programming already" went head on to start building the game without even looking at any documentation.

I honestly thought it would be finished in 2-3 hours max.

It probably took 4x that 🫠.

Part of the problem is that I also didn't take the time to define a scope (the start and end) of what I was going to build.

Mid thru the first day it wasn't fully convince with what I had and ended up adding a lot of stuff and that force me to change my code to make it adequate for the new logic.

I felt so silly with myself 🤡 (like Aaaaghhh 🤦) when I found blocks for emitting and listening to events, that changed my horizon of possibilities and made me increase the (loosely defined) scope I had a little (another day of work).

Conclusion

In the end, if I had to do it again it would probably took me half the time, or if I were to spend more time I know (now) how I would like to expand it, but would take the time to read thoroughly the docs so I don't miss any other feature gem before starting.

Can't leave the code here cuz it's made with blocks, but you can check it on Scratch and make yours, too.

It was fun for me, I'll appreciate if you try it and leave a comment.

Tell me

What would you do in my place?

• Hack-a-thon it
• The shortest MVP possible
• Took my sweet time
• Something different