Forem: Philip Warkentien II

Desert Racer 🏜️: World's First CSS-only Swipe-Aware Game!

Philip Warkentien II — Wed, 27 Mar 2024 13:20:00 +0000

A CSS-only, no JS, no checkbox, swipe-aware (scroll-aware) game. With config options and music!

Intro

I built Desert Racer to showcase the unique and unorthodox tricks of CSS-only Swipe Awareness and CSS-only Collision Detection. I believe these tricks to be the first of their kind. You're welcome to challenge these claims. This article covers the aforementioned tricks, plus the overall process of building a Swipe-Aware game.

Checked again today – March 27th, 2024 – and Gemini (Google's new AI) still believes swipe awareness to be impossible.

transcription:

👨 — "Can I achieve bi-directional swipe detection with only CSS and HTML?"
🤖 — "No, achieving bi-directional swipe detection with CSS only and HTML is not possible. CSS lacks the functionalities needed to determine the direction and intent of a swipe gesture."

✨ Creativity is not yet obsolete! ✨

Is CSS the right tool for this job? Not at this moment. However... CSS has been offloading JavaScript event handlers. Hopefully, this article contributes to that goal. Either way, as somewhat of an artist myself, building things with the wrong tool – for the sake of debunking something considered impossible – is a natural impulse. I had a hunch that it would work, and it did.

This article will be interactive and hopefully inspiring. So, stick around! (Or at least scroll to see the cool GIFs)

The idea
Building a swipe-aware game
1. Primary obstacles (idea validation)
2. Fine-tuning the mobile UX
3. Secondary obstacles
Lessons learned
Kudos
Credits
FAQ

1. The idea

On October 6th, 2023, I caught wind of a brand-new CSS feature: scroll-driven animations. All thanks to Bramus' excellent expository article. Later that night I WhatsApped myself the following idea:

👨 — "X and Y scroll-driven animations with snap-to-center when released to emulate swipe detection!!!! Hide the scrollbar with CSS."

You can feel the excitement with all the typos, the misplaced comma, missing article, and missing preposition. Could I achieve swipe awareness without JavaScript? This idea grew into this HTML and CSS-only game you see today. Go test-drive, then come back to see how I built it.

📙: Original CSS background, assets generated with AI, music from Pixabay.

📙: scroll-timeline is only supported by Blink/Chromium browsers (Chrome Desktop, Edge Desktop, and Chrome for Android). For iPhone users: Chrome for iOS is just Safari with a skin, so use Chrome on your MacBook (that we all know you have).

2. Building a swipe-aware game

This process demanded multiple prototype validations, adapting, refactoring, and inventing never-before-seen CSS tricks (which can lead you down an exploration rabbit hole).

⚠️ Keep in mind that at the time I created this game I wasn't aware of the space toggle hack. So the entire logic of this game relies on CSS properties that accept numerical values. For instance.: I could manipulate animation-duration but not animation-play-state.

Are we swiping or scrolling?

Under the hood, we are using CSS scroll properties and the experimental scroll-timeline 🧪. However, for touch devices and trackpads, the real-world action is literally to swipe, hence the name swipe-detection. I made this as a swipe-first game with a Mouse-wheel-detection fallback. If your mouse supports side-scrolling, remember to activate the mouse input setting on Desert Racer's home screen.

2.1.: Primary obstacles (validating ideas)

· 2.1.a.: Achieving bi-directional scroll-driven animation

The first thing I needed to validate was if I could control my timeline by scrolling on both axes. At first, I got misled by the scroll-timeline-axis property definition, since accepted values were only unidirectional (x, y, block, and inline). To bypass this I nested two scrollable containers to handle each axis. This is still the solution used for mobile, as it limits motion and avoids accidental horizontal motion while swiping up and down.

Over halfway through the project, I ran into Bramus' clever single-element bi-directional solution: comma-separated scroll timelines! It's obvious after you see it. I don't automatically think a new CSS property has comma support, so it didn't cross my mind.

Snapping back to center

What differentiates this technique from a normal scroll-driven animation is two-fold: Purpose and Repeatability.

Purpose: we are not scrolling to animate the content but to detect the swipe. The DOM stays fixed, only --x and --y values update.
Repeatability: by snapping back to center, we can repeat our action as much as we need. We wouldn't want a scroll box that always restarts, but we do want to be able to swipe again.

💡: [ Previous Art ] Adam Argyle also mixed scroll animation + scroll snap to mimic a mobile's "refresh page" swipe interaction. Article 👏

Main trick

We use two separate scroll timelines to control changes in the horizontal and vertical axes. For the scroll-timelines to activate we need the content to be larger than the scroll wrapper – as you would expect. Depending on the goal of your game we can have any size grid (3x3 recommended). We can also decide on snapping or not snapping back to the center. For Desert Racer the jump axis (y-axis) snapped back to the ground level, but changing lanes didn't trigger a snap action. You can also use Houdini's @property declaration to achieve interpolated values between 0 and 1, thus making the swipe detectable to the smallest movement. With this, you can create motions such as drawing circles.

Use the settings ⚙️ menu to play with different swipe-aware configurations.

📙: Settings menu was also written in pure CSS, because "why not?"

· 2.1.b.: Detecting collision

To detect collision I check if the vehicle's current cell is also an obstacle cell.
--collision-on-cell-4: calc(var(--vehicle-on-cell-4) * var(--obstacle-on-cell-4))

Broken into steps:

Detect what cell the vehicle is on by converting --x and --y swipe coordinates into their corresponding current grid cell. --cell-pattern-n represents --vehicle-on-cell-n E.g.: if our swipe coordinates are (-1, 0):

   --vehicle-on-cell-4: 1;

Place obstacles on the 3x3 grid. E.g.: for a tree on the left side of the road:

   --obstacle-on-cell-1: 1;
   --obstacle-on-cell-4: 1;
   --obstacle-on-cell-7: 1;

Detect collision if the current cell also has an obstacle.

   --collision-on-cell-4: calc(
     var(--vehicle-on-cell-4) * var(--obstacle-on-cell-4)
   );

You can see this logic in motion on .gif below:

· 2.1.c.: Animating a collision map over time

Animate the value of --obstacle-on-cell-k, where 1 ≤ k ≤ 9.

To simplify my work, I declaratively generated the animation. (With .SCSS)

$OBSTACLES: {
  (),
  (),
  (("tree", 1), ("tree-arch", 3)),
  (("tree-arch", 1), ("tree", 2), ("tree-arch", 3)),
  (),
  (),
  (("arch", 1), ("arch", 3)),
  (("rock", 1), ("rock", 3)),
  (("arch", 1), ("rock", 2), ("arch", 3)),
  (),
  (),
}

Each item represents a keyframe.

You can see obstacles animating across time on the .gif below:

📙: blue overlay for obstacles, red overlay for collisions

📙: Transparent floor lets you see how I planned subterranean obstacles to block under passage

· 2.1.d.: Immediately stopping the game after any collision

I check each cell for a possible collision and store those results on --collision-on-cell-k, where 1 ≤ k ≤ 9.
If the sum of all possible collisions is greater than zero, we have a collision!

Now the tricky part.

As soon as the animation ticks to the next keyframe the collision drops. So, how do I keep the collision state? Remember that I can't control non-numerical CSS properties, so I can't simply set animation-play-state: paused;. By changing the duration to animation-duration: calc(var(--virtually-infinite) * 1s); I also change the progress of the current animation. (E.g.: If I'm at 50% and suddenly increase the animation duration by 10x, the total animation progress will drop to 5%).

So what did I do?

I immediately slid in the Game Over screen, and set the slide-out transition to 31.7 years! This means that, unless you plan on waiting it out, the Game Over state is perceivably static.

Here's the code:

:root {
  --virtually-infinite: 1000000000s; // 31.7 years
}

.game-over {
  background: black;
  bottom: calc(var(--zero-collisions) * 200lvh);
  transition: bottom calc(
      var(--zero-collisions) * var(--virtually-infinite) + 1ms
    ) linear;
  z-index: 100;
}

On the split second that --zero-collisions is 0, bottom is set to 0 and transition-duration to 1ms. The trapdoor has fallen. --zero-collisions is once more set to 1, but it will take 31.7 to reset the trapdoor. If --zero-collisions is set to 0 in the background due to a secondary collision, we won't notice since the trapdoor is already down.

· 2.1.e.: Detecting victory

This one was easy. I set --you-win to true at the end of the round. The victory screen slides up – behind any possible Game over screens – and stays up.

@keyframes move-obstacles {
  // ...

  99.999% {
    --you-win: 0;
  }
  100% {
    --you-win: 1; // last keyframe
  }
}

.victory {
  transition: opacity 250ms ease-out;
  bottom: calc((1 - var(--you-win)) * 200lvh);
  opacity: calc(0.875 * var(--you-win));
  z-index: 99;
}

2.2.: Fine-tuning a swipe-first mobile UX

· 2.2.a.: Disabling native swipe-navigation

When you start creating a swipe-first mobile web experience, you quickly realize that the Browser already uses swipe-actions for things such as horizontal swipe native browser navigation, vertical pull-to-refresh gesture, toggling the address bar, and pinch-zooming.

Here's how we block it:

The contain value disables native browser navigation, including the vertical pull-to-refresh gesture and horizontal swipe navigation.

html,
body {
  overscroll-behavior: contain;
}

· 2.2.b.: Fixing vertical swipe layout shift

Vertical swipe toggles address bar visibility, which resizes the UI.
Solution: Tie layout mechanics to the bottom of the viewport.

.container {
  position: relative; // or absolute;
  height: 100lvh;
}

.game-view {
  position: absolute;
  height: 100svh;
  bottom: 0;
}

· 2.2.c.: Blocking pinch-zoom

<meta
  name="viewport"
  content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"
/>

.view {
  touch-action: pan-x pan-y;
}

2.3.: Secondary obstacles

· 2.3.a.: How to handle huge CSS files

To load very large CSS files, I created an old-school MPA (multiple-page application). This is a fancy way of saying that I loaded a different CSS file per page, thus allowing me to add multiple phases to this game without bloating the CSS file. However, since I was hopping between pages I couldn't hold state with checkboxes. So I decided to hold state with the URL and the:target selector.

body:has(
    :is(
        #color-1:target,
        #color-1--lowres:target,
        #color-1--mouse:target,
        #color-1--lowres--mouse:target,
        #color-1--muted:target,
        #color-1--lowres--muted:target,
        #color-1--mouse--muted:target,
        #color-1--lowres--mouse--muted:target
      )
  ) {
  --car-color: 1;

  .dynamic-link:nth-of-type(1) {
    display: inline-block;
  }
}

· 2.3.b.: How to animate as much as 126 obstacles in a single phase in 3D space

I don't, GPU doesn't handle animating 126 obstacles in 3D space, so it's just an illusion. All obstacles are hidden and fixed at a given distance, and only animate toward the screen on cue animation-delay. This way we don't have more than a couple dozen obstacles animating in any given time.

other tricks

will-animate, contain: strict, backface-visibility: hidden (This goes beyond the scope of this article)

· 2.3.c.: How to auto-play sounds

It's as straightforward as placing <audio autoplay> elements in your HTML documents and hiding them with CSS.
For the muted option, use a separate HTML document without <audio> tags.

· 2.3.a.: How to persist state between page changes

By storing the car color and game config state on the URL and reading it with the :target selector. However, for audio on and off I directly rendered a page with or without <audio> tags, since there is no way to turn audio on and off without JavaScript.

3. Lessons learned

It's incredible how much we can create with the current state of CSS math and CSS logic. GrahamTheDev is here to prove it!

I'll leave a single Lesson Learned: Keep CSS variables unit-free until the very end, which is until you have to use it. I'm not the first person to say this, but it's worth the emphasis.

width: calc(var(--complex-logic) * 1vw);

4. Kudos

I'd like to thank a few developers who indirectly contributed to this project by providing such quality educational content.

Kudos to Bramus
- for all the great tutorials on scroll-driven animations.
- for the clean bi-directional scroll-driven animation setup.
Kudos to Jamie Coulter
- for raising the quality bar on CSS-only games.
  - You so masterfully showcased the power of checkboxes, that I purposefully refrained from using them
Kudos to Amy Kapernick
- for spreading the word about HTML state storing hack with :target
  - Car color and configuration options were stored in :target
Kudos to Kevin Powell

for spreading the word about named grid lines.

The home page's highly dynamic Bento Style Grid wouldn't be possible without it!

   /* 
       I pretty much only had to reset these two properties per media query. 
       7 grid sections styled across 11 @media definitions totaled 22 style declarations.
       The traditional grid-area approach could need as many as 77 style declarations.
       e.g.:
   */

   .bento-box {
     grid-template-columns: [header-start display-start] 4fr [display-end share-start actions-start specs-start] 3fr [header-end share-end config-start] 1fr [config-end actions-end specs-end];
     grid-template-rows: [header-start config-start] 1fr [header-end display-start share-start] 0.75fr [config-end share-end actions-start] 1fr [actions-end specs-start] 1.5fr [display-end specs-end];
   }

   @media screen and (max-width: 1300px) {
     .bento-box {
       grid-template-columns: [header-start config-start display-start] 3.25fr [config-end display-end actions-start specs-start share-start] 3.875fr [header-end display-end actions-end specs-end share-end];
       grid-template-rows: [header-start] 0.875fr [header-end config-start actions-start] 0.625fr [config-end display-start] 0.125fr [actions-end specs-start] 1.5fr [specs-end share-start] 1fr [display-end share-end];
     }
   }

   @media screen and (max-width: 1000px) {
     .bento-box {
       grid-template-columns: [header-start config-start display-start specs-start] 2.75fr [config-end display-end specs-end actions-start share-start] 1.5fr [header-end actions-end share-end];
       grid-template-rows: [header-start] 1.125fr [header-end config-start actions-start] 0.75fr [config-end display-start] 2fr [actions-end share-start] 2fr [display-end specs-start] 2.5fr [share-end specs-end];
     }
   }

   /* ... 8 other queries */

Kudos to LEGO® Friends Heartlake Rush
- for the UI and gameplay inspiration!

5. Credits

Assets and UI

Ground and Sky — CSS art — by warkentien2
Irregular road — SVG designed in Figma — by warkentien2
Obstacles — by warkentien2
- AI-generated obstacles — AI Art Generator
- AI background removal — remove.bg
- AI image to pixel art conversion — Pixelied
- Sprite sheet generation - Pixlr Express
Vehicle — by warkentien2
- AI-generated vehicle — Recraft
- AI background removal — remove.bg
- AI image to pixel art conversion — Pixelied
- Drawing details and cropping — PixilArt
- Comping and enhancing assets — Pixlr Express
- Color variations and sprite sheet generation — Pixlr Express
Dust adapted from Esteban Díaz's Youtube channel
Image Landscape — by warkentien2
- AI-generated scenery — Recraft
First sketch

Sound snippets and soundtrack

Home — revving — by warkentien2
All phases — driving noises — by warkentien2
Phase 1 — Dark Country Rock — by moodmode
Phase 2 — Western Cowboy — by Music_For_Videos
Phase 3 — Tumbleweed Tango — by moodmode
Phase 4 — Excess Voltage — by moodmode
Phase 5 — Spirit of the Road — by SergePavkinMusic
Phase X — Cowboy Redemption — by Music_Unlimited

6. FAQ

Go to Desert Racer's F.A.Q. section at the bottom of the homepage.

Thank you for reading!

You're welcome to ask questions and speak your mind.

Follow me on X, @warkentien2

Curious Geckos 🦎🦎🦎: The Most Precise CSS-only Position-Aware Mini-Game!

Philip Warkentien II — Wed, 27 Mar 2024 13:15:00 +0000

A CSS-only, no JS, no checkbox, position-aware (hover/touch aware) interactive gecko-luring pastime!

TL;DR I revisited an old CSS-only hack with new CSS features and some ingenuity to bypass rendering limitations and achieve as much as a 25.6x precision gain over the best previous solution – getting much closer to native position awareness! Try out the mini-game, play with just the “debounced CSS algorithm,” and if you are in a rush, start reading from Section 2.

Intro

We're gathered here today to gain awareness about an ingenious CSS trick I call CSS-only Position Awareness. We could also call it Position-Aware CSS, but it fails to unambiguously state that no JavaScript was used.

It's based on a known trick, but, as you'll soon find out, CSS :has enabled us to push it further. And so we did. Besides, AI still has no clue about it and maybe neither do you. Here's what ChatGPT had to say this morning – March 27th, 2024:

transcription:

👨 — Is it possible to achieve position-awareness with only CSS and HTML?"
🤖 — "No, it's not possible to achieve position-awareness using only CSS and HTML. JavaScript is necessary to interact with the mouse events and update CSS properties or HTML content based on the mouse's position."

This article will be interactive and hopefully inspiring. So, stick around! (Or at least scroll to see the cute photos)

The Idea
Position Awareness
Building a Position-Aware Game
Cast and Credits
Previous Art
FAQ

1. The idea

Back in September 2023, I was custom styling a <table> component and ran into a fun use case for the :has() pseudo-class. Without resorting to a "CSS-grid table," but using the actual – correct and accessible – <table> markup, I could now highlight not only the row but also the column being hovered!

See it in action:

💡: [ Fun fact ] Sten Hougaard discovered this same trick a month later and got featured on CodePen's Instagram. 👏

What stood out was how little CSS I needed to write. All it took was 37 lines of pure CSS to highlight a 7-column table by any given number of rows. What if I needed more columns? Could I refactor this CSS algorithm to support any number of columns? While digging for this answer I stumbled upon something else, a better algorithm for CSS-only Position Awareness. And that's where the game comes in.

Before we get all scientific, let's play the mini-game!

📙: Supported on all devices and modern browsers. For the best mouse-tracking UX try Chrome Desktop (or Edge Desktop)

This was all achieved without a single line of JavaScript! You're welcome to double-check and disable JavaScript on your browser.

2. Position Awareness

A code is position-aware when we can pinpoint the --x and --y coordinates of a cursor on the screen and make these values available for any element on the page. To achieve this without JavaScript requires a position grid to detect which subsection of the screen is being hovered. Ideally, we would have a position cell per pixel, but we aren't there yet. We might, however, be just a Moore's Law cycle away.

Previous iterations of the Position Grid were modest, only tracking 4 quadrants and calling it Direction Awareness. It evolved into 10x10 grids (100 cells) called Mouse Tracking, some as large as 16x16. However, Mouse Tracking was not the best name for something that should include track pads and touch devices. Now it evolves once more, with the addition of :has and dynamic rendering. I present to you the Position Awareness grid, with 81x81, 6561 cells!

There's a catch to Position Awareness: we change the expected behavior of hovering on a page. Instead of tracking :hover interactions with DOM elements, we are tracking interactions with subsections of the screen.

Here's a “debounced” Position-Aware CSS algorithm in action:

🖱️💻 : Intended for mouse and trackpad devices.

📙: 81x81 grid for Desktop, 27x27 grid mobile

2.a.: Precision Gains

Previous approach was achieved by placing non-nested cells before a target element, and transferring placement coordinates through the “any sibling ahead” selector .cell:hover ~ .position-aware-element. This overloads the wrapper component with a huge number of child nodes and can impact performance.

Here's a brute-force image generated by painting each pixel with CSS to illustrate what happens when we style too many elements. Hit play at your peril 😱.

Current approach takes advantage of the :has() pseudo-class which supports nested position cells. By nesting a single level deep we reduce the max number N of children cells to the square root of N. E.g.: a previous shallow position grid with 100 children cells can now be represented with 10 children, each with 10 children. This way, every single cell has only at most 10 children. Imagine if we nest even deeper! This two-level approach hits a performance cap at around 33x33 (1089 points of awareness). This is the resolution I'm using for Curious Geckos. Beyond that limit I would need to create dynamically rendered grid subsections, like I showcased on the blue Position-Aware CSS example above. This is similar to how 3D game engines dynamically increase the level of detail on elements near the camera.

📙: More on this in a future article

3. Building a Position-Aware Game

Now that we have a Position-Aware Grid filled with (x, y) coordinates, how do we go from --x and --y values to a working mini-game?

Here's the trimmed version of the steps:

3.1.: Feed --x and --y coordinates into the 🪰(fly) and 🦎(gecko) wrappers

@for $i from 1 through 33 {
   .position-aware-container:has(tr:nth-child(#{$i}):hover) {
      :is(.fly__wrapper, .gecko__placement) {
      --y: #{($i - 1) * $axis-step};
      }
   }

   .position-aware-container:has(td:nth-child(#{$i}):hover) {
      :is(.fly__wrapper, .gecko__placement) {
      --x: #{($i - 1) * $axis-step};
      }
   }
}

3.2.: Use CSS calc to rotate the 🪰(fly) by a centrifugal angle

3.3.: Create SVG puppets for the geckos:

· 3.3.a.: A Puppet, also known as a Rig Model, is a technique used for animation. You might have seen it before on my portfolio

📙: More on this in a future article

· 3.3.b.: Group each body part in a hierarchical structure. E.g.: If I rotate the shoulder, the entire arm rotates.

· 3.3.c.: Anchor geckos by their thorax to facilitate head angle calculation:

--head-angle: max(
   var(--min-head-angle),
   // limit CCW head rotation
   min(
      var(--max-head-angle),
      // limit CW head rotation
      calc(
         (atan2(var(--dy), var(--dx)) * var(--head-angle-intensity, 1)) - calc(
               (
                  var(--head-initial-rotation, 0) * var(
                     --head-angle-intensity,
                     1
                     ) * 1deg
               ) + var(--head-angle-correction, 0deg)
            )
         )
   )
);

· 3.3.d.: Split the head rotation in three for a more natural motion:

.gecko__neck__body {
   --rotate-member: calc(var(--head-angle) * 1 / 6);
}
.gecko__neck__head {
   --rotate-member: calc(var(--head-angle) * 1 / 3);
}
.gecko__head {
   --rotate-member: calc(var(--head-angle) * 1 / 2);
}

3.4.: Set attack zones per gecko and per @media query.

3.5.: Detect attack zone :hover and trigger attack state

// ----- Gecko 1 attacks ----- //
:is(
   .gecko-trap-1_base,
   .gecko-trap-1_min200,
   .gecko-trap-1_min250,
   .gecko-trap-1_min300,
   .gecko-trap-1_min350,
   .gecko-trap-1_min450,
   .gecko-trap-1_max166,
   .gecko-trap-1_max150,
   .gecko-trap-1_max125,
   .gecko-trap-1_max100,
   .gecko-trap-1_max75,
   .gecko-trap-1_max66,
   .gecko-trap-1_max50
) {
body:has(& span:hover) {

Expand the hovered cell to full-screen. This locks hover to the last hovered cell. Locking the attack state.
Attack state freezes fly movement and animates the desired gecko.

3.6.: Slide in a pulsating call-to-action with a higher z-index, this will trigger the restart state.

3.7.: Add some flourishes:

tail animations
fine-tuned gecko placements to best fit the aspect ratio
Black and White gecko's resting arm changes position based on the @media query for best composition

3.8.: You're done!

4. Cast and Credits



      Super Hypo Tangerine Leopard Gecko - by Tamara Locke

      Oreo Whiteout African Fat-Tailed Gecko — by unknown

      Mandarin Tangerine Leopard Gecko — by CB Reptile

Geckos — SVGs designed in Figma — by warkentien2
- Scales by pattern.monster, thanks Naveen CS!
Fly - CSS art – by warkentien2
First sketch

5. Previous art (Post-project research)

Although many developers have tackled some form of Position Awareness, I would like to highlight a few:

Fabrice Weinberg, June 2013: 2x2 (first ever?) Direction-Aware Grid (Code)
Gabrielle Wee, Jan 2017: 4 cells. Beautiful direction-aware effect. (Code)
Gabrielle Wee, April 2018: 10x10 grid with 100 individual <a> tags and 100 individual style definitions. (Code) > "It would be smoother with more links but also would take longer to load, so I only used 100 instead of something like 1000." > – Gabrielle Wee's notes on this Pen
Christopher Joshua, Nov 2019: 16x16 grid with 256 individual <i> tags and 768 lines of CSS just for tracking. (Code)
Honorable Mention ⁽¹⁾ Jane Ori's amazing etch-a-sketch with an impressive 75x50 grid! (Code) Genius state tracking with the space toggle hack + animations. ______________________________________ (1): Honorable mention since it achieves Position Tracking but not Position Awareness. · 5.a.: Position information is dynamically set, not extracted. · 5.b.: Cell can't be hovered twice. · 5.c.: Regardless, it's impressive and deserves to be shared!

6. FAQ

Is this really a game? Well, it's as much of a game as playing catch is a game. ⚾ It's the reason I called it a mini-game ⚾ or a pastime.
Why make this? To Flex... and to Grid.
What do you mean by “no checkbox”?
- Most CSS-only games use checkbox for state management, but not this one.
- This game runs completely on :hover events, even to track victory/restart.
UX is jittery, can I improve it? Troubleshooting:
- Try Chrome Desktop or Edge Desktop for the best UX.
  - If you're a MacBook user, you can emulate Chrome inside Safari: Safari > Develop (tab) > Open Page With > Google Chrome
- Use a JS disabler (extension).
- If it's still slow, use Firefox or Safari Desktop for a debounced hover tracking experience.

Thank you for reading!

You're welcome to ask questions and speak your mind.

Follow me on X, @warkentien2

Forem: Philip Warkentien II

Desert Racer 🏜️: World's First CSS-only Swipe-Aware Game!

A CSS-only, no JS, no checkbox, swipe-aware (scroll-aware) game. With config options and music!

Intro

Table of contents

1. The idea

2. Building a swipe-aware game

Are we swiping or scrolling?

2.1.: Primary obstacles (validating ideas)

· 2.1.a.: Achieving bi-directional scroll-driven animation

Snapping back to center

Main trick

· 2.1.b.: Detecting collision

· 2.1.c.: Animating a collision map over time

· 2.1.d.: Immediately stopping the game after any collision

· 2.1.e.: Detecting victory

2.2.: Fine-tuning a swipe-first mobile UX

· 2.2.a.: Disabling native swipe-navigation

· 2.2.b.: Fixing vertical swipe layout shift

· 2.2.c.: Blocking pinch-zoom

2.3.: Secondary obstacles

· 2.3.a.: How to handle huge CSS files

· 2.3.b.: How to animate as much as 126 obstacles in a single phase in 3D space

other tricks

· 2.3.c.: How to auto-play sounds

· 2.3.a.: How to persist state between page changes

3. Lessons learned

4. Kudos

5. Credits

Assets and UI

Sound snippets and soundtrack

6. FAQ

Curious Geckos 🦎🦎🦎: The Most Precise CSS-only Position-Aware Mini-Game!

A CSS-only, no JS, no checkbox, position-aware (hover/touch aware) interactive gecko-luring pastime!

Intro

Table of Contents

1. The idea

2. Position Awareness

2.a.: Precision Gains

3. Building a Position-Aware Game

4. Cast and Credits

5. Previous art (Post-project research)

6. FAQ