Cool Scene

For making this cool scene, I had ideas of making a farm but I could not find good free assets online. So I decide to make this room. This is how it looks. Hope you like it. :)

Here's the link to my code: Download Code

Graphics Assignment 12

So much satisfaction after seeing the shadows work properly. I did face some problem but luckily they were small mistake which JP helped me figure out.

For doing shadows, I created a texture and a surface. This was used to create a shadow map. A shadow map is basically depth map with respect to the light. This shadow map is used to figure out which point on the map is closer to the light.

For doing shadows, we pass the view position and projected position of the pixel in light's space. Then the z value of the view position in light space is compared with the value which is looked up in the shadow up. The projected position of the pixel in the light space is used as texture co-ordinates for looking up the value in the shadow map.

Here are the screenshots of my Renderer and Shadow Map.

Here's the link to my code: Download Code

EAE Day

We had a build running on the EAE for the people to play. There were many industry professionals playing our alpha version of the game. We got a lot of valuable suggestions for improving the game.

Our graphics professor JP has some valuable inputs too. He said the Point Man lacked control. It seemed like he was taking orders from the hacker and not able to play his own game. We had this problem since the prototype itself but we could not find a good design solution. We surely added things to the Point Man after the prototype but that was not enough. We will look into this after we start the development process again after the semester is over. JP also said that the Hacker side lacked thrill which the Point Man had.

All the inputs that we got during the EAE will be considered during our design discussions.

I am sure that The Co-Signers is going to be a really good game. Lets see how the development process goes after this.

Scrum - Week 2 and 3

Our engineering team was very much stuck to the schedule. We were done with all the task assigned for the two weeks. 

In the second week, I worked on the Guard chasing the player. Guard's vision was implemented by Kiran. I just had to make the Guard chase the player when he saw the player. This was an easy task for me. I completed it quickly so that I could have time for handling my other programming stuff.

We decided to make the game feature complete in the 3rd week itself so that all the engineers can have more time to work on the assignments that we were lagging on.

I took lot of work in the 3rd week. I did the EMP implementation and the Power Node implementation on both, the hacker and thief side. Before this time, I did not work on the Hacker side at all. So I knew very little about it. I sat with Max, Nikhil and Chris to understand how exactly the hacker side works. 

While doing so, we got into a discussion about how the states of the nodes on the hacker side works and we came to know that we surely need to change the implementation of it when we are done with the alpha. 

My task in the 3rd Week was hardly anything from the Point Man side. It was a lot of work on the Hacker side. 

EMP implementation:

EMP is a trigger which releases all the network connections in a certain radius.

1) Point Man triggers the EMP.

2) Network is notified about this event.

(Thanks to Max's work on the Networking System. This was not too hard.)

3) Network tells the Hacker Side that EMP has been triggered at x,y,z position.

4) All the nodes surrounding this position in a particular radius are released.

Power Node Implementation:

Power Nodes are the nodes which have to be powered on by the Point Man for the Hacker, so that the hacker can hack it.

I know this does not sound very difficult but there are so many states for a node which makes it kind of complicated. 

At the end of the 3rd week, all the engineers met for making a final build for the EAE day. We remained at the lab almost till the midnight for combining the code and bug fixing.

With the end of that day. Work on Co-Signers for the semester was over :).

There starts SCRUM

When we met after GDC, the producers were finalizing the design of the game and all the engineers were designing a well formed architecture for the game. Since we had two sides working together, synchronicity between the two sides was very important and for that to happen a proper structure and interaction between the Hacker side, the networking and the Point-Man side was necessary. We decided the architecture and all of sat to decide how should the alpha be made.

We had 4 weeks to pull off an alpha (Less time than what we had for making the prototype). So we had 4 sprints. Each of one week in length. We made the tasks as short as possible so that each engineer can work on a unique task.

In the first week, I worked on making the Guard Overlord System. The Guard Overlord System was basically a manager between all the AI entities on the Point Man side. So if something happens in the world then this information won't go to the guards directly. This information would be sent to the Overlord. The overlord will decide which guards should be affected by this event.

So in the first week I created this basic Guard Overlord System. This will be expanded during the development process later.

Back from GDC...Engine Decided

After we came back from GDC, we had a meeting for deciding what engine we were going to use. Everyone of us agreed that for the game to be good and complete as per schedule we should use Unity.

We talked to people at GDC and the thing that was important were playable demos, something that someone has done on their own and good programming skills. Experience in UDK might be important but for the game Unity was important. Hence we finalized Unity4 and decided to meet next morning during our projects class to finalize the progress of our game.

I will make something in UDK on my own whenever I get time. More on that......when I start making something ;).

And, This is what happened at GDC.....

This was my first GDC and I was so excited for everything. Meeting people, talking about games, talking about work that's happening around, listening to the talks of big people. Everything was overwhelming.

On the first two days of GDC, I attended various sessions. Sessions on Math for Game Programmers, Physics for Game programmers and especially the AI summits. I got to know a lot about lots of stuff. Also, the other important thing to do at GDC was networking. I was finding it difficult initially to approach people and talk to them. But as time passed, I started getting into the groove ;).

I wanted to know few important things from the people, especially engineers working in the industry and I wanted to talk to people about that. I always thought that as an engineer it is very difficult to portray how good of an engineer you are from your resume. So I asked a lot of people about what could  be done regarding this. I got a lot of valuable information. Most of the stuff that people told me was to create a website, portray work on the website, have code samples, have playable demos on the website.

I also talked to people about how can I develop myself in the one years time that I have before I graduate. I got various kinds of answers for this question. Few people said that work on some technical stuff and create something that could be awesome like an AI technique or a good collision system and few people said that they just look into the playable demos of the games. I will be concentrating on all the things that I have learnt from all the big people and that will surely make me stand better in the crowd next year.

One of the many other reasons to be at GDC was to try and get an internship opportunity. I was talking to  people, especially near the job pavilion  regarding this and most of the companies did not have internship positions. But I was amazed by the number of people out there looking for jobs. That was a real eye opener. I was living in this shell of University of Utah. I surely understood that this is not easy industry to get into.

When we apply for a job, there are thousands other than you applying for the job. So even if I am a really good engineer, getting someone's eyes on my Resume is really hard and that is when I understood the importance of networking. If I know someone and I am in contact with them, they know whether I am a good engineer or not. They can at least forward my credentials to the HR. By doing this, at least I have someone reading my Resume and that's mostly what I aim for.

How can I make good relations with someone by talking to him/her for 5 minutes?
I cannot. But at least while I am talking I can make a mark so that they can remember me. Even if they don't I get their contact information so that I can ask them for help regarding my Resume and who knows while helping me they might find a good candidate for their open positions.

During the interview, it's completely my battle. I will be responsible for winning or losing the battle. That is the time when I can show the interviewer how could of an engineer I am. But getting into the battle is really tough and that's what networking in GDC has helped me to do.

I might not have got responses from everyone. I am not even saying that I have 10 internships lined up for me. But I surely got some valuable advice on my Resume and on my website (Yes. I created a website as soon as I came back from GDC. Here's the link: vaibhavbhalerao.com. Take a look. All your suggestions are valuable too. :D)

Going to GDC was an amazing experience. I have learnt so much from GDC. Not just about programming. But also about how to present myself in front of people. And I think, that's an very important lesson.

Just before GDC - The Change of Engine Issue

In one of the projects classes during the next week, Bob, Roger and Craig were going to talk to all the Engineers, Producers and Artists respectively.

The Engineers meet Bob:

Bob wanted to talk about why and what engines both the teams have chosen and why?

Engineers in our team told Bob that we have chosen Unity and the reasons for that. So Bob told us that if deadline was the issue with we not using UDK or any other engine then this deadline can be changed to something else and a date should not stop us from using some other engine. All the engineers definitely wanted UDK or CRY experience on their resume and hence all of us started thinking about changing the engine.

Till the Producers finished their discussion, all the engineers in our team were discussing about the practicality of it and we thought if the alpha date was pushed to just before the start of the next semester then we can try changing the engine and engineers will be able to pull it off.

When the producers were back, we shared our thoughts about changing the engine. The discussion got a little ugly. The engineers were concerned about their Resumes and the producers were concerned about the progress of the game. We discussed the Pros and Cons of both. The discussion could not go very well because the state of minds of the people was not calm. So we decided to make ourselves calm and discuss this issue as a team.

What did we decide?
We decided to talk to people at GDC about how much it matters for the engineers to use engines other than Unity and also think about the progress of the game. We decided to have a meeting after GDC to decide the engine to be used for The Co-Signers.

Gate 1 Cleared. What Next?

We cleared Gate 1 and all of us were getting ready for the next phase. During the prototyping phase, we found out some flaws in our game ideas. But then we did not have time to deal with it. The industry panel was going to see our games and that time it was just about getting stuff done which was decided. So we did not pay attention to the flaws in the game. Design discussions were necessary when we started phase two.

Another question in front of us was to decide the Engine to be used for making our game. We were considering 3 options, viz. Unity, UDK and Cry.

Why not CRY?

One of our major thing in mind was to port the Hacker side of the game on the IPad. Cry would not let us do that.

Why not UDK?

Max and Nikhil were working on the game for Ubisoft Competition and they were using the UDK engine for that game. They were of the opinion that the learning curve for UDK is very steep and it might take time for us to learn the engine and make the game. We had heard this from other people too. Since we had to submit the alpha version of the game at the end of the semester, we had no time to learn the engine and then make the game. 

Why Unity?

Unity did a lot of favors for us. Our game was huge in scope. Even the industry panel said that. The current idea of the game sounded big and we wanted to add stuff to it because we were not happy with design that we had at the prototyping stage. So, for quick development and the ability of having an iterative process we chose Unity.

When we met as a new team during the projects class we used to discuss the design. We also planned on having an engineering session so that all the engineers can talk about how stuff was implemented in the prototype and how it can be changed. The actual engineering work did not start on the game soon. It was because people were adjusting into the new team , the design was to be finalized and previous implementation was not discussed sooner.  So all the engineers decided to meet once and talk about the engineering side of the game while the design discussions were still on for around two weeks.

Graphics Assignment 11

This was the best assignment of all time. I have learned a lot of stuff from the assignment. How exactly RenderStates work, why, when and how to change the textures (DirectX textures), how to create some cool effect after you have drawn a scene and other important stuff.

Process that I followed was:

1. Draw everything to the opaque surface.
2. Copy everything from opaque surface to postProcessing surface.
3. Draw translucent bodies on the postProcessing surface

Now the postProcessing surface has everything that is needed to be drawn on screen.

4. Copy everything from postProcessing surface to the BackBuffer.
5. Take in postProcessing texture as in input in the final draw call and create some cool effects.

This is how my final render screen looks like.

I added 2 different kinds of effects. First one was the blurry effect. For doing so, I looked up the color values in the neighboring pixels and averaged it. The current pixel got the averaged value of the neighboring pixels. In the other effect, I added a random color to the pixels. This random color was changed based upon sine, cosine functions.

Final part of the assignment was adding a HUD element. The HUD needs to be drawn on the screen after everything else is drawn. I gave the screen co-ordinates directly to the HUD entity in the Mesh file and it was drawn onto the screen.

Here's the link for the code: Download Code

Graphics Assignment 10

The things that we are making in this graphics class are overwhelming. I had never thought of the cool things that we can do.

In this assignment, I created a depth buffer to make a cool effect. I needed to make a depth buffer of our own because the depth buffer in the graphics hardware cannot be accessed.

I used this depth for creating a blending effect. For doing this, I checked the distance from the camera (i.e. the depth). If the difference between current pixel's depth and previous pixel's was too low then I added transparency to it (value of alpha depended on the difference ).

This is how the effect looks.

Here's the link to my code: Download Code

Graphics Assignment 9

I was thinking that this assignment is really easy and it is true indeed. But I could not complete the second part of the assignment properly even after trying hard for a long time.

The first part of the assignment was to  create reflecting surfaces.

I used environment maps for doing so. I used the DirectX's texture tool to create Environment Map. 

I used this environment map to be sure that I am doing all the steps correctly. I could have have created different fancy environment maps but for the assignment I stuck to this one.

I used the camera position to find the vector between the fragment and the camera. Then using the reflect function, I found the reflected vector which was used to look up in the Environment Map to find the exact color for the pixel.

I was done with this part pretty quickly.

The next part was to create different render targets and create some fancy effects. For example, making the translucent objects to have the refraction like feel or magnification. 

The steps were:

1) During Initialization, create a copy of the back buffer.

2) Create a different render target (i.e. the back buffer won't be used for storing the information)

3) Draw all the opaque objects (This information will be written to the user created DirectX surface)

4) After drawing the opaque objects, the back buffer should be set as a render target again.

5) Copy all the information from the user created DirectX surface to the back buffer.

After this step, we have all the information about the opaque objects in an image which will be used by the translucent effects to create fancy effects.

6) Draw the translucent objects.

I thought of another way to do it which would be to:

1) Keep the back buffer as the render target

2) Draw all the opaque objects

3) Copy the back buffer data to a texture which will be used by the translucent objects for creating effects

4) Draw the translucent objects

By doing this, we would not have to change the render targets and the work will be done.

Unfortunately, due to a few problems ( which are unknown right now ), I was not able to exactly do what I intended to. But I will look into it and completely it later.

Here is the Pix screenshot and the Screenshot of the renderer.

Here's the link to my code

The Judgement Day

After so much of hard work for more than a month, everyone was waiting for the decision. We wanted to know which were the games that got selected. We came to the lab at 9 in the morning. Our EPs (Professors) wanted to make sure that they were on the same page. So they were LATE :P. We all wanted to relieve our pressure. What could help more than a game of League of Legends? So all of us started a game of league.

After a while, Roger, Bob, Mark and Craig arrived. We all sat in the presentation area and all of them started talking about how they felt about the pitches and all the games. They said that they spent hours talking about the games and finally they revealed that two games out of the four presented, were gonna go ahead. After that they asked each team about the responses of the industry panel about their game and what exactly each team felt about that.

Now was the time for the big announcement. The two games that got selected were VINYL and THE CO-SIGNERS. It was a happy moment for me. I wanted to jump in the air but at the same time, I was feeling bad for the other games that could not make it. Everyone in the cohort did an fantastic job of creating an awesome prototype and putting forward some awesome pitches but unfortunately, only two games were gonna go ahead.

After this announcement, they told us that everyone in the cohort can choose whichever team they want to join and we were given time till Tuesday for making the decision. Most of the team was pretty much decided on the same day itself.

Now our new team for THE CO-SIGNERS includes me, Chris, Max, Nikhil, Kiran, Sagar, Saurabh, Aaradhya and Yang as Engineers, AJ, Andrew, Zac and Jake as Producers and Damean as our Artist :).

I am very excited to see people playing this game when we complete it. Right now, we are finalizing the details and we are gonna complete an Alpha version of the game till the end of this semester. Hard work ahead. Hope it pays off :D.

Let me tell you about The Co-Signers :D

THE CO-SIGNERS

It has been a long time since my last blog post about the games we pitched and the games that got selected for Gate 1. Now I will tell you about my experience as I started working on our prototype for Cellblock.

Our final team who was working on Cellblock for the Gate 1 included me, Max, Nikhil, Chris, Kiran and our great team of producers, Andrew, AJ and Zac. I was very happy with my team. All of us were really excited to make an awesome game. The idea of an Asymmetric couch co-op game was something different and exciting. So our team started working on it with full force.

We started our first day with physical prototype of the Game focusing on the stealth mechanism and communication between the two players. Initial premise of the game was a Hacker helps a Prisoner to escape out of a high security prison. The hacker can hack the security cameras, get to know the position of the prisoner using the security camera footage and eventually, guide the prisoner to take proper decisions while the prisoner tries to dodge the security guards and other security threats on the ground.

Here's the video of our physical prototype

This physical prototype was followed by a week of brainstorming sessions. We came up with a few mechanics for both sides of the game. The mechanics that we came up with for the first-person view player did not suit the theme of the prisoner. We wanted the first-person guy to have some high tech gadgets like tracking bugs, mobile cameras and other similar stuff. A prisoner would not have all this if he was trapped in a jail. So we thought of moving away from the Prisoner-Hacker team to something else.

The Prisoner-Hacker theme was followed by a Thief-Hacker theme but even that too did not stay on the table for long. Then during our next stand-up meeting, Andrew told us about the theme that he thought of during the weekend. So the theme was that two graduate students infiltrate the department of education for resetting all the student loans. So we thought of the name THE CO-SIGNERS!!!

After the theme and the mechanics we decided, we started working of the prototype in Unity4 with full force. Me and Kiran were working on the Point Man's mechanics whereas Nikhil, Chris and Max were working on the Hacker's mechanics. Max also managed the networking between the two parts of the Game.

Me and Kiran working on the Point-Man's mechanics

Chris, Max and Nikhil discussing the Hacker's perspective

Specifically, I started my work on the Mechanics with implementing the doors properly, viz. Opening and the Closing of doors. The doors that I implemented for the prototype were the old-school Doom or Wolfenstein style doors which open and close side-ways. 

My next task was working on the AI, i.e. movement of the guards in the world. I used Unity4's NavMesh for implementing it. Andrew gave me the guard paths and I assigned those patrol paths to the Guards. We thought that if the Point-Man is seen by the guard then that is the end-state for the prototype. So me and Max added a vision box for the guard and that was all about AI for the prototype.

Both sides of our prototype were coming through nicely. Max had figured out the networking stuff in Unity4 in the first week itself. He continued managing the networking till the end of the prototype. We had a few playtesting sessions and added a few mechanics that we necessary for the prototype.

This prototype had to pass through Gate 1 for making it into a complete game. Industry panel was going to judge our games and give some suggestions about the game. The games shortlisted after this gate were gonna be made into complete games. Before the final industry panel meeting, we had our demo presentations. For this presentation, everyone worked really hard. 

Before the Gate 1, we had a major question in front of us. Whether to show a video of the game being played or to show a live gameplay demo? Our prototype had a few game crashing bugs which would show up once in thousand times. We tried our best to find all the bugs and resolve them before the Gate 1 presentations. While this was being done, deciding which way to go was still a question. After our first demo presentation all of us decided that we will have a live gameplay demo. A gameplay demo was really necessary for understanding the core of our game which was the co-operative tension between the two players. If this was not showcased properly, our prototype and the presentation would have lacked the most important idea that we wanted to convey.

It was Saturday and our industry panel presentations were gonna be on the following Monday. All of us met in the lab on Saturday and we were working on polishing the presentation. Few of us worked on the Game Demo while others worked on the presentation. Collective effort of Chris and AJ created an awesome video which was gonna place the plot of our game during the presentation.

On Monday, all of our cohort helped is setting up and cleaning the lab for the BIG EVENING.

Studio Setup

Members of Team Hack 'n' Hide Setting up the presentation (From left - Zac, Me, Andrew, AJ and Chris)

Everything was set to go. Our team, all pumped up. Andrew, very nervous :P. We wanted to be the first ones to present because we were the one group which had 10 different technical things that could fail. Two projectors, HDMI switchers, Live Gameplay Demo are the few things that I can mention. 

Finally the presentations started. Here's the video of our presentation.

Lot of the industry professionals mentioned their concerns about the scope of our game being too big. We knew this could come up and this was one of the other reasons that we wanted a Live Gameplay Demo. We wanted them to know that we have done so much in the span of 5 weeks and we could do a lot more if we get an year. Some of them encouraged us by saying that if this is done in a right way, we could pull this off.

After all the presentations were over, we had to wait till Thursday to know which games were going to go ahead. All of us wanted The Co-Signers to go ahead. All of us were really passionate about this idea and could work really really hard for making this game. But we had to wait till Thursday to know what was gonna happen with the Co-Signers.

Wait for the next post to know what happened with THE CO-SIGNERS :).

Graphics Assignment 8

I have started loving this class. The things that we are doing are getting interesting every week. Yesterday I was going through my blog and saw all my post from assignment 1 till 7. We started with drawing a rectangle on the screen in 2D space, then we created a cube in 3D space, added a texture to it, added diffused light, added specular light, created transparencies and now, we added normal maps. Things looked better than what they were in the previous assignment.

In this assignment, I was very clear about the concepts for adding the normal maps. So it did not take long for me to complete the assignment. This time we had to add to textures to a single Mesh, one for the diffused map and one for the normal map. The normal map basically gives the information about the normals to the shaders, hence giving a mesh a visual feel as if it was not a flat surface.

With the normals that we already got from Maya, we also needed to take the tangent and the bitangent information. We used this information to create a Matrix which will convert the normals from Texture Space to World Space. After we get the normal information by multiplying the normal in the texture by the matrix, we can use it in a same manner as we did before.

Here is the Grafitti Image for which I gave a wall texture as normalMap and the Soccer Ball image for which I gave the RaisedSucken Image as normalMap.

Here are the diffused maps and normal maps that I used.

Here is the link to my code :)

Controls for moving the Camera:

W - Up

S - Down

A - Left

D - Right

E - Forward

C - Backward

Controls for moving the light:

T - Up

G - Down

F - Left

H - Right

Y - Forward

N - Backward

Graphics Assignment 7

I loved every bit of this assignment. It was really amazing to see how different blending modes worked for transparency.

I approached this assignment by setting the ALPHABLENDENABLE to True. Then I just changed few alpha values for the Meshes and I ran the program to see how it looks. So it did show some transparent surfaces. For doing so, I had to research a little bit the Render States. Sagar was little ahead of me in this part. So I took his help also in understanding the render states.

After doing this, I targeted each effect on its own. I created each of those effects one by one and tested them. I started with Additive because it was the easiest of the other transparency effects.

According to my understanding, ADDITIVE effect just adds up all the colors that have already been drawn on the screen at that particular pixel position.

SRCBLEND and DESTBLEND is ONE for ADDITIVE effect.

Then I moved to Partial Transparent Effect. For partial transparent effect, I took the alpha value from the material file. I set this Alpha value as a uniform so that the shaders can use it. Using this alpha value, I set the alpha value for the fragment and then GPU did the rest of the work using Render States.

SRCBLEND is SRCALPHA and DESTBLEND is DESTALPHA for PARTIAL TRANSPARENT effect.

Lastly, I worked on the Binary alpha. I created an Alpha map using an image of my favorite football (soccer ;P ) club. I got this image from google and then I deleted the background. I used this image for taking the alpha values for the shader. Then I used the clip function to clip of the unnecessary fragments.

 We set the ALPHABLENDENABLE to false in the case of BINARY EFFECT since we take care of it manually in the shader.

It was very important to sort the Entities from back to front because for creating transparent meshes, the Meshes in the back have to be drawn first.

But I divided the Entities into two different list. One for Opaque Entities (the color of the pixel depends only upon the current value of the fragment) and Translucent Entities (the color depends upon the pixels already drawn).

For optimization purposes, the Opaque Entities are sorted in the way mentioned in the last assignment.
For accuracy purposes, the Translucent Entities are sorted based upon the distance of the Entity from the Camera (descending order).

Here is the screenshot of my scene.

Below are the screenshots from Pix with Events.

Here is the link to my code: Download Code

Graphics Assignment 6

Exporting from Maya was really amazing. I wanted to export some fantastic model. But lack of knowledge in Maya held me back for a lot of time. The Maya Exporter did not work for some meshes. Finally I exported a Spiderman model which looked amazing :D.

After that I moved to converting the file into binary. I was struggling in understanding the concepts for binary file. Sherly and John-Paul helped me to understand it. So I was pretty happy that I will be able to complete the next part quickly. But then a weird error troubled me a lot. When I was writing the file in binary, the compiler gave an Debug Error which said Invalid Allocation Size. Moreover, I could not debug the MeshBuilder application. Debug window did not open and Windows asked whether I want to report the problem. So after trying to find out the problem for a long time, I gave up on that.

Then I added a few more Meshes from Maya and was trying to recompile after deleting the temp folders. A new problem arised. The Mesh builder did not compile. I did not make any change in the Mesh Builder and it started giving me an linker error. I restarted the computer and it started working.

Download Code

Updated on 1st March:

Since I could not complete the assignment on time, I did not submit the completed assignment. After that I was trying to figure out why my assignment did not work and I could not go ahead. AB, apparently found that the reason for that was my anti-virus program. My anti-virus program blocked some of the .dll files and hence the MeshBuilder did not compile properly. 

After that problem was solved, I pretty much knew what I wanted to do. I created my binary files, read the data from the binary files and then drew the Meshes. Then I moved to the 2nd part of the assignment which was sorting the Meshes in such a way that all the way that all the entities having the same effect are grouped together. Moreover, all the entities having the same material should be grouped together. This was done to minimize the changes between the register data of the GPU (I guess).

After this was done, I was clear for doing the next assignment :D.

Graphics Assignment 5

After I was done with assignment 4, assignment 5 was pretty easy

For making the specular light work, we calculated the dot product between ViewVector and the Normal of the surface. This was multiplied with the dot product of LightDirection and the normal because we did not want light on the opposite side of the Mesh.

Finally exponent was used to define the texture of the mesh.

Download Code

Graphics Assignment 4

Phew......This assignment was too big for me. This assignment needed a good structure.

In my structure, scene has information about the Light, Camera and the Entities.

Entities had information about Meshes and Materials that the mesh will use.

Materials had texture information and effects which will be applied to the Mesh.

So basically a mesh got data from 2 sides. 1. Scene and 2. Materials.

After a mesh had all the information it needed, during the Mesh Update, it drew on the screen. There were more than one entities on the scene, each with a different material and different effect.

I got stuck with a trivial thing for very long time. I could not see anything on the screen. Then Sagar Mistry was tweaking through my PIX and said there could be something wrong with the transforms. So then I checked my files and CameraPosition was {x,y,z} = {0,-10,0} instead of {x,y,z} = {0,0,-10}.

Controls

Moving the camera

W A S D

Moving the Light

T F G H

Moving the objects or meshes

Arrow Keys

Download Code

Graphics Assignment 3

After creating a 3D Cube and coloring it, it's now time for texturing it and adding some light to the scene.

In this assignment, I figured out including the light pretty easily. I was very clear about the concepts. SO it was just about passing some extra variables to the shaders and doing the Math.

I have a cLight class. It's position can be changed at run-time using 'T'(up), 'G'(down), 'F'(left) and 'H'(right).

I struggled a bit with the texture. I added the file to the textures folder. But for some reason my texture did not load. Then I found out the reason. I was loading the texture during the initialization process. It should have been loaded during the loading of the scene. After I changed it, texture should up.

Screenshot with texture and light

TextureData in Pix

 I used the "fake" normals for processing the light. I used the mesh-coordinates as normals for the cube. After completing the assignment with these normals, I tried increasing the number of vertices and changed the data for the vertices but it messed up the cube completely. I will try to use the real normals but for now here's the assignment 3 with "fake" normals: Download Code

Assignment 2 Graphics Class

Introduction to 3D

Phew!! This was a challenging assignment for me. I understood all the concepts. But the biggest challenge was to convert those concepts into code. I referred and got some help figuring out the code part from Jason Thummel's Code.

For Moving the Camera:

I created a cCamera Class. cCamera Class create the World To View Transformation Matrix.

Controls for moving the camera:

W - Up

S - Down

A - Left

D - Right

Controls for moving the Cube

Up Arrow - Up

Down Arrow - Down

Left Arrow - Left

Right Arrow - Right

For the World To View Transformation, I used the LookAt function.

cMesh Class created the Model To View Transformation Matrix

I had problems figuring out how to create the View To Projection Transformation Matrix.

Following links helped me understand it.

http://msdn.microsoft.com/en-us/library/windows/desktop/bb147302(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/bb206341(v=vs.85).aspx

Here's the link for my code:Download Code

Decision Time

My pitch started with a thought that I don't care if the game idea is bad or not but I want to pitch and it ended with I WANT MY GAME IDEA TO BE SELECTED :P. I really thought I don't care whether the game gets selected or not but I thought so much about the game in the 2 days before the decision was going to come out that I got attached to it. After the pitch I thought of so many things that could be done with this idea.

So, it was decision time. Roger, Bob, Craig and Mark (The Selection Panel :P) came to the lab and they said that they would give comments about each of the pitches. They said that my game idea was not new and there are a lot of games that have used shadows for something. Shadows was compared with Curse Of Shadows and they were of the opinion that another game about shadows won't be cool enough. (Shattering sound :P). I expected a lot good from this game idea and I felt that "Ahhh. I am sure it's not getting selected. So just move on and start thinking about other games."

After their comments about all the games, I was just waiting to hear were games were actually selected. And then comes the decision. They don't select the games this time...we do...!!! There should be at least 5 people on one team. As soon as they said this I knew that this is not going to go well. There were 18 pitches and 26 people in the Cohort. So people will have to give up their ideas and join other games. I knew it was going to be a mess.

The mess started right then. People moving it and out of groups. I believed in my idea and I thought I would convince others to make Shadows. But I got no chance to explain how my idea was different or how the team could make it different. 

I chose to be in the race then gave up later in the day. Thought over it again and thought of coming back into the race and finally I gave up again. I thought this was a good thought on their side to let us choose the games we want to work on. But the best thing that could have made the process a lot easier would be shortlisting the games. Shortlisting would have made easier for people to leave their game ideas and join other ideas. If I knew that Shadows does not have any chance, I would have readily and easily joined Cellblock the very first minute after the decision was told to us.

Loving the game that you are working on is really important. Giving that chance was completely correct. But the mess in the process could have been avoided. I thank Roger, Bob, Craig and Mark for giving us the opportunity to work on the game I like.

I love the idea of CELLBLOCK and I am all set to create an awesome game now.

Pitching Game Ideas for Thesis Game

Yeah! It's a new semester and everyone was excited about what is going to happen this time. We knew that we were going to start working on our thesis games. We had the opportunity to pitch our own games ideas. It was not a necessity but being involved in some pitch in some way was.

I had a set of mechanics that I thought were interesting but I was not able to build a game around it. It's not that I did not try. I was trying to build a game around these mechanics and write a thesis paper on it in the last semester's game design class but I landed up pitching an idea which I did not quiet like. So I had to be involved in some game pitch.

So.....My To Do List said....FIND A GAME THAT YOU LIKE AND BE A PART OF IT. So I asked Kiran if I could help him with his idea of augmented reality game idea and he was cool with it. Somewhere I knew that I wanted to pitch a game. But I could not because for pitching a game, you need a game idea :P and I did not have one.

That night, AB (Aaradhya), was working on his game pitch (Footprints) and I was sitting with him. He was so excited about pitching a game. He was literally saying that it doesn't matter to him whether his idea is good or not, but he wanted to pitch and I was like, "Yes. Why can't I just go out there and pitch a game? It does not matter whether it is a good game idea or not." So yes, AB was an source of inspiration for my pitch.

Me and AB looked through some videos of IGF games and we were really awed. The game ideas that really made me go crazy were 'Perspective', 'The Bridge' and 'One and One Story'. I really loved those game ideas and I wanted to come up with something different. So I started thinking about the mechanics I had and mould it into a game. One of the mechanics, was to duplicate things or in other words, change one object into other. This dragged me to SHADOWS.

I don't know how this happened. An idea just came into my mind at 2 am in the morning and I was like, "Yes. This is what I want. And this is not just some game idea. It is AWESOME!!!". So I started preparations for my pitch. There was no research behind the shadows games. I had no clue if there exists some games which use this. (I knew Curse of Shadows but it didn't come in my mind because I still think it is a different game). I did not research about anything whatsoever. Rather I did not have time to do that.

Me...Pitching Shadow

Next morning I was pumped up for my pitch. Before this idea came into my mind, I really believed that I was not capable of coming up with a good ideas. I had no confidence that I could come up with a good game idea. (This opinion of mine is now changed. Surely.) Now that I believed in my idea, I wanted to give a best shot. The pitch really went well and people liked it ( I guess :P). So I was really happy.

Concept Art of Shadow

Something about Graphics Class

Assignment 1 Game Graphics Class

• Modifying the vertex data and creating a rectangle instead of a triangle

I took little time in understanding the code initially as I was working for the first time with code based on DirectX. After I found the way to change the vertex data, it was pretty easy. I tweaked in some values to try and make different shapes and then I made the rectangle finally by putting in 6 values.

•  Data for the vertex buffer comes from a file

The data for the vertex buffer was supposed to come from a text file. So the easiest format I thought of was .txt. So I created a text file listing the points, each on a new line. I read each line and put the values in the buffer.

•  Text file should go through the Asset Building process

For doing so, I referred the TextureBuilder and did a similar process to create a MeshBuilder Tool.

•  Modifying vertex shaders and fragment shaders

For changing the shaders I played with the sin and cos functions (even dividing them to create tan) and was observing the changes. Also, used the timeElapsed variable to see the changes in real-time.

•  Debugging through PIX

Debugging through PIX was not a big problem. I took little help from Sherly and Kiran to figure out the initial part. After I started the test run, I went to the Rendered tab to check out the pixel information and debugged it through the pixel and vertex shader.

Here's link to my code: http://www.eng.utah.edu/~bhalerao/