I won't say I'm not a little intimidated about the software, but if other non-programmer/non-video game people have been able to teach it, so can I.
The question remains, though, what will you teach?
Please understand, we want to help.
Several people in this discussion, including one who happens to be a full-time professor at a major university teaching game design and game project management, have come back to the very important issue of curriculum in the thread. (I'll leave you to figure out who it is that's the teacher.) Several contributors in the thread have written books used in college courses. So please, the distinction about what exactly you are trying to teach is very important.
We want to help, but it seems communication is difficult.
However, I would question your understanding of education and pedagogy. I don't understand where your negative attitude about my approach is coming from.
Much of it comes from the terms you are using. Imagine a budding photographer coming up to you and describing how he dislikes the bokeh of a photo and showing it you see no depth-of-field effects at all. The student continues to state just how badly the bokeh bothers them, but looking at the photo again and again you see no bokeh effect at all. You may question for the student to point exactly what he means by bokeh, only to have the student indicate the purple banding of chromatic aberrations. Similarly with other words, perhaps confusing tone and value, or confusing subject and composition.
The words you are saying are valid in their own right, but you seem to have interchanged several of them in ways that are nonsensical to those in the field.
You say with words you want one thing, but you describe with links that you want something different.
Many schools and teachers say "game design" when they mean "game programming", or "level design". Many who teach "game design" instead teach an introduction on how to use the tools but never actually reach discussion on design itself.
Game development is a broad collection of everything related to games. Programming, art, animation, UI, UX, game design, level design, audio, QA, marketing, production, management, and many other enormous topics fall here. If it is related to developing games, it falls under the industry-wide game development umbrella.
Game design is a broad field, but has very little to do with programming games, viewing games on a screen, or actually building games. Game design studies topics like balance, making not perfectly-balanced games but perfectly-imbalanced games where everything has strengths and weaknesses to each other. Topics like analyzing the psychology of fun, what makes something fun and why, or how to trigger and build emotions in players. Topics like how to build numeric systems with interplay between each other, much like the Dungeons and Dragons manuals, with the interplay between monster families and world items and weapons and character traits.
Level design and world design are a subset of game design focusing on the environments of the games. These have an enormous impact on the game. Horror games with their tightly confined spaces; shooter games with levels of carefully designed obstacle courses allowing for sniper holes that are never fully protected, choke points, open fields of death that must be crossed yet can be strategically defended; playground games with vivid colors, yet balanced so important items are clearly visible among the bright and beautiful world. Platform games that slowly teach you how the world works and gradually moves from a simple platform and simple pit into later levels that require dexterity and skill to cross. Puzzle levels and worlds that need to be solvable by all players from all backgrounds around the globe, tricky enough to present a thought-provoking challenge, but not so difficult as to stump anyone from any culture at any age in your demographic.
Game programming relies on the tools like GameSalad and Unity mentioned above. It is the source code, the math functions, the computer code that ties everything up. As you wrote that you have an art background this seems the least likely thing for you to be teaching, yet it was the first thing in the conversation about what you wanted to teach.
Game art comes in many flavors. UI art is typically 2D and Photoshop is the current dominant program. Concept art is often 2D, again with Photoshop high on the chart but with several other artistic programs being popular in sub-groups, such as Manga Studio for concept art in its style. 3D models have many tools available, Maya and ZBrush are quite common with 3D Studio having a heavy following, and Blender showing up from time to time thanks to its cost.
Game animation is an art discipline but often treated separate from the other arts above. 3D animation tools have an overlap with some art tools, Maya and 3D Studio being quite common. 2D animation tools are the drawing tools rather than rig manipulation, but as an art teacher you probably get that.
Game tools, game engines, and game content pipelines are the tools, software, and other machinations forming the hoops to jump through to turn a collection of images, scripts, code, sound clips, and other materials into a full-fledged game.
All of these can be taught, but each are enormous disciplines on their own.
So the question remains... What are you trying to teach?
You posted several links to student-built projects built with Flash, GameStar, GameSalad, and other tools. Those tools are not focused on game design, but are instead focused first on game programming and secondarily on basic level design.
You posted links to the top game engines, Unreal, Unity, CryEngine, etc. While these tools have some of the games pipeline as it relates to art, getting art assets like models and animations into a world, or building levels using their tools, they are primarily the realm of programming, and secondarily world design, and only marginally game design as the interactions and numbers created by designers are tweaked and twiddled.
Perhaps the most powerful tool available to game designers are the text editor and the spreadsheet.
You are not the first, nor will you be the last, to miss that.
Pure game design can probably best be taught by immersing the students in Dungeons and Dragons, card games like Magic the Gathering and Yu Gi Oh, and video clips and level maps from hundreds of games.
Though the students may learn much about designing a game, they are unlikely to come out of the class feeling unfulfilled by not having developed a game.
Your posts seem to indicate that as well. While you state you want to teach game design, you indicate differently that you want to teach a shallow introduction to game development across most disciplines.
Since you linked to successfully completed games by student, a broad game development across all disciplines, my hunch is that game design is probably the smallest aspect of the course that you will teach that age group. You will probably start with the basics of the tools you will use, then start with the content pipeline for getting art and animation in the game, quickly build up some simple levels. Then off to programming to give them the ability to bind the pieces into something useful. Then will be iteration on all of those, the content pipeline, tool usage, and programming, until they are able to actually construct something that holds their interest. Only after those skills have been developed are you likely to actually get into the barest fundamentals of design, of the psychology of play, of the understanding of emotion and fun, of balance and imbalance, of building precept upon precept, on crafting designs that can be reused, on building a small number of carefully crafted parts that are easily understood and enable depth of play.