Friday, January 25, 2013

Graphics Assignment 2


This week's assignment was really difficult. Even though, I had everything figured out in my head, I had no idea where to start from. Structuring the code was hardest part. I wasted most of my time studying up DirectX syntax and functions and looking up oversimplfied tutorials.
Enough of ranting, let's move to the code.

Here's is my code
Download

Changes:

- Changed the mesh file format to include Color and Indices.
The new format looks like this:

NoOfTriangles = n
NoOfVertices = n
NoOfIndices = n
Vertices
x , y , z |   r , g , b, a
x , y , z |   r , g , b, a
x , y , z |   r , g , b, a
x , y , z |   r , g , b, a
Indices
i1 , i2 , i3
i1 , i2 , i3

- Added an index buffer and changed the draw call to drawIndexedPrimitive.
- Added a cMesh class, which contains the cube's position and modelToWorld matrix, which transforms the model from Model space to World space. It also contains basic functions for moving around and rotating the mesh about the Y axis. (for now) 
- Added a cCamera class which holds the camera position and worldToView matrix, which transforms the model from World space to View space.
- I am creating the viewToProjected matrix (which transforms the model from View to Projected space , 3d to 2d representation of the model) in the cRenderer class for now.
- Added a LoadTransforms() function to the cRenderer class which loads all these matrices into the Vertex shader.
- Added a GetInput() function to the cRenderer class which gets the user input and moves the camera or cube accordingly.
- Made the Update and waitForShutdownThis non const, for now. This was really frustrating. I was constantly getting 'Conversion loose qualifiers' errors. 

Instructions:
- Move the cube using W,A,S,D.
- Move the camera using the arrow keys.

Screenshot of my funky cube


PIX Screenshots of Mesh Pre and Post Vertex Shader

Game Pitch

Here is a picture of me pitching my thesis game called Prey. 
It was my first time pitching a game and I'm glad that it went smoothly. The profs really liked my concept of having a low hanging dynamic FPS camera that simulates real motion, making you feel immersed in the character and the environment.

Friday, January 18, 2013

Graphics Assignment 1


This week's graphics assignment was simpler than I thought it would be. We were required to build our own mesh format, a mesh builder tool and make some changes to John Paul's vertex and fragment shader.

Here is the download link for my assignment. Download code

File/Mesh format
My file format looks like this:

NoOfTriangles = n
x , y
x , y
x , y
x , y
x , y
x , y

Here is my rectangle mesh for this assignment:

NoOfTriangles = 2
0.6 , -0.5
-0.6 , -0.5
-0.6 , 0.5
-0.6 , 0.5
0.6 , 0.5
0.6 , -0.5

Vertex shader
I changed the vertex shader so that the rectangle moves in a cool counter-clockwise fashion across the window. What I did is basically add a sine wave of the elapsed time to the input x position and subtract the input y position by a cosine wave of the elapsed time. Then I scaled the displacement down by a certain value, so that the rectangle moves inside the window.

Fragment shader
I added a cool negative image effect to the fragment shader, by subtracting 1 by the input color.

Here are a couple of screens:









PIX screenshot of Vertex shader




PIX screenshot of Fragment shader




Notes
I did not run into any problems with the programming part. But I had a hard time dealing with PIX, since I had never used it before and was absent for John's first lecture.

Prototype 4 : The Lurker's Cave


Overview:

The premise of this game is really interesting. It is 2.5 D worms style game where you play as the antagonist, a cave dwelling monster that is trying to protect itself from the explorers, by freezing them and trapping them. You must avoid light throughout the game and since the explorers carry flashlights, being near them for too long depletes your health. So your goal is to come up with tactical and sneaky ways of freezing them, before they find you and kill you.


My contribution:

- I developed a Player controller script from scratch, which essentially manages the core mechanics of the player like moving around, jumping and climbing.
- While playing around with the physics of the player, I implemented this really cool infinite ( yes, not double or triple, but infinite) jump mechanic which I am really proud of. We obviously had to set the maximum jumps to 2 for the game. But, this is something that I thought was really cool and I will probably use this in some of future projects.
- I integrated Alice’s 3D model for the monster into the game and with the player controller.
- I integrated the main camera with the player and fixed a lot of camera synchronization issues.
- I designed the lighting system for our level.

What I learned from this prototype and the positives and negatives of the process:

Positives:

- I got to work with an artist and for the first time ever got to add a completely textured 3D model into my game.
- We set up a SVN server for managing our code, which I think is a must have for every prototype.
- Alice’s model looked really cool and fit well with the theme of our game.
- All the programmers spent a lot of time working together in the lab, which was really productive.
- Our communication was great.

Negatives and What I would have done differently:

- Our game mechanics were pretty ambiguous and no one was willing to sit down and discuss them in detail, thinking it was a waste of time and that we should start working and then see how they work out. I pointed this out a lot of times but gave up in the end. This led to a lot of problems later when we had to merge the mechanics together, because everyone had different ideas about how the mechanics worked.
- Our producers thought it was a good idea to divide work based on roles ( UI programmer, mechanics programmer, etc ), which did not work out very well. Things got messy as some features overlap roles and we did not know how to split them. So we decided to divide the work based on features from further on.
- Unity is not really programmer friendly and when working with a team of 6 programmers, it can cause disasters. Merging the .scene files in Unity was a task in itself and caused a lot of issues.

Prototype 3 : Nemmi

Overview:

Nemmi is a top-down RPG whose goal is to help its players learn about the Shoshone language and culture, through fun gameplay.  It is basically a mash up between Pokemon and Skyrim. The premise is that, a Shoshone Chief Elder has discovered that monsters have been scattered throughout the region and because of this has made the Shoshone Spirits lost and restless. As the main character, your job is to go explore the region, solve puzzles, battle monsters to help put the Shoshone Spirits at peace once more. 



My contribution:

- This game was my idea, so naturally I was really excited about it and worked on a major part of the game.
- I developed the gameplay and AI entities like the Player Entity, Collectible Entity, Monster Entity and Non-Playable Character entities.
- I worked on the world and level design with Zeph. We also worked together on the artwork.
- I developed the NPC conversation system.
What I would have done differently:
- The only thing I’d like to change about this game is fighting system. My team wanted to implement a turn-based fighting system and I always wanted to make it real-time.
What I learned from this prototype and the positives and negatives of the process:
After making two prototypes, there’s not a lot you can learn from making another. So, honestly this was just another prototype for me.

Positives:

- We made a smart choice by choosing to work using the Actor-Entity model of programming, where in the Actor is a generic object and it’s behavior is modded by plugging in different Entity code.
- We set up and SVN server from merging and managing code.
- Implemented the Player Entity quickly.
- The  .TMX editor and parser in MelonJS was just awesome.
- We worked well together. Our communication was good.

Negatives:
- Our choice of engine was bad. We had to write code for the simplest things manually.
- The world’s TMX files got corrupted days before the presentation. We tried redoing as much as possible.
- And like always my team did not have an artist.