I was amazed to have seen the course offered at my community college and had to immediately speak with the CIS professor who was teaching it as to what it was all about. After showing me demos of a caveman sprite running across the screen and first-person tank program of sorts, I was sold on the course.
I attended the course for the first-ever time it was taught at the school. Harbour's "Beginning Game Programming" paperback was somewhat the template for how the course was taught. The instructor pointed out several errors in the code written in the book and provided his own corrected code on the college's server. I should note that it has been my experience with this professor that I have not need to use books for thorough reading but rather for occasional reference, and it is somewhat my chagrin that I didn't use Harbour's book as much of a reference either.
For the first one or two classes, we discussed our favorite video games and some of the principles behind video games as we watched a demonstration of a few popular games on the projector via a Super NES emulator.
Next came my favorite part of the course: seeing student projects from another school! It was a laugh riot seeing the amateur quality of these games. In my head, I was thinking: these guys are chumps! I can make better games than that! No flies will be on me!
The course would then be taught in much of the order of the Harbour book, demonstrating the blitting of a bitmap on the screen, blitting in various positions, accepting inputs, loading sounds, timing, and whatnot. The code for utilizing these DirectX tools is complicated. It's really hard to tell sometimes what each element of the code exactily does for what's going on on the screen.
As you go through the class, you shed your original misconceptions of what was being taught and what your tools actually provide. One thing to know is that game programming teaches you nothing new about programming. It provides you with a set of tools to utilize the graphical capacities of DirectX. Everything else is up to you.
By the time you get to the mid-term project, you end up taking a big dose of humble pie as you realize it's hard to make a killer game all by yourself and the project you turn in doesn't look that much more impressive than those other projects you mocked. Do not worry; you are not graded harshly if your game sucks (even though that's how it works in real life).
It is important to be inquisitive and to entertain your interests. I was highly interested in tiled video games and had developed functions for drawing a tiled map on the screen.
We never got to any of the three-dimensional material at the end chapters of Harbour's book. Rather, the last portion of the course was spent on producing the final project. And it would still be my disappointment that my game would still be grossly amateurish.
Computer Science II was the prerequisite for taking the course. I had taken that course, but I unfortunately had not remembered any of the elements that that particular course taught, especially the object-oriented programming portion of the course. Knowing the paradigm of object-oriented program helps tremendously in the science of game programming, but do not feel you need to know it to take this course. Still, it is a useful paradigm that you should adopt as it has helped me tremendously.
After I had finished the course, I produced my own project outside of the class, probably taking a few months. After having gone through the rigors of using DirectX alone, now I am learning to use other libraries, such as Allegro, in the development of my own engines and games.
Thanks for visiting and please share your own experiences!
This post has been edited by MadPlumber: 28 July 2007 - 10:42 AM

New Topic/Question
Reply




MultiQuote











|