stemkoski You're welcome. These are early students, typically late freshman and sophomores. Since the class is available as a general elective I also get the occasional non game student from another field who has some interest in games or game-like activities. The vast majority of people are design or art oriented meaning that most have little to no programming skills. I will also get a small handful of engineering students who are just barely getting comfortable with a language. The designers and engineers usually move pretty quickly into GML because they tend to be self driven in terms of figuring things out.

I do a lot of forcing people to slow down and incubate, document, and prototype which often drives the ego's of the engineering people crazy at first. But they find it saves their sanity by the end of the course when they're in big teams. Every now and then I get someone taking it as a late junior or senior and they usually comment that they wish they had taken it earlier. Most junior/senior classes are in Unity3D or pure code and some don't pick up the process habits I teach in those classes.

I teach a Game Dev I class at DePaul and thought I'd share some of the format of that class in hopes that it might be of use to you. The class is taught using Game Maker Studio. That's what the school is invested in, so it's what I'm currently teaching but I use bits and pieces of this when I visit highschool and some local youth groups to do workshops. I believe everything I do is applicable to Construct 2 and at some point will be using it for smaller/more condensed workshops and game jams.

It's a game design class and an engine learning class. My focus is on game design so I spend a lot of time with processes and design patterns. This is a 3 hour, 10 week class (11 if you include finals) with usually about 30 students meeting twice a week for 1.5 hours and goes something like this.

Week 1

Introductions and identity

Introduction to engine basics (sprites, objects, events, actions)

Assignments - Create a splash screen to represent who you are. Using graph paper design the layout for a break out game. Create said game, include room switch from splash screen, ball, paddle, static targets, one moving target, one toylike interaction. (don't worry about scoring and what not, we're just worried about getting stuff into engine and getting it interacting in one room)

Week 2

Review Break out games. Delve deeper into sprites creation and working with them. Look at Shoot-em-up games with a historical review of shooters from space war to geometry wars. Deconstruct what's interesting about shooters. Delve deeper into creating behaviors with objects and creating game control objects that manage the flow of play.

Assignments: Come up with an idea for a shooter. Write a one page treatment about it. Define the core play of this shooter, sketch out out the objects you think are needed and a sample level for your shooter.

Week 3

Look at shooter designs. Break into pairs and do design interviews. One person interviews the other about the game and takes notes on post-its, placing post-it's on large easel graph paper. One post it per event, interaction, object. Once done you have beginnings of asset lists and user stories. Switch roles. By end of session each student should have a collection of post-its to use as the foundation of their game.

Assignment: Make one room of the game that shows core play in action. This is an ugly prototype.

Week 4:

Review prototypes. Get feed-back on how to make it work smoother. Discuss level design and verbs. The use of space outside of visible room, player feedback, the importance of sound, facilitating the player, timers and timing and timelines. variables and scope.

Assignment: Finish game with 3 rooms/levels, splash screen, opt in entry point, win/lose screens that allow for opt in or quit. Every room needs to have one new opponent that behaves differently and that behavior is visible to the player. Some sort of scoring that is understandable to the player and visible.

Week 5:

Review games. Discuss planning and documentation. Present planning document template.

Assignment: Each student conceives of a game they'd like to make. Plan out the game. This involves writing out any story notes, make asset lists for sprites, sounds, behaviors, etc. The game must have some sort of smart opponent. Create level design for individual levels. Build one level ugly prototype of this game. Create power point pitch for the game that shows off art target, look and feel, and scope of play. (This assignment is two weeks long).

Week 6:

Discuss rudimentary AI behaviors, discuss scripting and the math of building some behaviors that test for player distance, direction, and state. Talk about basic state machines. Talk about the needs of platformers.

Weeks 7:

Present pitches. Class votes on pitches electing 5 that will be taken to polish. Class breaks into teams that will work on these games to polish with game designer as lead. Discuss agile development methodologies, sprints, scrum, deliveries.

Assignment: Using Trello, create user stories, prioritize them, and break them into 3 sprints (First playable, Feature complete, Polish and ship). Every week here after students must come in with a fully functioning build (executable). Running from engine can lead to failure of that milestone.

Week 8

First Playable Due: Present and lab work.

Week 9

Present and report. Show build and work in lab. Testing

Week 10

Feature Complete Due. Present, check-in and get OK move to polish and ship (I'm the client and they have to respond to my feedback). Make user stories for all known bugs.

Finals Week:

Present final game

There is a lot of room for variation in here and I change it a little every class (for instance sometimes I make that first planning document be a reverse engineering of an existing game and then they can do one of their own). If the class is heavy on engineers I push a little harder. If the class is heavy on artists I push a little harder on look and feel. If the class is designer heavy I push harder on creating polished play that allows for emergence and visible feedback and facilitation.

Since Construct 2 has so many behaviors built in to work with I think you can push more on making those interesting and polished. Also don't forget to push sound as feedback tool and a way to immerse your player. Games that neglect to include sound design will often lose 1 or 2 letter grades.

I hope this is useful.