So now I’m done with my first quarter of actual game programming at DePaul University. The culmination of my work over these first 10 weeks can be seen in this video on YouTube:
This project was created in five parts. The first part was the scene graph, which is just a node object that has a parent, child, and sibling. Make a ton of them and connect them all together and you have a tree. Professor Keenan gave us a bunch of unit tests that our tree had to pass and I was pretty surprised by how hard it was to make sure they all actually passed. But in the end we made a great scene graph.
The second part was a memory system, which was by far the hardest part of this whole thing. It was an elaborately debuggable system based on the Windows Heap API. Very complex, lots of pointer math, but I was so impressed by the whole concept that I’m going to do an independent study over the summer where I build a more in depth memory module for DePaul’s Azul project.
The third part was a file I/O system, which is currently just a simple Win32 wrapper. This was much simpler compared to the memory system.
The fourth part was the Math library, at least the Vector and Matrix portions of it. We are adding quaternions next quarter. This was more of an operator-overloading lesson for C++ than anything else. The math was pretty simple, but to get the operators to do what we wanted was harder.
The fifth part was the graphics system, where we took a simple OpenGL demo and built it into whatever we wanted. The requirements were to use the scene graph we made, cull objects against the camera frustum, and instantiate a bunch of our objects. It was hard because we were left to our devices to figure out how to do most of this stuff. Each week in class Prof. Keenan would go through the process of refactoring or building a small part of what we needed, but a bunch of it was left to us.
This proved to be a fascinating lesson. Rather than worry about finding The One Right Way to do something, as I used to do, I learned to just hack something together to get what I wanted, and then refactor the functioning code into a proper system. This is a much more effective and iterative way to get things done, and it was a lesson I don’t think I would be able to learn any other way. It was terrific.
So where to go from here? We have a number of steps we will be taking next quarter, but that doesn’t mean I intend to sit on my laurels in the meantime! I have four objects in the code as it stands – the pyramid, the cube, the doughnut, and an object that is essentially the parent that holds all 36 of those objects into a DNA shape. These represent four classes in my code. Each of these classes has a file for its overall representation or model, and a class that represents an instance of that object.
I want to abstract this into two classes. One will be the equivalent of Game Coding Complete’s Actor class – a generalized class that holds an OpenGL VBO with however many vertices this object needs, its location in the world, and anything else I may need for it. The other class will represent an instance of one of these objects.
In the end, this code will not function any differently, but internally it will be much simpler. It will also be more data-driven, as each of these objects will have a source file that its info is read from.
I hope to update here on a weekly basis of what I am changing in my system. As the months and years go by I hope to see it improve from what it is now to a fully realized game engine. I think even the next 10 weeks are going to show a drastic improvement.