Brian Norman's Blog

2022-12-25T00:00:00Z

One of my New Year's Resolutions this year was to learn game development (again) and try actually publishing some games. This post is a look back at how that went.

Dear Diary

Back in December 2021, I randomly stumbled across Yahtzee's Dev Diary on Youtube, and that playlist really struck a cord with me for whatever reason. When coming up with my plan for 2022, I wrote what would go down as an overly ambitious north-star goal:

"I want to spend 365 hours doing gamedev this year"

Lofty!

My desire to learn game development goes way back, playing a large part in why I learned to code in the first place. Obsessed with video games since I was old enough to use a mouse and keyboard, I always thought it would be cool to actually make my own experiences. I expressed this interest to my friend Wesley who introduced me to two people (Cole and Sunny) who were also moderately interested in programming/gamedev, and we hit it off! This was back in 2014, and that group would eventually become Cobresun.

Eight years later and we hadn't really published any games yet, so I figured I'd better take the opportunity now that I was done with school to get my feet wet and learn.

Inspired by Yahtzee, I really wanted to have my own "dev diary" retro on the year of gamedev, which is what you're reading right now. It didn't go as planned, and I released 5 of the 12 games Yahtzee did in a year, but he's made games before, and I'm a noob, so I'm still pretty happy with how it turned out!

How It Went

If you're curious, I actually only spent ~135 hours this year working on games, but all in all, I'm extremely thrilled with that!

Obviously the first half of the year was much better for me than the latter half (as New Year's Resolutions tend to be), but I'm still proud of the games I made this year!

I learned a new game engine Godot for these games, which was a decision mostly made arbitarily around the idea that an open source engine sounded like a good idea. I'm grateful I chose Godot, the community is really cool, the engine is a delight to use, and appeals to a beginner like myself.

Revisiting a Classic: Sweet Tooth

Dec 26, 2021 -> Dec 29, 2021

It all started with Sweet Tooth.

Back in 2015 Cobresun decided to host our own Game Jam (a hackathon for video games), where we'd each made a game in a week (this was during winter break in highschool), and we'd get each of our younger siblings to review the games on some criteria, score them, and then determine a winner. I made the original Sweet Tooth in Python and Pygame, which at the time was probably the most ambitious coding project I had ever attempted.

I didn't win !! Sunny won for his game Llama Run. His colourful art appealed to the kids judging the games 😜.

I decided for my first stab at learning gamedev, I'd take the project I was still most proud of (Sweet Tooth is a genuinely fun game with a core gameplay loop I've yet to surpass), and update it in Godot. I had done the Godot tutorial before this, but really wanted to learn the engine by avoiding Tutorial Hell and instead getting my hands dirty with my own projects, so that I could feel attached and proud of the work. This turned out to be a great idea.

What I did with this reboot of Sweet Tooth was add elements like sound effects, particle effects, and generally made little quality of life improvments that really add a ton of polish to a game. Also actually playable version with a web release! Turns out, this goes a long way in making people play your game... (note, a lot of these quality of life improvements were added later in the year as prep for the GMTK 2022 Game Jam, which I'll talk about later).

Entering the Matrix: Cobresun Metaverse

Jan 17, 2022 -> Jan 28, 2022

For my next game, and first original game idea since 2015, I decide to learn some multiplayer with the Cobresun Metaverse.

Okay fine, so not exactly a game. But that would have been too much pressure! I wanted to learn multiplayer as a sort of warmup for my next game (another unoriginal idea), and also learn pixel art.

I dug around online for the best beginner tool for pixel art, and came across Aseprite. Turns out, Aseprite might as well be one of the most well-designed, delightful apps I've ever used! (I do wish there was an iPad app).

I learned this week just how hard pixel art was, which wasn't exactly a surprise, but it was still cool to peel back the curtain on that gian black box in my head. As you can see from the screenshot, I didn't do a great job with the artwork here, but the fact that it was all original art was really exciting.

Better With Friends: Fadeaway Reboot

Jan 28, 2022 -> Feb 13, 2022

Following up the tech demo that was Cobresun Metaverse, I decided to take another classic from the Cobresun troves, and give it a fresh multiplayer spin. Enter, Fadeaway Reboot.

This was a 4-player co-op zombie survival game where you try to rack up the kills, and see who the last player standing is. The catch? You can't see in the night... except for when lightning strikes!

This game is the multiplayer reboot of the original game Fadeway which Sunny made for a Cobresun Gamejam in 2017.

This game was particularly fun to develop for because I had spent some time getting acquainted with Godot at this point, and was starting to go off of muscle memory instead of revisitng tutorials to make everything.

Every week while working on these games, I'd show updates to Cobresun during our weekly calls (which we have to discuss the latest movie in our Movie Club). I'd solicit feedback and get the boys to play the games, which was a lot of fun, and definitely a habit that made me work on what mattered every week, and avoid bikeshedding. It was also a satisfying feedback loop demo-ing the game every week, pushing me to work more.

I did give up on this game before it was fully finished, because while the ideas were flowing for fun features, the multiplayer was making the game unweildy. If I were to go back in time, I'd probably make the game fully in single-player just to get a good grasp of the core gameplay loop and determine the minimum viable set of fun features. I'd also flesh out a bunch of levels, and generally just make a good single player campaign. Maybe 10 or so levels. After that I'd have hopefully gotten a solid system in place with the object oriented nature of the code, different enemies, weapons, etc. Only after that would I consider adding multiplayer.

Using Work Hours for Fun and Profit: Seat in a Seat

Mar 18, 2022 -> Mar 22, 2022

I was discouraged by Fadeaway and it's inability to progress through multiplayer issues, but when the opportunity arose to get paid working on a game, I had to take it, and thus Seat in a Seat was born!

A big part of the desire to learn gamedev this year was to keep me entertained but also mentally stimulated outside of work, so it is a little ironic that my favourite game of the year was a game I made for a Hackathon at work! Hyewon Kim, designer at SeatGeek (where I work), designed this game with me, and it was such a pleasure working with her on this project. Sunny and Cole also helped debug an issue I had, which resulted in much smoother gameplay.

We went all out on polish for this one, a beautiful vector UI, music, sound effects, etc. My biggest regret was not making it a web release from the get-go, which prevented most people from playing the game, and probably hindered out chances of getting a good review in the hackathon!

Still though, just working on a game with people I enjoy working with was such a pleasure, it made me realize that if I can, I should always find other people to colaborate with (assuming they're as invested in the project as I am).

untitled unmastered.

For the next couple months I worked on a game I am nowhere near releasing, but mostly writing and learning about storytelling, which was a lot of fun! Did some gamedev here, but I'd say nothing too substantial unfortunately...

Sleepless Weekend: Orc Onslaught

July 15, 2022 -> July 17, 2022

There was a drought in terms of released work since Seat in a Seat, so when the opportunity came up to work on a game for my first public game jam (GMTK 2022 Game Jam), I decided to jump at it! The result was Orc Onslaught.

My friend Ray has spent the pandemic learning how to code (he's a nurse), and I've been trying my best to mentor him through that. I had mentioned the game jam to him and we thought it could be fun if he joined Cole and Sunny and I on this project, so it was one of his first projects in general, which is such a cool project to cut your teeth on!

Working with these guys over the weekend on this game was one of the best experiences of my life. Nothing will quite top Cobresun collaboration vibes when we're in a high pressure experience, boucing ideas off of each other, and me in awe of the sheer talent and genius that Cole and Sunny can whip up on a moments notice.

In the final moments of this game's balancing we ended up making it too difficult, and we ended up getting a lot of players in the game jam judging period commenting this!

It was so cool for anyone to have played a game I worked on, I was too excited about that fact to even really pay attention to the criticism!

Some lessons here:

Release for web if you want people to play your game. Before the gamejam I practiced by converting the other games to web (Sweet Tooth and Seat in a Seat), which was a life saver.
Playtest, playtest, playtest! Have other people other than the devs playtest !!!
Polish is all about sound effects, music, and particles. It's kind of hilarious how much these things make a difference.
Okay polishing is nice, but the core gameplay loop has to be fun. We spent a lot of time going back and forth on this for Orc Onslaught, since the basic template of a tower defence game is nice and all, but we were really complicating it with the addition of a roll of the dice and randomness.

Thats all Folks!

And that was that! I unfortunately had a very busy and distracted second half of the year, so I didn't release any more games after Orc Onslaught (admittedly a weekend of that many hours of gamedev definitely hit me hard, and I needed a break).

I really hope next year is another great year for gamedev for me, in which I'd like to return to making small proof of concept games with tiny but fun gameplay loops, and sharing them with Cobresun every week and eventually releasing them.

2021-03-21T00:00:00Z

This brief article will be some collected thoughts and learnings from making Community: Required Reading with my friends. If you haven't checked it out, I recommend it! It's a website that collects every parody and pop-culture reference from every episode of NBC's hit sitcom Community, organized by episode.

History 101

The idea was born on January 4th, 2021. My friend Sunny Nagam and I were doing some technical interview prep together, since we both had interviews coming up. As is usually the case with the two of us, any time we get in a call, it never ends up just being for what we initially set out to do. Very quickly we devolved into one of our favourite hobbies, coming up with random ideas for things we'd like to eventually do.

I can't remember exactly how we got there, but eventually I started sending him some assorted works of Lynn Fisher's. She's a creator I admire quite a lot, because her projects are interesting, creative, technical explorations of her favourite things. From cataloguing all the apparel David Rose wears in Schitt's Creek, to an exploration of three-letter airport codes around the world, the only common thread between all her projects are the love she has for the content.

Simultaneously during this call with Sunny, the topic of Vue.js came up. Another member of Cobresun, Cole Adams, happens to be a full-throated evangelist for the web framework, and his influence has spread through Cobresun like wildfire. Sunny had the opportunity work with Vue on a project he and Cole collaborated on for school. Sunny was now suggesting that I learn Vue.

One thing lead to another, and all of a sudden there I was coming up with the idea for this project while chatting with Sunny.

Lesson #1: The Adjacent Possible

There's this concept I love called the "Adjacent Possible" which I first came across in Cal Newport's So Good They Can't Ignore You a few years ago. The basic idea is that if you've got a pool of chemicals sloshing around, you may or may not have all the ingredients necessary to create a new compound. But let's say you periodically find new chemicals, and add them to this pool. Theres a chance that eventually, maybe on the 3rd or 10th or 100th addition, you'll eventually add something that is the "final piece of the puzzle" needed to make a compound.

The adjacent possible in Newport's book was talking about new innovations being created. It's the answer to the question: Why do many of the great scientific innovations not happen for centuries, but then all at once within a decade or so, multiple scientists from around the world come up with the same idea? The explanation is the adjacent possible. All the ingredients for that scientific innovation was gathered by humanity over centuries, so once the final puzzle piece is in place, it's only a matter of it being sloshed around enough before some people connect the dots.

I think that any creative project has some element of the Adjacent Possible to it. Heres just a few of the ingredients that had to come together here for this project to get made:

I am relatively new to web development, having only learned React.js at the beginning of 2020 for a now delayed project that the final member of Cobresun, Wesley Tang, had asked us to work on. Nevertheless, knowing React helped me visualize the technical details of Community: Required Reading in my head while discussing it.
I've been a fan of Community since 2011 and have rewatched it many times since (the latest rewatch being April 2020).
Sunny and I happened to be calling because of interviews.
Cole had to shove Vue down our throats for months before it finally found it's way into one of our projects.
I've been a fan on Lynn Fisher's work for a few years (first found her through her various site redesign projects) and I happened to have seen the David Rose project a few weeks before this call with Sunny.

My point is, you can't underestimate the adjacent possible. I am not entirely sure what the lesson here is. Maybe it's to consume lots of great content, have lots of great calls, and when an idea strikes, give it a serious consideration before dismissing it?

Lesson #2: Parallelizing Work and Task Boards

Literally that night, on January 4th, 2021, after Sunny left for dinner, I got started coding the website. I began with Vue's tutorial and documentation, optimizing for quick results and not necessarily good code. The first night was just some Vue boilerplate (Hello World of course) and hosting that boilerplate on Netlify, so Cobresun could quickly look and provide feedback on the latest build.

Day 2 (Jan 5th) was creating the JSON that would store everything, defining some Vue components for the episode grid, search bar, episode pages, and this was also the day Sunny joined me in coding, implementing routing and making the cards pretty.

One of the key lessons I've learned over the years is how important parallelizing tasks can be. We started by separating out the code such that Sunny and I could code in parallel on different files, so we wouldn't have to deal with merge conflicts. This also made for an easier to understand and debug codebase, which helped onboard new developers. As a bonus, we all just pushed to master to avoid the overhead of reviews taking too long 😅 (Was this the best idea? Who knows?!)

Additionally, we separated out what work was left to do using Github Projects Kanban board, which ended up being extremely useful as more members of Cobresun started working on the site. You have to get the whole team on board with this system to work like a well-oiled machine. For example, Sunny was terrible at keeping the board up to date with his work (sorry for calling you out publicly bro!) but we were small enough that I could just update it for him. I think getting this system to be a part of the process for everyone is the key to taking advantage of it.

Still some tasks in there if anyone wants to contribute 😊

On Day 3 (Jan 6th) I worked on more of the code, and started importing data into the site by manually scraping the Community Wiki. Sunny was taking a break this day, which was probably a good idea, but I have this constant fear when working on a new project that I need to work on it practically non-stop until it's done if I want to ever finish it, otherwise I'm prone to dropping it halfway... This is something I'd like to work on.

Day 4 (Jan 7th) was a big day, because Cole returned from a ski trip, and was overjoyed that Sunny and I had started working on a Vue project! He asked if he could help, and that handy Kanban board I mentioned earlier came in use. We could simply send him the link, and he was off to the races! This was the day Sunny added the amazing navbar, styling, and some bug fixes. I added the remaining references. Cole added some great UI improvements like season collapsing and custom CSS on different screen sizes.

Day 5 (Jan 8th) was around the time we started heading for the endgame. We had animations, sizing, and other minor improvements. It was on this day that we decided to do a launch on January 10th, the last day of our Winter Break before Sunny, Wesley, and I headed into our final semester of University. The reasoning was simple, I just didn't want to overwork myself once the semester started, and I would prefer if I could be fully emotionally separated from this site.

Day 7 (Jan 10th) came the final necessary code changes before launch. I sourced and added all the images for each episode, which Cole made some optimizations to for size. Wesley updated the About page with a disclaimer, and created the logo. We created a Twitter and Reddit account for Cobresun, and added a Kofi to accept donations should any kind souls decide to donate.

That night we all got on our weekly call, and then we launched, by sharing to Twitter and Reddit! 🎉

Lesson #3: Deviating From the Plan

The original idea was deceivingly simple on paper, so we jumped at it. The final version of the website you can now visit is pretty much exactly how we wanted it to look and function when coming up with the idea in call, with one notable exception. We originally wanted hand-drawn images for every episode, that were of pop-culture references in each episode. After some debate later in the week as we neared completion of the site's functionality, we decided that would be too much work and we'd never launch anything if we tried to draw 110 individual pieces of art. Thank goodness we decided against this!

This amazing drawing by Cole was for S1E8: Home Economics

I drew this football for S1E6: Football, Feminism and You

The Reaction

We were pleasantly surprised by the positive reaction we got. My expectation was that we'd get exactly four visitors (each of us in Cobresun) and maybe one more if my brother opened the link... We turned on Netlify analytics for the first month, and this was the result:

That sharp drop-off was the giveaway that we did not have a viral hit on our hands 😆

We're fairly positive the usage of the site has tapered off, with a few visitors a month now, but I'd like to think at least one person out there is using the site regularly for their latest watch through of the show 😁

Emotional Consequences of Broadcast Television

In the end, the week we spent making this site will, looking back, be one of my favourite weeks that Cobresun had. I spent 25 hours that week working on the project, which is not bad all things considered. The result was a really fun website I genuinely enjoy clicking around and scrolling through!

A quick recap of the lessons learned:

The adjacent possible will lead to serendipitous project ideas, don't dismiss them
Get started right away, and without overworking, try to keep at it consistently until an MVP is done, so you don't drop the project unfinished and un-launched
Parallelize the work in code to avoid merge conflicts, and have a lot of trust in your team
Kanban board of up-to-date tasks to work on is esssential
Be okay with changing the original plan to make your life easier, as we discovered, people will likely not notice and not care
Know when to call it, and make a big deal out of launch day, because it's fun!

Now I'm itching to do another Community rewatch...

2021-01-02T00:00:00Z

Watching videos is one of the most ubiquitous activities on the internet, but few understand the technology behind it. It would be nice to understand a little of whats happening under the hood, and I'd like to start with a look at HLS (HTTP Live Streaming), a streaming protocol developed by Apple in 2009 that is used by the majority of video streaming sites today.

A World Without HLS

In a world without HLS, there would be a lot of buffering. Not only during the video, but the time it takes to initally load the video once you click play would be excruciatingly slow (scaling with video length). This of course is dependant on the internet speed of the user, but because most countries have slow or flaky internet, watching videos online would be a luxury few could afford.

There would be no dynamic changing of video quality while watching, which you might not think is a big deal, but having to change the stream's quality constantly and then re-start download every single time your internet is flaky would be a nightmare given what consumers have come to expect.

If this world sounds familiar, its because it is, we used to live it! Internet videos used to be a lot less accessible and much more of an ordeal than they are today, and we have Adaptive Bitrate Streaming to thank for that.

Adaptive Bitrate Streaming with HLS

Note that HLS is not the only protocol in this space, the other popular option is MPEG-DASH. Both are examples of Adaptive Bitrate Streaming protocols. Here are a couple of tricks up their sleeves that make modern video streaming possible:

1. Fragmented Stream

Imagine the wait time for every video if you had to download the entire clip before the player would start playing the video. That might sound fine for a 30 second cat video, but imagine a Netflix movie! One of the great innovations in the video streaming world was the idea of playing a video without having to download the whole video to a user's device.

To experiment with this feature, I created a little archive of my own videos, and below is a screenshot of the network responses that occur when hitting play on one of the videos.

The network responses once the play button on the video is clicked.

The initial .m3u8 file downloaded is an M3U playlist for the video. An M3U (MP3 URL) playlist is a file that describes a list of media files, including where they can be found (their URL). HLS works by first segmenting the video into .ts files, which are Video Transport Stream files used for compressed video data. A sequence of .ts files numbered in ascending order represent the full video. The .m3u8 file lists .ts files and where they can be found, so if the client has the .m3u8 file they'll be able to reconstruct the whole video!

Example of .m3u8 file from apple docs.

You've probably noticed when watching Youtube videos that the seek bar has an indicator for how much of the video has already been downloaded ahead of the current timestamp. This feature is noticable when the internet connection goes out while watching a video, and the playback stops abruptly once the seeker reaches the furthest point downloaded.

This "pre-fetching" of video is done with Adaptive Bitrate Streaming, where .ts files ahead of the current timestamp are constantly queued up. An additional side-effect is that if users frequently open videos and then exit out of them without watching the whole video, or maybe skip around different timestamps, the entire video file need not be downloaded, saving plenty of bandwidth!

2. Different Bitrates

I mentioned earlier that one of the benefits of HLS was video quality dynamically changing as the video is viewed. This works via HLS inspecting the bandwidth on the user's device, which is why HLS is not the only streaming protocol that exists. When Apple created HLS, they built out support for all the Apple devices for the Safari web browser and Apple TV, but HLS has been adopted widely across the board. HLS supports intelligent switching of streams based on bandwidth changes, meaning the video won't stop playing when a user's internet slows down, instead a lower quality .ts file is downloaded so the playback is un-interrupted.

The example .m3u8 file shown above is just one of the various .m3u8 files a video will have in HLS. The reality is that there is a master .m3u8 playlist, which has links to many .m3u8 files each at a different bitrates (or video stream quality). HLS intelligently switches between the .m3u8 file to download from, and in turn downloads the .ts files from that .m3u8 playlist.

The real master m3u8 playlist of the Canon Ad video I showed the network response of above.

You can see the various bitrates in the titles of the m3u8 files, for example 0.4Mbps which corresponds to the 480x270 video, versus the 6.5Mbps video which has a resolution of 1280x720.

Demystifying Streaming

I wanted this post to be a brief non-technical introduction to HLS, so I won't go into how the different components actually work to make it all possible. I'll leave some of that magic intact 😉 (or if you're still curious, the apple docs do a good job explaining).

I hope this brief intro was enough to get you curious the next time you watch a TV show on your Mac in Safari, or a Youtube video on your Android device! The full list of usages and supported players can be found here.

2020-11-22T00:00:00Z

I decided to redesign my personal website from scratch (you're looking at the new one) and this first post is a little explanation as to why. I'll first go over some of the technical reasons, and then follow it up with the more aspirational.

Technical

Purely from a learning point-of-view, it's fun to learn new technologies and experiment with them! The website I've been running for most of 2020 was itself a React.js redesign of my 2019 website (static HTML and CSS).

That beautiful drawing of me was done by my friend Wesley Tang

I needed to learn React this year for some projects, so practicing it on my own website seemed a fun way to personalize my learning. This was not a bad idea, I learned a lot about React, those projects went well (or nowhere), and my website worked just fine.

Once in React, you know I had to add night mode with hooks (however extraneous) 😎

The problem was React was not the best tool for the job. For a website that hosted an About page, a Portfolio of projects, and a list of books I've read, it had a pretty long build time! It's a classic case of seeing every problem as a nail when holding a hammer. I'm not saying there's anything wrong with using React for a simple website, but it should be dependant on the use-case. I don't think I'd hear much pushback if I suggested "We probably don't need Electron for our company's portfolio page!"

I ended up switching to 11ty for the current incarnation of the site (at the time of writing). I don't have much to say about why and I can't claim to have done much research on the subject before deciding, but what I can say is that my build times are shorter! I also enjoy the simplicity of writing posts in markdown, although I'm still getting used to the syntax Shopify Liquid is... interesting).

Another switch worth noting is the switch from Firebase to Netlify for hosting. I'd argue this is probably the better example of my previous point about the hammer and nails. Firebase was definitely overkill for my website, and the fact that I can now have new builds deployed with a simple push to the main branch is exciting! I could have automated deployment with Firebase using Github Actions, but I enjoy the reduced friction and boilerplate that Netflify comes with. Connecting the site to my repo and having it build 11ty without any config was a magical setup experience.

The UI for this site was my best attempt at stealing the wonderful design of Aaron Shekey's personal site, who I recommend everyone check out! (Update April 2021: His website no longer looks like the one that I drew inspiration from, but still check him out!)

Aspirational

I didn't mention another big reason for switching the website technology, which was to support friction-less blogging. One of my goals going forward is to write a little more publically; about my learnings, my thoughts (I'll try and refrain from inflicting my views upon the world too much) and my goals. I see this website redesign as my public commitment to writing and putting myself out there more.

Writing more helps with decision making, thinking clearly, understanding something deeply, generating more ideas, and just getting better at the act of writing itself.

This first post should serve as a sort of template of what the writing on this site may look like, a mix of personal and technical anecdotes, roughly in the same ratio (all subject to change!). I'm not a technical authority by any means, so I won't pretend to be. These posts are more like a public journal for myself, which others may or may not find useful. Even if nobody reads them, I think I'll get value from writing them. Beyond practicing writing, these posts serve as little note-to-selfs for me to look back to (now I'll hopefully avoid unnecessarily switching back to React for this site a year from now!).

I chose to put this writing on my own static website, as opposed to a Medium blog or something, because I like the idea of decentralizing the internet, and operating outside the walled gardens of big social media companies. On this site there is no content moderation (not that I'll be sharing anything controversial 😅) and no ads!

2020-01-17T00:00:00Z

I just launched v1.0 of WeightLess today after 3 days of working on it, and I thought I'd reflect!

This was the first app where I had a Figma design first before diving into code, which was epic! Knowing where you're going makes it much faster to get there.

A lot of the code is directly ripped from another similar project, so the process went by super quick since I had experience.

There's a lot more I wanted to add, but in the spirit of quick iteration/feedback, I released an MVP. This was great because I got super useful and actionable feature requests I hadn't thought of!

Tip: leave every day on an interesting solvable problem for the next morning, so the activation energy to get back in is low