DAVID MALAN: So why don't we go ahead and begin our 1:00 PM to 2:00 PM Eastern session-- an overview of the classes that you can teach before or after CS50AP. This, like a lot of CS50, will be a bit of a fire hose-- a lot of information. But it's really just meant to give you a taste of what is available to you optionally. 

Indeed, over the past few years, though we began with just CS50 the course, which composes much of our discussion in the past few days, thanks to Brian and Colton and other colleagues of ours, have we begun really building out a curriculum of sorts that's particularly well-suited for high school and/or middle school students, so that teacher is teaching CS50AP don't just have one curriculum at their disposal. But they have more runway for their students. So students might take one class before CS50AP, one or more classes after CS50AP, or just CS50AP, or one of these other classes themselves. It really is up to you how you might like to assemble any of these building blocks. 

So we thought we'd give you a whirlwind tour of six other courses, one of which you've seen already, and three of which are related to one another. So it's not quite as much as it might seem. Brian, you know. Allow us to have our colleague Colton say a formal hello, so you know whom to expect in a few minutes, too. 

COLTON OGDEN: Hi. Nice to see everybody here. Hope you're all staying safe. 

DAVID MALAN: Colton will be introducing in just a bit our game development class, which is particularly well-suited for a lot of high school students' interests. So here on the screen, you should see next to me the list of six other courses that are currently in our curriculum. All of them have a single or one or two characters that describe them. 

CS50B is a course for computer science for business professionals. CS50L is CS50 for lawyers. CS50T is understanding technology. And then we have three follow-on classes, CS50AI, which is an introduction to AI with Python; CS50G, taught by Colton, an introduction to game development; and CS50W, like CS50AI, taught by Brian, Web Programming with Python and JavaScript. 

And I think if of any interest to you in teaching these classes, be it this coming year or down the road, hands down, I think the best preparation for doing so is to simply take the courses themselves. They're freely available as OpenCourseWare. We'll provide all of the URLs as we go here. But they're also centrally located, if you would like, on edx.org, where you can sign up for free for audit status and follow along at your own pace, if you might want to prepare over the summer or some future year for any of these curricula. And indeed, that's much like our own teaching fellows become teaching fellows because they have quite simply taken successfully any of these classes. 

To help give you a mental model for how everything fits together, if you think of CS50 itself or CS50X, the OpenCourseWare version of the class, as the backbone or the main class that students have long taken at Harvard, these other courses now fit into that pipeline either as predecessor courses or follow-on courses. So a possible model would be for a student to take CS50b or L or T, and then CS50X, and then to take CS50AI or G or W or even multiple combinations thereof. 

The first three courses on the left, B, L, T, are essentially mutually exclusive. We'll see that there are differences among them, so they don't need to be taken one or the other. The three follow-on courses can be taken in their entirety. 

So you could imagine, for instance, at the high school level, perhaps a student starts out freshman year with CS50T. Maybe sophomore year, spends time on CS50X or really CS50AP. And then maybe junior and/or senior year, has an opportunity to take something like the AI class, the games class, for the web class. 

Of course, two of these we're now well familiar with. CS50T plus CS50X compose what we've been calling CS50AP. So please interject at any point if you have any questions. And if I miss a hand, Brian or Colton, please do just chime in and call my attention. 

But why don't we dive in first, just more formally, to CS50T, which we've been taking for granted as just part of CS50AP's curriculum. But again, factoring that out and maybe having less comfortable or younger students simply start with that piece, as opposed to diving into CS50AP itself, is one viable option. So here comes the whirlwind tour. 

The syllabus of this class is essentially divided into these six large topics. The goal of this class ultimately is to provide students and of any age with really an understanding of the technology that they see and hear about every day, but don't necessarily understand. And we break the course down into these six components. And let me give you a quick tour of each of those. 

So on the hardware front, we start, not unlike CS50 itself, with a look at binary, and more generally, representation of information. But we focus a bit more on hardware than we do in CS50 itself, looking more at things like CPUs, the brains of the computer; hard drives, and how data is actually stored underneath the hood; and even talking about peripherals and connectors, the plugs that you see on the back of the computer. Colton might remember this throwback from a few years ago when we filmed this. 

The course also, albeit on video, has this lab component where we take things apart. We show students on camera pieces inside of a computer. And so what's especially fun about CS50T, really, in isolation, if it were taken or taught as a course unto itself, is if you have access to an old computer, a PC or a Mac, that you can take apart, it's actually a lot of fun to enable students to play more hands-on with what's inside the computer, or conversely, to have them build up a computer based on those same parts. 

We then focus in CS50T on the internet and what it is. And we talk about things that many students will take for granted. If they're fortunate to have internet access at home, we contextualize what that cable modem is from Comcast or any other provider and what all of those wires actually do and mean. 

We show them on their Mac or PC incarnations of how they're connected to the internet. So we talk about IP, IP addresses, and DNS, and DHCP. And if you yourself aren't familiar with that alphabet soup, that's totally fine. Again, taking the course is perhaps the best preparation. And here is just a similar view on Windows. And then, again, we keep this in context with which students are familiar-- talking about home networks that might have WiFi, that might have wired devices, that might have phones or laptops or television set-top boxes, and try to help students understand the technology they see and/or use every day. 

We spend time, too, on multimedia in this class. And we introduce students to audio, video, and other forms of multimedia as well. And we give them a sense of how, for instance, music might be synthesized, talking about formats like Mitty, which, if unfamiliar, is a way of encoding music digitally, so you can interact with it with a computer. 

We talk about how images are represented. Here's a 1-bit image of a smiley face using just a single bit for black or white. We talk about image compression. 

So given an image like this, let me actually ask the group, what might the opportunity here be to compress an image like this if it's stored in a digital file format? How might you go about compressing this apple that you see on the screen here against this blue backdrop? Any ideas or intuition for where the opportunity is? Brett? 

AUDIENCE: Yes, you could condense and consolidate the colors. 

DAVID MALAN: Consolidate the colors? Yeah. 

AUDIENCE: So like all the same blue color could be combined and just repeated. 

DAVID MALAN: Yeah, exactly. There's a lot of redundancy here. There seems to be some common red, some common blue. So you could effectively store that same image by factoring out a lot of the common blue. And instead of saying the digital equivalent of blue, blue, blue, blue, blue, blue, blue, blue, blue, blue, blue, blue, and so forth, you could just say blue 10 times, blue 10 times. And just like it sounds faster, it would similarly take less space in memory. 

Here's a clip from, for instance, a video. And you have a bumblebee on top of some flowers. And you can see that the flowers are not moving, but the bumblebee is. 

And so here might be an opportunity to get students thinking about how you can save space by not repeating yourself as much. And maybe you could in a video file format do something similar in spirit, but only track the movements of the bumblebee. And don't worry about redundantly storing those flowers because, again, they appear again and again stationary. 

Of course, it's quite common in TV and movies to see ridiculous scenes like this. This is taken from like CSI something or other. And of course, the police or investigators are able to zoom in on that glint in the person's eye and figure out who the suspect is. We point out to students that they're just going to see generally a blurry mess. And if you can see this on my screen, albeit a bit small, there is really little identifying information of who the bad guy is, at least from that frame in the show. 

So we talk, too, in this class about security and passwords. If you see any of your own passwords on this list, you're part of the lecture now because these are the top 10 most common passwords as of a year or so ago. They're not particularly secure. And so we talk to students about why they're not secure and how they might use things like two-factor authentication or other techniques to keep them secure, whether it's with their accounts, or whether it's in WiFi. 

And we also talk about issues of privacy, for instance, by way of cookies. You've probably heard that cookies somehow can be used to track you on the internet. We help students understand technically what that means and why they're not all bad and actually do solve technical problems. 

And then, toward the end of the semester in CS50T, we introduce students to a little bit of web development. And we start with HTTP, the protocol that moves the data back and forth. But we also introduce them hands-on to HTML and CSS. And we help them understand, too, really as a stepping stone to something more like CS50 itself, that there's ways of representing this information in different ways. Just like you have a family tree where you might have these nodes, and a graph with edges and circles or squares or the like, we can see something like HTML code and start to think about it in different ways, setting the stage for more sophisticated discussions in a higher-level class. 

And then lastly, we focus on programming with the students. And we introduce them to pseudocode and searching the phone book, for instance, algorithmically. But we spend a good amount of time on Scratch. And that is their only language in this course with which they experiment. But they have an opportunity to apply those same ideas. 

So if you're curious-- and again, these slides are on the website-- you're welcome to go to this URL if you'd like to see a sample assessment. I'll go ahead and paste this into the chat window. Actually, let me add the HTTP. That's a sample assessment, but there are other assignments week to week throughout the course, not just this end-of-course assessment. 

But that'll give you a sense of the summative questions that we tend to ask of students. And they're similar in spirit to CS50's own in that they're meant to be short answers or the like. Before I give you a whirlwind tour of CS50B, [? Hani, ?] any questions or comments? 

AUDIENCE: I'm sorry. This was back to the image compression. 

DAVID MALAN: Oh, sure. 

AUDIENCE: Of course, if you save the difference between the pixels instead of the pixels themselves then you can save a lot. 

DAVID MALAN: Yes, indeed. So opportunities to talk about different forms of representation, too, of the format itself. So CS50B, for business. So this course has a lot of overlap with the course's content, but the target audience is a bit different, and the mindset is a bit different. So generally speaking, this course is taught to older students, be they adults or students at Harvard's Business School. 

But the goal there is not to just understand technologies that we see and use every day in a consumer sense, but to understand technologies on the basis of which you might make this decision. So if you happen to be running a company, or you're the CTO or the CEO or a manager or someone that works with technical people, but isn't necessarily as technical themselves, what do you need to know about technology in order to just get real work done and hold your own in conversations with more technical people? So as such, it can be applied to younger audiences, certainly, as well. 

So the six categories into which this course is structured are a little similar in spirit, but these six here. And let me give you a quick tour of those. So we begin with computational thinking, not unlike CS50 itself. And we help students think about how you take inputs, and your goal is to get outputs, and in between there are these things called algorithms. 

But in the business version of the class, we spend a bit more time on sophistication of concepts like this-- so running time, and how you think about not just whether or not an algorithm will find Mike Smith in a phone book or solve some problem correctly, but does it do it well? Does it do it quickly and efficiently? So you can start to think, as a business person might, in terms of cost, in terms of time or money or the like, thereby having all the more building blocks at your disposal for discussions of trade-offs. 

We talk about programming languages. So here, we give students a sense of what's out there. We don't teach them any of these languages in any detail. We show them simple snippets, just so they can understand what features exist in programming languages. 

But as with the technology class, we use Scratch because it allows us to explore a procedural language, as well as a number of topics that they'll encounter in the real world. Scratch, of course, supports things like events. And anytime you and I use our phones these days, anytime you touch your tap or swipe, those are all events. And so we help students understand how these paradigms of programming map to actual technologies they use. 

We talk again, as in T, about the internet. But we go into a little more detail into the alphabet soup so that they understand the kinds of jargon that might get thrown around by their own engineers, whether they're a startup or a larger company that just uses IT Infrastructure. We introduce them to web development. 

The goal is not to turn them into web designers, but just so that they know what this HTML and CSS and other such tools are. So we show them and allow them a hands-on opportunity to play with HTML again. But we also spend a bit more time translating Scratch to something like JavaScript, a language that's commonly used in the context of web programming. So there, too, the students of CS50B have a mental model of how more pieces of the puzzle-- no pun intended-- interconnect. 

And then, quite different from CS50T, we talk about so-called technology stacks-- like how all of the various technologies and acronyms and languages and protocols somehow fit together. And we break things down into front end, so to speak-- the part of the interface that humans see. And we rattle off, and we give them just some sense of what's out there and in vogue these days in terms of libraries and frameworks for front end technologies. 

We do the same for back end, giving them a sense of what languages are in vogue, what frameworks are in vogue-- not so that they know themselves how to use them, but just so that they know that, one, they're out there. And two, if there's another one tomorrow, it's not really that big of a deal because it fits into a paradigm with which they've already had some comfort. We talk, too, about databases. And so middle tier architectures or, depending on how you might want to think about the tiers. And, again, some big-name products that they might know of in Oracle, in MySQL, in others as well, just so that, again, they've been exposed to these things. 

Then we talk about mobile, too. Especially in the context of businesses, it's often a decision whether to have a website or a mobile website, a mobile application. Should it be Android or iOS or both, and the like? And we help them think about the non-trivial costs-- again, in terms of finances or time or humans-- in developing solutions to all of those various platforms. 

And we talk, too, about data itself and how you go about structuring data. For instance, a spreadsheet, with which most business types might be familiar, but we introduced them to SQL, which we don't do in the technology class. And we introduced them to NoSQL, again, at a high level, but so that they understand that it allows you to store, for instance, in this case more structured data, and not just flat row-by-row based data instead. 

Cloud computing-- a topic, too, that's distinct to this class. And we talk about some of the biggest players out there. What can Amazon, Google, Microsoft, and others do for you and your business? 

And we talk about some of the technologies and principles that underlie cloud computing that someone has to understand. And so we talk about scaling and replication and containerization and virtualization-- a lot of the alphabet soup here-- so that, again, when it comes to asking questions of their engineers or trusting in the correctness of their decisions, they at least understand how their own servers or applications or products work. Even if it's at this level of abstraction, they're not completely dependent on the technical savvy only of others. 

So I'm a little worried this URL is not going to work either. But allow me to-- oh, this one does work. So this one is a sample assessment from the end of this business-oriented class, if you'd like to take a look. Again, I'll open up the other one in just a bit. 

But again, the goals of the class are a bit different. To recap, T is more about technology for everyone from more of a consumer angle. B is more about business-type mindsets and how you might use technology to make better decisions. But the audiences can certainly be one and the same. 

Before I forge ahead to a third and final precursor to CS50 itself, any questions or comments here that I can answer? No? All right, seeing none, allow me to give you the third and final short-form course that might proceed CS50-- CS50 for lawyers, so to speak. 

So this course of the three we've now discussed is a bit longer than the others with more detail and goes into more discussion of topics that intersect technology with society. The original target audience was, indeed, law students or lawyers. But here, too, there are wonderful opportunities I think for high school or even middle school level to focus on some of those exact intersections. And I'll give you a few examples of those. 

In terms of the syllabus, it's a little longer, and it's structured along the lines of these topics here. But as with the business class, we begin with some commonalities. We introduce students first to computational thinking, as before. But we get them thinking more about representation of not just ASCII or English, which had its start with just seven bits. 

But we get them thinking about Unicode and larger character sets and the implications for internationalization and representation of other languages as well. We talk about algorithms, but we also spend a bit more time helping them think about some of the primitives that might underlie how you implement algorithms. For instance, we spend more time talking about abstraction. On the screen here is, of course, what? What does anyone see, if you'd like to shout it out or raise your hand? Anyone? Not a trick question. 

AUDIENCE: A cube. 

DAVID MALAN: A cube, I heard. So it's indeed a cube. And really, you know that, you say that, because we all have in our minds the definition of some abstraction of what a cube is. 

But frankly, what I am seeing is maybe three diamonds that are all touching each other. Or what I'm seeing is a diagonal line and another diagonal line and two more diagonal lines that connect with each other. And you can imagine really getting into the weeds of describing what you see. 

But thankfully, as [? Momadu ?] notes, we have an abstraction known as a cube. And so we get students thinking about the utility of these abstractions versus the price you pay by not getting into the weeds of what it is you're trying to say, and appreciating what computers can do and can't do when it comes to following commands. 

We talk about programming languages as before, but we go into a little more detail in the context of the law class, looking first at a higher-level language like C, looking at a lower-level language like assembly language, and looking at the lowest of languages, like machine code, which is just 0's and 1's. And we do this so that aspiring attorneys down the road actually have a better understanding of intellectual property, what it might mean for someone's code to be similar to another, what it might mean for someone's algorithm to be identical to another, just to that they have this bottom-up understanding of those principles. And they don't have to just take for granted that, oh, an algorithm is step-by-step instructions for solving some problem. 

But what does that really mean when computers and companies and owners and intellectual property gets involved? We talk about the limitations of computers. 1999 was a problematic year, a.k.a. Y2K, because so many companies and so many products were using just two digits to store years instead of four. And so bad things might have very well happened on scale. 

We talk about floating point values-- numbers that have decimal points in them-- and give real-world examples where failure to appreciate or failure to protect against these realities of computing can lead to potentially catastrophic failures. Here's a Boeing 737, I believe, that essentially would turn off after 248 days in the sky because a 32-bit counter, a variable in memory, would overflow potentially. And bad things would happen. And the solution in the short-term from Boeing was literally reboot your planes every 247 days. So we get students thinking about how software decisions and hardware limitations might have very significant real-world ramifications. 

We talk in a bit more depth about algorithms and data structures-- more similar, if you will, to CS50 itself and CS50AP. We go into things like bubble sort, for instance, or selection sort, for instance, or really sorting in general. We talk about data structures as they are incarnated in languages, like Python having dictionaries and lists and other such things. And then we go into more detail on cryptography. 

We, of course, spend a bit of time on this in CS50 itself with Caesar or Vigenere or few such problem sets as well. But we spend a bit more formality on this, getting students thinking about what it means to encrypt information, whether it's with substitution ciphers, whether it's an attack on the same using so-called "frequency analysis." And we get students thinking a little more adversarily about some of the technology that they might build in CS50, but might not necessarily think twice about at that point in the course. 

We talk about what it means to hash passwords. Not just encrypting data, but hashing them in one direction, and what it might mean if a company's database is hacked or compromised, and what the threats to a customer's privacy might be. We talk about encryption a bit more mathematically, a bit more formally, in the context of, say, public-key cryptography, if you're familiar. And we talk about digital signatures, which is sort of an opposite application of the same technology, in order to prove mathematically that I am who I claim to be. 

We intersect with more modern technologies like Blockchain and cryptocurrencies like Bitcoin and the like and help students understand what is interesting about those technologically and what kinds of problems they can actually solve. And we talk about cybersecurity in much more detail, too, when we talk about how hardware itself-- what various hardware components inside of a computer do, and which of those are potential threats to one's privacy if, for instance, someone has physical access to the memory or some other device. We talk about deleting files, be it on Mac OS or Windows. And just emptying the recycle bin or trash can is not really the best way to cover your tracks or to remove sensitive information. And we help students understand why. 

We talk about how you might intercept network traffic-- everyone uses WiFi or mobile networks these days-- and what it might mean to use things like HTTPS for encryption. And then we spend a bit more time intercepting things like the primitives that underlie internet technologies as they relate to bigger-picture uses of cloud computing. And we talk quite simply about how you get data from point A to point B. But then we start talking about how you get a lot of data from point A to point B, maybe with one server initially, or a bigger server as load scales. 

And we talk about horizontal scalability, vertical scalability, and the kinds of approaches you can take to solving some problem, even if you're not an engineer yourself. Maybe you're just the one with the checkbook. But you need to decide, are you going to get a lot of really cheap machines? Are you going to get a few really beefed-up machines? And what are the trade-offs, being the operative word, going to be? 

And then, again, we talk in a bit more detail about very modern technologies like virtualization and containerization-- which, as an aside, if unfamiliar, you've been using for some time. Whether you use CS50 IDE or any other tools, they're out there. And we help students understand those building blocks. 

And then lastly, at the tail-end of CS50 for lawyers, do we introduce students-- as often we do-- to a bit of web development and helping them understand HTML. We spend a bit more time on JavaScript and that event-based model I alluded to before, clicking and dragging and changing things on the screen, and how you write code to interact with humans. We talk a bit more about database design-- so not just using SQL, but using it efficiently, designing and choosing the types of your language more aptly, and even more sophisticated techniques like transactions and locks. How do you assure the integrity of your data, especially when you have a lot of it coming in, especially for popular websites and tools? 

And then at the very end of the semester, do we revisit and reconnect some of the topics, talking about things like denial of service attacks on scale on the cloud, talking about defenses or potential weaknesses like SSL or TLS, talking about more precise attacks using code-- cross-site scripting attacks, where someone tricks you into executing code in your users' browsers that they provided to you. Or something like a cross-site request forgery, where you trick a user into sending a request to a website that they might not have even intended. And we talk, of course, about databases as well, and hashing those passwords, and what that really means. 

We talk about SQL injection attacks, threats against the same. We talk about Man in the Middle attacks. We talk about phishing and really a whole lot of technologies intersecting with society. 

And indeed, what we do at the end of the course, particularly by way of a colleague of ours, Doug, we start talking about really the real-world ethical issues and the legal issues that result from these intersections. And so we consider implications of open-source software and the licensing thereof and what you need to be mindful of, and what the trade-offs are of open-source software that everyone can see, or closed-source software that no one can see. Talking about disruptive technologies and things that the law hasn't even caught up to yet. 

For instance, being able to 3D-print guns that aren't even metallic and can't be detected anymore-- what are the implications for society when now, anyone on the internet can download something like that and, resources permitting, just create their own threats? Digital privacy and tracking certainly in the news, and ever more so today when it comes to social networking sites and the implications for humans. AI and robotics are very much on the horizon. 

And indeed, Brian, will soon introduce a course on the same and what the implications are for users in society. GDPR and data privacy laws here and abroad are germane as well. And then Net Neutrality, which keeps coming up from time to time, particularly within the US, and what that means technologically, and what that means for users. 

And here, too, I'm going to cross my fingers and see if I gave the right permissions for this one. This one, too, is successful. So I got two out of three. Let me give you this sample assignments as well. 

And you'll notice the overlapping. So, in fact, allow me in closing, before I turn the reins over to Colton, just to give you a sense now of the similarities and differences here. We've looked at CS50B and L and T here in succession. And here is the same syllabi from each course, this time laid out from left to right in the order in which we saw it. 

And I did my best to color-code this to show you the similarities and differences. I realize the colors won't necessarily stand out well for your eyes or your screen. So we'll document this in another form, too. 

But essentially, I used the same colors in each course to indicate that there is significant overlap in those topics. So both B and L, for instance, in pink, spend a good amount of time on computational thinking, as they do on programming languages, as well as programming. So sometimes, the titles might differ, but the concepts are the same. 

And so ultimately, each of these three courses is available to be taught as OpenCourseWare, either as maybe a freshman class, a middle school class that introduces students to the world of computing and computer science, or, as with any of the classes, you can pick and choose things off the shelf and integrate them into your own class, be it CS50AP or something else. But generally speaking, these are more conceptually-oriented classes, more societally-oriented classes, and more introductory than something like CS50X or, really, CS50AP itself. Any questions or comments before we turn our attention to what students and teachers can do after these on ramps? 

AUDIENCE: I was just thinking that if there is a CS50 course for medicine, my students would love it. 

DAVID MALAN: So the one course we don't have, OK. But we've actually been thinking about that, if only because Harvard does have a Medical School. But it does not, I'm afraid, exist yet. Other questions or comments? No? Colton, would you like to take the floor? 

COLTON OGDEN: Sure thing, awesome. So thanks, David, for the introduction. I'm going to talk about CS50G, or GD50, as I like to call it-- Game Development 50. I'm going to switch my screen over here just to have a slightly better view of the slides, here. 

So GD50 is a continuation after CS50. So the expectation by this point will be that students do have some programming experience, be that through CS50 or through other equivalent courses. And GD50 or CS50's Intro to Game Development is all about 2D and 3D games. So we spend a good chunk of the course going through a lot of really famous titles that you probably see around the screen like Super Mario Brothers, Legend of Zelda, Angry Birds, Pokemon. But we also do a little bit of 3D game development at the very end in Unity Game Engine-- Dreadhalls, Portal, and a helicopter game in 3D being examples thereof. 

And this course uses a couple of different programming languages. And I think this is actually pretty important because in real-world industry, it's pretty common that between companies and even within the same project, you'll be expected to use-- and even within the same game project, for the sake of this course at least, you'll be expected to use not just one language, but multiple languages. So here, we have Lua and Love 2D. That's what that symbol is there on the left-hand side to represent the 2D section of the course. And on the right-hand side, we have C # and Unity, which represent the 3D side of the course. 

So we start things off with Pong. And this is a very quintessential, classic game. But this really is students'-- we can presume many, for them, their first dive into something as graphical as this. And it made sense to take things in a progression from really, really simple to more complicated. And pong is a very suitable first example as well because it's the grandfather progenitor of the video game industry. 

So the sake of this example, really, is to showcase very basic things like getting something visual on the screen to begin with, where students may only have thus far done textual CLI-based programming. We have text being rendered on the screen, but not through a command prompt. And we have various things like game state, so managing what we're doing, whether it's the beginning or the end of the game. And this is a very common theme in programming. And this is-- effectively, state machines are an important concept in computer science, generally speaking. 

We transition from that to something a little more visually interesting. So this is where we can start to have students actually use their own art or at least get a sense of how to do that and have it actually move around on the screen. So we cover things like delta time, which just means the difference between two frames in milliseconds, which allows us to then calculate things like gravity, which is a frame by frame calculation. 

After that, we go to breakout, which is a continuation of one and two-- rather, lectures 0 and 1-- Pong and Flappy Bird, where we've taken the basic idea of Pong, and we've taken the idea of adding in sprites. But we've also made the game a lot more complicated. 

And this I like to use is an example of what's called procedural generation. So we're doing things, not just necessarily putting graphics on the screen, but talking about algorithms that let us generate data or information to make games playable, one iteration after another, which I thought was an interesting thing. It's something that I'm personally attached to with games and with programming. 

And it makes things a little bit more, I think, rigorous. And ties it to something that's not, strictly speaking, necessary to games because you can do the same thing with a database. You could generate your own database information if you were testing something on the web, for example. 

We go into match 3, which is a discrete style-- not really a board game, but it's a discrete style game where you swap tiles and try to get matches. And this illustrates a different kind of programming, where you're looking at a finite space and trying to calculate whether a particular rule or condition is met, and then changing the game board, one iteration after another. So it's just kind of-- at least with this example, I liked it because it was a popular thing. 

Again, the whole idea or philosophy of the course is that it should be a case study approach to the course, where we have a full corpus of source code that you dive into. But it's also varied so that the students aren't necessarily getting the same type of game throughout the whole course. They're getting to sample the landscape, which was a major design philosophy of GD50. 

DAVID MALAN: Angela asked earlier, how many girls play these games? And does the course cover the work issues that face game designers? 

COLTON OGDEN: I imagine-- I haven't done the research to know the gender distribution. I believe I read stats on mobile games-- in particular, things like Candy Crush and many other types of games on mobile were very-- actually, I think more women played those than men, if I remember reading a study about that. I'm not entirely sure. I don't want to say anything incorrect as regards that. I feel like the games industry is a little bit more male-skewed. 

Although I think within the last five to 10 years, it seems like it has gotten a little bit more balanced. But there's still a bit of a discrepancy for sure. In terms of the workplace considerations, we don't really cover that as much. It's an interesting thing that would be maybe worth adding to the course, actually. But currently, no, we do not talk about that-- at least not in detail, as far as I recall during lecture, unless it was asked as a question. Sure. 

DAVID MALAN: And Colton, [? Amira ?] asked, is this course considered to be advanced? 

COLTON OGDEN: I would say it'd probably be intermediate level. It's hard for me to put a specific label on it. Certainly, it's more advanced than-- well, I didn't want to say it's more advanced than CS50 is because CS50's relatively advanced for an entry-level course. I would say it approaches the level of difficulty maybe as the later stages of CS50. 

In some regards, maybe slightly more difficult because we're dealing with larger code bases on average. Actually, most of the code bases in GD50 are upwards of 1,000 lines-- maybe 2,000 lines of code. And this was deliberately the case, because at least with the design philosophy that I had going in, I did not want-- or as I was learning game development, it was very hard for me to find large code bases like the complete picture of what a game is and how all the pieces worked together. 

I could very easily find tutorials online that would illustrate one concept, like how to move something on the screen or how to transition between two different scenes, maybe. But very rarely would I actually have a full code base that was representative of what an entire game might look like, or at least a proof of concept there that was relatively fleshed out. And you could easily add more content to it to make a proper, full game. 

So yeah, in that sense, students will be expected to navigate large code bases. And the assignments therefore are a little bit smaller than obviously implementing an entire code base. They're usually adding a small feature. For example, in Pong, the objective for the student is to just simply add an AI to the paddle on the right-hand side that lets it track the ball or have some behavior that the student wishes, whether it's to make it behave somewhat like a human or to be infallible, which is often the case. But, yeah, generally, that's the case-- large code bases to navigate, which might be a difference from CS50. But the assignment rigor in and of itself is probably comparable to mid to late CS50 in difficulty. 

DAVID MALAN: And Steve, to your point about it being too advanced for middle schoolers, it does assume, to be clear, as will Brian's classes, that students have taken CS50 itself or some equivalent. So it assumes that degree of comfort and sophistication out of the gate, to be clear. 

COLTON OGDEN: Indeed. 

DAVID MALAN: Colton, back to you. I think we caught up. 

COLTON OGDEN: Awesome. Thank you so much. So I was talking about Super Mario Brothers, which was the influence of the course from the very beginning. I probably mentioned all of that stuff. 

But the big thing that I wanted to hammer home was the idea of illusions-- how games in and of themselves usually are meant to trick us into thinking that we are in a particular place or doing a particular thing as a particular entity. In the case of Super Mario Brothers, in this case, at least we are typically rendering the entire thing at once. But typically with games, outside of the camera bounds, you will not have tiles being rendered to save on memory and to save on rendering-- for the GPU you to not have to render more texture or bits of textures. 

In the case of Flappy Bird, if you were to zoom way out of the example of Flappy Bird, you would see these long weird pipes, and then just a simple image that was infinitely scrolling to make us feel like we're actually moving through space. But in fact, we're not. And actually, the pipes are getting generated and shifted back and forth around the screen as needed to get the effect that we're looking for. So that was it for Super Mario Brothers. 

Now, let's go over to Legend of Zelda. So Zelda is a another game of that era where it was released for the NES. And it has a similar almost aesthetic of the era. But this gives you really a top down games. And the real purpose of this lecture, amongst a couple of little minor things that we talked about graphically, was that we wanted to discuss how we could model things like creatures as data. 

So we could have these things like these ghosts and these spiders and these slimes actually modeled in a config file, more or less. And we would just dynamically load them in, rather than have to write a lot of different logic or repeated logic or use a particular inheritance in the object-oriented sense, an inherited class, to model all of these individual creatures. So data-driven design is a big aspect of this lecture. And I want to believe that that applies to a lot of domains, just like a lot of these other concepts do, beyond the world of game development, like in web development, for example. 

We transition completely in a different direction here to Angry Birds or an Angry Birds style game using physics, 2D physics. Box 2D would be the name. And this was more to give students a taste of a different outlying genre and a different way of building games because building games with physics objects is very different than a lot of what we've covered earlier in the class. 

So this is, again, part of the idea of giving students just a wide taste of the landscape as befits game development. And here, they learn things like how to model different types of shapes and how they interact with each other. In this case, we have this little barricade here, represented by these wooden boxes. And then we have the characters themselves, with a model trajectory here, in which case they'll collide with that. 

Following that is our last 2D game, which is Pokemon, or a version thereof. Again, everything with this course is all public domain sprites by design because we don't want to infringe on anybody's copyright. But here, this is very similarly modeling off of Pokemon, which was a very famous game in the late '90s, where you capture these little creatures. And you can fight them back and forth. 

And this was to help with a few different things, particularly events and callback functions, which is a big aspect of asynchronous programming. And also higher order or functional programming, which was a different paradigm that students might not be super-subjected to until they've maybe taken CS50, because I believe with CS50, and at least JavaScript, there is a bit of that. But here, Lua, because it's a dynamic scripting language, it does have these features actually very similar in a lot of ways to JavaScript. So Lua gives us the option. We can both test not only turn-based combat systems and the idea of two entities taking turns and making decisions back and forth, but also a different way of thinking about programming, which I thought was important to illustrate. 

And then following that, we actually transition to Unity 3D. And this was by design because it was a nice way to get students to use a real-world toolkit. Not that Love 2D isn't real-world, but Unity in particular is not only a game engine, but also one of the most widely used game engines in the modern game development ecosystem. And by doing that, we let students actually use the tool that's highly in vogue and get real-world skills, not only just use things that are in a model or mock environment. And that's also, again, by design throughout the entire course to give them a larger code basis to work with. 

So here, we are creating just a simple helicopter game. It's actually almost like a 2D game in and of itself. But we have helicopters and planes and the like moving around. So we're using models. We're doing basically just a tutorial on how to use Unity for the most part and get our minds thinking in 3D and using models rather than using 2D and sprites. 

Following that, we do a first-person horror game. So this is Dreadhalls, which we actually played in the office on a VR headset, which was a great time. And here, we talk about first-person games. And this is very different, obviously, from anything that we've done in the course. 

Now we're actually doing or beginning to do something that's unique to the realm of 3D games. It's something that we couldn't-- unless we used faux 3D-- 2D-style implementations, something that we could not do in 2D that we can now do using Unity and 3D-- that idea of navigating a world, an actual world, and feeling like we're an actor or an agent in that space. And here, it's really just a horror game, and then to model that idea. 

But it's a big step. And we can talk about things like how to model a character moving around and interacting with things and colliding with things. And this is applicable to all kinds of different things. I even taught a seminar on-- a workshop on how to use a lot of these same ideas just to create a museum navigational tool, which illustrates just how powerful Unity is, even outside the world of game development. 

So if students want to maybe learn the principles here, they could take this idea and apply it to all sorts of domains. This doesn't have to necessarily strictly be creating games. It could be any type of multimedia. 

And then the final lecture of the course is a evolution of that last process, where we're actually implementing a first-person shooter, but not in the traditional sense of the term, but rather a clone of the game Portal, which involves a portal gun, which shoots just these portals on flat surfaces that you can then walk through and then jump out the other side. This was meant to involve the player in a little bit more of the technical aspects of using Unity-- things like rendering textures, casting rays from the point of view of the camera, and then finding what the nearest collidable surface is-- things that would allow students to not just simply create a thing to walk around, but that can actually interact in dynamic ways with the surfaces in their game world. And that's basically it in terms of the curriculum for the games course. 

Again, it's meant to be a case study approach, where the concepts and the ideas and the curriculum or the subjects therein are introduced in an organic way to make it feel like they're navigating the process of becoming a game developer, less so than they are maybe learning it in a traditional, more austere sense of the term. It was a philosophy that I personally wish existed when I was learning how to game program. And so I figured it would be a nice thing to try out. So yeah, that was it for the game syllabus. And I think Brian is next, but I'm happy to take any questions if anybody has any. 

SPEAKER: Some questions that came up in the chat, Colton-- Peter asks, "What development environments are used for the courses on CS50 IDE?" 

COLTON OGDEN: So currently, no, it's not in CS50 IDE. We expect the student, at least for the Love 2D section, and even for the C # and Unity section, to use a tool called VS Code, which is a very popular text editor which has actually integration with Love 2D, where you can just press Alt L or Command L, depending on whether you're using a Mac, to actually fire up Love with your current project loaded immediately. 

So you just very quickly test back and forth whether your code is working or not, which I personally really enjoy. And I use that almost exclusively. And Unity has its own built-in IDE, more or less, with at least all of the visual aspects of things, although it still defers ultimately to a text editor for you to write your code. But you can set it up to use anything you want to, whether that's VS Code or Sublime Text or the like-- even Text Edit, if you are so inclined. 

SPEAKER: And prior to that, also from Peter, "Love 2D has been updated. The distro in the course, this is an older version. [INAUDIBLE] update with the course plan? 

COLTON OGDEN: That is correct. Yeah, the current distro that we are using is for 0.10.2, which is mentioned in the assignment. Although we will be making an update to the upcoming semester that makes it compatible with 11.3, which is just a series of essentially copy and paste across all of the source code. 

SPEAKER: And Ty asked, "Are you planning to teach programming in Minecraft?" 

COLTON OGDEN: Programming in Minecraft? You know, that would be fun. I am personally a fan of Minecraft and all of the crazy things you can do in Minecraft. You can use-- you can do it the crazy way, which is where you actually build computers using redstone or using electricity or electrically modeled blocks. And that will take you a tremendously long time. 

Or you can do it through something like ComputerCraft or CC-- I forget what it's named these days. But it's essentially-- it actually does run, if I remember correctly, a Lua interpreter in one of the blocks in Minecraft that is actually a computer. That lets you interact with things in the game. So it actually is an excellent way, I think, if you have the right environment and the right exercises, for a student to learn. Haven't thought about using it for CS50, but maybe it's something to think about. 

DAVID MALAN: And Joanna, in answer to your question about using Scratch for games, it's not something that we use in the games class. It's something that can certainly be used in the technology class, for instance, or CS50 itself. 

And then Angela, your question, "Is there a discussion about the violence and illustration of women in games?" Not something that's covered in this class, which takes a purely technical approach to it. But those would be the kinds of materials that we're working toward building out for more discussion-oriented classes, as teachers might use it in high schools or college classrooms. 

COLTON OGDEN: Yeah, good point. And yeah, the course does not have any of those topics. Also, I included all the games that are very family-friendly. 

DAVID MALAN: All right, Brian, should we turn the reins over to you? 

BRIAN YU: All right, thanks, Colton. So the final two classes that we'll be talking about-- one is about web programming, and one is about artificial intelligence. Both of these classes are designed to be taken after students already have the prior experience from CS50 itself. 

These classes build on top of CS50 and explore a little bit further what you can do with programming and what you can do with computer science. So just a whirlwind tour of these classes. First up-- and it looks like we'll probably go a couple minutes past 2 o'clock Eastern, if that's all right. But we'll try not to go too far over that time. 

But as for the web programming class, the topics that we cover, we start by introducing HTML and CSS in much the same way that CS50 itself does, but also introducing some of the more recent features of HTML with regards to video and with regards to handling large amounts of data, just to make the process of building websites a little bit easier. After that, we turn our attention to Git, which we've mentioned a couple of times now throughout the workshop. Just a version control tool popular across all of programming, but web programming especially, just for keeping track of changes you might make to a web application over time-- how to do that effectively and how to be able to manage different parts of the program at the same time. 

After that, we introduce students to Python in particular, taking a look at the Python data structures that you can use in order to represent information in programming, taking a look at things like lists and dictionaries and sets and how you can write functions to manipulate these data structures. And then, in particular, in the next part of the class, we introduce a programming framework called django. So if you've taken CS50, you might be familiar with Flask, which is a web framework. 

Django is a very similar framework, but has-- it's a little more full-fledged, has more features to it, especially when it comes to building web applications that deal with storing large amounts of data. So when you're dealing with applications that have lots of users that have accounts, where those accounts are storing information, django makes it very easy just to set up a web application so that you can focus on the interesting parts of building the web application without worrying too much about the underlying details and implementations there. No relation to the movie in the name of this framework. 

After that, we take a look in particular at SQL and how you can use SQL to be able to build a database that works with your web application. And here, we talk about the various different parts that a web application might have-- the front end that the user sees, some of the more controller code that operates how the web application really works, and then a database that web application might be connected to. And we explore some of the tools and ways that you can have web applications that interact with those databases. 

Following that, we introduce the second of the programming languages that are covered in the course-- JavaScript. In particular, using JavaScript to build user interfaces-- so using JavaScript on the client side. In other words, running inside the user's browser, whether that's Chrome or Safari or Firefox, to be able to make web applications a little bit more interactive so that things happen when a user clicks somewhere. So that when a user gets a new message, for example, they might see a notification window pop up, talking about some animations. Things like infinite scroll-- if you're scrolling through Twitter or your news feed, you'll often see new data appear as you continue to scroll. We talk about some of those implementation details and how some of the modern web works. 

And then after that, we go into some best practices for building web applications-- things like testing and CICD, Continuous Integration and Continuous Delivery, which are ways of allowing it such that when you're building your website piece by piece, your web application doesn't need to just update once a month or once a year. But you can continually update your web application so that every time you make small, little changes, your web application can update for all of your users as well. 

And then finally, we talk about what might happen as your web application starts to grow. Talking about issues of scalability and security, thinking about when your web application gets too big for just one web server to be able to handle all the users. How might you scale that up to have multiple servers and balance between those? And what are the security implications of doing that sort of thing and security ideas that you have to be mindful of? 

This is a very project-driven class. So throughout the class, there are various different web applications that students create. So they start by re-implementing something like Google-- just a search engine where people can type in something and see a whole bunch of search results. And each of the course projects in this class is modeled after a popular web application that students might have seen or interacted with before so that they get an opportunity to try and better understand how the web applications they interact with really work. 

So next up, they build a wiki, sort of like Wikipedia, where users can edit new pages, create new pages, and search for various different wiki pages that might be on the internet. After that, they build an e-commerce website, sort of like an Amazon or an eBay, where students can build a website where users can log in, put up items for auction, and bid on those listings. And then the highest bidder wins at the end of the auction period. 

Then they implement a variant of Gmail, where they effectively build a mail client where you can have an inbox of all your email messages. And then you can send emails and receive emails as well, before finally building a social network, effectively like Twitter or Facebook or something like that, where users can make posts and comment on those posts and heart other posts, for example, just to get a sense for the various different types of web applications that are out there and the types of things that you can do with those web applications. And then at the end of the course, we have students build a final project of their own choosing, where they just pick some web application they would like to create. And we give them the tools and the resources to go and create that application, at a database to it, add a front end to it, and try to make it a little bit more interactive. 

So that, then, is a brief tour of the web application course. The question is, how long is each of the courses? Generally speaking, the courses are designed at Harvard to take a semester-- so something like 12 weeks' worth of time. But certainly, they can be adapted to work at other paces. So often, even though CS50 and the web programming class and the AI class are all designed to take a semester here at Harvard, I know that oftentimes for CS50 in particular, you might stretch that out to cover one year or even two years, potentially. And so that can make things a little bit more manageable-- the pacing is a little more easily. 

Are tools like submit50 used in these courses? Yes, you can use submit50 with these courses as well for submitting work and collecting that work. Where are the databases and the website hosted? Ultimately, there are multiple possibilities, though the popular one that we recommend is a service called Heroku, which just happens to be one of the easier services to set up. You can set it up for free, just to take a web application and a database and put that online. 

But there are other options available, and we talk about some of those in the web programming class, too. We don't talk about Firebase, though we do talk about other libraries. In particular, this version of the class talks a little bit about React for front-end development and for designing interactive user interfaces as well. 

All right, and with the last few minutes, I'll just go ahead and talk about CS50's Artificial Intelligence with Python, CS50AI, another course that's designed to be taken after CS50. And the important thing that I'd like to mention here is that while most artificial intelligence courses, if you find them online, require a fair amount of mathematical sophistication and background-- require knowledge of calculus, require knowledge of linear algebra, which is involved in a lot of artificial intelligence. We made the intentional decision in this class to create an introductory artificial intelligence class that doesn't require that mathematical background. 

So there's no need to know calculus or linear algebra to be able to go through the curriculum in this class. The prerequisite really is prior experience programming in Python, which is assumed for the class. But we introduce the mathematical details. 

There is some math we talk about. We talk a little bit about formal logic. We talk a little bit about probability and statistics. But we introduce those ideas in the class, and we don't assume any higher level math that other artificial intelligence classes you might see do. 

So the topics we talk about are, first, how to search for answers to problems. How does AI do that? How does it look for how to win in a game, for example, considering all the possibilities in that game? 

Then we turn our attention to the question of how it is that artificial intelligence can represent knowledge. How can AI store information? And how can artificial intelligence use that information to draw new conclusions? 

So we talk about things that AI can be certain about. But we also talk about things that AI can be uncertain about. If artificial intelligence might know something with some probability, but not be entirely sure, how does it deal with uncertain events and trying to deal with that? 

We then turn our attention to optimization. So if there are many possible ways to solve a problem, how can our AI find the best solution? If there are many possible ways to-- this is useful for things like if you're planning a city, for example-- trying to plan where the hospitals should be. How do you optimally place the hospitals, so they're in a useful and practical location? These are the sorts of problems that we try to take a look at. 

And then in the latter half of the class, we turn our attention to machine learning. So we talk about machine learning, what it is. What are the different types of machine learning, the different types of problems you can solve using machine learning? And in particular, talking about the sorts of tools that are often used in machine learning, in particular focusing on things like neural networks, a very popular model in machine learning where you try and design an AI system that's modeled on the way the human brain works, with these neurons that are interconnected and connect to each other in order to try to draw conclusions. 

And then finally in the class, we turn our attention to natural language, thinking about how do we get artificial intelligence to speak the language of humans? To be able to understand our language? To be able to respond to our questions? And how things like Siri and Alexa and other voice assistants on your phone or on your computers might work. 

In the process, we introduce students to a number of tools. Of course, the Python programming language, which we use for the entirety of the course. But also, introduce them to some common Python libraries that are used for things like machine learning, such as scikit-learn, a popular Python library for machine learning, as well as TensorFlow, a popular library for building neural networks. 

And the advantage of this is that students get an opportunity to build their own neural networks without needing to implement all of the math behind the neural network. That normally, to build a neural network, there is a lot of linear algebra and optimization involved. And here, students can really just focus on the problem that they're trying to solve, without having to get too deep into the mathematical details that are underlying it. 

So just to give a taste for some of the projects that students complete, they start by building a game engine. We have them build a tic-tac-toe player so that they can play against the tic-tac-toe player. And ideally, they should be able to build a tic-tac-toe program that never loses. It should either win, or it should be a draw. But the tic-tac-toe player should never lose. 

We then introduce some logic-based thinking, trying to build an AI that can play a game like Minesweeper to try and logic their way through where the mines might be and which cells might be safe, if you're familiar with that game. Then we have the AI do some things that are more creative-- have students build AIs that write a crossword puzzle, for example, to be able to fill in words into the appropriate places and to try to do so effectively. And then when we turn things to machine learning, things get even more interesting. 

And we have students think about self-driving cars and the implications of those and what might go wrong. In particular, asking students to build just a small part of self-driving car software-- building software that can look at a street sign and identify what kind of sign it is based on the street sign. So learning to look at an image and try and learn from that image to figure out what that image might be. 

So that was just a whirlwind tour of what's covered in the artificial intelligence curriculum. But in short, we use Python throughout the entirety of the course to try and build these artificial intelligence systems. With all of the projects, we give students a fair amount of distribution code. 

So they're not building the entirety of the project from scratch, which might be quite a lot. But usually, we give them the framework and the structure, where students are then adding in the functionality and the capabilities into the program to make the program a little bit more intelligent. So I'll pause now, if there are any questions about the web programming class, the artificial intelligence class, or really, any of the classes, now, as we get ready to wrap up this session. 

DAVID MALAN: Brian, Bret asks, "I understand the AI program is intended to occur after CS50X, but would it be possible for students to go through the topics without that background?" 

BRIAN YU: Potentially, yes. So the projects all require Python and will expect that students are writing programs in Python but the lecture is material is all designed such that you don't necessarily even need to know how to program to be able to watch the lectures and just get an understanding for how it is that this AI works. So I could see multiple different approaches, here. 

You could use the curriculum as just a way of introducing the principles of artificial intelligence-- what machine learning is, how some of these artificial intelligence things that you encounter in the real world might work, without having students actually get into implementing the AI for themselves. But for students who are a little bit more advanced, who might have a bit more programming experience, we do have these projects available just to allow students the opportunity to create AI of their own, if they would like to. 

DAVID MALAN: And Glen, ask-- he has a similar question. "Is it possible to run one of those classes-- web AI, game dev-- as a quick intro, and then maybe cover fewer projects to make up the difference?" 

BRIAN YU: Yeah, absolutely for both-- for, actually, all of the follow-on courses, really, they're very much divided into different topics, such that it is possible to pick and choose certain topics that you'd like to talk about without using the entirety of the curriculum. So certainly, all of the curriculum is available as OpenCourseWare. But you can pick and choose what you like and adapt the course in the curriculum for your own liking as well. 

DAVID MALAN: And John asks, "Any words about CS50M?" which is a mobile app development course that a colleague of ours taught a couple of years back. We're probably not planning to bring that back too soon. That material, more so than any of the classes, has drifted out of date the fastest by nature of the tech industry evolving so quickly. 

There's also more challenging issues of access to hardware for that class for students, or requiring that certain software be installed, which is not necessarily within the grasp of teachers with system administrators and schools. So it's probably not coming back too soon. But we have not ruled it out entirely. 

Gloria asks, "Are there any promotional materials that show sequences and course descriptions?" We do have introductory videos for each of the classes. We will share those out via email, if we may. They're also on all of the OpenCourseWare sites. So I'll probably send over those URLs as well. 

All right, well, I think we're indeed running a bit late. My apologies. But coming up next in just under an hour will be our final session all together-- Teachers Teaching CS50, with Margaret, with Jenny, and Douglas, all teachers themselves, moderated by Jason. And we'll use that time for Q&A as well for some final connections and closure. And then we'll be sure to stay in touch in the days to come. 

So why don't we go ahead and officially adjourn here? Please feel free to stick around. We'll turn on some music if you'd like to ask us questions or chat with each other. But we'll resume at 3:00 PM Eastern. Thank you to Colton and Brian.