Uhm... I worry about the direction and priorities a course like this would take. If you're trying to teach game design, then the right course of action is to have kids design games. I think there's a bit of a misconception between your idea of what game design means and what we in the industry call game design. So, I'll try to define it briefly and we can start working from the same understanding of the term:
Game design is the process of planning out the game rules and mechanics of how a game is played. (others here can feel free to agree/disagree/amend)
This is not to be confused with the production of the game assets, such as modelling characters or drawing artwork, which I suspect may be how you define it.
A game designer will often do what's called "grey boxing", where they spend zero effort making art. Everything is just a gray rectangle. The rules of the game are put into place, and then the game is played to see if it is actually fun. The game "fun" should stand on the merits of its design, not on the quality of its artwork. The risk is that you'd put in a lot of unnecessary time and effort into creating something that sucks because the concept doesn't work. (ie, let's make a game where you squirt mustard at a wall and then spend 5 days designing the mustard bottle and splatter effects.)
I'll tell you a short story of a game I designed and built half way. About two years back, I decided I would build a game about wizards leading massive armies on a battlefield and casting spells in conjunction with commanding the units. Think, total war meets magic the gathering. I wrote up a 30 page game design document which detailed many of the game systems and the rules which governed them. Even at 30 pages, it seemed like it wasn't even close to detailed enough. I played through my game in my head over and over, trying to imagine how each system should work. Once I had everything written down to a 'good enough' level, I started programming the game to satisfy the design I had come up with. This is wrong. I thought the fastest way to test my design would be to quickly whip up a grey boxed prototype of the game. It wouldn't take more than a week to implement. It actually took 2-3 months of full time work. It was going too slow. And I just wanted to test whether the rules worked and were fun. It then occurred to me that there was a faster and easier way to test my game and iterate on the design: I should make a physical simulation of the game by using scraps of paper and coloring crayons. I created a battlefield on a table top, invented some spells of various types, and started playing the game as spelled out in my game design doc. The problem is, the design doc is 30 pages long and I needed another player to play with me, and I couldn't ask them to read 30 pages of rules. So, I had to write an abridged version of the rules and explain it to the other player. Then we started playing the game by taking turns and moving scraps of paper around. The game was meant to be a real time strategy game, so we tried our best to simulate real time by making the turns very short when the combat action got intense. It kind of worked. It took about 30 minutes to play through a battle, and 4-6 hours to play through a campaign. I learned that some of my mechanics were broken, too over powered, or too under powered. Some of my rules just didn't get the desired effect I was aiming for. So, I changed them by changing one or two sentences in the rulebook. 30 seconds, done. Guess how much work that would take to implement if I was writing code? 30 minutes to several hours. This is the right way to design a game. You want to avoid wasting time by iterating quickly to find what doesn't work. If you spend 30-90 minutes writing code each time a rule changes, you're gonna take forever to design a game.
So, if I was in your position as a teacher trying to teach game design, I would forget about the digital side all together and focus on the design of the rule set. The technical stuff just gets in the way. I used to invent games and play them in my sandbox with my brother during the summer and all we needed were sticks, sand and our imaginations. It worked and it was fun, though tedious. Teach your kids the theory of game design, let them invent some games, then let them play those games with each other, figure out what works and what doesn't work, iterate on the rule set, and keep trying. Some of them will make games which turn out to not be fun at all, and that's okay! They thought it would be, but it wasn't. Learning just happened. Now they can try again and invent a different game. The whole time, they're not just learning game design, but also learning the process of game design. I would expect that this would take several months of school time (considering you may have an hour a day at most). If this is truly a class focused on design, then any time spent doing digital stuff would be kind of a waste of time (in my humble opinion). And if you have to make a convincing argument to justify the artistic merit of this whole thing, it is all inherently a very creative process with tangible results! You may not have something visual to look at like a painting, but you do have a designed game system which used much of the same processes other forms of art take. How you would grade this stuff... participation? Personally, this is tough to measure by any metric. Instead of using grades as an incentive for performance, I'd put together a competition where students can win prizes for designing a game which is the best in a specific category (oh hey, that's a game itself!).
I'm assuming you haven't read any of my past posts based on what you are saying.
Game Design will be a unit of study where students will learn principles of design. It will be an introduction. The other subjects- history, character design and game development, will be covered separately and also be introductions.
