The first assignment was mainly all about setting up the solution in Visual Studio correctly for the future assignments. This was very interesting to me as I have only worked with smaller projects before that didn't have much inter dependency between projects and libraries. So it was a great learning experience for me.
We had most of the code provided by our instructor John-Paul so the majority of the assignment included just adding the different facets of the project into a well structured solution. The main thing is we want the systems to have minimal dependency on each other so that the systems remain modular and can be reused in a different project. We had to separate out the project into an Engine system, External library, Tools system and Game. What I mean by this is the engine I write is independent of my game and can be reused in a different game. It would be double the effort to write the same engine code for another game I make later.
For the most part we were provided instructions on how to set up the project in a way that helps us simplify all the systems and they way they work so we had very minimal decision making in terms of architecture of the project, but more important was understanding the way things worked and why it was setup the way it was.
One of the really cool things is using property sheets to set up a temp folder that all of the files that we build would go into. This is really useful as all those files are a product of building the source code but not required in the source code (hence the folder name 'temp'). The good part about this is one; all the generated files from building the code are organized in a separate folder, and two; since these files are separated removing will not affect the project the in any way.
Another thing was separating out the asset system from the game system so that each one can be built separately. That way once the asset list is much larger, the assets can be built independent of the game system so when there are changes to the assets the whole project does not need to be rebuilt (in larger games build times can be as long as an hour or more). It works more so for the other way around when assets can be very large, then a small bug fix in the code can result in a very time-consuming asset rebuild.
At the end of the semester I hope to have a better understanding of the asset pipeline in games, as well as an understanding of the graphics and shaders used in graphics in game engines. I know very little about the graphics side of game programming and I'm really excited to see what I can get out of this class. I still have mixed feelings about whether I'll like it or not... who knows, time will tell.
For all this work, we have a triangle printing on screen (screenshot below) to show for it. :D
You can download the current version of my work:
Download DirectX_64 build here
Download OpenGL_32 build here
Leave a Reply.
This is a blog that documents my work for my graphics Game Engineering class at the University of Utah.