Prototype 4- The Lurker's Cave

   This prototype things were really different than the previous prototypes we have had. We didn't have client this prototype. So, it was more like indie game style where a team of 6-7 people design and develop a game with no controlling interests or creative limitations. We had a chance to fully exploit our game ideas and we had absolute control over the narrative, mechanics, viewpoint, aesthetics and gameplay of our game.

 We spent our first week on designing the game and later time of the week on physical prototype. We coalesced our ideas into one game idea. During physical prototype, we tested our idea with using different camera viewpoints and kept iterating on the main concept. At last we decided to go with 2.5D viewpoint- a side view but using 3D art assets.

   With less than two weeks to develop the game and just one artist on the team I decided to go a little artistic. I took the task of modeling the antagonist (The explorer) of the game. I used Maya to model the character. Here are some screenshots of the model-

Being a programmer, I didn't quite feel that I did my part in this prototype as I had not contributed much on the code of the game. To overcome this frustration I started pair programming on the AI of the game with Vaibhav Bhalerao who is an engineer on the team. This was the first time I did pair programming. Together, we resolved many AI related problems like best path finding to catch the protagonist and also mechanics of the AI character like giving correct impulses to the character to climb up. We also designed a level of the game.

Pair programming does help in a lot many ways, sometimes coming up with different feasible solutions.

This prototype was a firsthand experience of how things work in indie game development. It will also help in the coming semesters where such small groups would be developing games and competing for IGF.

 This prototype I got a chance to work on Maya and Unity3D. I really feel good that I stepped out of the box and did something which was totally out of my grasp by not much losing my identity as of a programmer. 

Orc Choppin Completed!

  These last three weeks were just crazy work and nothing else. But I just loved working on something so awesome as Orc Choppin. At first everything was going great with the camera movements and using simple textures to create the scene of the game. But then later when the models started coming into the scene, it started getting complex. Handling perfect collision with the target-Orc and trees,rocks to the world boundary was just something.

   

    One of the prime reasons I couldn't update my blog with the game progress was because I was stuck at moving the first person camera on a rough terrain using a terrain model, which made all of us fall behind the schedule. But, it is one of the most challenging things I have encountered while developing this game. I came up with various alternatives for dealing with this problem one of which was using a heightmap and store all the vertices of the terrain so that my camera can move relative to the vertices and the height of the terrain. But, I was really afraid of trying this thing as we were already behind the schedule. I wasted almost 3 days trying to figure out on how to do the camera movement on the rough terrain using different types of collision with BoundingBox, BoundingSphere using rays and triangles and what not. Even, Googling and reading blog didn't help.

  After a while I gave up on the rough terrain and decided to do it later if time allows me to. Gameplay is more important than specific things- like terrain. But, by this time, I had a list of tasks to work on, all piled up on my plate, like-

• Random orcs, trees,rocks, logs generation.
• Collision with orcs, trees, world boundary.
• SkyDome.
• HUD layer.
• Clocks and counts.
• Memory management and resolving FPS drops.
• Sounds-walking, choping, Orc Crying.
• Lighting.
• Animations.
• Splash Screens.
• Testing.
• Working on the loop holes.

    At this point of time I have taken care of all the tasks that I had taken up and the game is up and running. I wasn't able to work well on the FPS dropping down issue because it is a little tricky and I figured out that it can be done in many ways, some of the most trivial and common being-

1. Using Frustum Culling to render only the objects that are inside the camera view.
2. Using the Vertex Buffer to store and render the objects every frame from the main memory.
3. Reducing down the size of model files so that the CPU doesn't go crazy rendering each object per frame.

 These last couple of days, I am going to keep working on the FPS drops and try to keep it to 60. Another thing I can work on is the camera movement on a rough terrain but I am thinking to stick to flat terrain as the theme of the Orc choppin is forest and forests are most of the times flat terrains.

Some sneak-pics of Orc Choppin-

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.