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
Thursday, May 2, 2013
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.
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
Wednesday, May 1, 2013
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.
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.
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 ;).
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.
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.
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.
Subscribe to:
Posts (Atom)