I took a game design course in University not too long ago so maybe my experience from the student side will help you.
We used a book called "Understanding Video Games," though the prof disagreed with some things in the book, it did have some good info in it. For developing we used Game Maker Studio; you can get it on steam for free but not by searching, you need the direct install link. My prof gave us this link to
the steamdb page for GameMaker Studio and I verified by searching it manually that this link is not hidden or anything so it should be good. You can just click the install button and it will install through steam. There are a lot of tutorials and help resources online for making games in GameMaker through the drag-and-drop functions, and if you have a background in C or a C-based language learning GameMaker's scripting language GML isn't too difficult (and the api doc for it is pretty good).
In terms of lecture material we started with some real general questions of "what is a game?" and "what is play?" with some great group discussions on this topic where everyone was encouraged to share their views of what makes a game. He led the class with some great questions and interjections like "You said that a game is a challenge you must overcome, so would you consider school a game?" You know, interesting things like that which really helped us question whether it is even possible to define a game. This was all to build into our midterm project which was a researched essay on what is a game where we had to use a theory he taught us in class as a starting point. If I recall mine started from Huizinga's Magic Circle and built into my own general explanation of what is a game. There are quite a lot of thoughts on this topics, and I recommend taking some time just to see what other people think is the definition of a game.
We followed the theory lesson with mechanics, game elements, and aesthetics which taught us how to think about our games and also to teach us that games are a "co-authored experience." Meaning that what the designer creates is not the game as it is experienced by the player; both bring something to the experience, and the interplay between these is how the game is experienced. We used the MDA framework to examine this. In terms of aesthetics I guess the big point was somewhere along the lines of "ceci n'est pas une pipe" and whatnot. I'm a little fuzzy on the details now.
A really important set of lectures was on the development process, most specifically that you should use an Agile process. Iteration is key. The developers and designers should always be implementing stuff and then testing it to see if it works. Whatever you start off with in your head is not going to be the final product in code. Somewhere along the lines you will realize something isn't fun to play and change it, or find a really fun feature and expand it beyond what you originally imagined. Though you should be sure to teach them about scope creep!
There was a lecture on designing tutorials, and I'm pretty sure he showed us an Extra Credits episode for that one. So Mark Brown will actually come in handy here. I'd say he did this because it was easier to show a good tutorial than tell us about one. Which, side bar, is another good lesson: play don't show, and show don't tell. If possible, it is always preferable for the player to play through the story. "I shot that guy" is better than "Trevor shot that guy" which is far superior to "I heard that Trevor shot that guy." I don't really have a good place to put this, but we also did a short UI and UX lesson where we looked at good and bad UIs, and also talked about Fitts's Law which is helpful to know.
Other than that, looking at my syllabus for it, it seems we had a couple lectures with more of an arts focus because it was an arts course. This was topics like the culture of games, controversies about video games, games as art, etc. He ended the course with a conversation about the industry, but that was more him sharing his experience with us and would be hard to replicate authentically.
What I couldn't find in the syllabus but remember was important was the concept of pillars. Your game should have design pillars that define the game you are making. They can also be used to gauge whether a new feature will fit the game. His example was Sleeping Dogs. One major design pillar was that actions should be possible no matter the context, so if you can kick, you should be able to kick whether you are on a boat, or in a car, or wherever. There are also Anti-Pillars which are the "this game is definitely not" concepts. So my own example for this would be in Mario they most likely have "heavy story focus" as an Anti-Pillar, meaning that when you stomp on a goomba he isn't going to tell you his life story. It's just not what the game is about.
Fortunately for us, our prof was actually ex-EA so you could tell when he said something off-handed about development and design that it was based on a real story.
I'd suggest if you really want to do this right for your students you should seriously take some time before school starts to take a deep dive into game design. Watching the occasional Game Maker's Toolkit is great for scratching the surface, but to be able to competently teach this I strongly feel that you should have as deep of an understanding of the topic as you possibly can.
Sorry for the long, rambling response. Hopefully something in my memories of my course can help you figure out what you want to do with your class.
