Speaker 1: Welcome to the Deep Dive. We're the show engineered to
Speaker 1: give you that well, the ultimate shortcut to being truly
Speaker 1: well informed fast. We know your time is valuable, so
Speaker 1: our mission cut through the noise, deliver those surprising facts
Speaker 1: and the aha moments that make complex stuff just click.
Speaker 1: Today we are plunging right into the bedrock of the
Speaker 1: interactive web. We're talking HTML five, CSS and JavaScript, but
Speaker 1: we're doing it with a really fantastic twist. Instead of
Speaker 1: dry textbooks, we're exploring how these things spring to life
Speaker 1: through the world of games, creating games.
Speaker 2: That's exactly right. I mean, in this age of just
Speaker 2: constant information, understanding how the web actually works isn't just
Speaker 2: for developers anymore, is it. It's really about demystifying the
Speaker 2: tools that shape our well our daily digital lives, everything
Speaker 2: from simple web pages to really complex apps. And honestly,
Speaker 2: what better way to see these concepts in action than
Speaker 2: through you know, the fun and very real examples you
Speaker 2: find in games.
Speaker 1: Yeah. Absolutely, and our deep dive today comes straight from
Speaker 1: the Essential Guide to HTML five Using Games to Learn
Speaker 1: HT and all five and JavaScript by Genie Meyer. It's
Speaker 1: a really great resource. It shows how programming can actually
Speaker 1: be well an art form, but one that's surprisingly accessible.
Speaker 1: M hmm. The author makes this brilliant point. If you
Speaker 1: can put words into sentences and sentences into paragraphs, and
Speaker 1: you've got some logic, then you basically have the skills
Speaker 1: to program.
Speaker 2: It really is about breaking ideas down. It's logical thinking.
Speaker 1: Okay. So let's start with those fundamentals, the building blocks
Speaker 1: powering almost everything you see online. At the core, it's
Speaker 1: these three pillars, right, HTMO five, CSS.
Speaker 2: And JavaScript team, A perfectly coordinated team. Yeah, each one
Speaker 2: has a very specific job.
Speaker 1: So HTML five that's the structure, like the skeleton exactly.
Speaker 2: It lays out the content, defines the structure of the page.
Speaker 2: Think of it as the architect, okay, andss CSS is
Speaker 2: the designer. It adds all the style, the visual appeal,
Speaker 2: the colors, fonts, layout.
Speaker 1: Makes it look good, right.
Speaker 2: And then JavaScript that's the engineer, MA can things happen precisely?
Speaker 2: That's the dynam engineer breathing life into the page, interactivity,
Speaker 2: dynamic behavior, making things respond. And what's kind of amazing
Speaker 2: is how simple HTML five is underneath it all. It's
Speaker 2: fundamentally just a plain text document. You write it in
Speaker 2: any text editor. It's made of elements surrounded by tags
Speaker 2: like an image tagged MNG SRC, home, dot gift.
Speaker 1: Okay, MG src And you said that's a singleton tag. Yeah.
Speaker 2: See how there's no closing MLG. It just stands alone
Speaker 2: because it doesn't really wrap around other content. It just
Speaker 2: is the image placeholder.
Speaker 1: Ah okay.
Speaker 2: And every standard HTML page has this basic structure, right.
Speaker 2: You've got the main HTML tag inside that, a head
Speaker 2: section for stuff like the page title that's what shows
Speaker 2: up in the browser tag, right, and then the body
Speaker 2: that holds everything you actually see on the page. And
Speaker 2: nesting these elements it just makes it all clear. Title
Speaker 2: inside head, head and body inside HTML makes sense. Oh
Speaker 2: and an important quirk, HTML ignores extra spaces. If you
Speaker 2: want a line break, you have to use a specific
Speaker 2: tag brewer.
Speaker 1: So HTML for the bones the content, but CS as
Speaker 1: the style. How does that work? You mentioned cascating.
Speaker 2: Yeah, cascating it's a really powerful idea. It means styles
Speaker 2: kind of trickled down. Styles applied to a parent element
Speaker 2: will generally apply to its children unless you give the
Speaker 2: child a more specific rule.
Speaker 1: So you can set a font for the whole body,
Speaker 1: but make one paragraph different exactly.
Speaker 2: You can put CSS rules right inside an HTML tag
Speaker 2: that's called inline style, but it gets messi fast. More
Speaker 2: often you put it in a style block in the
Speaker 2: head or ideally in separate dot CSS files, especially for
Speaker 2: bicker sites, and it.
Speaker 1: Controls things like color, font size with oh yeah.
Speaker 2: Text aligne margin, padding, background color, tons of control over
Speaker 2: the look. And the best practice, like the book emphasizes,
Speaker 2: is the separation HTMIL for content, CSS for looks, JavaScript
Speaker 2: for action keeps everything way.
Speaker 1: Cleaner, makes maintaining it easier, I think. Okay, Now for
Speaker 1: the action part JavaScript, the engine right JavaScript.
Speaker 2: It's made of statements basically individual instructions usually end with
Speaker 2: a semicolon, uses variables to hold data like a player
Speaker 2: score or name, and functions to group chunks of code
Speaker 2: you want to reuse.
Speaker 1: Can you give a quick example.
Speaker 2: Sure, A really simple one is document dot rit document
Speaker 2: dot right. That line just writes the current date and
Speaker 2: time right onto the web page. Here. Document is an object,
Speaker 2: it represents the whole page. Right is a method an
Speaker 2: action that object can do, and date is a built
Speaker 2: in function that gives you the date.
Speaker 1: So objects have methods that do things.
Speaker 2: Got it exactly, and you declare variables, often with var
Speaker 2: like var score eual zero. That single equal sign is
Speaker 2: for assignment, putting the value zero into the variable score,
Speaker 2: not for comparing things, right, that's different. For comparison, like
Speaker 2: checking if the score is zero, you'd use two equal
Speaker 2: signs score equal zero crucial difference.
Speaker 1: Okay, good distinction.
Speaker 2: And programmers write their own functions all the time. That's
Speaker 2: key for reusing code, keeping things organized. Don't repeat yourself.
Speaker 2: Dry is a big principle, makes sense. And one little
Speaker 2: style thing you'll see everyone where camel.
Speaker 1: Case camel case.
Speaker 2: Yeah, for variable names like number of turns. See how
Speaker 2: the O and T a capitalize like humps on a
Speaker 2: camel just makes multi word names easier to read without spaces.
Speaker 1: Ah, number turns, I see it. Okay, so that's the theory.
Speaker 1: HTML structure, CSS style, JS action. But how does building
Speaker 1: a game actually help cement these ideas. Let's unpack that right.
Speaker 2: This is where it gets really practical and frankly fun.
Speaker 2: How do you even draw things dynamically? HTML five gave
Speaker 2: us the canvas element.
Speaker 1: The canvas like a painter's canvas exactly.
Speaker 2: It's your digital drawing board. It lets you draw lines
Speaker 2: shapes images directly onto a part of the screen, a
Speaker 2: huge step up from old HTML's boxy feel.
Speaker 1: So you're not stuck with just text and static images.
Speaker 2: Not at all. But the coordinate system is a bit quirky.
Speaker 2: Quirky how the starting point coordinates zero zero isn't the
Speaker 2: bottom left like in math class. It's the upper left
Speaker 2: corner of the canvas nupper left okay, and the wy
Speaker 2: valu's incre as you go down x increases to the
Speaker 2: right like normal. But why is flipped from what you
Speaker 2: might expect. Huh.
Speaker 1: Takes getting used to, I guess it does.
Speaker 2: But once you have that, you can draw use methods
Speaker 2: like movetoe to position your virtual pen and then line
Speaker 2: toe to draw a line to another point, like connecting
Speaker 2: the dots sort of. Yeah, And you see this perfectly
Speaker 2: in the slingshot game from the book, drawing the slingshot
Speaker 2: string as.
Speaker 1: You pull it back right okay, and circles arcs.
Speaker 2: There's an arc method for that. But here's another fun detail.
Speaker 2: Angles in most programming, including JavaScript for canvas, are in radians,
Speaker 2: not degrees radiance.
Speaker 1: Oh boy, I remember those from math, dot pi.
Speaker 2: And all that exactly. So three hundred and sixty degrees
Speaker 2: is two math dot pi. Radians one hundred and eighty
Speaker 2: degrees is math dot pi. It's essential for getting circles
Speaker 2: and rotations right.
Speaker 1: Okay, note to self brush up on radiance.
Speaker 2: Huh yeah. Beyond lines and arcs, you can use draw
Speaker 2: image to slap images onto the canvas or create smooth
Speaker 2: color transitions with create linear gradient the bouncing ballgame. Use
Speaker 2: is this for cool looking walls. Nice And for text
Speaker 2: like scores or messages, use fill text. You see that
Speaker 2: in the memory game or Hangman.
Speaker 1: So you can write text right onto this drawing surface.
Speaker 2: Yep, and super important for games. Transformations things like save, translate, rotate,
Speaker 2: and restore.
Speaker 1: What do those do?
Speaker 2: Save remembers the current state like position rotation. Translate moves
Speaker 2: the origin point zero zero somewhere else. Rotate spins the
Speaker 2: coordinate system, and restore puts everything back to how it
Speaker 2: was when you saved.
Speaker 1: Why would you do that?
Speaker 2: Think about the cannon ball game. You want to rotate
Speaker 2: the cannon around its base. Right, you translate to the
Speaker 2: cannon's base, rotate it, draw the cannon, then restore so
Speaker 2: the rest of your drawing isn't rotated.
Speaker 1: Ah, clever, So you isolate the rotation just to the.
Speaker 2: Cannon precisely keeps things manageable.
Speaker 1: Okay, so that's getting things drawn, but making them move
Speaker 1: and react to me the player. That sounds like JavaScript.
Speaker 2: Again absolutely, This is where event handling comes in. The
Speaker 2: page needs to listen for and react to things the
Speaker 2: user does events clicking the mouse exactly. Mouse events are huge.
Speaker 2: The Slingshot game is perfect here. Mouse doown fires when
Speaker 2: you press the mass button that starts the poll. Mass
Speaker 2: move fires as you move the mouse while the button
Speaker 2: is down that stretches the string, and mouse up fires
Speaker 2: when you release the button that launches the projectile.
Speaker 1: Okay, mouse down, mouse move, mouse up makes sense. And
Speaker 1: you connect code to these events.
Speaker 2: Yep, using something called ad event listener. You tell the browser, hey,
Speaker 2: listen for a click on this button, and when it happens,
Speaker 2: run this function.
Speaker 1: Got it? What about? How do you make it happen repeatedly?
Speaker 2: Usually with set interval. You give it a function to
Speaker 2: run and a time interval in milliseconds. Say run this
Speaker 2: update function every thirty milliseconds. That creates the continuous motion
Speaker 2: for the bouncing ball or those fly in effects in
Speaker 2: Rock Paper Scissors, and you can stop it yep, with
Speaker 2: clear interval. You need that when the game ends or
Speaker 2: the animation sequence is over. There's also set time out,
Speaker 2: which runs a function once after a specified delay, useful
Speaker 2: for pauses like in the Memory game before mismatched cards.
Speaker 1: Split back over right, set interval for loops, set time
Speaker 1: out for delays.
Speaker 2: Okay, Now games need more than just movement. They need
Speaker 2: some intelligence, right rules, randomness keeping track of things.
Speaker 1: Yeah, like how does the computer opponent in Rock paper
Speaker 1: scissors decide it's move? Or how does the dice game work?
Speaker 2: Good questions For randomness, JavaScript gives us math dot random.
Speaker 2: It generates a number between zero and just under.
Speaker 1: One a decimal. How's that useful for dice?
Speaker 2: You can mine it with math dot floor. Math dot
Speaker 2: floor rounds down to the near sohole number. So if
Speaker 2: you want a number from zero to two for rock zero,
Speaker 2: paper one scissors two, you can do math dot floor
Speaker 2: math dot random three.
Speaker 1: Okay, math dot random three gives zero to just under three.
Speaker 1: Mach dot floor chops off the decimal, giving zero one
Speaker 1: or two exactly.
Speaker 2: For a six sided die, it'd be math dot floor
Speaker 2: math dot random six plus one to get one through six. Technically,
Speaker 2: it's pseudo random. Computers follow instructions, so it's not truly random,
Speaker 2: but it's unpredictable enough.
Speaker 1: For games, close enough for rock paper scissors anyway.
Speaker 2: Right then you need logic game rolls. That's where I
Speaker 2: false statements come in.
Speaker 1: Like if the dice roll is seven, then you.
Speaker 2: Win precisely or false a fils for multiple conditions the
Speaker 2: dice game example, shooes this well, win on seven or eleven,
Speaker 2: lose on two, three or twelve on the first roll,
Speaker 2: otherwise establish a point. There's also switch statements, which can
Speaker 2: be cleaner. Sometimes we're checking one variable against multiple specific values.
Speaker 1: So that's the decision making. What about remembering things like
Speaker 1: in the dice game, knowing if it's the first roll
Speaker 1: or later roll.
Speaker 2: That's managing the application state. You need variables to keep
Speaker 2: track of the current situation. Often these are global variables,
Speaker 2: variables declared outside functions so they're accessible everywhere and retain
Speaker 2: their value between function calls. You might have a variable
Speaker 2: it's your first throw set to true initially, then set
Speaker 2: it to false after the first roll.
Speaker 1: Okay, So state variables track what's going on.
Speaker 2: Yep, and another key part for games like bouncing ball
Speaker 2: or mazes is collision.
Speaker 1: Detection, figuring out if things have hit each other exactly.
Speaker 2: The code needs to calculate based on object positions and
Speaker 2: sizes if they've overlapped, if the ball hits a wall
Speaker 2: or the player hits a maze boundary. This usually involves
Speaker 2: some math checking if coordinates are within certain boundaries, or
Speaker 2: if the distance between two objects is less than their
Speaker 2: combined radii.
Speaker 1: For circles, mass strikes again always okay, this is getting complex.
Speaker 1: If you have lots of balls bouncing, or lots of
Speaker 1: maze walls or cards in a deck, how do you
Speaker 1: organize all that data? Sounds like it could get messy.
Speaker 2: It absolutely could. That's why data structures are critical. The simplest,
Speaker 2: most fundamental one is the array.
Speaker 1: It's like a list, exactly, an ordered list of items.
Speaker 1: You can have an array of scores, an array of
Speaker 1: enemy positions, whatever. And the book shows how you can
Speaker 1: have arrays of arrays, basically a grid or table structure.
Speaker 1: The memory game uses this for pairs of matching cards.
Speaker 1: The quiz game uses it for facts, linking questions and answers.
Speaker 2: Arrays with an arrays okay, and elements are numbered starting
Speaker 2: from zero.
Speaker 1: Always remember the first item in a JavaScript array is
Speaker 1: at index zero, the second at index one, and so on.
Speaker 1: Trips up beginners.
Speaker 2: All the time index zero.
Speaker 1: Got it.
Speaker 2: But what if you need something more complex than just
Speaker 2: a list, Like a playing card needs a suit and
Speaker 2: a rank and maybe an image.
Speaker 1: Perfect example, that's where you create your own programmer defined.
Speaker 2: Objects, making your own things.
Speaker 1: Pretty much, you define a blueprint like a card object,
Speaker 1: then you can create instances of that card, each with
Speaker 1: its own properties card one dot suit, hearts card one
Speaker 1: dot value, ten card one dot picture, King of Hearts
Speaker 1: dot PNG.
Speaker 2: So each card is an object with its own data
Speaker 2: bundle together exactly. The Maze game might have wall objects,
Speaker 2: each with its x, y width and hype properties. It's
Speaker 2: incredibly powerful for organizing complex game elements.
Speaker 1: And how do you manage lots of these objects? Yeah,
Speaker 1: all the things on the screen that need to be drawn.
Speaker 2: A common pattern show in the Cannonball and Slingshot games
Speaker 2: is to have an array maybe called everything, that holds
Speaker 2: all the objects currently active.
Speaker 1: In the game, an array of objects.
Speaker 2: When you need to draw everything, you just loop through
Speaker 2: that everything array and tell each object to draw itself
Speaker 2: using its own draw method. And arrays have methods like
Speaker 2: push to add a new object to the end like
Speaker 2: adding a cannon ball when fired, and splice to remove
Speaker 2: an object from the middle like when a target is hit,
Speaker 2: push to.
Speaker 1: Add, splice to remove. Okay, that keeps the main list.
Speaker 2: Tidy, right, It's all about managing that complexity and beyond
Speaker 2: the core game mechanics. HTML five and its friends offer
Speaker 2: ways to really enhance the whole user experience by way well.
Speaker 2: Think about form input. HTML five added new input types
Speaker 2: that can automatically validate user entries. For instance, input type
Speaker 2: number min one max ten tells the browser to only
Speaker 2: accept numbers between one and ten. The browser can handle
Speaker 2: the basic check for you.
Speaker 1: Oh that's built in.
Speaker 2: Nice Yeah, and CSS can style these inputs based on
Speaker 2: whether they're valid or invalid. The bouncing balls shows how
Speaker 2: an input field might turn red if you enter something wrong,
Speaker 2: giving immediate feedback without needing complex JavaScript for simple checks.
Speaker 1: Instant visual feedback cool.
Speaker 2: Then there's audio and video. H to Mail five made
Speaker 2: embedding media way easier with the audio and video tags,
Speaker 2: just drop them in pretty much. The quiz game example
Speaker 2: shows using video to play clips, you often include multiple
Speaker 2: source elements inside pointing to different file formats like MP
Speaker 2: four webmog Why different format browser compatibility. Yeah, not all
Speaker 2: browsers support the same video or audio formats, so providing
Speaker 2: options ensures it works for more people.
Speaker 1: Makes sense.
Speaker 2: Any catches AutoPlay Browsers have gotten really stripped about letting
Speaker 2: pages automatically play sound or video because well, it can
Speaker 2: be annoying. True, so often media won't play until the
Speaker 2: user interacts with the page, like clicking a button. One
Speaker 2: workaround shown in the book is using the muted attribute
Speaker 2: on a video. It might be allowed to AutoPlay if
Speaker 2: it starts silent.
Speaker 1: Ah clever.
Speaker 2: And if you have multiple sounds like in Rock paper Scissors,
Speaker 2: maybe a sound for rock paper scissors win lose. You
Speaker 2: can get a list of all audio elements using document
Speaker 2: dot get elements by tag name audio and manage them
Speaker 2: through code.
Speaker 1: Okay, managing sounds? What else?
Speaker 2: A really powerful one local storage.
Speaker 1: Bo whole storage store and stuff on my.
Speaker 2: Computer exactly HTML five's local storage. Let's a web application
Speaker 2: save data directly in your browser and it stays there
Speaker 2: even after you close the browser and come back later.
Speaker 1: WHOA like cookies but more kind of like cookies? Yeah?
Speaker 2: Ye but design for larger amounts of data, and it
Speaker 2: doesn't get sent back to the server with every request.
Speaker 2: It's meant for the application to use locally. The Maze
Speaker 2: game uses it beautifully to save the Maize layout you created, so.
Speaker 1: I could build a Maze, close my browser, come back tomorrow,
Speaker 1: and it's still there if.
Speaker 2: The game uses local storage to save it. Yes, it's
Speaker 2: incredibly useful for saving game progress, user preferences, offline data.
Speaker 2: But you know, it also raises interesting points about what
Speaker 2: websites store locally on your machine. It's key to how
Speaker 2: many sites remember you or your settings, and it.
Speaker 1: Ties into things like behavioral market.
Speaker 2: Potentially it can be part of that ecosystem. Yes, storing
Speaker 2: identifiers or preferences locally. The key thing from the book's
Speaker 2: perspective is its technical capability for saving application state persistently.
Speaker 2: One detail. Local storage only stores data as tech strings,
Speaker 2: so if you want to save complex data like the
Speaker 2: array of walls in the Maze, you need to convert
Speaker 2: it to a string first, maybe using the join method,
Speaker 2: and then parse it back using split when.
Speaker 1: You load it, encode and decode. Okay, wow, so stepping back,
Speaker 1: what does this all mean for you? Listening. We've really
Speaker 1: unpacked a lot here. We've seen HTML five giving structure,
Speaker 1: CSS adding the style, and JavaScript bringing it all live
Speaker 1: with interaction and logic. And we saw it all through
Speaker 1: games randomized bouncing balls, rotating cannons, solvable meses. It shows
Speaker 1: the power packed into just these three core web technologies.
Speaker 2: It really does. And this kind of deep dive looking
Speaker 2: through the lens of games, I think it shows that
Speaker 2: programming isn't just about typing code. It's about problem solving,
Speaker 2: breaking down complex ideas into smaller manageable steps. It's about
Speaker 2: managing state, knowing what's happening when, and it's about responding
Speaker 2: to users. The art of it, like the author suggests,
Speaker 2: really shines through when you see those clever solutions using
Speaker 2: method eaight into for precise aiming angles, or a smart
Speaker 2: algorithm like fisheryates for shuffling cards properly. That's where creativity
Speaker 2: meets logic.
Speaker 1: Yeah, hopefully this whole discussion gives you a new appreciation
Speaker 1: for all those web apps you use daily. Maybe you
Speaker 1: see them a bit differently now, and perhaps it's even
Speaker 1: sparked some curiosity. Maybe you're thinking about how you could
Speaker 1: use these tools even in a small way to build
Speaker 1: something or make it your own.
Speaker 2: Definitely, And here's a final thought to chew on. If
Speaker 2: you can describe the rules of a game, how it flows,
Speaker 2: how players interact, think about that process. What other processes
Speaker 2: or systems in the real world could you describe that way?
Speaker 2: What else could you potentially model, simulate, or even automate
Speaker 2: using just these fundamental web tools. Once you start seeing
Speaker 2: the web not just as something you consume, but as
Speaker 2: a platform you can build on, while the possibilities really
Speaker 2: open up up