Game Development, a.k.a. Why I Started Programming

I came across Game Programming Patterns by Robert Nystrom, and it got me wanting to make a game. In particular, the goal of making a game engine, and then making a game on top of my game engine.

If I were to trace way back to my early days, the reason I learned programming in the first place was so that I could make games, and then I didn't get around to making a game. Or...well...technically, I did make a few games on Scratch, but I always had the goal of making a "real" game using a "real" tech stack.

I was a pretty avid Scratcher, but I didn't consider anything I made on Scratch to be "real," since Scratch is a drag-and-drop visual language for kids. When I learn programming language theory, maybe I can build a strong case for why Scratch is a legitimate language ;)

Ah, Scratch. Back in my day...

I basically grew up on Scratch and will gladly defend Scratch as a worthy source of education. It’s friendly enough for young kids that they can get something working relatively quickly. At the same time, if they want to implement a mechanic, they have to figure out how to do it themselves (I was going to say "from scratch" but decided this was a tad cheesy), since physics, controls, and logic aren't offered as ready-to-use add-ons. One of the Scratchers that I followed back in the day, griffpatch, has started putting out tutorials on YouTube, and I'm envious of kids these days for having such a good resource but also glad to see that some of my favorite creators are still active.

If we're talking strictly about software, here are some niceities of Scratch that seemed utterly magical to me that sound pretty ordinary today (of course, when I dress these up in the "wow so magical" point-of-view of my younger self, I once again feel the awe of technology):

Cloud variables: Cloud variables were a special feature that you unlocked when you got promoted from “New Scratcher” to “Scratcher” by being active on the site for a good amount of time.

This was seriously high-tech to me back then. You mean to say, if I set this to a value, no matter how many times I reload the page, it’ll still be there? And other users can also see the same value?? And if they set it to a different value, you’ll see their changes??? Wow!!

Cloud variables were a thing, but cloud lists were not. So some people would find creative ways around this, by coming up with encoding schemes for lists.

The most common use case for cloud variables was for tracking high scores. With some engineering expertise, you could make real-time multiplayer games.

Serialization: Serialization was another thing that seemed super high-tech to me. Basically, the pain point was that every time your player refreshed the page or reclicked the green flag, all the state in your project got reset. This was fine for small projects, but some Scratchers built magnum opuses that weren’t practical to be played in one sitting.

Some Scratchers decided, what if we encode our game data in the form of a save code and give it to the player? The next time the player reopens the project, they just copy-paste their save code, and their game would be restored from the save code.

On Scratch, you could click “See Inside” on any project to see how it was built, and even remix it to make it your own. A pasttime was deciphering how the save codes were generated, in hopes of generating your own to, say, give yourself more gold coins.

Turbo Mode: In the descriptions of some projects, you’d see something like, “Run this in turbo mode for better results.” What they were referring to was an option you got when you shift+clicked the green flag, in which you could run the project in Turbo Mode, which was supposed to reduce lag.

When I read this section of Nystrom's book about tuning frame rate for games, the sidenote about turbo buttons finally told me where the "turbo" in turbo mode came from.

Broadcast Blocks: Similar idea as signals and signal handlers, events and event handlers, and the like. It's kind of interesting to read about how the broadcast block has changed on the Scratch wiki; I mainly used Scratch 1.4 and 2.0 but stopped using Scratch by the time 3.0 came out.

Cloning: When I learned about fork, it reminded me of cloning and all the memories of making particle effects and enemy spawning systems with those clone blocks. Although fork is not quite the same, I think clone blocks helped me with reasoning about parent/child logic.

Outside of software and game dev, Scratch also introduced me to some amazing animators, music producers, and creative writers whose work I enjoyed very much and remember to this day. I can go on and on about the non-technical parts of the Scratch community, the silly feuds and traditions that I look back on fondly, but that would take a long time. In short, Scratch played a significant role in shaping my interests, both technical and non-technical.

Good luck finding my Scratch username; I came up with jespiron solely to shed my Scratch identity.

Goodbye Scratch

By the time I outgrew Scratch and moved on to "real" programming languages in middle school, I didn't really find the time to dedicate to a game project, and then my interest shifted from game dev to general computer science.

Due to some outside influences, I adopted the belief that game dev was just play and that in order to reach enlightenment as a true CS person, the subjects worth learning were the ones rich in theory and math, or the ones that worked the systems programming muscle. There are voices online who reinforce the belief that "real programmers" must be well-versed in these subjects, and I was determined to become a real programmer.

I remember being extremely passionate about this before college, where I'd look for pdf copies of textbooks off of libgen.is, and I'd often take my laptop to the library during lunchtime, with a blue clipboard to hold the fat wad of printer paper that I always kept in my backpack (this was before I got the luxury of an Apple pencil + iPad). Some of the content I incidentally saw again in college -- I'd gone through the entire Computer Systems: A Programmer's Perspective by high school junior year, and I self-learned enough discrete math that freshman fall felt like review, though I was quickly humbled in the next semester.

It's a bit different in college when the subjects are prescribed as coursework; the fact that I now see them as "work" means I unwind with more physical or artistic hobbies. But when I remember how much I fought to find time to learn these subjects before college, it helps me maintain morale in taking my coursework seriously.

I still hold appreciation for these CS subjects, but I no longer think they're essential to the point where I must do it in order to be a true CS person. I also no longer see CS as my identity but just one of my interests. I've redefined my sense of purpose to be a lot more high-level and well-rounded.

Have I become a "real programmer"? I'm back to the view I held at the beginning, that a real programmer is just someone who makes what they want. 🕊️

This reminds me a lot of the quotes,

"Before I studied the art, a punch to me was just a punch, a kick just a kick. After I learned the art, a punch was no longer a punch, a kick no longer a kick. Now that I've understood the art, a punch is just like a punch, a kick is just like a kick." - Bruce Lee

"Before one studies Zen, mountains are mountains and waters are waters; after a first glimpse into the truth of Zen, mountains are no longer mountains and waters are no longer waters; after enlightenment, mountains are once again mountains and waters once again waters." - A Buddhist monk somewhere

(Insert pretty much any horseshoe diagram or bell curve meme here)

The quotes are just various ways of saying that you start off seeing the thing in its literal form, you get to the point where the thing doesn't look like a thing anymore, then you go back to seeing the thing as a thing. Technically, the basics I learned at the beginning of my CS journey were all I really needed, but then and again...I can't say that the me at the beginning of my CS journey was particularly well-equipped to tackle what I can today, so there was still some value in going through the journey.

Hello Again

Game development piqued my interest again last summer. Someone asked me how I got into programming, and I started to trace back, way back, and mentioned game programming. Upon being asked why I didn't make games anymore, I said, "I lost interest," but that didn't feel quite true.

It was also that summer when I wondered, When was the last time I was actively excited about programming? I already had this question for a while, but coursework kept me busy enough that I didn't think about it much.

The thought of making a game brought back the early joys of CS for me, that I started to entertain the itch. Great! I want to make a game, what next?

I decided that I'd start by making a game engine, since the design principles behind making a game engine don't become dated, and I've always wondered what went on behind a game engine. I feel like those lessons are more important to me than my ability to use any particular game engine.

I'm quite happy with my progress so far but am far from organizing my thoughts into writing. I'm also making no promises on when the next update will come out, but stay tuned!

Updates:

• 8.17.2023: ECS implementation complete, now to plan out the components and systems...
• 8.25.2023: Instead of tacking on updates here, I might just make a master post when I'm ready (end of semester? year? optimistic question mark). I've mostly worked out the specs and how of my project, but will have to think through what exactly I want to convey. There's a lot of quality resources about software design patterns already, though I suppose there's no harm in putting down my thoughts on it. In any case, I've got myself plenty for the next few months and shall become a monk. Fetch wood carry water 😹
• 11.24.2023: The bare minimum of what I want is done, so I'll say the engine is 80% there (graphics, event handling, player input, collision detection, etc.)! Well, I didn't define the remaining 20%, but I mean that it's enough to start whatever I want to make. I can start making my game, and whatever else I need from my engine, I'll add as I go.
• 12.24.2023: I self-documented my progress and shelved my game engine for now. It was good for learning the basics of a game engine, but for actual game development, I'm better off using a more mature game engine. I'm diving into open-source game engines next!