As the semester comes to an end here I am with my version of a very simple first person shooter game.
You can download the Direct3D_64 build here.
You can download the OpenGL_32 build here.
My game has a cross-hair and a gun modeled and textures. You can move yourself around using the WASD keys. There is a cool wooden floor that you can walk on. All this to show off my fancy new texturing system. I also have 2 spheres with different colors. You can shoot at them by hitting the SpaceBar button. They will gradually fade away the longer you keep shooting at them. The fancy pyramid just exists to look cool.
Here's a screenshot:
The ultimate goal of all of our assignments this semester was to be able to build an engine that someone else can use to make a game.
And to prove that everything works, we had to make a simple game. Since it was an engine of my own design, it was easy to work with a lot of things. With the way I had my systems set up, applying materials to each of the objects was fairly simple. We had a full description of what sort of object we are looking at in our material file and that got built at compile time. All the required assets would be loaded at run time from their binary formats very quickly. The material files for each mesh can get super complicated when you are dealing with multiple small meshes and textures since each mesh needs its own material file, but for the scope of this project and my game it was fine.
Something else I would have done if I had more time was to add in more of the game code, like a win/loss state, more dynamic targets to shoot at etc. I was afraid of over scoping my initial project and not finishing it. That is why I decided to keep it simple, making sure it works as intended.
This class was all about making our engine, with a focus on graphics. Working with Direct3D and OpenGl in the same engine was difficult. While I feel this did not give my enough opportunity to learn in-depth about Direct3D or OpenGL, working with C++ code to make sure that you are supporting 2 different platforms was interesting. Finding ways to have platform independent code and dependent code so that when modifying things, the code doesn't have to be changed in multiple places was challenging.
Personally, I like to do my programming one step at a time. I build small systems first, using hardcoded values, and make sure the system as a whole works, before expanding to include additional features and less hardcoded, more dynamic systems. One of the problems with this approach is that you end up having to change a lot of your own code to incorporate the new systems. However, doing things step-by-step ensures that problems can be nipped in the bud. I also like this because I do not believing in building the most perfect engine, instead only adding scalability for things I am aware it needs to be scalable for. Sometimes this means I have to change things I have written before, but it helps me tackle problems a few at a time. The design of my code evolves as new features are added later on. Another limitation of this approach is that my engine also only contains functionality for things that are needed immediately.
With the approach our professor has taken in teaching this class, there are a lot of things I learned about good design since we would have very descriptive requirements for what was needed. My programming knowledge and style has definitely improved over the course of this semester. At times, especially in the earlier assignments, it felt like I was simply following the instructions in the assignment to get it done without having to think much about how I would tackle a specific challenge. However, it also established a good base of code which we could expand upon in later assignments. Plus, since I was new to graphics programming, following instructions could also get complicated sometimes.
That's all folks! I am ready for the holidays and done with my assignments. Wish you a Happy 2016!
Thanks for reading!
This week, I will added support for textures for the models we export from Maya and use in our game.
We had to change a few things to make this happen. First, in our fragment shaders we need to add a "sampler" to sample our textures for a set of texture coordinates and render it onto the screen. These texture coordinates (obtained from Maya),, also known as UV coordinates help us map a texture to a mesh.
I also added a texture builder that converts the textures into a DDS format that can be easily loaded by our Graphics API.
The material builder we built last week also need to be modified since our material files now include a texture as well. The material builder loads the texture along with the sampler uniform so that the texture can be loaded along with the material and rendered.
The image below shows my new material format in binary. The highlighted portion shows the new data that is added to my material file containing the name of my sampler and the texture.
To use this data in my game I had to decide whether to make a separate class for the textures or merge this data as part of my material class. I decided to have the texture data along with my material data since it made more sense for me to have all of it in one place since I was reading it from the same file. The only reason I can think of why having a different texture class would be useful is if there are multiple textures on the same mesh. This scenario also seems highly unlikely in my project.
Below are 2 screenshots comparing my game in Direct3D and OpenGl.. The textures look smoother on OpenGL and sharper on Direct3D. This is due to different default sampler states for each platform.
The screenshots show the textures on my objects as part of my work for the game I am building for our final project. This is the last of our assignments. More on the final project next week.
Download my current build here.
I have controls for my upcoming game, so use the WASD to move the gun and space bar to shoot the spheres. Esc to quit.