Project 2- A new client with a new project

  This time the client is from our own University from Neuroworx. Neuroworx is a licensed physical therapy clinic dedicated to providing innovative, activity-based therapy to individuals with paralysis from spinal cord injuries.

 They have developed a Treadport for people with spinal cord injury. Have a look:

http://www.youtube.com/watch?v=1YhUJVXyJ4I

So. this time we are going 3D. We have to develop an environment for the Treadport so that the patient would want to walk on it and thus get over all his fears of walking/running. So, we have decided to do it our ways- A game as a virtual environment where there would be tasks and score and everything just like a Game. We have to use XNA for developing this prototype. So, I started with C# which is what XNA runs. 

 This week's task for me was to work on Collision Detection with various objects. This week is almost over and I've ended up doing more than just collision detection. 

Setting up a Terrain and objects:

  I followed Riemers Tutorials to set up my terrain. I went step by step first creating a list in which I stored the vertices of the triangle. Whatever you want to render has to be in terms of triangles in XNA. For every single block of terrain, I created two triangles which share the hypotenuse, making it a square shape. Many such sqaures one besides another gave me a flat terrain. Similarly, for the objects I created a list and after doing that I used a texture for both terrain and the object giving them a textured look.

Camera Movement and Controller:

   As the game is 3Dimensional we have a First Person Camera view to work on. This single thing took most of my time because it mostly involves trigonometry. The main problem was that I wasn't able to update the camera to the position of that of the avatar. I tried several times to find the angles and then apply sine and cosine but nothing seemed to be working. In this process, I learned about a new concept of yaw, pitch and roll. This made my problem a little less severe. But still it didn't solve my problem because my sins and cosines concepts are a bit rusty.

After a lot of researching I came across a tutorial about Quaternion. Quaternion is a Matrix, in XNA, that stores the rotation of the avatar. PROBLEM SOLVED. Now, all I had to do was store and update the camera's positions and rotations an inch away from our avatar's positions and rotations. No Trig or complex mathematics needed. Done this my to-do list was updated with one more thing- "Brush up your math skills". 

Collision Detection:

This was a cake walk. Unlike other IDEs, I found XNA very lenient when it comes to collision detection. All I had to do was create a bounding sphere for the avatar and a bounding box for the obstacle between which I wanted a collision and check if there is any collision between these two. 

So, after working on all these aspects, the prototype now looks like this: 

Collision occurs when the avatar hits the green building which takes him back to the starting point.

 Pretty low in graphics and blank as a game right? Well, that's what I am going to work on in the next coming weeks.

  

Postmortem- The post 'game completion' phase

  We are finally through with our first prototype. I don’t know about myself but our professors are very proud of what we have done in just a period of one month. And, our first prototype did not end there. The last thing of all was the Postmortem. 

How Postmortem works:

  A line is drawn on a surface, dividing the complete line horizontally in 4 segments, one segment for one week. You, as a team member, are supposed to write on as many post-its as you want and stick them either on the upper part of the line or the lower. The upper part of the line is used for the things that went brilliant during the prototype and the lower half for the things that went bad or things that disappointed you. If the post-it is on the line then that means that particular activity was neither good nor bad.

 So, our postmortem had 19 post-its above the line and 11 post-its below the line. This seriously means that we had more of amazing stuff going on in our prototype than sad stuff. I was mostly complaining about the design process and how it should’ve been more defined and determined in the early stage itself.

     The whole point of developing prototypes is to iterate on the points which are not working good for the game. Meaning, if the game comes out to be very dull after the final stitches of the code then you are suppose to change those portions or mechanics of the game which makes your game boring. Frankly speaking, we never went that far as to iterate on the prototype. Even at the last minutes of the prototype completion cycle we were trying to make things just work, let alone iterate. Thanks to MOAI for making our lives sick with absolutely no concrete reference material.

 This first prototype taught me many things some of them being:

• The prototype is not a complete game but it’s a way of showing how everything in the game will work.  It does not have to be complete, or for that matters, polished. In short, it’s a demo.

• Team working manners.

• One Agile process which we are going to use from the next prototype onwards- SCRUM- A standup meeting.

• Good programming techniques and a little bit of frameworks and engines.

    

we are almost there

     After three weeks of project work we are finally ready with our first prototype: Ranch Rancers!! On Monday, we are going to present the dry run of the game pitch to our professors  and the other groups. Zeph, the producer, is going to explain the Game idea while actually running a video of the game in front of the cohort. I am gussing that there are going to be some last minute corrections in the game, after which we will finally present the game pitch to our client on Wednesday.

    
 This is how the game looks: A GamePlay of Ranch Racers

  

  We tried working on the different aspects of the game like- velocities of the characters, positions, timers, mouse clicks etc. We uncovered all most all the loopholes and amended most of them to work right. Zeph did an amazing job with the artwork which gives our prototype a look of completeness.
 

    All in all, the game is fun to play and we, the team sayCheese, are successful in our first prototype, period. 

Working on the First Game!

So, this week was a little less intense as compared to the last one. That is mostly because I am getting more comfortable with this city, my studies and most importantly with food :D I am learning amazing things about Gaming in my classes. I am loving what I am doing right now-Gaming !

  

   We all have been working on the Game and trying to create what we want to. As predicted, things aren't that smooth with this SDK and this language. Zeph is currently working on the artwork. Kiran is working on the artwork that Zeph has created, trying to bring animation out of that. Jon and I, are working on the the game mechanics, trying on making the prototype more game-like and playable.

   

   Currently, I am working on one part of the game- bees . The bees are supposed to fly in random direction and with uniform speed. Doing all of this takes patience as you need to do a lot of dry runs to get what you really want. So, one of the biggest problems I am facing right now is that when i work on my task I get a lot of different outputs at first, all of which feels right- this is a big big problem when engineers are a part of the deigning team, that they try to alter the game concepts because in the process of developing the game they initially come across variants of output, one of which they think is the best for the game. In such case, the game might keep evolving and no final or fixed result will ever be achieved (Risky).  

     

   But I am coming over this problem with a simple rule. A simple rule for myself? What am I? insane or something? But trust me it helps. RULE - Engineers should not be allowed to mess with the game design which is decided by the design team! Only when what was decided is achieved should the Design team meet again and try to figure out if the developed game/feature is better  than the one with the changes suggested by the Engineers.

    

   The coming week is the last week, by the end of which we have to complete our prototype and have to present it to the Client. I am excited about the next coming weeks when we get to play our own game and get to do some testing on it. I am looking forward to completing this prototype in the best possible way.