Assignment 6
Object Position 1
The write-up should also explain (in your own words) what the point of the assignment was and how you did it
A large part of this assignment I felt was to isolate super game specific logic, that would primarily be dictated in other programs (like maya). To isolate and read in external data, and have the game engine adapt to it. I for the most part didn’t have any problems in creating the file format and reading it in with Lua (have had some practice in lua before on a prior project). I spent more time trying to understand the file handlers. In the end, the code for the file handlers wasn’t much, but trying to understand how they worked or how they should be used was confusing. I had to wrap my head around how the template function for the handlers worked, and I also had to wrap my head around the scope param functions a bit(I still don’t know how they work).
The write-up should contain detail about how you personally completed the assignment:
I’m gonna be honest, I feel like how my game currently uses the file handler is pretty bad. It makes sense that the game developer gets a file handler to a path they pass in, but then it starts to feel weird when you have to use that handler to get a reference to a data structure to pass or call to functions (In my case it was the submitting of geometry data and the storage of it in a game objects). All the while I was scared that the reference counter might screw up somewhere along the way. In terms of why I didn’t go ahead and try to pass the file handler deeper into the system. One reason was that I felt like I was going to run into referencing counting issues and I wanted to avoid the problem till I got a better handle (no pun intended) on how things should be structured. Another reason was that I felt like I was missing another system that needs to be implemented. I feel that there needs to exist some static system that game objects interact with to manage geometry within the game. Just as how game engines have some mesh management system that manages instances or shared instances of meshes for performance reasons, I feel like that needs to eventually exist in our system as well. Or maybe I’m just crazy and overthinking things.
I would like to beg the question though, why negative indexes? I would also like to beg another question, why a stack? To answer the question of , “why a stack” I’m guessing its due to the nature of programming. Just as how we have a stack trace in c++, in order to interact with another language, you have to observe the stack of the language. The problems come in that as a user for making geometry files, I have to constantly think about the state of the stack, pushing, and popping. I am making a safe assumption that it is not ideal to use lua to store geometry, but for simplicity sake, it meets the requirement. As for the question of negative indexes, I’m assuming it’s because you are always looking at the stack from a point of reference that would make it most convenient to take steps backward then having to keep track of where you are in terms of brackets. Overall however, I feel it would be better to use a more managed file format or library made for storing data (and it self manage’s it’s own stack somehow), if it exists.
Specific Requirements:
When it comes to comparing the costs and benefits of having human readable assets, I’ve certainly seen a large benefit in them in comparing engines like Unreal Engine and Unity. In Unity, you have the option to configure all files to be “Serializable”, this essentially makes it so that all files are human readable in some text format. This makes working in environments that utilize file merging more manageable (like utilizing git). Being able to observe file history with human readable assets has vast benefits in terms of debugging and saving conflicting work. In Unreal Engine, most files (like blueprints) are binary and not human readable, this forces developers to adopt certain workflows like file locking. It also makes file merging or syncing a pain if you don’t adopt such workflows. This all being said, I assume that human readable assets come at a performance cost, so its very hard to make hard arguments without diving in more.
Looking at figure 1 shown below. you can see the human readable file format design I chose to go with for my geometry files. Looking at my file, there was one assumption I made, that assumption was that the user understood the concept of vertexes and indices in constructing geometry. I don’t know if this is a dangerous assumption, but I felt it was appropriate. For the file, it made sense to separate index data and vertex data into two separate tables. From there each table would have ordered array elements that would dictate geometry. I also felt that it was important to key label my X,Y, and Z values because I feel it adds context to what values represent (for if the user is worrying about W or weird ordering for some reason).
Looking at figure 2, you can see I was testing the debugging of my individual Geometry Builder project. It can be nice to isolate the testing of individual projects to isolate problems when you can encounter them. In this case, I didn’t encounter any bugs or issues, but I could see this playing a role in implementing unit tests of some sort for individual projects.
Credits:
I discussed the assignment with Bosan, and Pluto
Fig 1 : Geometry Lua File
Fig 2 : Debugging Geometry Builder
Instructions:
Use left and right arrow keys to move the camera
Use up and down arrow keys to move the camera forward and backward
Use ‘W’ ‘A’ ‘S’ ‘D’ to move one of the shapes.
Use ‘SHIFT’ to change the shape that moves when held down