What a great idea!
This is just my own person view on this:
I would say - if possible - develop part of your application which can start off with the basic bare-bones of procedural
programming, with video game syntax. Use an easy to use script (Python?) and give then the general feel about
what a program is, what a variable is, how video games are made in industry (i.e why they use C++ and scripting
languages like Lua).
A basic introduction program might be (C example):
#include <stdio.h>
#include <stdlib.h>
int main(int args, char *argv[])
{
puts("Welcome to game programming 101 - " G A M E O V E R");
return EXIT_SUCCESS;
}
Obviously C is a difficult example to understand from a beginner, but you get the idea.
When you have created all that, I would suggest slowly introducing OOP into the projects.
One good way to do this, is using whatever script your using - explain what "real world" object
the user is talking to using the script. Then, when you develop your OOP part of it - (e.g.: Java)
They will know off hand "Oh yes this is an object - this is how it is broken down".
I really like the idea of using structure-like methods to bind together pieces of code that have the
"look and feel" of an object too.
typedef struct
{
char player[100];
short int hp;
short int xp;
short float levelGain;
} ClientTalker;
Some closing thoughts:
1. Are you going to explain the possible pitfalls of using global and public objects and namespaces in programming?
2. A good point might be to explain the difference between a managed OOP language and a manual OOP language (C++)
3. Are you going to (or ever) introduce pointers?
4. Perhaps using a "visual" template for each project when moving into OOP game design (Java Swing?) might be a fun way to go.
Great idea, and I hope I helped you. Best of luck with the project.
Wishes Ada xx