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.