Forem: Bijan Boustani

Recreating Breakout for the Web

Bijan Boustani — Mon, 23 Nov 2020 14:46:23 +0000

Last time, we took a look at creating a web version of Pong, the classic Atari game. Here is an animation of what we ended up with:

Pretty cool! It's a fun game to play, even after all these years. And it was even more fun figuring out all the little things that made Pong so compelling.

In this post, I'll share some of the steps I took to adapt the Pong implementation into Breakout.

The original goal for these blog posts was to share step-by-step tutorials of how to recreate classic games. But the intent has evolved into sharing some interesting notes, ideas, and takeaways about the process of building these games.

⏳ tl;dr

In the last blog post, I buried the links to the playable demo and the source code all the way at the bottom of the post. It was my devious intention to force everyone to take hours of their precious time to scroll through my ~~shoddy~~ writing. This time, I'll link to them here in case you want to try the game out before reading on.

🕹 Playable Demo
💻 Source Code on GitHub

🛸 Why Breakout?

After working on Pong for a while, I was dying to move on to a different game genre. I've always wanted to learn how to create platform games like Super Mario Bros. and adventure games like The Legend of Zelda. But I decided to try Breakout for a couple reasons:

Breakout was my favorite Atari game. I grew up during the Nintendo era of video game history, so the Atari 2600 console was a little before my time. But games like Breakout felt timeless in their appeal. I also remember being blown away by some sort of "fancy" Breakout version in the arcade. I only recently found out that was a game called Arkanoid.
I already had most of the core components of the game figured out like the ball, paddle, and game window. With the basic mechanics in place, I'd be able to focus on other fun features like particle effects, pixel art, animation, music, etc.).

🤔 What's Interesting About Breakout?

Breakout consists of similar elements we saw last time like a game window, a paddle, and a ball. While Pong was meant as a two-player game, Breakout could be played solo since the objective was to break through the rows of stationary bricks at the top of the screen.

Beyond the gameplay itself, Breakout has an interesting history. Before Steve Jobs went on to found some company called Apple, he worked on Breakout at Atari. The story goes that he would invite his friend Steve Wozniak, who worked at Hewlett-Packard, to help him design and build the game. I find it fascinating to think that Breakout had some influence on the design of the Apple II computer, given its place in the history of computing.

If you're interested in reading more about this, the Breakout Wikipedia entry is a great place to start. And there are some fun videos on YouTube like Before Apple: Steve Jobs at Atari from Gaming Historian.

But what's most interesting to me about Breakout is how we can layer features and "game feel" elements on top of the simple core mechanics.

🤯 Game Feel and "Juice"

When I started working on a Breakout implementation, I knew I already had most of the features I needed for the game window and the paddle and the ball. You can see my previous blog post for an overview of how I implemented those features.

I knew I'd have to figure out how to implement the rows of breakable bricks at the top of the screen, but one of the first things I wanted to do was add a "screen shake" feature. When the ball hit one of the bricks, I wanted the window to shake to give the feeling that it was an impactful collision.

A screen shake is one of those features where you kind of don't notice it's there, but you can "feel" it when you play. It's used commonly in games, but proved surprisingly hard to find for browser games.

While looking for resources about how to accomplish this, I stumbled on this talk called The Art of Screenshake, and I became fascinated by this idea of adding seemingly small details to a game that add up to a lot in terms of game feel.

"Just fill your game with love and tiny details."
Jan Willem Nijman

This guided a lot of the work I ended up putting into building Breakout. In addition to the core game mechanics and a screen shake, I added things particle effects, pixel art, and music to make the game more fun and appealing.

For more on the topic of Game Feel, there's also a great video from Game Maker's Toolkit called Secrets of Game Feel and Juice.

🔄 Implementing a Screenshake

So how does a screenshake work? Thankfully we're working with a simple 2D game (as opposed to 3D or VR), so we only need to worry about moving the game window and then putting it back to restore its original position.

We start with our rectangular game window that's rendered with SVG. I've been working with the Elm programming language for these games, so I started with a type and set some initial values.

type alias Window =
    { backgroundColor : String
    , x : Float
    , y : Float
    , width : Float
    , height : Float
    }

initialWindow : Window
initialWindow =
    { backgroundColor = "black"
    , x = 0.0
    , y = 0.0
    , width = 800.0
    , height = 600.0
    }

The x and y represent the top left position of the game window. What we need to do is shift the x value to move the window left and right, and shift the y value to move the window up and down.

Then, after we shift the game window out of place, we restore its position back to the original position at (0, 0). Its kind of subtle if you don't know to look for it, but obvious once you see it. Here's what it looks like with the game elements in place so the window shake is visible:

If you go play the game in the production environment, you can actually click anywhere in the game window to simulate the screen shake feature.

I used a random number generator (which can be surprisingly hard to work with in Elm) so the screen shake didn't seem so predictable or jarring. And it does add a lot when the ball collides with a brick to trigger a screen shake.

If you're interested in learning more about screen shakes and more involved implementations, there's an amazing series of talks from the Game Developer's Conference called Math for Game Programmers. One of the talks is called Juicing Your Cameras With Math and it's really fun to see the code you can use to implement your own amazing screen shake features.

🎉 Particle Effects

Next, I wanted to add some particle effects to the game. Particles are usually things like fireworks, explosions, smoke, etc. I already had the screen shake working, but I thought it would be cool to create an explosion of particles when the ball collided with a brick.

I can't take credit for how awesome this feature looks, because I used an existing Elm package that makes these kinds of particles easy to work with. elm-particle is a package from Brian Hicks, who not only organizes the yearly Elm conference called elm-conf, but is also the nicest person you'll ever meet.

Here's an animation that shows what the particles look like during gameplay:

You can tinker with all sorts of settings for the particles. I ended up spawning ten small particles from the top left of the ball whenever it collides with a brick. In addition to the position, you can also tinker with things like how gravity affects the particles, how quickly they move and rotate, and how long they last before going away.

If you're interested in seeing more of the specifics of how the particle effects are implemented, check out the Breakout.elm file in the source code. The elm-particle package documentation also has some fun examples of how to use it for fun things like water and fireworks.

🎨 Assets and Pixel Art

For the Pong game I worked on, all the elements of the game were just based on simple shapes. So SVG rectangles were sufficient to represent things like the game window and the paddles and the ball.

But for Breakout, I wanted to incorporate some pixel art assets into the game to make it look a little nicer. I ended up using an iPad App called Pixel Studio to create the assets, but you might also want to check out Aseprite if you're interested in creating pixel art.

So instead of using Svg.rect to create a rectangle, I used Svg.image and linked to the static assets in the repository. The viewBall and viewPaddle functions use familiar attributes for the size and position, and also use the xlinkHref attribute to pull in the pixel art images.

viewBall : Ball -> Svg msg
viewBall ball =
    Svg.image
        [ Svg.Attributes.xlinkHref "/images/pixel-ball.png"
        , Svg.Attributes.x <| String.fromFloat <| Util.Vector.getX ball.position
        , Svg.Attributes.y <| String.fromFloat <| Util.Vector.getY ball.position
        , Svg.Attributes.width <| String.fromFloat ball.width
        , Svg.Attributes.height <| String.fromFloat ball.height
        ]
        []

viewPaddle : Paddle -> Svg msg
viewPaddle paddle =
    Svg.image
        [ Svg.Attributes.xlinkHref "/images/pixel-paddle.png"
        , Svg.Attributes.x <| String.fromFloat <| Util.Vector.getX paddle.position
        , Svg.Attributes.y <| String.fromFloat <| Util.Vector.getY paddle.position
        , Svg.Attributes.width <| String.fromFloat paddle.width
        , Svg.Attributes.height <| String.fromFloat paddle.height
        ]
        []

Mozilla's Developer Network (MDN) is great for looking up how to work with SVG elements and attributes. And then it's just a matter of translating it into Elm using the elm/svg package.

🎮 Updating the Game Platform

I ended up spending some time creating a new back-end for this project as well. I had originally built Pong and used a tool called Parcel to bundle the project. But I ended up running into trouble as soon as I started working with static assets, so I replaced it with the Phoenix Framework, which is way more familiar to me.

It may be overkill to use Phoenix to serve a couple of small image files, but it also gives me some freedom to add back-end features like tracking scores as I build more games. I've also been playing with Phoenix's LiveView capability and love working with it:

// Detect dark theme var iframe = document.getElementById('tweet-1296919592237969409-622'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1296919592237969409&theme=dark" }

Given that I was going from one game to multiple games, I wanted to add an index page to serve as a game selection screen. I also added some simple routing features to navigate between the different games. And I imported the Tailwind CSS framework to start with a simple design and add a footer area with some helpful links.

🎼 Music

For Pong, I had a couple of files called beep.wav and boop.wav that I was using for simple sound effects. I left those out of Breakout, but I wanted to add some background music.

// Detect dark theme var iframe = document.getElementById('tweet-1131530464727064577-989'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1131530464727064577&theme=dark" }

In the past, I had tinkered with creating some custom "chiptune" style music using programs like PICO-8 and Bosca Ceoil. They can be fun to play with, but my Breakout implementation was already getting complicated enough, so I tried finding existing music online.

After Googling a bit, I came across PlayOnLoop.com and found a royalty-free, upbeat song I liked and created a new CREDITS.md file.

To play the music, I use the howler.js JavaScript library. It required using Elm ports to sync up the JavaScript and Elm code, but howler.js has some great features that I'll likely continue to use as I create more games.

🧱 Implementing the Bricks (Finally)

The rows of breakable bricks at the top of the screen were the most important feature, so naturally I procrastinated on implementing them.

Somewhere in the commit history on GitHub, there was a range of commits where I used various combinations of several data structures (List, Dict, Array) in hopes of finding something that felt right to work with. I won't bore you with the details, but I can at least share how some of the fun parts work.

🏗 Individual Bricks

This is what the fields look like for the Brick type along with the data for a default brick:

type alias Brick =
    { color : String
    , height : Float
    , hitCount : Int
    , hitThreshold : Int
    , position : Vector
    , strokeColor : String
    , width : Float
    }

defaultBrick : Brick
defaultBrick =
    { color = "white"
    , height = 16
    , hitCount = 0
    , hitThreshold = 1
    , position = ( 0, 0 )
    , strokeColor = "black"
    , width = 80
    }

One of the first things that might stand out is the position. For Pong, I was using separate x and y fields to store Float values. But I've been working towards learning Linear Algebra a little better for the next games that I plan to work on.

For Breakout, I used a custom Vector type, but for the next games I work with I'll likely use the elm-explorations/linear-algebra package. Khan Academy also has great lessons on Linear Algebra if you're looking to learn more.

The other thing you might have noticed is that I added hitCount and hitThreshold fields. This allows for setting some breaks as "hard" bricks that take multiple hits to break.

🤔 Data Structures

After some initial thrashing about which data structure to use, I settled on using a Dictionary because it would allow for identifying bricks by their row and column. In this type alias, we create a Dict of bricks where the two Int types represent the row number and column number.

type alias Bricks =
    Dict ( Int, Int ) Brick

The implementation for the bricks may have ended up somewhat complicated, and it's possible a normal List would have sufficed. But I knew I wanted to adjust things like the hitCount and color for specific rows or bricks, and using a Dict made that a little easier.

Here are some of the important functions I used for constructing the rows of bricks.

buildRow : Int -> String -> String -> Bricks
buildRow rowNumber color strokeColor =
    List.range 1 10
        |> List.foldr (insertBrick rowNumber) Dict.empty
        |> setRowColors color strokeColor
        |> setRowPosition


insertBrick : Int -> Int -> (Bricks -> Bricks)
insertBrick rowNumber columnNumber =
    Dict.insert ( rowNumber, columnNumber ) defaultBrick

I'm glossing over the details, but definitely check out the Breakout.Brick module if you want to see how it all comes together.

🎨 Styles and Animation

For the brick colors, I used the color palette from Tailwind CSS and looked up the corresponding hex values to create a "ROYGBIV" rainbow for the rows.

The "hard" row of bricks at the top takes multiple hits to break. So it has a different stroke color as a visual indicator that there's something different about those bricks, even if it's not obvious until the ball hits them.

Another cool feature that isn't obvious is that the opacity of each brick is calculated as the percentage of hits remaining to break the brick. In other words, if we made a brick that took ten hits to break, the brick would start out opaque and subtract 10% of its opacity after each hit. If we were to create new levels, this would be a great feature to consider.

One of the most fun features to add was the drop-in animation for the bricks when the game first loads. The Animate.css library has tons of amazing examples for this kind of thing.

I used those examples to create a "bounceInDown" animation that you can find in the assets/css/animations.scss file. Then, in the Elm code, I added that bounce-in-down class to the bricks to get the animation working.

✨ Wishlist

It's amazing how many cool features you can add to a small game like Breakout. But I wanted to find a good stopping point and move on to a new game. One of the big takeaways from this project was how distracted I can get while trying to finish something. I actually finished writing the code for the game months before I was able to publish this blog post.

But there are some known bugs and wishlist items that would be great to add to the game:

Create Multiple Levels
Improve Collisions
Add Sound Effects
Incorporate Randomness
Save High Scores
Expand Particle Effects

If you're looking for inspiration and more features to think about, here are some other great places to look:

📈 What's Next?

I've been having fun building a little arcade cabinet lately. At some point, I'd love to see one of the games I build running on it.

I've also loved getting to explore things like WebGL and Unity recently. But the next game I'm going to focus on building is the classic game Adventure. And my plan is to hopefully incorporate both 2D and 3D features if I can get it all figured out.

If you're learning functional programming and game development, feel free to get in touch with me and I'd be happy to hear from you. You can also find me on Twitter.

And here are links to the game and the source code!

🕹 Play the Game!
💻 View the Source Code on GitHub

Recreating Pong for the Web with Elm

Bijan Boustani — Mon, 20 Apr 2020 14:02:55 +0000

Let's take a tour of the process for creating a web version of the classic Atari game, Pong! In case you missed it, here is the introductory post for this series. The goal is to rebuild classic interactive games and learn a little bit along the way.

🏓 Pong

Before we dive in, let's set the context for what Pong looks like.

Pong is an abstract representation of table tennis, consisting of these basic shapes:

a ball that moves and bounces around the screen
a left paddle that moves up and down, controlled by the player
a right paddle that moves up and down, controlled by the computer
a score indicator for each paddle
a window rectangle with a black background and a "net" in the middle

There have been many versions of Pong released over the years, but we'll use these elements as a model for our version. But let's start with some fun history.

📖 History

One of the fascinating things about Pong is that it was released in the early 1970s to a public that had little context for the idea of a digital video game.

Atari would need to "productize" arcade games at a time when coin-operated pinball games were probably the closest corollary.

Games like Spacewar! predate the release of Pong by a decade, but they were only available to academics and too complicated for the public. So Atari would have to use skills from several disciplines like engineering, design, and entrepreneurship to create something accessible.

The result was the game cabinet pictured in the marketing material above. And below we can see how straightforward they made the instructions and affordances.

In our version, we'll use the arrow keys on a keyboard to control the paddles. But it's easy to see how people could take to the simple controls on the cabinet.

The story goes that Atari put their prototype in a local bar named Andy Capp's Tavern in the heart of Silicon Valley. And the machine was so popular that it would overflow with quarters.

As I was doing "research" for this project, I bought an Atari 2600 emulator called RetroN 77 thinking it would be a good way to simulate the original. But it turns out Pong may have been considered passé by the time the Atari 2600 was released. After the arcade cabinet, there was a dedicated home console version that predated the cartridge-based Atari 2600.

The emulator was still fun to share with my daughter:

Due to its cultural relevance, Pong is even part of the Smithsonian museum. If you're interested in learning more about the history, the Pong Wikipedia page is a good place to start. And there's a fun documentary called World 1-1 you might like too.

🕹 Rebuilding Pong for the Web

My original intention for this series was to rebuild classic games, and then post step-by-step walkthroughs of how to do the same.

After taking the time to work out the mechanics of Pong, I realized that approach would be exhausting to read 😅. It would take a whole course to do justice to the content. So this post will be a tour of the process and the interesting bits, and I'll share all the source code on GitHub at the end.

Plus, I'm still learning game development, and I don't want to steer you in the wrong direction. I'll try to stick with clear explanations in plain terms without relying on jargon that can be scary when you're first getting started.

My goal is still to create faithful reproductions of these classic games. So I worked hard to figure out what made Pong so fun to play. But I'll also add little features and interesting bits where it makes sense.

🎯 Why Pong is Perfect

It turns out Pong is a perfect place to get started with game development. Like most software projects, the first 90% is straightforward. And then the last 10% that makes all the difference.

👏 Simple But Amazing

We can start by sketching all the elements that make up Pong to get an idea of what we want to put on the screen. It involves all the basics, and has everything you need to make for a surprisingly fun game:

Rules: Clear rules for controlling paddles and scoring make the game accessible.
Game Loop: A loop allows us to continuously:
- listen for input
- adjust objects over time
Input Handling: We'll use the keyboard to handle player input and move the left paddle.
Competition: Player scoring adds some fun and a win state.
Rendering: We'll use SVG to create a game window and render all the elements.
Game States: We'll transition between different states:
- StartingScreen
- PlayingScreen
- EndingScreen
AI: We'll simulate simple AI for the computer-controlled right paddle.
Basic Physics: We'll use basic physics to keep the ball and paddles moving with position and velocity.
Collisions: When the ball collides with a paddle or the edge of the screen, we can handle the collisions and responding accordingly.
Assets: Most games will incorporate external assets like sprites and sounds. We won't need any sprites since we're using simple SVG shapes. But we'll use an external sound library to incorporate simple sound effects.

Some of these can be tricky for those of us with a background in web development. When we're building web applications, our app is doing nothing most of the time. We occasionally need to load a new page or make a request to the database, but for the most part the content is static. Even now, you're reading this post but all the hard work of loading the text on the page is already done.

With game development, there is a constant stream of activity. We use a game loop to handle input from players. And, even when there's no input, we still move objects around the screen over time.

When I started learning some of these concepts, I was scared off by terms like "delta time" and "velocity" and "vector." And it's understandable if you feel that way too. It can also get confusing to think about the coordinates and which way is up and down.

One helpful technique is to think of words you're more comfortable with. For instance, you could think of:

horizontalPosition instead of an x position
verticalSpeed instead of vy velocity
changeInTime instead of deltaTime

Once we get a working mental model, we can work towards using common terms and find out why they're more fitting.

💊 Deeper Levels

After getting the basic game elements worked out, it turns out there's a much deeper level to games. Beyond getting things to show up on the screen and move around, we can start to take an interest in:

Game Design: The major takeaway from this project is how little changes can make a big difference in game-play. The game elements mentioned above will get things up and running. Then, you can tinker with all kinds of little settings like ball speed and angles and scoring to make it fun.
Risk and Reward: Hitting the ball closer to the edge of your paddle is a "risky" move, because you're more likely to miss it. A "safe" approach would be to hit the ball with the center of the paddle. But we can change the ball angle coming off the paddle, so your risky move turns into reward because the other paddle will have a much more difficult time returning it. Without this, Pong turns out to be surprisingly boring and predictable.
Speed: We can start by tinkering to set a fast ball speed that's fun to play, but not so fast that it's too difficult. But we also speed up the ball slightly every time it hits a paddle. The result is a feeling that the game speed increases with volleys and adds much more fun to the game.
Randomness: We start with a simple serve from the same location and in the same direction. Then, we can add randomness to the ball location and direction so you have to keep paying attention and build your skills to consistently return the serve.
Fairness: It turns out some changes will feel unfair. Between the ball speed and the randomness, the serves can feel unfair and it gets too easy to get scored on. And without capping the ball speed to an upper bound, it starts to feel unfair if a successful return is impossible.
Playtesting and Tinkering: I didn't know all this before building the game. It was a long process of adding features and playing the game to see the (often unintended) consequences. Tinkering with the values can lead to a lot of fun and interesting ideas.
Aesthetics and UI: I spent some time trying to recreate the feel of the arcade cabinet. I ended up throwing out some of the work, but adding a little color and polish adds a lot to the experience.
Learning and Skill Development: Games can be so compelling because we're learning as we play. We're wired to recognize patterns, and it's fun to feel the sense of improvement and progress as we get better. There's a book called A Theory of Fun for Game Design you might like if you're interested in reading more about this topic.

🌳 Working with Elm

If you haven't worked with the Elm programming language before, An Introduction to Elm is a good place to get started. It's a short book, and the examples give you everything you need to start building front-end web applications with Elm.

The Elm Architecture is also well-suited for building games too. At a glance, you can see the similar pattern between The Elm Architecture functions (init, update, view) and a simple game development platform like PICO-8 (init, update, draw).

init: We can model our game using types and provide initial values. For example, where should the ball and paddles be located when we start the game?
update: This allows us to continuously change the model values over time. We'll update player scores, move the ball, and transition between game states.
view: This will continuously draw the updated model on the screen using SVG.

I'll dive into Elm code throughout the rest of this post. But if you don't know Elm yet, feel free to skim through the content to see the process. And hopefully it will inspire you to go learn more about Elm and functional programming!

🤔 Modeling the Game Components

When you're coming up with an initial version of the data model, it doesn't have to be perfect. We can start with a handful of elements we know we'll need. Then we can pull those into the view function so we have something to look at:

Window
Ball
Left Paddle
Right Paddle

⬛️ Window

Here is a Window type alias we can use to create a SVG rectangle element that will hold the game. Keep in mind that SVG uses the top left as the starting point. When we start with 0 values for x and y we're starting at the top left.

As the x value increases, we move right ➡️
As the y value increases, we move down ⬇️

Using values for x, y, height, and width we can draw the rectangle for our game window.

type alias Window =
    { backgroundColor : String
    , x : Float
    , y : Float
    , width : Float
    , height : Float
    }

And we'll set some initial values:

initialWindow : Window
initialWindow =
    { backgroundColor = "black"
    , x = 0.0
    , y = 0.0
    , width = 800.0
    , height = 600.0
    }

These values will correspond to an SVG rect element, and Elm has an Svg package that contains all the same elements and attributes we'll need.

Here is the corresponding view function that calls Svg.rect. We can pass our initialWindow into this function and it produces the rectangle we need.

viewGameWindow : Window -> Svg.Svg msg
viewGameWindow window =
    Svg.rect
        [ Svg.Attributes.fill <| window.backgroundColor
        , Svg.Attributes.x <| String.fromFloat window.x
        , Svg.Attributes.y <| String.fromFloat window.y
        , Svg.Attributes.width <| String.fromFloat window.width
        , Svg.Attributes.height <| String.fromFloat window.height
        ]
        []

And we can even add another view function for the "net" in the middle of the screen. Some Googling turned up this stroke-dasharray doc from MDN, which worked well for placing a dashed line in the middle of the game window.

viewNet : Window -> Svg msg
viewNet window =
    Svg.line
        [ Svg.Attributes.stroke "white"
        , Svg.Attributes.strokeDasharray "14, 14"
        , Svg.Attributes.strokeWidth "4"
        , Svg.Attributes.x1 <| String.fromFloat <| (window.width / 2)
        , Svg.Attributes.x2 <| String.fromFloat <| (window.width / 2)
        , Svg.Attributes.y1 <| String.fromFloat <| window.y
        , Svg.Attributes.y2 <| String.fromFloat <| window.height
        ]
        []

It's not much to look at so far, but it works!

🎾 Ball

The ball is like the window because we're still using Svg.rect, but in this case it'll be much smaller. We add a vx and vy that we'll use to indicate the horizontal and vertical velocity. We could just push the position of the ball around over time using x and y. But these velocity values allow us to do things like change the speed and negate the values to get the ball moving the other way when it strikes a paddle.

type alias Ball =
    { color : String
    , x : Float
    , y : Float
    , vx : Float
    , vy : Float
    , width : Float
    , height : Float
    }

Here are the initial values I ended up with for the initialBall. It was basically a matter of tinkering until it was somewhere near the middle of the screen.

initialBall : Ball
initialBall =
    { color = "white"
    , x = 395.0
    , y = 310.0
    , vx = 350.0
    , vy = 350.0
    , width = 10.0
    , height = 10.0
    }

We also could have represented the same data with a position value to hold the x and y. And a velocity to hold the vx and vy. For this first game, I wanted to stick with a "flat" model that didn't involve any nesting so that updating values would be easy. But I'll likely change that approach in the next game I build.

I should also mention that I used Int values when I started. I later switched to using Float values to avoid having to perform conversions and round the integers. I'm not sure, but I think the precision of Float values also makes the animation look a little smoother too.

And here's the view function to render the ball on the page:

viewBall : Ball -> Svg msg
viewBall ball =
    Svg.rect
        [ Svg.Attributes.fill <| ball.color
        , Svg.Attributes.x <| String.fromFloat ball.x
        , Svg.Attributes.y <| String.fromFloat ball.y
        , Svg.Attributes.width <| String.fromFloat ball.width
        , Svg.Attributes.height <| String.fromFloat ball.height
        ]
        []

🏓 Paddles

The paddles are rectangles like the window and ball. Both paddles have the same fields, but we can add a PaddleId type to differentiate between them.

We add a score for each paddle that we can increment. Also note that we only need a vy for the vertical speed since the paddle doesn't need to move horizontally.

type PaddleId
    = Left
    | Right

type alias Paddle =
    { color : String
    , id : PaddleId
    , score : Int
    , x : Float
    , y : Float
    , vy : Float
    , width : Float
    , height : Float
    }

Then, we can set initial values to locate the paddles near the left and right edges of the game window:

initialLeftPaddle : Paddle
initialLeftPaddle =
    { color = "lightblue"
    , id = Left
    , score = 0
    , x = 48.0
    , y = 200.0
    , vy = 600.0
    , width = 10.0
    , height = 60.0
    }

initialRightPaddle : Paddle
initialRightPaddle =
    { color = "lightpink"
    , id = Right
    , score = 0
    , x = 740.0
    , y = 300.0
    , vy = 475.0
    , width = 10.0
    , height = 60.0
    }

Here are the view functions for the paddles and paddle scoring:

viewPaddle : Paddle -> Svg msg
viewPaddle paddle =
    Svg.rect
        [ Svg.Attributes.fill <| paddle.color
        , Svg.Attributes.x <| String.fromFloat paddle.x
        , Svg.Attributes.y <| String.fromFloat paddle.y
        , Svg.Attributes.width <| String.fromFloat paddle.width
        , Svg.Attributes.height <| String.fromFloat paddle.height
        ]
        []

viewPaddleScore : Int -> Window -> Float -> Svg msg
viewPaddleScore score window positionOffset =
    Svg.text_
        [ Svg.Attributes.fill "white"
        , Svg.Attributes.fontFamily "monospace"
        , Svg.Attributes.fontSize "80"
        , Svg.Attributes.fontWeight "bold"
        , Svg.Attributes.x <| String.fromFloat <| (window.width / 2) + positionOffset
        , Svg.Attributes.y "100"
        ]
        [ Svg.text <| String.fromInt score ]

When I first started, I hard-coded some of these values to keep things simple. For instance, the positionOffset for the scores is something I added in later as a way to use this same function to display both scores and pass in a number to move the score over within the SVG window.

We pull all that together into the model and we have all the basic elements for our game!

type alias Model =
    { ball : Ball
    , leftPaddle : Paddle
    , rightPaddle : Paddle
    , window : Window
    }

initialModel : Model
initialModel =
    { ball = initialBall
    , leftPaddle = initialLeftPaddle
    , rightPaddle = initialRightPaddle
    , window = initialWindow
    }

The game isn't "alive" yet, but we have everything we need and it's all in roughly the correct location.

🔁 Update

The update function is where a lot of the magic happens for our game. This is how we update the ball position, move the paddles around, update player scores, etc. It's also where things get a little more complicated. The source code for this project is available at the bottom of this post, so I'll try to keep this section at a high level without diving into the details.

⏱ Subscriptions

The subscriptions function is a good place to start, and we'll handle these in our update. We use subscriptions for two major features:

⌨️ handling keyboard input
✨ adding animation

In the code snippet below, we use the Browser.Events module from Elm's Browser package to handle browser animation and key events from the player.

subscriptions : Model -> Sub Msg
subscriptions model =
    Sub.batch
        [ Browser.Events.onAnimationFrameDelta BrowserAdvancedAnimationFrame
        , Browser.Events.onKeyDown <| Json.Decode.map PlayerPressedKeyDown <| keyDecoder
        , Browser.Events.onKeyUp <| Json.Decode.map PlayerPressedKeyUp <| keyDecoder
        ]

This produces a steady stream of data we can use for our game. And a Msg type allows us to indicate how we want to handle them in our update function.

type Msg
    = BrowserAdvancedAnimationFrame Time
    | PlayerPressedKeyDown String
    | PlayerReleasedKey String

I'm admittedly glossing over a lot of details as this blog post grows much larger than I intended. But the important part is that we'll use BrowserAdvancedAnimationFrame to animate the ball and paddles so they move over time. PlayerPressedKeyDown will give us a way to know when a player is pressing an arrow key to move the left paddle.

✏️ Sketching Updates with Pseudocode

When I started writing the update function, I mapped out a quick plan with the pseudocode below.

Thinking this way with conditionals turned out to be a huge mistake 👎. Every time I wanted to add a feature, it meant adding yet another condition. And the order of the conditions ended up being important too.

if nothing is happening
    move ball
    move right AI paddle
if player input
    move left paddle
if ball hits right paddle
    negate ball.vx
    update ball position
if ball hits left paddle
    negate ball.vx
    update ball position
if ball hits left window edge
    increment right player score
    reset ball to initial position
    set ball in motion
if ball hits right window edge
    increment left player score
    reset ball to initial position
    set ball in motion
if ball hits top or bottom window edge
    negate ball.vy

At least it gave me a rough idea of the events in the game of Pong. But for the next game I work on I'll sketch this out on paper before I dive into the code. And instead of thinking about if-this-then-that, I'll try to come up with union types for different states.

🚀 Getting the Ball Moving

At this point, it's fun to set the ball in motion and see what happens. We can use something like this to adjust the position based on the time we're getting from BrowserAdvancedAnimationFrame. In other words, as time advances, the ball's x and y position will increase, which means the ball will move down ⬇️ and to the right ➡️.

{ ball
    | x = ball.x + ball.vx * time
    , y = ball.y + ball.vy * time
}

It's fun to see the ball start moving, but we quickly realize it won't know to stop at the bottom of the window.

You'll need to check out the source code at the bottom of this post to see the complete example. But the basic idea at this point is to invert the ball's vertical direction when it hits the bottom of the window. The ball has a positive vy value as it's moving downward. Hitting the bottom edge of the window (which we know because it's the value of the window.height) means we take the vy value and turn it into a negative value.

-- ball hits bottom edge of window
case edge of
    Window.Bottom ->
        { ball | vy = negate ball.vy }

From here, the development starts to flow a bit. When the ball collides with the top or bottom of the window, we negate the vy value. When the ball hits the left or right edge of the window, we increment the player score by 1 and we reset the ball back to its original position.

💥 Paddle Collisions

Handling the ball collisions with the edges of the window is somewhat straightforward since we can use the window's x, y, width, and height values. Paddles are a little more difficult, because we have to compare the ball's location and the paddle's location to see if they intersect. Here are the boolean checks I used to determine if the ball had collided with one of the paddles:

ballHitLeftPaddle : Ball -> Paddle -> Bool
ballHitLeftPaddle ball paddle =
    (paddle.y <= ball.y && ball.y <= paddle.y + paddle.height)
        && (paddle.x <= ball.x && ball.x <= paddle.x + paddle.width)
        && (ball.vx < 0)

ballHitRightPaddle : Ball -> Paddle -> Bool
ballHitRightPaddle ball paddle =
    (paddle.y <= ball.y && ball.y <= paddle.y + paddle.height)
        && (paddle.x <= ball.x + ball.width && ball.x <= paddle.x + paddle.width)
        && (ball.vx > 0)

🚦 Game States

After getting some of the initial features up and running, we realize that games aren't always in a "playing" state. Super Mario Bros. is a memorable example where there is an initial screen and you have to press the start button to begin playing the game.

So we can begin with a StartingScreen state, and transition to a PlayingScreen state after a player is ready. For Pong, I added brief instructions below the game window (which are visible at the bottom of this post) and used the spacebar key to start the game.

Super Mario Bros. also has a memorable "Game Over" screen. When one of the players reaches the winning score, we'll transition from PlayingScreen to an EndingScreen state where we can display the winner.

type GameState
    = StartingScreen
    | PlayingScreen
    | EndingScreen

We can create a custom type like this to handle the different game states and transition between them. It also ensures that players are only in one state at a time, since we shouldn't still be playing the game in the "game over" screen. We can disable to movement of the ball and paddles in the start and end states. And we also handle keyboard input to start or restart the game from those states.

🦉 Draw the Owl

Take a look at the source code because there's actually a lot going on in the update function.

I hate to say "draw the owl" here. But I wanted to make sure I cover the more interesting aspects of what sets this implementation of Pong apart from many others.

😍 The Interesting Bits

Once you get a working version of the game up and running, it's time to figure out what makes it interesting, compelling, and fun.

⚡️ Changing the Ball Angle

If I had to pick one feature that makes a big difference in the game, it's this one. When the ball collides with a paddle, it initially makes sense to invert the ball's vx value and send it back the other way. It would look something like this:

-- ball hits paddle
{ ball | vx = negate ball.vx }

That works well for the ball to hit the paddle and change the horizontal direction. As it turns out, having the ball follow a slow, predictable path can make the game so boring.

The solution is to give players a way to control the angle of the ball off the paddle.

This is better explained visually, so here are a couple of quick sketches. Instead of having the ball follow a predictable path, the location where the ball hits the paddle determines the angle.

That might not seem like a big difference, but the result is that one paddle can make it way harder for the other paddle to return the ball.

We can also add a small amount to the ball speed whenever it hits a paddle to make the game feel quicker. Whenever the ball collides with a paddle, add to the vx value to increase the horizontal speed. Elm's clamp function is useful to set an upper bound, because the ball can end up moving so fast that it becomes difficult to play.

Adjusting things like the ball angle and speed has a huge impact on playability. It also adds an element of strategy to the game that gives the player options:

Conservative Option: Be conservative and hit the ball with the middle of the paddle. The speed will increase with each hit and eventually the right paddle will struggle to keep up.
Risky Option: Or, take on the risk of hitting the ball closer to the edge of the paddle, which returns it at a harder angle for the AI paddle.

🤖 "AI" for the Right Paddle

My first attempt at getting a computer-controlled paddle working was to just have the paddle.y position match the ball.y position. It works well as a starting point, because the ball and right paddle end up in sync with one another and allows the right paddle to consistently return the ball.

The only problem is that makes it impossible for the left paddle to score, because the right paddle will always meet the ball.

I ended up finding a solution that seems to work pretty well where the right paddle tries to "catch up" with the ball's location:

updateRightPaddle : Ball -> Float -> Paddle -> Paddle
updateRightPaddle ball time paddle =
    if ball.y > paddle.y then
        { paddle | y = paddle.y + paddle.vy * time }

    else if ball.y < paddle.y then
        { paddle | y = paddle.y - paddle.vy * time }

    else
        paddle

If the ball is higher on the screen, then the paddle will "chase" upward. If the ball is lower, then the paddle will "chase" downward. Then, you can tinker with the right paddle's vy value to increase or decrease the difficulty. I ended up finding a value that works well in that it's difficult to score but not impossible. So it feels rewarding to score points against the "AI" paddle.

🏆 Winning

Speaking of scoring, it was surprisingly difficult to figure out what the winning score was supposed to be for the arcade game. Was it 10? 11? 15? Or whoever scored the most within a certain time frame?

Then I found this sticker:

First player to score 15 points WINS

But I was curious about why the score on this arcade cabinet was on a sticker instead of located with the rest of the instructions.

It turns out there was a physical switch arcade owners could use to adjust the winning score.

This felt like low-hanging fruit, so I added it as an option to the game.

💯 Ball Path History

This felt like the "killer app" for this version of Pong. I saw Bret Victor's Inventing on Principle talk years ago and loved the idea that game elements have a past and future. But I never thought about how something like that works.

With Elm, it's a little more obvious because the Elm debugger gives a glimpse of what the stream of values looks like over time.

To visualize the ball history, we can start by creating an empty list. And then every time the ball changes position, we prepend the ball to the list.

updateBallPath : Ball -> BallPath -> Maybe WindowEdge -> Model -> Model
updateBallPath ball ballPath maybeWindowEdge model =
    case model.showBallPath of
        Pong.Ball.Off ->
            model

        Pong.Ball.On ->
            case maybeWindowEdge of
                Just Pong.Window.Left ->
                    { model | ballPath = [] }

                Just Pong.Window.Right ->
                    { model | ballPath = [] }

                _ ->
                    { model | ballPath = List.take 99 <| ball :: ballPath }

When the ball hits the left or right edge of the game window, we clear the history by setting ballPath = []. The rest of the time, we're collecting new positions by prepending the ball to ballPath. Instead of "prepend" the :: operator is usually called "cons" in languages like LISP and Elm.

Lastly, we can pipe to List.take 99 to limit the amount of history and avoid potential performance pitfalls. Having said that, I'd be curious how much history it could handle before slowing down, and you might even be able to build a whole new game around that idea.

📈 Performance

Game development can be pretty tricky. If I write an inefficient function for most applications, it's only going to run here and there and probably won't be noticeable. If I write an inefficient function for a game, it will run about 60 times per second. The whole time 😅.

As I continue to make more games, I'd like to find better ways to profile performance and benchmark. I recorded some performance profiles using my browser's DevTools, but it's difficult to see where inefficiencies are.

It's also interesting to try different machines and browsers. I wrote this on my relatively new MacBook Pro laptop, but it likely wouldn't run as smoothly on my older laptop.

For now, I added a viewFps function in the Util module that takes a list of times and allows you to use a toggle to display and hide the current frames per second.

🎨 Polish and Sound

As some final polish, I added some color to the background to pay homage to the original game cabinet. And I used SVG to recreate the Pong lettering at the top of the screen. I had other fun ideas to create more cabinet affordances in the UI, but it would've taken some time to get right.

There's also a great JavaScript library called howler.js for adding audio to the game. Some of the howler demos are really amazing. Elm provides "ports" to integrate with JavaScript libraries in a safe way. So I added simple beep.wav and boop.wav sounds for when the ball hits the paddles and edges. When the collisions occur, it triggers the port and plays the sound in the browser. Check out the source code if you want to see an example of how this works.

💡 Ideas

One of the most fun parts of game development is stumbling on little ideas that would be intriguing to implement.

Sometimes you have an idea you want to see come to life, and sometimes you accidentally write some bad code that produces an interesting result. For instance, I made a mistake where the ball's motion was stopped unless I was moving the paddle. But that got me thinking of a game like Superhot, where "time moves only when you move".

The ball path history feature I mentioned above is a good example of this kind of "+1" feature that's not core to the game but adds a lot to it.

Here are a few more ideas of varying complexity that I would've loved to implement given the time:

Change the ball's color.
Add particle effects for collisions.
Add a pause state.
Dynamically change the ball's width and height.
Multiball mode.
Multipaddle mode.
"Superhot" mode, where the ball moves only when you move.
Replay winning shots in the ending screen state.
Local multiplayer where one paddle uses the keyboard and one paddle uses the mouse.
Online multiplayer (if you build something like this I'd love to see it!).

🎓 Lessons Learned

Little things make all the difference. Adjusting settings like the ball speed and path has a huge impact on playability. Polish!
Think in states (with union types) instead of conditionals. You can start small with moving away from Bool values to an On and Off switch, then add additional custom states.
Refactoring has its ups and downs. It's great to clean up the code and add clarity. But I split the application code into separate files and modules, which didn't improve the development experience.
Find balance.
- Gently resist the urge to move on and work on something else that's new and different. It's easy to get the first 90% done, but the interesting bits are in the final stretch. Adding polish can move it from a lark to a genuinely interesting project.
- Having said that, find a good stopping point. I could probably keep building different versions of Pong with fancy features for a year. And it's tempting to implement those fun ideas in the list above. But it's important to find a good place to stop and ship it if we want to keep moving and growing. 🚀

📈 What's Next?

While rebuilding Pong, there were a bunch of times where I wanted to bail and work on something more complex and impressive. And other times where I just wanted to "quickly" build other games like Tetris and Snake. But I'm going to try sticking with the approach I outlined in the intro post for this series.

Breakout was always my favorite Atari game when I was a kid, so it'll be fun to figure it out. Plus I have all the basic mechanics built for this project, so it'll give me an opportunity to try different data structures and add some more interesting features like particle effects that I didn't get to do for Pong.

🏫 Resources

If you're learning functional programming and game development, feel free to get in touch with me and I'd be happy to hear from you. You can also find me on Twitter.

As promised, here are links to the game and the source code!

🕹 Play the Game!
💻 View the Source Code on GitHub

Recreating Classic Games for the Web (Series Intro)

Bijan Boustani — Sun, 01 Mar 2020 04:30:26 +0000

I've always been fascinated by the level of interactivity and fun that classic console games were able to offer. I grew up playing games like Super Mario Bros. for the Nintendo Entertainment System. And it's been a silly dream of mine over the years to create similar games for the web.

I've been working with web applications in recent years, but game development was a different world I always wanted to learn more about. And while I've tinkered with building a few demos here and there, I never got very far with it.

My goal for this series is to recreate classic console games from scratch with the Elm programming language, and to share the process as I go.

Which Games?

When I mention "classic games" in the title of this post, I'm primarily referring to console games for the Atari 2600 and Nintendo Entertainment System.

In other words, I'd love to recreate games like Pong, Super Mario Bros., and The Legend of Zelda. But I don't plan to work on games like Tic-tac-toe or Hangman. And it's also unlikely that I'll be able to recreate the modern AAA game titles that are developed by hundreds of talented people.

The plan is to get started with relatively simple Atari games (although I've found even simple games can take a fair amount of work to polish and get right).

(Atari) Pong
(Atari) Breakout

Assuming I don't rage quit after building those, I'll move on to Platformer games. This is where the list already gets a little hazy because Celeste is a modern take on some of these classic mechanics.

(Atari) Pitfall!
(NES) Super Mario Bros.
(Indie) Celeste

I'd also really love to build Adventure games, with The Legend of Zelda: A Link to the Past being my childhood favorite.

(Atari) Adventure
(NES) The Legend of Zelda
(SNES) The Legend of Zelda: A Link to the Past

Scope

Admittedly, I won't be able to clone all the amazing artwork and music and features from these games. So the idea is to at least figure out the primary game mechanic from each genre.

There are also subtle aspects of these games that make all the difference. Mario's jump has to feel just right. And when a ball strikes a paddle in Pong, hits toward the edge of the paddle make the ball come off at a steeper angle. So you take on more risk hitting it closer to the edge of the paddle, but you also increase the difficulty for your opponent.

Plan

My background is in web development, not game development. So I'll likely make mistakes and run into problems that other smart people solved a long time ago.

But it feels like a good way to learn and a good time to get into game programming. There are awesome tools and learning resources available these days.

You can download Unity for free and there are books and tutorials out there for creating both 2D and 3D games. There are also projects like PICO-8 and LÖVE 2D for a language called Lua that are super fun to try out.

Why Elm?

"As with any time you fall in love, it's difficult to explain why. It just worked the way I work."
Dave Thomas Programming Elixir

Elm is a fun language to work with, and it's become my favorite for front-end web development. Most languages involve a workflow where we write code, run our program, find errors, and debug them. With Elm, we write types and code with feedback from a compiler, and then run it with confidence that it won't catch fire.

Although the options I mentioned above are likely better for most game development, Elm will be a fun way to build things from scratch and a good way to learn. It also means I can start with simple Elm and SVG for the first couple games, and then learn more about WebGL and other technologies as needed.

Motivations

Beyond the motivation to create fun, interactive games; there's also a lot to learn. I'm excited to learn more about game design and development (like working with an Entity Component System). I find it fascinating to learn about how the game industry evolved. And it's amazing how far the medium has come considering that the 1970s (Atari) and 1980s (NES) weren't that long ago.

It's a good opportunity to continue improving functional programming skills and solve problems we don't usually come across when building web application features. And it would be cool to pull some of those ideas from games back into web application development. I'm personally interested in how ideas from the world of game design can be used to improve educational content.

There are some fascinating directions to go once we learn the basics. Creative coding projects and experiments like Cube Slam that combine web technologies like WebRTC and three.js for a fun multiplayer game.

How I Set Up a New MacBook Pro Dev Environment

Bijan Boustani — Wed, 08 Jan 2020 15:10:52 +0000

🎆 New year!
💼 New job!
💻 New laptop!

I'm so excited for this brand new decade. It feels like an opportunity for a fresh start.

I had been working at the same company for years. So, I'm eager to start my new job and work with a distributed team of talented people at Enbala Power Networks. It's a perfect mix of technology I love (Elixir and Elm), fascinating work, and people I admire.

💻 Setting up a New Laptop

The timing worked out well. Apple recently released the new 16-inch MacBook Pro models, and I had been dying for a new setup.

I figured I would take this opportunity to write down a checklist of applications I use and preferences I have for setting up a new laptop.

Some of my settings are eccentric (like having a plain black background instead of a fancy photograph). But my hope for this post is that you'll at least take away one or two helpful ideas that might get you unstuck from a rut.

🙉 Creating a Distraction-free Environment

Almost all my preferences are all about limiting distractions and enabling focus. I've always been prone to distraction. So, creating an environment where I can stay focused on a single task for an extended period is critical.

Otherwise, I make tiny amounts of progress in many directions without finishing anything. The result is that all the time and energy and effort I put in is wasted.

🧹 Cleaning up the Dock

Out of the box, macOS comes with so many applications in the Dock. But it's more efficient to use the native Spotlight search (or Alfred) to open applications with the keyboard. For example, you can type Command + Space + Sys and then press Enter to open the System Preferences.

So, I opt for a minimalist Dock area with only the following:

Firefox Developer Edition
Visual Studio Code
Downloads Folder

I also like to hide the Dock when I'm not using it, and I disable the option to remember recent applications.

⚡️ Speeding up the Trackpad, Mouse, and Keyboard

One of the first things I like to do for a new laptop is comb through the System Preferences. There are some default settings that slow you down. For example, the default Trackpad speed is slow, which can make it tough to navigate the cursor around, especially on large displays.

Command + Space ➡️ Trackpad ➡️ Tracking Speed ➡️ Fast

This can take some getting used to if you're accustomed to the slower setting. But it's worth it to adjust, because it's way faster to navigate with the faster setting.

🖱 Next, you can do the same for the mouse:

Command + Space ➡️ Mouse ➡️ Tracking Speed ➡️ Fast

⌨️ Similarly, you can speed up your Keyboard settings with the following:

Command + Space ➡️ Keyboard ➡️ Key Repeat ➡️ Fast
Command + Space ➡️ Keyboard ➡️ Delay Until Repeat ➡️ Fast

This might seem like a silly place to start, but the idea is to find small changes we can make that add up to a lot over time.

🖤 Background and Menu Bar

This setting might be a little odd, but I use a plain black color for my background. The macOS background pictures are beautiful, but this is the least distracting option for me:

Command + Space ➡️ Desktop & Screen Saver ➡️ Apple ➡️ Colors ➡️ Black

There is also an application called Bartender I love for cleaning up the menu bar area. After installing several applications, the menu bar area tends to look cluttered. Bartender allows you to show or hide menu bar applications, and I tend to prefer hiding everything except the date and time.

🖥 Adding Virtual Desktops

I also like to set up virtual desktop spaces to create separation between applications. This way, I can have my IDE running in a separate space from my browser.

To set this up, you can do a three finger swipe upward on the Trackpad to enter Mission Control mode. From here, you can click the ➕ icon at the top right to create new virtual desktop spaces.

This allows you to keep dedicated spaces for things like your IDE, browser, and task manager. And you have a couple options for switching between these spaces:

use Command + Tab to switch between open applications.
use a three finger swipe left or right to switch to the next virtual space. You can also use Control + ⬅️ or Control + ➡️.
use a three finger swipe upward to open Mission Control. You can also use Control + ⬆️.
use Control + N to switch to a particular space based on the number (N). This option requires enabling keyboard shortcuts with the following:

Command + Space ➡️ Keyboard ➡️ Shortcuts ➡️ Enable Switch to Desktop N

If you plan to dedicate spaces for a particular use, you can also disable the option to "Automatically rearrange Spaces based on most recent use."

🔕 Limiting Notifications

macOS comes with a Do Not Disturb mode that can help to reduce the number of interruptions. One way to turn this on is to hold down the Option key on your keyboard and click the Notification Center icon in the menu bar.

You can also set a time range for when to enable Do Not Disturb mode:

Command + Space ➡️ Notifications ➡️ Turn on Do Not Disturb

📱 It's not a bad idea to check your phone too for apps that are bombarding you with notifications. If you're using an iOS device, you can check the following:

Settings ➡️ Screen Time ➡️ See All Activity ➡️ Notifications

Disabling unneeded notifications from even a couple of apps can have a big impact and cut down on distractions throughout your day. 😌

Recommended Applications

General

🦊 Firefox Developer Edition for web browsing.
✅ Things for a well-designed project and task manager.

Utilities

🔒 1Password for password management.
⌨️ Alfred for keyboard-based productivity and automation.
🍻 Bartender for de-cluttering the macOS menu bar.
📦 Dropbox for cloud file storage across devices.
🦊 Gifox for a well-designed menu bar application to quickly record animated gifs.
🔍 Moom for moving and arranging your windows with Option + Tab keyboard shortcuts.
⏱ The Clock for replacing the default date and time in the menu bar. This is particularly helpful if you're on a distributed team where your teammates are in different time zones (demo).

Web Applications

✍️ 750words for a simple, daily writing habit.
💌 Gmail for email.
🗓 Google Calendar for shared calendars.
📝 Hemingway App for quick recommendations on how to simplify your writing.
💰 YNAB for budgeting.
🎼 Spotify for music.

💻 Development Environment

🐙 GitHub for code repositories.
- Set up ssh access.
🆚 VSCode for my coding environment.
- Set up ability to launch from command line with code.
- Disable "Scroll Beyond Last Line" option.
- Install Firacode for a font with fancy ligatures.
- Set up LiveShare for pair programming.
🎛 asdf for installing and managing multiple versions of programming languages.
- Erlang
- Elixir
- Ruby
- Node
- Elm
👨‍💻 iTerm
- homebrew
- oh-my-zsh
- dotfiles
- aliases
🐘 PostgreSQL
🏃‍♂️ Dash for quick access to documentation.

🕹 Gamedev

PICO-8 for minimalist, retro game development.
Unity for a fancy, batteries-included game development environment.
Asesprite for pixel art.

🤖 Automation

Even if you only have to set up a new laptop every few years, it's worth investing some time in automation. If you're interested in automating your laptop setup process, consider the following:

Create a dotfiles repo on GitHub to save your favorite configuration files.
Use Brewfiles for installing applications and common system dependencies.

😌 Next?

You can probably tell I love to nerd out about all these little applications and preferences. If you have any tips and tricks or recommendations, reach out to me on Twitter (@bijanbwb) and I'd love to hear from you!

I love when people create a "/uses" page (like this one from Wes Bos) to list the applications and the physical gear they use to be productive. I'm considering writing a future post about how I organize my home office, so let me know if there is something you'd like to see!

Forem: Bijan Boustani

Recreating Breakout for the Web

⏳ tl;dr

🛸 Why Breakout?

🤔 What's Interesting About Breakout?

🤯 Game Feel and "Juice"

🔄 Implementing a Screenshake

🎉 Particle Effects

🎨 Assets and Pixel Art

🎮 Updating the Game Platform

🎼 Music

🧱 Implementing the Bricks (Finally)

🏗 Individual Bricks

🤔 Data Structures

🎨 Styles and Animation

✨ Wishlist

📈 What's Next?

Recreating Pong for the Web with Elm

🏓 Pong

📖 History

🕹 Rebuilding Pong for the Web

🎯 Why Pong is Perfect

👏 Simple But Amazing

💊 Deeper Levels

🌳 Working with Elm

🤔 Modeling the Game Components

⬛️ Window

🎾 Ball

🏓 Paddles

🔁 Update

⏱ Subscriptions

✏️ Sketching Updates with Pseudocode

🚀 Getting the Ball Moving

💥 Paddle Collisions

🚦 Game States

🦉 Draw the Owl

😍 The Interesting Bits

⚡️ Changing the Ball Angle

🤖 "AI" for the Right Paddle

🏆 Winning

💯 Ball Path History

📈 Performance

🎨 Polish and Sound

💡 Ideas

🎓 Lessons Learned

📈 What's Next?

🏫 Resources

Recreating Classic Games for the Web (Series Intro)

Which Games?

Scope

Plan

Why Elm?

Motivations

Further Reading

How I Set Up a New MacBook Pro Dev Environment

💻 Setting up a New Laptop

🙉 Creating a Distraction-free Environment

🧹 Cleaning up the Dock

⚡️ Speeding up the Trackpad, Mouse, and Keyboard

🖤 Background and Menu Bar

🖥 Adding Virtual Desktops

🔕 Limiting Notifications

Recommended Applications

General

Utilities

Web Applications

💻 Development Environment

🕹 Gamedev

🤖 Automation

😌 Next?