Forem: Jeff Puls

Is React Holding You Back?

Jeff Puls — Sun, 31 Jan 2021 19:06:38 +0000

React.js is perhaps one of the most controversial topics among web developers in recent years. Some love it, some hate it, some can't live without it. This post aims to toe the line of both sides as I share my experience thus-far and explain what I learned by converting my React-based portfolio back to a bog-standard HTML/CSS/JavaScript page.

Strap in, this might be a long one...

The Alluring Trap of React

So you're like myself, a freshly self-taught developer who has spent ~~months~~ years working from the ground up, building your development knowledgebase and skillset from absolutely nothing. HTML and CSS are finally your bread-and-butter, you can craft a stylish (albeit plain-as-a-pancake) TO-DO list in no time flat. With your rudimentary JavaScript knowledge, you've made it interactive, perhaps it even talks to an Express server for that extra zest.

Now what?

Back to the land of tutorial-hell to try and pick up the next tool for your belt. You really enjoy the logical programming paradigms you learned in vanilla JavaScript, so you venture down that rabbit hole once again, this time looking to learn a framework. You quickly smash the keywords into Google.

best javascript framework to get rich quick

Instantly, you're bombarded with a never-ending wall of different catchy names and logos, but one stands out among the crowd, a sleek light-blue atom... it's calling to you, promising you fame, promising fortune... promising the future...

TIME MACHINE ENGAGED!

Six long months have passed. You've watched endless YouTube tutorial videos and read various blog posts about React and its many spinoff-frameworks. You're now able to wield Hooks and Context Providers like it's nobody's business. You've even assembled an impressive (at least to the lay-person) catalogue of React-based applications. Time to share your new-found mastery with the world, time to bring your personal portfolio into THE FUTURE™.

The next few months are spent designing and building the most incredible site you've created to date. I'm talking a global Context system, real-time updated personal stats from your npm and GitHub profiles (with lazy-loaded components!), and it's even got a custom Context-based multi-theme UI framework you built to drastically reduce the amount of CSS you need to write and load in. You're convinced it's the second coming, or at least the third.

Head now properly over-inflated, you decide to share your creation with your favorite online community to get some proper feedback.

Feedback quickly rolls in... It's got potential they say, but falls well short of expectations. Lethal bugs are discovered that you overlooked. Questionable design choices are picked apart. The worst part of all, your page's Lighthouse Performance Score on anything but your own machine SUCKS. It stings, but don't forget... you literally asked for this.

What Went Wrong?

Well, it turns out that the foundation of your website is made of some sort of radioactive (React's logo is an atom, get it? Get it...?) elements. And such as irradiated things tend to do, a tumor had quietly begun to grow at the heart of your project. A nasty little bugger known as the node_modules directory, and it was sapping the life out of your pride-and-joy.

If you're not aware, React applications are based on the idea of building your project by cobbling together bits and pieces of open-source code in the form of modules to bring developer-friendly functionality to different things. While a well experienced and season development team will likely have found ways to mitigate the shortfalls inherent to this development style, it can quickly swallow a green solo-dev alive.

The Ultimate Decision

Bloodied and beaten by the constructive criticism you received, you crawl back into your development lair, dim the lights and take a good hard look at your ~~life~~ code. A suggestion had been made to you by someone much more experienced in the field, and it has stuck in your mind.

Why even use React for a single-page portfolio... it's overkill. Do it all over again, but this time, just use HTML/CSS/JavaScript like the good-old-days.

"React is cool though... I WAS PROMISED IT WAS THE FUTURE!™", you maniacally howl at the gray mid-winter sky.

After sobbing yourself to sleep, you wake up the next morning and a decision has been made.

TEAR IT DOWN.

The next week or so is spent looking over notes taken from your original public showing (don't forget, constructive criticism is worthless if you don't utilize it!). The entire project needs to be re-written in the archaic, primitive language you haven't spoken in what feels like eons. So with the steadily thumping melodies of Retrowave | Synthwave radio in the background, you set to work, relearning the basics (and picking up a few new tricks along the way that never occurred to you before, since React took care of things behind the scenes for you).

The Result

You're exhausted. You're dehydrated. You haven't seen the sun in days... but it's complete. You take a tentative step back and prepare to gaze upon what now lies breathing on your Dr. Frankenstein's table, prepared to quickly avert your eyes from the horrors you're sure to find...

You throw back the curtains...

And...

✧･ﾟ: ✧･ﾟ: I T ' S A M A Z I N G :･ﾟ✧:･ﾟ✧

Your music choice has clearly had a profound impact on the style choices this time round (in perhaps the best way possible). The buggy-ness inherent in your original project nearly eradicated, thanks to no longer needing to worry about a million npm modules playing nicely together. The interface simplified and more intuitive. The layout, ironically, now properly reactive to different screen sizes. And The code base...

Literally 10% the size of its React counterpart.

Okay, okay. So you've made something that looks better and is physically a fraction of the size... But how does that translate to metered performance...

Well, I'll just let Chrome speak on that front.

Before:

After:

So my friends, as someone who is still deeply in love with the concept of React.js and the development and scalability advantages it provides, I can confidently tell you that it definitely has it's place in anyone's toolkit. However, that place does not appear to be a website as simple as a developer portfolio (even one who is actively pursuing work in this specific discipline)!

If you currently use React for your own small-scale website, I strongly urge you to take a good hard look at your project, and consider cutting off the tumor before it grows too large and ends up killing you in the long run!

Want to check out the differences first-hand?

Here is the original:
React-based portfolio

And here is the new-and-improved:
Jeff Puls | Front End Developer

Have you had a similar experience to my own? Want to crucify me for daring to speak out against the usage of THE FUTURE™ of web development?

Let's talk about it in the comments below 🙂

I Need Your Critique to Become a Better Developer!

Jeff Puls — Mon, 18 Jan 2021 18:01:20 +0000

Calling all web dev professionals and aficionados, I need your help!

As anyone in the tech space who has gone the self-taught route can tell you, there are several times when you hit a mental brick wall on your journey. I have once again unfortunately found myself slamming face-first into this proverbial mental blockade, but this time I'm trying a different approach to getting over it.

Being the only tech-minded one among my family and friends, I spend much of my time learning and processing things on my own. While as an introvert this seclusion can be nice, I've come to realize that it has severely crippled my opportunity to advance to the next stage in my quest for knowledge. For the past few years, I have very much had only myself (with the exception of one semester with a very poor community college professor) to provide any sort of feedback on the work I have done up to this point.

My Ask

What I need from the wonderful DEV community is some constructive, creative criticism and critique of what I have done thus far. Without any outside review, I'm afraid I have no idea where my time is best spent improving.

If you can spare a few moments, I would greatly appreciate anyone who is willing to take a look at my work from both an overall conceptual design standpoint, as well as a more technical "behind the scenes" perspective focusing on things like performance and code cleanliness. Am I doing something consistently right? Wrong? Absolutely unheard of?

You can view the major projects I've done / am currently working on at my website, as well as everything on my GitHub. (Try to keep chronology in mind, as these things span back to the beginning of my journey.)

Please leave any feedback you have (positive or negative, I'm not looking for only sugarcoated praise, although that's always appreciated 😉) in the comments here, at the email listed on my GitHub, or through the contact form on my website.

Help me DEV.to, you're my only hope!

Quick and Easy 2D Spatial Audio with Howler.js

Jeff Puls — Mon, 11 Jan 2021 20:58:21 +0000

Creating immersion within a web application is hard. Unless a lot of effort is put into the UI/UX design, these apps end up feeling very flat and lifeless. As such, even the smallest feature that adds an organic touch can vastly improve the "feel" of the app.

If your application is very audio-centric (a game for instance), one such feature you can easily add is spatial audio. Giving your sound effect an origin within the application can make the whole thing feel bigger. Let's take a quick look at how this can be achieved using a JavaScript audio library called Howler.

I won't go into details about how Howler itself works, but you can read up on the subject in their docs here. For now, all you need to know is that we use the Howl constructor to instantiate a simple sound effect object, and that this object takes an optional parameter called stereo.

The stereo parameter accepts a number ranging anywhere between -1 and 1, which corresponds to the left/right channel bias for the stereo sound (-1 being full left, 1 being full right). For this example, we simply want to play a sound effect when the mouse is clicked, and we want it to feel as though that sound originates from the cursor.

Below is the basic setup for use in a React component. This will play the specified sound effect normally whenever the mouse is clicked within the component.

import { useEffect } from "react";
import { Howl } from "howler";
import mySound from "./sounds/mySound.webm"; // our fictitious audio file, replace this with whatever sound you want to play

const MyComponent = () => {
  let component;

  useEffect(() => {
    const handleClick = (e) => {
      const sound = new Howl({ src: mySound }); // instantiate a new Howl here, passing it the path to our sound effect
      sound.play(); //  as soon as the object is created, we can play the sound effect
    };

    component && component.addEventListener("click", handleClick); //  once the component has been rendered and saved to a variable, add the EventListener

    return () => {
      component && component.removeEventListener("click", handleClick); //  if the component is removed, remove the EventListener
    };
  }, [component]);

  return (
    <div
      style={{ width: "100vw", height: "100vh" }} //  adding the styling ensures that our component will cover the entire viewport
      ref={(el) => (component = el)} // save the rendered element to a ref variable we can manipulate
    />
  );
};

export default MyComponent;

Now, to figure out where the sound is coming from, we need to do some simple calculations based on coordinates of the cursor in relation to the width of the component. We will do so by adding the following function to the top of the useEffect callback.

const getStereoBias = (mouseX) => {
    const w = component.clientWidth; // grab the component's width
    const bias = -((Math.round(w / 2) - mouseX) / w) * 2; // calculate a value of -1 to 1 based on the cursor position within the component
    return bias;
  };

And finally, we will use this function whenever a sound effect is generated to tell Howler where the sound is coming from by modifying the handleClick function as follows.

 const handleClick = (e) => {
    const stereoBias = getStereoBias(e.clientX); //  calculate the "position" of the sound's origin

    const sound = new Howl({ src: mySound, stereo: stereoBias }); // instantiate a new Howl here, passing it the path to our sound effect and stereo bias "position"
    sound.play(); //  as soon as the object is created, we can play the sound effect
  };

And just like that, whenever our sound effect is played, it will follow the cursor around the screen (handy for things like particle effects in games)!

To view a fleshed-out example of this concept in action, check out my Domain Destroyer Demo project.

If you make something cool like this, drop it in the comments, I'd love to see what you come up with!

How to Destroy a Web Page - (Digital Ocean Hackathon Blog: Part 3 - Finale)

Jeff Puls — Sat, 02 Jan 2021 19:48:45 +0000

What I built

The domain-destroyer npm package and its accompanying React demo application.

Category Submission:

Random Roulette

App Link

https://domain-destroyer-demo-95ini.ondigitalocean.app/

Screenshots

Description

Welcome back to 1995!

As anyone who was into computers throughout the 90s will know, there was one type of software commonplace in every household. Shareware games. There were free-to-play versions of everything from AAA blockbuster titles like the Duke Nukem series and (literal) hidden gems like Crystal Caves, to one-man-band side projects, all available free of charge. One such program that spread like wildfire in this time was Desktop Destroyer (which went by several pseudonyms, depending who you ask and from which region they resided).

And so, I would like to introduce domain-destroyer, a (limited) clone of that iconic program, this time catering to stressed-out web devs who need to blow off some steam. Written in TypeScript, and available for hassle-free inclusion with Node based projects via npm.

In addition to the development of the npm package itself which contains the core game logic, assets, and mechanics, I developed an accompanying demo application utilizing React to showcase the game in all its intended nostalgic glory.

Brandishing 3 of the original 8 (well, 9 if you count the "washing" tool) implements of destruction, use your mouse to mercilessly inflict damage to the web page before you! Personal project got you stressed out? Quickly implement the npm package and smash it to smithereens with the Hammer, blast it to bits with the Machine Gun, or decimate it with the defacing powers of the giant Stamp. You'll feel better in no time, I promise!

Hotkeys:

key	function
`mouse`	fire weapon
`1 key`	hammer
`2 key`	machine gun
`3 key`	stamp
`c key`	clear screen
`- key`	previous weapon
`= key`	next weapon
`; key`	volume down
`' key`	volume up

Link to Source Code

domain-destroyer source code

demo application source code

Permissive License

MIT License

Background

I wanted to build something unique from the sea of TODO List apps and recycled Web Dev Bootcamp blogs that will no doubt be present. In addition, and in light of what an absolute horror-show stress-fest that 2020 was for nearly everyone (myself included), I figured I would take this opportunity to harken back to simpler times, if only for a fleeting moment. What better way I thought, than with a game that lets you literally take out your aggressions, while hitting you with a wave of nostalgia for those rose-tinted glory days at the same time.

How I built it

The core domain-destroyer package was written from scratch in TypeScript, and made publicly available via npm here.

The demo application was created utilizing React and is hosted via the Digital Ocean App Platform. The process of importing the React application via GitHub could not have been more straight-forward.

Additional Resources/Info

I would like to give credit to the developer of the original Desktop Destroyer game, Miroslav Němeček (and any others involved, this being the only name I could find in direct association).

The spatial audio effect was achieved using Howler.

If you love this project, and would like to help improve it (sadly I wasn't able to implement all the weapons/features from the original that I had intended), please feel free to fork the repositories and make it happen!

Making Animated Sprites Interactive with JavaScript! - (Digital Ocean Hackathon Blog: Part 2)

Jeff Puls — Thu, 31 Dec 2020 20:25:08 +0000

If you haven't yet read my previous post in this series, I would highly recommend doing so before you continue with this post, things will make a lot more sense!

So, if all has gone according to plan, we now have our Link sprite marching bravely in place in the center of the screen. 10/10 graphics, but it falls short in the gameplay category. Luckily, interacting with our hero is only a couple HTML/CSS tweaks and a JavaScript file away!

Below are the new sprite sheets I will be using in this project, feel free to save them to your project directory and code along!

Modifying the HTML/CSS

Okay, we will start off super simple with a couple of tweaks to our original HTML file. In order to keep our spritely friend from wandering off screen, let's give him some boundaries.

To do this, simply wrap the sprite-view-frame div element with another div, this one with a class of container. The body of your HTML should now look as such.

<body>
  <div class="container">
    <div class="sprite-view-frame">
      <div class="sprite-renderer"></div>
    </div>
  </div>
  <script src="script.js"></script>
</body>

That will do it for the HTML, now to change some things around in the CSS.

Let's begin with introducing a few new variables under :root. These are --sprite-top, --sprite-left and --sprite-sheet-url. The names of which should be a pretty obvious giveaway as to their purpose. Make sure your code looks like the following.

:root {
  --sprite-width: 64px;
  --sprite-height: 64px;
  --sprites: 2;
  --animation-length: 0.5s;

  /* these are the values that we will modify via JavaScript to interact with the sprite */
  --sprite-top: 50%;
  --sprite-left: 50%;
  --sprite-sheet-url: url("./link-spritesheet-down.png");
}

Next, let's style our new container element. Make special note that it purposely does not fill the entire width of the <body>.

.container {
  width: 90%;
  height: 90%;
  position: relative;
  top: 5%;
  left: 5%;
}

After that, we need to make a slight modification to the sprite-renderer. Here, we will replace the hard-coded background-image with the variable we set in :root

 background-image: var(--sprite-sheet-url); /* the sprite sheet */

And then, move the animation property to a new selector, this time only being active when the sprite-renderer also has a class of .animating;

/* the sprite will only animate when the 'animating' class has been set */
.sprite-renderer.animating {
  animation: animateSprites var(--animation-length) infinite
    steps(var(--sprites));
}

One last modification to note is the addition of a short transition-duration to the sprite-view-frame. This will help smooth out the movement of the sprite across the screen.

transition-duration: 0.05s; /* adding a short duration here will smooth out the animation when moving the sprite */

That wraps up the modifications to the HTML/CSS!

Making it interactive with JavaScript

Alright, we made it to the meat-and-potatoes of the post once again! It's finally time to take this animation and turn it into an interactive "game" (I use that term very lightly here).

It will be assumed here that you have working knowledge of basic vanilla JavaScript

After creating a script.js file in your project directory, we need to start with setting up some variables. We need to gain access to our container element, as this will be our :root in CSS. We also need to be able to modify the classList of the sprite-renderer element, so we will grab that too.

// grab our elements to be modified
const root = document.querySelector(".container");
const spriteRenderer = document.querySelector(".sprite-renderer");

Next, let's set some variables to track where our sprite is positioned within the container. For this, we will use three built-in functions parseInt(), getComputedStyle() and getPropertyValue() to get the numerical value of our initial --sprite-top and --sprite-left CSS variables.

// grab the initial values where we placed the sprite in CSS
let spriteTop = parseInt(
  getComputedStyle(document.documentElement).getPropertyValue("--sprite-top")
);
let spriteLeft = parseInt(
  getComputedStyle(document.documentElement).getPropertyValue("--sprite-left")
);

The last variable we need to track is the direction our friend Link is facing.

let spriteDirection = "down"; // set an initial direction for the character to face

To make Link react to the standard W A S D movement keys, let's add a keydown listener to the document.

document.addEventListener("keydown", (e) => {}

The following code will be within the callback function of the EventListener

When a key is pressed, we want to begin by checking if that key is one of our desired directional keys. If not, we ignore the keypress, this saves on computation resources.

  // the following code will only run if we have pressed one of our directional keys
  if (!["w", "a", "s", "d"].includes(e.key)) return;

If the key pressed is valid, we move to a switch block to decide what variables need to be changed, depending on the intended direction.

// set up directional keys for moving the sprite (w, a, s, d)
  switch (e.key) {
    case "w":
      spriteDirection !== "up" && (spriteDirection = "up"); // change direction if not already facing up
      spriteTop >= 0 && (spriteTop -= 1); // move the character up if not at the edge
      break;
    case "s":
      spriteDirection !== "down" && (spriteDirection = "down"); // change direction if not already facing down
      spriteTop <= 100 && (spriteTop += 1); // move the character down if not at the edge
      break;
    case "a":
      spriteDirection !== "left" && (spriteDirection = "left"); // change direction if not already facing left
      spriteLeft >= 0 && (spriteLeft -= 0.5); // move the character left if not at the edge
      break;
    case "d":
      spriteDirection !== "right" && (spriteDirection = "right"); // change direction if not already facing right
      spriteLeft <= 100 && (spriteLeft += 0.5); // move the character right if not at the edge
      break;
    default:
      break;
  }

Next, we will tell the CSS which sprite sheet it should be using (note that we need to set the entire url() string here due to the way CSS parses variables.

root.style.setProperty(
    "--sprite-sheet-url",
    `url(./link-spritesheet-${spriteDirection}.png)` // tell the CSS what sprite sheet to use based on direction
  );

With our sprite now facing the correct direction, we'll let the CSS know to start animating the sprite.

spriteRenderer.classList.add("animating"); // tell the CSS that we want to animate the sprite

Last but not least, we will tell the CSS to move the sprite to the new coordinates calculated in the switch statement.

// move our sprite to the new coordinates
  root.style.setProperty("--sprite-top", `${spriteTop}%`);
  root.style.setProperty("--sprite-left", `${spriteLeft}%`);

The finish line is in sight! Just one more piece of JavaScript to take care of. This time, we just need to tell the CSS to stop animating the sprite when we release the key.

document.addEventListener("keyup", () => {
  spriteRenderer.classList.remove("animating"); // when the key is released, stop animating the sprite sheet
});

WHEW!

If all has gone according to plan, you should now be able to make Link walk in all 4 directions across the screen! How's that for gameplay!? (I told you I was using "game" very lightly here 😂)

Conclusion

In the third and final post to this series, I will be introducing what I have created with all of these concepts for the Digital Ocean Hackathon. (Spoiler alert: if you were a kid growing up in the 90s with access to a computer running Windows 3.1 or higher, there's a good chance you've played this before!)

Stay Tuned!

DISCLAIMER:
I did not create, nor do I own any of the pixel art depicted in this post, I simply edited it such that it meets the requirements for this project. Credit for the sprites used goes to RetroGameZone.

Simple Sprite Animations for Games on The Web - (Digital Ocean Hackathon Blog: Part 1)

Jeff Puls — Wed, 30 Dec 2020 22:28:56 +0000

One of the greatest advantages to building applications for the web is the low barrier to entry when it comes to easy, yet powerful graphics and animation.

It's no secret, HTML and CSS make up the backbone of everything you see and interact with on the Web. Once you add a splash of JavaScript, you can have your own fully-featured application, able to be used by anyone all over the world. What goes great with simple, powerful graphics and an intuitive programming language? Video games, naturally!

(a quick preface here, I don't want you to expect to crank out the next Call of Duty in your web browser after reading this series of tutorials, but something akin to a basic NES-style game? Sure, why not!)

If you don't care about the background and want to get to the meat-and-potatoes of this post, skip to this section.

Background: The Humble Sprite

What is a sprite anyways?

There are two basic categories when it comes to video game graphics: 2D and 3D. This post focuses on the prior, as it is the quickest and easiest to get going without needing any additional libraries, software, or prior graphics knowledge.

The most basic method of creating graphics and the illusion of motion for 2D games is by implementing a special set of images, known as sprites. At the core, a sprite is just an image which can be used to represent an entire object, or cleverly combined with other sprites as part of a larger whole. In the olden days of video game development, this was the go-to method for rendering graphics before 3D graphics tech had matured.

A sprite can be anything you want. Something as simple as a single-pixel square can represent the flying ball in Pong, or an elaborately illustrated character of your own design, the limits are only that of your own imagination.

How does sprite animation work?

We humans like to believe that we are super intelligent beings, that nothing can fool us. In reality, that couldn't be farther from the truth, especially when it comes to how we process visual information. If we view a series of similar images displayed in rapid succession, our brains have a hard time deciphering what is going on, and simply assumes it is the same object, just moving.

Sprite animation exploits this phenomenon at the most basic of levels. Typically, sprites for similar objects are all combined into one, larger image known as a sprite sheet, each individual sprite can be thought of as individual frames of a video. All the computer has to do to trick our meager caveman brains is to rapidly switch which part of the sprite sheet is displayed. Done right, we think we see our game's hero bravely marching into battle for instance, when in reality, its just the same two images being rapidly flipped back-and-forth.

For the purposes of this post, I am going to limit the examples to 8-frame, single-row sprite sheet examples, however you can in theory use as many frames as you'd like!

Example

Here is a very simple example of how the walking animation for Link from The Legend of Zelda on the NES works. Note how there are two distinct frames side-by-side in one image, this is the sprite sheet. (If you're coding along, you can save the sprite sheet PNG below to the same directory as your HTML and CSS files).

By rapidly switching between sprites, you get the basic walking animation!

Getting set up

The HTML

This post assumes that you possess a basic working knowledge of HTML/CSS, although if not, the concepts here should be pretty easy to follow.

We will begin with the basic HTML5 boilerplate, with the inclusion of a <link> tag to our CSS and <script> tag to a JavaScript file that we will create in the next part of this series:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <link rel="stylesheet" href="styles.css">
    <title>Sprite Animation Demo</title>
</head>
<body>
     <script src="script.js"></script>
</body>
</html>

The following elements will all be included within the <body> of the document, before the <script> tag.

<div class="sprite-view-frame">
    <div class="sprite-renderer"></div>
</div>

Here, you can imagine the sprite-view-frame as a picture frame that crops the visible portion of the image (a single sprite). The sprite-renderer will be the element that holds the entire full-size sprite sheet.

That's it for the HTML... no, really!

The CSS

Animating sprites in this manner only requires some very basic CSS properties to be set, I will explain what is necessary and why below. Begin by creating a styles.css file in the same directory as your HTML file. The sprite sheet we will be using in this example contains two 32px by 32px sprites, giving us total dimensions of 64px by 32px.

First, lets set some basic properties to make the body a bit nicer to look at.

body {
  background-color: #222222;
  height: 100vh;
  margin: 0;
  position: relative; /* this allows us to center the sprite-view-frame on the page */
}

Now, we can set some CSS variables to keep our code DRY later in the project. Simply adjust these values based on the sprite sheet in use:

:root {
  --sprite-width: 32px;
  --sprite-height: 32px;
  --sprites: 2;
  --animation-length: .5s;
}

Next, we will style the sprite-view-frame element. Note that the position, top, left, and transform properties will become more important later when we make our sprites interactive.

.sprite-view-frame {
  width: var(--sprite-width);
  height: var(--sprite-height);
  overflow: hidden; /* this will hide any sprites outside of the frame*/

  /* position the view frame on the page */
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate3d(-50%, -50%, 0);
  /* ********************************** */
}

After we have a frame to display the sprites, we can style the sprite-renderer element itself, which will be used to display and animate the sprite sheet.

.sprite-renderer {
  width: var(--sprite-width);
  height: var(--sprite-height);
  background-image: url("./link-spritesheet-1.png"); /* the sprite sheet */
  background-repeat: no-repeat;

  /* this prevents the browser from aliasing our pixel art image and making it blurry */
  -ms-interpolation-mode: nearest-neighbor; 
  image-rendering: -webkit-optimize-contrast;
  image-rendering: -moz-crisp-edges;
  image-rendering: -o-pixelated;
  image-rendering: pixelated;

  /* this is where the magic happens! */
   animation: animateSprites var(--animation-length) infinite steps(var(--sprites));
}

Finally, the most important part: the animation itself!

@keyframes animateSprites {
  0% {
    background-position: 0px;
  }
  100% {
     background-position: calc(var(--sprite-width) * var(--sprites) * -1);
  }
}

Basically, all our CSS needs to do is rapidly shift the background image of the sprite-renderer to display each sprite. The initial state of the animation will bring the first sprite (on the left) into view. Then, it will shift the image to the left by the total width of the sprite sheet, thus displaying the last sprite (on the right).

Here is a breakdown of what the animation property within .sprite-renderer is doing:

animation
- animateSprites | the name of the keyframes we defined
- var(--animation-length) | the entire animation lasts .5 seconds, or .25 per frame
- infinite | the animation will loop forever
- steps(var(--sprites)) | This is the most important part! This tells CSS that for each sprite, render that stage of the animation as a distinct frame, rather than interpolating between start and end states.

That's it!

If you open your HTML file in the browser, you should now have an animated Link marching in place on your screen.

The process for creating more detailed, higher frame rate sprite animations is largely the same. The only differences you need to account for in the CSS are the variables --sprite-width, --sprite-height, --sprites and optionally --animation-length.

Below is an example of an 8-frame sprite sheet, again featuring our friend Link, this time from A Link to the Past on the SNES. This sprite sheet is a bit larger than our previous example, featuring eight 64px by 64px sprites, for total dimensions of 512px by 64px:

We need only to tweak the CSS as follows:

:root {
  --sprite-width: 64px;
  --sprite-height: 64px;
  --sprites: 8;
  --animation-length: .8s
}

And when animated, you get this!

Conclusion

You now possess the knowledge needed to animate your very own sprites, using some very basic HTML and CSS!

In my following post, we will dive into the code behind making your characters interactive with JavaScript!

Forem: Jeff Puls

Is React Holding You Back?

The Alluring Trap of React

What Went Wrong?

The Ultimate Decision

The Result

I Need Your Critique to Become a Better Developer!

Calling all web dev professionals and aficionados, I need your help!

My Ask

Help me DEV.to, you're my only hope!

Quick and Easy 2D Spatial Audio with Howler.js

How to Destroy a Web Page - (Digital Ocean Hackathon Blog: Part 3 - Finale)

What I built

Category Submission:

App Link

Screenshots

Description

Welcome back to 1995!

Hotkeys:

Link to Source Code

Permissive License

Background

How I built it

Additional Resources/Info

Making Animated Sprites Interactive with JavaScript! - (Digital Ocean Hackathon Blog: Part 2)

Modifying the HTML/CSS

Making it interactive with JavaScript

WHEW!

Conclusion

Stay Tuned!

Simple Sprite Animations for Games on The Web - (Digital Ocean Hackathon Blog: Part 1)

Background: The Humble Sprite

What is a sprite anyways?

How does sprite animation work?

Example

Getting set up

The HTML

The CSS

That's it!

Conclusion

Stay tuned!