DEV Community: Stéphane CHANGARNIER

Building a narrative game with Next.js and AI

Stéphane CHANGARNIER — Thu, 20 Mar 2025 13:31:38 +0000

Note: This article was originally published on my technical blog.

Context

"Noël Solidaire 2024", the previous game release, was an opportunity to experiment with generative images to create a custom background set based on a specific style.

This time, I wanted to dig deeper into those restyling capabilities to re-style some Montpellier places, my home base.

I imagined a small narrative game that would make players discover the city through the transportation network.

I then quickly elaborated a scenario of a student's journey that would have to travel the city to reach a train station through a commute transit.

Sets

At the beginning, I decided on which places would be seen and how a transit system could work. I selected some key tram stations with connections as stops.

Then I took some screenshots using Google Street View of each place.

Finally I used Dzine once again to restyle each screenshot using a personal model style. This style was computed from a bunch of artworks I selected for their artistic styles.

Often, getting the proper result needed multiple generations with revised prompts.

I got about 50 generated sets to cover the whole story.

Sound

The effects come from a sound library, however, the music is generated using Soundraw. I didn't spend a lot of time because I found the first generation satisfying.

Story

Dialogs

I started by gathering dialog ideas, then sorted them as dialog descriptions for each sentence. As I don't have any storywriting skills, I once again relied on AI to generate my dialogs based on the desired style, game context, scenes, and dialog descriptions using a mix of Perplexity, ChatGPT, and Mistral AI.

I found myself rewriting a lot of dialogs, but was surprised at how well they were globally crafted.

Nodes

Once all dialogs were ready, I needed a nodal system to organize dialogs for each scene. Instead of directly crafting a huge JSON object, I relied on a visual tool called Twine.

Twine is both a web tool and a desktop app that is assisting through the creation on non-linear stories with links between story nodes.

Once the nodes were crafted, we could simply export the story as a single HTML file.

The next step was to parse this file so that it could be handled by our Next.js app.

It was then just a matter of displaying the proper scene and dialogs using some states and logic.

Stack

As always, I kept using Next.js, Tailwind, and Framer Motion for development, and Figma for UI.

Development

The only workflow change was switching IDEs, from VSCode/Copilot to Windsurf/Cascade, as it was depicted as a more performant AI regarding the app context.

Overall, my experience working with Windsurf was positive, and I indeed found Cascade (the chat assistant) very clever regarding my global app context and what I was trying to achieve.

The Cascade "write" mode generated nearly 75% of my logic code, getting me into this "vibe coding" workflow.

I encountered some struggle though:

It messed up with some existing code, and I had to carefully create rules to avoid that
It often happened that Cascade entered an infinite change loop, iterating on itself without end. The only workaround was to restart Cascade, improve prompts, and be clear about doing simple changes one by one.
Files are getting bulkier as time goes by, as Cascade tends to aggregate dozens of functions in a single component file. We have to refactor explicitly and thoroughly retest the app afterwards.

A lot of problems are avoided by creating detailed and explicit Cascade rules and also what is called "memories".

The pricing is pretty affordable ($15/monthly) for the time-saving.

Wrapping up

The creative phase took about 1-2 weeks (brainstorming + visual creations) and the development phase took about 1 week.

This was a very pleasant and instructive way to develop the game using Cascade.

I just have some thoughts about us getting more and more assisted with AI (design, ideas, architecting, coding). While we are shipping faster, it also tends to soften us intellectually.

I don't know what to think at this stage. I just know things tend to evolve at an exponential speed these days...

Demo

Here is the playable game.

The game takes only 5-10 minutes.

It's in French.
"Correspondance" means "transit connection".

Building a food simulation game with Next.js and generative design

Stéphane CHANGARNIER — Sun, 08 Dec 2024 09:12:24 +0000

Context

The end of 2024 is almost there, and I have been asked by a french Bank to build a casual game for Christmas, as I have now done several in the past.

After we put ideas on the table, the one selected was a mini food simulation that fitted the most with the "charity" theme our client wanted to exploit.

I benchmarked a bit and kept some gameboard designs as a starting to point to build a game scene showing a kitchen workshop with a specific illustration style (some outlined adorable characters and assets nested within an heart-warming environment).

Goal

The game encourages the player to complete as many orders as possible within a given time. He will have to compose the proper food tray by picking up the right assets.

Generative design

There was a problem: as being both in charge of the graphic design and the development, the chosen style was not in my skillset. The one I master is a low poly 3D isometric.

It has been the opportunity to test a new creative workflow using AI tools to generate the needed environments in the specific style.

Dzine.ai

I tried some Stable Diffusion based tools, and the one I retained was Dzine.ai. An intuitive interface with predefined models and tools allowing a precise control over image content.

Sketch to image

The most efficient starting point was to compose the game background on an existing image.
Providing even an ugly sketch produce stunning results if accompagnied with a precise prompt.

The initial concept was a gift workshop, and here was the result I got providing the following sketch and prompt:

The scene is a 2D flat, viewed from a frontal camera at eye level.
It is a gift-making workshop in a cozy house.
On the upper part of the image: the wall, with a cozy brick, a window with curtains and snowy outside. On the right part of the wall: a shelf with christmas decorations.
On the lower part of the image: it's a workbench.
There is a two-level workbench.
On the higher level (a wooden table): some empty wooden boxes.
On the lower level, beneath the table:
On its right side: three rolls of gift wrap in different colors.
On its left side: three rolls of thin ribbons in different colors.
The overall ambiance is blue.

Image to image

When it was decided to go with a food simulation, I used a screenshot of Lili's Cafe, an existing mobile game I took as a model. Here are the result with a little refining through prompt:

Scene cleanup

The next step was to get a clean separated background, so that I can manage assets apart. For this, I used both the Dzine "erase" tool, and the Photoshop "content aware fill" tool. Here is the evolution:

Assets

At the beginning, I tried to populate the scene with assets using the "image-to-image" tool but the results were too weird.

So I decided to use the text-to-image on a blank canvas for every single assets, but using a proper trained model (based on some uploaded Lili's Cafe images).

I had to trigger a lot of generations for some, because it didn't match the result or angle I wanted.

The final action were background removals and generations flaws fixs.

Here are some examples:

Final gameboard

I composed the final scene on Photoshop, importing and refining assets after assets. Finally, I set the game user interface with Figma. Here are the scene without and with assets + GUI:

Stack

Not that much to say, because I utilized my well-established following technology stack:

Frontend: Next.js (v.15)
Backend: Firestore (Firebase) as users database
UI: Tailwind.css + ShadCn + Framer Motion

Development

The project is strongly based on our previous game releases (Blackout, Fin de Chantier, Vendanges Master.

Therefore, I re-used the same architecture and patterns I had built for these past ones.

I took advantage of the newly released "Copilot edits" feature that can simultaneously modify a set of files for us, based on a prompt. We just have to accept or discard the proposed solution.

This has been helpful as we often have to change multiples files to implement a feature.

Deployment(s)

The project has to be deployed on an Apache server, so bye-bye "on-the-edge" Next.js toolings, such as Server Actions, or any Node-based features. It's all client-side static export.

Wrapping up

It would have been an usual work if I didn't experiment the generative image workflow.

My opinion on this is still reserved:

on the one hand, these tools give us the ability to produce a large variety of design without being an expert.
On the other hand, editing generation is truly a pain in the a**.

We are in the early stages of this technology and struggling with it is part of the game.

But when I see how fast things are evolving, I think we can be confident that those struggles will tend to minimize as time goes by...

For the time being, the best way would still be to hire an illustrator expert in this style.

Demo

Here is the demo.

Building a mini casual game with Next.js

Stéphane CHANGARNIER — Wed, 17 Jan 2024 14:40:00 +0000

As a quick reminder: this post is not a step-by-step tutorial on how I built this game, but just a review of how I approached this project during this journey.

The game

First and foremost, here is the playable live game this post is about.

Goal

I took this game as an opportunity to improve on my technical skill and some creative processes.
We (with Pommeclic) decided to communicate early as a way to celebrate the new year by publicly offering a game contest with prizes to win.

Previously

I didn't start from scratch. I previously released a pretty similar game one year ago called Blackout.

The theme was the deep energy concern that occurs in Europe with the Ukrainian/Russian conflict.

It takes the "whac a mole" concept and adapt it to electrical units to turn off as soon as they turn on.

I decided to reuse most of the layout and principles in order to save time and focus more on the design and game logic.

New Concept

I kept the same isometric gameboard to support the action. After a bit, I was inspired by the story of the controversial A69 highway construction.

The idea is to prevent vehicles to arrive on site, to postpone the start as much as possible, so that I can keep the "whac a mole" principle, with moving target this time.

Stack

I used Sveltekit for Blackout. Though I enjoyed its light syntax, I struggled with lacking features, especially having dynamic optimized assets.

I also wanted to refocus on React through Nextjs, to avoid having an overly dispersed knowledge.

I decided to go with the same stack regarding the rest:

Firebase as backend (auth + user data)
Tailwind as UI framework
Vercel as hosting

Design

Environment

I kept modeling using Cinema 4D to get the same low poly look & feel, this time designing a hilly countryside crossed by main roads, as well as tunnels. Those lanes will be the interactive part of the map.

I then adapted predesigned construction vehicles, simplified and uniformized their styles. I rendered them in the 4 perspectives for which they will be used.

I defined the animated flags and smokes and rendered them as GIFs through After Effects.

UI

As usual, I started with some Figma screens, based on the previously designed Blackout UI, and replace the environments. Overall, the UI stays the same. Some light improvements have been made here and there.

Coding

Migration from Svelte

I undertook to migrate the most of my previous Svelte codebase into a NextJs one, using the now established app router. Most of the time, it was just a matter of mirroring structure, replace with the proper framework attributes syntax (class= becomes className=).

Though a lot of functional programing could stay the same, I had to reorganize how the data flows. Stores become separated contexts, and useState enter the game.

I intended to experiment a lot with RSC and server actions, but, I almost any time gave up using the "use-client" directive to be able to use freely all the UI mutation patterns I was used to. I really have to take the mental shift to de-correlate RSCs and CSCs.

I guess it's no big deal as this app is mostly a client side with heavy reactive UI.

Gameboard

I used a single rendered image for the countryside background, and set the vehicles individually into their own components.

The main game logic consist on generating on the fly vehicles components based on an interval increasing in speed. Each vehicles take some props that define its vehicle's version to pick as well as a lane to run on.

Vehicles animations are handled with Framer-Motion.

I handled the vehicles masking (when entering tunnels) using a single css image-mask.

For the rest, it's a matter of vehicles triggering their situation to a global game context.

This context is in charge of rendering the whole game status ('ready', 'gameover', 'in progress'...).

Next auth and Firebase

I decided to go with Next Auth and found pretty easy to set it, but I didn't make the Firestore adapter work properly (to get the user data part of the Next Auth context).

Instead, I juggled with both Next Auth and FireStore hooks to retrieve bound data given a user auth, when necessary, that is ugly and I'm well aware of it 🙁.

Github Copilot

I didn't regret to get the Copilot subscription, that helped me in many ways. Sometimes, it misled me, especially providing obsolete import paths (from the Nextjs page router).

Deployment

Not that much to say with Vercel that do an excellent job and eases the process, be it the subdomain binding, preview deployments, error logs...

Wrapping up

To conclude, and as always, working on this kind of side project has been very fun and enriching. Seeing the ideas come to life is very satisfying, while being able to deliver it within a limited time frame.

It also help to underline which part of the process have to be improved, because I consider my codebase as pretty messy at the time, and that gives me a roadmap on what would be interesting to dig in.

Demo

Here is the playable game of "Fin de chantier" (french version only). The contest run until next February 12th. I will then reopen the game without the contest part.

If interested, you can also play the still playable previous Svelte game called Blackout.

Note

This post is also part of my personal blog lansolo.dev where I share most of my experiments.

A Tinder-like card game with Framer-Motion

Stéphane CHANGARNIER — Tue, 26 Sep 2023 07:07:27 +0000

Stack used

Next.js + Typescript
Tailwind
Framer Motion

Side note

This post is not a tutorial on building this module from scratch, but a recap of the process and things I wanted to share. I invite you to take a look at the repo if you are interested on examining or pulling the whole code.

Context

In the same vein of my precedent small puzzle game, I adapted the concept of Tinder-like cards swipe using Framer-motion, a powerful React animation library that I still explore on a regular basis.

Initially, I designed an animated prototype and I decided to implement it, in order to customize it for client in the future.

Here are the live demo and the public repo.

Design

The initial concept was to propose a quick game testing someone knowledge on the carbon footprint.

The Tinder-like gesture turned out to be an interesting UI solution, as it brings an appealing, and entertaining UI.

After designing some key screens (Figma) and tested them through an animated After Effects prototype (After Effects), time has come to turn it into some functional code.

Framer-motion

This kind of interactity perfectly fits with what Framer-Motion is capable of. We are talking about gesture event listeners and animation controlled elements.

1. Gesture management with Drag

The first needed piece is the Drag gesture, that will be mapped from the swipe movement.

Framer-Motion has the Drag & Pan helpers.

It's a matter of turning moving elements into a "motion" element using:



<motion.div>

Then apply specific Framer-Motion attributes on them.

For the use-case of a swiping card, I used the following ones :

drag (set the element draggable)
dragSnapToOrigin (animate the element back to origin at release)
dragElastic (set increasing friction as the element walks away from its origin)
dragConstraints (maximum distance allowed from element's origin)
dragTransition (apply an organic easing when the elements move away or back at release)
onDrag (speak for itself)
onDragStart (speak for itself)
onDragEnd (speak for itself)

All of these events handlers greatly simplify the process to animate a card properly, so it behave with constraints and elastic transitions.

2. Value mapping with UseTransform

The second needed piece is the transform helper to map other elements animation as we swipe left or right (e.g: the bottom action buttons scale).

Framer-Motion has the useTransform hook.

This is the Framer-Motion helper to map any primary movements to control adjacent elements.

The useTransform expose an output value based on a Motion value.
This hook track any motion values derived from a primary element.

Usually, we extract this motion value as variable from an element styled property, and pass it to the useTransform hook to map the desired output.



const x = useMotionValue(0)
const inputX = [-150, 0, 150]
const outputY = [50, 0, 50]

let drivenX = useTransform(x, inputX, outputY)

// ...

return <motion.div style={{ x }}></motion.div>

In this case, x is the Framer-Motion shorthand property for transform: translateX() , and only works for element with motion tags.

3. Animation state tracking with useMotionValueEvent

Lastly, a very useful thing is to trigger some actions based on some animated values.

Framer-Motion has the useMotionValueEvent hook.

It acts like a useEffects, but is specifically designed to work with motion values.



const x = useMotionValue(0)

useMotionValueEvent(x, 'animationStart', () => {
  console.log('animation started on x')
})

In my case, I used it to lift some updated states to a parent component, because animated adjacent components (actions buttons and colored background) are one level up:



useMotionValueEvent(x, 'change', (latest) => {

  setCardDrivenProps((state) => ({

    ...state,

    buttonScaleBadAnswer: drivenActionLeftScale,

    buttonScaleGoodAnswer: drivenActionRightScale,

    mainBgColor: drivenBg,

  }))

})

Swipe logic

In my specific case, I wanted to have a more granular control over the swiped card, so I used an additional transparent overlay as draggable element to control the card itself.

That is pretty much it for the Framer-Motion hooks experimented.

The official doc does a pretty good job at explaining the api. For additional and more human resource, I strongly advise the Sam Selikoff channel, a true expert with a great pedagogy on the subject.

Image-mask

Another thing I struggled with was masking the card image with a custom shape, while leveraging the Next.js Image component.

I wanted to use an SVG mask but failed at a satisfaying result in term of concice syntax.

I ended up using a png image using the CSS mask-image property. It works BUT, we have to put in the webkit vendor prefix to make it work.



style={{

    maskImage: url('/images/gamecard-image-mask.png'),

    WebkitMaskImage: url(/images/gamecard-image-mask.png),

    maskSize: "contain",

    WebkitMaskSize: "contain",

    maskRepeat: "no-repeat",

    WebkitMaskRepeat: "no-repeat",

}}

Contexts and RSCs

Next.js has adopted the new React server component paradigm.

This module is mostly state driven animated, so pretty much all the components are client.

I could have put the text as server component with boundaries, but I didn't see the burden being worth, for this prototype.

The Root Layout is the only server component and pass some initial datas to some React contexts.

These contexts take care of the current game and user score.

I don't want to advertise, but I learned a lot from the free Jack Herrington course to refactor the way I wrote contexts and how to deal with this new paradigm, regarding management state.

Wrapping up

Framer-Motion is a huge and pretty complex library that I still explore and use on a regular basis.

There is still a pile of hooks I haven't play with yet.

Also don't hesitate to drop feebacks, as there is always a lot to learn from each others!

A drag and drop puzzle game with Framer-Motion

Stéphane CHANGARNIER — Tue, 04 Jan 2022 17:16:39 +0000

Stack used

Next.js + Typescript
Tailwind
Framer Motion

Context

I'm a big fan of the Framer-motion animation library since I started playing with it a couple of months ago.

It comes in handy when I have to deal with high effect interaction designs.

I decided to dig a little deep more by using it for a simple drag and drop puzzle in a side-project.

I stumbled upon this Dribble design from Dwi Ash, and decided to implement it.

Here is how it looks like:

Here are the live demo and the public repo.

Design

First, I chose a pixelated and personified version of an apple, as the main puzzle picture.

This choice was made as a visual representation of the company I'm working with called Pommeclic (appleclic in French).

It's more complex than the original dog design, and I had to subdivide it into smaller grid cells.

Then I had to break the character into multiple pieces and add a grid system and pieces IDs to translate the whole thing as React components.

I have done that using Figma.

Design implementation

I decided to go with full css implementation using a data objects to compute both empty slot zones and floating pieces around.

Data objects

Slots are rows of squared units, each containing utility classes that I defined using Tailwind and based on css variables.

Pieces are grouped squared units, using the same system of utility classes, this is mandatory to be able to render proper bevel effect with light and shadow bevels at the right place.

Then, render the markup is only a matter of looping over these datas into the JSX part.

The index page contains of course lot of additional logic that I can't explain in detail (to keep this article concise), but the whole architecture is based on this showcased CodeSandbox from Matt Perry.

This CodeSandbox is a simple demo of a Framer Motion shared layout used within a drag and drop feature between 2 zones.

My project is much more complex as I have to handle multiple start and end zones (pieces and slots).

Framer Motion drag

Framer Motion has a built-in drag and drop feature that can be easily implemented on any HTML tags (set as motion.div), using specific attributes and methods (drag, onDrag, onDragStart, onDragEnd, dragElastic, dragTransition..).

Framer Motion shared layout

I think Framer Motion shines when dealing with shared layouts. It means we can use two different components, but keep only one displayed and animate it smoothly between one and another.

This what is done between a dragged piece and a positioned piece : both are defined at their final positions in their own containers.

Other utilities

I used multiple third party packages that I found useful along the way:

div100vh: as it's a responsive and centered design, this help to deal with real viewport size on mobile
Lottie React Player: to implement Lottie Json animations (the firework at puzzle completion)
clsx: my go-to package to help dealing with complex conditional classes
usehooks-ts: A very convenient collection of utility hooks written in Typescript

Helper

Completing the puzzle display a reward message, and a reset button.

I added a helper on the top-left corner of the screen to trigger the completion, that is useful during the development phase.

Here is how the final stage looks like:

To go deeper..

I intend to dig more on this lib as I barely scratched the surface of what is achievable.

Beside the official doc, I found a lot of examples animations exposed in the Framer book that is focused toward Framer, the original prototyping tool Framer Motion is based on.

I personally didn't use Framer so far but maybe should I?

Don't hesitate to tell me if you identify code smells within the prototype, as I started using React since a bit less than a year and Typescript for a couple of months.

Vue.js + Vuex form binding circuit

Stéphane CHANGARNIER — Fri, 08 Jan 2021 06:48:20 +0000

Introduction

The state reactivity is one of the feature that make Vue.js really stands out, especially when using the v-model attribute within a form element. We can manage the local state (i.e inside a given component) very easily.

Things get a bit more complicated when someone needs to deal with Vuex store, and get the data centrally managed. We can send our data to Vuex via either actions or mutations, and can get them via mapped states or getters.

Problem

Vuex in its design, does not allow to change its state directly, this should be done via actions or mutations. When using v-model on a Vuex state, we break this Vuex law and therefore get an error.

To bypass this common problem, Vuex documentation provides a work around that make use of a modified computed property which contains getter and setter. Each form element has to be bound to this computed but I think this approach can become very verbose if our form contains a lot of fields.

My approach

After a lot of research, studying different proposed developer approaches, I’ve always used the same pattern since the beginning which I find the most robust and straightforward: bind the form components on a local deep copy of the Vuex state and keep updating this copy through a watcher.

Mindmap

As a picture is worth a thousands words, I made an illustrated mindmap of the full circuit to get things as clear as possible :

Note: I’m using the fetch hook as the entry point (I always work with Nuxt), but this can be replaced with the created/mounted hook.

By no mean I would pretend this is the best solution, but only one that suits me the best across all my projects so far. Let me know if you identify potential problems/optimizations with this one.