A “Games class” in computer science can mean a lot of things. In fact, it has meant a lot of different things to me over the years I’ve taught it. This year, my thoughts have evolved a bit.
Understanding what I think this class is is important for you to know what to expect, what you will be doing (and why), how you will be evaluated, …
I see this class as having three interconnected parts:
- Technology for Games – The advanced computer science that goes into making games – graphics, AI, … Games have interesting demands on technology, with demands that are different than other applications.
- Games as Technology – The “science” (or art) of what games are and how to make good ones. Game design is particularly interesting because understanding how to make fun games gets at general issues of how to make “stuff” that is enjoyable to use, and to bring elements of game design to the creation of things other than games.
- Building Games – How to actually create the software that is a game. While a lot of this is “just” software engineering, the desire to make a game is a good excuse to learn how to work with others to make a non-trivial program.
In this class, you will learn about all 3. Each of these 3 topics is a key component of the class. This is a break in philosophy from previous offerings of this class which were focused on #1, and did a little bit of #2 and #3 since I wanted people to do a project.
What this means is that you should expect course content (lectures, readings, assignments) related to all 3 topic areas. We’ll spend time talking about software engineering, and expect you to do projects where you’ll get to try your hand and building things. We’ll spend time talking about game design, and try our hands at designing games and seeing how game design ideas can be applied in “the real world.” We’ll spend time talking about some advanced technical stuff, and try to apply them. …
Comments on this entry are closed.
{ 5 trackbacks }