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/

All about Snipe Hunt

Introduction:

     Snipe Hunt was the prototype made for the Mechanical Engineering department. The apparatus on which the Game was being deployed consisted of a tread-port, three giant screens and no mechanical interface between the player and the game. So, a player could just walk to play the game. Why such apparatus for playing games? This apparatus is for helping people with spinal cord injury to start walking again and regain their confidence and games are the medium by which people forget about the therapy and push themselves to succeed in the game. This is why Neuroworx asked us to make a game.

Game Idea:

     After a lot of discussion, Chris came up with the idea of a tower defense game. The player is a farmer and he needs to protect his food which he has just harvested and piled up, from the snipes. The player can set up traps or baits on the field which which trap or lure away the snipes. So, the mechanics of the game were walk to a trap spot or a bait spot to acquire a trap, stop walking to set up a trap or a bait and walk towards a snipe to manually capture a snipe. We divided the work according to different components that are present in the game and their behavior in the world.

Division of work into different parts according to components in the game  and their behavior

   
My Role in Snipe Hunt:

     My work was to manage the movement of the snipes on the field. I used the SnipePosition Vector and the FoodPosition Vector for doing it. I used the approach shown in the image below.

My approach for randomizing the movement of Snipe in the world

   Angle between the current Snipe Position and the Food Position was checked. Then within a margin angle of  'X' at a distance of 'Y', a point was selected randomly. The snipe makes its way to the selected sub-target and then finds a new sub-target. The motion between this two points was sinusoidal. The margin angle decreased after every iteration by a small amount. Hence, the snipes were directed towards the food. After the snipe is at a certain distance from the food pile, it will make its way towards the food pile without creating any sub-target.

Problems faced during this prototype (Postmortem):

One of the main problems that we faced during this prototype was merging the code that we wrote individually. This problem was caused because there was a lack of structure to the code. A proper interface between two systems was not defined and because of that merging was not possible. We ended up having two copies of the same game.

What I learned?

Defining the structure of the code before starting the code. For example, Part A of the code needs x, y, z from Part B. So Part B should be written in a way that it gives x, y, z to Part A and not something else.

Sticking to what work is assigned or what work we take up.

Take up more responsibilities if you know you are capable of doing it.

Screenshots:

Snipes in the farm

Trap Spot

Trap Acquired

Setting a trap

Snipe Captured

Monty's Quest - Up and Running

      Hey guys, this week was awesome. Everything was just great. Me and Max worked really really hard for the  game and all the work paid off. Everyone liked it. Nathan gave some amazing art to make the game look beautiful and our producer, Andrew, helped us on every step. I was lucky to have a great team in my first prototype in the EAE program.

Screenshot 1

Screenshot 2

Screenshot 3

Click here for Monty's Quest Trailer

   

   On Monday, we had a dry run pitch. We had a white box working on Monday. From that white box, making a complete prototype was a tough task. We worked hard on Tuesday and yes it was done. On Wednesday, we had our final demonstration of the game, which went really well. This was followed by postmortem. Bob explained us how a postmortem should take place and how it helps. And I think it really helps to improve yourself and make yourself ready for the next challenge.

Postmortem of the Game

     (All my friends in EAE, you all should know this.) I was talking to Roger during the break in the Game Design class and he said that he was surprised (in a good way :P) and really happy that all the prototypes were so amazing.

     WHAT I LEARNED FROM THIS PROTOTYPE?

     1) First of all, what exactly is a prototype?

     2) In a prototype, learn what is needed. You don't have time to learn everything and then start programming.

     3) When things aren't available with you, try to do it yourself.

     4) Your co-engineer could go faster than you. You should catch up with him. (what say Max? : P)

     Complete experience of making the game was fabulous. It started with a quick prototype followed by a running game. Then the pace slowed down a bit because of few reasons but then all ended well. Looking forward for the next prototype. See you soon C# and XNA :D.