Forem: Deon Rich

Complete Guide to Building Games in the Browser

Deon Rich — Thu, 09 Dec 2021 03:47:51 +0000

Back in the early days when I first started out in web development, I eventually stumbled across HTML Canvas, and I was immediately hooked. This discovery would prompt me to create many projects, from things like art programs to photo applications, and eventually even games.

Often I've been revisiting HTML Canvas, and combining it with some of my newer skills like Node.js. Using the two, I've been able to create full blown online games, and honestly have impressed myself with how much I've improved since I first came across the technology, becoming a kind of "canvas connoisseur" if I do say so myself! 😌

I thought it was about time I shared some of the knowledge I've gained over the years, and figured this was a good way to do it. So, today Im going to share with you my process and methods for creating games from scratch using HTML Canvas, showing you everything you need to know to get started building and designing your own!

Since this post will be a little lengthy, heres an overview of all of the topics I'll be covering:

What is HTML Canvas?
- Getting Started
- Drawing Graphics
Sizing the Game Area
- Applying a Static Fit
- Applying a Theator Fit
- Applying a Fullscreen Fit
Creating a Rendering Pipeline
Building Sprites
- Background Sprites
- Object Sprites
- Character Sprites
Movement and Controls
- Implementing Joysticks
- Joystick Movement
- Keyboard Controls
- Character Rotation
- Static vs Dynamic Movement
Collision Detection
- Squares and Rectangles
- Circles
Events
Putting it All Together

Just as a heads up, Im going to assume you have somewhat strong knowledge of Javascript and the DOM as I go through this guide, so I wont be explaining any syntax or basic concepts, only concepts related to HTML Canvas. Throughout this post I'll be explaining the key concepts used in my personal process, and then lastly in the final chapter I'll show a simple game I've created to showcase those concepts. But with that out of the way, lets get into it! 😎

What is HTML Canvas?

The HTML <canvas> element, or Canvas API as it's also called, is a special HTML Element used for creating graphics, similar to its counterpart SVG which is also used for creating graphics on the web. Unlike SVG however, HTML Canvas is built for speed and the rendering of graphics programmatically on the fly.

The API consists of the <canvas> element, which is used as a container for our graphics, and contains a whole plethora of properties and methods used for drawing things like shapes, images, text, 3d models and more onto it, as well as applying transformation on said elements.

Because its so simple, fast and versatile its applied in a wide range of web applications like games (2D and 3D), video chat, animations, art programs and everything in between. But before we start applying it for our game, let's get into how it works.

Getting Started

To get started with HTML Canvas, we'll need to first add it into our HTML. The <canvas> element has no children, but text can be added between its tags to serve as the text to be shown to a user in the case that their browser dosen't support Canvas.



<canvas>Sorry, your browser dosen't support HTML Canvas!</canvas>

By default, the dimensions of the <canvas> element are 300x150(px), but it can be resized in CSS. Note that this may alter the aspect ratio of the canvas's content, and it may be stretched as a result of resizing, but I'll get more into that later.

To breifly give you an introduction to the use of HTML Canvas (before we jump into the good stuff), I'll quickly go over each of the most important methods and properties you need to know to get started. Before we can render anything however, we first need to get a reference to the canvas's context using the canvasElement.getContext() method.



// get a reference to our canvas's context
const canvas = document.querySelector("canvas");
const ctx = canvas.getContext("2d");

The canvasElement.getContext() method takes 2 parameters. One is the context type, and another is the context attributes, however context attributes are irrelevant in our case, and can be ommited. The main two values for the context type are "2d" and "webgl".

Passing it a "2d" context specifies that we want a 2D rendering context, and canvasElement.getContext() will return a CanvasRenderingContext2D object, containing properties and methods for rendering 2D graphics onto our canvas. Passing "webgl", will return a WebGLRenderingContext object, which contains properties and methods for rendering 3D graphics.

WebGL as you may have heard of before, is a Javascript API for rendering 3D graphics, and is a very popular choice for creating 3D games on the web. The API however is very complex, which is why people usually opt to use libraries like Three.js to interact with it.

In this guide, we'll be using a 2D rendering context which is much simpler, but if you're interested in either Three.js or WebGL, you can check out some of the resources linked at the end of this article.

Anyway, let's take a look at some properties and rendering methods..👇

Drawing Graphics

Quickly, lets go over the main rendering methods and properties we'll be using to create our game. If any of these properties or methods dont seem clear, they'll become clearer as we apply them later in this article:

beginPath(): Starts a new "path", which means ties with previous renderings are cut. The path is all of the drawing commands that have been called up untill the current point. If you were to stroke a rectangle using rect() and stroke(), and then fill a rectangle using rect() and fill(), the stroked rectangle would get filled as well because both rectangles are part of the same path. Thus when fill() is called both rectangles are filled. This method prevents this from ocurring by starting a new path. Later you'll see this in action.
stroke(): Used to stroke (or line) the current path. Lines and shapes wont be stroked by default, so this should always be called explicitly.
fill(): Used to fill the current path. Lines and shapes wont be filled by default, so this should be always called explicitly.
moveTo(x,y): Moves the pen (the current coordinates from which to start drawing from) to x and y coordinates.
lineTo(x,y): Draws a line form the current pen coordinates to xand y coordinates. Line wont show unless stroke() is used after.
rect(x,y,width,height): Draws a rectangle whose top left corner is located at x and y, and whose dimensions are width and height. Wont show unless stroke() or fill() are explicitly called after.
strokeRect(x,y,width,height): Same as rect() but strokes (lines) the rectangle in the same function call (no need to call stroke() afterwards).
fillRect(x,y,width,height): Same as strokeRect(), but fills the rectangle in the same function call instead of stroking it.
clearRect(x,y,width,height): Same as fillRect(), but fill clear out (erase) the area of space specified. This is often used to clear the canvas for the next frame, as you'll see later.
drawImage(image,x,y,width,height): Renders a given image (image) onto the canvas located at x and y width the given width and height. Usually an HTMLImageElement created through the Image() constructor is used as the image value.
fillText(text,x,y): Creates text specified by text and x and y. Settings such as font and text alignment can be set using additional properties, which i wont go over here.
arc(x,y,radius,startAngle,endAngle,direction): Draws an arc centered at x and y coordinates, which has a radius of radius, starts at the angle startAngle and ends at the angle endAngle (both given in radians).To create a circle, set startAngle to 0 and endAngle to 2*Math.PI. direction specifies weather the arc is drawn counter clockwise, the default being clockwise.
strokeStyle: This property sets the color which will be used in strokes (lines). Can be any valid CSS color value. The new stroke color will be applied to everything drawn after its been set.
fillStyle: Sets the fill color. The new fill color will be applied to everything drawn after its been set.
globalAlpha: Sets the opacity. The new opacity will be applied to everything drawn after its been set.

These are the principle methods and properties that we'll be using to render our game onto the canvas, and draw each element from backgrounds, to characters and even on-screen controls for mobile users.

To keep this section as short as possible, i've only gone over the essencials. But, theres a ton of additional useful properties and methods you can use to acheive all kinds of stuff (some of which we will see later on). You can explore them here if you're interested.

Don't worry about it if it's hard to visualize any of these, as you'll see them in action further along. Any tips or other relevant information will be explained as this guide progresses. But now that we understand what we're using to create our game and a little about how to use it, let's look at the first step in implementing it.

Sizing the Game Area

The first step we need to take before drawing any game elements onto our canvas is to determine what kind of sizing we'll use, and how we want the game area to behave on different screen sizes. Before I show the methods I have for doing so, it's important we go over the width and height attributes of the canvas.

As before mentioned, the default dimensions of the canvas are 300x150, but this also serves as the default dimensions of the canvas's content. Using the width and height attributes we can change these inner content dimensions, and control how many units the canvas uses for rendering on it's x and y axis. Below is a further example and explination of how this works:

The canvas dimensions and it's content dimensions can also be set in one go, using it's width and height attributes in HTML:



<!-- canvas itself and its content is 300x250 -->
<canvas width="300" height="250">Sorry, your browser dosen't support HTML Canvas!</canvas>

What option you choose for sizing will determine how or weather or not you'll use these two attributes. But now that this concept is understood, let me show you what I think are the three best and most common methods for sizing your game.

Applying a Static Fit

A "Static Fit" (for the lack of a better term) is when you apply permanent default dimensions to your canvas, and then simply position it somewhere on your webpage. Generally, this is used for larger screens and desktops where you want other content to be visible without maximizing the game area, or you want to maintain the aspect ratio of the game area and dont care about maximizing it.

For some games, aspect ratio is important because if it's altered, the content of the game could squish or stretch. A good example of a static fit is the online game Tank Trouble (one i used to play quite a bit 😊). You can see they've simply positioned their game area onto the page, maintain it's aspect ratio, and keep it minimized as to keep the rest of the webpage content visible.

When applying this type of fit, you'll want to set the default content dimensions of the canvas once and never change them. They should have the same aspect ratio as the physical canvas dimensions in CSS, and whenever you want to scale the canvas, always keep it's aspect ratio and inner dimensions the same.

Applying a Theator Fit

The "theator fit" or "theator mode" method, is one of the most common ways used to maximize the size of content which must maintain its aspect ratio. This is when you stretch the height of the content to the full height of the device, and keep the width proporcionate, optionally filling in any gaps with black (or vice-versa, based on the client device dimenisons).

This method is usually applied when the game area has to maintain a certain aspect ratio and you want to maximize it as much as possible without cutting off any of the canvas. I could'nt find a good example in a game, but the Youtube video player serves as a good example. As seen when you try to fullscreen the video, black bars may cover the top or bottom of the video player in order to cover gaps not filled my the video itself.

Below, I show an example and full explination on how you can apply this:

Notice how the canvas adapts to the viewport changing, that way our game content wont end up stretching or being altered if a user resizes, and always provides the most optimum presentation possible. Similar to a static fit, you should set the content dimensions once and never change them, only changing the canvas's CSS dimensions to scale it, and maintain aspect ratio. It would also be smart to encourage your users to flip their device (if possible) to get as close to the aspect ratio of the game area as possible.

Applying a Fullscreen Fit

A fullscreen fit can be simple, or a tad more complicated. It's when you stretch the canvas dimension's (and it's content dimensions) to the exact dimensions of the user's device, as to leave no gaps. When using a fullscreen and theator fit, I would recommend fullscreening the canvas on touchscreen devices via the HTMLElement.requestFullscreen() method to lock it in place, because the browser may scroll and move as the player interacts with the screen to play the game.

A fullscreen fit should usually only be applied when the dimensions of your game area dont matter, and or the full game area within the canvas dosen't have to be visible. A good example of this is the online game Narwhale.io, where the character is centered and the map moves into view naturally.

A small pitfall if this is that the sizing of your game may vary slightly in terms of how much of the map certain clients will see. If your game is drawn on a phone with smaller dimensions than a tablet, the content is drawn using the same amount of units for each rendering (meaning a 2x2 square on the phone is also 2x2 on the tablet), except the tablet uses more units since the canvas's content dimensions will adapt to its larger screen size. This means that users on larger screens will end up seeing significantly more of the map than users with smaller screens.

Depending on your game, this may not matter to you, but if it's somthing you care about, I have a solution. I found to get around this was not to use pixels (the default units) as units when sizing renderings, but instead inventing my own "viewport unit" based on the dimensions of the device. Think of it as using "%" units instead of "px" units in CSS.

When applying this in an online game I had started a while back which used a fullscreen fit, it proved very effective at maintaining consistent proporcionality between devices. Below, you can see two screenshots I took, comparing the the size of the game area relative to the screen of my phone, and my tablet.

Phone game area (720x1520):

Tablet game area (1920x1200):

Notice how the elements of the game dont seem smaller on the tablet screen, and the distance between the benches from the edge of the screen is almost the same. Of course, some devices will inevadablely see slightly more or less of the map than others, because of slight differences in aspect ratio, but it's nothing to worry about.

In short, if you use pixel units (the default units) with a fullscreen fit you'll probably see large changes in the sizing of the map between devices (which isn't a problem, if you dont care), but if you use "viewport" units, the sizing of your game will stay consistent. Here I show an example and explination of how to apply these percentage units if you're interested.

On another note, if you're on a touch screen device and you're interested in checking out the unfinished multiplayer game where I took the screenshots from, you can check that out here. You can also dig through the code if you'd like to see how I apply some of the techniques I talk about here.

But with all that out of the way, lets finally start building our game, shall we? 👇

Creating a Rendering Pipeline

Before creating any characters, objects or backgrounds, we first need to define an order and structure through which each of these entities will be rendered and managed. Since we're building our game from scratch and HTML Canvas provides no kind of framework, we'll have to define ourselves a structure. I call this my rendering pipeline.

Generally it'll look like this:



// get canvas 2D context object
const canvas = document.querySelector("canvas");
const ctx = canvas.getContext("2d");

// object for storing globally accessable states
const GLOBALS = {}


// Array where all props will be stored
const PROPS = [];

// Array where all characters will be stored
const CHARS = [];

// function for applying any initial settings
function init() {

}

// function for rendering background elements
function renderBackground() {

}

// function for rendering prop objects in PROPS
function renderProps() {

}

// function for rendering character objects in CHARS
function renderCharacters() {

}

// function for rendering onscreen controls 
function renderControls() {

}

// main function to be run for rendering frames
function startFrames() {
// erase entire canvas
ctx.clearRect(0,0,canvas.width,canvas.height);

// render each type of entity in order, relative to layers
renderBackground();
renderProps();
renderCharacters();
renderControls();

// rerun function (call next frame)
window.requestAnimationFrame(startFrames);
}

init(); // initialize game settings
startFrames(); // start running frames

This provides us with an orderly process we can use to draw all of the elements of our game. The process goes as follows:

We create a container for any states that we want to be accessable globally. For example, if we wanted to create a "pet" that follows our character around, we could store the character's coordinates in our global container, for the pet object to access and use as a relative point to follow.
Two arrays are defined, one which will store all objects for props (objects that move or can be interacted with by the user), and another that will store all objects for characters (objects controlled by the user). Objects for props and characters will be created using classes, as we'll see later.
An initialization function is defined, which will set any initial states, like setting the canvas's dimensions, colors, fonts, etc. This is typically where you'd put the logic for your initial canvas sizing, like discussed in the previous section, or perhaps register an event listener for adjusting the game area on resize (depending on your prefered sizing method).
A function for rendering the backdrop is defined. Here we can either render an image, or separate background elements (more on that later).
We create a function which will render each prop in the PROPS array.
We create a function which will render each character in the CHARS array.
We create a function which will render onscreen controls (for mobile devices) line buttons and joysticks, as well as any other displays like showing the number of lives.
The main function is created. This function when called will begin running frames. It starts by erasing the canvas using clearRect(), then calls the render function for each type of entity. If somthing is drawn onto the canvas, and then we draw somthing directly ontop of it, the first rendering will be covered, meaning we'll have to think in layers. Thus, the render function for each type of entity is called in a logical order (background-> objects-> characters-> controls), with the background being on the bottom layer, and the onscreen controls being on the top. The last thing this function dose is run a special method requestAnimationFrame. This method takes in a function, which it will run as soon as the browser is ready to render new content, so we pass it startFrames. We call it in a loop, so that our frames run indefinitly (note that requestAnimationFrame isn't blocking, like if you were to run a for loop indefinitely, making the page unresponsive).
We call init and startFrames, to initialize our game, and begin running frames.

Of course, you can personalize this process however you please if you're actively following along, as this is just my personal process and none of this is set in stone (though I'd recommed still using requestAnimationFrame).

The purpose of this section was to explain that you should have some kind of structure for rendering your game, and managing states, animations and user interactions. This is the most important part, as it'll prevent our game from becoming a confusing, clunky mess in the long run.

Hopefully by now the fundamentals have more or less stuck, but now that the scafolding for our game is all set up, we can finally start filling our rendering pipeline with actual backgrounds, objects and characters (etc) to render!

Building Sprites

A "sprite" refers to any rendered object or character that can be moved around, interected with, or hold some type of state or animation. Some can be represented as objects, and others with functions, both of which should typically be stored in a separate file, to keep the file where your rendering pipeline lives clean. Usually I split these into three categories:

Background Sprites
Object Sprites
Character Sprites

As implied, they function as a tangible rendered elements of the game, each of which serves a different purpose. Below, I explain exactly the application of these, and how to create each of them.

Background Sprites

When creating a background for your game (as we'll dive deeper into later) there are generally two options. The background can be rendered as a single pre-created image, or, it can be rendered as a collection of "background sprites". This can be multiple renderings, or a collection of multiple images.

Because background elements cant be interected with and hold no state, usually these are created as functions which do nothing but render the sprite, rather than objects with render methods and properties as used in character and object sprites (more on that later). These functions will take in an x and y coordinate as parameters (optionally any other parameters regarding display as well), and will simply be called inside the renderBackground() function of our rendering pipeline.

Heres an example of a simple flower pot sprite ive created:

Here I draw each flower from scratch using rendering methods. If you do this its important that you draw each peice of the sprite relative to the x and y parameters that are passed into the function. I wouldn't recommend doing this however, as its tedious and using a prepared image generally will look alot better. I'm just using rendering methods to examplify their use.

Again, you can just as easily skip all of the building of the flower yourself, and simply use the drawImage(x,y) method to draw a pre-build image or PNG (one that hopefully looks better than my flowers) onto the canvas for a single background sprite, or even skip everything all together and render a single image for the entire background in the renderBackground() function.

Object Sprites

Object sprites are like background sprites, except they usually hold some kind of state (for user interactions), movement or have an animation, and may have access to certain global states in GLOBALS, like a ceiling fan, or a door that opens and closes when the user touches it. Usually these are made with classes and objects, which are stored in the PROPS array, which is later iterated through to render each object in it, inside the renderProps() function.

Classes for object sprites will always carry a render() method containing the commands to render the sprite, which will be accessed and called in renderProps. Of course you dont have to call it that, but you should have some kind of standard method for rendering each prop. Inside the render() method, state can be used to influence how the sprite is displayed. Similar to background sprites, these can also accept an x and y parameter, and any other additional parameters regarding interaction or display. Below I create animated spikes as an example of a simple object sprite:

The movement works because we're constantly changing the coordinates (our state) where the rendering is drawn, and because frames are running indefinitely, any changes we apply to the rendering will be immediately reflected since the sprite is being redrawn with new state repeatedly, which means it's up to us to control timing in animations. Again, my spikes are fairly ugly, and I'm just using render methods to demonstrate their use and prove the concept. You can make your sprites as pretty as you'd like.

This is a good example of the types of elements you should render as object sprites, such as obstacles or things a character can interact with or be affected by. As shown, typically you should make these as a class in which you'll specify its default functionality and give it a render method, then simply envoke it whenever you need to place a new object sprite of the same type, keeping our code nice and DRY.

Character Sprites

Character sprites function essencially the same as object sprites, accept they usually have state thats controlled by outside factors like keyboard controls or a joystick, and are rendered on a higher layer than objects. Character sprites are created as objects from a standard class which have state and a render method, and are added to the CHARS array which will be iterated through in renderCharacters() to call the render method of each existing character. This can include the player's character as well as other players, like in an online game.

Though they're similar, it's best to keep them separated, because usually you'll want your characters to be rendered on a higher layer than the objects and background.

In the next section I'll show how you can implement controls with a character sprite, and explain how to create different types of movements in your game like having the character look towards the mouse, making joysticks and using keyboard controls.

Movement and Controls

In this section I'll explain and demonstrate how to implement common controls and character movements that you'll typically apply in a 2D game, many of the methods I use to implement which can be used to create other types of controls and movements. Below I explain each one by one, and provide code and an example.

Implementing Joysticks

Joysticks are a common type of control used for mobile games and typically have two applications in regards to character actions: 1) Controlling a character's angle 2) Controlling a character's movement direction. Apart from display, a joystick's primary purpose is to keep track of each of these, so that we can apply them to whatever entity(s) it's controling. Typically it'll keep it's angle and x and y direction in GLOBALS so that they're accessible to every sprite that needs it.

These properties will allow us to specify certain directions in which sprites will travel on the game area, and the angle at which they're facing. Usually these are applied as character controls, and dual-joysticks are used, one for the character's angle and one for the character's direction.

Below I show an example and full explination on how to create a joystick. I've made this example so that you can interact using a mouse or a touchscreen device. Try not to resize to much, as it could break the example:

As you can see iv'e created a class for creating joysticks just like I would've made an object sprite, then instanciate and render it inside renderControls(). They technically aren't sprites however, because the joystick isn't an element of the game itself. I've rendered it simply as two circles, one serving as the thumbstick and one as the base (again, you can make these peices look however you want).

Within it's render method I added logic to draw the thumbstick towards the user's finger, while keeping it inside of the base (the distance() helper function, which measures the distance between two points, aids in this). Using one of the helper functions I've added to GLOBALS (angle()), the center coordinates of the base and the center coordinates of the thumbstick, Im also able to determine the angle between the two coordinates, and the x and y offset the thumbstick is from the base (the formula for which will be covered later), which is the information shown above the joystick. The formula used by angle() and distance() can be found commented in the above pen.

Note: The formula I've used to calculate the angle will output radians, because that's the unit used by the rotate() method of the canvas's context. This will be used later to rotate our character.

This information can be kept in GLOBALS to later be accessed by our main character sprite, to control it's movements. Another important note to mention is how im giving the joystick class access to the mouse actions through GLOBALS, and then implementing it's logic within it's own class instead of inside the event listeners for mouse/touch events. This keeps things much more orderly, rather than cramming the logic of each sprite who needs mouse events inside the same event listeners. This is why inside init() I've registered mouse/touch event listeners which when fired just add that information to GLOBALS to be globally accessible.

Joystick Movement

Below is an example of integrating a joystick with a character sprite to allow movement. Our character sprite is the red circle in the top left corner. Simply use the joystick to move it across the screen with your finger or mouse. Again, try not to resize the window:

Here our character sprite is accessing the charX and charY properties on GLOBALS, which are being continuously updated by and based on our joystick's state. Again, this is better than directly updating our character sprite's coordinates inside of the joystick's class, because if we we're to add more sprites for the joystick to control, we would have to cram a ton of code inside it. Instead, any sprite can simply access the information via GLOBALS and keep its implementation within it's own class.

The way this movement works is a bit different than implementing keyboard controls, because our character sprite is moving in very smooth angles rather than simply up or left. Here's how it works: First we declare charX and charY onto GLOBALS, which serve as the horizontal and vertical amount of units a character will move over time.

Note: The way the joystick determines both of these values is by mesuring the x and y offset of the thumbstick of the joystick from the center of it's base. These are determined by subtracting the base's x coordinate from the thumbstick's x coordinate to get charX, and then subtracting the base's y coordinate from the thumbstick's y coordinate to get charY. You might want to only use a fraction of the result of both of these calculations, like a 10%, because if the result of calculating charX for exmaple is -56.09, your character will be moving alot of units to the left very quickly. You can fraction each of these however (as long as you fraction both the same). It's all about the ratio between the amount of units our character sprite is moving in one direction vs the other overtime, to apply movement at dynamic angles.

If a user had the joystick positioned at the bottom right (as far as it could go in each direction), this would mean our character would move diagonally downwards to the right. Why? Because since charX and charY are the same value (because the width and height of the joystick are equal and thus if the thumbstick is at the bottom right it has equal x and y offset) charX and charY would be set the same, and the character would move down and right at the same rate, causing our character to move diagonally downwards towards the right. Hopefully that made sense, but lucky for you implementing keyboard controls is 10x simpler.

Keyboard Controls

Unlike joystick controls keyboard movements are much simpler to implement. It's as simple as registering a keydown and keyup event inside init(), and then keeping track of weather or not the keycodes you're listening for are pressed down or released. That information is kept inside GLOBALS, where our character sprite has easy access, and depending on weather a key is currently being pressed, the x and y coordinates of the character sprite will be incremented or decremented by a certain amount (the character sprite's speed property).

Below is an example of a character sprite (the red circle) which you can control using the arrow keys:

Simple right? As it's name implies, the speed property of the character sprite controls how many units our character will move when it dose, allowing us to control how much ground it covers in each movement. The same can be done with joystick controls by either multiplying charX and charY to go faster, or dividing them to go slower (as long as they're multiplied or divided by the same factor).

Character Rotation

In the below example I've made a small rocketship character sprite using the drawImage() method. Not only dose it move in the direction of the joystick, but also mimics the angle of the joystick. The joystick's angle is kept in GLOBALS.roation, which our character sprite has easy access to for it to rotate that amount.

Below is an example and explination of how to apply rotation to a character sprite:

The key part here is the angle() method on GLOBALS, which takes in two sets of coordinates and returns the angle between them (in radians). The formula for which is atan2(y2 - y1, x2 - x1). We use angle() to measure the angle between the center of the joystick's thumbstick, and the center of the joystick's base, and then put the result into GLOBALS.rotation. This formula (and every other I cover in this post) has a ton of applications when building a game, and you can use it to control rotation with the mouse as well, by mesuring the angle between the mouse coordinates and the center of the screen.

The second primary part which allows this to work is the rotate() method of the canvas's context, which is what's used to apply the rotation to the character sprite. The way this method works is by rotating the canvas from its top left corner by the specified amount of radians. The rotation only applies to everything drawn after the method is called. Of course this works alot differently than you would expect, but we can normalize it by doing the following:

We want to rotate the canvas by the center of the thing we want to rotate (our character sprite) rather then the top left corner. The way to do this is by using the translate(x,y) method to move the canvas's top left corner to the center coordinates of the thing we want to rotate, rotate our desired amount using rotate(radians), undo the translation (translate(-x,-y)), redraw our sprite with the applied canvas rotation, and then call the resetTransform() method to reset the canvas transformations we just did, so that everything drawn after the thing we wanted to rotate dosen't become part of the rotation or translation. This process can be seen in the render method of our character sprite.

You can read more on the rotate() and translate() methods here.

Static vs Dynamic Movement

In 2D games typically there exists two major types of character movement:

Static Movement: This is when the map is fixed on the game area, and the character moves relative to the map. Like in Tank Trouble.
Dynamic Movement: This is when the character is fixed to the center of the screen, and the map moves relative to the character. Like in Narwhale.io.

So far the type of movement I've examplified has all been static movement, but in this section I'll give an example and explination on how to apply dynamic movement:

See how the "camera" follows our character as the map moves relative to it. The way we do this is by applying the joystick's x and y offset to coordinates which will serve as a map anchor, which our background sprites will be drawn relative to (and of course remove the charX and charY implementation from our main character sprite).

First what I do is store the joystick's x and y offset in GLOBALS.anchorXand GLOBALS.anchorY, and then declare GLOBALS.mapAnchor to store the "map anchor" coordinates. Inside renderBackground() before rendering each sprite, I update GLOBALS.mapAnchor.x and GLOBALS.mapAnchor.y by subtracting GLOBALS.anchorX from GLOBALS.mapAnchor.x, and subtracting GLOBALS.anchorY from GLOBALS.mapAnchor.y.

Here we subtract instead of add like we did in static movement, because the map has to flow the opposite direction from where the character is moving towards. Then finally, inside our Pot() sprite, I add GLOBALS.mapAnchor.x and GLOBALS.mapAnchor.y to it's x and y coordinate, to draw the sprite relative to the current map anchor coordinates.

Collision Detection

Collision detection is typically an essencial when it comes to games, weather it's stopping a character from walking through a wall, or killing a character when a bullet hits them.

In this section I'll touch base on basic collision detection, and explain how to detect collision between squares, circles and rectangles as well as give examples.

Squares and Rectangles

Collision detection is all about using the dimensions and coordinates of two shapes, to mathematically determine weather or not both are in contact. Depending on the shapes themselves (square, circle, etc.), the way you'll determine this will vary.

Below I give an example and explination on how to apply collision detection with squares (same exact method can be used with rectangles of any size). Simply drag the pink square into the blue square, and the blue square will turn red when the pink square comes into contact in the following example:

The first thing I did was implement some logic for dragging the pink square. That isn't as relevant but if your interested in how I implemented it just take a look at the code. Next, onto the base class for our squares (which is the one the blue square instanciates) I attach an object inside the constructor called collisions. On this object, we'll keep a sub object for every sprite we want to detect collision for, thus, I add pinkSquare.

On pinksquare (and every other collision object in collisions) there exists a conditions property which holds the boolean for mathematically determining contact with the pink square (which we're about to dig into), and then an inContact property which specifies weather not the sprite is in contact, though here we aren't using this property. This is a good standard to use when implementing collision detection, since its simple and keeps things orderly.

Note: collisions.pinkSquare.conditions is a string rather than a boolean, so that we can revaluate it constantly with eval(), and we dont have to hard code it into if statements.

Here is the pseudo-code for determining collision between two rectangles/squares, exactly the same structures as the boolean in collisions.pinkSquare.conditions:



A = {x: ... y: ..., width: ..., height: ...}
B = {x: ..., y: ..., width: ..., height: ...}

if (A.x + A.width) > B.x 
 and A.x < (B.x + B.width)
 and (A.y + A.height) > B.y
 and A.y < (B.y + B.height) 
...

Try visualizing this boolean in action as you read through it, and eventually you'll get the gist.

Circles

Determining contact between two circles (not ovals, we'll get to that) is very straight forward and simple to understand. Because Im lazy, just imagine the shapes in the above example I showed are now two circles. The pseudo code for collisions.pinkCircle.conditions would be the following, to determine weather the two circles are in contact:



A = {x: ..., y: ..., radius: ...}
B = {x: ..., y: ..., radius: ...}

if
 distance between A and B < (A.radius + B.radius) 

...

Here, "distance between A and B" refers to the distance between the two points where each circle is centered. If you remember, you determine this with the handy-dandy formula: √(x2 − x1)^2 + (y2 − y1)^2. Simple right?

These two examples are pretty simple, but collision detection with more complex and irregular shapes can require much more advanced methods of determining collisions. Of course here I've only gone over the basics, but if you do plan on implementing collision detection for complex shapes, I highly recommend you check out these resources:

Events

Keeping track of certain events, such as when a door is opened or when the character is hit in a game is important. This allows us to globally listen for (and trigger) when certain things happen our game no matter what sprite we're in.

Below I've edited the previous example to use events to run two alert()s every time the squares are in contact:

Basically the way I've implemented events is exactly how DOM events are implemented, by adding an addEventListener() and dispatchEvent() method to GLOBALS. That way both methods are globally accessible.

GLOBALS also includes an events property, and each of its sub properties are the name of an existing event which points to an array where callbacks for that event will be stored. I simply call GLOBALS.addEventListener(name,callback) to add a callback to the array for the specified event, and then call dispatchEvent(name) to call each callback inside the array of the specified event name. And of course we can all new events by adding a new property to GLOBALS.events. Easy-peasy! 🍋

Despite how simple it is, I just wanted to clarify that its important that you implement some kind of event system within your game, otherwise you'll be hardcoding alot of stuff, which isn't good practice.

Putting it All Together

Finally let me go down the list of each integral concept that makes this process possible. If any of what I explained previously seemed unclear, I recommend you try to examine where and how each concept is implemented within the code to gain a better understanding of how this all functions. Let us first again go down the list of each of the steps of the process:

Choose a sizing for the game area (apply it in init())
Create your rendering pipeline
Fill your rendering pipeline with sprites (in their respective locations depending on the sprite)
Apply movement and controls
Apply collision detection
Integrate events

Each of these concepts can be seen applied in this simple game I've created, named "Drift". The objective is to last as long as possible without being hit by a barrier or leaving the map, steering a car by tapping the left or right half of the game area or using arrow keys. I found it about as frustrating as playing Flappy Bird, my highest score being 33.

This game greatly examlifies the process and methods I've explained throughout, and hopefully with this guide and example to throw it all together, you'll be equiped with the knowledge to build your own games using HTML Canvas, and the techniques I've gone over in this post.

I hope you've managed to gain somthing from this article, and if you're still thirsty for more related to game development, definitely checkout the resources below.

Thanks for reading, and happy coding! 👍

HTML Canvas API - https://developer.mozilla.org/en-US/docs/Web/API/Canvas_API
Advanced Collision Detection - https://www.gamedeveloper.com/programming/advanced-collision-detection-techniques
https://docs.microsoft.com/en-us/archive/msdn-magazine/2015/march/game-development-a-web-game-in-an-hour

Understanding Speech Recognition and Building a Voice Controlled To-Do List

Deon Rich — Wed, 03 Nov 2021 02:37:53 +0000

One of the biggest and most important building blocks of modern technology, hands-down, is AI. Machine learning is a completly different animal when it comes to how machines process information. I consider it to be one of the key stepping stones for bridging the gap between the way machines process and understand data, and the way we humans think and take in information.

It can seem rather impossible for a machine to emulate the capabilities that our human minds do, with the unique way we have of learning, understanding, mapping information and extracting context from data. This especially applies when talking about human language and speech. But as always, technology has found a way!

In this post, I thought it would be interesting for us to take a look at how modern speech recognition technology works, as examplified by technologies such as Google Assistant, Amazon's Alexa and Apple's Siri. Then lastly, we'll look at an example of how we can utilize this tech in our projects by building a voice controlled to-do list using the Web Speech API! 😉

The Building Blocks of Speech Recognition

When it comes to how machines understand and process language, more specifically in the form of audio, there exsists two fundamental concepts that must be implemented for speech recognition to be possible:

Automatic Speech Recognition (ASR): Though ASR is usually used as an umbrella term for the concepts behind speech recognition, it primarily refers to the process of breaking down speech in the form of audio, and applying algorithms to transcribe the peices of audio. This is the main concept behind Speech-To-Text programs, and allows a machine to know what you're saying, but not the meaning behind it.
Natural Language Processing (NLP): Refers to the process of understanding or emulating language. The act of constructing and or deconstructing key points in natural speech. This is the main player behind programs like Alexa, which are able to not only know what you're saying, but understand it based on the summary it formulates from your speech (NLU), or even respond back (NLG). The concepts used in NLP are applyed in both NLG (Natural Language Generation) and NLU (Natural Language Understanding), as its used as an umbrella term for both.

Both NLP and ASR are implemented using algorithms based on machine learning, neural networks and deep learning, and are heavily based on linguistics, semantics and statistics. And considering how complex human language is, this is the right approach.

These technologies aren't perfect, however. Human language cannot be simply analized like any other set of data. There exists anthimeria, sarcasm, slang, implication, words with double meaning, figures of speech and a whole lot of other quirks that a machine is going to have to learn to identify over time. Not to mention, this all varies from language to language.

So how do ASR and NLP acomplish what they do? Lets take a bit of a closer look..👇

The Process of ASR

The main steps behind ASR that a program will take go as follows. Note that the process may vary depending on a specific programs end goal:

The program receives an audio input.
This audio is refined, as the program attempts to isolate the speech from background noise.
The resulting speech is split into phonemes. Phonemes are small units of sounds unique to a language that are commonly used to construct words, and can be used to differentiate one word from another, or where one word may start or where another may end.
The phonemes are then analysed, and the AI uses its aquired knowledge of that language to determine the most likely word that would follow based on the sequence of sounds. Once it forms words, the same probability analysis is applied to determine what a sentence might be.

The Process of NLP

The main steps behind NLP (or more specifically NLU) that a program will take go as follows. Note that the process may vary depending on a specific programs end goal:

The input speech is separated into sentences. The resulting sentences are then split into separate words, this is called tokenization.
The tokenized words are then analysed and given roles (nouns, verbs or adjectives) based on the surrounding sentence.
Non lemmas are then lemmatized, meaning they're mapped to their basic form, to signal that they pose the same meaning (broken -> break).
Common words such as "and","or" and "a" are removed, as to isolate the words which hold the primary meaning.
Dependency Parsing is then preformed, and a tree is created, associating words which depend on each other together (chocolate -> best -> icecream -> flavor).
Named Entity Recognition (NER) is preformed, labeling each noun based on the real world thing they're meant to represent (Peter Parker -> fictional character).
Lastly, Coreference Resolution is done on pronouns such as "it", "she", "he" and "they", in order to link them to the noun that they're refering to. Once this is done, the program can properly deduce the meaning behind the speech sample (she -> Lisa Ross).

Of course its important to remember that there is much more that goes into these proceses within a real implementation of NLP and ASR. In order to actually execute each of these steps advanced algorithms and methods are utilized, such as Hidden Markov Models, Dynamic Time Warping, and Neural Networks to list a few.

Anyway, now that we've got a good idea of how ASR functions, lets get our hands dirty at look at how we can use it in our code by utilizing the Web Speech API, and building a Voice Controlled To-Do List! 😁

Note: The Web Speech API is still in an experimental phase. It may not support a given browser and its implementation is still incomplete. That being said it should be used in personal projects only. There already exists stable STT APIs out there such as those listed here, but im going with the Web Speech API as its extreamly simple, easily accessable and suffices our needs.

Building a Voice Controlled To-Do List

Before I walk you through our example, let me first show you the finished product. Here however, the embed isn't allowed media access, which breaks its functionality. If you want to see how it functions you can view it here. Anyway, heres what it will look like:

The functionality is pretty simple. Once the switch is flipped, the speech recognition service will start listening for speech. Our program will first expect the user to give a title, and once thats given it will then expect a description. After the description is spoken, a new task will be added to the UI, containing the title and description the user entered. The state of the program (weather its active, or what peice of information its expecting next) will be expressed in the message above the switch.

Simple, right? Lets go over the code..

Using the Speech Recognition Service

First, lets cover the most important step, which is starting the speech recognition service through the Web Speech API. When I say "speech recognition service", im refering to the default speech recognition service build into Chrome. Our audio will be captured and sent to a server (the speech recognition service) where it will be processed, and then sent back.

First, we need to establish a connection with it:

  // Setup recognition service
if (webkitSpeechRecognition || SpeechRecognition) {
  const recog = new (webkitSpeechRecognition || SpeechRecognition)();
  const grammarList = new (webkitSpeechGrammarList || SpeechGrammarList)();
  recog.grammars = grammarList;
  recog.lang = "en-US";
} else {
  // Alert user if API isnt supported
  alert("Sorry, your browser dosen't support the WebSpeech API!");
}

Here all we do is first ensure that the API exists within the window object. Once thats done we instantiate a new SpeechRecognition object, which is the interface for interacting with the speech recognition service.

Its primary events and methods are as follows:

start(): Begin listening for speech.
stop(): Stop listening for speech.
abort(): Stop listing for speech without returning result.
result: Fires when a result is returned from the recognition service. The result is passed to the callback.
end: Fires when the speech recognition service is stopped.
start: Fires when the speech recognition service is started.
speechstart: Fires when speech is detected.
speechend: Fires when speech is no longer detected.

Then I attach a SpeechGrammarList to it via SpeechRecognition.grammars. SpeechGrammarList is an object which is meant to hold a list of grammars. A grammar (though through this API is given as a string) is a special file that is sent to the speech recognition service, which gives it the grammar or key words or phrases that it should be listening for. Through grammars you're also able to tell it which phrases it should listen for more than others, by specifying their "weight".

Grammars are typically specified using the SRGS(Speech Recognition Grammar Specification) format, or the JSGF(Java Speech Grammar Format). However, at the moment this API dosen't support grammars very well, as they have little effect on the results of the speech recognizer. Thus, I give it an empty SpeechGrammarList.

After that, we set the language the recognizer should listen for via the SpeechRecognizer.lang property, which in this case is english.

And thats really all there is to it to get up and running. Now we just need to fill in the gaps we need to integrate it into our to-do list!

Putting it All Together

Because the UI isn't as important i'll only be going over the javascript, but you can give it a closer look here or in the embed I showed earlier. You can of course make the UI look however you want if you intend on following along.

The main idea is that we simply have a main button to toggle the speech recognition service, a message to indicate the state of the program (active, listening, or what info its expecting), and an area where the resulting tasks will appear.

To wrap up, i'll breifly go over each segment of functionality.

// Only proceed if API is Supported...

if (webkitSpeechRecognition || SpeechRecognition) {

/*
"active" will be used to keep track of weather 
or not the service is active.

"phase" will be used to keep track of what 
information is currently being 
expected (either the title or description).

"task" is simply a container for our information 
when results are received.
*/

  let active = false,
    phase = undefined,
    task = {};

//________________________________________

/*
Listen for when the switch is toggled. 
If the service is inactive, start the service 
and set the phase to "title" since 
this is the first peice of info once 
the service is listening. 
If the service is active, do the opposite.
*/

// select message element above switch
  const message = document.querySelector(".container__message");

// select toggle switch
  const button = document.querySelector(".container__button");

  button.addEventListener("click", () => {
    if (!active) {
      recog.start();
      active = true;
      phase = "title";
      message.innerText = "waiting for title...";
    } else {
      recog.abort();
      active = false;
      phase = undefined;
      message.innerText = "Flip switch to toggle speech recognition";
    }
  });
// ________________________________________

/*
"addTask()" will be after both the title and description are 
spoken. This will hide the placeholder 
and fill a copy of the tasks template with the 
respective information. It'll then be 
appended to the tasks container
*/

// Select container where tasks will appear, its placeholder and the template for the tasks.
  const tasks = document.querySelector(".container__tasks"),
    placeholder = document.querySelector(".container__tasks__placeholder"),
    template = document.querySelector("#task-template");

  // Function for appending tasks
  function addTask() {
    placeholder.style.display = "none";
    let content = template.content.cloneNode(true);
    content.querySelector("p").innerText = task.desc;
    let n = content.querySelector("div");
    content.querySelector("summary").innerText = task.title;
    content.querySelector(".x").addEventListener("click", () => {
      tasks.removeChild(n);
      if (tasks.children.length === 2) {
        placeholder.style.display = "block";
      }
    });
    tasks.appendChild(content);
  }

//________________________________________

/* Setting up the recognition service, 
as already explained previously */

 // Setup recognition service
  const recog = new (webkitSpeechRecognition || SpeechRecognition)();
  const grammarList = new (webkitSpeechGrammarList || SpeechGrammarList)();
  recog.grammars = grammarList;
  recog.lang = "en-US";

//________________________________________

/* Inform user that service is listening when speech s detected */

  // Let user know recognition service is listening
  recog.addEventListener("speechstart", () => {
    message.innerText = "listening...";
  });

//________________________________________

/*  
Register an event listener for when the result comes in, 
which will be each time the user stops 
speaking and speech was recognized. 

In the callback, if the phase is currently 
"title" (the program is waiting for the title) 
add the title to the "task" object and 
switch phase to "desc".

If the the phase is currently "desc" 
(we already have the title, and are waiting for the description) 
add the description to the "task" object, call "addTask()" 
and inform the user that the task was successfully added.
*/

  // Determine what to do with result once it comes in
  recog.addEventListener("result", (res) => {
    let result = res.results[res.results.length - 1][0].transcript;
    switch (phase) {
      case "title":
        task.title = result;
        message.innerText = "waiting for description...";
        phase = "desc";
        break;
      case "desc":
        task.desc = result;
        message.innerText = "task added!";
        phase = "title";
        window.setTimeout(() => {
          message.innerText = "waiting for title...";
        }, 2000);
        addTask();
        break;
    }
  });

//________________________________________

  // Keep service open by restarting it, since it ends after each speech segment it receives.
  recog.addEventListener("end", () => {
    if (active) recog.start();
  });

  // Cancel service if error occurs
  recog.addEventListener("error", () => {
    recog.abort();
  });
} else {
  // Alert user if API isnt supported
  alert("Sorry, your browser dosen't support the WebSpeech API!");
}

Conclusion

And there you have it folks! An introduction to how ASR works, and a small example of how you can implement it into your projects. If you want to dive deeper into ASR, NLP or the Web Speech API, you should check out these resources below..👇

ASR: https://verbit.ai/asr-and-the-next-generation-of-transcription/
NLP: https://medium.com/@ritidass29/the-essential-guide-to-how-nlp-works-4d3bb23faf76
Web Speech API: https://developer.mozilla.org/en-US/docs/Web/API/Web_Speech_API;

Thanks for reading..😊!

A Quick Guide to Custom HTML Elements

Deon Rich — Sun, 24 Oct 2021 05:08:09 +0000

After getting to know the component based system of modern frameworks such as React and Angular, i was immediately interested when i came across the term "Web Components". After taking a deep dive into the subject, i thought it would be worth sharing. So, today im going to provide a quick guide to Web Components, how they operate, and how we can create our own custom HTML elements by applying this concept!

What are Web Components?

A Web Component serves as a label for any HTML Element that possesses its own underlying DOM tree, CSS styles, and even scripts, that are separate from the reset of the DOM and encapsulated completely by that element. This underlying DOM tree is refered to as the Shadow DOM.

The Shadow DOM

To further understand the Shadow DOM, take the contents of the following HTML <input> as an example:

Inside of the input the first thing we see is #shadow-root. This simply represents the root of the <input> element's shadow DOM, much like how <html> is the root element of the document. The element containing the #shadow-root itself is refered to as the "shadow host", which in this example is the <input>. Everything that comes after #shadow-root is the contents of the element's shadow DOM. Simple, right? :)

Not all, but many elements are capable of having a Shadow DOM attached to them, which can serve useful if you require a quick way to provide encapsulation and abstraction in your code.

In this particular case, the Shadow DOM of the input element contains only two <div> elements. As you may have been able to tell by the ids of each element, these are used to create the track, and thumb peices of the range slider.

This is a perfect example of the Shadow DOM in action. It allows things like <video> and <audio> elements to hide their moving parts and functionality away from the rest of the document, simplifying and keeping the program organized.

We can take this a step further, by implementing the Shadow DOM API to create our own custom HTML components..😁

Creating our first Custom HTML Element

Before starting to build our custom element, we first need to understand some criteria it has to meet to be considered one:

It has to have a constructor (usually via a class)
It needs to posses a Shadow DOM
It must be registered within the CustomElementRegistry
It can optionally use a <template>

If any of these steps dont immediately make sence, dont sweat it, everything will become clear as i walk you through it.

For demonstration in this short tutorial ill be making a custom HTML element named <type-writer>. The final product will look like this:

I decided to make a simple custom element which consists of a <textarea>, and a some <button> elements to serve as keys to show text onto the screen.

An easy example that should clearly demonstrate how we can create somewhat complex custom elements using this API.

Without further ado, lets start with the first step..👇

Creating a Web Component Constructor

Before we do anything else, its mandatory that we create a constructor function for our custom element. Its purpose is to initiate our component and attach any functionality it might have to it, and will be called each time a new instance of our web component is created.

Below i create the constructor for our <typewriter> element using a class:



// Extend generic HTMLElement interface
class Typewriter extends HTMLElement {
 constructor() {
  super();
  // implement functionality...
 }
}

I've named the class Typewriter, though this dosent serve as the name we'll use to write it into our HTML (<type-writer>), so you can call it whatever you want. Ill show how you can define a tagname for it in a later section.

When creating your constructor, its required that you extend the functionality of an existing built-in HTML element, or the generic HTMLElement interface. This is so that your custom element inherits all of the same required properties that all built-in elements do. Otherwise your custom element wouldn't be compatible with the DOM.

There are two types of web components that can be created, based on the interface that you're extending:

Customizable components: Custom elements where the constructor of which, extends upon the functionality and properties of an already existing built in element.

Its constructor would be similar to -



// Extend functionality of a <div> element
class Superdiv extends HTMLDivElement {
constructor() {
 super();
}
}

And would be shown in HTML as -



<div is="super-div"></div>

Autonomous components: Custom elements where the constructor of which, extends the functionality of the generic HTMLElement interface. These elements apply their own functionality, and share no properties in common with other built-in HTML elements other than those defined in the HTMLElement interface (which serves as the bare-bones, or, minimum required properties for every HTML element).

Its constructor would be similar to -



// Extend the generic HTMLElement interface
class MyElement extends HTMLElement {
 constructor() {
  super();
 }
}

And would be shown in HTML as -



<my-element></my-element>

In this case, our <type-writer> element is an autonomous component, because it extends the HTMLElement interface. I decided on an autonomous component because i didn't find it nesessary to extend another elements functionality, but mainly because i find writing <type-writer> into HTML rather than somthing like <div is="type-writer"></div> much more attractive..👌😎

Attaching a Shadow DOM

Now that we've got a container for our elements functionality, we need to attach a Shadow DOM onto our element upon its initiation.



// Extend generic HTMLElement interface
class Typewriter extends HTMLElement {
 constructor() {
  super();
  // attach shadow DOM to element
   let shadow = this.attachShadow({mode: "closed"});
  // implement functionality...
 }
}

After calling super, i call the attachShadow method of our new element (which was inherited from HTMLElement) which returns the newly created #shadow-root, which i store in the variable shadow.

The one parameter it takes in is an object which contains a couple of configuration options. The mode property indicates weather or not the elements within the #shadow-root of our element are accessable outside of the shadow host. Ive set it to "closed" so that they aren't accessable, but you can use "open" as well depending on your programs reqirements.

We now have a reference to our shadow root, so we can go ahead and start appending content to it to construct our element!

Filling Our Shadow DOM

I would say theres two good ways to go about adding content to the Shadow DOM once its attached; you can create elements and append them to the #shadow-root via normal DOM methods, or you could utilize a <template>.

The `<template>` Element

The HTML template element is a unique element, used to hold content which will later be implemented.



<!-- a simple template example -->
<body>
 <template id="my-template">
  <!-- template content -->
  <p>A simple template!</p>
 </template>
</body>

<template> elements are parsed in HTML, but not rendered. Each <template> will have its own content property, which is DocumentFragment(much like a React fragment) of its contents. We can then clone this content and append it to our elements #shadow-root.

The <template> element can also be used in conjunction with the <slot> element, which serves as a placeholder for you to add dynamic content into a template. Its a tad out of the scope of this guide, but you can read more about it here.

Below i create a template containing the content that will be inside of the #shadow-root of my <type-writer> element, and append it:



  <template id="typewriter-template">
    <style>
    /* applying default styles to our element */
      textarea {
        background: black;
        color: limegreen;
        width: 200px;
        height: 70px;
        box-sizing: border-box;
        border: none;
        padding: 0.5em;
      }

      div {
        width: 200px;
        display: grid;
        height: 200px;
        grid-template-columns: repeat(4, auto);
      }

      span {
        height: 270px;
        width: 200px;
        display: grid;
        border-radius: 10px;
        overflow: hidden;
      }
    </style>
    <span> 
    <!-- screen -->
      <textarea readonly placeholder="..."></textarea>
    <!-- button container -->
      <div></div>
    </span>
  </template>



class Typewriter extends HTMLElement {
 constructor() {
  super();
  // attach shadow DOM to element
   let shadow = this.attachShadow({mode: "closed"});
  // Apply template
   let template = document.getElementById("typewriter-template");
shadow.appendChild(template.content.cloneNode(true));
  // implement functionality...
 }
}

Lastly, before implementing the final step, i'll add in all of the functionality for my custom <type-writer> element, completing our constructor:



class Typewriter extends HTMLElement {
  constructor() {
    super();

// attach shadow DOM
    let shadow = this.attachShadow({ mode: "closed" }),
      template = document.getElementById("typewriter-template");

// implement template
shadow.appendChild(template.content.cloneNode(true));

// Adding keys and additional functions
    let keys = shadow.querySelector("div");
    let screen = shadow.querySelector("textarea");
    let typed = new Event("typed");
    screen.addEventListener("typed", () => {
      screen.innerHTML = screen.innerHTML + "|";
    });
    for (let i = 97; i <= 122; i++) {
      let key = document.createElement("button");
      key.addEventListener("click", (e) => {
        backspc();
        screen.innerHTML = screen.innerHTML + e.target.innerText;
        screen.dispatchEvent(typed);
      });
      key.innerText = String.fromCharCode(i);
      keys.appendChild(key);
    }
    let del = document.createElement("button"),
      spc = document.createElement("button");
    del.innerText = "DEL";
    function backspc() {
      let l = screen.innerHTML.split("");
      l.pop();
      console.log(l);
      screen.innerHTML = l.join("");
    }
    del.addEventListener("click", () => {
      backspc();
      backspc();
      screen.dispatchEvent(typed);
    });
    keys.appendChild(del);

    spc.innerText = "SPC";
    spc.addEventListener("click", () => {
      backspc();
      screen.innerHTML = screen.innerHTML + " ";
      screen.dispatchEvent(typed);
    });
    keys.appendChild(spc);
  }
}

Registering our `<type-writer>` Element

Before we can use our new <type-writer> tag in our HTML code, we lastly need to register our component within the CustomElementRegistry. The CustomElementRegistry interface is implemented by the customElements object, which is where constructors for custom elements are stored, and can be accessed.

We can register our new element by using the customElements.define() method:



customElements.define("type-writer",Typewriter);

The first parameter is the tagname we want for our new element. This can be anything as long as a dash (-) is included within it. And then our second parameter is simply the constructor thats associated with our new custom element.

Once thats done, you can use it in your HTML and refer to it in your CSS and Javascript just as you would with any other built-in element! Pretty cool, huh?



<type-writer></type-writer>

Conclusion

And there you have it! I hoped this guide served useful for understanding how Web Components work, and how we can use the Shadow DOM and Custom elements APIs to create our own HTML elements.

Good luck, and happy coding! 😁

Forem: Deon Rich

Complete Guide to Building Games in the Browser

What is HTML Canvas?

Getting Started

Drawing Graphics

Sizing the Game Area

Applying a Static Fit

Applying a Theator Fit

Applying a Fullscreen Fit

Phone game area (720x1520):

Tablet game area (1920x1200):

Creating a Rendering Pipeline

Building Sprites

Background Sprites

Object Sprites

Character Sprites

Movement and Controls

Implementing Joysticks

Joystick Movement

Keyboard Controls

Character Rotation

Static vs Dynamic Movement

Collision Detection

Squares and Rectangles

Circles

Events

Putting it All Together

Understanding Speech Recognition and Building a Voice Controlled To-Do List

The Building Blocks of Speech Recognition

The Process of ASR

The Process of NLP

Building a Voice Controlled To-Do List

Using the Speech Recognition Service

Putting it All Together

Conclusion

A Quick Guide to Custom HTML Elements

What are Web Components?

The Shadow DOM

Creating our first Custom HTML Element

Creating a Web Component Constructor

Attaching a Shadow DOM

Filling Our Shadow DOM

The <template> Element

Registering our <type-writer> Element

Conclusion

The `<template>` Element

Registering our `<type-writer>` Element