Monthly Archives: October 2014

Pre-IGF Jitters

We’re a few weeks from IGF, and its getting a little stressful. We need to finalize a lot of things and get the game playable. I’ve opted to put the final UI into the game.

We’ll be working through the weekend, and I’ve put aside assignments from my other classes to concentrate on this final push. Sleepless night to come …

Assignment-6

The objective of our sixth Assignment was to change our asset build process from  accepting the names of all assets to be built on the  command line to accepting a file which included all the information regarding the assets to be built. We also created a new builder for our shader files, so that the program did not have to compile them at run-time, and could just load the compiled files.

The shader builder expects an additional argument on the command line when being invoked, which tells it whether the shader being compiled is a “vertex” shader or a “fragment” shader. It compiles the shader into the game directory, from where the comiled file is loaded at run-time.

For the asset build list, I decided to use the file format suggested by our professor, since I felt that it did a good job of maintaining readability and handled all the information that would be necessary for building each asset. Here’s how my file looks:

Assignment6-Graphics

The file returned a table, with each table value containing information specific to an asset builder. This information included the name of the asset builder, the list of assets which would be built using that particular asset builder, and the source and target extensions of the assets to be built. Provision for extra arguments to be given on the command line was also made.

I had to make minor changes to my source file extensions, since I was  earlier using my GenericBuilder to copy files of varying  source extensions into the game directory, but the source extension for all assets built with the same builder had to be identical for my asset list to work. Hence, I changed the source extension of all my assets which used the GenericBuilder to “.txt”.

Here’s a zip file of my Assignment: Click Here

 

Floating Skulls :D

I fixed a few bugs with my weapons this week, mainly the pull gun. I also refined the AOE nuke ability.

Apart from fixes/ tweaks, I developed the floating skull. This development was the outcome of one of the suggestions given to us by our professors. They thought that the tumbling blocks we had as part of our initial prototype were really cool, and so I coded something which was more dynamic ( the tumbling blocks would eventually end up at the bottom of the tube due to gravity, and that was undesirable. We wanted them to be more spread out through the cylinder)

The new blocks now have three phases. During the first phase, they gravitate towards the center of the tube ( with gradually increasing force). During the second phase, a downward force is applied to them ( which increases in magnitude). During the third phase, they tumble around the tube, acting under the effects of gravity. All these phases have random time durations, so that a few of the tubes will tend to hover with minimal forces on them, while a few others will rise, and fall quickly. This gave the tube an almost wormhole-like appearance 🙂

Aiming Assistance

We soon realized that having a reticle in the centre of the screen was not a good idea for our game, as we were a third person shooter, and our projectiles were affected by gravity.

I began working on a system which would help the user see where his projectile would end up. After a few failed attempts at solving this issue, I decided to simply use kinematic equations to estimate the projectiles path, and feed these points to a line renderer, which would thus show the trajectory of the projectile.

After calculating each point on this trajectory, I would also check to see if there were any floor tiles in its vicinity. If this was the case, I would and a Material to these tiles ( so that the user knew the exact tile where his projectile would land), and also terminate any further calculations for the trajectory ( as they weren’t needed).

 

Assignment 5

We finally got into 3D rendering with this assignment. The change involved changing our vertex information to hold an additional float value for the Z position.

 cube_vertices

 

Here is an example of the vertex layout of a cube mesh. Each of these meshes holds its vertex data in model space, which is the relative location of the vertices with respect to a pivot.

The next step in getting this mesh rendered onto the screen is to get it into world coordinates. Each of the vertices will be transformed by a “Model space to World space” matrix, which converts the vertex positions to positions in the world

model_to_world

Our mesh is now in world co-ordinates. In order to get it onto the screen, we need to know where the camera (or eye) is placed, and which directions it is facing. We use this information to calculate the “View space to world space” matrix. The inverse of this matrix, when applied to each of the meshes in our game, transform the vertex positions of our mesh in such a way that they are now located in a world where the camera is at the origin and facing the positive z direction ( for direct X).

This makes it easy for the graphics hardware to compute which of the vertices will be visible on the screen, and which of them are located closest to the screen ( so that we do not render  vertices unnecessarily, since they will be rendered over by other meshes closer to the screen)

graphics_fundamentals_viewport_3dscene

At the end of these transformations, we can finally render our meshes onto the screen!

Here’s a screenshot of my program rendering two meshes: A cube, and a floor

Assignment5-SaumyaMukul

Here’s a screenshot of Pix showing debug information of my vertex shader.

Pix-Assignment5

 

 

You can move the cube and the camera around in the game. The cube is controlled by the arrow keys, and the camera is controlled by the Numpad keys 8,6,4 and 2 ( Make sure the numlock is turned on)

You can download a zip of my program here: Click Here

[EDIT]: Restructuring had messed up my error handling. Here’s a better build which does not crash when it doesn’t find files it needs to run( like shaders, materials etc.): Click Here

[EDIT]: I’ve added functionality from my previous programming classes into my game now. So I can implement shared pointers, memory pools, store data as actors, have a world which keeps track of all the Actors etc.! I plan to use them for my upcoming assignments 🙂

New Weapons!

So I finished developing the AOE nuke and the pull weapon. Shelwin had already created a weapon system for our game, and I had to get my weapons incorporated into that.

For the pull gun, I created triggers around the players. On shooting the pull gun, I would cast a ray out in the direction of the player, and if this ray hit the trigger around the other player, I would apply a force to the other player, which would pull him towards the shooter.

The AOE gun was a little trickier. I didn’t want it to simply convert a bunch of tiles to the users color. I had this idea in my head, wherein the initial bullet would split into a bunch of bullets on colliding with the floor. These new bullets would then rise as a circle of ever increasing radius, reach their apex, and fall down,  thus converting a circular region around the point of impact. This made the weapon look a lot cooler, and added a whole new dynamic to the game!