Setting up game programming class, JS question

I am in the process of setting up a 16 week college course introducing game programming. Here are the expectations:

1. No pre-requisites

2. The students will learn JavaScript, in the context of game development

3. The class has to be as non-intimidating as possible, as an attempt to attract and keep students who aren't sure about programming.

I have been brainstorming for a while now, and I am having trouble making these expectations compatible with each other. It is hard enough to illustrate the concepts behind game programming to one with no prior programming experience in a single semester, let alone make it a welcoming game-building experience.

A thought I had was to use Construct 2 events at the beginning of the class, concurrently teaching basic programming language constructs (variables, control structures, etc) in JavaScript. Then halfway through, I would transition to using JavaScript in Construct 2.

Of course, the problem is that I fear that Construct 2 may not support such a seamless transition. I know that Stencyl allows the developer to switch from the visual scripting view to code view on the fly, even permitting the developer to hypothetically write the whole game in HaXe (similar to JS). It would be awesome if Construct 2 had something comparable, something like a code view that eliminates as much peripheral boilerplate code as possible, leaving only an intuitive JS-syntax event, conditions, and actions sandbox. A best compromise could work.

Any suggestions?

What I would do is use Construct 2 to demonstrate game concepts and refer to the events as a means to introduce people to the thought process behind those concepts.

Each event requires some understanding/expectation that leads somewhere.

The javascript, I would focus mainly on, with the understanding of what was demonstrated a motivating factor. If people will potentially have no programming experience, I would focus on the programming. I wouldn't mix the two unless you can show specifically how one affects the other- which is easier with basic programming concepts like for loops, functions, etc. Making them understand why something works the way it does is more important in the beginning than knowing all the creative things they can do with it.

Prominent

Hmm... that's an interesting idea; I hadn't thought of that.

The advantages there would be 1. the students could make more ambitious and interesting projects (and most likely more entertaining for them); 2. the JS and programming syntax they'd be learning would not be confused with proprietary engine code. This means that their JS and programming knowledge could be more portable for other contexts.

My concern with this though is that the students are not technically doing any game programming in a Game Programming course. That might make it harder to get the idea past advisory committees, as well as easily disappointing a number of students I'd expect to be coming in with a few CS classes under their belt, looking to do "true" game programming. I would want to think of a way to address that (if you know programming, you are free to use the SDK? Nah, that could get hairy, quick).

I have never really heard of "Game programming." I've heard people program games, but not "game programming." You can't really program a game without learning to program. With Construct 2 you create games using its event system, which shares some resemblance to certain programming concepts, but it isn't true programming from the user's point of view. That's why I suggest using it for demonstrating game concepts, how certain events in a cycle over time produce certain things like a moving object, etc. And then focus more on actually writing code that you'd expect to find in those situations.

That's how I'd do it, but you might be a bit constrained if you're expected to teach "game programming." Because I'm not sure how a person is suppose to learn that without learning to program.

CannedEssence uhmmmmm....speaking from a parent who has 3 kids and have tried different methods and is still currently trying to get them to understand game development i would not focus on the programming part because most of them won't get it, but more on the game art, graphics, game play, game design, level and the last thing would be coding because is all about making the game, and there is so much more that gets done before doing the game that a lot of people don't teach that and just jump straight into the core of game development which will only get the interest of a few and not fit the many who might be talent at art, or game design etc.