I am tasked to create the course materials for a game programming class, and I’d like your opinion on what aspects and areas of game programming, such as game state management, game object storing or simple AI, should I include in it? The course is intented to be the first step into game programming for students with novice skills in programming.
There will be mathematics as well, but I found that there are multiple questions, with good answers, on that subject already.
For this question I will assume that the course name might be something along the lines of "Introduction to Computer Games".
I remember taking a game programming course once, and one of the things I had appreciated the most was the fact that the prof. actually took time to teach us a little about game storytelling. In fact, our first assignment was to create a text-based game which would be evaluated on how good the story was.
A lot of the students argued and complained that creating a story was outside of their skill set, and that it was unjust to evaluate them on such a thing. However, if I may paraphrase the prof., the goal in making a game is not only to create something pretty and efficient/fast, but also to entertain your intended audience. Thus, for indie game developers, it's a good idea to start developing storytelling skills as early as possible.
Another thing I think was useful was teaching how to find our intended audience through the Bartle Test. The Bartle Test is a test to define what kind of gamer you are, and therefore to define what kind of games you like. Knowing for whom you are making a game can greatly help reduce the "useless" features your game has and expand on what will eventually be your greatest selling points.
Finally, one thing I would talk about are distance metrics and mathematics. Both of these things are very important in game development and are some of the most underestimated challenges a beginning game programmer will face. Things such as 3D rotation (quaternions) are often ignored until they are needed.
These all have to do with general game creation practices, and are not limited to a single development environment/language/technology. Thus, I think, at least in the long run, that they would be very useful to teach aspiring game-developers :)
EDIT: As a closing note, I would like to add that although taking a course in game development is a great step in the right direction, you should tell the students that the best way to gain some skills and experience is to "get their hands dirty" by making their own small games. To reuse an already overused truism, practice makes perfect!
You could make it for the first part of semester for theory to describe about all subsystems that are common for games (introduction, main loop, resource loading, memory management, math - general and 2d math) and for theory for second part of semester to move to more advanced topics such as game engines their architecture, and how earlier described common subsystems are extended to next level which is required for bigger games supported by big engines, then introduce them to more math - 3d math and advanced topics , opengl, directx, and maybe, just maybe, short intro to few game engines.
At the end of first part of semester it would be good if they get guidelines for game design (story telling, and other related stuff).
For practice part, first part of semester they could do exercises on per class basis, that is they themselves write small main loop, write short resource loading, etc.
Before second part of semester, they form groups of 3-4 students, and design a game (before second part and after game design guidelines), and during second part of semester they do implementation using some framework that has all the boring stuff implemented (resource load, pathfinding, gui, etc...). This framework, should not be some game engine, or big name game framework but something small and compact, and easy to use. Also they should have game art ready to use if they'll make a game.
This would actually be interesting, you give them building blocks (framework, art) and they connect the dots, but they need to know how things work under the hub.
First. Maybe the start of the course could be a quick introduction to Unity and animated/textured character import and static mesh import. I think it is important to get this out of the way as early as possible because it:
Second. Player control (mouse clicking (rts/diablo) and game-pad (action/splinter cell)) and camera control. Some discussion about ray-casting (and corresponding collision queries), transformations, and quaternions. First exposure to ideas of collision, intersection tests, etc...
Third. Game state/character state/FSM. Discussion on logic flow/state transitions and good modular design with Unity's component system. Could couple this with triggers/collision boxes to work on getting characters to respond to the environment, hug and shimmy across walls, grab pick-ups, etc..., for example. Would give second exposure to collision system and related considerations.
Forth. Introduce NPCs and AI. Can complete mouse clicking player control with A* path-finding. Move to flocking behavior and behavior trees (or other interesting topics).
Fifth. Networking.
Sixth+. Other items, depending on course length.
I think it might be cool to have class assignments be limited to making Unity components that implement things related to various topics. This would implicitly force (hopefully) good modular design. It would also be cool to work on a class level game, where friends can plug-in each others components and see the differences.
Making a "full" game could be extra credit/grade booster/separate final assignment and students can be informed of this at the start of the quarter. This way, there is extra motivation for them to start thinking about the design of their code and how best to make it work for them and their own projects.
Anyways, just trying to throw some ideas out there.
