DEV Community: Claudio Bonfati

The Vaccination Game (Canvas API)

Claudio Bonfati — Tue, 22 Jun 2021 23:57:57 +0000

Last year I've worked on a project where I had to develop a small game alongside other components. But recently I've decided to isolate this game as a single stand-alone project since it was a good way to share a bit about canvas development and possibly introduce someone that Canvas API.

This article is intended to detail the development process of the game and some fundamentals of how to deal with Canvas API for similar projects.

First things first, you can take a look at the GitHub Project ⭐ or just play the game 🎮.

Before jumping into coding, we must have some things clear in mind, such as the concept of the game, the goal, how to win, and how to lose. If you have played it already, you've probably got it, but here is a quick overview:

The game consists of a population of 54 people separated in a grid system that keeps them apart from each other. As the game starts, 2 random people are infected by a disease. Infected people tend to infect the nearby population by randomly choosing what neighbors they will try to infect and at what speed the disease will reach them. By clicking at the healthy person we can vaccinate them, allowing them to become immune to the disease. The goal is to trap the disease right at the start, preventing it to spread further through the population and then vaccinate all remaining healthy people. I also added a timer of 30 seconds to make things a little bit more interesting.

Let's start by setting up our Canvas environment. For this project, I've chosed the framework NuxtJS to work with VueJS to handle all the interface interactions and also the engine responsible to create the triggers we will be needing later. After this quick introduction, let's start!

Global wrapper

The first thing - and the most obvious one - is to "create a NuxtJS project". I set it up with nothing different from a simple project, with an index page, global style, and a single component called "Game" to manage all functionalities and interactions.

But one thing is important to highlight here. The Game component will handle the interactions with VueJS, but all behaviors of the game will be set up directly with Canvas API and a javascript Class we will also be creating later. Remember these two terms, the difference between them will get clear as we talk more about canvas.

Markup structure

All HTML needed was created and styled at the Game component. But again, one thing is an important note here. Our game must have some "sections", which are the steps where the player will be. If we take a look that the player's journey, it starts at a welcome page, then the game starts and after the timer goes out (or the player vaccinate all the population), it has two possible endings, they will win, or lose. These steps are what we called "sections" here.

To manage these sections, I chosen the GreenSock javascript library to handle activating (showing) and deactivating (hiding) each section whenever we need it.

Things start to get interesting

Now that we have our environment properly set up, we can start talking about the game itself. In a simplistic overview, to work with Canvas we need two main things: a canvas HTML tag and a javascript function that will be pointed as our requestAnimationFrame() handler, that will create a 2D context allowing us to draw some shapes onto the canvas. And what does this requestAnimationFrame() function do exactly?!

"requestAnimationFrame() is the method from Web API that tells the browser that you wish to perform an animation and requests that the browser calls a specified function to update an animation [...]" _ by MDN Web Docs

Now a non-technical explanation:

"It calls a function over and over again for literally every single frame, and this function will draw an updated image onto the canvas with minor differences from the previous frame, simulating the idea of movement."

Now let's do this at our Game component. We create a canvas HTML tag and a VueJS method called animate(), and the first thing this method does is to "request-animation-frame" pointing itself as the argument so this function can be called for every frame.

This is the initial setup for all canvas development. From now on we can start looking at our project specifically, but all the concepts that will be detailed here can be applied to different scenarios.

Population grid

As you may have noticed, we will need to create a grid to display the population, with lines and columns. At this point, we need to start talking about the basics of what we can draw on a canvas.

The draw() function that we talked about earlier receive as the first argument a rendering context, this context is an object with properties and methods that you can use to render graphics inside the canvas element, such as Lines (that can be curved or straight) and Circles. For our game, these are the only two shapes we will be using - since the game is a bunch of lines and circles.

We already have the canvas width and the height values that we used to style it. But now, to create a grid system, we just need to use the power of math to get the starting-point and the ending-point for each line and column. These points are specified as coordinates related to the top side (X-axis) and left side (Y-axis) of the canvas, and that's the part where we start looking at the canvas as a Cartesian Coordinate System that will guide us throughout the next steps.

Create a person

This is one of the most interesting parts. As we already defined as the game scope, every person has a predefined (and identical) way to behave and interact with each other, but here is a reminder:

"[...] Infected people tend to infect the nearby population by randomly choosing what neighbors they will try to infect and at what speed the disease will reach them. [...]"

When we have a situation like this, the best decision to make is to deal with Classes - where a single structure can have multiple instances.

Now we can create a javascript class named "Person" in a separated javascript file that will be imported into the Game component. Initially, the class must have at least two things, a constructor(), and a draw() method. The constructor will receive the initial values for each variable the person will need, such as coordinates where it will be placed at the canvas, the current state ("healthy", "infected" or "vaccinated"), what neighbors it will spread the disease when and if infected, the spreading speed, and so on...

At this draw() method we must create the shapes that will form the face, and this "face" consists of three simple elements (the head, left eye, right eye, and mouth). And since we received the center coordinates for the person at the constructor(), we can again use the power of math to draw all three elements and place them related to this center point.

It's important to detail here that some aspects of the face will vary based on the person's state property, like the color that will be blue for healthy people, red for infected people, and yellow for the vaccinated ones.

For now, we must also have in mind that all the population will be instantiated from the Game component, once we have a basic structure for it to work. In fact, thats exactly the next step...

Populate grid with 54 people

Now that the Person class has a simple structure, we can instantiate the population at the Game component. This process will take a bit to finish since this is the moment we need to define no only the center coordinates for each person, but also randomly define the directions it's going to infect its neighbors and randomly define the spreading speed for each "disease arm".

For this logic to be simulated with javascript, we can use Math.random() method to create a random value from 0 to 1 and pass this value to the Person class.

There is also one thing that must be clear here. If you recall one detail of the game scope, each person will be able to infect their neighbors by trying to infect them once the disease has reached them. The mechanic behind it is simple: "if the disease arm reaches the neighbor, and it's not vaccinated yet, the neighbor will turn into an infected individual". To create this logic, two things will be needed: the first is that at the Person class we will create a function able to try to infect the current person, and the second thing is that for each person of the population we will need to store the instances of its surrounding neighbors so we can trigger this tryToInfect() method once the disease reaches them.

Disease spreading

Mathematics starts to have a bigger role here. If you ever thought that you would never use the Pythagorean Theorem in your life, I'll try to convince you otherwise. Looking to a single person, they can try to infect their neighbors in 8 different directions (top, top-right, right, bottom-right, bottom, bottom-left, left, top-left).

This article wont turn into an Algebra class, but if you think about it for long enough you will start to see some triangles being formed to define all the 8 arms of the disease related to the center of the face and two close neighbors. The principle that needs to be mentioned is that for each one of these arms we must have stored all the way-points between the center and neighbor's edge in an array so we can control the arm movement and its speed until it reaches the neighbor and try to infect them. And to accomplish that, there isn't much we can do besides applying some algebra formulas to get and store the values.

Deliver the vaccine to the population

Now it's time to create the interaction that will wait for the player to click/tap at some person, and the behavior to apply the vaccine that will be triggered with this interaction.

First I created a method at the Person class called applyVaccine(). The idea behind it is also simple: "if the person is not 'infected', change its state to 'vaccinated'".

After creating this method we can create the event listener to wait for the player's interaction to trigger the applyVaccine() method. The trigger can be built receiving the coordinates from the mouse position related to the canvas element, and these coordinates must be compared with the existing center point from every person instantiated. And if the difference between these two points is smaller than the radio of the head circle, the player clicked at a person.

Sound Effects and Scoreboard

We are getting to the end. Now we reached a point where the "soul of the game" is already created, the main interactions (witch are the functions we've defined at the Game component) and behaviors (which are the methods created at the Person class), we can focus some effort at the smaller things, such as the scoreboard, the timer, and sound effect management.

We stored all instances of the Person class, and with this list we can easily retrieve the current state of each one of them, calculate its percentage, and display it on the Scoreboard. It's always important to remember that for all functions that we want to run for each frame, it must be executed at the animate() method, and with the Scoreboard update, it's no different.

Sounds effects can be easily implemented using Howler.js, an awesome library able to manage mp3 files in a reliable way across all platforms. It works in a similar way as GreenSock, we instantiate the audios, and play/pause/restart them whenever it's needed.

Conclusions

Working with Canvas API usually requires more than we initially think, but between all the math, rules, and exceptions we create, the logic of the game can be found as a simple and straightforward storyline, just like it was described at the beginning of this post.

As it was mentioned before, I created this game in particular as a stand-alone project with the idea to introduce new developers to canvas development. Trying to accomplish that, the ⭐ GitHub Project ⭐ is full of comments for every function, method, code block, and property that needs guidance describing what it does. With these comments, the whole story I told here can also be found in javascript language right there.

When looking for the final project I wouldn't say it was easy to develop, there were a ton of problems along the way, crashes, conflicts, things that I initially had no idea how to fix, but as I said at an old article:

"Start from the basics, recognize how the next step looks like, and work on it. Problems are inevitable and that's what makes each project unique in some way, and winning these small battles is one of the things that motivate us to go to the next one." _ from What if LinkedIn was beautiful?

That's all, everyone. If you made this far, congratulations, and thank you for reading. And also, feel free to connect with me on LinkedIn.

What if LinkedIn was beautiful? - New UI

Claudio Bonfati — Fri, 19 Mar 2021 18:37:14 +0000

Hey everyone, three months ago I started a side-project with the goal to create a beautiful user interface for the web version of our beloved LinkedIn. The idea was to enhance some javascript skills by building a smoothly transitioned and friendly interface that I, personally, would like to use when browsing LinkedIn.

First things first, here is the LIVE project and also the GitHub project.

As the goal here wasn't to design an UI, but to develop it using React.js, searching around I found an amazing redesign concept by Gregoire Vella that was pretty close to what I had in mind. Inspired by his work I coded the interface proposed. Here is a quick video of the final result:

I'm writing this article to share a quick overview of the development process, walking through some challenging parts, explaining some decisions I made on the way, some of the troubles and the learnings during the whole process. I'm hoping this article can help someone in some way.

The API

Development

Before jumping into the interface, the first task in my To-Do list was to create an API able to serve the data in the structure that I would need them. I didn't need to create it from scratch using a real database since it wouldn't be necessary to insert/update or delete any data — I just needed an API returning all the data that I would use. To achieve that, I used the awesome package json-graphql-server which does an amazing job creating a GraphQL API with static data that can be stored in a simple JSON file on the server — I just realize that the package name does a pretty good job describing it.

Problems?

The only inconvenience I had with the API was that json-graphql-server, unfortunately, could not easily handle a scenario where a collection refers to multiple items from another collection. For instance, a "Recommendation" system, where users can write a recommendation to a friend and also receive a recommendation from someone else. In this case, we would have the author and the target fields, both referring to the "Users" collection. This issue could be solved with an intermediate collection acting in the middle. Initially, this collection wouldn't be necessary, but apart from that, everything went well.

So, static GraphQL API as a back-end, done! To the UI!

The Interface

Development

React.js plays the main role here, using Next.js for File-system Routing, as well as SSR, Images Optimisation and a lot other advantages the framework provides us.

I would say that about 50% of the total time spent on this project was coding just the interface, creating all the display components, styling them with CSS Modules — where SASS could be used — making sure the components would still work on mobile devices, and so on... In the second week, I had to refactor some of the components from Class-based to Function-based components. At a certain point, I realize that React Hooks could easily handle all scenarios that would be necessary and there wasn't actually any real advantage for them to be created as javascript Classes. And also, Function-based components require less code, which is a plus for everyone.

With the all components created and working property, it was about time to integrate the app with our static API. In order to do that, Apollo Client was imported into the project to manage all the GraphQL requests the app would run. With Apollo in place, the pages could be created individually, requesting the data from the API, passing them to the child components, and rendering them. Even though Function-based components were the choice I made for the display components, the pages were kept as Classes to handle some complex scenarios with the infinite scroll functionality and conditional data fetching. No problem so far, just a lot of work.

Animations and Interactions

Development

No need to say that GreenSock is one of the most complete animation javascript library we have available today. The framework was used as the main source of animations that come directly from user interactions, like tabs, popups, drop-downs, etc.

Besides the user interactions, we also need to have smooth navigation between pages, to create a friendly user experience, and that's where Framer Motion API takes place in our LinkedIn. It has the ability to intermediate between Next router system applying CSS animations while leaving/entering a page. The implementation was quite easy, without any trouble... Except for the fact that it had a serious issue after building the project and testing it live.

Problems?

The problem here was that Next was creating a conflict with Motion API for some components down in the component tree from React — when a page was changed, Next core unmounted only the CSS Modules from some components too fast, not giving Motion API enough time for the page to fade-out of the screen, so the CSS was lost before the elements leave the page — the problem only happens after the project is bundled into static files, strangely enough, this behavior doesn't happen on Next development mode.

In fact, this is still an open issue at Next (by the time this post was written). Currently, there are some workarounds available to solve the problem, but they have their downsides as well. Fortunately, the problem drew a lot of attention at GitHub community, and hopefully, it will soon be fixed.

Learnings?

Working with animations that takes a big space at the device screen can be tricky sometimes. Targeting the right elements and choosing the right CSS properties is an important task to get a great performance. At first, it may not look a big deal, but it made a huge difference in the performance tests I ran with some old mobile and desktop devices.

There is also a second topic here. I wouldn't say it was a "problem" but more like a point of attention with the Framer Motion API integration. As some of the routes are dynamic generated based on data from the server, it is important to handle them with React Memo, where it can prevent components from unnecessary multiple renders. Otherwise, as soon as the router change was triggered — but before the animation — the current page would be re-render, not giving enough time for it to fade-out of the screen (again). These re-renders have a serious impact on the app's final performance, not only affecting the client-side of the application but also increasing the requests to the server leading to possible overloading problems. I would say that the memoization system when used wisely is an awesome optimization technique with a huge performance impact and deserves special attention while developing an application.

Data Management

Development

Working with individuals stand-alone display components fit most cases, but there are some scenarios that it's not enough to achieve a goal. The Chat component — which is composed of a master component and three sub-components — is a perfect example of that. The challenge here is not only the interface by itself — with a decent mobile version — but also to make the sub-components communicate with each other in harmony. At first, I thought of using Redux.js for that, but even though it would fulfill the requirements and solve our problem, I've chosen to work with React Context API instead, that is meant to share data that can be considered “global” for a tree of React components, fitting perfectly to the Chat component case. This wasn't the only place where Context API was required, but as mentioned, this is a "quick overview", so we are going to stick only with the Chat component.

Learnings?

React first introduced Context API in version 16 with the goal to solve the issue of props drilling where you avoid passing props through many components in the component tree. Using Redux, on the other hand, requires not only adding more libraries to the application bundle but also requires following a set of configurations and their boilerplates for the library to be able to manage the application states. Which doesn't mean that Context API replaces Redux and its purpose — to be honest Redux is perfect for larger applications where there are high-frequency state updates — but the point here is to understand the problem and balance the best solution for each case where sharable states are necessary.

Conclusion

Well, usually the side-projects that I decide to build end up taking me more time than I expected at the beginning, but overall the final result, in this case, was actually better than I expected as well, so I guess it's forgivable.

The development process should not be a blurry thing, but you don't need to know every single thing you will do beforehand. I divided the development process into individual steps here, only to create a clear structure for the article. These steps are usually merged with each other while developing, and sometimes you'll need to go back a few days and work on something you thought was completely done.

Start from the basics, recognize how the next step looks like, and work on it. Problems are inevitable and that's what makes each project unique in some way, and winning these small battles is one of the things that motivate us to go to the next one.

That's all everyone, if you have come this far, thank you for reading. And also, feel free to connect with me on LinkedIn (this time it's the real one).

Netflix intro animation - Pure CSS

Claudio Bonfati — Sun, 29 Nov 2020 17:32:31 +0000

Hey everyone,

Recently I've cloned the Netflix's intro animation using only CSS and I got some great feedback about it, so I thought it would be great to share a bit about the development process of the animation step-by-step.

So here we go!

HTML Structure

First I mapped the letters in Netflix's logo, and separated they so I could use it as a base reference for positioning the HTML elements later.

In the HTML, I've created a container with 4 subdivs named helpers, each helper is designated to be a 'side' of the animated letter, for example, animating the N letter, 3 helpers are going to be used, because the N is divided in 3 individual parts, like this 👉 I\I

That being said, considering that in the container div we have an attribute named 'letter', I've used the image we export in the previous step, and it placed exactly where the helper divs should be for each value in the 'letter' attribute, wich supports all letters from the 'NETFLIX' name.

The Animation

Now it's time to focus on the animation part. The animation is composed by three main steps, the first one is when the letter is fading each one of its sides, until it came to the second part, that is mainly composed by lots of vertical 'lights' with different widths and colors that emerge from the last side of the letter while it's also fading away. The third part is the camera movement applied while the lights are going away - but that is the easiest part.

The first part (fading away)

The fading effect has a clear similarity to a paintbrush "unpainting" the letter. In order to clone this effect, we must acknowledge that a paintbrush doesn't have an uniform tip, some brush tips are made of nylon and polyester.
To do this, we have to build an 'irregular' gradient effect. Using photoshop I've made this brush effect:

Later I've created each little piece of the gradient into HTML helpers elements, this pieces was named as a 'fur', each one being a single 'span' tag. And, as it can be seen in the image, each fur has a different gradient effect, that was also replicated in the CSS file.

With this irregular gradient created, I made they move using simple CSS key-frame animation, each helper having its own delay setting to start one after another.

The second part (colorful lights)

The idea behind the lights is similar to the paintbrush. But, instead of each little piece being a fur with a gradiente background, each light has a random solid color as background and a box shadow for the illumination effect.

In order to make the lights "avoid the camera" while its getting closer, it was created a random movement with key-frame animation that make them move sideways, opening an empty gap in the middle of the lights.

The third part (camera movement)

The camera movement was replicated also using key-frame animation, but this time the css property manipulated was the scale of the main HTML container, so it looks like the camera is zooming in the letter while all the other animations are playing at the same time.

Conclusion

The hardest part was to conciliate all animations to be played at exactly the time they should be, so 'animation-delay' plays a big role in these scenarios. The approach I toke in the animations was to make sure that the animation could be played with a different background color and even with a different letter color, just changing the SASS variable and all the animation would still work as it should.
The code can still be optimised in many ways, so feel free to play with it if you like.

Thats all guys. I hope this post can help someone in some way. =)