Design of the game mechanics and level representation.
In our version of Bloxorz (which we call Bloxorz mini) We implemented the required game mechanics minus the teleports/bridges/”weak” tiles; so all in all we have a map of tiles that was empty spaces in it and that we have to drive the 2x1 brick from start to end location in our map.
Due to the fact that our geometry rendering ended up being quite a bit more complex that necessary we used two sets of variables, one to keep track of the cube’s position in the map and one to handle the required translations of the geometry; hence we had the position & translation variables. Here we will explain only the empty tile detection, which use the position variables; explanation of the translation variables will come later.
We track always the top tile of the cube and make adjustments on which parts of our surface to look based on our current and previous position. Hence is the tile was up in (0,0) if we press the TOP button and lay the brick down vertically the translation variables will be updated and will carry the following values (0,2) this happens on and on minding of course the pitfalls that might happen if we move the cube pressing TOP and then immediately pressing BOTTOM; these cases of the movement are handled by a helper variable that lets us know which button laid the brick down which in turn helps us determine the correct offset to add.
Design and Rendering of Geometry and basic functionality.
The level (and the cube) is drawn using the reference cube that was given to our initial sandbox and applying to it the required matrix operations in order
to bring it to position. The approach that was followed made the detection of the cube in empty tiles later on a bit difficult so another set of
variable coordinates was used to represent the actual cube’s position which we explained above; so all in all we have the translation variables and
the position variables.
The level is represented by just using a double for-loop and drawing the cubes next to each other, minding of course the empty tiles, start and end tiles which need to be handled differently. During that loop empty tiles are handled by just advancing the translation variables by the required amount as-if there was a normal cube, this results in the adequate spacing that we want between each tile and correct representation of empty spaces. The Start and End tiles have different textures applied to them so the user can easily distinguish them.
The brick is drawn prior to the actual level and there is a bunch of translation cases that we take into account in order to successfully translate the 2x1 brick in the correct place; all in all it works as intended although it is a bit more complicated that it should.
A highlight of my project is a feature that enables the player to play for an infinite amount of levels as we feature random level generation using a variable length table which the user can set; at this time the table must be NxN (i.e. must have the same X/Y dimensions) but this will be changed in the future. The user can select the minimum/maximum width & length of an empty space as well as its granularity factor; which basically is a factor that indicates how large the empty spaces will be, lower values (and which are power of two) tend to give better results.