The user can now set resolution via the settings.ini file. All shaders are now built with lua code. I also added some more pretty sprites. Hooray! (Simple one-click download. Once downloaded, unzip, play the executable, enjoy!)
About the Project
I added a settings.ini file to the download which allows users (like you!) to set the resolution of the game. The file is originally contained as part of the UserSettings project inside the engine, but is copied by Visual Studio into a predetermined output directory, and then the lua asset build script copies it into the final game directory. This is pretty neat as it makes updating the resolution practically trivial: meaning no code recompilation is needed. As everyone’s device is different, this allows the user to set their desired resolution. It also means that there is more we could add to the settings.ini file later that the user could then change as they desired, removing the developer from the updates at hand. As a developer, QA, or even level designer, this also makes it fast to test different resolutions for different platforms.
For gamers, hot loading data into the game takes the settings.ini idea a step further. Hot loading data into the game means (at least how I’ve done it) that game periodically checks for new data while it is running and can import the data during run-time. I actually prototyped a game at EA that did just this. So the player could drop a file specifying more data like having a dinosaur model in the game, put the information in the hotload folder, and then their dinasour would appear in the game. It was really neat, especially as a player, to see data you created become part of the game during run-time.
Before the settings.ini (or the default resolution):
After a tweak to resolution variables in settings.ini:
The other thing I did was implement a lua script for building the graphics assets (and copying files into the final game directory). In debug I merely copy the lua build assets script which makes debugging and testing simpler. But in release the lua code is compiled and then ran. This makes running the lua code more efficient, but it also makes it hard to debug because, well, this:
It doesn’t really matter in this example though for compiling vs plain text as the assets build lua file is run at build time and so compiling the lua file only helps to build faster. It doesn’t affect the player.
Of course I didn’t compile the settings.ini file into binary because that would completely defeat the purpose of having a human-editable file for changing settings for the game. If a human can’t read it, they can’t edit it!
I find the interesting bugs…
So I ran into an interesting bug: I was getting an “incorrect function” error. It was obvious that there was a path error, but this error message was really throwing me off. After hours of trying to resolve (Zeno and my TA Ameya both helped me in trying to resolve the issue), but ultimately I was stuck. I finally talked with the developer (my professor) and he discovered a bug in his code: he was returning the wrong string variable for the error. Once that was resolved we quickly resolved my bug which to my chagrin was the same bug as his: I too was also returning the wrong string variable.