Skip navigation

Monthly Archives: September 2014

The two parts for this assignment were:
1) Use shader constants, and change them through either the material file(color) or user input(position)
2) Add a new GenericBuilder project, as an example of of different builders we can have.

For the first part, the material file was changed to the following:
return
{
    constants =
    {
        g_colorModifier = { 0.8, 0.5, 0.8 },
    },
    shaders =
    {
        vertexShader = “data/vertexShader.hlsl”,
        fragmentShader = “data/fragmentShader.hlsl”,
    },
}

Now, when the program runs, it reads the g_colorModifier value from above, and sets it in the fragmentShader, shown here:
Fragment Shader

This is a per-material constant, meaning it stays the same throughout the use of the material. What we could do is make different copies of the same material, but with a different per-material constant value, resulting in objects that look the same, but with a different color (in this case).
Here is the rectangle using two different color values from the material:
Game - 4 - 1

Game - 4 - 2

Another type of constant is a per-instance constant, which is different for each mesh using a material. This is why its not read from a material. The vertex shader has the following constant in it:
Vertex Shader

We used this constant to change the position of the rectangle on screen using the user input. In the sample exe below, use the arrow keys to move the rectangle around.

For the second part, we added a BuilderHelper project, which can now be used as a base to develop specific builders in the future. As a start, we made a GenericBuilder, which builds all assets. However, in the future we can extend BuilderHelper to make asset-type specific builders, such as a shader builder, a texture builder and so on. Building assets converts it from a human friendly form to an efficient machine readable format. Hence, it is better to have different builders for different types of assets to help build them efficiently.

Time breakup:
Reading/Understanding what to do: ~4 hrs
Getting the graphics part working: ~3 hrs
Setting up the BuilderHelper and GenericBuilder: ~1 hrs

Total Time: ~8 hrs

You can download the working exe here.

Your browser may say that the file is malicious. This is because some browsers do not allow sharing executables from unknown sources. However, the file is perfectly safe to run.

We spent most of this week working on refining our mechanic further, as we had a lot of the other stuff nailed down. We decided a penalty system to the premonition, to stop players from spamming way too much. This came in the form of reducing the radius of how far the premonition reveals everything, as well as taking away color from the game. Yes, as you keep spamming the ability, the screen turns more and more black and white, as another form of punishment. The other big thing was, we found the fun in our game. Ever since Andrew’s feedback, we’ve been constantly trying to figure out what makes our game fun. And this week, we may have found it. Up until now, the environment would always affect the player, whether player revealed or not. Just as a test, we decided to make it so that the various tiles affect you only if you can see them. It was simple enough to implement ( all it needed was an if condition and a new boolean), but that simple change made our game a billion times better. Now, instead of being a game where you just run forward and let the level take you wherever, you had to actively think when and where you want to use the ability, which made the game become about making split second decisions, to escape the thing chasing you and making it to end.

In this assignment, we progressed from drawing one triangle, to a rectangle. We also made our own material file, which currently only holds shader information for our rectangle. So the two parts to this assignment were:
1) Use an indexed buffer to draw two triangles(to make a rectangle)
2)Create a new file format for material files which we will be using in the rest of the assignments.

Here is the rectangle we drew:
Game - 3

For the first part, since a rectangle needs two triangles to be drawn, and each triangle needs 3 vertices to draw, the first thought is to just draw two triangles, with three separate vertices for each. But, as two vertices were shared between the triangles, we decided to use an index buffer, so that we can minimize the size of the vertex buffer being used, by reusing vertices. An index buffer stores the indices of the vertices that form a triangle. Thus we could reuse the vertices already present in the buffer to draw separate triangles. This reduces the size of the vertex buffer. Here is a PIX screenshot showing the Draw call used for above rectangle:
PIX - 3

The IDX column in the PreVS tab in the details section shows the index buffer values used for each triangle. Also in the same section is the position for each vertex. When finally drawing on screen, DirectX uses normalized screen space co-ordinates, which means that the rightmost edge of the screen has an X value of 1.0, leftmost has -1.0, and similarly for top and bottom. Which is why the co-ordinates are in decimals smaller than 1, because otherwise they wont be rendered on screen.

For the second part, I created the following material file:

return
{
    shaders =
    {
        vertexShader = “data/vertexShader.hlsl”,
        fragmentShader = “data/fragmentShader.hlsl”,
    },
}

Its a very small material file for now, but will grow as the class goes on. It is based in Lua, which is a powerful scripting language, and also a very good data description language. I chose the above format as it is easy to parse in code, easy to add new material information, and also very human readable, making it easy to find any problems that might be present in the material file itself.

Time breakup:
Reading/Understanding what to do: ~4 hrs
Getting the graphics part working: ~0.5 hrs
Setting a new class to use the material file: ~1 hr
Reading the material file and using it to render everything: ~2 hrs

Total Time: ~7.5 hrs

You can download the working exe here.

Your browser may say that the file is malicious. This is because some browsers do not allow sharing executables from unknown sources. However, the file is perfectly safe to run.

That we have a build this week? Why yes we do! Although it is in very early stages, we do have something that works. Jose had been pressuring us to have a proper build for a while, so we gave in and worked hard on getting one this week. We made a wrapper to manage the menus, as well as level loading (so that the game is actually playable). Also, through our internal playtesting, we decided to get rid of the simple chasing boss we had, so we shifted Abhishek to be the guy making the Wrapper. Being the lead engineer, it fell to me to be the guy who makes sure we have a build ready on time. This brought forward new challenges with Unreal, which I had honestly not seen coming. First off, building lighting takes years, even on the machines we have. Having experienced this first hand, I’ve started looking into setting up Unreal Swarm ( a Task Distribution system which makes the lighting builds quicker by distributing the process to multiple computers). Also, apparently Unreal projects are HUGE. Are very simple game, with only four levels, takes up two gigs after being packaged. This is another thing I will be looking into, to make our build as small as possible. Meanwhile, James has started prototyping a new boss type, which instead of simply following you, flies above you and shoots things down at you. While not in this build, it should be there in the next one, and I’m looking forward to seeing how it will work with the rest of the game.

For this assignment, we had to play around with the vertex data used to draw the white triangle in the previous assignment, and make a colored triangle. The second part of this assignment was integrating Lua into our project. The goals of this assignment, according to me were:
1) Start getting a base knowledge of how vertex buffers and shaders work.
2) Setting up an asset pipeline which can be easily expanded later, using Lua and C++ together.

I found the first part to be easy enough, which involved using the new vertex and pixel/fragment shaders provided by our professor, and modifying the structure of the vertex buffer to incorporate color as input data, along with vertex position. We learned that the vertex buffer, along with the graphics hardware, interpolates input data on its own, to generate color values for each pixel within the triangle. Since the color values are interpolated between the three vertices, we get a smooth gradient as can be seen here:

Nicely interpolated colors between green, red, and blue.

Nicely interpolated colors between green, red, and blue.

Here is a PIX capture of the above program:

PIX Capture. That's a lot of stuff which happens every single frame.

PIX Capture. That’s a lot of stuff which happens every single frame.

PIX is tool available with DirectX which helps a lot in debugging graphical/drawing problems. In the above screenshot, the highlighted DrawPrimitive() function call is the call which actually draws the triangle onto the screen. The parameter “D3DPT_TRAINGLELIST” means that we are sending the list of traingles to be drawn in the form of a list of vertices, with each element in the list being a set of three vertices. The details tab on the right side shows the vertex information used to draw this mesh, which in this case was a single triangle. It shows the vertex positions, and the colors associated with each.

The second part of the assignment, integrating Lua and C++ was itself composed of two parts:
1) Enabling C++ and Lua to communicate with each other
2) Using the above communication to build assets for our “game”

The first part was kind of tricky, and involved adding three new Lua projects to our current solution. When I finally got that to build without errors, the super tricky part began. I learned how to call Lua functions from C++ code, and vice versa. From what I’ve seen of Lua till now, it seems like a really powerful and versatile scripting language, able to do a lot of complicated stuff. The major amount of time in this assignment was spent on understanding how Lua and C++ work together, and getting that functionality working in our project.

Time breakup:
Reading/Understanding what to do: ~4 hrs
Getting the graphics part working: ~0.5 hrs
Getting Lua projects ready: ~0.5 hrs
Using Lua in actual code: ~ 3 hr

Total Time: ~8 hrs

You can download the working exe here. It’ll just show the colored triangle from earlier, but you wouldn’t believe the amount of code in there!

Your browser may say that the file is malicious. This is because some browsers do not allow sharing executables from unknown sources. However, the file is perfectly safe to run.

This week we made huge progress on all fronts. I got the different environment interactions working with the player, and also working with Vinod premonition. Abhishek got a basic version of the chasing enemy in, which follows the player around the map, ready to kill them. We’ve started getting levels in as well, with Tony, Brenton, and Kyle working hard on designing and creating levels. This is what part of the launch tile looks like:

launch

 

I had the material of the tiles switching instantly as soon as the player used the ability, and Vinod upgraded it so that the material change happens smoothly between the two states, which makes the game look much better. With Unreal, we can quickly try out stuff that could work, and although combining code to make sure everything works together is a bit confusing at first, we’ve got the hang of it now, and can easily combine what different people are working on. We are making great progress, and I hope that we will keep up the momentum!

For this assignment, I had to take all the sample code provided by my professor, combine them into a single Visual Studio solution, and then structure the code in such a way that:
1) Makes sense
2) Is easily extendable to allow future additions.

Rather than involving a lot of coding, this assignment was more focused on setting up a good code-base for the future.

To structure the code, I decided to use namespaces instead of classes, for the following reasons:
1) The current “systems” present need to have only one instance during the entire program execution. Namespaces ensure that there is only a single copy at all times
2) Namespace definition can be spread across multiple files. Classes do not allow me to do this

I would have preferred to use classes, but considering the multiple problems I ran into during last semester, I chose to go with namespaces this time around. I hope this was not a bad choice.

I did not encounter any major problems, and I believe that this was partly because of all the discussions we had over the problems some of my fellow students were facing. Had they not already run into a problem, and have our professor or some other student provide a solution for it, then this assignment would have probably taken a lot longer for me.

Time breakup:
Reading/Understanding what to do: ~4 hrs
Getting all the sample code together and working: ~4 hrs
Thinking about architecture: ~2 hrs
Actual structuring: ~ 1 hr
Setting up Git: ~ 0.5 hrs
This Write-Up: 0.75 hrs

Total Time: ~12.25 hrs

The game executable can be downloaded here.
Your browser may say that the file is malicious. This is because some browsers do not allow sharing executables from unknown sources. However, the file is perfectly safe to run. It should show a white triangle on a black background.

UPDATE #1:

After receiving some feedback from our TA, I made the following fixes:
1) Unnecessary includes in EntryPoint.cpp: I had a bunch of includes in my my EntryPoint.cpp, which were not needed at all.
2) Game crash on missing shaders: If the shaders were missing from the data folder next to Game.exe, the game would show a message and crash. Fixed so that it shows a message and exits.
3) Resources folder in the wrong place: The Resources folder was in the wrong location. Moved it to be where the Windows code was.
4) Defined -1 as a const: Instead of an arbitrary -1, I defined a const DEFAULT_FAIL which is returned in case of no well defined error code.

The fixed game executable can be found here.

This week, most of our class time was spent in meeting, first to lock-down what all features we want, and then coming up with an alpha checklist. The alpha date for all mechanics is Oct 02, which is about a month from now. Here is what the checklist looks like:

alpha

 

Yeah, that’s a long list, considering we are doing most of it from scratch. We also defined what are premonition mechanic is, which is: it reveals in an area around the player, and when the environment is revealed, the player can’t interact with it. Once we hit this checklist, we will go into polish and bug fix mode, so that we can deliver a complete experience for IGF. We were also going to be focused more on the juice, as that was another important thing we got from Andrew, that our current game felt very boring. The team has already started coming up with level designs. As for engineering, I’ve taken the responsibility of creating the various environment elements that the player will be interacting with, as well as the player controller. Vinod will be working on the Premonition mechanic, while Abhishek will be developing the enemy that follows you.