The usefulness of Settings.ini
The settings file will contain useful, relevant variables of the game that can be manipulated by the player. In our specific example, it merely sets the resolution of the output window of our game. Being able to configure the game without recompilation saves time, and negates the need to have access to the source code to set these variables. In useful real work applications, if a game were to properly utilize a human readable, sensible settings file. Than perhaps, the player could take their settings along with them from installation to installation, like that of a LAN party, and keep their personal settings along with them. Along with allowing players to manage their own custom settings, this could also make the distribution of custom settings as easy as authoring a properly formatted lua or text file.
The benefits of allowing simple, or even complex, game settings and variables easily manipulated and set without the need of compilation is a useful feature. Offering quality of life benefits to players’ experiences, easy distribution that may foster the community within the player base, and also less developer leg work without requiring specific releases / executables for mass deployment of differing setting configurations.
The Benefits and Disadvantages of Compiled Lua
- Because the Lua compiler doesn’t need to actively recompile the file when the game begins, it is relatively faster than if the file needed to be compiled first. This process could take some time and is also dependent on the size or complexity of the input Lua file.
- Shipping compiled files negates the need for the inclusion of the compiler in the shipped product. If you will never need to recompile any Lua file, that’s less dependencies and one less external to be included at distribution.
- The compiled byte code, is much smaller than the raw text Lua file.
- Finally, the fact that Lua must be compiled before shipping, you could catch errors at this point in time rather than down the road when the final product is given to customers. There’s fair amount of assurance that during transmission that the file’s integrity is intact, but that’s not always a complete guarantee.
- Readability no longer exists in this file. As seen in the graphic above, the Lua file is no longer human readable. This makes debugging, or attempting to find errors in your script near impossible. Also, it is less clear to the end user whom is using this compiled file what the Lua file is actually doing. You lose the transparency that you may be aiming to uphold with your end users.
- With the raw compiled output still easy to edit via a text application, a simple mis-delete or accidental addition of a character can completely corrupt the file making it unusable. By directly altering the compiled code you may cause unforeseen errors ranging from code that does not work properly to code that may completely crash the application.
Leave Settings.ini Alone!
Settings.ini is a particularly useful file, as outline in the beginning of this post. By not compiling this file we allow it to be easily modified by the end user. In this specific example, we give the ability to set the resolution of the game window, something that the user may want to change often or on their own whim, via an uncompiled Lua file. It’s simply a matter of making trivial modifications, trivial to access.
You can try out these games via the below links. The only difference is that Direct3D will be used in the x64 version, with OpenGL in the other. They have been built and verified to work on Windows.