Assignment2 Writeup

This assignment was mainly focused on us learning the basics of LUA and how to supply game
data at run time.
Lua- Lua is a scripting tool which we use in our project. This is basically used to supply user
specified data to the game in a user friendly format. This is because the game files in a real
game need to be edited by a non-technical person as well.
Lua is open source software and it can be fully integrated with C, C++. There are different ways
that we can interface with Lua1. Calling Lua functions from C- Using this method we can create different functions in Lua
and call those functions from C. These functions can have to be first registered with
C/C++ and then these can be called. So in this way, Lua file can have all the actual logic
of a function but C will just have its definition.
2. Calling C functions from Lua This can also be done. But the main difference between
this and the above method is that, the function parameters in lua need to pushed onto
the stack. The C functions need to get these parameters from the stack, process the
data and then push the resulting parameters onto the stack. The only legitimate
argument for the function is the Lua state and the return parameter is always an int
which is the number of parameters pushed onto the stack before returning.
Lua also has basic data types similar to Cnil - Used to differentiate the value from having some data or no(nil) data.
boolean -Includes true and false as values. Generally used for condition checking.
number - Represents real(double precision floating point) numbers.
string - Represents array of characters.
Using these variables we can process real time data such as user data which user may provide
in a .ini file as well.
Log Files- We also learned in this assignment how to output data to a log file. Both errors and
information messages can be transferred to a log file. This will allow the users as well as the
engineers to know what exactly went wrong in the code or which steps were executed in the
game.

Additions to the game

In addition to integrating Lua to the game we also successfully managed to render a square on
to the screen and animate it. This was done as1. Increasing the size of the vertex buffer The vertex buffer size was increased from 3 to
6. This is because we want to draw two triangles now instead of one and draw them
simultaneously so they appear as a square.
2. Adding 3 new vertices Three new vertices were added to the game. The ordering of
these vertices depend on the graphics API used.
a. OpenGL uses a right handed triangle system. This means that the ordering of
triangles must be counter clockwise.
b. Direct3D uses a left handed triangle system. This means that the ordering of
triangles must be clockwise.

Above screenshot shows the start of the game where the white square is drawn by using two
triangles.

Above screenshot shows the progress of the game after a few frames where the height of the
square is decreasing. Also the fragment shader has changed the color to cyan. This behavior
occurs repeatedly as a function of time.

Asset build procees

The current asset builder is using Lua functions to build the assets. Currently the only thing
being performed by the assetbuilder system is, compare the assets in the Authored assets and
the Built assets directory. If there is some updates in the assets, we are copying the latest
assets into the build directory.

Dependencies
1. Lua This project is only depending on the source code of Lua which is included in the
project.
2. User settings This project depends on Asserts, Logging, Lua and Platform projects to
be built.
3. AssetBuild System This is only dependent on the AssetBuildLibrary which inturn is
dependent on other projects.

Changing Settings in settings.ini

settings.ini is a file the user can interact with as discussed above. It is an interface with which
the user can tell the game to run under certain settings. Now, after the game is built, there will
be a copy of the settings.ini in the game folder as well.
If we change the resolution values in this file which is present in the game folder, and then
execute the game, the game will now run in the new resolution. This is very convenient for the
user as he wont be forced to build the game each time.
Now, if we go and rebuild the solution for the game, then return to the game folder, we can see
that the values in the settings.ini have been changed back to the original as per the ones in
the User Settings project folder. This is favorable from the developers perspective. The
developer needs to run the game from his own settings. Which will be set in the source
settings.ini. The target settings.ini is intended for the users/testers of the game.
So basically settings.ini will be always copied from the source to the destination as it is setup
in its properties as a custom build tool. The reverse is not happening and should not happen
because the actions of the user/tester should not directly conflict with the development of any
game.