Tuesday, April 29, 2008

Mini-Course: Outline

As the start of my mini-course on computer science and games designed specifically for girls draws ever nearer, I have been excitedly finishing up an outline with my course's contents. I have a lot of detail written out, but just wanted to share a brief outline for now. Note that one of the reasons for organizing things the way I did is to ensure there is a good level of variety between videos and activities, and not too much "lecturing" in a row. Furthermore, about two or three hours a day will be spent working on an actual game using Game Maker.

Without further ado, here it is!

Computer Science and Games: Not Just for Boys!

Part I: Games and Computer Science
  • Introduction
  • Computer Science and Games
  • Not Just for Boys
  • Preview of Course
Part II: Game Design
  • What is a Game?
  • Key Components
  • Introduction to Game Maker
  • Design Process 1: Concept Stage
  • Design Process 2: The Elaboration Stage
  • Design Process 3: The Tuning Stage
  • Starting Your Own Concept
  • Game Worlds
  • Gameplay
  • Other Topics You Can Learn About
  • Refining Your Concept
Part III: Usability and Design
  • Why Good Design Matters
  • Principles of Good Design
  • How to Learn About Your Users
  • This is Computer Science?
  • User Experience for Games
Part IV: Graphics
  • Vector vs. Raster
  • 3D Objects in the Computer
  • 3D Objects on a 2D Screen
  • Other 3D Graphics Concepts
  • 3D Graphics Demo
  • Alice
Part V: Audio
  • Using Audacity
  • Challenges With Game Audio
Part VI: Artificial Intelligence
  • Why AI Is Important For Games
  • Examples of AI in Games
  • Using Finite State Machines

3 comments:

Jos Hirth said...

Using Game Maker is a good choice, I would say. It's even good enough for some shareware games. And there are also a bunch of very nice freeware games like Ikiki's Hakaiman.

Questions like "what is a game?", "what is fun?" or "why do people play games?" are very broad questions though.

If I remember correctly there is one book which contains hundreds of definitions what a game is.

The reason why someone is playing a specific game also might be completely unrelated to the game itself. E.g. he/she could be playing it just to interact with some old friends.

And there is also this whole meta game thing and other unpredictable factors.

What I'm trying to say is that you shouldn't try to answer this kind of questions completely. It's futile. You could talk for a year and at the end there will still be a few things missing.

I would keep it very brief. Like using a dictionary definition, pointing out that there is a lot more to it (with one or two examples), and move on.

What seems to be missing is a "Genres" bullet. While using a specific genre isn't always the most innovative thing to do, it's certainly a valuable tool (if there is some overlap with your game).

Each genre comes with its own set of golden rules and you can chose to stick to them or break/ignore/invert them on purpose. Additionally, they make communication easier, because you can say a lot with only one or two words.

Talking about all genres is again hopeless. There are too many of them. But you could for example talk about a few well known ones and step down the tree a bit to outline the amount of variety.

Does "Design Process 1: Concept Stage" also cover prototyping?

Apart from game design the level design is also very important. But that's again a very broad topic, since each genre/sub-genre has its own requirements.

And those requirements are sometimes very counter intuitive. Good first person shooter team death match maps for example are "broken" on purpose. Without this imbalance, there wouldn't be an important area to control. Which in turn makes the matches less interesting, because no one has a proper strategy and everyone is more or less walking aimlessly around. And there isn't much you can achieve with good team play.

Other topic you might want to raise are contrast/color balance or things like "screen flow diagrams", which are very helpful for streamlining common user tasks like saving a game or changing the volume.

Good luck with your course. :)

Gail said...

Hey jos, thanks for the detailed comments. A lot of what you mentioned is actually covered; it just doesn't appear in the brief outline I put here. (Which is good!) For the actual game design portion, I stuck to one resource, to keep things simple and consistent, as you mentioned. I won't be getting into level design and that kind of thing, however. The course is largely intended to give the impression that computer science can be fun, rather than be just about game design ;)

Jos Hirth said...

Oh yea, I forgot... for sound effects take a look at sfxr. It's a small free semi-open source application, which allows you to create retro flavored sound effects with a few clicks.

What's unique are the generator buttons, which randomize the settings within specific ranges in order to create specific kinds of sounds. There basically is no learning curve at all.

It's really handy. :)

There are also far less formal approaches to game design. If the scope of the game is very limited (e.g. web or mobile games), you can for example prototype around until you identify an interesting mechanic. Then it's "grown" into different directions and once you're sure you're onto something you start with formal stuff.

It's somewhat unorganized, but you get quick progress and interesting results in return.

Well, interesting for about 5-15 minutes on average. Somewhat depressing perhaps, but that's what most of the audience is looking for. It's just something they can do during their coffee break. Complex rules/mechanics won't work there. A nice looking "one trick pony" is all they want (or well, have time for).

Post a Comment

Comments are moderated - please be patient while I approve yours.